Netflix工作環境的分析和思考
Netflix是業界微服務架構的最佳實踐者，其基於公有云上的微服務架構設計、持續交付、監控、穩定性保障，都爲業界提供了大量可遵從的原則和實踐經驗。
Netflix是沒有運維崗位的，和運維對應的崗位其實是我們熟知的SRE（Site Reliability Engineer）。但我們知道SRE≠運維，SRE理念的核心是：用軟件工程的方法重新設計和定義運維工作。
爲什麼Netflix會做得如此極致？
我想這個問題可以從Netflix的技術架構、組織架構、企業文化等幾個方面來看：
海量業務規模下的技術架構和挑戰
前面我也提到，Netflix在業務高速發展以及超大規模業務體量的驅動下，引入了更爲靈活的微服務架構，而且已經成爲業界的最佳實踐典範。
引入微服務架構後，軟件架構的細化拆分和靈活多變，大大提升了開發人員的開發效率，繼而也就提升了業務需求的響應和迭代速度，我想這也正是微服務思想在業界能夠被廣泛接受和採用的根本原因。
但是這也並不是說沒有一點代價和成本，隨之而來的便是架構複雜度大大增加，而且這種複雜度已經遠遠超出人的認知能力，也就是我們已經無法靠人力去掌控了，這也就爲後續的交付和線上運維帶來了極大的難度和挑戰。
這時，微服務架構下的運維就必須要靠軟件工程思路去打造工具支撐體系來支持了，也就是要求微服務架構既要能夠支持業務功能，還要能夠提供和暴露更多的在後期交付和線上運維階段所需的基礎維護能力。
簡單舉幾個例子，比如服務上下線、路由策略調整、併發數動態調整、功能開關、訪問ACL控制、異常熔斷和旁路、調用關係和服務質量日誌輸出等等，要在這些能力之上去建設我們的運維工具和服務平臺。
講到這裏，我們可以看到，微服務架構模式下，運維已經成爲整體技術架構體系中必不可少的一部分，而且與微服務架構相關的體系是緊密相連不可拆分的。
我們現在看到很多跟SRE相關的文章或內容，對於SRE產生原因的解釋，大多是說爲了緩解開發和運維之間的矛盾，樹立共同的目標，讓雙方能夠更好地協作配合。這樣理解也沒有太大的問題，但是我認爲不夠充分，或者說以上這些只能算是結果，但不是背後的根本原因。
我理解的這背後最根本的原因是，微服務架構複雜度到了一定程度，已經遠遠超出單純的開發和單純的運維職責範疇，也遠遠超出了單純人力的認知掌控範圍，所以必須尋求在此架構之上的更爲有效和統一的技術解決方案來解決複雜度認知的問題。進而，在這一套統一的技術解決方案之上，開發和運維產生了新的職責分工和協作方式。
目前業界火熱的DevOps理念及衍生出來的一系列話題，我們可以仔細思考一下，其實也是同樣的背景和邏輯。DevOps想要解決的開發和運維之間日益嚴重的矛盾，究其根本，還是微服務架構背後帶來的技術複雜度在不斷提升的問題。
Netflix帶給我們的啓示一：微服務架構模式下，我們必須換一個思路來重新定義和思考運維，運維一定要與微服務架構本身緊密結合起來。
更加合理的組織架構和先進的工具體系及理念
我上面提到，在微服務架構模式下，運維已經成爲整體技術架構和體系中不可分割的一部分，兩者脫節就會帶來後續一系列的嚴重問題。
從這一點上，不得不說Netflix的前瞻性和技術架構能力還是很強的。因爲早在2012年，甚至更早之前，Netflix就已經意識到了這個問題。在組織架構上，將中間件、SRE、DBA、交付和自動化工具、基礎架構等團隊都放在統一的雲平臺工程（Cloud and Platform Engineering）這個大團隊下，在產品層面統一規劃和建設，從而能夠最大程度地發揮組織能力，避免了開發和運維的脫節。
當然，這個團隊不僅沒讓大家失望，還給我們帶來了太多驚喜。業界大名鼎鼎的NetfixOSS開源產品體系裏，絕大部分的產品都是這個團隊貢獻的。
比如持續交付系統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，要對你發佈的代碼和線上服務的穩定運行負責。
在這種文化的驅使下，技術團隊自然會考慮從開發設計階段到交付和線上運維階段的端到端整體解決方案，而不會是開發就只管需求開發，後期交付和維護應該是一個叫運維的角色去考慮。No，文化使然，在Netflix是絕對不允許這種情況存在的，你是開發，你就是Owner，你就要端到端負責。
所以，短短兩個英文單詞，Freedom & Responsibility，卻從源頭上就決定了團隊和員工的做事方式。
Netflix帶給我們的啓示三：Owner意識很重要，正確的做事方式需要引導，這就是優秀和極致的距離。
總結:
通過上面的分析，我們可以看到，Netflix在其技術架構、組織架構和企業文化等方面的獨到之處，造就了其優秀的技術理念和最佳實踐。從運維的角度來說，無論是SRE也好，還是DevOps也罷，都被Netflix發揮到了極致。
當前問題：
現在很多公司在採用了微服務架構後，就沒有充分考慮到後續基於微服務架構的運維問題。而且在運維團隊設置上，仍然是脫離整個技術團隊，更不用說將其與中間件和架構設計等團隊整合拉通去建設，自然也就談不上在產品層面的合理規劃和建設了。
因此導致的問題就是運維效率低下，完全靠人工，線上故障頻發，但是處理效率又極低，開發和運維都處於非常痛苦的狀態之中，運維團隊和成員也會遭遇到轉型和成長的障礙。
以上這些問題都很棘手，亟待解決。後面我們詳細解釋。
精選提問：
-
有具體的Netflix原則和最佳實踐參考嗎？
推薦兩個Netflix的技術網站(需要翻越)： Netflix的Tech Blog：https://medium.com/Netflix-techblog Netflix公開分享的PPT合集：https://www.slideshare.net/Netflix 特別是第一個，Netflix會持續更新他們的技術動態和實踐，很好的學習案例。slideshare這個雖然內容大部分是前些年的，不過仍然會有很大的啓發意義，在這裏會體驗到Netflix的技術前瞻性。 後面我也會有文章分享我們的一些實踐，期望對你會更有幫助 -
owner 直接體現了自帶責任屬性 可以避免好多推鍋和定位故障難問題
把事情當作自己的，處理起來最高效 -
作爲運維人員如何權衡自己的發展呢？如果將來的運維人員的發展方向更偏於容器，k8s，自動化。那企業內應用，比如說windows的AD運維，exchange運維。企業如何在沒有開發團隊的基礎上實現運維？開發團隊如何在遠離生產環境的模式中實現owner&build？
我看下來應該是三個問題，也確實是一個個非常典型的現狀，我的答覆如下： 第一個，關於如何衡量個人發展，這個問題說實話有點大，我可能無法回答全面，我建議可以把問題再具體一些。然後，個人是否能夠有發展，是否能夠發展地還不錯，這裏暗含着一個關鍵的前提，就是要看你個人想要什麼，想要成長成什麼樣子。 第二個，容器、k8s和自動化，一定是未來的演進趨勢，因爲它們確實能夠帶來更高的效率，讓人工作的更輕鬆，任何技術的發展只要能夠起到上面這兩個作用，就一定是有生命力的，代表着未來趨勢。 第三個，關於企業內第三方產品的運維和開發問題，我的建議是當內部無法基於這些產品進行運維效率和穩定性提升方面的二次開發時，還是儘量依賴第產品方的服務，看產品方是否可以提供一些運維方便產品技術支持。 從你反饋的單個案例來看，如果還是保持現狀，你提到的運維和開發這兩個事情都很難改變，因爲受限於產品形態和合作模式。但是從整個業界來看，你提到的這兩個產品，其實微軟都已經將它們上雲了，如果是在雲上應用，這些問題是不是就不是問題了？ 可能有些問題的答案是在問題之外的，這一點可以多考慮一下，因爲隨之而來的還會有其它一系列問題要去考慮。 思考之後，可以繼續留言給我。 -
傳統應用的運維模式會逐漸轉變到這種模式下嗎？那運維外包業務豈不是會慢慢萎縮，運維人員的成長也被侷限了。
必然會向這個方向發展，是不是會萎縮不一定，但是發展空間一定會受限。 -
我能明白市場選擇所帶來的陣痛，不管是對企業對個人。其實運維主要面臨兩個問題：
一個是企業方面，如果市場趨勢如此，那企業在選擇業務服務的話，是否應該把運維獨立出來以服務的形
式提供，並且押寶在上面。
另一個就是運維人員，因爲如果按照這種趨勢下去，運維最終會由工具的使用者轉變爲工具的製造者。這個轉變是巨大的，也有會一部分開發者進入這一領域，對傳統運維衝擊很大。另外就是對第三方獨立應用來說，如何提供產品，以及後續的交付都是值得深思的地方。
2019年~2020年現在對於運維者，可以懂得一門開發語言的需求變的更重要，這已經代表運維會從工具的使用者變成工具的製造者。這樣對於運維的要求更高。 但是運維管理者的要求，則更偏向技術架構方面的規劃和結合生產業務，轉變運維思路上的轉變，遠比單純提升運維技術更有價值，而運維真正的價值應該跟研發團隊保持一致，真正聚焦到效率、穩定和成本上來。 -
從專精的角度上考慮，開發和運維技術棧，看待問題的角度還是有所區別的，我比較好奇Netflix的開發人員如何做到既能關注自身開發的功能，又能關注到產品上線後的運維和部署架構？他們到達今天這個程度是開發的能力推動，還是因爲運維基礎平臺的完善推動？
這個是自驅動型的，當然，很重要的一個前提是，他們技術能力非常強大，這個是國內達不到的，所以更多的需要組織架構上互補。