?譯者 | 崔皓

大多數組織都在努力改變他們的文化，盡管過程布滿靳棘但他們仍在探尋成功的方法。往往他們并不了解自己的系統。

谷歌最近的Accelerate State of DevOps報告發現，超過26%的開發團隊被認為是 "精英執行者"。這個數字比2018年的18%有所上升。根據DORA（DevOps研究和評估）指標，精英人才每天執行多次軟件部署，發布的準備時間和恢復服務的時間在一小時以內，并將其發布失敗率保持在15%以下。

與低績效者相比，精英績效者的部署頻率高與前者973倍，準備時間快6750倍，部署失敗率降低3倍以上。當出現問題時，精英們能夠以比低績效者快6570倍的速度恢復。

在筆者的職業生涯中，曾與不少如此出色的人共事。大多數組織都在努力改變他們的文化，盡管過程布滿靳棘但他們仍在探尋成功的方法。往往他們并不了解自己的系統。

知道精英團隊具有哪些特質，以及這些特質如何影響生產力是很重要的。上述指標沒有告訴我們這些精英團隊是如何實現這些成果的，以及如何讓較差的團隊演變成精英團隊的。雖然知道了什么成功，但開發人員和工程經理更希望了解如何做才能提升自己的能力。

對于那些進行流程升級的組織而言，在市場競爭中進行加速創新變得更容易。今天成功的組織建立了高度可觀察的系統，并在開發過程中使用這種可觀察性來提高整體速度。想想看，測試驅動的開發是立體的。

在這篇文章中，筆者將就成為精英人才的最重要見解描述如下：

1、過程能力：精英們的秘密

筆者在IT職業生涯的早期，是一名實施CMMI（能力成熟度模型集成）的講師和顧問。在堂課上，有一個相當古怪的工程師，他幾乎在每一個話題上都會“硬剛”。

盡管筆者想把他從課上趕出去，但最終決定與他共同授課，并在課堂上分享他的經驗。這門課成為筆者最難忘的課程之一，并促進了職業生涯中最有影響力的友誼。那段時間，他們兩位經常辯論很長時間，分享彼此的經驗，同時給雙方不小的思想碰撞。

課程的最后一天，他帶來了一本《工業自動化標準手冊》的副本。在1986年版的書中，他強調了一句話："測量過程能力"，并加了一個手寫的說明，說："這就是你需要知道的一切"。這句話在過去30年中一直是正確的。

表現優異的公司在流程工程方面有很強的文化。流程工程包括設計和實施將原材料——客戶需求和軟件工程能力--轉化為業務產品的流程。精英企業在定義、測量和改進流程方面表現出色。每一項都對過程很重要：好的設計和好的規范定義了應用程序在生產中應有的樣子；指標、監控和現在的可觀察性有助于衡量實際應用程序與設計之間的差距；利用這種反饋讓新的功能或重構代碼以改善應用程序。

有一個單一的指標可以用來衡量過程與設計的匹配度，就是過程能力。它是對客戶需求（客戶的聲音）和過程的實際表現（過程的聲音）之間差異性進行衡量。它可以表示如下：

規格寬度是規格中定義過程指標的上界（USL）和下界（LSL）之間的差異。過程寬度是指除生產過程外的那個相同的差值。

因此，對于任何指標，都要定義規范的上限和下限，并評估這些指標違反限制的頻率。這聽起來很熟悉嗎？它應該是。看看任何SRE的服務水平指標（Sli）和目標，你會發現錯誤預算和burndown的想法是源于Cp。另外，因為這個過程的重點是提高流程的質量和效率，這意味著我們應該考慮數據質量和樣本集的大小。

我們可以參考控制理論——現代可觀察性的基礎，來幫助我們設計流程，并指導良好的編碼實踐來支持這些流程。我們在Cp中測量的指標是根據它們的一致性來評估的，或者說它們在定義的性能走廊（可接受值的范圍）內保持得如何。例如，對于一個微服務架構，我們希望黃金信號在我們的性能走廊內是可預測的。

