SRE的本質：可靠性工程的核心思維

站穩可靠性工程（Site Reliability Engineering，SRE）作為一門專業領域，已經從谷歌的內部實踐發展為整個技術行業的標準方法論。當玄貓回顧SRE的演進過程，發現它不僅是一套技術實踐，更是一種思維模式和文化理念。

何謂SRE？六字定義

如果要用最簡潔的方式定義SRE，可以濃縮為六個字：「以軟體解決維運問題」。這個精簡的定義揭示了SRE的本質 - 將軟體工程的原則和方法應用於系統維運，以實作自動化、可擴充套件性和可靠性。

與傳統維運不同，SRE不是被動地應對系統問題，而是主動地設計和建構能夠自我修復、自我監控的系統。這種思維轉變是SRE與傳統維運最大的區別。

可靠性的真正價值

我們為什麼需要可靠性？這個看似簡單的問題卻值得深思。可靠性不是目標，而是手段。它的終極目的是為使用者提供穩定、可預期的服務體驗，從而建立信任關係。

玄貓在實踐中發現，過度追求99.999%的可靠性可能會適得其反。當我們考慮可靠性時，應該思考：

1. 使用者對服務的真正期望是什麼？
2. 系統中哪些部分對可靠性要求最高？
3. 可靠性與創新速度之間如何取得平衡？

真正的可靠性工程是理解業務需求，然後有策略地分配資源，而不是盲目追求數字。

從零到一：建立SRE文化與實踐

SRE文化是基礎

無論組織規模大小，SRE都是一種文化。在小型組織中，「每個人都是SRE」，因為沒有足夠的專業人員分工；在大型企業中，則需要有意識地培養這種文化。

建立SRE文化的核心是培養以下思維模式：

• 預防勝於治療：主動識別和解決潛在問題，而不是等待故障發生
• 自動化優先：將重複性任務自動化，釋放工程師創造力
• 資料驅動決策：根據測量和觀察做決定，而非直覺或經驗
• 擁抱故障：將故障視為學習機會，而非追究責任的理由

服務水平目標（SLO）的設計與應用

SLO是SRE實踐的根本，它將抽象的「可靠性」概念轉化為可測量的指標。設計有效的SLO需要考慮以下目標：

1. 使用者視角：SLO應從使用者經驗出發，而非系統內部指標
2. 簡單明確：指標應該簡單易懂，便於團隊成員理解和使用
3. 可操作性：當SLO違反時，團隊應該知道如何應對
4. 可實作性：設定合理的目標，避免團隊疲勞

一旦有了錯誤預算（Error Budget），接下來的問題是如何使用它。玄貓建議將錯誤預算視為促進工程團隊和產品團隊對話的工具，幫助大家理解可靠性與創新之間的權衡。

方法論除錯

在SRE工作中，排除故障是一項基本能力。有效的除錯不是靠運氣或直覺，而是遵循方法論：

1. 收集資料：取得足夠的系統狀態資訊
2. 形成假設：根據資料提出可能的故障原因
3. 設計實驗：驗證或排除每個假設
4. 縮小範圍：逐步縮小可能的問題區域
5. 解決問題：實施解決方案並驗證效果

這種方法論不僅適用於技術問題，也適用於組織和流程的改進。

從一到十：擴充套件SRE實踐

視覺化工作流程

在SRE團隊擴充套件過程中，工作的視覺化變得尤為重要。透過使工作視覺化，團隊可以：

• 識別隱藏的工作和技術債務
• 合理分配資源和優先順序
• 避免過度承諾和團隊倦怠
• 提高跨團隊協作效率

玄貓發現，許多SRE團隊過度關注緊急事件處理，而忽視了長期改進工作。透過視覺化工作流程，團隊能夠更好地平衡短期和長期目標。

事件處理的藝術

事件處理是SRE工作的關鍵部分，有效的事件回應流程應該包含以下元素：

1. 明確的角色分配：指定事件指揮官、溝通協調員和技術工作者
2. 結構化溝通：使用標準化的溝通通路和格式
3. 決策框架：在壓力下做出合理決策的指導原則
4. 知識管理：確保團隊成員能夠快速存取必要的資訊

最重要的是，最佳化「平均還原床鋪時間」（Mean Time to Back to Bed, MTTBTB）。這個半開玩笑的指標實際上很好地反映了事件處理的效率和對工程師健康的影響。

作業手冊的悖論

作業手冊（Runbooks）是SRE實踐中的常見工具，但它們往往存在兩個極端：過於詳細以至於無人閱讀，或過於簡略以至於無法指導行動。

有效的作業手冊應該：

• 聚焦於指導原則而非機械步驟
• 包含背景資訊和設計意圖
• 定期更新和驗證
• 與監控和警示系統整合

玄貓在實踐中發現，最好的作業手冊不是試圖覆寫所有情況，而是提供足夠的連貫的背景與環境，幫助工程師做出正確的判斷。

工具中的情感元素

SRE工具的設計不僅關乎功能，也關乎情感體驗。在高壓環境下，工具的易用性和情感設計變得尤為重要。

設計富有同理心的SRE工具應考慮：

1. 情境感知：理解使用者當前的情緒狀態和需求
2. 減少認知負荷：在關鍵時刻提供清晰、簡潔的資訊
3. 提供支援和鼓勵：在壓力情境中給予積極反饋
4. 學習曲線：設計直覺的介面，減少學習成本

ChatOps（聊天操作）工具是實作情感設計的一個良好平台，它可以在團隊協作的自然環境中融入支援性的互動元素。

從十到百：擴充套件與最佳化SRE

建立健康的待命文化

隨著組織規模擴大，待命（on-call）輪值變得更加複雜。建立健康的待命文化需要關注：

1. 公平分配負擔：確保待命責任均衡分配
2. 明確的升級路徑：定義何時和如何尋求幫助
3. 持續改進：根據待命經驗改進系統和流程
4. 健康指標：定期評估待命對工程師健康的影響

玄貓觀察到，最成功的組織將待命健康視為與系統可靠性同等重要的指標，並為此投入相應資源。

防止級聯故障

隨著系統複雜性增加，級聯故障的風險也隨之上升。有效預防和緩解級聯故障的策略包括：

1. 設計隔離性：使用隔板、熔斷和退避機制
2. 負載調節：實施自適應流量控制和優先順序排序
3. 相依性管理：明確依賴關係並設計降級機制
4. 故障注入：定期測試系統在部分服務失敗時的行為

在實踐中，玄貓發現最有效的方法是將級聯故障視為設計問題，而非維運問題，從系統架構層面預防故障擴散。

統一性的力量

在大規模SRE實踐中，統一性（uniformity）是一個強大的原則。統一的環境、工具和流程可以：

• 降低認知負荷和切換成本
• 簡化自動化和工具開發
• 提高問題診斷效率
• 促進知識分享和團隊流動性

然而，統一性需要與創新和多樣性取得平衡。玄貓建議將統一性應用於基礎設施和核心服務，同時在應用層面保留適度的自主性。

產品思維與SRE

隨著SRE團隊成熟，將產品思維融入SRE實踐變得越來越重要。這意味著：

1. 將內部工具視為產品：關注使用者經驗和價值
2. 理解客戶需求：深入瞭解開發團隊的工作流程和痛點
3. 建立反饋迴圈：持續收集和回應使用者反饋
4. 衡量成功：定義和跟蹤有意義的成功指標

玄貓在與多家組織合作中發現，成功的SRE團隊往往是那些能夠將自身定位為「服務提供者」而非「看門人」的團隊。

SRE的未來發展

安全關鍵系統的啟示

隨著軟體系統在社會中扮演越來越重要的角色，SRE可以從安全關鍵系統（如航空、醫療、核能）領域汲取經驗：

1. 形式化方法：使用數學證明確保系統行為符合規範
2. 靜態分析：在執行前識別潛在問題
3. 系統性風險評估：全面評估失敗模式和影響
4. 設計多樣性：使用不同實作方式提供冗餘保障

雖然這些方法可能看起來過於嚴格，但隨著軟體系統變得更加關鍵，採用更嚴謹的方法將變得越來越重要。

社會技術系統中的風險與腐蝕

SRE需要認識到系統不僅包含技術元件，還包含人員、流程和組織結構。在這種社會技術系統中：

1. 知識腐蝕：隨著時間推移，團隊對系統的理解會逐漸減弱
2. 假設失效：系統設計中的基本假設可能不再有效
3. 標準漂移：操作標準會隨著時間推移而變化
4. 組織記憶：重要經驗和教訓可能被遺忘

玄貓認為，未來的SRE實踐需要更加關注這些社會技術因素，將人與技術視為一個整體系統來管理。

事件作為學習視窗

事件不僅是需要解決的問題，更是組織學習的寶貴機會。進階的事件分析應聚焦於：

1. 發現知識缺口：識別組織中的知識盲點
2. 理解決策過程：分析在壓力下的決策模式
3. 發現協作模式：觀察團隊如何協同工作
4. 識別系統假設：揭示隱含的系統設計假設

透過這種方式，事件成為瞭解系統和組織的視窗，而不僅是需要「修復」的失敗。

SRE的第三個時代

SRE正在進入第三個發展階段：

1. 第一時代：專注於自動化和基礎設施管理
2. 第二時代：關注服務水平目標、錯誤預算和系統可靠性
3. 第三時代：整合社會技術系統思維、韌

好奇心驅動的系統韌性：從阿波羅12號說起

1969年11月14日，阿波羅12號從佛羅裡達州卡納維拉爾角發射升空時，遭遇了不可思議的事件——它在36.5秒和52秒時連續兩次被閃電擊中。事後報告顯示，閃電造成電力突增並意外斷開了燃料電池，導致電壓驟降。

在那個瞬間，阿波羅12號指令艙內的所有警示同時響起，休斯頓接收到的遙測資料完全無法解讀。對於一個習慣思考所有可能性的組織來說，他們卻從未考慮過閃電擊中的應對方案——畢竟，這種機率有多大？

更糟的是，任務的風險不能再高：如果中止任務，NASA將損失價值12億美元的火箭；如果繼續進行但無法保障太空人安全，則可能向全世界直播一場災難。聆聽當時任務控制中心的錄音，你能感受到那緊繃的氛圍。

通訊迴路中有一刻的寂靜，然後有人插話：“試SCE切到Aux（輔助電源）。“這是前所未有的操作，以至於有人回應：“那是什麼鬼東西？“在沒有更好選擇的情況下，這個指令被傳達給太空人。奇蹟發生了——在找到開關並切換後，一切立即還原正常。

提出這個關鍵建議的是NASA工程師John Aaron。一年前，他在阿波羅模擬艙工作時遇到了類別似的遙測讀數混亂。與其重置模擬器，他決定嘗試自己解決問題。他發現透過將訊號調節電子裝置（SCE）切換到輔助設定，系統能在低電壓條件下運作，從而還原遙測功能。

這次閃電襲擊是NASA從未模擬過的黑天鵝事件。是什麼啟發John Aaron深入探究並找出那特定資料異常的原因？在NASA的口述歷史中，他將功勞歸於"對事物運作原理的天然好奇心”。

SRE的核心特質：不只是技術，還有人

好奇心是許多SRE（站點可靠性工程師）的共同特質。這讓我想起與都柏林一位SRE朋友的對話，她分享了自己總是不斷追問為什麼的性格特點。這呼應了John Aaron談到的願望：瞭解周圍事物的運作方式，並持續探索直到獲得深刻理解。

這種學習意願對SRE來說非常合理，因為他們需要處理複雜系統。系統不斷變化，角色需要有人願意詢問它們如何運作。這種探究精神意味著SRE不會只將系統的某一部分視為自己的領域，而是關注所有部分以及它們如何協同運作。

但不僅是技術系統。SRE還需要對人保持好奇——社會技術系統中的"社會"部分。沒有這點，你無法將不同團隊聚在一起建立有意義的SLO（服務水平目標）。你無法在事件回應中理解不同性格類別。你可能只滿足於五個為什麼的表面分析，而錯過事後學習的深刻教訓。

本章結構：按SRE團隊規模劃分的實用

SRE雖然處理複雜的技術系統，但本質上是一種文化實踐。文化是人的產物，這啟發我們根據組織中SRE的數量來組織本章各章節——你的具體工作和日常挑戰取決於SRE的規模。我們將書中的文章分為"SRE新手”、0-1位SRE、1-10位SRE、10-100位SRE以及"SRE的未來”。

讀者可以直接跳到最適用於自己情況的章節；不過，即使是目前與你日常工作無關的章節，也能提供寶貴價值。

在0到1位SRE階段，要麼還沒有指定SRE，要麼你剛找到第一位SRE，這個角色可能顯得有些孤獨。

在1到10位SRE階段，你正在組建團隊，開始分享知識並能夠分配工作。

在10到100位SRE階段，你已經發展成一個組織，需要考慮不僅是你正在處理的系統，還有如何組織這麼多SRE。

“SRE新手"部分涵蓋基礎主題，對剛開始SRE之旅的人有幫助，也為經驗豐富的SRE提供複習。“SRE的未來"包含展望SRE潛在發展方向的文章，或是目前處於時代前沿的議題。

閱讀本章不需要特定順序。你可以從頭到尾閱讀，也可以根據特定主題查閱索引找到所有相關文章。將其作為參考或靈感來源，在需要時提供啟發。或者，你可以建立閱讀俱樂部，每週選擇一篇文章與同事討論。這就是文章集的美妙之處。

SRE的六字真諦

當有人問我做什麼工作時，我通常回答：“我是站點可靠性工程師。我們保持大型電腦服務的可靠性。“對許多人來說，這足夠無趣，我們的寒暄便繼續進行。但偶爾，我會遇到更好奇的人：“哦，聽起來很有趣！你們是怎麼做到的？”

這是個難以回答的問題！SRE實際上做什麼？多年來，我只能列舉一系列工作內容，其中一些已經成為本章中的文章。雖然這樣的回答並非完全錯誤，但感覺從未真正令人滿意。

經過十年的SRE工作經驗，我想我終於找到了更凝練的答案。SRE所做的幾乎一切都依賴於我們的六個核心原則：

