Netfix業務運維分析和總結

眾所周知，Netfix是業界微服務架構的最佳實踐者，其基於公有云上的微服務架構設計、持續交付、監控、穩定性保障，都為業界提供了大量可遵從的原則和實踐經驗。

Netfix超前提出某些理念並付諸實踐，以至於在國內眾多網際網路公司的技術架構上也可以看到似曾相識的影子。當然殊途同歸也好，經驗借鑑也罷，這都不影響Netfix業界最佳實踐者的地位。

Netfix運維現狀

準確一點說，Netfix是沒有運維崗位的，和運維對應的崗位其實是我們熟知的SRE（Site Reliability Engineer）。但我們知道SRE≠運維，SRE理念的核心是：用軟體工程的方法重新設計和定義運維工作。

也就是要改變之前靠人去做運維的方式，轉而通過工具體系、團隊協作、組織機制和文化氛圍等方式去改變，同時將之前處於研發體系最末端的運維，拉回到與開發肩並肩的同一起跑線上。

但是Netfix的神奇和強大之處在於，連Google都非常重視和大力發展的SRE崗位，在Netfix卻沒有幾個。按照Netfix一位技術主管（Katharina Probst）在今年9月份更新的部落格中所描述，在1億使用者，每天1.2億播放時長、萬級微服務例項的業務體量下，SRE人數竟然不超過10個，他們稱這樣的角色為Core SRE。

不可否認，Netfix擁有強大的技術實力和全球最優秀的工程師團隊。按照SRE的理念，完全可以打造出這一系列的工具產品來取代運維和SRE的工作。但是能夠做到如此極致，就不得不讓人驚歎和好奇，Netfix到底是怎麼做到的？

為什麼Netfix會做得如此極致？

這確實是一個很有意思的問題，帶著這樣的疑問，閱讀了大量的Netfix技術文章和公開的演講內容之後，我想這個問題可以從Netfix的技術架構、組織架構、企業文化等幾個方面來看。

海量業務規模下的技術架構和挑戰

前面我也提到，Netfix在業務高速發展以及超大規模業務體量的驅動下，引入了更為靈活的微服務架構，而且已經成為業界的最佳實踐典範。

引入微服務架構後，軟體架構的細化拆分和靈活多變，大大提升了開發人員的開發效率，繼而也就提升了業務需求的響應和迭代速度，我想這也正是微服務思想在業界能夠被廣泛接受和採用的根本原因。

但是這也並不是說沒有一點代價和成本，隨之而來的便是架構複雜度大大增加，而且這種複雜度已經遠遠超出人的認知能力，也就是我們已經無法靠人力去掌控了，這也就為後續的交付和線上運維帶來了極大的難度和挑戰。 這時，微服務架構下的運維就必須要靠軟體工程思路去打造工具支撐體系來支援了，也就是要求微服務架構既要能夠支援業務功能，還要能夠提供和暴露更多的在後期交付和線上運維階段所需的基礎維護能力。

簡單舉幾個例子，比如服務上下線、路由策略調整、併發數動態調整、功能開關、訪問ACL控制、異常熔斷和旁路、呼叫關係和服務質量日誌輸出等等，要在這些能力之上去建設我們的運維工具和服務平臺。

講到這裡，我們可以看到，微服務架構模式下，運維已經成為整體技術架構體系中必不可少的一部分，而且與微服務架構相關的體系是緊密相連不可拆分的。

我們現在看到很多跟SRE相關的文章或內容，對於SRE產生原因的解釋，大多是說為了緩解開發和運維之間的矛盾，樹立共同的目標，讓雙方能夠更好地協作配合。這樣理解也沒有太大的問題，但是我認為不夠充分，或者說以上這些只能算是結果，但不是背後的根本原因。

我理解的這背後最根本的原因是，微服務架構複雜度到了一定程度，已經遠遠超出單純的開發和單純的運維職責範疇，也遠遠超出了單純人力的認知掌控範圍，所以必須尋求在此架構之上的更為有效和統一的技術解決方案來解決複雜度認知的問題。進而，在這一套統一的技術解決方案之上，開發和運維產生了新的職責分工和協作方式。

目前業界火熱的DevOps理念及衍生出來的一系列話題，我們可以仔細思考一下，其實也是同樣的背景和邏輯。DevOps想要解決的開發和運維之間日益嚴重的矛盾，究其根本，還是微服務架構背後帶來的技術複雜度在不斷提升的問題。