圖1.用規格下限和上限表示的公制系列的例子

我們希望API響應時間與客戶體驗（CX）相關聯。如果響應時間到處都是，如果難以辨別調用的速度，那么就不可能知道CX是好是壞。因此，至關重要的是要避免懶惰的編碼，如getAll()類型的語句，這類語句會讓調用充斥著不可預測的大量數據。相反，可以利用分頁來控制結果集，這樣做就可以創建一個可預測的API。發現正在進行過多的調用，就可以預先異步獲取更多的數據，或者選擇改變用戶界面，以便通過排隊的方式處理大量的請求，并在處理后返回。下次你在設計服務的時候問問自己這些問題。

• 為確保良好的用戶體驗所需的響應時間是多少？也許API必須在250ms以內響應，或者不超過500ms。
• 哪些上游或下游的依賴性會破壞性能？能克服它們嗎？
• 將如何設計代碼以表現出確定性的行為？是否有我們可以使用的標準或模式？
• 能否使用斷路器或Stack Overflow上討論的其他設計模式來處理故障狀態，而不影響性能？
• 將使用API調用的哪些屬性來得出指標，以確保對跟蹤的實體進行同類分析和歸類？比如分離POST、PUT、DELETE操作，了解哪些屬性是導致代碼路徑選擇的原因。

注：用來了解性能的屬性越多，就越容易在變化發生時了解與之相關的偏差來源，從而提高Cp。

具有確定性的代碼在規定負載下表現出可預測的響應時間。寫得好的服務會隨著時間和負載的增加而表現出一致的響應曲線。如果負載的增加超過了突破點，我們很可能會看到錯誤的高峰。

圖2.負載增加時響應時間的曲棍球模式的例子

隨著時間的推移，指標越平穩，越一致，直到突破點，就等于高Cp。

知道一個過程將可靠地產生指標值，并落在一個狹窄的走廊內（理想情況下，LSL和USL之間不超過兩個或三個標準差），有助于計劃想要的結果，并有助于更好地自動補救（通過AIOps和MLOps）。隨著時間的推移，所做的與構建、測試和裝運軟件有關的一切，都應該提高Cp、可靠性和預測結果的能力。如果發現自己有大量的技術債務，或者團隊因為新的功能需求而不得不宣布解散，那么對抗這種情況并擺脫債務的最好方法就是專注于提高流程能力。

為了提高流程的能力，你將希望在軟件開發生命周期中收緊反饋回路。這意味著你要了解客戶的聲音，并能夠持續地測量過程的聲音。 

以下是一份事情清單，它將幫助你集中精力從債務中掙脫出來。如果你沒有深陷債務，它也是很好的預防措施，幫助你避免深陷技術債務。