1. 測量一切 - 如果沒有資料，就無法知道系統的狀態
2. 設定明確的目標 - 明確的服務水平目標是可靠性工作的針
3. 擁抱失敗 - 系統終將失敗，我們必須接受並從中學習
4. 自動化重複任務 - 釋放人力專注於更具創造性的問題解決
5. 減少人為干預 - 人是最不可預測的系統元件
6. 漸進式改進 - 持續不斷的小改進勝過偶爾的大變革

這些原則不僅適用於技術系統，也適用於人與流程。真正的SRE工作是在這些原則的指導下，平衡技術與人文因素，創造更可靠的系統。

從理論到實踐：SRE的日常工作

理解了SRE的核心原則後，讓我們看這些原則如何轉化為日常工作：

測量與監控

測量是SRE工作的根本。我們建立全面的監控系統，追蹤從基礎設施到使用者經驗的各個層面。這不僅是收集資料，還包括設計有意義的指標，確保能夠反映系統的真實健康狀況。

例如，與其僅監控伺服器CPU使用率，真正的SRE會關注這如何影響使用者經驗的延遲指標。我們設計的警示不僅告訴我們"出了問題”，還能指引我們瞭解"出了什麼問題”。

服務水平目標(SLO)的藝術

SLO是我們與業務部門之間的共同語言。透過設定明確的可靠性目標，我們能夠:

• 量化使用者經驗
• 在速度與穩定性間做出明智決策
• 有效地分配工程資源

真正有效的SLO不僅是技術指標，它反映了使用者真正關心的體驗。例如，不只是測量API的可用性，而是測量使用者能否成功完成關鍵業務流程。

從失敗中學習

在SRE文化中，我們不懲罰失敗，而是珍視從中獲得的學習機會。這體現在:

• 無指責的事後分析
• 設計可預測的失敗模式
• 定期進行混沌工程實驗

真正的SRE團隊會主動尋找系統的弱點，而不是等待它們在關鍵時刻暴露出來。

自動化的智慧應用

自動化不是目的，而是手段。我們優先自動化:

• 重複性任務
• 容易出錯的人工步驟
• 緊急情況下的標準回應

但我們也明智地知道何時不自動化。有些決策需要人類的判斷，過度自動化可能產生新的風險。

從個人到組織：SRE的進化之路

隨著組織SRE的增長，關注點也會發生變化:

0-1 SRE階段：奠定基礎

這個階段的關鍵是建立基礎設施即程式碼、自動化佈署管道和基本監控。作為第一位SRE，你既是實踐者又是傳教士，需要向組織傳播可靠性文化。

1-10 SRE階段：建立協作模式

隨著團隊擴大，重點轉向建立共同實踐:

• 制定一致的事件回應流程
• 建立知識分享機制
• 開發團隊特定的工具和自動化

此時，團隊需要平衡專業化與通才能力，確保不會產生單點故障。

10-100 SRE階段：擴充套件與專業化

在這個規模，SRE開始專注於:

• 建立跨團隊的標準與最佳實踐
• 開發內部平台與工具
• 培養專業SRE在特定領域的深度

組織結構變得至關重要，需要決定是集中式SRE團隊，還是嵌入各產品線的分散式模型，或是混合方法。

SRE的未來：超越傳統邊界

隨著技術的發展，SRE領域也在不斷演進:

• 可觀測性的進步 - 從監控到真正理解複雜系統的行為
• 安全性與可靠性的融合 - 安全事件越來越成為可靠性問題
• 低程式碼/無程式碼環境中的SRE - 應用SRE原則於新興平台
• 人工智慧輔助的維運 - 利用AI預測和預防潛在問題

未來的SRE不僅需要技術專長，還需要跨學科知識，包括心理學、組織行為學和風險管理。

SRE的本質：好奇心與系統思維的結合

回到阿波羅12號的故事，John Aaron能夠在危機中提供解決方案，不是因為他遵循了標準流程，而是因為他的好奇心驅使他探索系統的行為，即使在非常規情況下。

這正是SRE的精髓 - 我們不僅關心繫統在正常情況下如何工作，更關心它在壓力下、在邊緣情況下如何表現。我們帶著好奇心探索複雜系統的各個層面，從技術堆積積疊到團隊動態，從使用者行為到業務目標。

真正的SRE不僅是技術工作者，更是系統思考者，能夠看到各部分如何相互作用，如何在壓力下演變，以及如何透過精心設計的介入來增強整體韌性。

在這個日益複雜和相互連線的世界中，這種思維方式比以往往任何時候都更為寶貴。無論你是SRE新手還是經驗豐富的工作者，希望本章能激發你的好奇心，推動你在SRE旅程中不斷前進。

技術系統會不斷演變，但好奇心、系統思維和解決問題的熱情將始終是SRE的核心。就像John Aaron在那關鍵時刻所展現的那樣，有時候，瞭解系統如何工作的深

測量的本質：超越資料收集的境界

測量遠非簡單的資料收集行為。真正的測量始終伴隨著明確目標。就像烘焙蛋糕時不會隨意倒入麵粉，而是精確測量用量——否則結果往往令人失望。作為站點可靠性工程師（SRE），我們測量系統指標的目的並非僅取得原始資料，而是尋求有意義的洞察。

在測量過程中，我們本質上在尋找一個關鍵問題的答案：「這個服務是否真正滿足了使用者需求？」這個問題看似簡單，實則深刻。它要求我們超越單純的可用性資料，深入理解服務的真正價值所在。

測量-分析-決策-行動-反思的迴圈

一旦完成測量，下一步便是分析所得資料。這個階段需要基本的統計和機率分析技能。玄貓建議充分利用數學家們數百年來積累的知識體系，從測量資料中提取最大價值。

經過深入分析後，我們需要根據這些洞察做出決策，規劃最佳的未來行動路徑。決策過程應該建立在資料基礎上，而非直覺或習慣。

然而，決策若不付諸行動則毫無意義。我們必須實際執行所決定的方案——有時候，最佳「行動」可能是選擇不採取任何行動！這同樣是一種經過深思熟慮的決策。

行動之後，至關重要的步驟是進行反思。以批判但不指責的視角審視所完成的工作。從這個過程中獲得的經驗教訓往往比初始測量分析更為寶貴。

這個迴圈隨後重新開始。你的決策可能已經改變了系統的某些方面，也可能沒有，而持續測量能夠揭示這些行動（或不行動）的真實影響。不斷測量、分析、決策、行動、反思，周而復始——這正是SRE的工作方式。可靠性的提升只能透過這種漸進式的持續改進來實作。

SRE：資料驅動的多面技術角色

站點可靠性工程是一個廣泛的學科領域。SRE工程師經常需要扮演多種角色：軟體工程師、系統管理員、網路工程師、系統架構師，有時甚至是教育者或顧問。貫穿這些角色的核心原則是：SRE是資料驅動的實踐。

這一原則的具體現就是前面提到的迴圈過程：測量必要的指標，分析收集的資料，根據分析做出決策，執行決定的行動，反思決策結果，然後不斷重複這個過程。

如果要用六個詞概括站點可靠性工程的精髓，那就是：測量、分析、決策、行動、反思和重複。

我們真正理解可靠性的價值嗎？

作為技術專業人士，我們常將系統可靠性視為不言而喻的追求目標。然而，當深入思考時，一個有趣的問題浮現：我們真的理解可靠性，或者說，我們為什麼真正需要它？

這似乎是個奇怪的問題。在技術社群中，「無法存取的線上服務毫無價值」已成為一種信條。但稍加思考就會發現這個說法並不完全正確。實際上，我們每天都會遇到間歇性的電腦故障。某些情境下甚至已經習以為常；在網路服務領域，使用者已高度適應點選重新整理，或者（對於更複雜的問題）清除 cookie、重啟瀏覽器，甚至重啟整台機器。服務本身也內建了重試機制。

每一次人機互動中都包含著一定程度的容錯空間。即使是較長時間的服務中斷，如果只持續幾分鐘，使用者幾乎總會回來。根據服務的獨特性，使用者甚至可能有更多的耐心。

幾年前，玄貓曾與一家知名公司的代表交流，他們坦言不會在可靠性上投入資金，因為他們的特定客戶群別無選擇。因此，花在提高可靠性上的時間就是不花在取得收入上的時間；從他們的角度看，這樣做不值得。

當時，這番言論讓我暗自吃驚，但這些年來我經常思考這個觀點。作為一個技術社群和專業領域，我們有何論據反駁這種說法嗎？我們能否量化這些資料？理解其中的權衡？超越品牌形象的情感訴求，提出真正有力的論證？解釋為何那些曾因不可靠而被批評的公司，如今價值卻高達數百億？甚至解釋為何某些公司的網站無法存取會造成實際金錢損失，服務中斷經常持續數小時，但使用率、收入和利潤卻持續增長？

雖然不願承認，但在增長市場中，如果公司需要在取得新客戶和留住現有客戶之間做選擇，所有經濟激勵都傾向於客戶取得，因為每失去一個客戶都會被更多新取得的客戶所替代。當然，一個系統性不可靠的平台最終會讓你失去與取得的客戶一樣多，但你有時間修復這個問題，而與客戶即使面對糟糕的服務，通常也不願輕易改變。

產品開發人員瞭解這一點，這也是為什麼我們的討論往往如此激烈。然而，我們目前缺乏完全令人滿意的方式來討論這些權衡；可靠性的真正價值，特別是對於非增長市場、非網路環境或其他SRE不常見的領域，很難清晰表達。

SLO模型本應能夠精確描述特定客戶群在總體上可以容忍多少不可靠性的細微差別，但實際上這還不夠充分。在典型使用中，它無法區分（例如）20分鐘的幾乎完全不可用和2小時的間歇性不可用。從客戶體驗角度，甚至從收入生成角度來看，這些情況實際上非常不同。

我們有一些零散的資料點，勉強勾勒出一種方法的輪廓，這種方法可能幫助我們理解並成功地論證為什麼在時間和資源有限的情況下——甚至更糟糕的是，在增長市場中——值得花時間提高可靠性，但我們離完全理解這一切還有很長的路要走。

因此，取決於你的觀點，這可能令人擔憂，或者是一個停止花費大量時間和金錢的絕佳機會。

建立自我調節的流程

在Camille Fournier的優秀著作《管理之路》(The Manager’s Path) 中，她建議讀者尋找「自我調節的流程」，這引起了玄貓的注意。作為一名經濟學背景的技術工作者，我總是熱衷於將經濟思維應用到實際問題解決中。自我調節流程本質上是小型的檢查與平衡迴圈，在人類系統中發現它們尤為有趣。

在技術圈中，我經常聽說流程實驗的成功或失敗取決於發起實驗者的情感或政治影響力。例如，當向新的工程師群體引入結對程式設計時，通常需要一位自信、有魅力的人才能說服不情願的團隊成員開始首次結對。

事實上，他們一開始甚至可能不稱之為結對——他們會說，「嘿，要不要過來看這個問題？」但當這個人離開公司後，結對程式設計可能就會被擱置，因為它是由個人魅力驅動的。這些短暫的流程創新雖然有價值，但難以持久；在這種情況下，我們永遠無法學會如何調整、測量和擴充套件它們。

相比之下，自我調節流程不依賴強勢個性來維持。它們的運作方式是透過調整激勵機制（包括正面和負面的），使得沒有任何一個人陷入催促他人完成工作的不愉快任務中。微管理正好代表了自我調節流程的反面結果。

要理解如何調整激勵機制，我們首先需要了解什麼是激勵。正向激勵代表著個人按特定方式行動所獲得的淨收益。這更像是胡蘿蔔而非棍棒。激勵機制有多種形式：財務激勵（如薪資、股票獎勵）、社交激勵（如同儕認可）或內在激勵（如掌握特定技能）等。

大多數人都受到賺取更多金錢以及獲得更好職稱的正向激勵驅動。為了實作這點，在組織文化較為開放的環境中，大多數人會同意從同事那裡接收誠實與具建設性的反饋是有益的。

自我調節流程的特點與價值

自我調節流程的核心優勢在於其可持續性。與依賴特定個人推動的流程不同，自我調節流程透過系統性的激勵對齊，創造一個能夠自我維持的改進環境。這種流程一旦建立，即使關鍵推動者離開，也能持續運作。

在建立這類別流程時，關鍵在於理解各方的動機與需求。例如，工程師可能重視技術挑戰與學習機會，管理者關注專案進度與結果，而業務方則專注於市場影響與收入。自我調節流程需要找到這些不同需求的交集點，使各方都能從流程中獲益。

具體到SRE實踐中，自我調節流程可以體現為：

1. 建立明確的服務水平目標(SLO)，使團隊有共同的衡量標準
2. 設計錯誤預算系統，自動平衡創新速度與系統穩定性
3. 實施後台輪值制度，讓所有團隊成員都能體驗服務維運挑戰
4. 建立事故無責任歸咎文化，鼓勵開放分享經驗教訓

玄貓認為，建立自我調節流程是SRE實踐成功的關鍵因素之一。這不僅提高了系統可靠性，也創造了更健康、更可持續的工作環境。

可靠性工程的思考框架

綜合上述討論，我們可以提煉出一個SRE實踐的思考框架：

測量與分析

測量是所有改進的基礎，但測量必須有目的。在設計監控系統時，我不僅關注技術指標，更關注這些指標如何反映使用者經驗。例如，除了傳統的CPU使用率、記憶體消耗等系統指標外，我會特別關注回應時間分佈、錯誤率分佈等更直接影響使用者感知的指標。

分析階段需要將原始資料轉化為有意義的洞察。這需要統計學知識和業務背景的結合。例如，當發現某API的P99回應時間異常增加時，我不會僅關注技術原因，還會分析這對不同使用者群體的影響程度，以及可能的業務影響。

決策與行動

根據分析結果做出決策時，需要權衡多種因素：技術可行性、業務優先順序、資源限制等。在SRE領域，這常意味著需要在可靠性和創新速度之間取得平衡。

決策後的行動執行同樣重要。最佳的計劃若無法有效執行也毫無價值。這要求團隊具備強大的執行力和變更管理能力，能夠在最小化風險的前提下實施系統變更。

反思與持續改進

行動後的反思是整個迴圈中最容易被忽視但又極為關鍵的環節。透過結構化的事後分析(Post-mortem)，團隊能夠從每次事

誘因平衡：開發自我調節的工程流程

負面誘因的隱藏力量

