大數據文摘出品
編譯：朱一輝、塗世文、Aileen
你也常常遇到這個令人頭疼的事嗎？每次產品出現問題，開發團隊和運行維護團隊就開始互相踢皮球，很難直接定位問題所在。全週期開發模式是一條看起來艱難，但是值得去探索的道路。
本文來自付費視頻網站Netflix的開發者博客，介紹了Netflix如何從軟件生命週期開始思考，優化服務的開發和運營流程。2018年，Netflix已經發展成為擁有1.25億全球用戶，每天超過1.4億小時的瀏覽時長的流媒體巨頭。希望他們踩過的坑能對你有所啟發。
整個團隊的心路歷程
Edge Engineering團隊負責支撐Netflix流媒體業務的AWS服務的第一層。在過去，Edge Engineering擁有專注於運維的團隊和SRE（網站可靠性工程師）專家，他們負責軟件生命週期中的“部署+運營+支持”部分。新功能的發佈意味著開發人員需要與運營團隊協調處理諸如各項指標、注意事項和性能等事宜，然後將代碼交付運維團隊部署和維護。
為了代碼的高效運行並配合開發部門同事的工作，運維團隊需要就新增的功能和已修復的bug持續進行培訓。擁有獨立運營團隊的主要好處是，在事情進展順利的情況下，開發人員可以專注於的開發而不被運維方面的事情所打斷。
但是當事情進展不順利時，各種成本就會增加。開發人員與運維人員之間的溝通和信息傳遞是失真的，需要他們進行進行額外的多輪溝通來調試Bug或解答同事的疑問。
由於運營團隊對正在部署的服務的更改沒有直接的瞭解，因此部署問題需要更長的檢測時間和解決時間。代碼完成和部署上線之間的時間間隔比如今要長得多，新功能的發佈需要幾周而不是幾天。
直接的反饋來自運營人員，他們直接經歷了諸如警告/監控或性能問題以及延遲增加等痛苦，而開發人員聽到的都是二手消息，不利於直接定位和解決問題。
為了改進這一點，Edge Engineering團隊嘗試了一種混合模式，在這種模式下，開發人員可以在需要時自行推送代碼，還負責解決非工作時間的生產問題和支持請求。這種模式縮短了開發人員的“反饋-學習”週期。但是，只承擔部分責任會留下了缺口。
例如，即使開發人員可以自行部署和調試通道破損，他們通常也會推遲到運營發佈專家那裡。對於以運維為中心的人員，他們有動力去做日常工作，但是很難優先考慮自動化，因為自動化一旦實現，其他人則不再不需要依賴他們。
為了尋找到更好的方法，我們退後一步，決定從最基礎的原則入手。我們試圖完成什麼？為什麼我們還沒成功？
軟件生命週期
軟件生命週期的目的是優化“從時間到價值”這一過程；有效地將創意轉化為對客戶具有針對性的實用產品和服務。開發和運行軟件服務涉及到一整套責任體系：
設計 開發 測試 部署 運營 支持
軟件開發生命週期（SDLC）組成部分
在過去，我們一直在細分這些責任。理想情況下，每個功能區域都由不同的人/角色負責：
設計 開發 測試 部署 運營 支持
架構師 開發人員 測試人員 發佈工程師 系統管理員 客戶支持
軟件開發生命週期（SDLC）專家
這些專業角色可以在每個環節中有著高效的工作水平，但這樣同時可能使整個生命週期的效率低下。專家在重點領域發展專業知識，並優化該領域的需求。他們能更高效地解決對應領域的難題。
但軟件需要整個生命週期為客戶提供價值。各自擁有生命週期一部分的專家團隊會造成孤島效應，從而減緩端到端的進程。將不同的專家組合成一個團隊可以打破孤島效應，但是由於不同的人擔任每個角色會增加溝通開銷，引入瓶頸並抑制反饋閉環的效果。
親自運維你構建的內容
為了重新思考我們的方法，我們從“開發-運維”（DevOps）行動原則中獲得靈感。我們可以通過打破孤島效應並鼓勵整個軟件生命週期所有權的共享，來優化“學習-反饋”循環：
用開發運營（DevOps）原則處理SDLC
“運維你構建的內容”是指通過讓開發系統的團隊也負責該系統的運維和後期支持工作，將DevOps原則付諸行動。將這一責任分配給每個開發團隊，而不是外包給其他團隊，從而創建直接反饋閉環並協調激勵。
感覺運維痛苦的團隊更有動力通過改變系統設計或代碼來消除痛苦；他們對這兩項職能負責並具有解釋權。每個開發團隊都擁有部署問題、性能Bug、性能規劃、警告缺口、夥伴支持等權利。
藉助開發者工具進行規模化
完整軟件開發生命週期的所有權極大地增加了軟件開發人員預想的工作量。將那些可以簡化和自動化開發的共同需求做成工具，有助於減輕一部分負擔。例如，如果軟件開發人員需要管理其服務的代碼回滾，那麼需要豐富的工具，既可以檢測並警告問題，也可以幫助回滾。
Netflix創建了集中式團隊（例如雲平臺，性能和可靠性工程，工程工具），其任務是開發通用工具和基礎設施，以解決每個開發團隊都有的問題。這些集中式團隊通過將他們的專業知識轉化為可重複使用的塊，增強生產力。例如：
構建工具 部署管道 評測和警告 洞察分析工具
專家創建可重複利用的工具
有了這些工具，開發團隊可以專注於解決其特定產品領域內的問題。隨著更多的工具需求的出現，集中式團隊會評估多個開發團隊的需求是否共有。如果是，那麼合作就開始了。有時候這些局部需求太過特定，就不能保證集中團隊會處理。在這種情況下，開發團隊決定他們的需求是否足夠重要，以便他們自己解決。
在類似問題上局部平衡與集中處理，是我們方法中最棘手的問題之一。根據我們的經驗，尋找針對開發人員需求的新穎解決方案的價值，值得讓多個團隊冒險去創建並行解決方案，這些方案需要在未來能夠融合。溝通和協調是成功的關鍵。通過一開始就良好協調需求和它們可能的普遍程度，我們可以更好地使全體Netflix開發團隊的投入與收益相匹配。
Netflix常用工具和架構可參考
https://netflix.github.io/
全週期開發者
通過將所有這些想法結合在一起，我們創造了一個模型，在此模型中，開發團隊裝備著令人驚歎的開發者生產力工具，負責整個軟件生命週期：設計、開發、測試、部署、運行和支持。
火力全開的全週期開發者
全週期開發人員需要對軟件生命週期的所有領域都熟悉且高效完成。對於許多新到Netflix的開發人員來說，這意味著要加深他們之前並不關注的領域的瞭解。
我們舉辦開發訓練營和其他形式的不間斷培訓，以傳授這些知識並增強他們的技能。知識是必要的，但還不足夠；用於部署通道（例如Spinnaker）和監控（例如Atlas）的易於使用的工具，對於有效的全週期所有權也是需要的。
Spinnaker：
https://www.spinnaker.io/
Atlas：
https://github.com/Netflix/atlas/wiki
全週期開發者將工程原則應用於軟件生命週期的所有領域。
他們從開發者的角度評估問題，並提出諸如“我如何使的運營維護此係統所需的操作自動執行？”和“什麼自助服務工具能夠幫助我的合作伙伴解答他們的問題，而不需要我參與？”這有助於我們的團隊，通過傾向於以系統為導向而不是以人為導向的思維和自動化，而非人工方法，來形成規模效應。
轉向全週期開發人員模式需要轉變思維。有些開發人員將設計+開發，以及測試，視為創造價值的主要方式。這導致產生了相悖的模式，將運營視為干擾，傾向於修復短期運營和支持問題，以便他們能夠回到“真正的工作”。
但全週期開發人員的“真正的工作”，是利用他們的軟件開發專業知識來解決整個生命週期中的問題。一個全週期開發者的想法和行為要像SWE、SDET和SRE一樣。有時，他們創建解決業務問題的軟件，有時他們會為此編寫測試用例，有時還會將系統的運維工作自動化。
要使這個模式成功執行，團隊必須致力於發現其帶來的價值，並認識到成本。
團隊需要配備足夠的人員來管理構建和部署工作，處理生產問題並響應同伴的支持請求。需要花時間培訓。需要利用和投入工具。需要通過集中式團隊培養同伴關係，以創建可重用的組件和解決方案。在規劃和回顧過程中，需要考慮生命週期的所有領域。像自動化警告響應和構建自助式協同支持工具等投入，需要與業務項目一起按照優先順序排列。
通過適當的人員配備，分配優先次序和協作關係，團隊就可以成功運維他們所建立項目到內容。如果沒有這些，團隊就會有超負荷和倦怠的風險。
要在Netflix之外應用此模型，有必要進行適當修改。在你的開發團隊中，常見問題可能類似於對持續傳遞通道、監控/可觀察性等方面的需求。
但許多公司沒有足夠人員投入，來組建像Netflix一樣的集中式團隊，或者沒有達到Netflix規模所需的複雜性。Netflix的工具通常是開源的，將它們作為第一次嘗試，可能會引起大家的興趣。
但是，針對這些問題的其他工具和SaaS解決方案可以滿足大多數公司的需求。首先分析潛在價值並計算所需成本，然後進行思維轉換。評估你需要什麼，並注意要用最不復雜的必要工具。
權衡利弊
科技行業有多種方法來解決開發和運維需求。這裡描述的全週期模型在Netflix中很常見，但也有其不足之處。在選擇模型之前瞭解利弊，可以增加成功的幾率。
採用全週期模式，在這些更廣泛的領域中，通過工具，優先考慮有更大的所有權和有效性領域。廣度需要在不同的技術領域有興趣和能力。一些開發人員更願意專注於一個狹小領域而成為世界級專家，我們的行業在某些領域需要這些類型的專家。
對於那些專家來說，讓他們廣泛瞭解很多領域，並對每個領域有適當深入的理解，可能會使他們感受到不適，有時甚至覺得無法取得滿足感。Netflix的有些人更喜歡在需要研究深厚專業知識，而不需要持續的廣度的領域，我們支持他們找到自己的角色定位；而對於其他人則自由享有並鼓勵承擔更多的責任。
在我們構建和運行基於雲的系統的經驗中，我們已經看到了那些擁有全週期所需廣度的開發者所產生的效果。但是這個廣度增加了每個開發者的認知負擔，這意味著團隊每週需要平衡的優先事項，比他們專注於一個領域的要多。
我們通過“調用輪轉”的方式來減輕負擔，開發者輪流處理“部署+運維+支持”責任。如果做得好，就為其他人做專注的、流程性的工作，創造了空間。如果做得不好，團隊會進入每個人都投入到如產品問題的高中斷工作狀態中，這會導致整個團隊精疲力竭。
工具化和自動化有助於擴展專業技能，但沒有任何工具能夠解決開發者生產力和運維空間的每個問題。Netflix有一套,由集中式團隊支持的“鋪好的道路”般現成的工具和方法。
我們不強制要求採用這些現成的工具和方法，而是通過確保使用這些技術進行開發和運維工作有更好的成效，來鼓勵團隊採用它們。我們方法的缺點是，“每一個團隊使用每個工具中的每個功能來滿足他們最重要的需求”這個理想幾乎不可能實現。為了實現我們集中式團隊解決方案的投資回報，需要付出努力、保持一致性以及進行不斷調整。
閱讀更多 大數據文摘 的文章