• 嘗試弄垮你的服務。了解你的服務的故障狀態對于優化代碼和創建基礎設施至關重要。有一些客戶僅僅通過研究弄垮自己服務的方式，就把服務的工作效率提高了300倍甚至更多。通過這種方式就了解每秒和每個節點的交易峰值吞吐量，以及集群有許多節點（或pod）時的擴展因素。然后再思考，你能優化代碼以減少CPU上的時間嗎？是否存在線程問題、單子問題或類加載問題導致線程等待？你是否在該使用異步的地方盡量使用異步調用？
• 為編寫的API發布模擬。讓你的下游生產者也這樣做。模擬失敗的狀態，比如用mock來模擬緩慢的響應或沒有響應，而不是依賴下游的系統。你會發現你不需要一個強大的環境來破壞你的服務，或者在做這件事的早期就暴露出許多問題。 
• “浸泡”服務。利用斷點測試來找到吞吐量的極限點，然后在這個吞吐量的極限點上縮減20%的負載，以這個縮減后的負載為基礎，對系統進行長時間的負載測試。經過一段時間的浸泡測試，觀察系統的可靠性，如果在此期間發現故障，就想辦法解決。
• 識別金絲雀。利用金絲雀測試的這段時間定義幾個關鍵指標，這些指標將準確地推斷出服務的健康狀況，它們的規格上限和下限是什么？當它們超出限制時，運行手冊將是什么？
• 作為CI/CD管道的一部分，自動進行故障測試。不斷地對你的代碼進行實戰測試。
• 使用峰值吞吐量來設定會話數量的上限。在達到這些閾值之前，要擴大規模。如果擴展失敗，告訴用戶系統忙，無法提供請求服務，這比提供低劣的體驗要好得多。
• 對端到端堆棧進行混沌工程。如果x事件了如何處理？作為一個團隊形成幾個假設，并在鍋里扔5美元給贏家。要有創造性，找到弱點并解決它們。在你如何運行你的堆棧中改進方案和理論，并慶祝發現。
• 消除工作隊列。尋找所依賴的團隊，是否存在的延遲，重組，是否可以采用小組/隊的模式--做你必須做的，以盡可能地實現自我服務。分析流程，定義衡量標準，并設定OKRs，以便進行持續改進。
• 追蹤做出決定所需的時間。是否需要幾周的時間來決定某事？ 這些指標是否被持續測量？
• 找到重復的手工任務，然后將其自動化。減少重復勞作。

對服務測量設定9的數量（例如99.99%），并開始使用誤差預算。換句話說，不要依賴平均數。相反，利用最高百分位數（TP）、直方圖、以及超出中位數分布和規格限制的次數。把這些變成預算，當錯誤預算是健康的，就可以繼續甚至加速生產。如果預算正在下降或低于可接受的水平，那么是時候放慢腳步，專注于穩定和減少風險。根據需要重構代碼以減少異常值并提高可預測性。

Github上有一個偉大的項目，叫做OpenSLO，它通過使用SLOGen生成規則，將服務級別指標（SLI）和目標（SLO）聲明為代碼。這樣做能夠利用Terraform來部署SLI和SLO，并生成儀表盤、指標規則和警報閾值。Sumo Logic最近發布了與OpenSLO的完全集成，使客戶能夠對其服務進行自動化并保持一致的服務級別管理。這樣一來，增強了服務部署的可靠性管理，并實現服務部署的自動化，這些動作會使你成為精英。

2、構建可觀察的系統（避免事項）

精英人才利用可觀察性技術和工具創建緊密的過程反饋循環。他們擅長建立和運營高度可觀察的系統。這里使用的 "系統 "是很寬泛的。不僅是被部署的服務，還包括CI/CD管道、遙測管道和自動化的控制平面。此外，構建可觀察的系統包括觀察管理軟件交付的過程和過程所采用的標準。總之，精英們能夠以簡潔、可靠和可預測的方式在軟件開發生命周期中測量事物。他們有意使用最少的指標或數據點（簡明）來接近可觀察性，這些指標或數據點由一致的、高質量的數據（可靠）產生，最能代表過程的健康狀況，并與問題有很強的關聯性（可預測）。

為了在構建可觀察系統時擁有最大的靈活性，在選擇工具鏈、遙測代理、遙測管線或控制平面時，要尋找完全接受和支持開放標準的組件。開放源碼和CNCF工具鏈在原生互操作性方面非常出色。請記住，CNCF上列出的一些供應商屬于支持開放標準的灰色地帶，但有專有的閉源代碼，如他們收集遙測的代理。在選擇專有供應商之前要仔細考慮，看看是否有開源的解決方案可以滿足你的要求。沒有開源的供應商提供的代理通常產生專有的數據集，只能從供應商的后端平臺讀取，讓數據成為孤島（供應商獨家擁有數據）。這并不理想，因為團隊被供應商鎖定在獨家數據上，而這些數據很難在更大的組織內普及。可觀察性中的專有組件歷來導致IT部門擁有許多不同的數據孤島，限制了實體建模、機器學習和企業整體數字化轉型的有效性。為了成為精英，企業應該盡其所能從源頭上擁有他們的遙測數據，而不是以專有供應商代碼的形式租賃。