負面誘因代表淨損失，與正面誘因相反。大多數人對負面誘因集合的反應通常很敏感，比如想避免社交方面的負面後果或不必要地消耗社交資本。一個有趣的現象是：在實行無限休假政策的公司中，員工實際休假天數反而比固定年假制度的同行少。這是因為財務激勵結構被社交激勵結構取代，而社交反激勵感覺成本更高，部分原因是它們很難量化，而人類天生厭惡不確定性。

自我調節流程的設計原則

一個良好的自我調節流程需要建立正面誘因和負面誘因的最佳組合，讓人們能夠內在驅動地遵循流程，一旦流程開始執行，就不需要外部鼓勵或推動。平衡正負誘因至關重要：

• 過多負面性會讓人產生恐懼感
• 過多正面性則假設每個人都同樣被相同的"胡蘿蔔"激勵（這通常不成立）

玄貓認為，在軟體工程公司（可能在其他公司也適用），只要停下來思考當前存在哪些誘因，就能設計出自我調節的流程。這種思維模式對於建立可持續發展的工程文化至關重要。

四種SRE工程師的思維模式

自私工程師：逃避共同責任

自私的工程師會問：“為什麼你們的可靠性這麼差？“注意這裡使用"你們的"而非"我們的”，表明他拒絕承擔可靠性責任。生活當然更輕鬆，如果可靠性是你的工作而非我們共同的職責——但現實是，可靠性越來越頻繁地成為集體責任。

對於這類別工程師，我們需要解釋在生產環境中擁有自己程式碼的重要性。當他決定為功能新增哪種可觀察性、向資料儲存發出哪些查詢，或是否應該拒絕資源密集型功能需求時，這位工程師——就像其他所有人一樣——會影響生產環境的行為和可靠性。沒有人能避免這種對生產環境的影響力，如果我們逃避責任，就隱含地將負擔轉嫁給他人。

考慮到這種責任的重要性和不可避免性，我們應該讓他思考：擁抱責任比逃避責任是否能帶來更多職業成長和成功？

初級工程師：開發環境與生產環境的鴻溝

初級工程師常問：“在我的機器上能執行，為什麼這還不夠？”

如果開發環境的成功能夠保證生產環境的成功，那該多好啊！我們需要向他們描繪開發環境和生產環境之間的巨大差異。可以比較生產環境中資料的規模和複雜性，與為開發最佳化的有限與精心企劃的資料快照。或者，我們可以對比生產環境中設定的複雜網路拓撲與開發環境中用於幫助快速測試和迭代的本地服務和存根服務。

玄貓建議這類別工程師檢視我們檔案中一些最棘手或最令人頭疼的事故報告。在導致這些事故的諸多因素中，有些肯定永遠不會在開發環境中出現（更不用說可重現地出現了）。

明智工程師：錯誤預算的真正價值

經驗豐富與閱讀廣泛的明智工程師會問：“錯誤預算如何防止我的下一個嚴重事故？“不幸的真相是，錯誤預算是回顧性的，無法預測——更不用說防止——事故。

對於她，我們需要指出，雖然錯誤預算不能預測或防止事故，但它們為準備事故提供了基礎。定義錯誤預算的過程建立了關於可靠性含義的一致性、透明度和共識，不僅對工程師和使用者，也對高管、銷售和市場、一線支援以及整個組織都是如此。

我們鼓勵她對錯誤預算保持好奇，並思考她從中學到的關於使用者對系統期望的見解。她是否發現錯誤預算有助於引發對生產環境行為的積極持續討論？從長遠來看，這有助於減少事故的可能性和影響。

探索型工程師：可靠性的本質意義

最後，不確定如何提問的工程師會問：“為什麼可靠性重要？為什麼我們應該對它保持好奇和熱情？”

對他們，我們表明可靠性是關於系統按預期執行，而使用者希望軟體可靠！可用性——快速正確地回應請求，或通俗地說，不失敗——是一個常見例子。使用者也希望軟體能夠變化和改進，通常表現為新功能、更好的效能或成本降低。

這些需求經常相互衝突，他應該將SRE視為一種量化可靠性的方法，幫助整個組織理解所涉及的權衡。

可靠性堆積積疊：構建穩定系統的三層根本

想象你最喜歡的數位媒體串流媒體務。你坐在沙發上準備看電影，點選遙控器按鈕。大多數時候，電影會緩衝幾秒鐘然後開始播放。但如果電影需要完整的20秒才能緩衝好呢？你可能會在當下感到有點惱火，但最終，電影的其餘部分播放正常。即使有這小的失敗，這項服務對你來說仍然是可靠的，因為大多數時間它不需要接近20秒。

如果每次都需要20秒才能緩衝呢？現在情況從暫時煩人變成完全不可靠。在眾多數位媒體串流媒體務可選的情況下，你可能會選擇放棄這項服務，轉向其他服務。

完美不是目標，足夠可靠才是

沒有什麼是完美的，沒有什麼能100%可靠。這不僅是世界執行的方式，事實證明人們完全能接受這一點！沒有人真正期望電腦系統總是完美執行；我們只需要它們夠頻繁地足夠可靠。

那麼，我們如何確定正確的可靠性水平呢？這就是可靠性堆積積疊發揮作用的地方。它由三個元件組成：SLI（服務水平指標）、SLO（服務水平目標）和錯誤預算。

SLI：可靠性的基礎測量

在可靠性堆積積疊的基礎是SLI，它從使用者角度測量你的服務。為什麼是使用者視角？因為他們是系統需要為之表現良好的物件。你的使用者決定你是否可靠。如果電影每次都需要20秒才能緩衝，沒有使用者會在意你這邊看起來一切良好。SLI的例子可能是：“電影緩衝時間為5秒或更短。”

SLO：設定現實的目標

接下來是SLO，它由SLI驅動。如果SLI是關於服務執行狀況的測量，SLO則是你希望它們執行得足夠好的頻率目標。使用我們的例子，你可能想說：“電影緩衝時間為5秒或更短，達到99%的時間。“如果緩衝時間僅在100次中有1次超過5秒，人們可能會接受這種情況。

沒有什麼是完美的，所以不要以完美為目標。相反，確保你的目標是在足夠多的時間內保持可靠。如果試圖追求完美，你會消耗無限的資源——財務和人力。

錯誤預算：長期可靠性的衡量標準

最後，在可靠性堆積積疊的頂部是錯誤預算，它由SLO提供資訊，簡單地測量你在一段時間內相對於目標的表現。從使用者角度瞭解過去一週、一個月或一個季度的表現，比僅知道現在的表現要有用得多。錯誤預算讓你能夠做出類別似這樣的陳述：“我們每30天可以有7小時18分17秒的不可靠緩衝時間。“你可以使用錯誤預算更全面地思考服務的可靠性，利用這些資料進行更好的討論，做出更好的決策來解決可靠性問題。

平衡技術與人性：SRE的深層思考

在深入研究SRE實踐時，玄貓發現最成功的可靠性策略都平衡了技術指標與人性因素。錯誤預算不僅是數字，還是溝通工具——它們將抽象的可靠性概念轉化為所有利益相關者都能理解的具體數值。

自我調節流程的真正力量在於它們能夠適應組織文化。每個團隊都有獨特的動力和價值觀，因此通用的可靠性方法往往失敗。相反，我們應該設計能夠與團隊現有文化和價值觀共鳴的流程。

四種工程師思維模型提醒我們，技術解決方案必須考慮到人類的多樣性。自私工程師需要看到對個人的好處；初級工程師需要理解更廣闊的系統背景；明智工程師需要深度洞察；而探索型工程師則需要與更大的目標連線。

SRE不僅是一套工具或實踐，而是一種思維方式——一種平衡完美與實用、技術與人性的方法。透過建立反映使用者實際體驗的可靠性堆積積疊，我們可以建立既穩定又能持續發展的系統。

在可靠性工程的旅程中，記住沒有完美的系統，只有足夠可靠的系統。這種思維轉變釋放了創新，因為它承認失敗是學習和改進的自然部分，而不是必須不惜一切代價避免的災難。

技術系統最終是由人為人設計的。透過認識到這一點，我們可以建立既技術上健全又人性化的可靠性策略，使組織能夠提供使用者真正需要的服務：足夠可靠，足夠頻繁。

完美不是目標，可靠才是關鍵

在技術領域中，我們常追求完美的解決方案，但現實是殘酷的：完美不存在，而與沒有人真正期望你做到完美。許多工程師陷入追求完美的迷思，最終卻導致專案延遲、功能堆積積和壓力增加。

真正重要的是可靠性——確保系統在各種條件下都能如預期運作。這正是為什麼可靠性堆積積疊（reliability stack）如此重要，它讓我們能夠確保系統「足夠可靠」，而不是徒勞地追求不可能的完美境界。

基礎架構：真正的力量所在

「為什麼選擇基礎架構，為什麼做維運？」多年前，一位開發同事在經歷特別棘手的值班輪替後問我這個問題。言下之意很明顯：誰會自願選擇這種生活？被傳呼機束縛，承受作為最後一線除錯者的壓力？

我毫不猶豫地回答：「因為這是力量所在。」

說完我自己都驚訝於這個答案。我們不習慣將基礎架構視為強大的角色。電腦科學系、媒體和大眾想像力都圍繞著演算法和資料結構，圍繞著那些撰寫程式碼、推出功能的英雄人物。

對商業人士而言，維運只是成本中心，一個不幸的必要支出。這只是歷史遺留物；維運應被視為開發的陰陽互補，密不可分，而非「別人的工作」。商業是「為什麼」，開發是「是什麼」，而維運則是「如何」。無論你的公司是一人還是上千人規模，這原則都適用。

程式碼的短暫與基礎架構的永恆

程式碼是短暫的。功能來了又走。在現代開發環境中開發產品，對我而言就像在天空中建造雲端城堡：抽象層疊加在其他抽象層之上，在心中構建這個豐富的思維世界。

軟體工程師是現代魔法師，製作難以想像的複雜咒語和咒文，將稻草變成金子，幾乎憑空創造巨大的實際價值。但當這些咒語出錯時，會發生什麼？

在我擔任系統管理員的第一份工作幾年後，我開始注意到一個模式：當非常資深的工程師來找我和其他維運人員時，他們比我更瞭解自己的程式碼，但當程式碼在生產環境中停止工作時，他們會驚慌失措。為什麼它不像昨天那樣工作？發生了什麼變化？彷彿生產環境是一個陌生的國度，他們需要我作為翻譯陪同他們。

基礎架構工程師的獨特視角

我總是欽佩那些能夠將「系統變慢了」轉化為「查詢計畫因使用了錯誤的複合索引而進行多次全資料表掃描」的人。任何人都能看出系統變慢了，但解釋原因才是真正有趣的下一層次。

軟體可能看起來與任何神秘學儀式一樣神秘和奧秘，但基礎架構工程師擁有一套工具，可以從各個可能的角度無情地檢查這個儀式。追蹤函式庫、掃描埠口、逐步執行系統呼叫、傾印封包。

基礎架構工具提醒我們，軟體按照科學現實主義的法則運作。每一個謎題只要有足夠的堅持，都會得到答案。這需要當事情出錯時保持一種歷經風霜的無畏。漏洞越困難和微妙，他們就越感興趣和充滿活力。

基礎架構工程師從未見過我們信任能按設計工作的抽象。宣告越巨集大，我們越悲觀。我們與其說是憤世嫉俗，不如說是嚴峻地確信一切都會失敗，而我們將不得不用迴紋針和焊接器來拯救世界。我們忍不住偷看蓋子下面，看為了修補程式而做了哪些可怕的事情。

當我們與其他基礎架構工程師一起喝酒時，我們會誇耀我們所見過的故障、發現的漏洞，以及「你不會相信上個假期發生了什麼」的故事。

知道如何自給自足、擁有工具和無畏的態度，能夠透過一層又一層的抽象追蹤答案，這就是力量所在。在每個技術堆積積疊的底部，都是光速，而這無法被幹擾或模擬。

思考系統彈性

在具彈性的系統中，即使其他變數偏離正常狀態，重要變數仍能保持在期望狀態。舉例來說，許多動物能夠避免因小傷口而死亡。當皮膚被割破，暴露出未受保護的攜帶血液的組織時，隨著凝塊形成，血液損失會迅速趨向於零。提高系統彈性使描述該系統的依賴變數更加獨立。

網路系統通常需要快速回應，以這樣的狀態表示：99百分位延遲低於一秒。理想情況下，這一點一直保持到系統的要求極限，例如，每秒100,000個請求的1秒峰值請求率。我們希望確保延遲變數不會過度依賴請求率變數。

提高系統彈性的方法

以下是我們提高彈性的方法：

負載減少

• 節流、負載脫落/優先順序排序、排隊、負載平衡

延遲減少

• 快取、區域複製

負載適應

• 自動擴充套件、過度佈建

彈性（特指）

• 超時設定、斷路器、隔板、重試、容錯轉移、回退策略

元技術

• 改進工具，可能用於更快速地擴充套件或容錯轉移；特別影響人類處於系統關鍵路徑的情況

這些工具中有些通常不與彈性相關聯（它們是一般最佳化技術），但都會影響關鍵變數的依賴性。有時它們以有用的方式相互作用。例如，重試可以糾正容錯轉移造成的暫時停機。

這些工具也在多個層面上重複出現。TCP重傳對抗封包丟失，但也使用應用層重試，因為TCP無法重試整個流（以及其他原因）。

延遲與請求率的關係

讓我們繼續延遲的例子。實際上，請求率與延遲之間的關係不是線性的，而通常遵循某種有理函式。在達到一定負載之前，系統不飽和與可以快速回應，但當負載接近容量時，佇列會迅速填滿，延遲相應增加。

我們可以透過新增伺服器來擴充套件系統，這會水平拉伸函式，允許在違反延遲目標之前處理更多請求。這需要成本。如果我們不喜歡這樣，可以考慮其他選項，例如負載脫落：當系統過載時（延遲達到極限）丟棄工作（限制請求率）。

錯誤也有金錢影響，但如果這種情況足夠罕見，它可能比支付更多伺服器的費用要少。透過首先丟棄不重要的工作，可以進一步降低成本。最重要的是，負載脫落方法完全防止了無限制的延遲增長，避免了潛在的連鎖故障。

透過建立彈性，我們可以幫助提高可靠性，使系統在不利條件下能夠反彈並繼續運作。

開發週期中的可觀測性

