?譯者 | 崔皓

大多數(shù)組織都在努力改變他們的文化，盡管過程布滿靳棘但他們?nèi)栽谔綄こ晒Φ姆椒?。往往他們并不了解自己的系統(tǒng)。

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

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

在筆者的職業(yè)生涯中，曾與不少如此出色的人共事。大多數(shù)組織都在努力改變他們的文化，盡管過程布滿靳棘但他們?nèi)栽谔綄こ晒Φ姆椒?。往往他們并不了解自己的系統(tǒng)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖2.負載增加時響應(yīng)時間的曲棍球模式的例子

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

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

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

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

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

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

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

2、構(gòu)建可觀察的系統(tǒng)（避免事項）

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

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

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

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

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

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

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

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

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

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

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

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

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

成功開發(fā)可觀察系統(tǒng)的團隊表現(xiàn)出以下特點：

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

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

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

3、可觀察性驅(qū)動的開發(fā)

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

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

圖3.用ODD擴展TDD

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

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

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

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

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

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

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

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

譯者介紹：

崔皓，51CTO社區(qū)編輯，資深架構(gòu)師，擁有18年的軟件開發(fā)和架構(gòu)經(jīng)驗，10年分布式架構(gòu)經(jīng)驗。?