關于頂級公司Netflix 的運維揭秘，趙成老師在新書《進化：運維技術變革與實踐探索》中有比較詳細的分析。
眾所周知，Netflix 是業界微服務架構的最佳實踐者，其基于公有云上的 微服務架構設計、持續交付、監控、穩定性保障，都為業界提供了大量可以 遵從的原則和實踐經驗。
Netflix 超前提出了某些理念并付諸實踐，以至于在國內眾多互聯網公司 的技術架構上都可以看到似曾相識的影子。當然，殊途同歸也好，經驗借鑒 也罷，這都不影響 Netflix 作為業界最佳實踐者的地位。
同樣，在運維這個細分領域，Netflix 仍然是最佳實踐的典范。所以在本 書的開始，就讓我們一起看看世界頂級的互聯網公司是如何定義運維以及如 何開展運維工作的。
1. 沒有運維的 Netflix
準確一點來說，Netflix 是沒有運維崗位的，和運維對應的崗位其實是我 們熟知的 SRE(Site Reliability Engineer)。但我們知道 SRE 不等于運維， SRE 理念的核心是，用軟件工程的方法重新設計和定義運維工作。
但是 Netflix 的神奇和強大之處在于，連 Google 都非常重視和大力發展 的 SRE 崗位，在 Netflix 卻沒有幾個。按照 Netflix 一位技術主管在 2017 年 9 月更新的博客中所描述的，在 1 億用戶、每天 1.2 億小時播放時長、萬級
微服務實例的業務體量下，Netflix 的 SRE 人數卻不超過 10 個，他們稱這樣 的角色為 Core SRE。具體描述如下:
100+ Million members. 125+ Million hours watched per day. Hundreds of microservices. Hundreds of thousands of instances. Less than 10 Core SREs.
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ——Katharina Probst
不可否認，Netflix 擁有強大的技術實力和全球最優秀的工程師團隊。按 照 SRE 的理念，完全可以打造出一系列的工具產品來取代運維和 SRE 的工作。 但是 Netflix 能夠做到如此極致，就不得不讓人驚嘆和好奇，它到底是怎么 做的?
2. Netflix 是如何成為行業典范的
這確實是一個很有意思的問題，我帶著這樣的疑問，閱讀了大量的 Netflix 技術文章和公開的演講內容之后，我想可以從 Netflix 的技術架構、 組織架構、企業文化等幾個方面來看這個問題。
海量業務規模下的技術架構和挑戰
前面提到，Netflix 在業務高速發展以及超大規模業務體量的驅動下，引 入了更為靈活的微服務架構，而且已經成為業界的最佳實踐典范。
引入微服務架構后，軟件架構的細化拆分和靈活多變，大大提升了開發人員的開發效率，繼而也就提升了業務需求的響應和迭代速度，我想這也正是微服務思想在業界能夠被廣泛接受和采用的根本原因。
但是這樣做也并不是說沒有一點代價和成本，隨之而來的便是架構復雜度大大增加，這種復雜度已經遠遠超出人的認知能力，也就是我們已經無法靠人力去掌控了，這也就為后續的交付和線上運維帶來了極大的難度和挑戰。
這是，微服務架構下的運維就必須要靠通過軟件工程思路打造工具支撐體系來支持了，也就是要求微服務架構既要能夠支持業務功能，也要能夠提供和暴露更多在后期交付和線上運維階段所需的基礎維護能力。
簡單舉幾個例子，比如服務上下線、路由策略調整、并發數動態調整、 功能開關、訪問 ACL 控制、異常熔斷和旁路、調用關系和服務質量日志輸 出等，要在這些能力之上建設我們的運維工具和服務平臺。
講到這里，我們可以看到，在微服務架構模式下，運維已經成為整體技 術架構體系中必不可少的一部分，而且與微服務架構相關的體系是緊密相連、 不可拆分的。
我們現在看到很多和 SRE 相關的文章或內容，對于 SRE 產生原因的解 釋，大多是說為了緩解開發和運維之間的矛盾，樹立共同的目標，讓雙方能 夠更好地協作配合。這樣理解也沒有太大的問題，但是我認為不夠充分，或 者說以上這些只能算是結果，不是背后的根本原因。
我理解的背后最根本的原因是，微服務架構復雜到了一定程度，已經遠遠超出單純的開發和單純的運維職責范疇，也遠遠超出了單純的人力認知掌控范圍，所以必須尋求在架構之上的更為有效和統一的技術解決方案，來解決復雜度認知的問題。在這一套統一的技術解決方案之上，開發和運維進而產生了新的職責分工和協作方式。
對于目前業界火熱的 DevOps 理念及其衍生出來的一系列話題，我們可 以仔細思考一下，其實也是同樣的背景和邏輯。DevOps 想要解決的是開發和運維之間日益嚴重的矛盾，究其根本，還是微服務架構背后的技術復雜度在不斷提升的問題。
Netflix 帶給我們的啟示一:在微服務架構模式下，我們必須換一個思路 來重新定義和思考運維，運維一定要與微服務架構本身緊密結合起來。
更加合理的組織架構和先進的工具體系及理念
前面提到，在微服務架構模式下，運維已經成為整體技術架構和體系中不可分割的一部分，兩者脫節就會帶來后續一系列的嚴重問題。
從這一點上，不得不說 Netflix 的前瞻性和技術架構能力還是很強的。 因為早在 2012 年，甚至更早之前，Netflix 就已經意識到了這個問題。在組 織架構上，將中間件、SRE、DBA(DataBase Administrator，數據庫管理員)、 交付和自動化工具、基礎架構等團隊都放在統一的云平臺工程(Cloud and Platform Engineering)這個大團隊下，在產品層面統一規劃和建設，從而能 夠最大程度地發揮組織能力，避免了開發和運維的脫節。
當然，這個團隊不僅沒讓大家失望，還給我們帶來了很多驚喜。在業界 大名鼎鼎的 Netflix OSS 開源產品體系里，絕大部分的產品都是這個團隊貢 獻的。
比如，持續交付系統 Spinnaker;穩定性保障工具體系 Chaos Engineering， 這里面最著名的就是那只不安分的猴子，也正是這套穩定性理念和產品最大 程度地保障了 Netflix 系統的穩定運行;被 Spring Cloud 引入并得以更廣泛 傳播的 Common Runtime Service&Libraries，而且大家選用 Spring Cloud 基本 就是沖著 Spring Cloud Netflix 這個子項目去的。當然還有很多其他優秀的開 源產品，這里就不一一介紹了。
Netflix 帶給我們的啟示二:合理的組織架構是保障技術架構落地的必要 條件，用技術手段來解決運維過程中遇到的效率和穩定性問題才是根本解決方案。
自由與責任并存的企業文化
上面講了這么多，看上去好像就是 SRE 常見的理念和套路，只不過 Netflix 在開源和分享上更加開放和透明，讓我們有機會更多地了解到一些細 節。但是為什么 Netflix 會做得如此極致呢?好像我們一直沒有回答這個問題， 說到這里就不得不提 Netflix 的企業文化了。
Netflix 的企業文化是“Freedom & Responsibility”，也就是自由和責任 并存，高度自由的同時，也需要員工具備更強的責任心和 Owner(責任人) 意識。
體現在技術團隊中就是“You Build It，You Run It”。工程師可以隨時 向生產環境提交代碼或者發布新的服務，但是工程師同時作為 Owner，要對 自己發布的代碼和線上服務的穩定運行負責。
在這種文化的驅使下，技術團隊自然會考慮從開發設計階段到交付和線 上運維階段的端到端整體解決方案，而不會是開發人員就只管需求開發，后 期交付和維護應該由一個叫運維的角色去考慮。文化使然，在 Netflix 是絕對 不允許這種情況存在的，你是開發人員，你就是 Owner，你就要端到端地負責。
所以，雖然是短短兩個英文單詞——Freedom & Responsibility，卻從源 頭上決定了團隊和員工的做事方式。
Netflix 帶給我們的啟示三:Owner 意識很重要，正確的做事方式需要引導，這就是優秀和極致的距離。
3. 總結
通過上面的分析，我們可以看到，Netflix 在其技術架構、組織架構和企 業文化等方面的獨到之處，造就了其優秀的技術理念和最佳實踐。從運維的 角度來說，無論是 SRE 也好，還是 DevOps 也罷，都被 Netflix 發揮到了極致。
當然，Netflix 能做到這一點，是需要非常強大的技術實力和人才儲備的。 當前我們雖然沒辦法直接套用它的整套體系，但是這并不妨礙我們在某些經 驗和思路上去借鑒和學習。
比如，現在很多公司在采用了微服務架構后，就沒有充分考慮到后續基于微服務架構的運維問題，而且在運維團隊的設置上，仍然脫離了整個技術團隊，更不用說將其與中間件和架構設計等團隊整合拉通區建設，自然也就談不上在產品層面上的合理規劃和建設了。
因此導致的問題就是運維效率低下，完全靠人工，線上故障頻發，但是處理效率又極低，開發和運維都處于非常痛苦的狀態中，運維團隊和成員也會遭遇到轉型和成長的障礙。
以上這些問題都很棘手，亟待解決。通過本節內容，我們了解了 Netflix 技術團隊的運作模式和思路，不知道給你帶來了哪些啟示呢?