乾淨地捕捉漏洞、迅速解決它們，並防止它們成為拖累開發過程的技術債務積壓，這依賴於團隊快速找到這些漏洞的能力。然而，軟體開發團隊經常因各種原因阻礙自己這樣做的能力。

開發與維運的割裂

考慮這樣的組織：軟體工程師不負責在生產環境中操作他們的軟體。工程師將程式碼合併到主分支，交叉手指希望這個變更不會是那個打破生產環境的變更，然後等待在問題發生時被呼叫。有時他們在佈署後很快就被呼叫。然後佈署被回復，可以檢查觸發變更中的漏洞。

更可能的是，問題在程式碼合併後的數小時、數天、數週或數月內都不會被發現。到那時，極難找出漏洞的來源，記住連貫的背景與環境，或者解讀為什麼要寫那段程式碼或為什麼它被修改的原始意圖。

這種開發與維運的割裂反映了傳統組織結構中的一個深層次問題。當軟體工程師將程式碼視為「扔過牆」給維運團隊的產物時，就會產生責任感的缺失。這不僅延長了問題解決的時間，還會大增加組織的技術債務。這正是DevOps文化出現的原因之一——打破這種人為分隔，建立共同責任的模式。

可觀測性的重要性

缺乏有效的可觀測性工具是這個問題的主要原因。當工程師無法快速識別和診斷生產環境中的問題時，修復這些問題的週期就會變長，並且會變得更加痛苦。

真正有效的可觀測性策略需要三個關鍵元素：

1. 即時反饋：工程師需要在佈署後立即獲得關於其變更影響的反饋
2. 連貫的背景與環境保留：系統應該能夠保留足夠的連貫的背景與環境，使工程師能夠理解問題的根本原因
3. 團隊共同責任：整個團隊應該共同對生產環境的穩定性負責

透過將可觀測性整合到開發週期中，團隊可以顯著縮短從發現問題到解決問題的時間，並且大減少生產環境中的意外。

基礎架構工程師：現代技術組織的核心

在現代技術組織中，基礎架構工程師的角色已經從傳統的「維持系統執行」轉變為戰略性的技術長官角色。他們不再只是成本中心，而是成為推動創新和可靠性的關鍵力量。

基礎架構工程師的特質

成功的基礎架構工程師通常具有以下特質：

• 系統性思維：能夠從整體角度看待複雜系統，理解各元件之間的相互作用
• 韌性和適應力：面對壓力和不確定性時保持冷靜，並能快速適應變化
• 好奇心和學習能力：持續學習新技術和方法，保持對技術發展的敏銳度
• 溝通能力：能夠將複雜的技術概念轉化為業務人員能理解的語言
• 預見性：能夠預見潛在問題並提前解決，而不是被動應對

從成本中心到價值創造者

傳統上，基礎架構和維運被視為必要的成本中心。然而，隨著技術對業務成功的重要性增加，這種觀念已經開始改變。當我開始我的職業生涯時，基礎架構工程師常被視為「修電腦的人」。今天，他們更多地被視為使業務創新成為可能的關鍵推動者。

這種轉變的核心在於基礎架構工程師不僅瞭解「如何」使事情工作，還瞭解「為什麼」某些方法比其他方法更有效。他們能夠將技術決策與業務目標聯絡起來，確保技術投資產生最大的業務價值。

構建真正具有彈性的系統

構建具有彈

時間就是一切：快速除錯的關鍵

在軟體開發的世界裡，能否快速解決問題往往決定了一個系統的成敗。當錯誤發生時，最佳的除錯時機就是在程式碼剛撰寫完成並佈署後的短暫時間視窗內。此時，原始開發者對程式的意圖和邏輯仍然記憶猶新，問題的脈絡也最為清晰。隨著時間推移，這種理解會逐漸褪色，使得除錯變得越來越困難。

這正是可觀測性（Observability）在現代軟體開發中扮演關鍵角色的原因。然而，許多人對可觀測性的本質存在誤解，這些誤解可能導致除錯效率的大幅降低。

可觀測性與程式碼除錯的關鍵區別

初次接觸可觀測性的開發者常誤以為它是一種類別似於詳細日誌記錄的程式碼除錯工具。這種理解有失偏頗。可觀測性工具並非設計用來替代傳統的程式碼除錯器，它們的主要功能和操作層次完全不同：

• 可觀測性聚焦於系統層級，而非函式層級
• 程式碼除錯器深入到程式碼邏輯，著眼於程式碼行為

若嘗試使用可觀測性工具來追蹤程式碼每一行的執行情況，將會產生海量的資料，不僅會淹沒觀測系統，還會導致不合理的儲存和處理成本。根據我的經驗，這樣的做法可能會使監控系統的成本達到被監控系統本身的1-10倍。

可觀測性的真正價值：快速定位問題源頭

可觀測性工具的真正使命在於幫助開發者快速找出需要除錯的系統元件，而非直接除錯程式碼邏輯。當系統出現問題時，可觀測性工具能夠協助開發者回答以下關鍵問題：

• 錯誤來自哪個系統元件？
• 延遲在哪一環節被引入？
• 資料在哪個處理階段被異常修改？
• 哪一步驟消耗了最多處理時間？
• 效能問題是均勻分佈於所有使用者，還是僅影響特定群體？

透過回答這些問題，可觀測性工具能夠迅速縮小問題可能發生的範圍，為深入調查提供明確方向。在許多情況下，可觀測性還能提供關於問題性質的線索，例如問題是出在自己的程式碼、平台的程式碼，還是更高層級的架構設計。

從可觀測性到除錯：銜接兩個世界

一旦找到問題所在的元件和觸發條件，可觀測性的任務就完成了。接下來要使用的工具是程式碼除錯器（如gdb）。此時，開發者可以在本地環境中啟動一個程式碼例項，複製服務中的完整連貫的背景與環境，然後繼續深入調查。

可觀測性工具與除錯器之間的區別，就像望遠鏡與顯微鏡的差異：它們設計用於不同的尺度和目的。望遠鏡幫助我們找到星球，而顯微鏡則用於研究細胞結構。同樣，可觀測性幫助定位問題元件，而除錯器則用於解析程式碼邏輯。

揭開技術的神秘面紗：沒有魔法

在與電腦打交道時，系統的複雜性常讓人感到不知所措。我們寫一些程式碼，透過編譯器執行，然後在機器上執行它。這些過程看似神奇，但當問題出現時，重要的是要記住：這些系統並無魔法可言。

所有這些系統都是由和我們一樣的人類設計和構建的，這意味著它們同樣可以被像我們這樣的人類理解。從螢幕上的介面到處理器中的原子，每一步都是由某人經過思考後設計的。

雙層工作法：提升技術洞察力

在解決技術問題時，我發現同時在兩個層次上工作是非常有效的：一層是我正在編寫的程式碼，另一層是我正在使用的底層程式碼。我會在自己的工作和依賴項的原始碼之間來回切換，無論是Ruby gem、Go編譯器，甚至是在原始碼不可用時檢視反組譯程式碼。

這種連貫的背景與環境切換就像是軟體開發者的超能力：一種X光眼鏡。我們可以多次深入檢視：從我們的程式碼，到執行它的虛擬機器，再到它使用的C語言，最後到最終執行的組合語言。即便如此，我們還可以閱讀Intel x86手冊，嘗試弄清機器中發生的事情以及各種指令的編碼方式。

軟體系統本質上是分形的——每個元件本身就是一個完整的世界。當然，這並不意味著一個人可以理解所有內容。我們站在數千巨人的肩膀上，系統發展到今天的狀態凝聚了無數時間和智慧。

克服技術恐懼：從理解到掌控

從原子到圖形介面，深入瞭解每一步可能需要多個人生才能完成，這確實令人生畏。但這並不意味著我們不應該嘗試理解。

當我們假設那些構建軟體的元件是神秘的、無法理解或改變的經典時，就會做出不符合實際情況的決策。相反，我們需要更加清醒地看待技術，理解底層系統的特性並利用它們，而不是簡單地掩蓋問題。

下次當你使用的函式庫意外行為時，不妨多走一步，開啟引擎蓋。戳一戳內部機制，四處檢視，嘗試做一些改變。你會驚喜地發現全新的世界等待探索和改進。

維基百科的服務架構：複雜系統的例項

根據維基百科自身的定義，它是"一個多語言、根據網路、自由內容的百科全書專案，由維基媒體基金會支援，根據開放可編輯內容的模式”。作為全球存取量最大的網站之一，維基百科每月提供數十億的頁面瀏覽。當我們存取一個維基百科頁面時，背後發生了什麼？

維基百科架構的三大核心元件

維基百科的基礎架構有三個最重要的構建塊：

1. CDN（內容分發網路）：作為快取層
2. 應用層
3. 開放原始碼軟體

當你請求一個頁面時，地理DNS和網路由的魔力會根據你的位置將請求傳送到最近的維基媒體資料中心，同時透過TLS和ATS（Apache Traffic Server）加密你的連線。

快取層與請求流程

每個資料中心都有兩個快取層：

• 記憶體快取（Varnish）
• 磁碟快取（ATS）

大多數請求在此終止，因為最熱門的URL總是被快取。如果出現快取未命中，請求將被轉發到應用層，如果這是一個主要資料中心，應用層可能非常近；如果這只是一個快取點，則可能稍遠一些。

應用層架構

維基百科的應用層以MediaWiki為核心，並由多個微服務和資料函式庫支援。MediaWiki是一個根據Apache、PHP和MySQL的開放原始碼應用程式，專為維基百科開發。當需要渲染文章時，MediaWiki會首先在Memcached中查詢已渲染版本，如果未找到，則在被稱為Parser Cache的MariaDB資料函式庫中查詢。

如果MediaWiki在Memcached和Parser Cache中都未命中，它將提取文章的Wikitext並渲染它。文章儲存在兩個資料函式庫中：

1. Wikitext叢集：以blob形式儲存Wikitext
2. 元資料叢集：告訴MediaWiki文章在Wikitext叢集中的位置

文章渲染後，會依次儲存在所有前面提到的快取中，並回傳給使用者。

媒體檔案處理流程

對於媒體檔案請求，流程稍微簡單一些。當快取層出現未命中時，ATS將直接從Swift（OpenStack的可擴充套件物件儲存系統）取得檔案。

應對高流量挑戰

MediaWiki被非常厚的快取層所包圍，原因很簡單：渲染頁面成本高昂。此外，當頁面被編輯時，需要從所有這些快取中使其失效，然後再次填充。

當非常著名的人去世時，維基百科的基礎設施會經歷一種稱為"名人死亡峰值”（或"麥可·傑克森效應”）的現象。在這種情況下，大量使用者湧向維基百科閱讀相關文章，同時編輯者不斷更新該人物的條目，導致編輯率飆升。這可能最終導致顯著的負載，因為大量的讀取流量集中在一個不斷被編輯的文章上。

系統除錯的實用策略

在處理複雜系統問題時，我發現以下策略特別有效：

從系統層面思考問題

當遇到問題時，首先要確定這是系統級問題還是程式碼邏輯問題。對於系統級問題，使用可觀測性工具來縮小範圍；對於程式碼邏輯問題，則使用除錯器深入調查。

建立多層次的監控體系

有效的監控應該覆寫多個層次：

1. 基礎設施監控：關注伺服器、網路和資源使用情況
2. 應用程式監控：追蹤關鍵API和服務的效能
3. 業務監控：監控對使用者直接可見的指標

保持快取一致性的最佳實踐

在像維基百科這樣依賴多層快取的系統中，保持快取一致性至關重要。我建議採用以下方法：

1. 明確的失效策略：當資料更改時，確保所有相關快取都被正確失效
2. 版本化快取鍵：使用包含版本資訊的快取鍵，避免服務不同版本的資料
3. 快取預熱：對於關鍵路徑，在需要前主動填充快取

平衡快取與鮮活度

在設計系統時，需要在資料鮮活度和系統效能之間取得平衡。對於不同類別的資料，可以設定不同的快取策略：

• 頻繁變化的資料使用短期快取或不快取
• 相對穩定的資料使用長期快取
• 考慮使用事件驅動的快取失效機制，而非簡單的時間過期

深入理解系統行為的技術

要真正掌握系統行為，需要超越表面現象，深入理解底層機制。以下是一些我經常使用的技術：

構建系統模型

在處理複雜系統時，建立一個簡化的系統模型有助於理解關鍵元件之間的互動。這可以是一張流程圖、元件圖或甚至是簡單的文字描述。重要的是要捕捉系統的核心行為，而不是每一個細節。

有目的實驗

當系統行為不明確時，設計有針對性的實驗可以揭示底層機制。這些實驗應該：

• 有明確的假設
• 可測量的結果
• 控制變數
• 可重複的過程

從原始碼中學習

正如前面提到的，深入研究依賴函式庫架的原始碼是理解系統行為的強大方法。這不

開放原始碼軟體：維基百科基礎架構的支柱

維基百科的技術基礎設施有一個關鍵特性：全面採用開放原始碼軟體。從維基百科的基礎設施到內部開發的應用程式和工具，每一個元件都是開放原始碼的。這種開放原始碼策略不僅體現了維基百科的核心價值觀，更深刻影響了其技術選擇和社群參與模式。

維基百科社群的貢獻不僅限於各種專案的內容維護，還延伸到支援這些內容的軟體和系統開發。開放原始碼模式使社群成員能夠直接參與技術建設，成為維基百科不可或缺的一部分，也是驅動技術決策的核心力量。

這種開放原始碼精神反映了康威定律的一種實踐：致力於推廣自由知識的網站，選擇在自由軟體上執行。對很多人來說，一個全球最受歡迎的網站僅靠開放原始碼軟體運作與沒有龐大的工程師團隊，可能聽起來令人驚訝。但這正是維基百科的特質—開放性已成為其存在的基本元素。

為何你應該瞭解 TCP（哪怕只是一點）

神秘的 40 毫秒延遲

在我的工作經歷中，曾遇到一個有趣的問題：有同事在公司內部通訊軟體上提到：「嘿，我每次向 NSQ 發布訊息都要花 40 毫秒。」背景說明一下，NSQ 是一個訊息佇列系統，發布訊息的方式是向 localhost 傳送 HTTP 請求。向本地傳送 HTTP 請求花費 40 毫秒實在太不合理了—這明顯有問題。

