最近幾年，接觸了很多團隊，特別是創業的技術團隊，大家容易犯的一個錯誤就是有些形而上學，而沒有真正瞭解背後的真正原因。
比方說，大家對「快速迭代」有共識，沒有團隊會反對執行快速迭代，但也有嚴重的誤解。事實上，很多團隊沒有做好快速迭代的真正原因，並不是工程師能力差或者不願意快速迭代，而是沒有一個可以支持快速迭代的架構和基礎工具。想快速迭代，對架構設計的要求是比平常更高的，這裏說的不是高併發、高可用的架構，而是支持高迭代的架構。
在一個產品的初期，很多技術管理者思考的是高可用，其實完全錯了，而是應該思考快速迭代的框架，爲什麼？因爲產品的方向和細節剛開始是很難想明白的，包括大家正在用的微信，龍哥當時也沒完全想明白。另外，更別說剛開始產品就沒有幾個用戶。
有朋友會跳出來，高可用和快速迭代矛盾嗎？可以兩者兼有嘛。但實際上，我們就是要分出「主要」:
快速迭代的架構「主要」是爲了「開發階段」。高可用的架構是「主要」爲了「增長」階段，高擴展的架構是「主要」爲了「運維階段」。這幾者是不同的。
我喜歡用「維度」來思考框架：無論是技術還是業務框架亦是如此。維度的思考方式可以讓我，在一段時間只關注一個方面，避免分心，可以有最大的思考成果，能最大化的實現業務目標。在不同維度下，我會進一步看，是否還有必要進行細分。
下車了，昨天忘記提前買票了，今天只買到站票，反而讓我加速寫完。