通過利用像OpenTelemetry這樣的開放標準，你永遠不必擔心供應商改變他們的許可模式，從而嚴重影響數據的民主化，就像一家APM供應商最近所做的那樣。你的選擇是，要么向他們支付更多的錢來訪問你的數據，要么放棄他們的技術，這樣做的話，就需要針對他們平臺和自動化的時間重新設定成熟度。這就是為什么精英們選擇利用OpenTelemetry，并與像Sumo Logic這樣的供應商合作，接受選擇與鎖定的分析。尋找完全支持開放標準和工具鏈的供應商，而不是繼續投資于或依賴封閉/專有代理或生態系統來收集你的遙測數據。 

OpenTelemetry成功的另一個原因是，它是一個高度有主見的開源模式，對數據的存儲、聚合或處理方式皆是如此。它簡化/標準化了遙測采集，將所有的日志、指標、跟蹤和事件統一為一種新型的復合（和高度豐富的）遙測流，并使復雜的處理和轉換在采集器管道中發生。這些功能結合在一起，解決了IT領域的許多數據挑戰，特別是在商業智能團隊中，這些團隊歷來都在努力獲取不可變的實時數據。

采用OpenTelemetry的開發團隊受益最大的是擁有輕量級的API和可交互的SDK架構，這意味著不再依賴一個封閉的代理，不用擔心技術債務問題。如果OpenTelemetry中需要一個錯誤或功能，它可以由開發者或行業中的任何人來修復或編寫，而不是等待和依賴供應商的工程師組成的小團隊。當最近的Log4J漏洞被公布并導致每個專有代理部署的大規模中斷時，這一點尤其有利。對于OpenTelemetry來說，這幾乎是無痛的。

傳統的應用性能監控（APM）和可觀察性工具建立在兩到三個數據源的支柱上：主要是跟蹤和度量，在很多情況下還有有限的日志記錄。優秀的團隊對他們的系統進行儀表化，將這三種類型的數據排放到一個統一的平臺上，以達到最強的可觀察性。雖然傳統的APM供應商認為，你可以取消其中一個來源，或者嚴重依賴一個來源，但這三個來源在創建可觀察系統方面都有其作用。

雖說傳統APM萬般好，但存在一個問題，它使團隊捕獲所有的東西，而不去考慮什么是重要的，主要是因為它不依賴于開發人員的輸入。太多的數據獲取并不考慮其目的，會導致效率低下。構建系統的目的是通過最有效的輸出來可靠地推斷內部狀態，這就產生了與元數據中必要的豐富性深度相關的遙測數據，以滿足設計結果。這導致了一種優化的狀態，我們可以在更大的笛卡爾集合中利用更少的指標來驅動SLI，并通過SLO和burndown更有效地運作。

OpenTelemetry讓你從四個來源收集數據：日志、指標、追蹤和Span事件。

日志，簡單的說，就是附加在文本文件或數據庫中的帶有時間戳的信息和審計跟蹤。幾十年來，APM供應商一直在淡化對日志的需求，聲稱專業的跟蹤具有更大的價值。他們的論點是，追蹤會捕捉到異常日志，而且結合用戶會話來診斷追蹤比分析一堆日志更容易。現實情況是，我們既需要原始日志，也需要跟蹤記錄。今天，隨著組件的爆炸、堆棧的復雜性、變化率和攻擊面的增加，專有代理比以往任何時候都處于不利地位，特別是如果他們的平臺在日志聚合方面不健全。統一所有遙測數據意味著很容易從指標跳到相關的跟蹤和日志，反之亦然。日志對于審計和合規性以及通過事情的順序了解根本原因至關重要。如果在其他地方發生的事情間接地影響到一組追蹤，怎么辦？你仍然需要一個完整的查詢語言和日志搜索引擎，以便在許多情況下有效地確定根本原因。與OpenTelemetry相比，專有的追蹤工具受限于其專有的數據模型、后端平臺，以及大多數簡單事實。