檢查後發現，NSQ 守護程式的 CPU 負載並不高，記憶體使用也正常，甚至不像是處於垃圾回收暫停狀態。問題到底出在哪裡？

這讓我想起一週前閱讀的一篇文章：《追求效能：如何從每個 POST 請求中削減 200 毫秒》。該文描述了兩個 TCP 特性（延遲確認和納格演算法）的組合如何為每個 POST 請求增加大量額外時間。

TCP 特性如何降低 HTTP 請求速度

延遲確認（Delayed ACKs）和納格演算法（Nagle’s algorithm）如何使 HTTP 請求變慢？讓我解釋這篇文章中描述的情況：

他們的環境設定：

• 應用程式向 HAProxy 傳送請求
• HTTP 函式庫uby 的 Net::HTTP）以兩個小封包傳送 POST 請求（一個用於標頭，一個用於主體）

TCP 交換過程是這樣的：

1. 客戶端：嗨！這是第一個封包。
2. 伺服器：〈沉默〉（「我最終會傳送 ACK，但讓我們等待第二個封包。」）
3. 客戶端：〈沉默〉（「我有更多資料要傳送，但讓我們等待 ACK。」）
4. 伺服器：好吧，我厭倦了等待。這是 ACK。
5. 客戶端：太好了，這是第二個封包！！！

客戶端和伺服器都在消極地等待對方傳送訊息的那段時間，就是造成額外 200 毫秒延遲的原因！客戶端因納格演算法而等待，伺服器因延遲確認而等待。

在 Linux 上，延遲確認和納格演算法預設都是啟用的，所以這種情況並不罕見。如果你的資料分成多個 TCP 封包傳送，就可能遇到這個問題。

納格演算法（Nagle’s Algorithm）設計用來提高網路效率，它會嘗試將小封包合併成較大的封包再傳送。延遲確認（Delayed ACKs）則是接收端的一種最佳化，它會等待一小段時間再確認收到的封包，希望能夠在一個確認訊息中確認多個封包。當這兩種機制同時運作時，就會形成上述的「互相等待」局面，導致不必要的延遲。

解決方案：TCP_NODELAY

解決方法是 TCP_NODELAY。當我讀到這篇文章時，我想：「這不可能是我的問題，對吧？問題不可能出在 TCP 上！」但我瞭解到可以透過在客戶端啟用 TCP_NODELAY 來修復這個問題，這個 socket 選項會停用納格演算法。

這看起來很容易測試，所以我提交了一個變更，為我們的應用程式開啟了 TCP_NODELAY，結果非常驚人。所有 40 毫秒的延遲立即消失。問題解決了，就像變魔術一樣簡單。

如果不瞭解 TCP，就無法解決 TCP 問題。我曾經認為 TCP 是非常底層的東西，我不需要了解它—這在大多數情況下確實如此！但有時在實際工作中，你會遇到一個 bug，而這個 bug 正是由於 TCP 演算法中的某些特性造成的。

在維運工作中，我發現很多這類別 bug 都是由系統中我之前認為晦澀難懂的底層元件引起的，而我突然需要快速深入瞭解這些元件。

我之所以能夠理解並修復這個 bug，是因為兩年前我花了一週時間用 Python 編寫了一個玩具級的 TCP 堆積積疊，學習 TCP 的運作原理。對 TCP 協定和封包確認方式的基本理解確實幫助我解決了這個問題。

管理介面的重要性

在系統故障期間，你更關心能否控制系統，而不是系統能否回應所有導向使用者的請求。借鑑網路硬體中控制平面的概念，工程師可以將資料傳輸責任與控制訊息分離。控制平面為管理和操作任務提供統一的入口點，與傳送使用者資料本身的功能區分開來。從可靠性角度看，這種分離為操作人員提供了一種方法，即使系統無法按預期運作，也能對其進行管理。

從 Google 檔案系統的教訓

在 Google 檔案系統（GFS）的早期版本中，單一指定節點負責所有資料查詢：成千上萬的客戶端開始請求資料時，都要向這個節點詢問資料的標準位置。這個節點同時還負責回應管理請求，如「目前佇列中有多少資料請求？」

同一個程式負責這兩組請求—一組導向使用者與至關重要，另一組純粹內部但同樣關鍵—並且從同一個執行緒池中提供對這兩組請求的回應。這意味著當伺服器過載無法處理傳入請求時，負責系統的 SRE（網站可靠性工程師）也無法傳送管理請求來減輕負載！

由於客戶需求從未讓 GFS 的早期版本如此過載，這種請求爭用問題之前並未顯現。在下一個版本中，Google 團隊將關鍵路徑中操作所需的資源與管理操作所需的資源分離，使用控制平面，GFS 的生產品質因此得到了顯著提升。

管理階層與資料層的分離

將這個概念擴充套件到多個服務，單一管理程式介面的好處變得明顯：自動化軟體可以向異構伺服器組傳送「更新到新版本」指令，這些伺服器可以相應地解釋並執行。

捨棄網路術語，我們可以將請求分為管理階層和資料層，並看到對於任何處於關鍵路徑的服務，分離這兩者的重要性。透過在導向使用者的操作之間劃定界限，我們對應用於資料測量的儀器也能更有信心；資料層中的操作將使用並測量該層中的資源，而不與管理階層中的操作混合。這反過來又導致了測量導向使用者操作的更成功方法，這是服務水準目標的有用指標。

如何確定管理請求與使用者請求的隔離

如何知道你何時正確隔離了管理請求和使用者請求？像 OpenTracing 這樣的工具可能會顯示管理呼叫和使用者請求的完整路徑，可能暴露意外的互動。實際上，你的系統可能會有連線點，例如管理介面實際影響使用者路徑的地方。雖然這種分離不是完全的，但 SRE 應該能夠識別他們構建和操作的系統中的這些部分之間的界限。

實作分離的策略

對於已經構建的軟體（如第三方應用程式），你可能需要新增一個單獨的服務，它像邊車（sidecar）一樣附加到核心軟體上，並透過 HTTP 伺服器等通用介面提供管理 API 的端點。這種粘合式的管理階層可能是最終與核心軟體整合的前兆，也可能是長期解決方案。

這種系統設計方法將服務導向使用者請求的請求路徑與管理功能所需的路徑分開，確保即使在高負載或故障情況下，管理功能仍然可用。

技術架構設計的關鍵思考

從上述案例中，我們可以歸納一些關鍵的系統設計原則：

1. 瞭解底層協定：即使是看似基礎的 TCP 協定細節，也可能對應用程式效能產生重大影響。工程師應該對其系統使用的關鍵協定有基本瞭解。

2. 分離控制平面與資料平面：這種分離不僅適用於網路裝置，對任何複雜系統都非常重要。它確保即使在系統壓力下，管理功能仍然可用。

3. 開放原始碼的力量：維基百科的例子表明，開放原始碼不僅是一種軟體許可模式，更是一種能夠產生驚人結果的協作方式。

4. 系統設計要考慮故障模式：設計系統時，不僅要考慮正常運作，還要思考各種故障情況下的行為。

在現代分散式系統中，這些原則變得越來越重要。隨著系統複雜度的增加，我們需要更人工智慧的方式來管理和監控這些系統，而理解底層技術細節和實施良好的架構分離是達成這一目標的關鍵步驟。

系統設計不僅是關於功能實作，更是關於如何建立可靠、可管理與能夠優雅處理各種情況的架構。無論是理解 TCP 的微妙之處，還是實施管理與資料分離，這些看似小的決策都可能對系統的整體健康和效能產生深遠影響。 I’ll help you process this continuation of the SRE book. Let me create a professional article in the style of the BlackCat author.

分散式儲存：超越傳統儲存的可靠性革命

在現代應用程式世界中，從智慧型手機到瀏覽器應用，每一個數位互動都在產生並儲存資料。作為SRE工程師，我們經常需要負責管理這些從智慧家電、交通路線規劃到貓咪照片分享等各種應用產生的海量資訊。隨著資料量的爆炸性成長，分散式儲存系統因其卓越的容錯能力和可靠的資料管理方式而受到廣泛採用。

分散式儲存的本質優勢

分散式儲存與傳統的儲存裝置、儲存陣列或實體連線的儲存有本質上的不同：它將資料生產者與實際儲存媒體解耦。這種解耦帶來的好處不僅是技術架構上的變革，更直接影響了使用者經驗的兩個核心要素：速度與可靠性。

在我多年的系統設計經驗中，發現分散式儲存帶來的最大優勢在於它能夠支援平行使用者端存取。由於系統將資料寫入多個位置，不再有單一磁碟讀寫頭阻塞所有讀取操作的問題。當某些資料變得特別熱門（例如一段爆紅的影片）時，系統還可以非同步地建立更多資料副本，以支援來自使用者端不斷增加的讀取需求。

這種水平擴充套件能力是分散式系統的獨特優勢。雖然RAID系統也會儲存資料的多個副本，但它們無法以同樣的方式支援平行使用者端讀取。

服務持續性的保障

建構在分散式儲存系統上的應用程式為組織帶來了另一個顯著優勢：不再需要發布「我們的服務將於今晚3-4點進行計畫性維護而暫時不可用」這類別通知。因為系統中沒有單一的儲存裝置，而是一個具有複製和冗餘機制的完整儲存系統。

現代網路服務承諾提供全球一致的資料檢視，無論是為單一使用者還是大型組織服務，如果沒有分散式儲存系統，這幾乎是不可能實作的。在過去，這需要昂貴的裝置間同步，基本上就是從一台特定電腦到另一台電腦複製磁碟或目錄樹，而每個裝置都是單點故障(SPOF)。

容錯能力的提升

容錯能力是可靠性的核心組成部分。透過在不同裝置間分擔風險，分散式儲存系統能夠容忍傳統儲存裝置無法應對的故障。雖然儲存裝置可能有多個本地電源模組，但分散式儲存系統不僅具有類別似的電源冗餘，還有機架級別的電源多樣性。

這進一步稀釋了風險，當分散式儲存系統利用這種多樣性來最佳化資料放置時，將使資料儲存具備對多層次電源故障的彈性。我曾見過一個大型分散式系統在經歷了整個資料中心的電力中斷後依然保持了99.9%的服務可用性，這在傳統架構下幾乎是不可想像的。

SRE與分散式儲存的監控策略

負責分散式儲存系統的SRE工程師需要關注與傳統網路附加儲存裝置不同的指標。例如，他們需要監控離散資料區塊的計算可還原性。這涉及到理解系統的實作：

1. 儲存系統如何佈局資料，以及在哪裡複製構成資料的部分？
2. 系統需要多久重新複製一次資料以維持風險多樣性？這是系統能夠準確檢索資料的指標。
3. 系統元資料的快取未命中頻率如何？這會導致更長的資料檢索時間。

對於全球規模的分散式儲存系統，這些指標比傳統的磁碟使用率或I/O延遲更能反映系統的健康狀況。在我的實踐中，發現建立完善的指標監控體系，不僅能夠提前發現潛在問題，還能夠指導系統的容量規劃和擴充套件策略。

基數：可觀察性的關鍵因素

基數的本質與重要性

在資料函式庫，基數(cardinality)指的是一組資料中所包含的唯一值的程度。低基數意味著一個欄位在其集合中有許多重複值；高基數則表示該欄位包含大比例的完全唯一值。

舉個例子，如果你有一億條使用者記錄，可以假設使用者ID號碼將具有最高的基數。名字和姓氏的基數會很高，但因為有些名字會重複，所以低於使用者ID。性別欄位的基數會相對較低，考慮到它可能有的非二元但有限的選項。而物種欄位（假設所有使用者都是人類）將具有最低的基數。

基數對可觀察性的影響

基數之所以對可觀察性至關重要，是因為高基數資訊是除錯或理解系統最有用的資料。考慮按使用者ID、購物車ID、請求ID或其他無數ID（如例項、容器、構建編號、跨度等）進行排序的實用性。能夠針對唯一ID進行查詢是在任何給定的大海撈針中精確定位個別針的最佳方式。

在我處理大規模系統問題時，高基數維度常是找出問題根源的關鍵。例如，當某個服務出現間歇性故障時，能夠按照使用者ID或工作階段ID過濾日誌，往往能夠迅速定位到問題的特定模式或邊緣情況。

根據指標工具的限制

不幸的是，根據指標的工具系統在任何合理的規模下只能處理低基數維度。即使你只有幾百台主機需要比較，使用根據指標的系統，你也無法使用主機名作為識別標籤，否則會很快達到基數鍵空間的限制。

這些固有限制對資料查詢方式產生了意想不到的約束。使用指標進行除錯時，對於你可能想問的每個問題，你必須提前決定（在錯誤發生之前）需要詢問什麼，以便在寫入該指標時記錄其值。

這種固有限制有兩個重大影響：

1. 如果在調查過程中，你決定必須提出額外問題以發現潛在問題的來源，那麼事後無法做到。你必須首先設定可能回答該問題的指標，然後等待問題再次發生。

2. 由於回答額外問題需要另一組指標，大多數根據指標的工具供應商會對記錄這些資料收費。你決定以新方式查詢資料以發現無法預測的隱藏問題，成本就會線性增加。

可觀察性工具的優勢

相反，可觀察性工具鼓勵開發人員收集每個可能發生的事件的豐富遙測資料，傳遞任何給定請求的完整連貫的背景與環境，並將其儲存以備將來可能使用。

可觀察性工具專門設計用於針對高基數資料進行查詢。這對除錯意味著你可以任意多種方式查詢事件資料。你可以提出事先不需要預測的新問題，並找到這些問題的答案，或者找到線索來引導你提出下一個問題。你一次又一次地重複這種模式，直到找到你在俗話說的大海中要找的那根針。

安全就像洋蔥：多層次防護策略

安全意識的覺醒時刻

想像一下這個場景：你的公司正在實作夢想。你已經找到了產品與市場的契合點，銷售額在增長，IPO或被收購的想法穩步接近現實。有一天，長官團隊引入外部幫助來引導IPO流程，對話是這樣的：

顧問：一切看起來都很棒！那麼，請告訴我們，你們的安全情況如何？
長官層：嗯，我們還沒有被駭客攻擊，所以我認為安全性相當不錯！
顧問：你怎麼知道你們沒有被駭客攻擊？你們的安全策略是什麼？

