熱門消息

Netflix 官方博客:我們的全週期開發者實踐

Google+ Pinterest LinkedIn Tumblr

編者按:對於像Netflix這樣服務上億用戶的軟件服務提供商來說,服務運營是非常複雜的。按照傳統的做法,複雜的事情需要專業的分工,於是整個軟件生命週期會有設計、開發、測試、部署、運營、支持等不同的術業有專攻的團隊和角色進行配合。但是這種做法會增加溝通損耗,導致問題經常被踢皮球。於是Netflix在實驗中實踐出了一套採用DevOps原則的混合模型:全週期開發者模式——誰開發的業務誰來運營,誰出的問題誰負責。同時設立了集中化團隊來支撐不同的DevOps團隊的公共需求。

Netflix 官方博客:我們的全週期開發者實踐

2012年的時候在Netflix運營一項關鍵服務是很費力的。開發感覺就像在溼沙中行走。金絲雀部署變成了對耐心的測試(「一週的金絲雀測試都沒問題發生所以我們繼續推進吧」)而不是正確的功能。研究問題就好像橡皮球一樣在團隊之間被踢來踢去,很難抓住根源,想要阻止大家不再踢皮球更是難上加難。

時間快進到2018年,Netflix已經發展到擁有1.25億的全球會員,每天的瀏覽量超過了140萬小時。我們已經在改進開發運營方面進行了顯著投入。一路走來我們試驗了很多服務開發和運營的方案。在此,我們願意把其中一種我們內部用得相對普遍的方案,包括它的優缺點拿出來跟大家分享。我們希望我們的經驗分享能給大家一點啓發並且討論出可能的替代方案。

一支團隊的旅程

Edge Engineering(邊緣工程)負責AWS服務的第一層,必須爲Netflix的流媒體服務正常工作準備就緒。在過去,Edge Engineering有專注運營的團隊以及SRE(網站可靠性工程師)專家,他們負責軟件生命週期的部署+運營+支撐這部分。發佈新功能意味着開發跟運營團隊要協調指標、告警及容量考慮等東西,然後再把代碼交給運營團隊部署和運營。要想高效運行代碼並支持合作伙伴,運營團隊需要持續接受新功能和修補bug的培訓。擁有一支獨立運營團隊的主要好處是在一切正常的時候對開發者的干擾沒那麼多。

可當情況進展不暢時,成本就會提高。開發和運營/SRE人員之間的溝通和知識轉移是有損耗的,調試問題或者回答夥伴問題需要額外的來回。部署問題因爲運營團隊對部署的變更沒那麼多直接知識,所以檢測和解決需要更多的時間。代碼完成與部署之間的鴻溝變得更大,發佈往往是以周爲量級而不是日。反饋從運營發起,這幫人直接經歷了缺少告警/監控或者性能問題及時延增加這樣的痛苦,然後再傳遞到開發人員這裏時問題已經是二手了。

爲了改善這種情況,Edge Engineering實驗了一種混合模型,就是開發人員可以在需要的時候自己推送代碼,同時負責非高峯期的生產問題和支持請求。這改善了開發者的反饋和學習週期。但這會出現部分的責任不到位的問題。比方說,即便開發者可以自己部署和調試管道破損,他們往往也會交給運營發佈專家處理。對於聚焦運營的人來說,他們對日常工作有積極性,但是很難會把無需別人依賴自己的自動化放在優先考慮的位置。

爲了尋找更好的解決辦法,我們退後一步決定從第一性原理開始。我們究竟想實現什麼?以及爲什麼我們不能成功?

軟件生命週期

軟件生命週期的目的是優化「時間價值」,有效地將想法轉化爲替客戶做出產品和服務。開發和運行軟件服務涉及到一系列的責任:

Netflix 官方博客:我們的全週期開發者實踐

軟件開發生命週期組件

我們一直在細分這些責任。極端情況下,這意味着每一個職能領域都由不同的人/角色負責:

Netflix 官方博客:我們的全週期開發者實踐

軟件開發生命週期專家

這些專門的角色在每一個細分領域內創造出了效能,但是卻有可能造成整個生命週期的低效。專家在其聚焦的領域發展專業知識並針對該領域的需要進行優化。他們在解決特定領域的難題上變得越來越高效。但是軟件需要整個生命週期來爲客戶提供價值。各自精通生命週期的一小塊的專家團隊反而可能會製造出煙囪導致整個端到端流程放緩。將不同的專家組成一個團隊能減少煙囪,但讓不同的人負責各自角色又增加了溝通負擔,引入了瓶頸,並且抑制反饋迴環的效能。

運營你開發的東西

爲了反思我們的做法,我們從開發運營(devops)運動的原則總獲取靈感。我們可以通過打破煙囪並鼓勵分享整個軟件開發週期的所有權來優化學習和反饋:

Netflix 官方博客:我們的全週期開發者實踐

支持devops原則的軟件開發生命週期

「運營你開發的東西」通過讓開發系統的團隊也負責系統的運營和支持來踐行devops原則。把這個責任分攤給每一支開發團隊,而不是外化它,這樣就建立直接反饋迴環並且把激勵給統一起來。感受到運營痛苦的團隊被賦權通過改變系統設計或代碼來治療這種痛苦;他們要負責這兩種職能。每一支開發團隊都要負責部署問題、性能bug、能力規劃、告警差異、夥伴支持等等。

利用開發者工具擴張

對整個開發生命週期的所有權給軟件開發者顯著增加了負擔。這就需要有簡化和自動化共同開發需求的工具來減輕負擔。比方說,如果軟件開發者預期要管理服務的回滾的話,就要有豐富的工具既能檢測到問題並予以告警,又能輔助進行回滾才行。

Netflix建立了集中化團隊(比如Cloud Platform、Performance & Reliability Engineering以及Engineering Tools)來解決每一支開發團隊都會遇到的問題,其使命是開發公共工具和基礎設施。這些集中化團隊將自己的專業知識變成了可重用的建構塊,充當了力量倍增器的作用。比方說:

Netflix 官方博客:我們的全週期開發者實踐

專家創建可重用的工具

有了這些工具在手,開發團隊就可以專注地解決自身特定產品領域的問題。當額外的工具需求產生時,集中化團隊會評估多個開發團隊是否也有這些需求。如果有,接着就要協作。有時候這些局部需求太過特殊而無法獲得集中化的投入。在這種情況下開發團隊就要決定其需求是否重要到需要自己解決。

對類似問題在局部與集中投資間進行平衡是我們的方案當中最棘手的地方。按照我們的經驗尋找開發需求的新穎解決方案的好處,是值得冒險讓多支團隊同時開發在將來殊途同歸的解決方案的。溝通與協調是成功的關鍵。通過協調好需求及其共性,我們就能更好地將投資與跨開發團隊的好處進行匹配。

全週期開發者

把所有這些想法湊到一起,我們就得出了這麼一個模式,在配備了出色的開發者生產力工具之後,開發團隊將負責整個軟件生命週期:包括設計、開發、測試、部署、運營以及支持。

Netflix 官方博客:我們的全週期開發者實踐

被賦能的全週期開發者

全週期開發者需要熟悉軟件生命週期各個領域並且高效。對於很多不熟悉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

編譯組出品。編輯:郝鵬程。

TechRoomage 為收集網路上各大新聞網站最新資訊,提供新聞的聚合類網站,本站不擁有這些文章之著作權,若有違反您的權益,歡迎來信 [email protected],我們將盡速幫您移除疑似侵權文章。

Write A Comment