Netfix帶給我們的啟示一：

微服務架構模式下，我們必須換一個思路來重新定義和思考運維，運維一定要與微服務架構本身緊密結合起來。

2.更加合理的組織架構和先進的工具體系及理念

我上面提到，在微服務架構模式下，運維已經成為整體技術架構和體系中不可分割的一部分，兩者脫節就會帶來後續一系列的嚴重問題。

從這一點上，不得不說Netfix的前瞻性和技術架構能力還是很強的。因為早在2012年，甚至更早之前，Netfix就已經意識到了這個問題。在組織架構上，將中介軟體、SRE、DBA、交付和自動化工具、基礎架構等團隊都放在統一的雲平臺工程（Cloud and Platform Engineering）這個大團隊下，在產品層面統一規劃和建設，從而能夠最大程度地發揮組織能力，避免了開發和運維的脫節。

當然，這個團隊不僅沒讓大家失望，還給我們帶來了太多驚喜。業界大名鼎鼎的NetfixOSS開源產品體系裡，絕大部分的產品都是這個團隊貢獻的。

比如持續交付系統Spinnaker；穩定性保障工具體系Chaos Engineering，這裡面最著名的就是那隻不安分的猴子，也正是這套穩定性理念和產品最大程度地保障了Netfix系統的穩定執行；被Spring Cloud引入並得以更廣泛傳播的Common Runtime Service&Libraries，而且大家選用Spring Cloud基本就是衝著Spring Cloud Netfix這個子專案去的。

當然還有很多其它優秀的開源產品，這裡我就不一一介紹了。

Netfix帶給我們的啟示二：

合理的組織架構是保障技術架構落地的必要條件，用技術手段來解決運維過程中遇到的效率和穩定問題才是根本解決方案。

3.自由與責任並存的企業文化

上面講了這麼多，看上去好像就是SRE常見的理念和套路，只不過Netfix在開源和分享上更加開放和透明，讓我們有機會更多地瞭解到一些細節。但是為什麼Netfix會做的如此極致呢？好像我們一直沒有回答到這個問題，那這裡就不得不提Netfix的企業文化了。

Netfix的企業文化是 Freedom & Responsibility，也就是自由和責任並存，高度自由的同時，也需要員工具備更強的責任心和Owner意識。

體現在技術團隊中就是，You Build It，You Run It。工程師可以隨時向生產環境提交程式碼或者釋出新的服務，但是同時你作為Owner，要對你釋出的程式碼和線上服務的穩定執行負責。

在這種文化的驅使下，技術團隊自然會考慮從開發設計階段到交付和線上運維階段的端到端整體解決方案，而不會是開發就只管需求開發，後期交付和維護應該是一個叫運維的角色去考慮。No，文化使然，在Netfix是絕對不允許這種情況存在的，你是開發，你就是Owner，你就要端到端負責。

所以，短短兩個英文單詞，Freedom & Responsibility，卻從源頭上就決定了團隊和員工的做事方式。

Netfix帶給我們的啟示三：Owner意識很重要，正確的做事方式需要引導，這就是優秀和極致的距離。

總結

通過上面的分析，我們可以看到，Netfix在其技術架構、組織架構和企業文化等方面的獨到之處，造就了其優秀的技術理念和最佳實踐。從運維的角度來說，無論是SRE也好，還是DevOps也罷，都被Netfix發揮到了極致。

當然，Netfix能做到這一點，是需要非常強大的技術實力和人才儲備的。當前我們雖然沒法直接套用，但是這並不妨礙我們在某些經驗和思路上去借鑑和學習。

比如，現在很多公司在採用了微服務架構後，就沒有充分考慮到後續基於微服務架構的運維問題。而且在運維團隊設定上，仍然是脫離整個技術團隊，更不用說將其與中介軟體和架構設計等團隊整合拉通去建設，自然也就談不上在產品層面的合理規劃和建設了。

因此導致的問題就是運維效率低下，完全靠人工，線上故障頻發，但是處理效率又極低，開發和運維都處於非常痛苦的狀態之中，運維團隊和成員也會遭遇到轉型和成長的障礙。

以上這些問題都很棘手，亟待解決。

通過今天的分享，我們瞭解了Netfix的技術團隊運作模式和思路，不知道給你帶來了哪些啟示呢？