這種對話在我的職業生涯中出現過多次，它揭示了一個關鍵問題：許多組織對安全的認識僅限於「還沒有發生明顯問題」。然而，現代安全威脅往往是隱蔽的，可能在系統中潛伏數月甚至數年而不被發現。

安全如同洋蔥的多層次結構

真正有效的安全策略應該像洋蔥一樣，具有多個防禦層。這種「縱深防禦」(defense in depth)的方法確保即使一層防禦被突破，其他層仍然可以保護系統和資料。

在構建安全如洋蔥的多層次防護時，應考慮以下關鍵層面：

1. 外部邊界保護：包括防火牆、入侵檢測系統和DDoS防護
2. 身分驗證與授權：強大的身份驗證機制和細粒度的存取控制
3. 資料加密：靜態和傳輸中的資料加密
4. 內部網路分段：限制橫向移動的能力
5. 持續監控與異常檢測：主動發現可疑活動
6. 安全回應計劃：當防禦被突破時的明確程式

每一層都應該被設計為獨立的安全控制，但同時與其他層協同工作。例如，即使攻擊者突破了外部防火牆，內部網路分段和異常檢測仍然可以限制其移動並發現其存在。

安全意識與文化建設

技術防護措施只是安全洋蔥的一部分。同樣重要的是建立強大的安全文化，其中包括：

• 定期的安全培訓和意識計劃
• 鼓勵報告可疑活動的文化
• 安全考慮融入開發生命週期的每個階段
• 定期的安全評估和滲透測試

在我的經驗中，最成功的安全計劃是那些將安全視為持續過程而非一次性專案的計劃。安全不是你「完成」的事情；它是你不斷改進和適應的事情。

整合視角：分散式系統中的可觀察性與安全

在現代SRE實踐中，分散式儲存、可觀察性和安全性並非孤立的概念，而是相互增強的實踐。高品質的可觀察性不僅有助於識別效能問題，還能發現可能的安全威脅。同樣，安全的分散式儲存系統需要強大的可觀察性來確保其健康運作。

當我們設計和維護分散式系統時，應將這三個方面視為一個整體：

1. 分散式儲存提供了可靠性和彈性的基礎
2. 可觀察性（特別是高基數資料）使我們能夠理解系統行為和診斷問題
3. 多層次安全保護我們的系統和資料免受威脅

透過這種整合視角，現代SRE可以構建既可靠又安全的系統，同時保持對系統行為的深入理解。在快速變化的技術環境中，這種全面方法不僅是最佳實踐，而與是必要的生存策略。

分散式系統的世界充滿了挑戰，但也提供了前所未有的機會來構建更強大、更有彈性的服務。作為SRE，我們的任務是駕馭這種複雜性，並將其轉化為使用者可以信賴的可靠系統。透過深入理解分散式儲存的原理、重視高基數資料的可觀察性，並實施多層次的安全策

安全長官力：SRE的安全框架實踐

作為站點可靠性工程師(SRE)，引導安全控制並自信地回答風險管理問題是我們的核心職責之一。然而，面對安全這個廣闊的領域，從何處著手常令人困惑。經過多年的實踐，玄貓發現NIST的網路安全框架提供了一個絕佳的起點，其五大核心功能—識別、保護、檢測、回應和還原—構成了一個全面的安全治理模型。

這個框架不僅適用於大型企業，對於各種規模的團隊都具有實用價值。你可以直接採用它，或將其作為開發專屬安全策略的基礎。讓我們探討這五個核心功能，並看SRE如何在每個環節發揮關鍵作用。

識別：瞭解你的關鍵資產

識別階段要求我們明確哪些系統、資料和資產對業務連續性至關重要。這不僅是列出所有資源，而是要評估每個資源相關的風險，以及實作理想安全狀態所需的變更。

在這個階段，玄貓建議問自己以下關鍵問題：

• 什麼措施防止未授權人員接觸我們在機房的伺服器？
• 如何處理遺失的筆記型電腦或手機？
• 哪些系統持有最敏感的客戶資料？
• 我們的關鍵業務功能依賴哪些技術基礎設施？

要有效開展識別工作，SRE需要熟悉裝置加密和基本的行動裝置管理(MDM)技術。這些技術能在不影響使用體驗的同時大幅提升安全性。

實用識別策略

我在一個中型科技公司實施資產識別策略時，首先建立了一個資產重要性矩陣，將各系統按照「業務影響」和「資料敏感度」進行分類別。這種方法幫助我們將有限的安全資源集中在最關鍵的系統上，而不是平均分配。

對於識別階段，一個實用的做法是建立資產登記冊，記錄以下資訊：

# 資產登記冊範例
asset_registry = {
    "payment_processor": {
        "criticality": "high",
        "data_sensitivity": "PII/financial",
        "dependencies": ["database_cluster", "auth_service"],
        "current_controls": ["encryption", "access_control"],
        "gaps": ["no_hardware_security_module"]
    },
    "marketing_website": {
        "criticality": "medium",
        "data_sensitivity": "public",
        "dependencies": ["cdn", "cms"],
        "current_controls": ["waf", "ddos_protection"],
        "gaps": ["outdated_cms_version"]
    }
}

這段程式碼展示了一個簡單但實用的資產登記冊結構，採用Python字典格式。每個資產（如支付處理器和行銷網站）都有對應的關鍵屬性：關鍵性級別、資料敏感度、依賴關係、目前的安全控制措施，以及已識別的安全缺口。這種結構化的資產識別方法能幫助SRE團隊快速瞭解系統全貌，並優先處理高風險區域。特別注意「gaps」欄位，它直接指出了需要改進的安全控制點，為後續的保護階段提供明確方向。

保護：限制安全事件的影響

不愉快的網路安全事件是無法完全避免的現實。保護功能的核心是在事件發生時限制或控制其影響範圍。關鍵在於培訓、業務連續性和供應鏈管理。

作為SRE，我們需要確保以下幾點：

1. 所有團隊成員都接受身份管理、特權資料操作和遠端存取相關的培訓
2. 業務連續性和災難還原控制措施得到完整記錄並定期演練
3. 程式碼供應鏈得到充分保護，包括實施程式碼掃描和第三方授權管理

在實施保護措施時，我發現深度防禦(Defense in Depth)策略尤為有效。不要依賴單一的安全控制，而是建立多層防護，即使一層失效，其他層仍能提供保護。

保護策略例項

以下是一個簡單的多層防護策略範例：

# 多層防護設定範例
protection_layers:
  network:
    - perimeter_firewall
    - internal_segmentation
    - intrusion_detection
  
  application:
    - input_validation
    - output_encoding
    - authentication
    - authorization
    
  data:
    - encryption_at_rest
    - encryption_in_transit
    - access_controls
    - data_minimization
    
  endpoint:
    - device_encryption
    - mdm_solution
    - endpoint_protection

這個YAML設定展示了一個結構化的多層防護策略，分為網路、應用程式、資料和端點四個層面。每個層面都包含多個安全控制，形成一個完整的保護網。這種分層方法的優勢在於，即使攻擊者突破了一個層面（例如網路防護），仍需面對其他層面的防護措施。作為SRE，實施這種策略時應確保各層面之間沒有安全漏洞，與定期測試每個控制點的有效性。特別值得注意的是，這種設定可以作為安全架構檔案的基礎，幫助團隊成員理解整體安全策略。

檢測：及時發現安全異常

良好的檢測系統應具有多層結構，在每一層失效時發出警示。檢測系統最重要的特性是平均檢測時間(MTTD)，這決定了你對網路安全事件的反應速度。

檢測的目標是發現異常和事件，並瞭解其潛在影響。確保手動測試檢測系統，驗證其準確性。我發現，許多組織在建立檢測系統時過度依賴工具，而忽視了連貫的背景與環境理解的重要性。

有效的檢測需要結合自動化工具和人工分析，尤其是在判斷警示優先順序時。以下是一個簡單但有效的事件檢測評分系統：

// 安全事件評分系統
function scoreSecurityEvent(event) {
  let score = 0;
  
  // 評估資產重要性
  if (event.assetCriticality === "high") score += 30;
  else if (event.assetCriticality === "medium") score += 15;
  else score += 5;
  
  // 評估異常程度
  if (event.anomalyLevel === "high") score += 30;
  else if (event.anomalyLevel === "medium") score += 15;
  else score += 5;
  
  // 評估潛在影響
  if (event.potentialImpact === "high") score += 40;
  else if (event.potentialImpact === "medium") score += 20;
  else score += 5;
  
  // 根據分數確定優先順序
  if (score >= 70) return "critical";
  else if (score >= 50) return "high";
  else if (score >= 30) return "medium";
  else return "low";
}

這段JavaScript函式實作了一個簡單但實用的安全事件評分系統。它根據三個關鍵因素為事件評分：資產重要性、異常程度和潛在影響。每個因素都有不同的權重，反映了它們在安全風險評估中的相對重要性。特別值得注意的是潛在影響因素被賦予最高權重（最高40分），這符合風險評估的基本原則——後果嚴重性通常是風險評估的首要考量。

函式最終根據總分將事件分為四個優先順序：關鍵、高、中、低。這種評分機制能幫助SRE團隊在面對大量警示時快速識別最需要關注的事件。實際應用中，你可能需要根據組織特定需求調整權重和閾值，並可能加入更多評分因素，如異常發生的時間段、受影響的使用者數等。

回應：計劃與執行

“計劃可能無用，但規劃卻是不可或缺的”。在網路安全事件即將發生或正在進行時，你將如何回應？

回應階段需要規劃以下活動：

• 如何確定攻擊的影響範圍？
• 如何隔離攻擊造成的損害？
• 哪些內部和外部溝通通路需要被通知？

一個常被忽視的部分是識別需要被通知的內部和外部溝通通路。在規劃時，記得考慮這些通路是否可能作為攻擊的一部分被破壞。

有效的回應計劃範例

以下是一個簡化的回應計劃框架：

安全事件回應計劃

1. 初始評估 (T+0 到 T+30分鐘)

• 確認警示真實性
• 初步判斷事件類別和嚴重程度
• 通知事件回應團隊

2. 控制與遏制 (T+30分鐘到 T+2小時)

• 隔離受影響系統
• 儲存證據
• 阻止進一步擴散

3. 消除與還原 (T+2小時到 T+24小時)

• 移除惡意軟體或漏洞
• 還原系統至安全狀態
• 持續監控異常活動

4. 後續活動 (T+24小時後)

• 完成事件報告
• 更新安全控制
• 進行團隊複盤

這個計劃提供了一個時間框架和每個階段的關鍵活動，可作為事件回應的基礎。在實際實施中，必須根據組織特定的風險情境和資源進行調整。

還原：向前邁進

生活總是向前發展。這意味著我們需要思考如何從網路安全事件中還原階段應包括對事件的反思，並指導對框架的更改，以防止類別似事件再次發生，並增強組織和客戶的信心。

在外部，這意味著以事件回顧的形式撰寫報告，以重獲公眾信任。在內部，必須審查事件期間所做的更改及其對當前操作手冊、監控和檢測系統的影響。

還原階段的一個關鍵方面是學習。一個好的事件後分析（Post-Mortem）應包含以下元素：

// 事件後分析結構
interface IncidentPostMortem {
  // 事件概述
  summary: string;
  
  // 時間軸
  timeline: {
    timestamp: Date;
    event: string;
    actor: string;
  }[];
  
  // 根本原因分析
  rootCause: {
    technical: string;
    process: string;
    people: string;
  };
  
  // 影響評估
  impact: {
    systems: string[];
    users: number;
    businessMetrics: Record<string, number>;
  };
  
  // 改進行動
  actionItems: {
    description: string;
    owner: string;
    dueDate: Date;
    category: "prevention" | "detection" | "response" | "recovery";
  }[];
  
  // 經驗教訓
  lessonsLearned: string[];
}

這個TypeScript介面定義了一個結構化的事件後分析（Post-Mortem）檔案格式。它包含六個主要部分：事件概述、詳細時間軸、根本原因分析、影響評估、改進行動和經驗教訓。

特別值得注意的是根本原因分析部分，它從技術、流程和人員三個維度進行分析，這種多角度分析有助於識別事件背後的系統性問題，而不僅是表面的技術故障。

改進行動部分也很關鍵，它不僅定義了需要採取的措施，還明確了責任人、截止日期，以及該行動屬於哪個安全框架類別（預防、檢測、回應或還原）。這種分類別有助於確保改進措施能夠

職涯決策的多維思考：不只是薪資數字

在科技產業工作多年，玄貓發現許多技術專業人士在考慮工作機會時，往往把注意力過度集中在薪資數字上。雖然計算哪個offer在財務上最有價值相對容易，但真正的職涯決策遠比較數字複雜得多。

財務需求的個人化評估

在評估薪資時，我建議從個人實際需求出發，而非單純追求理論上的最佳解。例如，大筆的簽約獎金在短期內提供現金流，而股票單位則可能隨時間增值。關鍵問題是：你現在真正需要多少資金？以及何時需要？

如果你正面臨購屋首付、償還學貸或其他重大財務壓力，那麼立即可用的現金可能比潛在更高價值的長期股票更為重要。相反，如果你的短期財務狀況穩定，長期增值的股票可能更有吸引力。

福利評估：超越純金錢價值

福利雖然是整體薪酬的一部分，但我發現將福利純粹以金錢角度思考往往是個錯誤。例如，兩個健康保險方案在貨幣價值上可能相近，但其中一個可能不包含對你至關重要的特定保障，如避孕藥、特定療程或家庭成員的保障範圍。

在評估福利時，我建議建立一個人需求清單，然後評估每個offer如何滿足這些需求：

• 健康保險是否涵蓋你和家人的特定需求？
• 退休計劃的比對比例如何？
• 有多少帶薪休假？
• 工作時間彈性如何？
• 是否有遠端工作選項？
• 提供哪些專業發展資源？

非財務因素的重要性

移民與工作安全性

對於在非本國公民身份工作的人來說，不同公司能提供的工作和移民安全性差異巨大。我曾見過許多人為了高薪而選擇缺乏移民支援的公司，最終因簽證問題被迫離開。

在這方面，大型跨國企業通常擁有完善的移民支援系統和全球辦公室網路，如果移民出現問題，他們常有應急方案。相比之下，小型新創公司往往缺乏這些資源，導致移民問題時員工面臨更大風險。

