對于像Netflix這樣服務上億用戶的軟件服務提供商來說，服務運營是非常復雜的。按照傳統的做法，復雜的事情需要專業的分工，于是整個軟件生命周期會有設計、開發、測試、部署、運營、支持等不同的術業有專攻的團隊和角色進行配合。但是這種做法會增加溝通損耗，導致問題經常被踢皮球。于是Netflix在實驗中實踐出了一套采用DevOps原則的混合模型：全周期開發者模式——誰開發的業務誰來運營，誰出的問題誰負責。同時設立了集中化團隊來支撐不同的DevOps團隊的公共需求。
2012年的時候在Netflix運營一項關鍵服務是很費力的。開發感覺就像在濕沙中行走。金絲雀部署變成了對耐心的測試（“一周的金絲雀測試都沒問題發生所以我們繼續推進吧”）而不是正確的功能。研究問題就好像橡皮球一樣在團隊之間被踢來踢去，很難抓住根源，想要阻止大家不再踢皮球更是難上加難。
時間快進到2018年，Netflix已經發展到擁有1.25億的全球會員，每天的瀏覽量超過了140萬小時。我們已經在改進開發運營方面進行了顯著投入。一路走來我們試驗了很多服務開發和運營的方案。在此，我們愿意把其中一種我們內部用得相對普遍的方案，包括它的優缺點拿出來跟大家分享。我們希望我們的經驗分享能給大家一點啟發并且討論出可能的替代方案。
一支團隊的旅程
Edge Engineering（邊緣工程）負責AWS服務的第一層，必須為Netflix的流媒體服務正常工作準備就緒。在過去，Edge Engineering有專注運營的團隊以及SRE（網站可靠性工程師）專家，他們負責軟件生命周期的部署+運營+支撐這部分。發布新功能意味著開發跟運營團隊要協調指標、告警及容量考慮等東西，然后再把代碼交給運營團隊部署和運營。要想高效運行代碼并支持合作伙伴，運營團隊需要持續接受新功能和修補bug的培訓。擁有一支獨立運營團隊的主要好處是在一切正常的時候對開發者的干擾沒那么多。
可當情況進展不暢時，成本就會提高。開發和運營/SRE人員之間的溝通和知識轉移是有損耗的，調試問題或者回答伙伴問題需要額外的來回。部署問題因為運營團隊對部署的變更沒那么多直接知識，所以檢測和解決需要更多的時間。代碼完成與部署之間的鴻溝變得更大，發布往往是以周為量級而不是日。反饋從運營發起，這幫人直接經歷了缺少告警/監控或者性能問題及時延增加這樣的痛苦，然后再傳遞到開發人員這里時問題已經是二手了。
為了改善這種情況，Edge Engineering實驗了一種混合模型，就是開發人員可以在需要的時候自己推送代碼，同時負責非高峰期的生產問題和支持請求。這改善了開發者的反饋和學習周期。但這會出現部分的責任不到位的問題。比方說，即便開發者可以自己部署和調試管道破損，他們往往也會交給運營發布專家處理。對于聚焦運營的人來說，他們對日常工作有積極性，但是很難會把無需別人依賴自己的自動化放在優先考慮的位置。
為了尋找更好的解決辦法，我們退后一步決定從第一性原理開始。我們究竟想實現什么？以及為什么我們不能成功？
軟件生命周期
軟件生命周期的目的是優化“時間價值”，有效地將想法轉化為替客戶做出產品和服務。開發和運行軟件服務涉及到一系列的責任：
軟件開發生命周期組件
我們一直在細分這些責任。極端情況下，這意味著每一個職能領域都由不同的人/角色負責：
軟件開發生命周期專家
這些專門的角色在每一個細分領域內創造出了效能，但是卻有可能造成整個生命周期的低效。專家在其聚焦的領域發展專業知識并針對該領域的需要進行優化。他們在解決特定領域的難題上變得越來越高效。但是軟件需要整個生命周期來為客戶提供價值。各自精通生命周期的一小塊的專家團隊反而可能會制造出煙囪導致整個端到端流程放緩。將不同的專家組成一個團隊能減少煙囪，但讓不同的人負責各自角色又增加了溝通負擔，引入了瓶頸，并且抑制反饋回環的效能。
運營你開發的東西
為了反思我們的做法，我們從開發運營（devops）運動的原則總獲取靈感。我們可以通過打破煙囪并鼓勵分享整個軟件開發周期的所有權來優化學習和反饋：
支持devops原則的軟件開發生命周期
“運營你開發的東西”通過讓開發系統的團隊也負責系統的運營和支持來踐行devops原則。把這個責任分攤給每一支開發團隊，而不是外化它，這樣就建立直接反饋回環并且把激勵給統一起來。感受到運營痛苦的團隊被賦權通過改變系統設計或代碼來治療這種痛苦；他們要負責這兩種職能。每一支開發團隊都要負責部署問題、性能bug、能力規劃、告警差異、伙伴支持等等。
利用開發者工具擴張
對整個開發生命周期的所有權給軟件開發者顯著增加了負擔。這就需要有簡化和自動化共同開發需求的工具來減輕負擔。比方說，如果軟件開發者預期要管理服務的回滾的話，就要有豐富的工具既能檢測到問題并予以告警，又能輔助進行回滾才行。
Netflix建立了集中化團隊（比如Cloud Platform、Performance & Reliability Engineering以及Engineering Tools）來解決每一支開發團隊都會遇到的問題，其使命是開發公共工具和基礎設施。這些集中化團隊將自己的專業知識變成了可重用的建構塊，充當了力量倍增器的作用。比方說：
專家創建可重用的工具
有了這些工具在手，開發團隊就可以專注地解決自身特定產品領域的問題。當額外的工具需求產生時，集中化團隊會評估多個開發團隊是否也有這些需求。如果有，接著就要協作。有時候這些局部需求太過特殊而無法獲得集中化的投入。在這種情況下開發團隊就要決定其需求是否重要到需要自己解決。
對類似問題在局部與集中投資間進行平衡是我們的方案當中最棘手的地方。按照我們的經驗尋找開發需求的新穎解決方案的好處，是值得冒險讓多支團隊同時開發在將來殊途同歸的解決方案的。溝通與協調是成功的關鍵。通過協調好需求及其共性，我們就能更好地將投資與跨開發團隊的好處進行匹配。
全周期開發者
把所有這些想法湊到一起，我們就得出了這么一個模式，在配備了出色的開發者生產力工具之后，開發團隊將負責整個軟件生命周期：包括設計、開發、測試、部署、運營以及支持。
被賦能的全周期開發者
全周期開發者需要熟悉軟件生命周期各個領域并且高效。對于很多不熟悉Netflix的開發者來說，這意味著要在自己之前不怎么關注的領域加把勁。我們開設有dev新兵訓練營及其他持續培訓形式來灌輸這種知識并培養技能。知識是必要非充分條件；部署管道和監控還需要有易用的工具才能支撐高效的全周期開發運營。
全周期開發者把工程規范應用到生命周期的各個領域。他們從開發者的角度去評估問題，會提出類似“我如何才能自動化該系統運營所需的東西？”以及“什么樣的自服務工具能讓我的伙伴回答他們的問題而不需要我的參與？”優先考慮聚焦系統的辦法而不是聚焦于人的辦法，優先考慮自動化而不是手工，這幫助了我們團隊實現伸縮性。
轉向全周期開發者模式需要理念的轉變。一些開發者認為設計+開發，或者有時候測試才是創造價值的主要手段。這會導致一種反模式，認為運營是分心的事情，更喜歡對運營和支持問題進行短期性質的修補以便能夠回到自己“真正的工作”上去。但是全周期開發者這項“真正的工作”是利用他們的軟件開發知識去解決全生命周期的問題。全周期開發者要像SWE、SDET以及SRE一樣思考和行動。有時候他們要創建軟件去解決商業問題，有時候他們寫相應的測試用例，還有些時候他們會對系統的運營方面進行自動化。
這一模式要想取得成功，團隊必須為它所帶來的價值做奉獻并且要認識到所需的成本。團隊需要預留合理的人手去管理開發和部署，處理生產問題，并且對伙伴的支持請求作出響應。需要投入時間到培訓上。要利用好工具并且投資于工具。需要跟集中化團隊培養合作關系來創建出可重用的組件和解決方案。規劃和回顧階段要考慮到生命周期的各個領域。除了商業項目以外，像自動化告警響應和開發自服務伙伴支持工具這樣的投資需要優先考慮。有了合適的人力、恰當的優先次序，再加上合作關系，團隊就能成功地運營自己開發的東西。沒有這些，團隊就會有負擔過重精疲力竭的風險。
在Netflix之外的地方應用這一模式需要進行必要的調整。開發團隊之間的共同問題可能是類似的——比如持續交付管道的需求，比如監控/可觀察性等等。但很多公司并沒有像Netflix這樣有足夠的人力投資到集中化團隊上，或者也不需要Netflix這種規模導致的復雜性。Netflix的工具往往是開源的，所以一開始你想嘗試一下也正常。不過這些問題其他的開源和SaaS解決方案也能滿足大多數公司的需求。先從分析潛在價值和計算成本開始沒然后再進行觀念轉變。評估你需要什么，小心不要引入不必要的復雜性。
權衡利弊
技術圈有很豐富的手段來解決開放和運營需求（延伸閱讀：devops拓撲）。這里描述的全周期模型在Netflix很普遍，但這種模式也有缺點。在選擇一種模式前先了解其中的利弊可以提高成功的幾率。
在全周期模式下，一個人要管的事情變寬了變多了。而一些開發者偏向于專注成為比較狹窄的領域的世界級專家，在一些領域我們也是需要那種類型的專家的。對于那些專家來說，需要一專多能，對每個領域都懂一些的要求可能會感覺不太舒服而且有時候勉為其難。有些人寧愿呆在需要深厚知識不需要持續擴展廣度的領域，我們也支持他們去虛招這樣的角色；有的則享受并且歡迎承擔更廣的責任。
根據我們開發和運營基于云的系統的經驗，我們見識過哪些重視擁有全周期所需的廣度的開發者的效能。但是這種廣度增加了每一位開發者的認知負荷，這意味著團隊每周將比僅關注一個領域要平衡更多的優先事項。為此我們采取了隨時待命的輪轉來緩解這一點：即讓開發者輪流分擔部署+運營+支持責任。做得不好的情況下，就會出現人人都在當救火隊員去處理生產問題等高中斷的情況，導致所有人精疲力竭。
工具和自動化有助于擴展專業知識，但沒有一項工具能解決開發者生產力和運營領域的每一個問題。Netflix有集中化團隊支撐的現成的一套工具和實踐。我們不強求其他團隊一定要用這些，但是通過確保開發和運營采用這些技術的體驗要比不用好得多來鼓勵他們采用。我們的辦法不好之處在于“每一支團隊將每一項工具的每一個功能用到其最重要的需求”上這個理想幾乎是不可能實現的。需要意識到我們集中化團隊解決方案的投資回報需要努力、協調以及持續適配。
結論
從2012年走到今天經歷了種種實驗、學習和適配的過程。Edge Engineering的早期經歷刺激了尋找更好模式的需求，從此全周期開發者模式就被我們積極地應用到今天。部署是日常，進行得很頻繁，金絲雀行動只需要數小時而不是數日了，開發者可以迅速調研問題作出變更而不是在團隊之間踢皮球。其他的團隊也看到了類似的好處。然而，我們認識到我們是通過應用替代方案并從中學習才走到今天的。我們預期將來的需求還會推動進一步的演進。
原文鏈接：https://medium.com/netflix-techblog/full-cycle-developers-at-netflix-a08c31f83249
責任編輯：張曉寶
相關推薦
美衛星電視公司Dish推流視頻服務挑戰Netflix
北京時間9月3日消息，據國外媒體報道，一名不具名知情人士透露，美國第二大衛星電視公司DishNetworkCorp.(以下簡稱“Dish”)下個月將推出一款流視頻服務，與Netflix競爭。上述知情人士稱，Dish之所以選擇下個月推流視頻服務，原因就在于Netflix提高了其服務的價格。Netflix表示，從本月開始，該公司將對郵寄DVD和流視頻服務分開收費，同時購買兩項服務的價格將提高60%至15.98美元。上述知情人士稱，Dish尚未設定服務的價格。Dish4月份斥資3.2億美元收購了破產的視頻租賃服務Blockbuster的幾乎所有資產。上述知情人士稱，Dish的新服務可能包含Block
Netflix與米高梅簽訂多年期授權協議
北京時間11月7日晚間消息，Netflix和米高梅周一共同宣布，兩家公司已經簽訂多年期授權協議。根據這一協議，Netflix將在英國和愛爾蘭提供米高梅電影的獨家流媒體播放服務。這一協議將于2012年初生效，屆時Netflix將開始在英國和愛爾蘭提供服務。訂購Netflix的服務后，用戶將可以通過電視機、平板電腦、游戲主機、計算機和手機觀看流媒體內容。Netflix尚未宣布在英國和愛爾蘭地區提供服務的價格。將在上映后一年內通過Netflix獨家播放的電影包括《霍比特人：不可思議之旅》、《霍比特人：來來往往》、《動物園看守》和《龍虎少年隊》等。此外，英國和愛爾蘭地區用戶還可以通過Netflix觀看
Netflix創始人買進價值100萬美元Facebook股票
北京時間8月11日消息，據國外媒體報道，周三的一份監管備案文件顯示，Netflix的創始人兼Facebook董事會成員里德-黑斯廷斯（ReedHastings）買入了這家社交網絡公司價值100萬美元的股票，他表示自己對Facebook依然充滿信心。黑斯廷斯按每股21.03美元的價格一共買進了大約47800股。其他投資者并不那么急于買進Facebook的股票。Facebook在五月份上市時的股價為38美元一股，但
Netflix想要徹底顛覆電視：收視率不再重要