優先處理:SRE時間管理的藝術
完成評估後，選擇一些任務著手進行。你希望在有限的時間內獲得最大的改進。為了確保穩定進展，可以每週安排兩小時專門處理這些任務。確保你的主管同意你把時間花在這上面。不要被大量待辦工作壓垮，也不要試圖承擔另一份全職工作的責任。這會增加你精疲力竭的風險，並降低公司為你提供更多SRE資源的可能性。
玄貓在擔任獨立SRE時發現，關鍵在於找到高影響力的小改進，而不是嘗試一次性解決所有問題。例如，我曾在一家中型企業中實施了這個簡單的SRE任務優先順序矩陣：
優先順序矩陣 = 影響範圍 × 實施難度 × 維護成本
影響範圍:
- 高(3): 影響所有服務或關鍵業務功能
- 中(2): 影響多個服務或非關鍵功能
- 低(1): 影響單一非關鍵服務
實施難度:
- 低(3): 可在一週內完成
- 中(2): 需要1-4週完成
- 高(1): 需要1個月以上
維護成本:
- 低(3): 實施後幾乎不需維護
- 中(2): 需要定期維護
- 高(1): 需要持續維護
使用這個矩陣，我可以快速評估和優先處理各種SRE改進任務。例如，實施基本監控（高影響、低難度、低維護）得分為3×3×3=27，而重構整個CI/CD流程（高影響、高難度、中維護）得分為3×1×2=6。這種方法使我能夠專注於高價值、低成本的改進。
接受不完美的現實
你無法修復所有問題。即使有一個完整的SRE團隊，這也是不可能的！我們的目標不是追求完美，而是追求更好。你是在一次一個任務地將SRE引入公司，使事情變得更好。只要堅持下去，就會成功！不要壓力太大。系統總會出現問題，這是工程的正常部分。這不是你的主要工作，即使你獲得批准減少其他任務，也不可能修復所有問題，即使有一個完整的SRE工程師團隊也是如此！
事件應變：從零開始建立有效框架
現有事件應變計劃的常見問題
很有可能，你的事件應變計劃看起來像這樣：
- 有人收到警示（可能是你！）
- ???
- 解決問題
這是在許多情況下自然形成的計劃。隨著組織和系統的成長—無論是在操作它的人數、服務的使用者數量還是其複雜性方面—該計劃不再適用。作為SRE或維運團隊的一員，你可以關注以下一些跡象：
- 不確定如何啟動事件處理
- 不知道如何或何時讓更多人參與
- 不知道是否開始通話、會議橋接或使用聊天工具
- 沒有一致的方式通知可能受事件影響的人
- 在處理事件時，不清楚誰在做什麼
事件本質上是一個令人驚訝的事件，是認知上困難的任務。無法回答這些問題會在事件中引入更多不確定性，可能代價高昂。回應人員不是直接調查和解決事件的謎題，而是試圖從頭開始弄清如何協調，而不是解決問題。結果是回應人員分散注意力，停機時間延長。
從小處著手建立事件應變框架
改變這種模式可能很困難。尤其是在最近發生許多事件的情況下，可能很難找到時間或空間來學習或制定新計劃。幸運的是，可以從小處著手。如何從即興應對轉向在框架內運作？採取小步驟，理解在處理複雜、不可預測的事物時，計劃無法規定一切。你永遠不知道可能發生什麼類別的事件，因為你無法預測未來，所以投資事件應變框架有助於將注意力從需要在當下做出的許多小決定轉移到事件本身的謎題上。
在與各種組織的許多團隊合作後，玄貓發現一個很好的起點是考慮三個角色：事件管理員、工作者/操作員和通訊員。如果你是被呼叫的人，在你回答的那一刻，你就承擔了所有這些角色。任何時候你沒有人填補某個角色，你就填補它。除了事件管理員，你可以有任何數量的其他角色，只要合理；通常，這只適用於工作者/操作員角色，但有些人喜歡分開內部和外部通訊。
玄貓曾在一家電商平台實施了一個簡單的事件應變範本，顯著提高了團隊的應對效率：
事件應變檔案
角色分配
事件管理員
- 負責人: [填寫姓名]
- 備份: [填寫備份人員]
事故管理：可觀察性之後的自然程式
事故管理是可觀察性之後的自然延伸 — 畢竟，你必須先能夠偵測到事故，才能進行管理。當系統出現問題時，一個結構化與定義明確的事故管理流程能讓團隊迅速應對，將損失降到最低。
建立結構化的事故管理流程
事故管理的核心在於建立一套明確的流程，並輔以詳盡的檔案支援，例如故障處理手冊(runbook)，提供如何處理故障服務的具體指導。在我設計事故管理系統時，發現最關鍵的是定義清晰的角色和責任，這能確保每個人在壓力下也知道自己該做什麼。
一個完整的事故管理流程應包含以下要素：
角色與責任明確化
典型的事故管理角色包括：
- 事故指揮官(Incident Commander) - 負責協調整體應對工作
- 技術負責人(Technical Lead) - 專注於技術問題的解決
- 通訊負責人(Communications Lead) - 管理內外部溝通
根據組織規模和事故嚴重性，這些角色可能由一人身兼數職，或由不同人員分擔。我曾在小型新創公司工作時一人扮演多個角色，但在處理大規模事故時，將責任分散給專門的團隊成員效果更佳。
避免測試與發布流程不足
不充分的測試和發布流程常是事故的根源，也會在事故發生時不必要地延長解決時間。這通常源於流程缺乏可重複性，過度依賴容易出錯與耗時的手動操作。
我發現尋找自動化機會是提高可重複性並縮短操作時間的絕佳方式。例如，自動化佈署流程可以將原本需要一小時的發布時間縮短至幾分鐘，同時大幅降低人為錯誤風險。
從小處著手，循序漸進
作為SRE實踐者，最重要的是從小處著手，快速取得一些成功案例。這樣你將能夠透過漸進式變革展示SRE的積極效益，並減少工程師日常的繁瑣工作。
當我剛開始推動SRE文化時，先選擇了一個頻繁造成值班警示的系統進行改進。透過自動化故障處理流程，我們將平均修復時間從幾小時減少到幾分鐘。這個小勝利為團隊帶來了信心，也讓更多人願意參與SRE實踐。
展示這種積極變化並讓其他人參與過程中是培養SRE文化的重要一步。很快，你會發現越來越多的工程師願意學習並接受你正在建立的SRE文化。
獨行SRE的重要提醒
作為獨行SRE，最重要的是記住：雖然你可以在組織內推動變革，但你無法獨自完成一切，所以不要試圖僅靠自己的肩膀承擔組織所有問題的重量。
對自己和組織最糟糕的做法是試圖將所有責任都攬在自己身上。在某些極端情況下，這可能導致職業倦怠。你的心理健康至關重要，請記住這一點！
SLO測量的設計目標
設計服務水平目標(SLO)測量系統時，需要考慮彈性、可測試性、時效性、成本、可靠性以及組織限制等目標。讓我分享如何運用這些原則來構建有效的SLO系統。
彈性目標：適應不斷變化的需求
SLO必須能夠隨時間演變。有時這只是為了調整錯誤預算，以允許更多發布和更快的產品迭代。
在設計SLO系統時，操作人員應該能夠調整嵌入在服務水平指標(SLI)中的引數，例如將回應時間從25毫秒調整到30毫秒，成功閾值從95%提高到97%，或聚合視窗從過去30秒改為過去7天，所有這些都不需要更改程式碼、重新佈署軟體或推播新的生產設定。
此外，目標修訂前後的SLO效能歷史應該保留，並提供檢視每個目標如何隨時間變化的方法。這對於理解長期趨勢至關重要。
可測試目標：驗證SLO有效性
新增SLO時，我們需要同時定義SLI和目標。制定適當的目標通常非常微妙與具有挑戰性。
- 考慮我們的可靠性歷史，什麼是合適的錯誤預算？
- 應該測量哪個延遲百分位數？
- 實際的延遲閾值應該是多少？
每當SLO需要更新時，這些問題都應該重新考慮。為了對SLO有信心，特別是當SLO涉及告警時，應該對可能的目標進行回測，利用歷史資料來驗證，並在設定閾值時估計告警頻率。
時效性：反映實時資料的速度
時效性衡量的是SLO反映生產環境實時資料所需的時間。從時效性角度來看，時間延遲越低越好，但實際的時效性需求取決於特定的SLO用途。
某些SLO可能只用於月度管理報告，此時SLO是否包含最近30秒的資料並不重要。而在其他情況下，SLO可能是業務關鍵生產環境故障排除的第一道防線；那麼，時效性應該以秒為單位測量，資料處理延遲應保持最小。
成本考量：平衡投資與收益
實作彈性、可測試與時效性好的SLO在無限預算下當然更容易，但有效的組織範圍SLO的資料工程需求可能相當龐大，尤其是對於高吞吐量或廣泛分佈的應用。
雖然不必也不現實地估算成本到多個小數位，但透過提前考慮以下三個方面，應該可以在10倍範圍內得到估算：
- 時間序列資料儲存與處理
- 結構化日誌資料管理
- 機會成本評估
SLO基礎設施的可靠性
就像單個服務有SLO一樣，SLO基礎設施本身也必須有SLO！應該在現有的高用性可觀察性元件之上或內部實作SLO。
有時候，SLO是透過不穩定的指令碼或監控不良的計劃任務實作的，這會引入風險和不可靠性。如果需要建立全新的基礎設施來實作某些高優先順序SLO，那麼就這樣做吧—但要提前規劃並分配時間，使新建的基礎設施高度可用。SLO基礎設施必須是組織在生產環境中執行的最可靠軟體之一。
組織限制：非技術因素的影響
組織通常會帶來超出技術或預算考量的限制。例如，某些高度監管行業的組織仍然要求所有營運資料留在本地，存放在物理資料中心或組織的虛擬私有雲中。
在其他情況下，組織為了對抗資料孤島，可能要求所有持久的時間序列資料或所有結構化日誌資料都儲存在特定資料函式庫使用特定供應商。
這些目標並非詳盡無遺，但考慮並解決這些問題將使你的SLO實作更加完善！記住這只是一個模型；你必須做對你、你的系統和你的使用者最有效的事情。
錯誤預算的實際應用
SLI、SLO和錯誤預算是網站可靠性工程的根本。關於它們是什麼已經有很多文章，但關於如何使用它們的文章卻不多。“當你有錯誤預算時發布功能；當預算耗盡時停止發布並專注於可靠性"這種經典例子有些古老，並沒有真正揭示你可以用資料做出的所有決策。
超越傳統應用：錯誤預算的多樣化用途
如果錯誤預算不僅關乎是否發布新功能，我們還能用它做什麼？
首先，我必須提到，你確實可以使用錯誤預算來決定何時發布新功能。程式碼或設定的變更是新問題最常見的來源，因此有時候說"讓我們放慢腳步，找出如何使系統更穩定"確實是完全合理的。但讓我們花些時間討論使用錯誤預算資料可以做出的其他決策。
確定專案工作重點
錯誤預算資料的一個更合理用途是確定專案工作的重點。根據SLO的可靠性方法是為你提供更好的資料，以進行更好的討論並做出更好的決策。
在許多情況下，關於何時發布程式碼的硬性規定可能沒有太大意義，但使用這些資料來幫助你確定團隊應該專注於什麼確實很有意義！你不必停止發布流程，就能說：“我們的不可靠性超出了我們的目標—也許在下一個衝刺中，一半團隊專注於修復這個問題，而不是功能開發。”
當玄貓處理一個大型電商平台的可靠性問題時，我們使用錯誤預算資料來平衡功能開發與穩定性工作。透過將團隊工作時間按80/20比例分配給穩定性和新功能，我們在三個月內將系統可靠性從99.5%提高到99.9%，同時仍然保持了產品的競爭力。
驅動架構決策
錯誤預算還可以驅動更大型的架構決策。例如，如果你發現特定服務或功能持續消耗錯誤預算，這可能表明需要進行更深層次的架構變更，而不僅是表面修復。
在一個專案中，我們注意到認證服務經常出現問題。透過分析錯誤預算消耗模式，我們決定將其重構為更可靠的微服務架構，而不是繼續進行增量修復。這個決策最終使該元件的可靠性提高了近乎100倍。
錯誤預算：不只是一個數字
錯誤預算不僅是一個單一數字。深入瞭解預算消耗的方式和原因，可以幫助你做出更明智的決策。
例如，如果你的錯誤預算主要因為佈署問題而消耗，那麼改進CI/CD流程可能是最佳解決方案。如果消耗主要發生在特定時間或特定負載下，那麼可能需要改進容量規劃或自動擴充套件策略。
玄貓建議將錯誤預算視為針，而不是硬性規則。它應該指導你的決策，但不應成為唯一的決策因素。在實際操作中，我發現結合錯誤預算資料與團隊經驗和業務優先順序，能夠做出最平衡的決策。
SRE實踐中的平衡藝術
SRE的核心是找到可靠性與創新之間的平衡。無論是事故管理、SLO設計還是錯誤預算應用，都需要考慮技術與業務之間的平衡。
技術卓越與業務需求
在追求技術卓越的同時，我們不能忘記業務需求。100%的可靠性在理論上很美好，但實際上可能會導致創新停滯。
我曾與一家金融科技公司合作，他們將SLO設定為99.999%的可用性，結果導致幾乎無法發布新功能。透過重新評估業務需求，我們將SLO調整為99.95%，這為產品團隊提供了足夠的錯誤預算來推動創新，同時仍然維持了使用者滿意的可靠性水平。
培養SRE文化
SRE不僅是一套工具和流程，更是一種文化。
透過主動變更理解系統：SRE的探索思維
系統的本質只有在變化中才會顯露。作為SRE工程師，我們需要主動引入變化，而非被動等待系統出問題。這種主動探索的方法能幫助我們更深入地理解系統行為，並在真正的事故發生前發現潛在問題。
有目的地引入變化
有目的地引入變化是一種強大的學習工具。這些變化可以是：
- 混沌工程實驗：隨機終止服務例項，觀察系統如何應對
- 容錯移轉演練：模擬主要系統故障，測試備份系統能否順利接管
- 演算法與設定實驗：嘗試不同的垃圾回收方法或新演算法，測量效能變化
在玄貓的實踐中，我發現這些實驗不僅能驗證系統的彈性，還能發現檔案中未記載的依賴關係和假設。例如，在一次計劃內的區域容錯移轉測試中，我們發現某些客戶端程式碼並未正確實作重試邏輯，這在正常執行時完全不會顯露出來。
錯誤預算的戰略運用
錯誤預算是決定何時進行這些實驗的重要指標。錯誤預算的本質是讓團隊對可靠性與創新進行平衡權衡：
- 如果最近系統不太可靠，已經消耗了大部分錯誤預算，暫時推遲實驗可能是明智之舉
- 若有大量剩餘錯誤預算，這正是進行實驗的絕佳時機
刻意消耗錯誤預算
這聽起來可能有些反直覺，但有時刻意消耗剩餘的錯誤預算也是一種策略。如果其他服務依賴於你的服務，你需要確保自己的服務不會比宣稱的更可靠。有計劃地讓服務短暫離線，可以幫助依賴你服務的團隊學習如何在你不可靠時應對。
這種做法看似激進，但能有效防止依賴服務對你的系統產生過度依賴，形成脆弱的單點故障。在我參與的一個微服務架構中，我們每季度會安排一次"計劃性降級”，這幫助下游服務團隊建立了更健壯的錯誤處理機制，最終提高了整體系統的可靠性。
不做任何事情也是選擇
有時最佳策略是什麼也不做。如果有大量錯誤預算剩餘，而團隊面臨其他緊急優先事項，維持現狀可能是合理的選擇。相反，如果已經多次超出預算，可能是在等待新硬體到貨，或者是遇到了黑天鵝事件，此時轉向可靠性工作可能不是合理的選擇。
錯誤預算的價值在於提供更好的資料，幫助做出更明智的決策。若你有意義的SLI（服務水平指標）和合理的SLO（服務水平目標），錯誤預算資料能幫助你思考系統如何滿足使用者期望和需求。如何使用這些資料，取決於你的具體情境。
如何在組織中推動變革
作為SRE，你可能嘗試推動一個你確信對公司有益的計畫，但沒有其他團隊的支援和配合就無法完成—而現在，你兩者都沒有得到。
“理論上我們支援你，但我們沒有足夠的資源來配合。也許下季度吧。”
“這個變更沒必要，現在的方式已經足夠了。”
戰略性推動變革的步驟
如何推動這種變革？首先，這個變革必須對你來說足夠重要。不要為你不在意的事情付出這麼多努力。它必須能帶來全域性的改進，並且時機必須合適。
取得管理階層支援
如果你無法說服你的經理這個變更值得，那就停下來，選擇另一場戰鬥。它短期內不會發生。優雅地退讓，六個月後或任何減少阻力的情況出現時再重新考慮。你的經理不斷評估員工時間與任務價值的關係，所以尊重他們的決定。
下一步：向上走。你和你的經理需要與你經理的長官，如你的總監，進行會面。
- 解釋為什麼你想現在進行這項變更
- 列出變更的好處、風險和可能性
- 準備好討論影響
- 準備好妥協
- 討論為什麼其他團隊會反對
- 列出如果不進行這項變更的風險
- 有測試和佈署計畫
- 有回復步驟
取得高層支援
如果他們同意這是一件值得做的好事，討論組織阻力。阻力可能來自這位總監的同事或他們同事的下屬。
向上走還是橫向走？此時，你的總監可能會與他們的同事分享計畫。然而，如果你的總監認為來自某些其他總監的阻力可能很難克服，你可以再次向上走。該專案可能需要一位高管贊助，如VP（副執行長）或CTO（技術長）級別。
你的經理或總監論證案例。他們不會粉飾問題，而是討論解決這些問題的計畫。工程高管不太可能贊助一個引發地盤之爭並對工程內部關係產生負面影響的專案。
如果變更值得，時機適當，你展示了足夠的前瞻性規劃，與各種條件都對齊了，恭喜，你已獲得他們的贊助。
執行變更
現在怎麼辦？你再次向下一級。你的總監與其他總監開會，分享計畫，而高層贊助者說：“是的，這將會發生。“這次會議的結果應該意味著其他工程總監確信你和你的團隊將盡最大努力使這一切盡可能容易，但也明白變更是不可避免的，所以他們不妨接受它。
從一開始就對受影響的團隊表示理解。你必須讓每個人都盡可能容易地接受這個變更。在相關團隊方便的時間安排會議，聽取他們的擔憂和痛點。尊重他們的顧慮，集思廣益找出減輕障礙的方法。制定符合他們時間表的佈署計畫。
有效溝通
考慮如何向組織傳達變更。在變更發生前，向工程部門做一個演示，因為這將有助於減輕顧慮，幫助維持專案動力，並減少專案期間對協助請求的抵抗。
讓這成為一個提升所有人的專案，他們可能會讓你再次做類別似的事情！
玄貓在推動變革時學到的關鍵是：技術上的正確性只是成功的一半，另一半是人際關係和組織導航能力。即使最好的技術解決方案，如果沒有組織支援也無法實施。最終，SRE工作不僅是技術問題，更是人的問題。
結構化除錯方法論
SRE經常在生產環境中除錯—在壓力下，被資訊淹沒。除錯可能看起來像一種神秘的、與生俱來的特質，但幸運的是這是不正確的；相反，你可以遵循結構化的方法論過程來準確定位問題，避免錯誤和認知偏差。
分類別處理（Triage）
在處理事件時，我們首先必須快速做出一些元決策：業務影響是什麼？我們現在處理這個事件還是可以推遲？我們有時間除錯還是應該採用緊急容錯移轉程式？在開始除錯之前，許多答案是未知的。分類別是一個短暫的階段，在可能漫長的除錯過程開始前快速回答這些問題。然而，你可以在任何時候回到這一步：將分類別視為一個快速失敗步驟，在有更多資料時隨時可以回傳。
操作性定義（Operational definition）
要解決我們認為值得追求的問題，我們需要精確與可測量地定義它（“它很慢"是不夠的）。操作性定義有兩個主要部分：測量方法（即，從哪裡？用什麼工具？什麼時候？在哪個環境中？）和該測量的預期結果（例如，“交易X的p99持續超過500毫秒已經1小時了，應該低於100毫秒”）。這使我們能夠協作並驗證我們確實解決了我們正在處理的問題。
使系統的心智模型明確化
我們不立即知道什麼出了問題，這強烈表明我們對系統的心智模型不完整，甚至可能具有誤導性。我們的任務是逐步完善這個模型，直到它足夠接近現實來解釋問題。將模型寫下來，可以是圖表或文字（使用對你來說舒適的方式）。你可能會想跳過這一步；不要！寫作迫使你清晰表達你的模型，這有助於找出差距，更重要的是，使你的假設清晰，這樣你才能對它們進行迭代。
模型迭代
一旦我們有了明確的模型，我們可以對其進行迭代改進直到找到問題—這與科學方法沒有太大區別：提出假設，定義需要什麼資料來佐證或拒絕假設，收集這些資料，並評估它以決定是否應該拒絕假設。記住，我們的測量可能是錯誤的，我們可能被各種認知偏見誤導，或者我們可能只是受限於還原論思維的限制。
重建和驗證
重建階段基本上是我們在建立關於模型假設時所做分析的反向過程。我們不是將系統分解為部分和子系統，而是從我們假定的部分重建系統，使用我們擁有的測量結果，並詢問部分之和是否解釋了我們看到的系統—通常不是。我們可能缺少一個部分，或者我們在某個部分發現的故障與這個事件無關（某些東西總是在某處失敗！）。也可能是部分之間的互動解釋了我們正在經歷的事情，而不是任何單一部分。
在我處理的複雜系統問題中，這種方法論除錯方式已經幫助我找出了許多難以診斷的問題。例如，在一次關於API請求延遲突然增加的事件中，我們最初懷疑是後端服務出現問題。但透過明確操作定義、繪製系統心智模型並迭代假設，我們發現問題實際上來自於一個看似無關的網路設定變更，它改變了請求路由方式，導致某些請求繞道經過擁塞點。
系統可靠性工程不僅是維護現狀，更是透過深思熟慮的變革來推動系統和組織進步。從有目的地引入變化以理解系統行為，到戰略性地利用錯誤預算，再到在組織中有效推動變革，以及採用結構化的除錯方法論—這些都是SRE成功的關鍵要素。
透過主動探索系統行為、靈活運用錯誤預算、熟練導航組織政治，並採用系統性的問題解決方法，SRE可以不僅是維護者，更可以成為推動技術和組織進步的變革者。最終，SRE的價值不僅在於保持系統執行，還在於使系統和支援它的組織變得更好、更有彈性。
SRE思維：超越技術的客戶體驗導向
在科技產業中，有一個常見的誤解是將SRE(Site Reliability Engineering，網站可靠性工程)視為純技術角色，僅負責系統穩定性和監控。然而，經過多年與不同規模組織合作的經驗，玄貓發現真正成功的SRE實踐遠超過這種狹隘定義。
SRE的核心是建立以客戶為中心的思維模式，真正理解使用者如何體驗你的產品，並確保這種體驗始終滿足或超越預期。這不僅是技術團隊的責任，而是應該融入組織DNA的文化。
方法論除錯：精確校準心智模型
在討論SRE實踐前，我們需要理解一個重要概念：方法論除錯。其核心思想是將我們的心智模型明確化，以識別模型與現實之間的偏差。
任何方法論的掌握都需要練習和訓練。透過模擬日(game days)等活動，團隊可以訓練並改進對系統的心智模型。這種訓練使團隊能夠在真實緊急情況發生前，識別並修正對系統行為的錯誤假設。
創業公司如何建立SRE思維
優先順序平衡的挑戰
在創業公司中，SRE常被視為次要考量，優先順序遠低於新功能開發。這可能源於產品市場契合度(product-market fit)被賦予更高優先順序，或是服務水準目標(SLOs)未能與客戶需求明確對齊。
然而，忽視SRE意味著失去了拼圖的重要一塊。SRE不只是關於系統穩定性，更是關於真正理解客戶體驗和使用產品可能遇到的痛點。它應該成為公司每個人都具備的思維模式。
實用建議：整合客戶關注點
那麼，創業公司如何實踐SRE思維？以下是幾個實用策略：
測量客戶真正在意的事項：不僅是功能本身，還包括這些功能的表現如何。建立能反映真實使用者經驗的指標。
定義工程原則與發布門檻：制定明確的工程原則和發布門檻，幫助標準化全公司的生產就緒性。確保工程團隊超越單純的願望性表述，建立具體標準。
建立服務水準層級：為不同開發階段的功能和產品設立明確的服務水準期望。例如：
// Beta功能的發布門檻
{
"使用者容量": "支援一萬使用者",
"監控": "SLO指標在內部儀錶板上線",
"限制": "速率限制設定比正式功能低得多"
}
玄貓為你解密：
這個簡單的JSON結構定義了Beta功能的發布標準。它設定了明確的期望：功能必須能支撐一萬使用者的負載，需要有視覺化的SLO監控，並且對資源使用設定保守的限制。這種明確的定義讓各部門都能理解產品當前的可靠性狀態，避免過度承諾。
跨部門協作的關鍵
成功實施SRE思維的關鍵在於讓商業團隊(如市場和銷售)全程參與軟體開發生命週期。這確保了所有人對規模期望、優先順序和路線圖設定都有正確認識。
想像一下，如果市場和銷售團隊理解可靠性的影響，並被授權為客戶適當設定產品路線圖期望！這種透明度能大幅減少溝通開銷，讓商業團隊獲得客戶溝通所需的一切資訊。
無論開發階段為何，瞭解系統的瓶頸並將其傳達給利害關係人都是至關重要的。這能防止銷售和市場團隊向客戶過度承諾，並促進瞭解系統的工程師與接觸客戶的商業團隊之間的持續溝通，最大限度地減少引入大型新客戶時的意外。
克服阻力：平衡功能與可靠性
在大多陣列織中，總會有強大的推力忽視SRE能力建設而專注於新功能開發。這時，你可以指向那些工程和產品原則以及發布門檻，說明：
“客戶可以沒有尚未購買的功能生活，即使他們想要它。但他們無法接受已購買與期望能正常運作的功能失效。走上那條路，他們很可能會流失。”
使用Kano模型展示權衡
要說明功能與SRE概念之間的客戶滿意度權衡，Kano模型是一個強大工具。它能視覺化展示：
- 基本功能：缺失會導致極大不滿，但存在只提供基本滿意度
- 表現功能：滿意度與功能表現成正比
- 驚喜功能：意外驚喜帶來高滿意度
而可靠性屬於基本功能：客戶預期它存在，缺失會導致極大不滿。
graph TD
A[客戶滿意度] --> B[基本功能/可靠性]
A --> C[表現功能]
A --> D[驚喜功能]
B --> E[缺失=極大不滿]
B --> F[存在=基本滿意]
C --> G[表現越好=滿意度越高]
D --> H[存在=高滿意度]
D --> I[缺失=無不滿]
玄貓為你解密：
這個流程圖展示了Kano模型的核心概念。在與業務團隊溝通時，我常用這種視覺化方式說明為何可靠性不可妥協 - 它是客戶基本期望，失去它會導致客戶流失，而這比缺少某個新功能的影響嚴重得多。
建立自助流程
如何實作這種跨部門協作？關鍵是讓流程盡可能自助化：
- 在內部發布根據價值的路線圖，並有明確的更新節奏
- 任何利害關係人都能查詢下一個最大挑戰並在需要時提出紅旗
- 透過跨部門的"Scrum of Scrums"增加參與度
- 最大化分享所有權感(例如錯誤預算)
- 使商業團隊能夠就業務最佳利益的重大潛在機會提供資訊和建議
大型企業中的SRE實踐
與創業公司相比，大型企業面臨的SRE挑戰更為複雜。在啟動企業級SRE轉型前，必須瞭解組織需要解決的關鍵問題，並確定SRE將產生最大影響的領域。
識別企業特有的SRE需求
大型組織通常因規模而遭受更多執行效率低下的問題。投資SRE能減少生產執行的操作開銷(進而減少預算)，常見的激勵因素是提高開發人員生產力和推動策略性變革的時間。
然而，這個問題的表現方式更加微妙。例如，服務水準成熟度較高的服務可能已經有完善的營運實踐，但由於使用增長(即容量限制)和隨時間增加的複雜性，相比較新的服務可能存在更多不穩定性。
制定成功的SRE轉型策略
根據與眾多大型企業合作的經驗，以下是成功實施企業級SRE的關鍵策略：
1. 建立明確的業務案例
花時間進行研究，訪談產品經理和值班工程師，瞭解常見挑戰。利用可用的資料集(如問題管理資料函式庫件事後分析)確認趨勢並消除近期偏見。
一旦能夠清晰表達SRE的業務案例，在高層獲得支援將為實施設定正確的焦點。
2. 取得利害關係人的支援
其他技術主管和經理的利害關係人支援對於建立夥伴關係和擴充套件組織至關重要。獨立系統在企業中很少見—你營運的服務可能依賴一系列其他上游和下游服務，因此你的成功與你在組織中導航、影響和交付的能力直接相關。
為利害關係人定義明確的角色和職責，以及他們在每次互動中可以從SRE期望什麼。為管理期望，就每季度的一組可衡量目標和可交付成果達成一致。定期檢查進展，在任何互動開始時更頻繁(例如每週)檢查，直到事情達到穩定狀態。
# 利害關係人參與計劃範例
stakeholder_plan = {
"產品團隊": {
"角色": "提供業務優先順序和使用者需求",
"SRE承諾": "提供SLO建議和可靠性影響評估",
"互動頻率": "每週(前2個月)，之後每兩週"
},
"開發團隊": {
"角色": "實施可靠性改進",
"SRE承諾": "提供工具和最佳實踐指導",
"互動頻率": "每週同步"
},
"高層管理": {
"角色": "資源分配和戰略方向",
"SRE承諾": "提供ROI指標和進度報告",
"互動頻率": "每月更新"
}
}
玄貓為你解密：
這個Python字典結構定義了與不同利害關係人的互動計劃。在實施企業級SRE時，我發現明確定義每個團隊的角色與期望至關重要。這種結構化方法確保了各方都瞭解自己的責任，並建立了清晰的溝通通路。特別注意互動頻率如何隨時間調整 - 這反映了在初期需要更緊密協作，隨後逐漸過渡到常規節奏。
3. 適應企業環境的SRE實施
教科書式的SRE實施很少能在企業中很好地轉化，考慮到業務、產品和服務的多樣性，以及隨時間有機增長的組織結構、環境和系統的複雜性。
然而，對於大多數企業來說，為關鍵業務服務引入SLO和錯誤預算仍然是建立SRE的關鍵差異化因素，因此可能是任何實施路線圖的核心部分。如果SLO不是組織的現狀，請準備投入大量時間教導利害關係人SLO的重要性以及如何設計有意義的SLO，作為建立這一共同語言的一步。
4. 專注於短期影響
在開始階段，專注於解決SRE可以在短期內展示最大影響的幾個關鍵問題。這些早期成功建立了與前面提到的利害關係人的信任，向不熟悉該學科的人展示SRE如何增加價值，幫助確保持續投資，並最終增加長期成功的可能性。
5. 測量投資回報
隨著時間的推移，要深思熟慮地衡量投資回報—任何互動的進展、結果和成功標準應始終是可量化的。這些可以採取多種形式，從SLO改進、減少重複性工作測量和實作OKR(目標和關鍵結果)，到客戶滿意度調查。此外，定期徵求利害關係人的開放和誠實反饋。這些都是根據什麼有效或無效來完善方法和迭代計劃的強大機制。
建立以客戶為中心的產品體驗
無論是創業公司還是大型企業，建立以客戶為中心的SRE文化的最終目標是創造卓越的產品體驗。這需要：
- 將業務利害關係人凝聚在根據價值的成果上：例如
在SRE文化中擁抱「不知道」的勇氣
在快節奏的技術環境中，特別是像SRE這樣的高壓職位，我們常感到必須隨時掌握所有答案。然而，LinkedIn的一個核心價值觀「承擔明智風險」(Take intelligent risks)提醒我們：失敗不僅是可以接受的，在某種程度上更是必要的。
坦承不知道的價值
我觀察到一個普遍現象：當被問及不知道答案的問題時，特別是來自管理階層的問題，技術人員往往會緊張地試圖編造答案，而非坦誠地承認不知道。這種行為模式通常導致兩種結果：
- 提問者要求後續跟進，這其實鼓勵了健康的「不知道也沒關係」的文化
- 更糟的情況是，接受了不準確的答案，導致錯誤資訊的傳播
為何直接說「我不知道」如此困難？因為許多人擔心這會損害他們的專業可信度。但這種思維模式忽略了一個關鍵點：工程師和長官者的職責並非無所不知，而是知道如何找到答案。
「我不知道，但我會查詢並回覆您」這句話，實際上展示了你是一個可信賴的資訊提供者。它表明當你確實提供答案時，那是根據實際知識而非臨時編造。
錯誤也是成長的機會
在一個允許說「我不知道」的文化中，犯錯也變得正常化。這裡的關鍵區別在於：
- 如果你因害怕承認無知而編造答案，隨後被發現錯誤，長期來看你會失去可信度
- 但如果你根據當時最佳資訊給出答案，並坦率承認不確定性，即使最終證明錯誤，你仍然表現出了作為技術人員成長和學習的能力
我曾在一些不允許犯錯或不允許「不知道」的公司工作過，那些地方政治因素遠比技術重要。相比之下，LinkedIn的另一個價值觀「開放、誠實、建設性」(Be open, honest, and constructive)培養了一種開放文化，我們不指責而是尋求理解，這意味著我們可以在彼此面前表現出脆弱，而不必擔心這會被用來對付自己。
行業內經常談論無責備回顧會議(blameless retrospectives)，但將這種思維帶入工作的各個方面才是關鍵。當我們或同事跌倒時，我們需要互相扶持，帶著新獲得的知識一同前進。成長意味著風險，風險意味著有時我們會犯錯。否則，我們只會停滯不前。
故事力量：SRE的隱藏超能力
當我得知我的職稱將是「工程故事講述者」(Engineering Storyteller)時，我不禁莞爾。這聽起來實在太「矽谷」了——即使我身在多倫多。我向人們提起時總會輕笑，你不會嗎？但直到我發表第一個故事後，我才明白這個頭銜其實精準地概括了我的角色。
故事力量的核心
那麼，什麼是工程故事講述者？講故事是一種傳承千年的傳統，之所以能夠存續，是因為我們天生就是透過故事來消費、創造和理解世界的。我的部分職責是幫助SRE建立智慧與引人入勝的技術故事，並為它們找到合適的展示平台，無論是部落格文章，還是演講和播客。
當我做好這份工作時，世界上某些機制被解鎖，分享資訊所帶來的興奮感如爆發般湧現。我不再對這種反應感到驚訝。畢竟，優秀的故事講述是一種超能力，它展示了你對工作的熱情和投入。它表明你對同事有同理心，希望讓協作和學習變得更容易。最重要的是，它表明你不僅想分享想法，還希望人們能理解這些想法。
打破技術溝通的迷思
在技術領域工作時，存在一個常見的誤解：認為不需要與人互動或發展所謂的「軟技能」。當我剛進入軟體開發領域時，我也相信這一點，以為可以整天只與機器打交道。但我的前幾份工作很快證明這種想法是錯誤的。
我意識到這與我過去作為運動員的經歷有相似之處：溝通清晰、迅速與有效的團隊，即使技術水平相當，也優於其他團隊。團隊中的明星球員之所以能成為明星，是因為得到了團隊其他成員的支援和協調，工作團隊也是如此。
故事力量在SRE中的特殊意義
故事講述在SRE中特別重要，因為所做的工作對其他團隊來說可能顯得神秘。你究竟如何診斷系統？實際上發生了什麼？你必須以其他團隊能夠理解的方式分享。故事講述為你的工作帶來更深入的知識，並有望激發新的洞見和想法。
要解鎖這種力量，必須不斷實踐。寫作和構建關於你想法的敘事需要時間和大量迭代。寫作技巧是培養出來的，而非天生的。這不僅關乎你使用的詞彙，更關乎如何以受眾能理解的方式分解複雜主題。
如何成為出色的故事講述者
- 清晰簡潔：使用易懂的語言，直接表達
- 詳細具體：簡潔並非總是你的朋友；你的決策和過程與結果同樣重要
- 提供證據：用證據支援你的論點，但不要過度詮釋結果
- 保持助人心態：關注讀者需求，而非自我膨脹
- 說讀者的語言：想法需要被理解，以最適合你受眾的方式分享
故事講述在SRE中有其一席之地，特別是在分享難忘的故障和事件時，但你可以將其用於更廣泛的場景。故事講述能完善溝通技巧，建立專業知識，創造重要的專業網路機會，幫助解決問題，並增強信心。這確實是一種超能力，但你可以透過實踐掌握它。
讓你的工作被認可：開發個人成就檔案
在職場中，有一種普遍的想法：如果你在工作中做得出色，人們會自動認可並獎勵你晉升和加薪。然而，這並非總是如此！你的管理者肯定無法記住你做過的每一件重要事情，而與如果你仔細想，即使是你自己可能也記不清過去一年中完成的所有工作。
成就檔案的概念
這裡有一個簡單的策略可以幫助你獲得工作認可：建立一份列出你的成就的檔案。與其試圖記住所有事情，不如維護你的「成就檔案」(brag document)，列出所有成就，這樣在績效評估季節到來時，你就可以參考它！
以下是一個範例結構：
- 今年的目標（你是否特別專注於安全？在團隊中建立程式碼審查文化？）
- 明年的目標
- 參與的專案（列出你參與的每個專案和你的具體貢獻）
- 工作以外的貢獻（你是否在徵才面試中幫忙？是否指導了新員工？）
- 獲得的新技能（實踐中學到了什麼新技能？）
- 其他值得記錄的事項（你是否發現了重要的錯誤？有哪些影響深遠的貢獻？）
成就檔案的實用建議
當你建立自己的成就檔案時，可以考慮以下建議：
- 持續更新：不要等到年末才回憶一整年的工作，而是在完成重要事項時就記錄下來
- 包含具體細節：不僅記錄「修復了系統故障」，而是詳細說明「診斷並修復了導致服務中斷3小時的關鍵系統故障」
- 量化影響：盡可能用資料說話，例如「最佳化查詢減少了處理時間30%」
- 關注成長：記錄你的技能如何發展，以及你在哪些領域變得更加專業
成就檔案的多重價值
成就檔案不僅在績效評估時有用，它還有其他價值：
- 自我反思工具：幫助你評估自己的成長和發展方向
- 職業規劃輔助：清晰地看到自己的專長和興趣所在
- 信心來源：當面臨新挑戰時，回顧過去的成就可以增強信心
- 知識分享基礎：可以從中提取材料用於團隊分享或技術演講
在SRE的高壓和快節奏環境中，我們往往專注於解決眼前的問題，而忽視了記錄和慶祝已經完成的工作。成就檔案提供了一種結構化方式來確保你的貢獻不會被遺忘，無論是被你自己還是被他人。
建立卓越SRE團隊的核心要素
在任何大型企業中建立成功的團隊都不是一件容易的事——對於像SRE這樣的專業領域來說更是如此，因為成功不僅依賴於技術交付，還依賴於整個組織的重大文化變革。但這是可能實作的！
從我的經驗來看，建立卓越的SRE團隊需要幾個關鍵要素的融合：
- 心理安全感：團隊成員必須感到可以坦誠地說「我不知道」或「我犯錯了」，而不必擔心負面後果
- 故事力量的培養：鼓勵和訓練團隊成員有效地溝通技術問題和解決方案
- 個人成就的認可：建立系統化方法來記錄和認可每個人的貢獻
- 持續學習文化：將失敗視為學習機會，而非指責的理由
這些元素共同創造了一個環境，在這個環境中，SRE團隊可以真正發揮其潛力，不僅解決技術挑戰，還能推動整個組織的營運改善。
在技術工作的各個方面，從故障排除到團隊建設，坦誠和開放的溝通都是成功的根本。當我們接受不完美，並將其視為成長機會而非失敗時，我們不僅成為更好的工程師，還成為更好的團隊成員和長官者。
作為技術專業人士，我們常專注於提升硬技能，但本文討論的這些「軟」技能——承認不知道的勇氣、講述引人入勝故事的能力、記錄成就的紀律——可能同樣對職業成功至關重要。透過培養這些能力，我們不僅提升了自己的職業前景，還為整個團隊和組織創造了更健康、更有效的工作環境。
在SRE的世界中，技術專長與人際技能的結合是真正卓越的關鍵。當我們接受這一點，並致力於兩方面的成長時，我們才能真正發揮SRE角色的全部潛力。
工程師的成就紀錄：職涯發展的隱形武器
在技術職涯中，我們常專注於解決當下的問題，卻忽略了持續追蹤自己的成長與貢獻。這種忽視可能導致在績效評估或升遷機會出現時，無法全面呈現自己的價值。作為工程師，我們需要一個系統性的方法來記錄、整理和展示我們的專業成就。
成就紀錄檔案的重要性
成就紀錄檔案（有些組織稱之為「brag document」）是追蹤個人專業貢獻的結構化檔案。這不僅是為了向管理階層展示你的工作成果，更是自我反思和職涯規劃的有力工具。從我的經驗來看，維護這樣一份檔案有幾個關鍵好處：
- 為績效評估提供完整的事實依據
- 協助識別個人技能發展的模式和機會
- 在管理階層變動時確保你的貢獻不被忽視
- 幫助同事撰寫更準確的同儕評價
- 支援晉升申請和職涯規劃
開發有效的成就紀錄：關鍵要素
一份優秀的成就紀錄檔案應該包含哪些內容？以下是我認為最為重要的幾個部分：
1. 量化的專案成果
不要僅列出你參與的專案，而是要具體描述你的貢獻及其影響。例如：
× 參與了搜尋功能最佳化
√ 主導搜尋引擎最佳化專案，將查詢速度提升40%，減少了90%的使用者投訴，並將系統資源使用減少25%
玄貓為你解密：
量化成果的表達方式能讓你的貢獻變得具體與不容忽視。注意我使用的是「主導」而非「參與」，明確表明你的角色；同時使用了三個不同維度的量化指標（速度、使用者經驗、資源使用），全面展示了技術改進的商業價值。
2. 解決的重大問題
記錄你解決的重大技術挑戰，特別是那些不明顯或容易被忽視的問題：
- 識別並修復了一個長期存在但難以重現的競態條件問題，該問題曾導致每月約5次的隨機系統故障
- 重構了遺留程式碼中的密碼管理模組，消除了三個潛在的安全漏洞，同時改善了密碼重設流程的使用者經驗
3. 技術債務處理
改程式碼品質和系統可維護性的工作通常不會得到足夠重視，但這些工作對團隊長期效率至關重要：
- 設計並實施了服務監控架構，使團隊能夠在問題影響使用者前識別90%的系統異常
- 為核心業務邏輯增加了單元測試覆寫率，從35%提高到85%，減少了迴歸問題的發生率
4. 團隊貢獻與長官力
不要低估你在團隊協作方面的價值：
- 指導兩名新入職工程師熟悉程式碼函式庫發流程，使他們能夠在一個月內獨立貢獻程式碼
- 組織並主導了每週技術分享會，提高了團隊的知識分享和技術討論文化
- 建立了團隊程式碼審查標準檔案，提高了程式碼審查效率和一致性
5. 設計與檔案貢獻
系統設計和技術檔案是工程師工作的重要組成部分：
- 編寫了新微服務架構的設計檔案，獲得了跨團隊的認可和採用
- 更新並重構了API檔案，使外部開發者的整合時間平均減少40%
6. 個人學習與成長
記錄你學到的新技能和知識：
- 掌握了Kubernetes的高階管理技能，並在團隊中實施了新的容器化佈署策略
- 深入學習了分散式系統追蹤技術，並應用於改進系統可觀測性
7. 工作之外的專業發展
不要忽略工作之外的專業活動：
- 在公司技術大會上分享了「高並發系統設計模式」的演講
- 在個人技術部落格上發表了5篇關於系統架構的文章，累計獲得超過1萬次閱讀
成就紀錄檔案的最佳實踐
根據我的經驗，以下是維護成就紀錄的幾個關鍵實踐：
定期更新，不要等到評估時才匆忙準備
我推薦採用一種持續更新的方式，而不是在績效評估前臨時回憶。我個人的做法是：
- 每週五花15分鐘記錄當週的重要工作成果
- 每月底進行一次回顧，確保沒有遺漏重要貢獻
- 使用標籤或分類別來組織不同類別的貢獻，便於後續整理
重視事實與資料
成就紀錄應該儘可能根據事實和資料：
- 使用具體的指標和數字來描述影響
- 參照反饋或證據來支援你的陳述
- 避免誇大或主觀評價
例如，不要寫「大幅提升了系統效能」，而應該寫「將API平均回應時間從300ms降低到75ms，如效能監控報告#123所示」。
分享你的成就紀錄
成就紀錄不應該是私金鑰件：
- 與你的經理分享，幫助他們更好地瞭解你的工作
- 在同儕評價期間與同事分享相關部分
- 在團隊交接或經理變動時主動提供