指標是關于一個系統的時間序列數據的匯總。如果實施得當，它們是煤礦中的金絲雀：檢測偏差最可靠的方法，然后可以在時間范圍內和可用的元數據維度上與日志、追蹤的ML相關。指標是偉大的，但當它們以統一的方式與日志和追蹤相關聯時，它們可以發揮巨大的作用。

日志捕捉的是系統運行的時間點，而追蹤則是通過所有的組件和時刻來跟蹤一個請求。由于度量標準聚集了一個系統所發出的數據，通過OpenTelemetry的跟蹤，在整個系統中用跟蹤和跨度ID來標記日志，使得搜索以及從跟蹤ID返回順序的日志變得簡單。追蹤也暴露了實際的代碼路徑，這對于跟蹤依賴鏈和發現瓶頸或代碼路徑上的問題。追蹤是非常有價值的，通過將追蹤日志按其發出的順序連接起來，使深度系統的日志分析變得平坦，這意味著日志分析仍然是線性的，而不是隨著復雜性的增加和云應用的擴展而變得指數化。

OpenTelemerty還增加了第四個數據源。Span事件。從本質上講，這相當于實現了對深度代碼可見性，如堆棧跟蹤或其他由框架或開發人員定義的事件。當異常被拋出時，在調用樹中提供堆上對象的所有屬性作為堆棧跟蹤的一部分。這將簡化找出那些難以分析的空指針異常，這些異常似乎從未在測試中出現過，但在生產中卻困擾著我們。 

如果你不熟悉OpenTelemetry，我強烈建議你熟悉它，并參與到工作小組中來，甚至對源代碼做出貢獻。

成功開發可觀察系統的團隊表現出以下特點：

• DevSecOps和業務分析是智能的、連續的、不可變的和實時的；數據是統一的和民主化的
• 整個組織使用通用的儀器庫；元數據是一致的和聲明性的
• 控制平面和遙測管線是一致的和聲明性的
• 可觀察性被干凈地注釋，工具化是用面向領域/面向方面的編程完成的。
• 監測健康/性能的指標是陳述性的
• 儀表盤、警報和警報閾值是聲明性的，并隨每次合并而部署。
• 控制平面根據規則評估輸出，并驗證金絲雀，擴大/縮小規模，智能回滾，很好地處理0級自動修復問題。

在很多DevOps和DevSecOps的子領域，如GitOps和零信任，精英們的表現都很成熟。價值流管理（VSM）和流量指標作為APM的新框架已經出現，并作為表達企業可靠性的一個集中方式。如果軟件系統表現完美，但客戶并不滿意，那么這個過程并沒有產生預期的結果。繪制和觀察你的價值流是集中精力的一個好方法。

歸根結底，成為一個精英人才意味著對高數據質量的癡迷，并更有效地利用MLOps。把所有這些數據集中（理想情況下），允許ML更有效地運作，并通過暴露這些高標準數據集之間的關系來關聯更多的信號。分析在推理和維度分析方面越有效和可靠，對你從故障中恢復的速度的影響就越大。在構建可觀察系統時，要強調收集什么數據，如何收集數據，以及為什么收集數據，這樣你就可以向IT和業務利益相關者提供高價值的信息和知識。

3、可觀察性驅動的開發

目前為止我們所討論的一切都以這樣或那樣的方式成為可觀察性驅動開發（ODD）基本原理的關鍵因素。ODD是將所有與可觀察性有關的東西向左轉移到開發的最早階段。就像測試驅動開發強調在編寫代碼之前編寫測試用例以提高質量和設計一樣，ODD對于構建可觀察系統也是如此：開發人員編寫代碼的目的是為了聲明推斷系統和流程的內部狀態所需的輸出和規范限制，無論是在組件層面還是整個系統。

