本文要點
- 對於團隊來說，想要持久地服務客戶不僅需要不斷改進工具，更需要文化和流程的變革。
- 我們可以設定一些服務級別目標，通過它們衡量客戶體驗，並在嚴重影響客戶的事故發生時獲得警報。這樣一來就能減少來自客戶的抱怨。
- 團隊可以在收集數據、追蹤事件、整理資料的過程中調試並理解他們的複雜系統。
- 要允許團隊自由、集體地討論風險，才能提升工作效率。
- 團隊可以通過定量風險分析來確定修復工作的優先級，從而更順暢地提供服務。
[網站可靠性工程（SRE）]和開發團隊需要直面問題，找出需要排除的隱患。SRE的一部分工作是在不斷變化的業務需求背景下幫助維持卓越的生產力。——Sheerin等，網站可靠性手冊
生產所有權意味着開發組件或服務的團隊需要隨時待命，這是確保軟件質量和縮短開發反饋流程的最佳實踐。如果能用好所有權這種方法，它可以爲工程師帶來動力和自主性，滿足我們掌控全局、做出優秀成果的渴望，併爲用戶提供更好的體驗。
但在實踐中，團隊經常沒有經過適當的培訓，也沒有足夠的福利保障，卻仍然需要隨叫隨到。沒有準備就突然增加團隊的責任負擔會降低服務的可靠性，使團隊士氣低落，並促使成員互相推卸責任。團隊成員還往往缺乏關鍵技能來處理新的難題，難以跟上局勢變化，也沒時間去學習並補足自身的缺陷。一個問題在於，團隊的責任加重了，得到的權力卻沒有跟上。雖然人們本能地會想到花錢解決問題，但購買更多工具並不能填補我們團隊的能力或結構的空白。工具只能幫助我們自動化現有工作流程，卻不能教我們學習新技能或調整流程來解決現有問題。
爲了掌握生產所有權方法的主動權，團隊需要發展運行生產系統所需的技能，併爲此制定一套路線規劃。我們需要的不僅是生產所有權，我們還需要卓越的生產力。卓越生產是一套需要學習的技能組合，團隊學會這套技能後就能自信地適應不斷變化的環境。它帶來的不僅僅是工具的變化，更是成員、文化和流程的變革。
運維工作事不關己是不行的
有些開發團隊會把他們的運維工作外包出去，沒有采用生產所有權方法，結果與運維越來越走不到一條線上。這些團隊只追求更快開發出新的功能，也不管運維是不是接受。運維工作需要的人力干預越來越多，團隊人手愈加緊缺。而負責運維的團隊本來應該保持系統運行並擴展系統能力，可現在卻要分出精力、深夜加班、拖着疲倦的身軀去收拾各種殘局。如果一項服務需要耗盡運維它的所有人員的精力，那麼它肯定不能長時間正常運作。
如果開發和運維團隊中間隔着一道高牆，那麼兩邊都會喪失宏觀層面的必要視角。產品上線前需要手動測試，配置需要人工調整，故障需要手動排查，而且多個團隊之間的摩擦讓複雜的故障需要更長時間才能解決。團隊最終要麼應付大量手動、繁瑣、容易出錯的操作，要麼發展出錯誤的自動化流程，反而加劇了風險——例如，出現生產故障後他們只是簡單地重新啓動，而不檢查爲什麼它會停下來。這種不斷重複的故障/修復循環，或者說苦力活，會隨着服務的規模擴大而帶來更大的負擔，白白浪費團隊的血汗與淚水。對於使用專用SRE團隊的組織以及更傳統的使用系統管理員團隊的組織來說，運維團隊很容易就會疲於奔命。
隨着時間的推移，運維挑戰也將拖累產品開發工作，因爲開發和運維之間的知識與工具互不相通，意味着各個團隊難以理解並修復生產中的故障，甚至不知道哪些故障優先級更高。生產所有權方法是很有意義的：它能消除反饋循環，讓開發團隊感受到自己的決策給運維帶來的痛苦，並在團隊中引入運維技能，而不是對運維工作不管不問。
僅僅讓所有人隨時待命是不行的
只讓開發團隊隨叫隨到還不夠，需要提前做一些準備工作才能讓他們發揮作用。幾十年前開始，IT企業將開發和運維的工作切割開來，希望通過專業化來提高效率。現代化的流程又想將這兩種功能強行合併在一起來提升敏捷度，但這個目標可不是一夜就能實現的。現在，組合而來的DevOps團隊需要做的運維任務所需的技能和直覺，通常與開發團隊的習慣截然不同。團隊可能會面對大量的警報和人工干預工作，讓人更感到運維工作沒什麼價值可言。想要減少警報數量、減少人工干預需要融匯運用開發和運維技能，因此許多開發人員拒絕在團隊中引入生產所有權方法。
市場上有許多工具聲稱自己能降低DevOps或生產所有權的負面影響，結果只是把水攪得更渾濁，給系統帶來了更多噪音而已。必須有一個系統方案來教育所有參與生產的團隊成員，否則所有不常見的問題最後都得推給團隊中少數幾位專家來解決。就算這些專家更希望分享信息而非壟斷信息，他們的工作也總會被打斷，當然也沒時間寫出完整的文檔。如果持續集成和交付指標只關注軟件的發佈速率，忽視軟件的質量，那麼它就是一個陷阱。
如果團隊無法理解系統在生產環境下爲何失敗，那麼檢測和修復故障事件的耗時將會很漫長。爲了提升團隊部署軟件時的信心，團隊必須確保軟件部署到生產環境時不會崩潰。否則，在https://cloudplatformonline.com/rs/248-TPC-286/images/DORA-State of DevOps.pdf">更改失敗率較高的環境中，團隊辛苦工作的成果會在高負載情況下反覆回滾，難以升級。雖說把運維工作的壓力分擔到團隊所有成員身上會更加公平，但真正要減輕運維負擔只能設法減少突發故障、打破故障/修復的惡性循環。
專業的系統工程自有其價值，需要花時間學習，以前這項技能常常被輕視了。產品開發人員需要有一套很好的框架來制定流程或修復錯誤，以儘可能減少噪聲。就算團隊有時間處理苦力活和其他形式的運維債，也需要提前做好規劃。可以把苦力活比作是技術債務在運維側支付的利息；只還利息並不會減少未償還的本金。相比沒有權力的運維團隊來說，生產所有權是更好的戰略，但生產中痛苦的程度還是一樣的。混合團隊肯定會更公平地分擔生產中痛苦的壓力，但更好的方案是減輕痛苦的程度。當我們償還技術和運維債務時，客戶和開發團隊都會受益。
更好的方法：卓越生產
所謂卓越生產，不是試圖通過工具或強制團隊合併來解決生產所有權問題，而是一種以人爲本的全新方法。
卓越生產是一套技能和實踐，能使團隊對生產的所有權充滿信心。卓越生產技能往往出自SRE團隊或負責SRE職務的個體，但這並不是專屬於他們的領域。消除生產所有權的反饋循環意味着我們要將這些技能傳授給我們團隊中的所有成員。在生產所有權體系下，運維是所有人共同的責任，而不是“別人的問題”。每位團隊成員都需要在運維和卓越生產領域具備基本認識，即使這不是他們的主要工作。當團隊成員培養這些技能時需要得到支持和獎勵。
爲了讓團隊及其支撐的服務長期正常運作，有四大關鍵因素需要考慮。首先，團隊必須就哪些事件能提高用戶滿意度的問題達成一致，並忽略其他無關問題引發的警報。其次，他們必須提高他們探索生產健康度的能力，要從用戶出現痛苦的跡象開始探索，而非從潛在成因入手。第三，他們必須確保彼此合作並分享知識，進而還能培訓新的成員。最後，他們需要一個框架來確定哪些風險需要補救，以保證系統足夠可靠，持續滿足客戶需求。
1. 衡量重要的事情
想要減輕運維工作的壓力，首先要從減少噪音和加強警報與真實的用戶問題之間的相關性入手。服務級別目標（SLO）是SRE實踐的基石，它能用來創建一個反饋循環，以保障系統正常運行，持續滿足用戶的期望。SLO的核心思想是將失敗看作是正常的事情，我們需要定義一個可接受的失敗級別，不要爲了追求完美而浪費開發的靈活性。正如Charity Majors所說，“你的系統一直處於一種部分不足的狀態。現在，有很多很多東西做錯了甚至壞掉了，而且你還不知道。” 我們不用讓每個系統中所有出現小故障的噪聲都發出警報，而是要在宏觀層面上應對影響用戶滿意度的故障模式。
因此，我們需要通過用戶每次與我們的系統交互時獲得的體驗質量來量化每位用戶的期望。然後我們要從總體上衡量所有用戶的滿意度。我們可以測量延遲和錯誤率，記錄放棄率等因素，並通過用戶訪談等直接反饋來着手製定這種服務水平指標（SLI）。
理想情況下，我們的產品經理和客戶成就團隊能得知用戶最關心哪些工作流程，還有大致上多大的延遲或錯誤率閾值會讓客戶呼叫支持熱線。將這些指標轉換爲機器可識別的閾值後（例如，“如果交互在300毫秒內完成，搭配HTTP 200代碼，結果就很好”或“如果數據在過去24小時內更新過，則此數據記錄就夠新” ），就可以分析整個系統的實時和歷史性能。例如，我們可以爲我們的系統設定一個目標，即每三個月內符合條件的活動有99.9％是成功的：意味着每段時期內每1000個事件有1個錯誤預算。
設置好性能目標並在一段時期內爲預期錯誤建立預算後，就能調整系統，使其忽略小的可以自我解決的波動，並只在系統顯著超過標記邊界時發送警報了。只有在實時錯誤率上升到將在接下來的幾個小時內讓錯誤超出預算時，系統纔會尋求人工干預。我們可以嘗試調整我們的工程優先級，看看是否能獲得更大的容忍度和更快的響應速度，或者當我們超出了可接受的故障水平時可以重新回來關注可靠性指標。如果團隊長期超出錯誤預算，用戶抱怨不停，那麼團隊可能需要優先考慮修復基礎架構，而不是開發新功能。
團隊需要有一套成文共識，在SLO出現問題時共同解決問題，這樣就爲可靠性工作提供了系統層面的支持。一個合理平衡的SLO應該讓用戶在遇到罕見錯誤時從容淡定，稍後重試就能繼續工作，而不是讓用戶面對持續斷線的服務不得不打給支持服務，乃至取消已有的交易。
隨着用戶期望的變化，以及速度和可靠性之間的平衡出現新的選擇，SLO可能會發生變化。但以用戶爲本的SLO無論多麼粗糙，都比陷在一大堆跟用戶沒什麼關係的指標裏要強得多。
3. 可觀察的調試工作
消除了較低級別的警報後，如果系統發現我們的服務不符合SLO指標該怎麼辦？我們需要調試並深入瞭解流量中的哪些子集正在經歷或導致問題。發現問題後我們要制定解決方案，然後付諸實踐並驗證一切是否恢復正常。
調試的能力與可觀察性這個概念密切相關；可觀察性指的是我們的系統要有足夠的遙測能力，使我們能夠在不干擾系統或修改其代碼的前提下監測其內部狀態。在充分了解我們的系統及其性能的前提下，我們希望通過假設檢驗來解釋並解決用戶遭遇問題的結果差異。現在需要500毫秒的請求改進到250毫秒後會有什麼效果？我們能否識別和解決拖慢一部分請求的性能問題來改善體驗？
僅僅測量和收集所有數據是不夠的。我們必須以新的方式檢查數據及其上下文，並用它來診斷問題。我們需要可觀察性，因爲我們不能只根據事先想到的指標來測量系統。複雜系統故障通常來源於衆多因素的新組合，而非一系列不變的成因。正因如此，我們經常無法在較小規模的臨時環境中重現生產故障，無法提前預測故障。
不管我們採用何種可觀察性方法，都一定要搞清楚請求流經我們分佈式系統的具體路徑。請求遍歷微服務的每處足跡都是我們必須監控的潛在故障點。可以採用帶有元數據的寬事件、分佈式跟蹤、指標或日誌的方法。每種方法都在工具支持、數據粒度、靈活性和上下文方面做了某種取捨。我們經常需要多組可以很好地協同工作的工具，以獲得所需的全套功能。如果我們無法將線索鎖定到用戶流程失敗的特定實例上，最熟練的問題專家也將一籌莫展。
如果遙測系統具備足夠的靈活性和保真度，我們就不需要爲了分析服務的行爲而讓它一直斷線。我們可以儘快恢復對用戶的服務，相信我們以後可以重現問題並調試。這樣我們就能自動化快速處理一大類故障，例如斷開損壞的區域或回退錯誤的更新，並在正常工作期間調查出錯的位置。當人們不需要完全調試並實時解決所有故障時，系統的運維能力就會隨之提升。
4. 協作和建設技能
就算有一套完善的SLO和觀測工具，也不一定能形成可持續的系統。調試和運行系統都需要人力參與。沒有人天生就知道如何調試，所以工程師都或多或少要學習相關知識。隨着系統和技術不斷髮展，所有人都需要不斷學習新的見解。
重點在於制定培訓計劃、編寫關於常見診斷出發點的最新文檔，並經常回顧之前的工作，但回顧時不能把之前的錯誤歸咎於某個人頭上。服務所有權並不等於自私和孤島，它意味着逐漸在團隊間分享專業知識。最重要的是，團隊必須營造一種心理上感到安全的氛圍，使團隊成員和外部人員可以直截了當指出問題。這使個體能夠更深刻地理解問題，並通過新的視角來解決問題。
跨團隊互動不僅侷限於上下游關係，還涉及諸如如客戶支持、產品開發和SRE等部門。如果客戶支持工程師一報出虛警就被人指責，他們就不太敢上報問題了，進而影響問題的檢測和解決。
在學習過程中有一點是非常需要重視的，那就是每個人都在生產環境中有自己擅長和負責的部分。然而，許多生產所有權的方法都是毫無彈性的教條主義，讓所有開發人員7x24候命。開發人員不願參與壓力過大且打亂自己生活節奏的流程。可他們又害怕如果不參與這些流程的話，就會被指責推卸責任甚至丟了工作，結果團隊就只能被趕鴨子上架，團隊精神蕩然無存。
生產所有權需要由所有類型的工程師共同分擔，少數幾種特定類型的工程師是不夠的。參與生產不見得就是簡單粗暴地隨時待命，而可以有許多不同的形式：例如讓難以隨時待命的成員負責後勤支持，或者讓晚上需要照顧家人的成員僅在工作時間待命。還有可能是讓一位虔誠的猶太人不用在安息日候命，或者在一位經理跑業務時不去打擾他。團隊可以共同協作，根據各個成員的背景和需求公平分擔生產所有權的壓力。
5. 風險分析
卓越生產的最後一個要素是預測和解決給我們系統的性能帶來風險的結構性問題。我們可以在危機發生之前識別潛在故障的性能瓶頸和類別。積極主動的策略就是在發現潛在故障點後知道怎樣用軟依賴替換硬依賴以避免故障。同樣，我們應該主動優化關鍵路徑，不應該等到用戶抱怨系統太慢時才動手。我們仍然需要一部分錯誤預算來處理新的系統故障，但同時必須努力解決系統中的已知風險。
訣竅在於確定哪些風險是最關鍵的，然後就解決它們。在20世紀60年代，美國阿波羅登月計劃整理了已知風險清單，並努力確保這些風險積累起來仍然處於計劃的安全參數範圍內。在現代，Google SRE團隊發展出了檢查風險和排序風險優先級的方法。他們創造了一個定量風險分析框架，通過風險的檢測/修復時間、影響的嚴重程度及其頻率或可能性的積分來做評估。
我們可能無法控制所有事件的發生頻率，但我們可以縮短響應時間、減輕負面效應，或減少受影響的用戶數量。例如，我們可以使用canary部署或功能標記來減少不良更改對用戶的影響，並在必要時快速回退到舊版本。一項改進是否成功取決於它是否減少了一般用戶的糟糕體驗。canary部署策略可能會減少與部署相關的服務中斷時間，從每月一次兩小時的中斷，影響100％的用戶（平均每位用戶每月兩小時），減到每月一次半小時的中斷，隻影響5％的用戶（平均每位用戶每月1.5分鐘）。
我們需要迅速解決那些消耗大量錯誤預算的風險，因爲它們可能會導致系統的災難性故障，並讓我們的錯誤預算嚴重超支。如果我們的錯誤預算處於超支狀態，可以把其他大批較小的風險推到以後再處理。通過定量分析充分利用錯誤預算的話，所有風險都會被解決掉；有了定量分析就更容易區分先後，並在開發新功能之前先解決已有的風險。
然而，針對特定風險條件的風險分析往往無法找到所有風險具備的共性。缺乏衡量標準、缺乏可觀察性和缺乏協作（卓越生產的其他三個關鍵方面）是幾大系統性風險，它們會讓故障時間更久，更難預知，從而加劇了其他風險的影響。
生產支持不一定是痛苦的工作
成功的生產所有權和DevOps長期方法需要以卓越生產的形式變革組織文化。如果團隊具有明確的可靠性測量手段和調試新問題的能力，擁有促進知識傳播的文化以及主動降低風險的方法，那麼團隊就更有更好的持久作戰能力。雖然工具可以用來幫助系統更加可靠，但文化和人才纔是最重要的投資。
如果沒有成熟的可觀察性和協作實踐，系統將在技術債務的重壓下崩潰，人員和資金投入再多也無濟於事。工程團隊的領導者必須負責創建可持續服務用戶需求和健康業務的團隊結構和技術系統。生產所有權和卓越生產的結構能夠幫助現代開發團隊取得成功。我們不能指望失去能力的運維團隊能夠自動獲得成功。
作者介紹
Liz Fong-Jones是一名開發人員支持者、勞工和道德組織管理者，還是一位擁有超過15年經驗的網站可靠性工程師。她是Honeycomb.io的SRE和可觀察性社區的推動者；她的SRE工作經歷包括Google Cloud Load Balancer到Google Flights等產品。
原文鏈接：
Sustainable Operations in Complex Systems with Production Excellence