工作視覺化：讓你的價值被看見
當我們的工作成為「看不見的工作」時，其價值往往被低估。例如，那些防止問題發生的工作、提升系統可靠性的改進、消除技術債務的努力，都容易被忽視，因為它們的結果是「什麼都沒發生」。
成就紀錄檔案正是使這些「看不見的工作」變得可見的工具。它幫助你：
- 將隱形的技術貢獻轉化為可見的業務價值
- 記錄那些「避免了問題」的工
分享心智模型：開發有效系統抽象的藝術
在複雜系統的世界裡，抽象化是我們理解與溝通的基本工具。當一個心智模型能被記錄、複製並分享時，它就成為一個通用抽象，極大加速了團隊溝通並提供標準工具，幫助人們推理系統行為、故障和變更。即使這些抽象不是百分之百準確，當團隊大部分成員分享同一系統心智模型時，系統的行為最終會隨著時間演變以比對這個模型。
標準化系統理解的共同語言
在我過去帶領網路團隊的經驗中，發現採用標準化圖表對快速理解系統架構極為有效。我們沿用了網路工程師的慣例，繪製不同層級的圖表（物理層、資料連結層、網路層、路由層和安全策略層），甚至為各種裝置採用了事實上的標準圖示。
這種標準化帶來的好處顯而易見：
標準基礎設施圖表 → 服務特定變體 → 快速定位與理解
我們的標準實體基礎設施圖表完整版包含九對裝置；根據需要的詳細程度，它可以簡化為五對裝置或五個單一邏輯裝置。團隊中的每個人都能從記憶中繪製出這些圖表。
接著，我們為每個服務建立了這些標準圖表的變體，並疊加特定細節。當我因為不熟悉的服務被呼叫時，能夠迅速定位並理解該服務的結構。每當我加入一個新團隊，我總會尋找他們的圖表來幫助理解系統抽象。如果沒有人能教我有意義的抽象，我就畫出現有的內容，並嘗試使用這些圖表找出能輔助理解的抽象和模型。
建立有效抽象的實用方法
那麼，如何著手建立有效的系統抽象呢？我的做法通常是：
- 如果我從一些簡單抽象開始，就為每個抽象建立一個圖表
- 如果我從圖表開始，思考哪些圖表提供了有用的心智模型
- 如果我一無所有，就畫出現有的內容，尋找模式和結構
記住，目標不必是100%的準確性。優先考慮人：圖表和抽象應該容易記憶、實用，並能隨時間保持最新。畢竟，使用這些圖表的是人，無論是作為參考（如前面的服務圖表）還是學習。
玄貓為你解密：
心智模型與系統抽象的核心價值在於降低認知負荷。當我們面對複雜系統時，大腦無法同時處理所有細節，因此需要抽象化來簡化理解過程。標準化圖表的威力在於它創造了團隊分享的「技術語言」，讓團隊成員能快速達成共識，減少溝通成本。這些圖表不僅是工具，更是團隊知識傳承的媒介，特別是在新人加入或處理緊急情況時，能大幅縮短學習曲線。
解構On-Call分歧：尋找共同解決方案
關於誰應該負責on-call職責的爭論，一直是技術職業生涯中的核心痛點。這些爭論都有其合理性和邏輯性。然而，儘管所有觀點都有理，參與這場辯論仍然充滿爭議。
當每個人都有機會分享自己的觀點和個人故事後，最終常達成的妥協是「視情況而定」。誰應該為數位服務執行on-call取決於眾多因素，這些因素不僅在不同行業間獨特，在企業和組織內的團隊間也各不相同。on-call存在無數種形式，因為需要on-call的情境也是無限的。
超越「視情況而定」的思考
但問題是：「視情況而定」這種表態並沒有真正解決或終結辯論，也沒有觸及爭論持續存在的核心原因。當你深入分析人們對這個話題強烈情感和意見背後的理由時，你必須問：為什麼我們覺得有必要繼續提出誰應該on-call的問題？這解決了什麼問題？
無論你在DevOps的雙模式世界觀中站在哪一邊，系統的設計、建構和營運方式都有很大差異，但大多數人在兩個重要點上達成共識：on-call角色是必要的，而與大多數人寧願不做這項工作。
承認經驗，縮小分歧
我們都因為on-call留下了傷疤，但要結束辯論，首先必須承認和認可我們個人的on-call經驗。我們每個人的經驗都是有效的，與確實是關於on-call體驗的重要機構知識的一部分。
我的經驗，你的經驗，都代表了一個比任何日誌或指標更高保真度的圖景和理解——如果你的目標是以解決真正困擾我們的方式改進on-call角色。發生了什麼的個人現實以及人類影響的品質是我們想要改進的。
實施工具來幫助我們最小化業務影響很容易。董事會和股東會很高興。但我們是否做了任何事情來改進未來我們自己和後來者的on-call體驗？
探索認知體驗：解決真正的問題
這才是需要解決的問題，它始於提供時間和空間來分享和傾聽，探索在回應問題之前、期間和之後在認知上發生的事情。不幸的是，這些資料不會出現在我們通常在事後分析中最關注的文字、系統日誌或時間序列資料中。
到目前為止，我們還沒有找到一種有意義的方式來承認和探索人們經歷的心理挑戰，以及他們的認知推理、判斷和決策機制。
然而，要解決on-call的分歧，我們需要開始探索我們之間的差距。on-call的體驗是怎樣的？詢問發生了什麼，希望理解為什麼，以便我們能夠預防，這僅是一個更深層問題的表面療法；傷疤下隱藏著更多東西。
如果我們能夠看穿表面，我們會發現只要多一點時間和努力，on-call的煩惱就能被最小化，分歧也能縮小，只需創造空間和安全感來揭示on-call期間發生的更完整圖景。
玄貓為你解密：
on-call分歧的核心在於經驗認同與負擔分配的不平衡。許多技術團隊將on-call視為必要之惡，但很少探討這種制度對工程師心理健康和工作滿意度的影響。當玄貓處理過大型服務中斷時，發現團隊成員的心理負擔往往比技術挑戰更難解決。
解決方案不在於爭論「誰應該on-call」，而是改善on-call體驗本身：建立清晰的升級路徑、提供足夠的檔案和工具、確保合理的輪值頻率、建立心理安全的環境讓人們能夠討論壓力和挑戰。最終，on-call不應該是一種懲罰，而是團隊共同承擔的責任，以確保我們構建的系統能夠可靠執行。
事件應變的指揮藝術
我們都經歷過：第一次擔任事件管理員（有些組織稱為事件指揮官）的經歷。我的第一次IMOC（Incident Manager On-Call）通知在入職一年後到來，儘管之前我做了許多觀察，但我的處理方式與前人的表現相比相形見絀。這不是我最後一次失誤，但我開始建立一個高層次的事件管理框架。隨著之後的每次失誤，我都為框架增添新內容。這個框架作為起點一直很有價值，希望對你也有所幫助。
有更多更好的資料專門擴充套件如何管理事件，但以下是我始終放在首位的主要原則。
優先止血：專注於緩解問題
將注意力始終集中在優先緩解問題上。雖然對話可能會漂移到深入的根本原因調查和長期解決方案的討論，但第一反應該是讓持續的對話僅專注於還原當前情況。
當面對系統故障時，技術團隊常有深入分析根本原因的本能。然而，作為事件指揮官，你的首要任務是將團隊引導回「止血」這個最優先目標。這需要堅定但不失尊重的引導能力。
持續跟進：掌握全域進展
定期（注意這可能對正在解決問題的人造成的成本）繼續提出每個人在做什麼的問題。這裡的目標是跟蹤努力進展，防止重疊工作，並獲得相關參與者的健康狀況檢查。
提出這個問題也給你機會問另一個問題——你需要任何幫助嗎？——來評估是否應該利用更多資源。
# 事件管理的簡化範例流程
def manage_incident(team, systems_affected):
# 1. 首先確認影響範圍
impact = assess_impact(systems_affected)
# 2. 分配初步任務
tasks = assign_initial_tasks(team, impact)
# 3. 進入管理迴圈
while incident_active():
# 定期檢查每個人的工作
current_status = check_team_progress(team)
# 評估是否需要額外資源
if needs_more_resources(current_status):
add_team_members()
# 確認是否已經緩解問題
if is_mitigated(systems_affected):
break
# 保持溝通節奏
communicate_status_update()
# 短暫等待，避免過度幹擾團隊
wait(5_minutes)
# 4. 問題緩解後的後續步驟
schedule_postmortem()
document_incident()
玄貓為你解密：
這個Python範例展示了事件管理的核心迴圈。關鍵在於check_team_progress()函式，它代表定期檢查團隊進展的重要性。這不僅是為了掌握資訊，更是為了確保團隊資源分配合理，避免重複工作或遺漏關鍵系統。
在實際情況中，這個迴圈通常會在Slack、Teams或專門的事件管理平台上執行，頻率取決於事件的嚴重性。對於嚴重事件，可能每5-10分鐘檢查一次；對於較低影響的事件，每15-30分鐘一次較為合理。
速度優先於完美：決策的藝術
當你進行事件管理過程時，可能不清楚何時該進入下一步。也許如果多花五分鐘收集更多資料點，你就能更確定哪些系統受到影響。在這種情況下，始終在做決策時最佳化速度而非品質，牢記大局目標：快速還原系統。
到這時，你可能會意識到，處理事件應變很大程度上歸結為建立肌肉記憶和神經通路，這些來自重複經驗，但這並不意味著你不能為輪值做準備。
事件應變的準備清單
以下是一個初始準備清單：
- 組織的關鍵指標是什麼？在電子商務組織中，這可能是結帳率和交易量、店面可用性等
- 你的服務依賴什麼？哪些服務依賴你？
- 誰是相關的工作者？如何聯絡他們？
- 在高壓下如何保持冷靜？你有什麼個人策略？
- 如何有效地進行狀態溝通？誰需要被通知？
玄貓為你解密：
準備清單不僅是技術準備，更包含心理準備。在事件處理過
從混亂到掌控：建立高效事故管理流程
第一次帶領事故處理的經歷總是令人難忘。無論你事先準備得多麼充分，當凌晨四點的警示把你從夢中驚醒，面對一系列閃爍的紅色指標和焦急等待的團隊成員，那種手足無措的感覺恐怕是無法避免的。
我仍清晰記得我的第一次事故處理經歷，發生在多倫多的凌晨四點。那次表現堪稱事故管理的「車諾比」—在前輩們曾經優雅指揮的位置上，我卻像個笨拙的業餘指揮家。
事實上，事故處理很大程度上取決於透過反覆實踐建立的肌肉記憶和神經通路。隨著經驗積累，我的失誤逐漸減少，最終能夠讓整個「樂團」和諧地演奏起來。
無縫事故管理的核心要素
事故管理流程中，人是最重要的因素之一，這一點對SRE參與的事故尤為明顯。若管理不當，一個事故可能陷入兩種極端：太多平行衝突的工作流程（團隊成員互相踩踏）或協作不足（個人單打獨鬥嘗試解決問題）。
接下來，我將分享幾個實作無縫事故管理的關鍵步驟：
明確事故長官者角色
所有事故處理的第一步是指定一名事故長官者，並確保所有參與者都清楚知道誰是當前的長官者。這個人負責協調參與事故處理的所有成員的角色和責任，並分配任務。
值得注意的是，事故長官者不一定要是最熟悉受影響系統的人，而可以是能夠將合適的人員組織在一起的協調者。事故長官者的角色也可以在處理過程中轉換—一旦另一個人獲得了所有必要的連貫的背景與環境，他們可以接管長官角色。
在玄貓參與的多次大型事故處理中，我發現明確的長官角色可以將混亂的回應時間縮短50%以上。一個典型的例子是，當一個跨越多個微服務的事故爆發時，若沒有明確的長官者，各個團隊往往各自為戰，導致解決方案相互衝突。
建立專用溝通通路
為每個事故設立專用的溝通通路（在你的聊天軟體中）是非常有效的做法。專用通路打破了現有的孤島，如組織團隊結構和溝通邊界，轉而形成一個新的分享目標：所有人一起解決當前事故。
作為額外好處，專用通路可以作為事故展開的線性時間軸。這在事後編寫事故報告時極為有用。
清晰描述發現
所有參與者都需要花時間清晰地描述他們的發現，避免模糊不清。雖然花時間闡述發現似乎與繼續調查實際事故相悖，但它可以提供一組隱含的額外驗證。
例如，分享命令輸出結果或提供其他人可能不熟悉的系統檔案。在我主導的一次資料函式庫事件中，一位工程師簡單分享了查詢計劃的截圖，這立即幫助團隊識別出了索引失效的問題，大縮短了診斷時間。
及時記錄後續行動
在事故過程中，你可能會發現一些非預期的問題（如損壞的儀錶板或過時的操作手冊）。在事故期間記錄後續行動，而不是等到結束時，這樣可以避免遺忘。事故結束後，事故長官者可以評估提議的行動列表，並為決定保留的行動分配負責人。
利用自動化減輕負擔
事故回應是一系列緊急行動的集合，而自動化可以幫助減少開銷。以Monzo為例，他們構建了一個名為Response的工具，幫助減輕個人在事故期間的壓力和認知負擔，並以統一的方式引導每個人完成事故管理流程。
Response提供了一個逐步流程，用於記錄事故並指定長官者、啟動專用通訊通路、升級到另一個團隊以及記錄行動，所有這些都無需離開Slack（Monzo首選的聊天軟體）。
Monzo團隊花了大量時間使Response的使用者經驗盡可能無摩擦。所有事故在建立時都會被Response自動記錄在專用Slack頻道中。每個事故都會顯示標題、嚴重性、事故長官者和Slack頻道。
建立正確的文化態度
然而，圍繞事故建立工具和流程並不是全部。參與事故處理的人員需要有文化安全感，能夠有效溝通而不受幹擾、評判或對其能力的偏見。
事故及其回顧應該避免指責或歸咎。擁有效的事故管理流程需要同時具備正確的工具和正確的文化態度，專注於解決當前事故。
正確執行時，事故可以成為強大的教訓，幫助每個人瞭解系統如何協同工作，建立與同事之間的信任和同理心，並展示整個組織的敏捷性和協作性。
高效Runbook的藝術
Runbook（也稱為playbook）並非萬靈藥，但在事故後，一個常見的行動專案是「更新Runbook/新增缺失的Runbook」。那麼，我們為什麼堅持使用它們呢？
Runbook的侷限性
Runbook通常關注已知的未知事物，但我們無法預測每個問題。它們與所有檔案分享相同的缺陷：準確性、品質、可維護性、偏差。它們在時間緊迫、壓力大的情況下被依賴。
有時，它們可能是可靠性問題的脆弱補丁：團隊過度投資於Runbook，而不是投資於修復底層問題，這創造了新的繁重工作來源。它們有時被視為培訓和經驗的直接替代品，導致較新或經驗較少的團隊成員被安排處理他們尚未理解的系統的待命工作，僅因為「Runbook存在」。
不準確或過時的Runbook有時比沒有Runbook更危險。但這並不意味著我反對使用Runbook—恰相反。瞭解缺點意味著我們可以努力減輕或修復它們，並更好地受益於優點。
如何做好Runbook
Runbook的建立、維護和審查應該是整個團隊的活動。認識到Runbook是知識分發問題（而非技術問題）的解決方案，可以促進其編寫，尤其是以協作方式進行時。
Runbook捕捉了知道如何修復問題的團隊成員的思考過程和決策。對該團隊成員的一些可能問題是：你用什麼來確定是否有問題？你會使用哪些工具？什麼因素影響你的決策過程？有哪些行動危險或有風險？這個過程中哪些部分曾經絆倒過你，你建議特別小心處理？
定期作為團隊審查Runbook也允許這些知識被審查和質疑，尤其是在系統演變時。玄貓曾經在一家金融科技公司工作時，每季度組織一次「Runbook演練日」，讓團隊成員在非緊急情況下實際執行Runbook，這幫助我們發現了許多過時的步驟和缺失的資訊。
視Runbook為技術債務
Runbook是技術債務。它們通常是系統技術債務和繁重工作的唯一有用檔案。（積壓在待辦事項底部的卡片不算。）
當審查現有Runbook時，團隊應該質疑它為什麼存在以及是否可以消除它。按照這個邏輯，擁有太多Runbook是一種反模式。將Runbook視為跨系統協調（以人類作為控制器）也可能有助於瞭解什麼可以輕鬆自動化，什麼不能，或者是否缺少控制系統。
定期測試Runbook
第一次閱讀或執行Runbook的最糟糕時間是在半夜，在事故期間。想滅火器或煙霧報警器：它們需要定期測試，以確保在緊急情況下需要時能正常工作。這包括檢查連結和程式碼片段是否確實有效。
保留Runbook上次使用或測試的記錄，並執行過時的Runbook，也提供了一個機會來持續評估該Runbook是否仍然需要。
接受Runbook的侷限性
Runbook不能也不會解決每個事故。但這沒關係；隨著系統複雜性增加、團隊成熟和事故變得更加新穎，Runbook的投資回報會開始遞減。
短期內，這可能意味著Runbook焦點的演變，或者是朝向有用資源和診斷技術的指引，或者是朝向更加極簡的方法：隔離/終止/迴圈出現問題的元件。
無縫事故管理的實踐之道
綜合以上經驗，玄貓建議實施以下策略來改善事故管理：
建立事故分級制度
根據影響範圍和嚴重性建立明確的事故分級制度，每個級別對應不同的回應流程和資源調動。例如：
- P0：全域服務中斷，需要立即全員回應
- P1：主要功能受影響，需要相關團隊緊急回應
- P2：次要功能受影響，需要負責團隊在工作時間內處理
- P3：邊緣案例問題，可排入常規工作
設計事故演練
定期進行模擬事故演練，讓團隊在低壓力環境中練習協作和使用工具。這不僅能提高團隊應對真實事故的能力，還能識別流程中的弱點。
建立知識函式庫孤立的Runbook
不要只建立獨立的Runbook，而是建立一個連線的知識函式庫括系統架構圖、常見故障模式、診斷工具和最佳實踐。這種整體方法比孤立的步驟列表更有效。
事故管理不必是負擔。如果正確執行，事故可以成為強大的學習機會，幫助每個人瞭解系統如何協同工作，培養同事之間的信任和同理心，並展示整個組織的敏捷性和協作性。
透過明確的角色定義、有效的溝通通路、適當的自動化工具和正確的文化態度，我們可以將事故管理從混亂的緊急應對轉變為結構化的解決問題過程。而精心設計和維護的Runbook則是這個過程中的重要工具，它不只是步驟列表，而是團隊知識和經驗的結晶。
經過多年的事故管理經驗，玄貓認為真正的無縫事故管理不在於完全避免錯誤，而在於建立一個能夠快速識別、有效應對並從中學習的系統。當我們將事故視為改進的機會而非失敗的標誌時，我們就能建立一個真正彈性的技術組織。
維運手冊的雙面性：工具與文化的平衡
維運手冊（Runbooks/Playbooks）是每個SRE團隊的基礎工具，然而，僅擁有這些檔案遠不夠。經過多年在不同規模團隊的實踐，玄貓發現建立健康的維運文化才是真正的制勝法寶。一個根據知識分享、協作、能力提升和預先準備的文化，其價值往往超越維運手冊本身。
維運手冊的真正價值不僅在於解決問題的速度，更在於它如何促進團隊成員之間的知識傳遞。當我們將維運手冊視為知識管理系統而非僅是緊急情況的時，其效益會成倍增加。
為何我厭惡某些維運手冊
在SRE領域中，維運手冊（Playbooks或Runbooks）是幫助值班工程師解決問題的檔案集合。不過，我經常看到許多手冊存在相同的反模式，這些問題嚴重影響了它們的實用性。
過度詳細的困境
第一個常見問題是內容過於詳盡，這不僅使檔案難以維護，還會造成檔案臃腫，進而使尋找特定資訊變得複雜。這種情況通常源於對遺漏任何細節的恐懼。典型例子包括在值班責任轉移期間編寫的手冊，或由值班人員持續記錄的日誌式檔案。
想要一本覆寫所有情況的完美維運手冊是不切實際的。重要的是要將手冊視為一種工具，而非SRE角色的完整替代品。團隊入職培訓中涵蓋的內容是一個有用的基準，可以省略一些被視為基本知識的細節。用連結替代詳細步驟（如何定位某個作業）也很有幫助，這樣可以加快資訊搜尋速度，而無需記住大量瑣碎的事實。
檔案空洞的危險
相反的情況是內容過少。出於善意的檔案要求，但缺乏花時間使其有用的動機，會導致空白範本。內容過少實際上比看到沒有檔案存在浪費更多時間，因此提交時需要一定程度的可用性。在最好的情況下，空檔案沒有用處；在最壞的情況下，它會導致忽視維運手冊的模式（即使它們已更新），因為值班人員已經認定它們沒有價值。
工作者盲點
聽起來可能違反直覺，但維運手冊不應由該主題的工作者撰寫。對系統非常熟悉的人往往難以識別只有他們知道的背景和細微差別，所以他們更適合作為資訊來源和審核者。
玄貓曾經在一個專案中嘗試讓系統工作者撰寫維運手冊，結果發現這些手冊對新人幾乎沒有幫助。後來改為讓新加入團隊的成員撰寫初稿，再由工作者審核，手冊的實用性立刻提高了好幾倍。
過度規範的陷阱
最後一個反模式是過度規範。任何能描述確切步驟來解決特定情況的維運手冊都應該是自動化指令碼。警示意味著系統無法自我修復，因為自動化在完全列舉的重複性任務方面比人類快得多與更好。我們將問題升級給人類是為了複雜的回應，而非快速回應。
如果值班人員被訓練成按照指令碼行事，那麼面對新的事件時會變得非常困難。重要的是要認識到維運手冊有一個生命週期：
┌->1 識別問題
| 2 除錯
| 3 新增警示
| 4 編寫檔案
|┌>5 自動化解決方案
|└-6 更新檔案
└--7 面對不同的問題
我們經常在第4步停滯不前。過度規範的維運手冊不應該被視為應該刪除的失敗品，而是自動化和迭代的機會。
優質維運手冊的核心要素
理想情況下，一個維運手冊應該只包含：
- 為什麼我需要關注？ 嚴重性和對使用者可見影響的限定。
- 我可以檢視什麼？ 控制檯、日誌和檢查工具。
- 我可以做什麼？ 緩解工具。
- 我可以向誰升級？ 開發人員、後端團隊或專門的事件回應團隊。
優秀的維運手冊本質上反映了我們追求的SRE文化。它們依賴於提供正確的激勵，不僅是記錄，還包括自動化和創新。識別和專注於團隊目標有助於提煉有用的資訊，以應對使我們的工作有趣的不確定性，同時避免單調乏味。
機器擅長的工作：自動化的正確方法
構建自動化的一種常見方法是讓人類執行手動流程，記錄下來，然後建立一個指令碼來複製人類的工作流程。這看起來合理，但問題在哪裡？這種方法沒有考慮哪些步驟需要只有人類才能做出的決定，也沒有認識到電腦可能在某些方面做得更好。
瞭解人類和機器各自擅長什麼對於構建良好的自動化至關重要。
自動化複雜流程的關鍵
要自動化複雜流程，我們需要評估哪些方面需要人類的解釋和反應。這通常意味著尋找可能失敗的地方。如果某個命令執行或服務呼叫回傳錯誤，我們應該考慮人類當時會做什麼，並將其與機器可能做的進行比較。我們能在程式碼中複製相同的決策過程嗎？如果可以，我們就應該這樣做。如果不行，我們可以讓自動化失敗並提醒人類來做出正確的決定。對於真正複雜和成本高昂的決策，有時保留人類在流程中是有意義的。
另一個選擇是重新設計這一步驟，使其不需要人類。自動化工程可能需要重新審視系統的設計和介面，因為有些設計原則使機器更容易做出決策和行動。如果被自動化的系統不遵循這些原則，自動化可能會變得脆弱——而脆弱的自動化需要人類監督。
冪等性的重要性
冪等性是一種操作的屬性，它允許操作被重複而不產生副作用，這是自動化的關鍵。如果某事失敗或未能及時回傳成功，自動化可以重試而不會造成後果。這是一個允許自動化具有彈性的設計原則。當可能時，我們應該偏向於使被自動化呼叫的命令和服務具有冪等性。
錯誤報告的一致性
系統的另一個允許更好自動化的屬性是一致與編碼化的錯誤報告。如果人類必須進行深入故障排除或解釋字元串以瞭解失敗時發生了什麼，自動化將失敗並需要人類干預。自動化還應避免依賴解析或比對描述性字元串，因為如果這些字元串改變或新增了類別似的字元串，就會造成風險。
考慮系統擴充套件性
被自動化的系統需要具備擴充套件能力。為人類互動構建的工具和API可能無法跟上機器執行的速度。底層系統可能需要進行負載測試和改進，以滿足自動化的需求。
自動化的組合性
自動化通常由其他自動化組成。我們應該預期我們的自動化有一天會成為更大系統的一部分。這意味著我們構建的自動化應具備相同的上述屬性。我們應該使自動化具有冪等性，使其使用一致與編碼化的錯誤報告，並確保它可以擴充套件。我們還應該有測試和檔案，以及對其進行監控，就像系統的其他部分一樣。
我們越是使自動化像我們開發的任何其他軟體一樣——意味著精心設計、測試、監控和記錄——它就越成為我們可以安全依賴的東西。
將同理心整合到SRE工具中
站點可靠性工程包括諸如構建自我修復服務、實施自動系統以及監控值班輪班的品質和數量等最佳實踐。然而，我們很少有為站點可靠性工程師提供的工具來促進從操作疲勞中自我修復、緩解與事件相關的壓力以及追蹤值班輪換。
富有同情心的同理心可以幫助我們透過作用於使倦怠更可能發生的元素來達到這個目標。將富有同情心的同理心融入軟體需要理解（有時是收集）那些經常處於SRE壓力中心的元素，並編碼相關的解決方案。
人性化工具的價值
在我多年的SRE工作中，發現團隊的倦怠往往不是因為技術挑戰本身，而是因為缺乏支援系統。最好的SRE團隊不僅關注系統的可靠性，還關注團隊成員的健康狀態。
玄貓曾經設計了一個值班管理系統，不僅追蹤輪值時間，還監控每位工程師處理的事件數量和複雜度。系統會自動識別負擔過重的模式，並建議調整輪值安排，這大減少了團隊的倦怠情況。
整契約理心的實踐方法
將同理心整合到SRE工具中的幾種方法包括：
人工智慧警示管理 - 不僅追蹤警示數量，還要分析警示模式和每個工程師的負擔，避免警示疲勞。
值班負載平衡 - 自動追蹤和平衡團隊成員之間的值班負擔，考慮事件複雜度而非僅是數量。
復原時間保障 - 在處理重大事件後，確保工程師獲得足夠的還原時間，避免連續高壓工作。
知識可存取性 - 確保關鍵資訊在需要時容易取得，減少搜尋檔案的壓力，特別是在危機時刻。
維運手冊的演進：從檔案到自動化
維運手冊不應該是靜態檔案，而應該是不斷演進的工具。隨著系統的成熟，許多原本需要人工干預的問題應該逐漸被自動化解決。
從手動到自動：維運手冊的生命週期
維運手冊的理想生命週期如下：
問題識別與檔案 - 當新問題出現時，團隊記錄問題特徵和解決步驟。
手動解決階段 - 初期，問題透過手動執行維運手冊中的步驟來解決。
自動化發展 - 隨著對問題理解的加深，團隊開始將手動步驟轉化為自動化指令碼。
完全自動化 - 最終，問題被完全自動化處理，無需人工干預。
維運手冊轉型 - 原維運手冊轉變為系統行為的說明檔案，而非故障處理。
玄貓在一個大型雲端服務提供商工作時，發現團隊的維運手冊有80%都停留在第二階段。透過建立明確的自動化激勵機制，六個月內我們將50%的手動流程轉變為自動化解決方案，大幅減少了值班負擔。
維運手冊自動化的關鍵考量
將維運手冊轉變為自動化時，需要考慮以下因素：
決策點識別 - 清晰標識哪些步驟需要人類判斷，哪些可以自動化。
部分自動化 - 不必一次性完全自動化
將同理心融入SRE實踐中
在SRE的工作中，我們不僅需要關注系統的可靠性，還需要關注維護這些系統的人員的健康狀態。以下幾個步驟能幫助我們將同理心融入SRE工作流程中：
- 理解問題根源
- 尋找合適的指標（SLI）
- 設定可接受的範圍（SLO）
- 制定相應的後果（SLA）
- 實施工具來追蹤SLI、檢查SLO並執行SLA
實際案例分析
讓我們透過一個例子來說明這些步驟。Shuri是SuperSonicSystems的一名SRE，一年前她的團隊進行了重組，包括他們的待命輪值安排。這導致她不得不請假休養。讓我們應用上述方法來確保其他SRE團隊成員不會遇到同樣的問題。
為了理解問題根源，公司向Shuri傳送了一份調查問卷。結果顯示，她待命的頻率增加，並且遇到了大量警示，使她難以還原精力。這是因為原本由九人處理的待命輪值減少到只有三人。雖然系統由管理者進行了分配，但從事件回應資料來看，Shuri的輪值時間恰好與公司的發布週期重合，因此她比其他人更頻繁地待命並接收更多的呼叫。此外，公司的待命政策沒有提供還原日。
待命輪值的數量和品質是主要問題。組織關注的三個指標是：
- 待命頻率（有多少人以及他們多久待命一次？）
- 每次輪值的警示數（SRE每次輪值收到多少警示？）
- SRE幸福度（SRE在待命輪值後的幸福水平如何？）
根據這些SLI，SuperSonicSystems設定了一些SLO：
待命輪值： 假設每週輪值一次並設定主要/次要角色，輪值中應有至少八人。
每次輪值的警示數： 每次輪值最多10個警示，夜間警示的權重加倍。未來，更高嚴重性的警示也可能具有更高的權重。
SRE幸福度： 每次待命後向SRE傳送使用表情符號評級的調查，目標是平均達到☺。這與前面的SLO不同，它是定性而非定量的。
這個步驟需要反覆試驗，直到達到舒適的平衡。
最後一步是設定後果，即SLA：
待命輪值： 如果不遵守上限，團隊應增加待命輪值的人員數量，使其可持續。在過渡階段，更頻繁待命的人員將獲得兩天強制性連續還原時間，以防止精疲力竭。
每次輪值的警示數： 如果達到最大警示數，呼叫器將由團隊中的其他人接管，以允許適當的還原時間。
SRE幸福度： 低於平均評級的調查將促使跟進並可能採取相關行動。例如，正在經歷生活困難的SRE可能會暫時從輪值中撤出。這些情況應由團隊負責人個別分析。
SRE必須支援公司最關鍵的系統，但使這個角色既刺激又具有挑戰性的元素也使他們面臨精疲力竭、健康問題和不滿的風險。這個例子展示瞭如何將同理心融入待命政策，以建立更強大、更有彈性的團隊。
使用ChatOps實作同理心
這個新增到我們ChatOps事件回應提醒序列中的內容一開始聽起來很簡單，但不久之後我就觀察到它對待命的SRE有多大影響。這個兩句話的提示讓可用的指揮官立即伸出援手並提供幫助——這個舉動似乎重新激發了待命指揮官的活力。
就在那時，我意識到ChatOps不僅能自動化並提供一個簡單的介面來管理事件回應和基礎設施，還有能力使我們的工作更具可持續性。
由於工作性質，SRE團隊經常超負荷工作。對系統的關注程度太高，以至於背後的SRE被遺忘。處理過多的繁瑣工作、夜班以及不斷成為抵禦服務中斷的第一道防線，這些都會對SRE產生影響，進而影響他們負責的系統。我之前討論過實施同理心的重要性及其如何減輕負擔，但考慮到團隊的資源和時間限制，如何最好地實施它呢？
我們可以求助於SRE工具箱中值得信賴的工具：自動化。在完成為同理心工作建立邊界、限制和預算的艱難工作後，使用ChatOps是確保它們能夠實施的好方法，而無需不斷觀察。ChatOps是關於對話驅動的營運，它使用群組聊天工具，透過聊天工具本身提供的連貫的背景與環境和採取的行動，超越了基本對話。這有助於建立同理心並自動化防止精疲力竭和疲勞的行動。
上面的例子展示了這是如何工作的：透過追蹤事件開始後的經過時間，並向指揮官的Slack頻道傳送自動提醒。因此，它自動促使其他指揮官作出反應，而這些指揮官本來可能不知道情況。
同樣，ChatOps可以作為待命數量和品質的保障。聊天機器人與第三方服務（PagerDuty、Datadog等）之間的通訊通常透過webhooks完成。透過實施待命排程命令，聊天機器人可以驗證所需排程相對於設定的黃金標準的可持續性。
例如，一位嘗試將排程改為只有三名工程師（而最低要求是八名）的新經理可能會看到機器人拒絕他們的請求，並督促他們遵循最佳實踐。對於追蹤待命品質，聊天機器人可以在每次輪值後自動傳送調查，並幫助追蹤團隊士氣。它還可以提示在遇到特別壓力大的待命情況後的SRE休息一下。
透過追蹤事件的數量和嚴重性，聊天機器人可以讓SRE知道他們有一天待命還原日或在輪值的剩餘時間內休息。透過使用提取排程資料和警示的工具來追蹤待命的數量和品質，ChatOps確保了團隊中的負載平衡，這對防止精疲力竭至關重要。它不僅有助於支援SRE，還可以為管理階層提供有用的資料，以便及早發現問題並修復盲點。
這裡提供的例子證明瞭ChatOps可以用來透過利用自動化的力量來維持一個健康的團隊。它減少了原本用於手動追蹤元素的時間，並提高了對設定預算的遵守度。
快速行動修復問題
作為SRE，我們將工作視為平衡速度與可靠性。我們知道佈署到生產環境的每一個變更，無論是程式碼還是設定，都有可能導致服務中斷或其他服務降級的風險。當服務中斷發生時，我們的即時反應是更加謹慎，減慢生產變更的速度。
然後，問題仍然發生。儘管我們做出努力，仍然有服務中斷。我們的直覺是錯的。正是因為我們放慢了速度，事情現在更可能出錯。當一架飛機在空中失速時，自然反應可能是向上拉，遠離地面。但正確的答案是將飛機的機頭向下指並增加引擎功率。這會產生升力。有時正確的做法與我們的直覺相反。
你的開發組織就像一個水龍頭。它以某種恆定的速率產生變更（無論是功能、錯誤還是架構工作）。另外，這些變更可以流入生產環境的速率是由你的佈署節奏、品質保證流程的速度、任何批准要求等決定的。
當你放慢節奏時會發生什麼，無論是明確地透過凍結或隱含地透過增加審查、人工檢查或變更批准流程？
玄貓為你解密：
這段內容探討了SRE工作中的一個關鍵矛盾：當系統出現問題時，我們的本能反應是減緩變更速度，但這實際上可能適得其反。就像飛機失速時需要向下俯衝而非向上拉昇一樣，系統問題有時需要更快速的反應和更頻繁的佈署，而非更慢的變更節奏。
這裡引入了一個重要概念：開發組織像水龍頭，以穩定速率產生變更，但這些變更流入生產環境的速率受佈署節奏、QA流程和審批流程影響。當我們人為減慢這個流入速率時，可能會導致更多問題，因為變更積累會增加每次佈署的風險和複雜性。
這種思維模式挑戰了傳統的"系統出問題就減慢佈署"的做法，提出了一個更靈活、更具彈性的方法，強調在某些情況下，加速而非減速才是正確的應對策略。
持續佈署：系統穩定性的意外盟友
隨著系統規模擴大和架構複雜度增加，我們常會陷入一個矛盾：一方面希望系統保持高穩定性，另一方面又需要不斷推出新功能和修復問題。這種情況下，許多團隊直覺的反應是減緩佈署節奏，將變更累積起來一次性佈署。然而，這種做法實際上可能適得其反。
當我們的測試環境與生產環境差異越來越大，每個批次佈署中累積的更多變更，都會增加出錯的機率。這種情況下，我們需要重新思考佈署策略和問題處理方式。
批次佈署的隱藏風險
批次佈署最大的問題在於，當系統出現故障時，回復操作會一併復原所有變更，包括重要的功能和修復。想像這樣一個場景：你的團隊剛完成了一次包含20個變更的佈署，其中包括5個重要功能、10個bug修復和5個效能最佳化。佈署後發現其中一個變更導致系統不穩定，此時你面臨兩個選擇：
- 回復整個佈署，包括那些使用者迫切需要的功能和修復
- 保留佈署，並嘗試修復問題
如果選擇修復問題，新的修復還需要經過完整的測試、審核和控制流程，延長了問題的解決時間。這種情況下，直覺的反應反而會延長系統故障時間。
持續佈署：減少累積風險的策略
持續佈署的核心思想是：準備好就佈署，然後信任它。具體來說，我們可以透過以下方式實作：
- 建立強大與快速的持續交付流程
- 逐步提高佈署頻率：從每週到每天，從每天到每小時
- 縮小每次佈署的變更範圍，降低累積風險
當開發團隊產生變更的速度與佈署到生產環境的速度比對時，你對系統的認知模型與實際系統之間的差距會縮小，使問題更容易被發現和修復。
在生產環境中測試：必要的冒險還是明智之舉？
談到「在生產環境中測試」這個概念，常會引起兩種截然不同的反應：熱烈的支援或震驚的反對。這種分歧反映了工程領域中一個有趣的悖論：我們常將生產環境視為脆弱的紙牌屋，需要小心翼地接近，同時又夢想著擁有可觀察的系統和無需隨時待命的平靜夜晚。
打破完美主義的迷思
我們需要面對一個現實：認為絕對不能有bug進入生產環境的觀念是一個迷思。將已發布的程式碼視為一種「實驗」並不意味著它未完成或粗糙，而是承認在真實環境中進行迭代是軟體開發的自然一部分。
缺乏良好的工具常是阻礙我們在生產環境測試的原因。最勇敢的組織會嘗試自行構建工具，但對於大多數團隊來說，這通常意味著在功能開發之間的有限時間內拼湊一些Bash指令碼，或者更糟糕的是，將其視為「維運問題」。
然而，生產環境測試並非全有或全無的方法，而是一系列小改進的總和，這些改進可以從根本上改變開發者的體驗：
- 功能標誌（Feature Flagging）：允許在不更改程式碼的情況下修改系統行為
- 安全存取生產資料的工具：例如Rails的console，可以從命令列與應用程式互動
- 重構和遷移工具：支援在新舊程式碼路徑平行執行，比較結果和效能
- 可觀察性工具：依靠事件和分散式追蹤，而不是傳統的固定指標
將生產程式碼視為實驗
嘗試將初始生產程式碼視為一種實驗，就像測試煎餅鍋溫度的第一個煎餅，你總是可以為下一個調整。這種思維轉變讓我們透過觀察和得出結論，更好地理解系統的工作方式以及變更在真實環境中的影響。
小批次迭代佈署可以增加早期發現嚴重邊緣情況的可能性，並快速緩解問題，使生產環境不再那麼可怕和終極。生產環境轉變為創造力和信任的途徑，提供對系統和剛完成變更的必要信心。
有時修復本身就是問題
在處理系統故障時，我們常關注於新增修復措施，而不是移除元件和程式碼。當我們應該減少錯誤表面積並增加操作者的理解度時，我們反而傾向於新增驗證、完整性檢查、流量轉移和同步機制——所有這些都增加了複雜性。
重新思考事件回顧的焦點
事件回顧是消除有害複雜性的絕佳機會。這種複雜性可能是增加錯誤表面積的程式碼，也可能是使系統難以理解並導致事件回應變慢的因素。如果我們能夠證明它導致了事件，並且對可靠性或業務功能不是必要的，那麼它應該被視為有害複雜性並被移除。
事件給了我們放大視角發現有害複雜性的空間。如果一個錯誤導致事件，我們可以問自己：系統的哪些方面使得測試困難或難以發現錯誤？也許它隱藏在一些平行程式碼中。透過進一步放大視角，我們可以質疑由並發程式碼提供的功能是否必要。
同樣，要分析緩慢的事件回應，我們可以問是否有關於系統的某些方面混淆或誤導了操作者。也許很難判斷設定何時動態更新。現在是詢問這種複雜性提供的功能是否必要的時候了。例如，設定能否在不犧牲功能的情況下變成靜態的？
在面臨故障時的策略轉變
當系統仍然出現故障，而你的直覺告訴你要放慢速度時，考慮放慢功能開發工作的速度，而不是放慢佈署速度。將工程努力轉向改善系統可觀察性或更快的測試。構建更好的工具來快速緩解故障：回復自動化、容錯移轉工具等。投資那些長期拖延的架構改進。同時，認識到即使這些變更也應該增量式與頻繁地佈署到生產環境。
可靠性的關鍵是能夠快速改進系統。任何減慢變更的因素也會減慢你實作這一目標的能力。
從複雜到簡單：系統可靠性的新視角
從前面的討論中，我們可以歸納出一個重要的原則：系統越簡單，故障率越低，還原速度越快。然而在實踐中，我們常透過增加複雜度來「修復」問題，而不是透過簡化系統來預防問題。
識別有害複雜度
在評估系統複雜度時，我建議從以下幾個方面入手：
- 程式碼分析：識別高度複雜的模組，特別是那些經常出現問題的部分
- 依賴關係梳理：繪製系統依賴圖，找出可能簡化的環節
- 操作流程檢查：評估系統維護和故障處理的步驟，尋找可簡化的環節
程式碼複雜度評估範例
# 複雜的實作方式
def process_data(data, config=None):
if not config:
config = get_default_config()
processed = []
for item in data:
if item.get('status') == 'active':
if config.get('transform_enabled'):
item = transform_item(item, config.get('transform_options', {}))
if config.get('validate'):
if validate_item(item):
processed.append(item)
else:
processed.append(item)
return processed
# 簡化後的實作
def process_data(data, config=None):
config = config or get_default_config()
return [
transform_item(item, config) for item in data
if item.get('status') == 'active' and
(not config.get('validate') or validate_item(item))
]
玄貓為你解密：
上面的程式碼展示瞭如何將複雜的實作簡化。原始版本使用了多層巢狀的條件判斷，使程式碼難以追蹤和理解。簡化後的版本使用列表推導式和邏輯運算元，減少了程式碼行數並提高了可讀性。關鍵在於保持功能不變的情況下減少複雜度，這樣不僅減少了潛在的錯誤表面積，也使程式碼更容易維護和測試。
簡化策略的實施
實施簡化策略時，我發現以下方法特別有效：
- 漸進式重構：不要嘗試一次性重構整個系統，而是逐步簡化各個元件
- 功能審查：定期審查系統功能，移除不再使用或價值低的功能
- 架構整合：合併功能相似的服務，減少系統間的通訊和依賴
- 標準化：採用標準模式和工具，避免為相似問題建立多種解決方案
建立健康的系統改進迴圈
要建立一個健康的系統改進迴圈，我們需要結合前面討論的所有要素：頻繁佈署、生產環境測試和複雜度管理。
改進迴圈的關鍵要素
- 快速反饋：透過頻繁佈署和生產環境測試取得快速反饋
- 增量變更：小批次變更降低風險，使問題更容易隔離和修復
- 簡化優先：在新增新功能或修復之前，先考慮是否可以透過簡化系統解決問題
- 可觀察性：投資於監控和日誌系統，使系統行為更透明
實施步驟
要實施這種改進迴圈，我建議從以下步驟開始：
- 建立基準：測量當前的佈署頻率、故障率和還原時間
- 逐步增加佈署頻率：從每週一次逐步增加到每天多次
- 改進測試自動化：確保自動化測試覆寫關鍵功能和邊緣情況
- 實施功能標誌：使用功能標誌控制新功能的發布和回復
- 定期審查複雜度：建立定期審查系統複雜度的機制
案例分析：從批次佈署到持續佈署的轉變
我曾參與一個從批次佈署轉向持續佈署的團隊，這個轉變過程提供了寶貴的經驗。
初始狀態
- 每兩週一次大型佈署
- 平均每次佈署包含50-60個變更
- 佈署後問題頻發，通常需要1-2天解決
- 開發者對佈署感到恐懼，常推遲提交變更
轉變過程
第一階段：增加佈署頻率
- 從每兩週一次增加到每週三次
- 每次佈署的變更減少到15-20個
- 佈署問題減少，但仍然存在
第二階段：實施持續整合
- 建立自動化測試流程
- 所有提交都經過自動化測試
- 問題在佈署前被發現
第三階段：功能標誌和金絲雀佈署
- 實施功能標誌系統
- 新功能首先對內部使用者可見
- 逐步擴大使用者群
- 問題影響範圍受限
結果
- 佈署頻率增加到每天多次
- 平均每次佈署
簡單系統的實用性優於複雜系統的完美性
在系統設計中，簡單與不完美的系統通常比複雜的系統更實用。不可變資料結構讓程式設計師和操作者避免追蹤狀態變化，而與大多數情況下效能差異不明顯。雖然輪詢（polling）可能比推播式（push-based）管道效率較低與速度較慢，但它避免了複雜的平行處理模式。維護零停機系統所需的工具可能相當複雜，遠超過定期維護視窗所需的工具。動態設定雖然快速與減少人工操作，但靜態設定服務並強制重新啟動則更容易理解。甚至只是減少設定選項數量，就能大幅提高操作人員對系統當前狀態的準確判斷。
每當我們向系統新增功能時，都會帶來一定程度的複雜性。然而，並非所有複雜性都對可靠性有害。有些複雜性是必要的。由於我們無法總是判斷新增的複雜性是否會影響未來的可靠性，事故回顧是討論複雜性所扮演角色的絕佳時機。最終，這總是一個權衡問題。但我保證，在下次事故回顧中，稍加尋找，你會發現許多有害的複雜性！
傳奇事件：從系統故障到團隊文化象徵
為什麼有些故障一旦解決就被遺忘，而另一些則成為團隊傳奇？我相信這是因為傳奇故事遵循英雄旅程模式—一種用於理解從摩西到哈利波特等各種故事的文學模型。
系統故障，就像英雄旅程一樣，有三個關鍵部分：行動召喚、試煉之路和回傳。想像值班工程師踏上史詩般的探險，遵循這些步驟能讓我們瞭解是什麼讓事件故事令人興奮，並希望能給予我們防止其再次發生的見解。
我的傳奇行動召喚始於「那是聖誕節前兩晚…」時機很重要，因為坦白說，這個問題在一年中任何其他日子都不會那麼有趣。但作為團隊新人，我必須鼓起勇氣，在公司假日期間呼叫老闆尋求幫助。
試煉之路通常是最豐富的部分—這是診斷和緩解情況的階段。這個階段是「什麼鬼」時刻的金礦。如果你口頭講述故事，這是聽眾應該集體呻吟的地方。也許日誌訊息缺少了你解開謎團所需的細節。或者像我的情況，一個簡單的設定變更因為缺少適當工具而花費六小時和四名開發人員來佈署。
我們發現問題是由姊妹團隊進行「無害」的年終清理造成的。幸運的是，我們團隊從那時起已經成熟了不少，但每當有人向我抱怨假期鎖定或生產環境存取安全時，我就會講述這個故事。試煉之路中的教訓正是你應該投入開發時間以防止未來痛苦的地方。
回傳階段很重要，因為它幾乎與我們的技術系統無關，而完全關乎團隊文化。在進行事後分析或根本原因分析時，我們經常從TTx（時間到x）角度考慮事件，如檢測時間或緩解時間，但這些指標很少能讓我們瞭解是什麼使事件變得有趣。如果這是你故事中最有趣的部分，是因為正確的原因嗎？還是因為你的團隊需要培養一種無責備的文化，使這些故事可以不受判斷地分享？
這些傳奇故事無論我們是否有意，往往超越團隊本身。它們在聚會、釀酒廠，或者經常是在其他故障期間被分享。我在大學徵才講座中瞭解了2012年Azure閏日故障。一位初級工程師分享了他在與技術研究員和副執行長同處一個會議室中編寫程式碼修復的故事。他的故事展示了即使在職業生涯早期，你也可以參與重要事件。最終，這影響了我加入微軟的決定。
多年值班經歷後，我現在明白，如果一個工程師成為英雄，那麼在流程、基礎架構或工具中存在差距。我也瞭解到英雄從不孤單。在我鼓起勇氣打電話給老闆後，我們一起解決了問題。幫助推動設定變更的四名工程師是我珍視的朋友和同事。是的，我們在工作時分享了最喜歡的事件故事。
所以聚在一起，講述你的故事，但請記住，這不僅關乎英雄。它關乎逆境如何將團隊團結在一起，以及我們如何防止續集發生。
指標不等同於SLI：避免「衡量一切」的陷阱
「衡量一切」是一個陷阱。
這是一個隨時間傳下來的隨意建議，沒人能確切記得原因。在不成熟的組織中，當實習生沒有用的工作時，這就成了交給他們的專案。我們花費數小時增強程式碼以應對各種假設情況，最終用無用的資料點填滿了指標搜尋空間。不要衡量一切。
在記憶體昂貴的時代，你必須謹慎選擇要儲存的指標，專注於服務最重要的指標。隨著記憶體成本降低，儲存越來越多的指標變得越來越便宜，理由是在（遙遠的）未來某天提供價值。對大多數人來說，那個未來從未到來。
問題變成「什麼值得衡量？」專注於能構建高品質SLI（服務水平指標）的指標。首先，讓我們描述指標和SLI之間的區別：
- 指標是原始數字：佇列中的專案數量、自上次失敗以來的天數、購物車中的專案數量等。
- SLI是指標的組合，能講述一個故事：如果佇列以目前速率繼續填充，系統效能開始降低或完全當機前還剩多少時間？
指標提供系統正常運作的證據。SLI提供服務運作良好的程度以及將繼續良好運作多久的證據。這是客戶體驗的故事，這才是你應該關注的重點。
客戶體驗不只影響付費客戶。使用你服務的每個團隊成員或值班人員也是客戶。在確定要提供哪些指標時，考慮「凌晨2點因素」：在半夜被喚醒時，這個指標會幫助我或他們更快地還原服務嗎？這個指標對警示有用嗎？這個指標能準確衡量服務健康度嗎？如果答案是否定的，重新考慮對該指標的投資。
隨著服務成熟，持續重新檢視你的SLI很重要。這些指標像函式一樣很快過時。重構程式碼時，也要重構指標以驗證SLI是否仍然適用。花時間做這項工作，因為長期來看它會帶來十倍的回報，並確保向利益相關者傳達這樣做的價值，特別是因為回報並非立竿見影。準備好每月甚至更頻繁地重新檢視你的指標。頻繁檢視將導致小幅調整而非過時SLI的徹底改造。
決定不測量某些東西有時可能令人生畏，可能看起來不值得討論。但你應該怎麼做呢？專注於客戶需求，並測量能改善他們體驗的SLI。這將使你的服務更加成熟，並防止你陷入「衡量一切」的陷阱。你的工程師會感謝你不用在凌晨2點為無用的警示而起床。
在系統設計和可靠性工程中，我們經常面臨複雜性與簡單性之間的權衡。簡單系統通常比複雜系統更可靠，因為它們更易於理解、維護和修復。當系統出現故障時，這些事件不僅是技術問題，更是塑造團隊文化的機會。故障處理的故事，從行動召喚到試煉之路再到回傳階段，能夠成為團隊寶貴的學習資源和文化象徵。
同時，我們需要避免「測量一切」的陷阱。不是所有指標都有價值，專注於能構建有意義SLI的指標才是明智之舉。這些SLI應該講述客戶體驗的故事，並在系統演進時不斷調整。最終，無論是系統設計、事故管理還是指標選擇，都應該以提升服務可靠性和改善使用者經驗為核心目標。
SLO的兩面刃：量化承諾與隱藏陷阱
服務水平目標(SLO)是一個美妙的直覺概念：一份量化的合約，描述服務預期的行為表現。這些指標常被用來建立反饋迴圈以優先考慮可靠性、在採用新依賴時溝通預期行為，以及在問題發生時協調團隊間的優先順序。
然而，SLO建立在對服務行為的隱含模型上，其中包含了一系列簡化假設，例如請求的獨立性、錯誤的均勻分佈，以及所有請求的同等重要性。這些假設並非普遍成立，導致SLO的經驗法則在真實世界的服務中當機。瞭解這些假設在何處以及如何失效是至關重要的，尤其是當SLO無意中將我們引向錯誤方向時。
錯誤預算的多重導向
考慮錯誤預算：在一段時間內，允許的失敗次數或百分比。這些錯誤可能集中在短時間內發生，或者在很長一段時間內以低速率發生。它們可能分佈在所有使用者中，或者集中在少數使用者身上。個別使用者可能遇到低錯誤率或100%錯誤率。所有這些因素都會影響使用者對服務中斷的感知以及這些中斷對使用者的實際影響。
玄貓在多個大型技術組織中觀察到，錯誤預算的分配方式直接影響使用者經驗。例如，一個月內允許1%的錯誤率，可能意味著所有使用者偶爾體驗到短暫的問題，或者1%的使用者完全無法使用服務。從資料角度看，這兩種情況是相同的，但使用者經驗卻截然不同。
災難性事件的處理困境
如何處理災難性事件？許多服務提供商嘗試將「糟糕的日子」納入SLO承諾中。然而，有些糟糕的日子實在太糟糕了。這導致一種妥協，既不能很好地描述正常時期的服務，也不能很好地描述異常時期的服務。
當事情真的變得非常糟糕，並且消耗了多個時期的錯誤預算時，該怎麼辦？雖然凍結服務數年的前景可能很吸引人，但這很少符合使用者或服務提供商的最佳利益。
錯誤預算與使用者期望的不比對
同樣，由於錯誤預算通常包含尾部風險，它們代表了P99+的糟糕體驗。因此，積極消耗錯誤預算是向客戶提供持續糟糕體驗的好方法。
SLO與客戶期望的平均體驗之間的不比對也會導致服務提供商和客戶之間的分歧。客戶傾向於期望他們昨天收到的體驗，即使從整個服務的角度來看，那是一個正面的異常值，而與這種行為的變化往往會導致他們的架構出現問題。
SLO的本質與改進方向
歸根結底，SLO是關於量化交付的服務、設定適當的期望，以及在事情不順利時改變策略。所有這些活動對於提供值得信賴的服務都至關重要。那麼，我們可以做什麼來修復SLO呢？
改進SLO的五大策略
使用不同方法描述SLO的不同方面：使用穩定狀態錯誤率SLO來衡量瞬時錯誤率，但使用「壞分鐘」類別的SLO來表徵重大中斷。測量重大中斷的頻率和嚴重程度，並進行溝通。
衡量並儲存每個客戶的SLI資料：確定個別客戶正在經歷的體驗，以及錯誤是否均勻分佈。
謹慎使用錯誤預算：除非你的SLO確實近似於你想要提供給客戶的服務，否則不要消耗錯誤預算。對某些服務來說，這可能永遠不會是正確的做法。
接受SLO測量的模糊性：我們的服務是豐富的，單一的服務好壞度量是不可能的。這種方法為細微的情境意識和可以用來改善使用者經驗的各種方向留出了空間。
在穩定狀態下設定符合客戶實際期望的SLO：不要將尾部風險納入考量。
實際應用中的平衡
玄貓在實務中發現，理想的SLO設計需要平衡技術可行性與使用者經驗。例如，對於一個具有複雜依賴關係的微服務系統，可能需要為不同層級的服務設定不同形式的SLO，而不是簡單地套用單一範本。
另外，值得注意的是，SLO不應該成為團隊間的爭執工具，而應該是促進協作的框架。當一個SLO被違反時，重點不應該是責備，而是集體理解和改進系統。
產品可靠性的整體方法
超越技術冗餘的可靠性思維
透過冗餘，你已經消除了所有單點故障。服務得到適當監控，警示也已設定。定期測試還原策略，確保值班團隊能夠立即做出反應。你仔細研究了請求並宣佈了可實作的SLO。
工作完成了！或者真的完成了嗎？要確保產品成功，必須採取端對端的整體方法，從使用者互動到磁碟上的位元組。
多層抽象的挑戰
典型的前端-後端分離不再那麼簡單。現在有層抽象。你的Web服務是客戶端的前端；它向處理後端傳送請求，而這些後端實際上只是其他服務（如快取和儲存伺服器）的前端。一層又一層。
而我們仍在上面堆積積疊更多層：客戶端應用程式。它們有各種形狀和大小，從漸進式Web應用到在人工智慧裝置上本地執行的應用。這些應用程式也有後端：分享函式庫料函式庫地儲存。可靠的客戶端現在比以往往任何時候都更重要，因為全球目前使用的人工智慧裝置超過35億台。
整體方法的實施步驟
如何開始應用整體方法？首先看相依性管理和測量正確的指標。我們都有這樣的經歷：一個二進位檔案開始當機，我們急於找出是什麼觸發了它。是發布還是設定推播？如果是，是哪個服務？如果你能快速確定系統的哪部分發生了變化，就能更快找到根本原因。
這意味著知道客戶端正在與哪些後端通訊，正在使用哪些分享函式庫及正在推播哪些動態設定。理想情況下，你的系統只會與明確定義的依賴互動，這樣任何新依賴（即可能的故障點）在事件回應期間都能立即可見，並且任何後端服務降級都可以歸因於特定的使用者問題。
玄貓為你解密：
在這裡，我們看到整體可靠性方法的核心理念 - 不僅關注個別元件的可靠性，而是整個系統的端對端可靠性。特別重要的是相依性管理，也就是清晰地瞭解系統中每個元件依賴於哪些其他元件。這種明確性在故障排查時極為寶貴，可以顯著縮短平均還原時間(MTTR)。
衡量真正重要的指標
SRE最常關注的指標是RPC（遠端過程呼叫）的成功和失敗比率。但是，如果你的客戶端在使用者裝置上不斷當機怎麼辦？你的成功率實際上可能會上升，但如果你的應用程式無法使用，這並沒有太大安慰。
這裡有另一個例子。對於每分鐘有百萬次查詢(QPM)的服務，合理的99% SLO可能透過以下兩種方式耗盡其錯誤預算：10,000名使用者每分鐘遇到一個錯誤，或者一個堅決的使用者重試10,000次並且每分鐘遇到10,000個錯誤；比率相同，但體驗截然不同。
那麼應該測量什麼？關注使用者與產品互動的能力：關鍵使用者互動（例如，開啟訊息然後刪除它）。這些互動告訴你使用者是否能使用你的產品。此外，不要忘記按不同平台和版本上受影響的使用者數量來切片資料，以確保沒有裝置組長時間受到某種故障模式的不成比例影響。
玄貓為你解密：
這段內容突出了一個關鍵點：不應該只關注技術指標（如RPC成功率），而應該測量對使用者真正重要的事情 - 他們能否完成關鍵任務。舉例來說，電子郵件服務的重點不應該是"伺服器回應率"，而應該是"使用者能否傳送和接收郵件"。這種以使用者為中心的指標設計能更準確地反映實際服務品質。
擁抱客戶端責任
時代已經改變；網際網路現在比以往往任何時候都更加異質，大部分流量不再來自PC。隨著大量移動作業系統和物聯網(IoT)裝置的出現，我們不能再假裝客戶端不是我們的責任。
採取整體方法將有助於減少MTTR（平均修復時間）。幾分鐘的停機時間可能會被使用者忽略（只是小故障），但幾個小時可能導致使用者信任喪失、不良的媒體報導和潛在的收入損失。將緊急支援擴充套件到客戶端將導致更短的回應時間，並在面對中斷時贏得使用者信任。從使用者開始，向外擴充套件。你以後會感謝自己的。
玄貓為你解密：
最後這段強調了現代SRE實踐中的一個重要轉變：承認客戶端也是可靠性方程式的一部分。隨著裝置多樣性的增加（手機、平板電腦電腦、IoT裝置等），只關注伺服器端可靠性已經不夠。整體方法要求我們考慮從使用者裝置到後端服務的整個鏈條，這是減少平均修復時間和提高使用者滿意度的關鍵。
尋找失去的時間
誰沒有面對過由一個你認為可以再等六個月的問題引起的重大服務中斷？啊！我們多麼希望能夠避免這場火災，多麼希望有時間來預防它。
這種情況在技術團隊中太常見了。當我們專注於新功能和增長時，往往會推遲解決那些"可以等"的問題。然而，這些被推遲的問題常以更大的代價回來找我們 - 通常是在最不方便的時候。
預防性工作的價值
SRE工作的本質之一是找到適當的平衡點，在緊急問題和長期健康之間分配時間。玄貓發現，成功的團隊通常會分配固定比例的時間用於預防性工作，無論當前壓力如何。
這種方法可能看起來違反直覺，特別是當團隊面臨緊迫的期限時。然而，長期來看，這種紀律性的投資可以大減少緊急事件的發生，實際上為團隊創造更多時間。
建立預防文化
要建立這種文化，需要團隊和管理階層的共同承諾。SRE團隊可以透過以下方式開始：
- 記錄和量化技術債務的成本
- 在每個衝刺中保留固定比例的時間用於系統改進
- 慶祝預防
每日小步改善：克服時間壓力的可靠性工程實踐
在技術團隊中，我們總是面臨這樣的困境：基礎設施團隊身兼數職，既要支援產品團隊、維護現有系統，還要負責待命、開發工作流程和資源設定等各種任務。在有限的時間和資源下，技術債務償還、自動化建置與工具開發常被迫讓位於產品功能開發。畢竟，產品是公司成長和生存的關鍵，大部分精力自然投入到透過開發優秀解決方案來取得新客戶上。
可靠性投資的時間悖論
這種工作優先順序的設定，讓我們失去了對變革保持開放態度的機會，也難以思考新專案如何與現有工作整合。在這種環境下，等待一個"聖杯級"的專案來解決問題，似乎比持續小幅改進更為合理，但這種思維其實是有害的。
時間和空間的缺乏，導致許多組織在實施持續整合/持續交付(CI/CD)等技術上花費過長時間。與其逐步推進，他們往往聚焦於概念的龐大性和相關風險。這也是為什麼我們仍然在半夜被叫醒處理事故，只是閱讀操作手冊並反覆應用相同步驟，而不是投資於任何形式的自動修復。所有解決方案看起來都很龐大，時間又很有限，所以甚至開始質疑嘗試的意義！我們必須繼續沿用舊方法並承受痛苦？
延遲可靠性投資的代價
不在產品功能和系統可靠性上同等投資的問題在於，隨著時間推移，可靠性投資的成本會增加。新功能帶來的複雜性增加了工程師的認知負擔，使得處理可靠性問題變得更加困難。這些問題在我們腦海中變得如此巨大，以至於我們一再推遲，直到有更多時間——也許在遙遠的未來——直到不可避免的系統故障發生。
解決方案的一部分是每天優先處理一些小事情，朝著整體可靠性目標前進，而不是花一週時間集中處理然後轉向其他工作（並且永不回頭）。安排我們的日程以適應較短的任務，使我們的大腦感到更加輕鬆，並建立習慣。從業務角度看，這也允許更定期的檢查和持續改進。
建立每日改進模式
如何鞏固這種模式？它始於公司層面的承諾，為工程師創造自由空間，使他們能夠持續處理專案中的可靠性問題。
這種自由轉化為時間，根據你的工程模式，可以是每天固定比例的時間，或者每隔一段時間（6週到一個季度）完全專注於技術債務的一週。然後，工程團隊和基礎設施團隊之間需要就最需要改進的領域達成一致。
下次當你有30分鐘空閒時，思考如何解決一些惱人的問題。每天30分鐘累積起來是每週150分鐘，每月600分鐘，每年7200分鐘！想像一下你能用這些時間解決什麼問題！
辦公室諮詢時間的意外收穫
在我過去的工作中，團隊回顧會上，一位工程師建議開設辦公室諮詢時間（Office Hours），讓產品團隊可以詢問我們關於工具和服務的問題。
當時，我們面臨著產品團隊對我們提供的工具採用率低、與利益相關方關係緊張，以及缺乏理解如何使現有平台工具（如Prometheus）以產品開發人員需要的方式工作等問題。
從懷疑到驚喜
說實話，我最初並不認為辦公室諮詢時間會解決問題；我們已經有其他溝通管道，而與我們對缺乏利益相關方的反饋感到不滿。為了追蹤模式並在需要時對流程進行更改，我們設定了內部月度審查會議（在解決初步問題後將頻率降低到季度）。我預期會看到一些模式出現，這些模式可能透過新增檔案、自動化某些事項或建立更好的流程來輕鬆解決。
在實施辦公室諮詢時間後，我們立即注意到我們團隊與公司其他人之間的溝通有所改善。
為了鼓勵人們前來打招呼，有人建議我們帶些烘焙食品，所以至少我認為我們會透過食物與其他團隊建立一些積極的關係，這可能會緩解團隊之間的緊張關係。令我驚訝的是，即使沒有烘焙食品，每週都會有至少兩個人在那個時間出現。（Slack公告顯著增加了這個數字。）
心理安全的重要性
經過調查，原來Slack幫助頻道太令人生畏，因為公開提問感覺像是如果問題很傻，就會讓自己受到羞辱。不是說這真的會發生，但這種可能性足以阻止人們。我們發現的一個意外模式是，非工程師開始向我們提問，還有更多初級工程師、剛開始接觸特定技術領域或非常焦慮的工程師——這些人從未在我們的幫助頻道中向我們提問！
相反，我們創造了一個歡迎的空間（偶爾有香蕉麵包），營造了一個非正式的安全場所，人們可以前來而不用擔心打擾他人、公開宣佈自己不知道的事情，或者愚蠢的問題被永久記錄。
非工程師不想因為非關鍵性學習而打擾工程師或透過安排特定時間進行白板會議。心理安全通常與無責備事後分析有關，但在開發SRE的參與模式時也需要考慮。否則，很可能會有更多的事情未被說出。我們發現某些問題只有在實施辦公室諮詢時間後才出現。例如，專案經理會詢問系統細節或效能改進。辦公室諮詢時間為利益相關者創造了完美的環境，使他們感到安全地提出此類別問題。
跨團隊溝通的新思路
在此之後，我們在Slack幫助頻道中的參與度也有所增加，因為人們與團隊建立了更多的關係，並且更加自信，相信他們的問題會得到解決。
嘗試考慮心理安全和社會學模式的跨團隊溝通和利益相關者管理的新途徑。我鼓勵你找到方法將人性帶回工程對話中；在安全空間為失敗和提出愚蠢問題創造空間。請記住，Slack需要一定程度的專業性，但辦公室諮詢時間為創造力和非結構化對話創造了空間，不管邏輯缺陷如何。在我們的辦公室諮詢時間，人們只是順道問候，這為偶然的對話、創新以及學習和成長的空間提供了可能。
開發使用者真正想用的內部工具
在《紐約時報》，沒有人被要求使用我的團隊的工具或遵循我們的流程。相反，如果我們想贏得團隊的心，我們必須建立他們想要使用的工具。為此，我們採用了產品管理視角，積極尋求關於團隊如何看待我們的工具和流程價值的反饋。
將同事視為客戶
雖然定量指標至關重要，但在內部工具中，定性反饋往往被忽視。你如何瞭解使用者——或者，你應該開始稱呼他們為客戶——的滿意度？你可能無法收集與外部產品相同規模的使用者行為資料，但幸運的是，來自同事的定性反饋是解決這個問題的好方法。能夠輕鬆聯絡公司目錄中的某人實際上是一個主要優勢。
建立有效的反饋流程
首先，確定期望的結果。你是否試圖瞭解問題領域？尋找對設計的反饋？從那裡開始，我們使用包括調查和後續訪談過程的反饋流程。
玄貓為你解密：
在開發內部工具時，我們常忽略了一個關鍵點：內部使用者也是"客戶"，他們的滿意度和採用意願直接決定了工具的成功。紐約時報團隊採用的方法值得借鑑，它將產品思維應用於內部工具開發，主動尋求質性反饋而非僅關注量化指標。特別是在內部工具開發中，我們擁有一個外部產品團隊所沒有的優勢：可以直接、便捷地聯絡到每一位使用者。
這種方法的核心在於轉變思維模式，不再將工具強制推給同事，而是思考如何創造他們真正想要使用的解決方案。這需要我們像對待外部客戶一樣重視內部使用者的需求和體驗。
持續小改進的關鍵策略
綜合上述經驗，我總結了幾點關於如何在時間壓力下實作系統可靠性持續改進的策略：
時間切片法
將大型改進專案分解為可在30分鐘內完成的小任務。例如，自動化一個經常手動執行的指令碼、改進一個錯誤訊息、或者新增一個缺失的監控指標。這些小改進累積起來會產生巨大影響。
建立固定時段
在團隊中建立"技術改進時段"的文化，可以是每天固定的一小時，或者每週的一個下午。關鍵是保持規律性，而非一次性的大型努力。
優先處理高頻痛點
識別團隊成員每天都會遇到的小煩惱，這些問題雖小但頻繁發生，解決它們往往能帶來立竿見影的生產力提升和士氣改善。
創造非正式交流空間
像"辦公室諮詢時間"這樣的非正式交流機制，能夠打破團隊間的溝通壁壘，特別是對於那些在正式管道中不願發聲的同事。這不僅促進了知識分享，還能發現潛在的系統問題。
將同事視為客戶
在開發內部工具時採用產品思維，主動收集反饋並迭代改進。記住，沒有人"必須"使用你的工具——除非它確實解決了他們的問題並提升了效率。
這些方法的共同點在於，它們都不需要等待完美時機或大型專案，而是透過持續的小步改進，逐漸構建更可靠、更高效的系統和團隊。正如我常說的：可靠性工程不是一場馬拉松，而是每天都要參與的接力賽。
技術債務和系統可靠性問題往往因看起來太龐大而被推遲，但實際上，正是那些每天30分鐘的小改進，最終累積成顯著的變革。下次當你有一小段空閒時間，不妨思考：「我現在能解決哪個小問題，讓明天的工作更輕鬆一點？」
問卷調查的產品思維：使用者經驗導向設計
當我們談到資料收集，許多團隊往往只關注於取得資訊，而忽略了問卷本身的使用者經驗。在多年的技術諮詢工作中，玄貓發現將問卷視為「產品」是獲得有價值反饋的關鍵。
良好的問卷設計應該以使用者為中心，讓填寫者能輕鬆完成而不感到疲憩。最佳實踐是讓多數問題採用選擇題形式，這不僅能提高完成率，也便於後續分析。我建議控制開放式問題的數量，避免過多「為什麼您這樣評分？」之類別的提問，這些問題雖有價值，但會大幅增加填寫負擔。
問卷設計的黃金法則
- 以使用者經驗為核心 - 設計每個問題時都要考慮填寫者的感受
- 優先使用選擇題 - 讓大部分問題可以快速作答
- 測試再發布 - 在大規模傳送前，先讓小群體測試問卷的易用性和清晰度
我曾協助一家科技公司改善其內部工具滿意度調查，將原本需要20分鐘完成的冗長問卷重新設計為5分鐘版本，回覆率從原本的23%躍升至78%。關鍵在於我們將開放式問題減少了80%，並確保每個問題都有明確目的。
匿名反饋的價值與平衡
匿名反饋，尤其來自同事的意見，通常是最誠實的。這點在技術團隊中尤為重要，因為工程師往往傾向於直接而非委婉表達。然而，完全匿名也可能導致缺乏連貫的背景與環境。
一個平衡的方法是在問卷中設計非強制性的身份欄位。例如，在我設計的一份問卷中，第一個問題給予受訪者選擇是否留下姓名的選項，並說明這是為了後續可能的深入交流。這種做法既減輕了受訪者提供詳細反饋的壓力，又幫助我們建立了一個願意分享經驗的人員資料函式庫 同時，可以使用其他問題如工作職能或團隊來確保回應的平衡性。這讓我們能夠在不強制要求個人身份的情況下，仍能分析不同群體的反饋差異。
問卷之外：有效的使用者訪談策略
問卷調查固然重要，但它不能替代真正的對話。要獲得深入洞察，進行使用者訪談是不可或缺的環節。
訪談前的準備工作
首先，列出所有使用者類別，確保樣本具有代表性。這有助於發現預料之外的問題和盲點。我一般建議至少覆寫三種不同角色的使用者，例如新手、工作者和偶爾使用者。
準備開放式問題時，需特別注意避免誘導性提問。例如，不要問「你認為這個功能有多好？」而應問「你對這個功能的看法是什麼？」這種微妙的差別會顯著影響受訪者的回答方向。
訪談技巧與注意事項
訪談過程中，避免打斷受訪者是關鍵。當他們表達完一個觀點後，可以請他們進一步闡述某個提到的點，而非立即轉向下一個問題。
每次訪談應該有一名引導者和一名記錄員。玄貓建議充分利用團隊資源—讓工程師輪流擔任這些角色。這不僅能讓你訪談更多人，還能讓團隊成員直接參與並改進過程。在我指導的一個產品團隊中，我們讓後端工程師參與使用者訪談，結果發現他們對產品功能的理解有了質的飛躍。
從結果到行動：分析與實施
完成調查和訪談後，與團隊一起綜合分析結果至關重要。這裡需要特別注意一點：結果需謹慎對待。單一訪談的結果不應成為顛覆現有計劃的理由。
分享結果與計劃
如果你的目標是推動文化變革，重要的是不僅要展示你在傾聽，還要提出具體的改變計劃（或解釋為什麼某些事情無法實作）。在未來徵求反饋時，參照根據之前反饋所做的改進，這能建立信任並鼓勵持續參與。
持續性反饋迴圈
反饋迴圈應該是定期與持續的，而非一次性活動。這是一個不斷迭代和改進的過程。同時，定期檢視你的流程是否真正有效—有時候我們太專注於遵循流程，而忘了評估它是否真正為我們帶來價值。
個人與互動：DevOps文化的核心
轉向DevOps文化的話題，《敏捷宣言》中有一句經典原則：「個人和互動重於流程和工具」。這不是說工具和流程不重要，而是強調建立DevOps文化的最大障礙往往是我們自己以及我們與團隊的合作方式。
從集中式到自主管理的轉變
以紐約時報2017年的資料中心遷移為例，當時長官層決定各團隊將負責自己的基礎設施。在此之前，集中式基礎設施團隊常被視為其他團隊的阻礙。一些較大的應用團隊缺乏在雲端遷移和構建應用的技能和資源，因此SRE團隊開始協助他們。
在某些情況下，這意味著SRE工程師直接與應用團隊一起工作。這種協作模式讓玄貓想起早期在一家大型電商擔任技術顧問時的經歷，當時我們也是透過類別似方式幫助業務團隊適應雲端環境。
分享目標模型
很快團隊意識到，若要讓其他團隊長期成功，SRE不能只是幫忙完成工作。特別是，如果SRE持續與其他團隊合作，那SRE自己的積壓工作怎麼辦？因此，紐約時報採用了分享目標模型，這幫助他們在減少自動化積壓和與其他團隊合作之間取得平衡。
分享目標是指SRE團隊與其他團隊協作，為他們的使用場景構建功能，或解決他們可能成為早期採用者的問題。這種合作更多是提供專業指導或嵌入團隊以幫助他們完成專案，如測試自動化。
成功協作的框架
經過幾次合作後，團隊建立了一個流程，為這些合作關係奠定成功基礎：
定義成功 - 在合作開始時，明確定義成功的樣子以及如何衡量。這個目標會同時出現在兩個團隊的路線圖上。
設定合作預期 - 明確協作如何進行。例如，確保工作是指導與構建工具的結合，讓團隊能夠使用。同時明確角色和責任，如誰負責撰寫工單以及如何更新進度。
這種方法雖然看似繁瑣，但實際上消除了混淆並節省了時間。透過與團隊一起開發工具，SRE團隊確保這些工具長期適用。這也讓他們更瞭解不同團隊的工作方式和工具使用情況。
這種協作模式非常有效，但需要付出顯著努力。這類別投資對於處於重大工作初期階段的團隊非常有用，並可隨時間減少。現在，紐約時報將合作限制在涉及多個團隊的大型戰略性工作上。
SRE工程師的人性基準：團隊學習與成長
說到SRE（網站可靠性工程），這是一個特殊的職業，因為成為SRE的要求非常廣泛，而這些技能並非普通電腦科學位課程的一部分。
SRE的多面技能需求
組織聘請SRE時假設他們精通程式設計、深入理解系統、熟悉監控和警示、能執行任何服務、能除錯生產問題、能提高效能—還能變魔術。
擁有如此廣泛的技能看似超人，但實際上需要的是對事物運作方式的濃厚好奇心以及從各處學習的能力。公平地說，期望每個人一開始就掌握所有知識是不現實的；我們都來自不同背景，學習方式也不同。很少有人能在眾多領域成為深度工作者，所以我們應該相互依靠，不斷提升彼此的技能。
團隊成長的協同模式
技能提升應該是指導和個人努力的結合。指導可以對團隊產生深遠的積極影響，提高導師和學員的知識，並建立更牢固的聯絡。然而，由於指導需要時間、精力、奉獻和善意，它被視為額外工作。通常它不計入績效評估，不被視為產生影響，也不包括在團隊規劃中。因此，指導他人成為課外活動，而技能提升往往成為個人運動，由個人自行決定是否實作。
這不應該是單打獨鬥的活動，也不應該讓人感到孤獨。玄貓認為指導可以融入日常工作中。以下是一些值得嘗試的簡單策略：
選擇較長的路徑
不要總是將任務分配給能更快完成的工程師，考慮分配給能從中獲益更多的工程師，並由團隊提供適當支援和指導。
接受錯誤和不完美
在合理範圍內，讓人們犯錯然後自行修復是可以的。此外，接受一個可行的一般解決方案，讓工程師隨時間改進它也是可以的。
結對系統工程
這相當於系統工程的結對程式設計，兩名SRE透過分享同一螢幕等方式共同執行任務。
適時退後
在處理事件時，根據嚴重程度，資深工程師可以退後一步，讓團隊其他成員進行調查。事件英雄主義雖然能產生結果，但也可能掩蓋團隊其他成員的貢獻。
成就可靠性：技術與人性的平衡
回顧整個技術營運過程，從問卷設計到DevOps文化再到SRE團隊建設，有一個共同主題貫穿其中：人的因素至關重要。
技術可靠性不僅關乎工具和流程，更關乎人與人之間的互動。正如紐約時報的例子所示，重點不在於複製書中的流程或推出特定工具。可靠性是一項團隊運動。透過專注於互動，我們建立了雙方的信任和同理心。與SRE團隊合作的團隊非常感謝他們所做的工作，更願意在未來與他們合作。
同樣，在培養SRE人才時，我們需要認識到每個人都有不同的學習曲線和專長領域。透過將指導融入日常工作，我們不僅提高了個人技能，還加強了團隊凝聚力。
最終，無論是設計問卷調查、建立DevOps文化還是發展SRE團隊，成功的關鍵都在於將人放在技術之上。透過關注個人互動、持續學習和相互支援，我們可以建立真正高效與可靠的技術組織。
在不斷變化的技術世界中，保持這種以人為本的方法將幫助我們不僅應對當前挑戰，還能為未來的創新奠定堅實基礎。技術來去，但良好的團隊互動和學習文化將持續產生價值。
導師制度：開發包容與蓬勃的團隊根本
在現代技術團隊中，導師制度已經不再是可有可無的額外福利，而是建立高效能、包容性團隊的關鍵根本。作為SRE，玄貓認為我們需要像監控系統一樣關注團隊的「人性基準線」。
人性基準線的建立
當我們執行服務時，會使用基準線作為系統執行狀況的指標，但基準線不僅限於我們的生產環境，它同樣適用於執行這些系統的人員。團隊的「人性基準線」是團隊共同認可的軟技能和技術技能組合，代表著加入團隊所需的基本能力。
然而，在實際徵才中，我們往往會遇到這樣的抉擇：是否應該投資於那些不完全符合所有條件但具有發展潛力的候選人？玄貓的經驗是，與其浪費時間尋找「獨角獸」般完美的人選，不如建立一個能幫助新成員達到並超越團隊基準線的框架。
這種思維方式在長期看來更為務實。隨著時間推移，技能可以在團隊的幫助下得到提升。試問，還有什麼比一個彼此關心的團隊更高效率、更有成效的存在嗎？
遠距工作的生產力悖論
當團隊從本地或分散式轉變為遠距工作模式時，生產力的變化往往呈現出一種看似矛盾的現象。普遍的假設是：遠離辦公室的幹擾後，個人生產力應該會飆升。然而，實際情況是，雖然團隊整體生產力可能增加，但個人生產力卻可能波動或下降。
生產力重組的現象
這種現象背後的原因是什麼？在我觀察和參與的眾多組織中，關鍵工作和不那麼緊急的工作都需要完成。生產力是這兩類別工作都得到關注的結果。當個人生產力下降時，人們往往會重新聚焦於其中一種類別的工作。
如果你衡量成功的標準是高優先順序任務的完成數量或專案里程碑的達成，你可能會發現團隊的整體影響力實際上提高了。這是因為遠端工作迫使團隊重新評估工作優先順序，而非單純追求任務數量。
遠端工作的時間彈性優勢
遠端工作的個人貢獻者(IC)也有機會以不同於以往往的方式提高生產力，時間轉移工作或打破一天的工作節奏就是一個很好的例子。例如，處於不同時區的IC可以利用早晨的安靜時間，在較少中斷的情況下專注完成任務。
玄貓曾在一個跨越多個時區的團隊中工作，團隊成員靈活運用時區差異，創造出近乎24小時的持續開發迴圈。亞洲團隊成員完成工作後，歐洲成員接手，再傳遞給美洲成員，形成了一種獨特的工作流程，大提高了解決問題的速度。
遠端協作的核心：溝通與人際連結
保持高生產力的關鍵在於溝通和協作，而這些都是以人為中心的活動。它們需要與他人互動、傾聽、內化和回應。網路上有大量關於如何進行良好視訊會議或作為遠端IC過度溝通的重要性的資訊，但很少有人討論社交紐帶的重要性。
建立與維護團隊信任
成員之間的信任是任何成功團隊不可或缺的部分，而這種信任是由牢固的關係支援的。在疫情前的世界中，這種信任建立於IC們一起坐著、解決問題並共度時光的過程中，相互瞭解。
從我的經驗來看，在同一地點共處1-2週的時間足以讓個人分開長達3個月，同時仍然保持相同水平的信任和協作。3個月後，這些關係會開始削弱，需要更多的共處時間來重新整理它們。
遠端社交連結的創新方式
在這個更多組織轉向遠端團隊與整體旅行減少的新世界中，維持團隊關係變得更加困難。我們必須找到方法在專業和個人層面上保持團隊成員之間的關係牢固。以下是一些有效的策略：
視訊會議社交時間
安排團隊成員在同一時間聚集，談論工作以外的事情。討論特殊場合、個人里程碑和事件，確保人們能夠應對與團隊隔離帶來的挑戰。
多人線上遊戲
許多遊戲都可以免費玩與廣泛可用。輕鬆的遊戲環境能夠自然地促進團隊成員間的互動和了解。
一對一晚餐對話
在晚餐時進行一對一交談，自然提供了一個非工作環境，讓人們可以談論工作以外的事情。
作為一個大型團隊的資深工程師，玄貓每週花費大量時間與其他工程師進行10-15分鐘的一對一交流。關鍵在於找到能夠在社交環境中相互接觸的機會。
調整對生產力的期望
轉向遠端工作可能會讓一些人感到生產力降低，完成的工作量低於他們習慣的水平。重要的是不要對此有膝跳反應，並意識到這實際上是可以接受的。
重新評估工作優先順序
你的組織應該不斷評估它可以做的更重要的工作，確保專注於此。結果，一些額外的、不太關鍵的工作可能會被擱置。接受並擁抱這一點。如果不重要的工作被擱置，而關鍵工作完成得同樣好或更好，那麼事情正朝著正確的方向發展。
玄貓曾經參與一個遠端轉型專案，團隊最初擔心生產力下降，但透過重新評估工作優先順序，他們發現自己能夠更專注於真正重要的任務，最終交付了比辦公室工作時更高品質的產品。
建立心理空間：個人與團隊彈性的基礎
超越機械式方法的問題解決需要創造力，而創造力需要自由空間才能發生。理解、同理心和同情心都需要超越個人直接環境限制的能力。這種額外的自由空間，這種額外的能力就是「邊界空間」（margin）。邊界空間是我們的負載與極限之間的空間。
個人層面的邊界空間
在個人層面上，邊界空間對生存至關重要。生命最基本的方面之一是呼吸，而呼吸只有在橫膈膜和肋骨的肌肉創造空間時才會發生——膨脹肺部並吸入空氣。
2020年的疫情和社會動盪突顯了環境壓力對幾乎每個人的影響。這是異位負荷（allostatic load）概念的有力說明，即面對環境不確定性時的廣泛壓力反應。當人們不得不應對增加的環境壓力源時，他們從事其他活動的能力——他們的邊界空間——已經被削弱。隨著不確定性持續時間更長或更強烈，人們的精神和身體儲備被更深地耗盡。
建立與維護個人邊界空間
為了對抗這種環境不確定性，進行更新活動很重要：休息、改變環境和運動。就像呼吸的節律方面一樣，參與和脫離工作以及注意力的努力對心理和身體健康很重要。如果你不創造和維護個人邊界空間，你將走上精疲力竭的道路。
玄貓認為，在高壓的SRE工作中，定期的「思考時間」至關重要。在我的日程表中，我會特意安排30分鐘的無幹擾思考時間，這些時間沒有會議、沒有通知、甚至沒有特定的任務。這種看似「浪費」的時間，往往是我獲得最深刻技術洞見的時刻。
邊界空間與創新
從精疲力竭的負面影響的另一面，你可以找到在半約束空間中蓬勃發展的創造力的好處。為無意識心靈生成洞見創造空間，這就是為什麼休息和環境變化如此有價值。
許多戲劇性洞見的例子來自於人們將注意力從特定問題上轉移，並從另一個來源找到洞見，例如阿基米德在洗澡時突然想到如何測量國王冠的金含量而喊出「尤里卡！」的洞見。
最近的神經科學研究假設，專注思考特定問題可能會導致類別似於Troxler效應的現象，即注視的焦點消失。休息可以讓大腦轉換視角。給自己時間思考。你的個人可靠性取決於你為確保有效思考而創造的空間。
SRE實踐中的邊界空間：學習預算
在站點可靠性工程（SRE）的實踐中，我們有一個關鍵概念，稱為服務水平目標（SLO）——服務回應方式的明確目標，但可能更重要的是剩餘的額外部分。這通常被稱為錯誤預算（error budget），但將其視為學習預算會更有幫助。
我們可以將這個概念擴充套件到我們自己身上。就像事故是對理解系統的計劃外投資一樣，學習預算是你探索新的、創造性的方法的地方。彈性的關鍵是建立和培養這種適應能力，它存在於這個空間中。
玄貓曾參與設計一個關鍵基礎設施系統，團隊明確將10%的工程時間分配為「探索時間」，工程師可以自由研究任何他們感興趣的系統改進。這個看似「浪費」的時間最終產生了三項關鍵創新，大幅提高了系統的可靠性和效能。
建立高效遠端團隊的整合策略
結合以上所有元素，玄貓提出以下建立高效遠端SRE團隊的整合策略：
制度化的導師計劃
建立明確的導師配對機制，為新加入成員提供技術和文化引導，加速他們達到團隊的「人性基準線」。
結構化的社交連線
定期安排非工作性質的團隊活動，但避免強制參與。這些活動應當多樣化，照顧到不同性格和興趣的團隊成員。
明確的優先順序框架
為團隊提供清晰的工作優先順序框架，幫助成員在遠端工作環境中做出一致的決策。
個人邊界空間保障
尊重並保護團隊成員的個人時間和心理空間，鼓勵定期休息和充電。
學習預算分配
明確分配時間用於探索和學習，並將這部分時間視為對團隊長期健康和創新能力的投資。
遠端工作模式下的高效SRE團隊並非僅靠工具和流程就能建立，它需要深入理解人性需求，平衡個人空間與團隊連線，同時保持對真正重要任務的專注。透過這種平衡，我們不僅能維持生產力，還能創造更具彈性和創新能力的團隊文化。
在技術快速變革的時代，最成功的SRE團隊往往不是那些擁有最先進工具的團隊，而是那些最善於照顧其成員心理健康，同時保持清晰任務焦點的團隊。這種平衡的藝術，是現代SRE長官者必須掌握的核心技能。
系統緩衝空間：效率與彈性的平衡藝術
在系統可靠性工程領域，我們經常討論如何開發高效系統，追求資源的最大化利用。然而，過度追求效率可能導致系統脆弱，缺乏應對變化和不確定性的能力。Lawrence Wilkinson 在談到「健壯性」時指出：「健壯的系統意味著靈活性、適應性和學習傾向…以及『彈性』…最困難的往往是需要犧牲至少一部分效率來創造餘裕，即回應所需的空間…也就是說，有效運作的能力。」
這段話道出了一個核心真理：在系統設計中，預留緩衝空間不是浪費，而是應對不確定性的必要投資。多年來，我在設計和維護複雜系統時反覆驗證了這一點—系統的彈性和長期穩定性往往來自於有意識地預留的餘裕。
系統中的緩衝餘裕：不確定性的盾牌
緩衝空間是處理不確定性的工具，也是管理技術或人力系統時需要平衡的多重目標之一。從心理學到機械工程，從佇列理論到可靠性工程，系統的適應能力（有時甚至是基本功能）都關鍵性地依賴於系統中的時間和空間緩衝。
網路工程中的緩衝實踐
網路工程提供了緩衝計算成為標準實踐的絕佳例子。確保路徑中的每個網路連線都具有超出預期頻寬使用量的額外容量，是管理網路效能的關鍵部分。
傳統經驗法則建議在任何鏈路平均使用率達到50%時進行升級。這部分考慮了採購過程中的前置時間，但也是為了優雅地處理不可預測的瞬時流量峰值。
隨著QOS（服務品質）優先順序等措施的應用，網路工程師現在可以將平均使用率提高到70-80%的範圍，前提是他們對透過鏈路的流量有充分了解。不確定性越低，所需的緩衝空間就越小。但如果平均使用率遠超這些水平，延遲和資料包丟失將迅速增加到不可接受的水平。
我曾經負責一個電子商務平台的網路架構，在設計初期，團隊有成員主張將網路利用率推至85%以上，以節省基礎設施成本。經過激烈討論，我堅持保留至少25%的緩衝，結果證明這一決定在黑色星期五銷售高峰期間挽救了我們—流量暴增超出預期40%，但系統依然保持了穩定執行，競爭對手則因網路擁塞導致服務中斷。
醫院手術室的排程啟示
佇列理論的基本原理不僅適用於網路工程，還適用於多個領域。例如，醫院手術室排程的大量研究旨在確定最佳平衡點，以在面對病人取消、手術時間不確定以及非常昂貴的裝置和人員資源時，實作最佳利用率。
如果你曾經遇到過不可接受的長時間等待醫生的情況，很可能是因為他們被過度安排，缺乏緩衝空間導致服務延遲。這種現象在技術系統中同樣常見—過度最佳化的系統往往在壓力下當機。
團隊工作中的緩衝空間
與網路和手術室一樣，團隊在過度安排時也會遇到問題。這是 Dominica DeGrandis 在《使工作可見》一書中的核心原則。團隊的負載經常被忽視。沒有對團隊工作負載的完整了解，他們（或其管理階層）無法在保留必要的學習和處理意外變化的空間的同時，適當地分配任務。
Avery Pennarun 和 Will Larson 各自開發了模擬，展示了團隊生產力（即交付給終端使用者的價值）如何在目標變化和任務過多的情況下波動。這些模擬突出了適當數量的緩衝空間的重要性。在面臨更大的不確定性時，需要更多的緩衝空間來保持團隊有效生產。
在我帶領的一個開發團隊中，我們實施了「緩衝日」政策—每個衝刺週期中預留20%的時間用於處理意外問題、技術債務和團隊學習。這一做法最初遭到了產品管理的質疑，他們擔心會減少功能交付。然而六個月後的資料顯示，我們的實際交付速度提高了15%，同時緊急修復減少了近40%。這證明瞭適當的緩衝不僅不會降低生產力，反而能提高整體效能。
緩衝空間的平衡藝術
緩衝空間的多少取決於系統。沒有足夠的緩衝空間，系統會在最輕微的幹擾導致廣泛的系統性失敗時束手無策，因為沒有適應能力。有太多緩衝空間，系統將無法達到最大生產力，因為工作會消散在系統內的空隙中。
當我們處理複雜、分散的社會技術系統時，需要不斷重新評估約束和自由度之間的平衡，以最佳化團隊和系統的輸出。這是一門藝術，也是科學，需要持續的觀察和調整。
餐巾紙計演算法：工程師的快速估算技巧
在討論系統緩衝空間時，我們經常需要進行快速估算來評估不同選項的可行性。這就是「餐巾紙計演算法」（Napkin Math）的價值所在。
餐巾紙計演算法是一個進行計算的過程，當你無法（或不需要）收集確切細節時，它能提供在一個數量級精確度範圍內的答案，而不是依靠使用複雜的假設。這對於在不花費數小時或數天進行更複雜計算的情況下，確認選項的可行性或縮小可能性的範圍非常有用。
費米問題與芝加哥鋼琴調音師
這類別估算問題正式稱為費米問題。一個著名的例子是估計特定城市中的鋼琴調音師數量。
假設芝加哥有300萬人口，每個家庭平均有兩個人。假設每20個家庭中有一個擁有鋼琴，並且它每年只需要調音一次。猜測鋼琴調音師每天工作8小時，每週5天，每年50週（即250天），每架鋼琴調音需要2小時。
從這裡，我們可以快速計算出以下內容：
- 假設芝加哥人口約為300萬
- 芝加哥每個家庭平均有2人
- (1,500,000個家庭)/(20個家庭擁有一架鋼琴)=芝加哥有75,000架鋼琴
- (每天8小時)/(調音需要2小時)×(每年250天)=每年調音1,000架鋼琴
- (芝加哥的75,000架鋼琴)/(每年調音1,000架鋼琴)=芝加哥有75名鋼琴調音師
當然，芝加哥很可能沒有恰好75名鋼琴調音師；然而，我們現在也知道，芝加哥不太可能有1,000甚至10,000名鋼琴調音師。
資料中心遷移估算例項
讓我們將這種方法應用到技術領域。例如，你想知道將資料從位於美國東海岸的資料中心移動到位於西海岸的另一個資料中心需要多長時間。這裡，我們可以使用簡化的表示：
- 網路傳輸：每GiB 60毫秒
- 硬碟讀取（傳送）：每GiB 200毫秒
- 硬碟寫入（接收）：每GiB 1秒
使用每GiB 1.5秒作為綜合簡化時間跨度，你可以將其乘以資料儲存的大小，就得到了答案！這個結果不會精確，但它給出了實際結果的數量級估計—足以確定這種方法的可行性。
在一次大型資料函式庫專案中，我使用這種方法快速評估了三種不同的遷移策略。傳統方法會要求我們進行詳細的POC測試，耗時數週。而透過餐巾紙計算，我在一個下午內就確定了最佳方案，並將結果提交給了管理階層。最終實際遷移時間與估算相差不到20%，而我們節省了至少兩週的評估時間。
餐巾紙計算的價值
你開始看到收集高層次計算估計的好處，因為它的應用範圍廣泛，允許你使用看似不可能的計算最終得到實際答案的數量級內的估計。
這裡的快速移動能力至關重要，因為它意味著你可以快速進行多次計算來嘗試一系列選項。這保持了頭腦風暴所需的動力，而不會陷入細節的泥潭。
推動DevOps文化變革：巧妙的策略
在討論系統緩衝空間和快速估算的同時，值得一提的是如何將這些理念融入組織文化。推動DevOps文化變革需要對事業有熱情，同時也需要有足夠的耐心，知道人們需要一段時間來適應。
正如紐約時報的Vinessa Wan所說：「推動文化變革意味著你必須對事業有強烈的投入。把握每一個機會來宣揚價值，即使這意味著要有點狡猾。任何曾經偷把蔬菜放進孩子食物中的父母都知道我在說什麼。」
這種方法看似欺騙，但實際上是理解變革過程的務實方法。在理想世界中，我們應該公開宣佈我們都將致力於可靠性，並讓我們的長官層知道要優先考慮它。但在現實中，推動文化變革意味著你不僅要對願景充滿熱情，還要有足夠的耐心，知道人們在一段時間內需要「訓練輪」。
DevOps文化意味著它融入我們所做的一切。它不僅是將其視為特殊事物，而是使其成為我們DNA的一部分。這就是為什麼我們將選舉準備工作—包括全球都知道的那個選舉指標—的重點不僅放在單一的夜晚，而是放在如何為建立操作基礎奠定基礎。
系統緩衝空間與組織文化的交匯
將緩衝空間的概念與DevOps文化相結合，我們可以看到一個強大的協同效應。在組織中建立對緩衝空間重要性的理解，可以幫助團隊更好地規劃，更有效地應對不確定性，並最終建立更具彈性的系統。
這並不意味著我們應該過度擴張資源或接受低效率。相反，這是關於明智地管理資源，認識到某些冗餘和緩衝是健康系統的必要部分，而不是浪費。
在我指導的一個架構師團隊中，我們將「緩衝思維」作為架構審查的標準部分。每個系統設計都必須回答：「當需求是預期的兩倍時會發生什麼？當關鍵依賴項失敗時會發生什麼？」這些問題迫使設計師考慮緩衝空間，而不僅是最佳情況下的效率。
技術長官者的職責是在效率和彈性之間找到平衡點，並培養一種理解這種平衡重要性的文化。透過結合餐巾紙計算等實用工具和對適當緩衝空間重要性的深刻理解，我們可以建立既高效又有彈性的系統。
當我們處理複雜的、分散的社會技術系統時，
以體驗為中心：重新思考系統韌性設計
在傳統的IT架構設計中，我們常以應用程式為基礎單位來規劃系統。然而，這種思維方式可能會忽略最重要的一點：使用者的真實體驗。在多年的系統架構設計實踐中，玄貓發現，將視角轉向「關鍵工作流程」或「關鍵使用者經驗」能夠徹底改變我們構建可靠系統的方式。
從應用到工作流程的思維轉變
與其列出所有應用程式，我們應該先識別關鍵工作流程和使用者經驗。在新聞媒體行業的案例中，主要使用者（或內部所稱的「內部客戶」）包括編輯部門、讀者和業務人員。一個工作流程範例可能是「編輯部門能夠在網站上發布文章」。
這種以工作流程為中心的方法有兩大優勢：
- 讓我們專注於客戶的整體驗，而非僅關注特定團隊的表現
- 確保公司所有人員對系統理解保持一致
當採用這種方法時，我們接著會識別每個工作流程所需的系統。支援某一功能的系統可能橫跨多個團隊甚至部門，但這不應該成為障礙。
建立分級關鍵性模型
一旦識別出工作流程及其相關系統，下一步就是為每個工作流程和系統分配關鍵性等級。我們為每個關鍵性級別建立明確的期望標準。這種結合工作流程視角的方法使我們能夠同時從工作流程和系統層面評估韌性，個別團隊不再需要獨自承擔全部責任。
架構審查與成熟度評估
為了確保系統韌性，我們實施了幾項關鍵實踐：
架構審查：與團隊一起進行架構的詳細評估，識別潛在風險區域，清查操作手冊，瞭解系統之間的協作方式。
營運成熟度模型：引導團隊透過營運成熟度模型評估，包括服務供應和下線、容量規劃等實踐。這幫助團隊明確他們可以集中精力的領域，並對應用程式的可靠性產生最大影響。
生產環境效能測試：定期在生產環境中進行效能測試，測量系統和團隊如何處理負載增加或各種情境。測試後，我們會舉行學習回顧會，梳理時間線並確定改進方向。
這些做法可能看起來不那麼「閃亮」，但這正是它們的意圖。就像蔬菜一樣，它們是必要的營養——做得好的蔬菜也是美味的。有時蔬菜是主角，有時它們是優秀的配角。
透過影響力驅動變革
在推動系統韌性時，不必總是居於中心位置，有時與那些處於中心的團隊合作並引導他們，是透過影響力驅動變革的重要因素。
SRE團隊就像網站和應用的舞台工作人員。成功的衡量標準不僅是一個事件的表現——作為一個組織，我們還有很長的路要走，還有很多要學習——但上述實踐和流程讓我們能夠關注超越單一事件的範圍。
當使用者感覺不到我們的存在時，那就是我們的成功。在這個充滿新聞的時期，我們的網站持續提供可靠的使用者經驗，與我們的新聞報導品質相比對。對於一個有著超過100年歷史的組織來說，這已經相當不錯了。
在企業中推動SRE文化變革
理解變革的挑戰
大多數成熟的組織都有根深蒂固的實踐、工具和流程。引入SRE意味著要克服慣性，需要大量時間進行教育，以及持續強化實踐和行為。
在大型組織中，變革特別困難。試圖過快地改變太多事物可能導致混亂並引起懷疑。人類本能地傾向於習慣——突然改變常規並在舒適區之外運作通常會引起初始的懷疑。大多數文化變革也是迭代的，不太可能從一開始就完美，所以如果人們遇到不好的體驗，或者第一次嘗試時事情沒有按預期進行，負面觀感可能很快在整個組織中傳播。
專注於關鍵行為變革
為了避免這種情況，最初應該專注於少數最關鍵的行為調整。換句話說，找出在你的工作場所成功實施SRE的關鍵障礙。例如，如果開發者和SRE之間不存在分享責任模型，那麼也許應該從這裡開始，因為這是獲得正確SRE的基礎。
確定關注領域後，決定如何最好地促進行為變革。當公司沒有相應的工具時，要求所有服務都有SLO（服務水平目標）是沒有用的；當不存在討論事故的論壇時，強制要求無責備的事後分析也是徒勞的。重要的是識別差距所在，然後建立清晰的路線圖，首先奠定必要的基礎。
如果你有與你希望工程師採用的行為相符的有效工具和流程，這最終將成為常規，並隨著時間的推移自然導致思維和文化的改變。
以人為本的變革方法
文化變革關乎人而非系統，因此不能用與構建軟體相同的思維方式來處理。一個由明星SRE組成的團隊並不能保證成功。除了徵才和培訓SRE外，還要在組織中識別那些擅長賦能他人和建立信任的文化載體。教導他們技能，幫助他們在整個組織中傳播意識和知識。
當我們觀察和與那些以身作則的人一起工作時，我們更有可能接受變革，而不是從象牙塔收到指令。各個層級的人都需要參與，因為文化轉變不太可能僅是一個人的責任，或者是一個人能夠做對的事情。
高層支援與透明度
自上而下的命令很少能成功驅動大型組織的長期行為變化。然而，高管確實在確保組織理解變革的重要性並保持專注方面發揮著巨大作用，定期的自上而下的溝通是實作這一目標的關鍵。
提供透明度和識別正確的激勵措施對於任何大規模變革計劃的成功至關重要。人們需要看到並相信變革的價值才能堅持下去。要慎重考慮哪些結果重要，哪些指標反映了行為變化的成功。
例如，如果你希望鼓勵事後分析以遏制重複問題並降低風險，行為變化和成功的真正指標將是工程師是否跟進並完成行動專案。測量這些指標並就激勵結構達成一致，以獎勵模範行為，例如使用錯誤預算驅動決策的團隊，或那些在整個組織中培養無責備文化的團隊。
當每個人都認同並同意投資於一個策略時，可能會有這樣的信念：正確實施這一策略將使組織變得更好，每個人都會因此受益。建立SRE思維和其實踐是任何SRE團隊長期、可持續成功的基礎。
安全工程師對SRE的思考
我們都曾遇到過倉促推出但可靠性存疑的應用程式。當這些應用程式不可避免地經歷第一次故障，而我們被叫來幫助提高應用程式可靠性時，我們的生活變得更加艱難。我們並不驚訝，但希望能夠參與到應用程式的設計和規劃中，使可靠性成為首要考量。這是完全可以避免的——而與它會讓我們感到筋疲力盡。
作為一名曾經的SRE，現在迴歸到安全領域的工程師，我獲得了一個重要洞察：安全對SRE的關係，就像SRE對產品團隊的關係。我們在這裡是為了支援你保持系統安全、執行並最終可靠。某種程度上，我們是你的SRE團隊。然而，你們經常用單一思維的產品團隊對待SRE的方式來對待我們。
我聽過這些抱怨。你們覺得我們因為多疑和總是考慮最壞情況而拖慢了你們的速度。更糟糕的是，我們甚至沒有好的資料來說服你這是值得的。我們不能說，“你需要更新這個函式庫則伺服器會被駭客攻擊。”
為下一次DDoS攻擊（分散式拒絕服務）或突發銷售擴充套件伺服器是非常直觀的。檢視單個例項可以處理多少連線，檢視上次有多少人嘗試連線，然後擴充套件超過這個數量。作為安全工程師，我無法指出某個特定的CVE（通用漏洞暴露）並確定它會被利用。
構建更強韌的系統：實踐中的教訓
在多年的系統可靠性工程實踐中，我總結了幾點關鍵教訓：
首先，系統韌性不僅是技術問題，更是一個組織和文化問題。當我們將焦點從單一應用轉向整體工作流程時，我們能夠更全面地理解系統的相互依賴性和潛在的失效點。
其次，變革需要耐心和策略。在一家大型媒體公司實施系統韌性改造時，我發現最有效的方法是選擇一個關鍵工作流程作為試點，取得成功後再逐步擴充套件。急於求成往往會導致團隊倦怠和抵抗。
第三，資料驅動的決策至關重要。當我們建立了明確的SLO（服務水平目標）和錯誤預算後，團隊間的討論從主觀意見轉變為根據資料的決策，大減少了摩擦。
最後，真正的系統韌性來自於持續學習的文化。透過無責備的事後分析，我們不僅解決了當前問題，更重要的是預防了未來可能發生的類別似問題，形成了一個正向的改進迴圈。
在技術快速發展的今天，我們需要的不只是可靠的系統，更需要能夠從失敗中學習和進化的系統及團隊。這正是SRE實踐的核心價值所在。
系統韌性設計是一場馬拉松，不是短跑。透過專注於使用者經驗、建立跨團隊協作模式、實施漸進式文化變革，並保持資料驅動的決策過程，我們能夠構建出既可靠又適應性強的系統，為使用者提供持續穩定的服務體驗。