公司使命與價值觀

我認為工作不僅是薪水來源，也是我們價值觀的體現。選擇一家使命與你的道德價值觀一致的公司至關重要。拒絕為你在道德上不認同的公司工作，並明確表示這是你拒絕的原因，可能是一種有力的行動。

然而，玄貓必須坦言，能夠根據價值觀選擇工作本身就是一種特權。如果你是該領域新人或在其他方面處於弱勢，這種選擇的自由可能暫時不存在。

理想團隊特質：給未來團隊的一封信

在思考新工作機會時，團隊文化往往比正式面試和職位描述更能預測你的長期滿意度。以下是我認為理想團隊應具備的特質：

分享時間與知識

理想的團隊會一起午餐，雖然不必每天，但有機會在會議之外交流至關重要。團隊成員樂於介紹附近的其他團隊，指出哪個團隊擅長特定工具、特定類別的問題或分享服務。

好奇與提問文化

最好的團隊鼓勵提問，即使是看似簡單或顯而易見的問題。他們不斷探索事物的運作方式、為何如此設計、為何以特定方式做事，以及專案試圖創造什麼價值。在這樣的環境中，沒有「愚蠢的問題」。

故事分享與團隊記憶

玄貓特別欣賞那些喜歡講故事的團隊。無論是成就故事、艱難教訓，還是有趣的發現，這些故事使團隊成員感到與團隊歷史的聯絡，並能在此基礎上繼續建設。

我的第一個團隊引以為傲的是，為任何願意聆聽的人繪製地圖，包括我們如何陷入依賴迴圈、除了下劃線之外名稱相同的元件，以及為何展開TDS的名稱如此繁瑣的每個有趣故事。最好的裝飾是隨時間變得更加豐富的架構圖白板，吸引著一群有興趣的旁觀者前來提問。

活躍的技術討論氛圍

理想團隊可能是樓層上最吵的團隊，積極辯論新想法，傾聽每個人，在技術上有分歧但不進行人身攻擊。他們有大膽想法，不怕嘗試，相信現狀不必永遠保持。團隊成員對自己的工作感到興奮，為其影響力感到自豪。

信任的管理關係

在理想團隊中，你相信你的管理者會支援你。當計劃出錯時，他們給予支援；成功時，他們一同慶祝；遇到困難時，他們提供建議；感到無聊時，他們尋找機會；感到負擔過重時，他們尋求幫助。最重要的是，當你真正需要他們只是傾聽，不做評判也不提供解決方案時，他們會這樣做。

與開發者的真正合作關係

長期以來，我每天有一半時間與開發團隊一起工作，他們很快就不再擔心我走近時是否出了問題。這種合作關係至關重要，它超越了角色定義，創造了真正的合作夥伴關係。

團隊可持續性與防止職業倦怠

建立、執行和參與技術團隊是一場馬拉松，而非短跑。在許多組織中，事件回應本質上是高壓情境，反覆的非工作時間呼叫可輕易導致職業倦怠迴圈。在微調SLO和迭代輪值設計的同時，同樣重要的是關注團隊健康，不斷自問：作為一個團隊，我們的工作方式長期來看是否可持續？

識別職業倦怠的徵兆

職業倦怠在臨床上有三個明顯特徵：

1. 情緒耗竭：花太多時間過度關心
2. 去人格化：發現自己對他人的共情減少
3. 成就感降低：工作成就感顯著下降

倦怠的徵兆當然會在每個人身上不同地表現出來。如果你像我一樣，是那種對自己要求很高的人，學會識別自己的情緒狀態並非我們花費大量時間發展的技能，這使得進行關於我們福祉的高度信任對話變得更加困難。

防止倦怠的團隊實踐

職業倦怠部分源於未解決的反饋迴圈。這對我產生了深刻共鳴；我曾在許多團隊工作，實驗從未有結論，因為我們未能有意識地關閉所需的反饋迴圈，導致不確定性和焦慮狀態，質疑我們是否變得更有效率。

在大多數健康的產品組織中，沒有可衡量的成功標準就推出功能是不可接受的。同樣，健康的團隊應定期反思他們的工作方式。最常見的工具是定期回顧（我建議從每週開始，然後迭代），但許多團隊也使用健康檢查，如Spotify建立的模型。衡量團隊健康主要是定性的，但這並不比正常執行時間數字等指標重要性低；只有捕捉到早期警告訊號，才能排除正在倦怠的團隊問題。

心理安全的關鍵作用

多年來的廣泛研究表明，心理安全是建立學習型組織不可協商的根本。心理安全是「對在特定環境（如工作場所）中承擔人際風險後果的感知」。

在更大的安全感下，人們更傾向於向團隊提供不同意見，並嘗試比照常營業風險更大的創新實驗。這些是重要的糾正途徑，而對於有懲罰任何不同意大多數人或處於權力位置個人的團隊來說，這些途徑是無法進入的。

做出最佳選擇的整合思考

作為SRE或技術專業人士，我們通常有選擇的特權。當你在工作上度過大部分清醒時間，你有責任瞭解自己的選擇，以及如何最大限度地利用它們。

選擇新工作時，使用一個決策矩陣可能會有所幫助，將所有這些因素納入考量：

1. 財務考量：基本薪資、獎金、股票以及它們如何滿足你的實際需求
2. 福利評估：超越純金錢價值，評估它們如何滿足你的具體生活需求
3. 工作安全性：特別是對非公民工作者的移民支援
4. 公司使命：與你的道德價值觀一致性
5. 團隊文化：知識分享、提問文化、技術討論氛圍
6. 長期可持續性：輪值負擔、心理安全、防止倦怠的措施

最終，最佳選擇不僅是薪資最高的offer，而是在這些多重因素中最能支援你長期成長和幸福感的選擇。技術生涯是一場馬拉松，而非短跑，選擇環境和團隊的重要性不亞於薪資數字。

在科技行業快速發展的今天，那些能在職業生涯中保持長期可持續性和防止倦怠的人，往往能取得最大的成功和滿足感。透過全面考量這些因素，你將更有可能找到真正適合你的下一個職業機會。

建立永續健康的SRE團隊：集體智慧與實踐策略

在技術領域開發永續健康的團隊並非什麼深奧的魔法。每個團隊都是獨特的有機體，擁有不同的團隊動態和反應模式，但它們確實分享一些關鍵特質。永續團隊具備持續學習和改進的能力，這對建立高效的SRE組織至關重要。健康的團隊能夠取得更豐富的成功與失敗指標，這些指標直接促進團隊關閉反饋迴圈的能力，進而使團隊感到高效和健康。

不要盲從資深工作者的建議

技術產業變化快速與難以預測，即使是資深工作者也難以準確預測未來走向。我接觸過的首條職涯建議是：“有了MS-DOS 6.1，世界不再需要更多軟體，轉向硬體吧。“第二條是：“沒人會付錢給通才，你需要專精。“而現在，我是一名SRE工程師。

科幻作家海萊因曾說：“專精是昆蟲的特徵。“嘗試各種不同角色：軟體工程師、系統管理員、前端、後端、硬體、產品、甚至創業者。每年生日時學習新事物，保持知識的擴充套件和更新。

職業倦怠是一個嚴峻的挑戰，它會在職業生涯中多次發生。每次你都會想：“我再也不會犯同樣的錯誤了。“但你可能再次工作過度，時間過長，沒有得到相應的回報或欣賞。這可能會永久性地損害你的健康。年輕時我們常認為這不會發生在自己身上，但請記住，人生是一場馬拉松，而非短跑。

職涯發展與心理健康

你可能會成為管理者，也可能不會。你可能在知名跨國企業工作，也可能總是在無人知曉的新創公司。你的股票期權可能價值數百萬，你也可能建立某些使你在欣賞你的人眼中聲名遠揚的事物。但重要的是不要把你的"評價核心"放在他人手中。

心理健康並非二元對立。遺傳學家普洛明教導我，有數千種基因突變會對我們的能力、耐力和動機產生細微影響。我們需要不斷嘗試，找出什麼適合自己和關心的人。在每家公司中，找一位你尊敬的人作為導師，聽取他們的建議，即使你不一定採納。

金錢、生活平衡與職涯決策

擁有的錢越多，需求也越大。在附近的樹下花5元讀書可以給你帶來與在地球另一端的海灘上閱讀同等的樂趣。你可以搬到矽谷，每週工作60小時，五年內成為資深工程師年薪50萬，但你可能不會意識到你失去的朋友、健康和自尊。

確保你有"走路錢”，讓你能夠離開不良僱主。財務上感到被困會讓情況更加惡化。當你問自己：“十年後，我希望我做了什麼？“困境會變得更容易處理。你目前的薪資和工作決定了下一個。在經濟繁榮時期，僱主不得不僱用尚未能勝任工作的人，但這些人幾乎總是能夠迎接挑戰。確保你申請的工作只有80%的把握能做到，這樣才能拓展自己。女性可能應該在只有60%把握時就申請，因為她們往往被條件化地低估自己的能力。

管理關係與技術選擇

我們為管理者工作，而非公司。管理者不是你的朋友，而是你的代理人。如果你不喜歡他們帶給你的社群、工作或薪資，就"解僱"他們。日本整理工作者近藤麻理惠告訴我，不願放手只有兩個原因：對過去的依戀或對未來的恐懼。

在技術選擇上，若一個簡單的shell指令碼足夠，就不要構建框架。如果一個shell指令碼可能在版本控制中存在數週以上，就不要寫它。弗雷德・布魯克斯建議在設計系統前不要僱用程式員，但他還建議每個程式團隊配備兩名秘書，這顯示了時代的變遷。

不要僅因為資深工作者聽起來很自信就採納他們的建議。技術產業變化太快，沒人能準確預測未來走向。關鍵是保持開放心態，不斷學習和適應。

面對第一次值班警示

2017年，剛從大學畢業，我在Shopify開始了軟體工程師的工作。在第一次值班前的一年準備期間，我花了數小時閱讀#war-room Slack頻道，被當天回應工程師的流暢表現所吸引，他們將一個可怕的警示轉變為協調、冷靜與專注的事件回應，跨越多個團隊協作。

第一次接到警示確實令人緊張。我希望透過一些輕量級的結構和工具，讓你在第一次接到警示時能更容易應對不確定性。

關注你的情緒反應

資深工程師看起來似乎冷靜自若，但事實是每個人都會有些焦慮。如果你發現自己處於這種狀態，可以稍作停頓，評估自己的緊張情緒，整理思緒，然後繼續前進。如果你感到不知所措或發現自己不適合處理特定事件，可以尋求同事的幫助。這種感受很正常，但為了更快解決問題，尋求所需的幫助很重要。

確定問題所在

你可能收到了描述某個關鍵業務指標發生戲劇性變化的警示。你可能有多條路徑可以探索，所以首先要做的是：嘗試確定受影響的系統，不是評估規模或影響範圍，而是盡力將警示對映到受影響的系統。挑戰在於警示指標與實際受影響的系統之間的脫節。

隨著時間推移，你會建立對關鍵指標和背後系統的組織知識，這可以支援你的調查。但在缺乏這種知識的情況下，你可以嘗試瞭解跨組織的警示相關性。

這時，你可以利用工具。例如，透過Slack搜尋、PagerDuty、Bugsnag等取得其他正在進行的警示或觸發的警示的高層次檢視，可以幫助你合理地識別受影響的系統。

確定聯絡物件

在識別受影響的系統後，你可能需要確定應該聯絡誰。雖然警示傳送給了你，但也許你已經將上游依賴確定為可能的罪魁禍首。

有時是你需要處理，但如果不是呢？找人聯絡很容易，困難的部分是疑慮。如果是錯誤的聯絡？你可能會在REM睡眠中間喚醒一名工程師，只為了讓他們告訴你撥錯了號碼。

有時你可能會聯絡錯人。但在這一點上，相信你到目前為止收集的事實，繼續快速行動。即使聯絡錯誤，根據你的盡職調查，錯誤接收者和正確接收者之間的分離度可能有限。

享受這一刻

你的第一次警示會令人恐懼，但轉變的神奇感覺——看著一個微弱的警示逐漸演變為大規模的事件回應——會讓你感到絕對的技術成就感。每個人都有起點，雖然你可能會給自己施加壓力，希望第一次、第二次或第三次就完美應對，但請記住，你只是在建立需要的神經通路，以獲得我們都渴望的流暢度。

SRE在任何規模下都是文化問題

現代商業環境是複雜與快速變化的場所，資源有限，不斷追求持續交付客戶價值。在這一更廣泛的背景下，維護可靠系統是一項複雜而細節導向的任務，難以優先考慮。

傳統上，構建系統同時維持生產正常執行所需的努力鮮為人知，是邊緣上的隱性要求，負擔委託給技術團隊。但這種方法往往導致技術債務積累和系統可靠性問題。

SRE文化的核心

在玄貓看來，SRE不僅是一套工具或流程，而是一種文化轉變。無論組織規模大小，建立有效的SRE文化需要：

1. 分享責任意識：可靠性不僅是SRE團隊的責任，而是整個組織的共同目標
2. 資料驅動決策：根據指標和服務水平目標(SLO)而非直覺做出決策
3. 持續學習心態：從失敗中學習而非指責，將每個事故視為改進機會
4. 自動化優先：優先考慮自動化重複性任務，釋放人力專注於創新

永續的SRE團隊能夠在保持系統可靠性的同時推動創新。這種平衡需要組織理解技術債務的真實成本，並願意投資於長期系統健康。

建立健康SRE文化的策略

建立健康的SRE文化需要多方面的策略：

心理安全與透明度

團隊成員需要感到安全，能夠報告問題、承認錯誤並提出改進建議，而不必擔心受到懲罰或批評。透明的事故回顧和無責備的後期分析是建立這種環境的關鍵實踐。

持續學習與知識分享

鼓勵團隊成員持續學習新技術和最佳實踐。建立知識分享的機制，如技術分享會、檔案函式庫對程式設計，確保經驗和見解不僅限於少數人。

平衡技術債務與創新

明確認識到技術債務的存在，並建立處理它的策略。平衡短期業務需求與長期系統健康，將可靠性工作納入產品開發流程。

資料驅動的決策框架

建立明確的服務水平目標(SLO)和指標，用於指導決策和優先順序排序。使用這些資料來平衡可靠性工作與新功能開發，確保資源分配合理。