在實踐中，ODD也可以成為組織所需的強制功能，以規范用于建立可觀察性的儀器框架、SDK和API，或者規范如何實現結構化日志、度量、跟蹤和事件，最終滿足需要這些數據的許多利益相關者的需求。通過ODD，本文所討論的可觀察性原則被有意和精確地編織到系統的結構中。

圖3.用ODD擴展TDD

TDD在測試和設計之間建立了一個反饋回路，而ODD則擴大了反饋回路，確保功能的行為符合預期，改善部署流程，并向規劃提供反饋。

我喜歡把ODD看作是一座橋梁，它跨越了歷史上削弱了開發人員與生產關系的一條很深的鴻溝。ODD是指為開發人員（和企業）提供必要的工具（和流程），以便與生產環境建立緊密和一致的關系。在這樣做的過程中，每個人都是贏家。

然而，ODD的最終目標是達到流程能力的水平，使你可以直接從開發到生產。在生產中進行測試對開發人員有許多好處。

• 業務部門、產品經理和開發人員可以通過假設更快地進行迭代。
• 與非生產環境相比，所產生的數據是最高質量的，非生產環境中的數據往往是假的，被洗過的，或者缺乏對生產的良好表述。
• DevOps團隊提高了他們的自動化、向前失敗、功能轉換和回滾的能力。
• 生產測試將暴露出任何尚不具備能力的過程。

筆者最近采訪了一家精品零售商的SRE，該公司在2021年的整個零售旺季都保持正常運營。他們是如何做到這一點的？

• 他們的工程團隊可以自由地將代碼推送到生產環境，只要他們的合并請求通過所有的檢查。
• 服務是用可以被其他團隊使用的模擬來編寫的，所以各種故障模式可以在開發人員的筆記本電腦上測試，以了解下游的依賴性。
• 他們對管道中的代碼進行自動化性能測試（使用過去專門用于暫存和較低環境的計算預算）。
• 這些性能測試做了很多事情，但也許最重要的是，他們一遍又一遍地顛覆他們的服務，在偏差中尋找統計學上相關的信號（想想六西格瑪），同時針對新功能的響應時間評估吞吐量和飽和度，這也是對他們SLO的輸入。
• 他們每周都會徹底銷毀并重建他們的Kubernetes集群，這并不是因為他們必須這樣做，而是因為這讓他們在恢復過程中保持可靠和自信的能力。
• 他們利用日志和指標來滿足所有的自動化需求，并利用追蹤來優化客戶體驗和快速隔離故障域的問題。
• 他們的所有數據都被標記為特征級別。
• 如果他們的SLO預算低于可接受的水平，新功能的發布就會受到限制，變化也僅限于恢復服務水平。
• 他們根據九位數定律進行管理，并依靠百分位數和指數直方圖來評估性能數據。

簡而言之，他們在進入可觀察性驅動開發的過程中，使他們沿途修復了許多流程，最終使他們能夠從筆記本和IDE直接到生產中的代碼。他們的工程師很少依賴其他團隊而耽誤工作，他們的管道很強大，在合并到生產之前對新代碼做了很好的認證，現在他們每天都要做幾百次。通過跟蹤他們的數據集的眾多維度，他們能夠暴露出異常值，并深入了解一段時間內的行為和性能特征。這種高保真度使他們能夠迅速發現回歸，并在一個小時內恢復正常的操作。可觀察性驅動的開發使他們成為精英的執行者。

原文鏈接：https://stackoverflow.blog/2022/10/12/how-observability-driven-development-creates-elite-performers/

譯者介紹：

崔皓，51CTO社區編輯，資深架構師，擁有18年的軟件開發和架構經驗，10年分布式架構經驗。?