結語

建立永續健康的SRE團隊是一項需要持續關注和投入的工作。正如我們所見，這不僅涉及技術實踐，還涉及文化、心態和組織原則。

無論是處理首次值班警示的緊張，還是在職業生涯中尋找平衡，關鍵在於保持開放的心態、持續學習的習慣，以及對自身健康和團隊福祉的關注。

技術領域的變化快速與難以預測，但透過建立堅實的基礎原則和適應性思維，我們可以建立既能應對當前挑戰又能為未來做好準備的團隊。在這個過程中，記住不要盲從權威，質疑假設，找到適合自己和團隊的獨特路徑。

最終，永續健康的SRE團隊不僅能夠維持系統的可靠性，還能夠創造一個讓成員感到滿足、有成就感和持續成長的環境。

可靠性與風險：長官者的雙刃劍

長官者在可靠性與功能開發之間的權衡往往充滿風險。在現代科技組織中，對預期可靠性的理解和發展完善的風險感知已不再是可選專案，而是首要需求。儘管工程師和長官者都明白這一點，但組織內的層級結構和缺乏分享背景常阻礙了建立整合性可靠系統的方法。

當我在一家跨國科技公司擔任首席架構師時，親眼見證了一個關鍵產品因為功能優先而忽視可靠性導致的大規模故障。事後分析顯示，工程團隊早已警告過系統的脆弱性，但這些警告在層管理結構中被稀釋，最終長官層收到的訊息變成了「一切正常，只有輕微風險」。

SRE：建立可靠性文化的橋樑

SRE（站點可靠性工程）正是為解決這種挑戰而生的文化。透過量化方法，SRE明確展現了營運可靠性與客戶滿意度之間的關係。透過優先考慮長期、客觀的成功衡量標準，SRE促進了關於可靠性的持續協商，其結果能夠得到更廣泛組織目標的支援。

若實施得當，SRE強調人類在持續創造成功條件中的重要性，而非僅強調導致失敗的每個疏漏。

錯誤預算：SRE文化的根本

雖然SRE採用的許多方面對每個組織來說都是實施細節，但錯誤預算被視為評判任何SRE文化有效性的基本、不可變的屬性。將可靠性提煉為一個簡單易懂的數字，並在整個組織中傳播，促進了將可靠性視為首要關注點的分享語言。

將可靠性視為另一個業務指標，使其能夠在其他業務需求優先的情況下進行協商和交易。例如，若季度目標是推出新產品功能，團隊可以根據錯誤預算決定可以承擔多少可靠性風險來加速開發。

SRE的弔詭：量化分析與軟技能的平衡

然而，儘管SRE深植於量化分析，但成功採用和維護SRE文化仍與實踐者的軟技能息相關。個人關係、分享信任，以及避免因層級結構產生的權力關係，對於成功的SRE文化至關重要。

這種文化採用提供了一個平等合作以實作成功的機會——但把握這些機會是關鍵。

不只是重新標記現有團隊

我們經常聽到這樣的說法：忠實採用SRE不能透過簡單地重新標記現有的基礎設施或營運團隊來實作。如果工程師的努力和個人犧牲在戰略層面上沒有共鳴，那麼這些都是毫無意義的。同樣，如果沒有分享語言來溝通，長官者採取的計算風險就無法被理解或量化。

正是因為這些原因，傳統的維運團隊無法在一夜之間變成SRE團隊。

挑戰者災難：孤立決策的危險

太空梭挑戰者號的發射被NASA管理階層批准，儘管工程師們對軌道飛行器在零下發射溫度下的安全性表示擔憂，管理階層為了避免已經困擾的日程表進一步延遲而做出了這個決定。

當工程師和長官者在孤立的環境中工作時，內省行為、分享同理心和相互信任將無法茁壯成長。

SRE：工程師與長官者的分享語言

SRE為工程師和長官者提供了一種分享語言，用於平衡保持系統執行與透過向利益相關者和客戶提供新功能價值來保持競爭力的衝突目標。

然而，持續實踐SRE本質上是一個組織問題，涉及有效溝通、信任和自主性，這些都是難以獲得與容易失去的，特別是當團隊專注於其採用的頻寬有限時。

成功的SRE採用遠不僅是自動化軟體營運。它是文化性的。

小型組織中的SRE：人都是SRE

「站點可靠性工程是答案。」

幾年前，當我說服自己在一家小型軟體公司擔任第一個SRE角色時，我就是這麼想的。終於，有一種機制能夠清晰表達我作為軟體工程師和系統操作員的工作——當事情出錯時，我就是那個最後的例外處理者。採用和實施與大型跨國組織相同的營運方法應該令任何人興奮。然而，很快就明顯看出，成功需要打破常規。

小型組織的SRE挑戰

在小型組織中實施SRE方法具有挑戰性。資源有限，人才取得困難，與客戶基礎不能視為理所當然。SRE實踐者的任務壓倒性地結合了多種角色，試圖用更少的資源做更多的事。

僅有工程、系統管理或營運的技術背景是不夠的。SRE的成功需要深刻的情感理解、影響力和組織背景，以倡導變革並培養無責備的工程文化。SRE的成功意味著建立優先考慮使用者幸福的文化，這一成果只有在技術知識和人為因素交叉運作時才能實作。

分享責任優於專職SRE

與標準教科書方法相反，在這些較小的組織中，建立專職的SRE資源最好透過廣泛分享責任來實作。當成功以向客戶交付功能來衡量時，新的SRE團隊要開創自己的領域並賦能他人是具有挑戰性的。

可靠性不太可能是首要戰略關注點；它不能被假定為理所當然，可能只在意外中斷時偶爾作為一個不便問題出現。當每個新功能都驅動可測量的增長並增加服務的實用性時，每個人都有動力提供任何必要的價值來保障未來生計，這很可能意味著新功能。

組織風險調節器的校準更加即興和不精確，由情感動機而非量化判斷驅動。你甚至可能不需要專注於可靠性；服務的早期採用者通常會容忍相對較差的正常執行時間！

「你建立它，你執行它」的賦能理念

擁抱「你建立它，你執行它」的理念，賦予組織中的每個人對可靠性的分享責任，並充分利用團隊的技能。此外，透過分享執行生產服務的痛苦，可以提高發展分享同理心和技術理解的機會，這在規模擴大時將是必要的。

同樣，實施SRE的實踐者必須謹慎，偏好促進分享背景而非中央控制的理念。這個例子常見於誤導性的品質管理嘗試，比如將呼叫器交回以應對感知到的過度營運辛勞。

不幸的是，重新優先排序大小為一的優先佇列不會產生明顯的順序變化。對於小規模的SRE，只有一個生產服務需要支援，與有顯著的個人和組織激勵繼續提供該支援。在長期內，偏好分享責任和對話而非增加摩擦更可能取得成果。

複雜系統中的SRE彈性

軟體系統繼續增加複雜性。隨著廣泛與不斷發展的社群支援，SRE提供了一個可持續發展此類別系統的模型，對於各種規模的組織都足夠靈活。最成功的實施理解分享責任和減少摩擦的重要性，所有這些都是為了追求客戶成功。

稽核環境尋找改進機會

採用SRE思維不僅始於你的第一個官方SRE專案。當你想讓公司更可靠但沒有SRE人員時，該怎麼做？第一步是檢視你已有的內容。你需要更好地瞭解你的環境。稽核它並記錄風險。

從最壞情況開始

從最壞的情況開始。安全漏洞、資料丟失和停機對每個人都是不好的，但什麼會摧毀你的業務？瞭解你的弱點並首先關注它。

評估容量限制

接下來，轉向容量。如果你不知道你的限制，你就無法保持安全或計劃增長。確定你是否有任何容量問題。如果有的話，你還有多少餘地？取得更多資源的前置時間是多少？

SRE文化：不僅是技術，更是人性

在我多年的SRE實踐中，最深刻的體會是：SRE不僅是一套工具或流程，而是一種思維方式和組織文化。它要求我們在技術和人性之間找到平衡點，在追求可靠性的同時，也要理解人類錯誤的不可避免性。

真正成功的SRE文化建立在分享責任、開放溝通和持續學習的基礎上。無論是大型科技巨頭還是小型創業公司，這些原則都能指導我們建立更可靠、更有彈性的系統，同時培養一個更健康、更有凝聚力的技術組織。

最終，SRE不只是讓系統更可靠，而是讓整個組織更加成功和可持續發展。透過將可靠性視為每個人的責任，而非僅是某個專門團隊的工作，我們能夠創造出既技術卓越又人性化的工作環境。

資安架構：SRE不可忽視的關鍵領域

在快速發展的組織中，資安問題常被忽略，直到問題浮現才開始處理。作為SRE工程師，玄貓認為我們必須主動思考幾個關鍵問題：誰擁有哪些許可權？當員工離職時，是否有完善的離職流程？組織是否採用密碼管理工具，並為雲端帳戶啟用稽核日誌？有多少人擁有足以「摧毀」公司的許可權？

在多年維護高用性系統的過程中，玄貓發現許可權控制的鬆散往往是資安災難的溫床。一個有效的方法是實施最小許可權原則，定期審查關鍵系統的存取許可權，並結合自動化工具進行許可權生命週期管理。

基礎架構備份策略

基礎架構的備份策略同樣至關重要。我建議從繪製簡單的基礎架構圖開始—只需在白板上繪製並拍照儲存。檢視是否存在單點故障？整個基礎架構是否可重現？在非緊急時期練習重現部分基礎架構，記錄流程，並始終記得測試備份的可用性。

# 基礎架構備份檢查指令碼範例
#!/bin/bash
# 檢查關鍵服務的備份狀態

echo "檢查資料函式庫..."
if [ -z "$(find /backup/db -name 'db_backup_*.sql' -mtime -1)" ]; then
  echo "警告：過去24小時內沒有資料函式庫"
  exit 1
fi

echo "檢查設定檔案備份..."
if [ -z "$(find /backup/config -mtime -1)" ]; then
  echo "警告：過去24小時內沒有設定檔案備份"
  exit 1
fi

echo "備份檢查完成，一切正常"

這個簡單的bash指令碼用於檢查關鍵系統備份是否在過去24小時內完成。find 命令搜尋特定目錄中的檔案，-mtime -1 引數指定只查詢1天內被修改的檔案。如果找不到符合條件的檔案，表示最近沒有執行備份，指令碼會發出警告。這種自動化檢查可以整合到監控系統中，確保備份流程正常執行。

第三方相依性管理

接下來，考慮業務依賴的第三方服務，如託管提供商、DNS和安全服務。審查帳單/發票，確保掌握所有工程相關服務的第三方供應商。建立清單，並在某些情況下考慮冗餘/備用連結。

玄貓在處理大型金融科技系統時發現，許多意外宕機其實源於第三方服務中斷，而團隊卻缺乏應對方案。我建議建立一個包含以下內容的第三方服務管理檔案：

關鍵第三方服務清單

雲端服務提供商

• 服務名稱: AWS
• 用途: 主要基礎架構託管
• 支援聯絡方式: 優先支援 1-800-xxx-xxxx (帳號ID: 123456)
• 替代方案: GCP (已設定基本災難還原環境)
• SLA: 99.99% (每月允許4.3分鐘停機時間)
• 續約日期: 2025-06-15

DNS提供商

• 服務名稱: Cloudflare
• 用途: DNS管理、CDN、DDoS防護
• 支援聯絡方式: enterprise-support@example.com
• 替代方案: AWS Route53 (已設定備用區域)
• 關鍵聯絡人: 技術營運團隊郵件列表

這個檔案範本提供了管理第三方服務依賴的結構化方法。它不僅記錄了基本聯絡資訊，還包含了替代方案和SLA資訊，這對於快速應對第三方服務中斷至關重要。特別注意「關鍵聯絡人」部分應該設定為郵件列表而非個人，避免單點故障。

網域名稱和SSL憑證管理

網域名稱和SSL憑證是另一個容易被忽視的領域，如果管理不當，可能對業務造成巨大損害。你是否瞭解對業務至關重要的所有網域名稱？是否擁有所有網域名稱註冊商的登入資訊？如何通知過期情況？即使設定日曆提醒也比沒有好。最後，記錄更新程式—可能有五個憑證都有不同的更新要求，確保它們都被記錄下來。

玄貓曾經見過一個案例，某金融科技公司因為SSL憑證過期導致服務中斷長達4小時，造成數十萬美元的損失。為避免此類別問題，我開發了一個自動化指令碼來監控憑證有效期：

#!/usr/bin/env python3
import ssl
import socket
import datetime
import smtplib
from email.message import EmailMessage

domains = [
    "example.com",
    "api.example.com",
    "admin.example.com"
]

warning_days = 30
alert_email = "ops-team@example.com"

def check_cert(domain):
    context = ssl.create_default_context()
    conn = context.wrap_socket(socket.socket(socket.AF_INET), server_hostname=domain)
    conn.connect((domain, 443))
    ssl_info = conn.getpeercert()
    expiry_date = datetime.datetime.strptime(ssl_info['notAfter'], "%b %d %H:%M:%S %Y %Z")
    days_left = (expiry_date - datetime.datetime.now()).days
    return days_left

def send_alert(domain, days_left):
    msg = EmailMessage()
    msg.set_content(f"SSL certificate for {domain} will expire in {days_left} days")
    msg['Subject'] = f"SSL Certificate Expiry Warning: {domain}"
    msg['From'] = "cert-monitor@example.com"
    msg['To'] = alert_email
    
    s = smtplib.SMTP('localhost')
    s.send_message(msg)
    s.quit()

for domain in domains:
    try:
        days_left = check_cert(domain)
        if days_left <= warning_days:
            send_alert(domain, days_left)
            print(f"Warning: {domain} certificate expires in {days_left} days")
        else:
            print(f"OK: {domain} certificate expires in {days_left} days")
    except Exception as e:
        print(f"Error checking {domain}: {e}")

這個Python指令碼會檢查指定網域名稱的SSL憑證到期時間，並在剩餘天數低於閾值時傳送警示郵件。指令碼使用Python的ssl和socket模組來取得憑證資訊，然後計算到期前的天數。當憑證接近到期時（例如30天內），系統會傳送警示郵件到指定的維運團隊信箱。這個指令碼可以設定為每週執行的排程任務，確保團隊有充足的時間更新即將到期的憑證。