?譯者 | 崔皓

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

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

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

在筆者的職業(yè)生涯中，曾與不少如此出色的人共事。大多數(shù)組織都在努力改變他們的文化，盡管過(guò)程布滿靳棘但他們?nèi)栽谔綄こ晒Φ姆椒āＭ麄儾⒉涣私庾约旱南到y(tǒng)。

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

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

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

1、過(guò)程能力：精英們的秘密

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

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

課程的最后一天，他帶來(lái)了一本《工業(yè)自動(dòng)化標(biāo)準(zhǔn)手冊(cè)》的副本。在1986年版的書(shū)中，他強(qiáng)調(diào)了一句話："測(cè)量過(guò)程能力"，并加了一個(gè)手寫(xiě)的說(shuō)明，說(shuō)："這就是你需要知道的一切"。這句話在過(guò)去30年中一直是正確的。

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

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

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

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

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

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

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

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

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

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

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

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

知道一個(gè)過(guò)程將可靠地產(chǎn)生指標(biāo)值，并落在一個(gè)狹窄的走廊內(nèi)（理想情況下，LSL和USL之間不超過(guò)兩個(gè)或三個(gè)標(biāo)準(zhǔn)差），有助于計(jì)劃想要的結(jié)果，并有助于更好地自動(dòng)補(bǔ)救（通過(guò)AIOps和MLOps）。隨著時(shí)間的推移，所做的與構(gòu)建、測(cè)試和裝運(yùn)軟件有關(guān)的一切，都應(yīng)該提高Cp、可靠性和預(yù)測(cè)結(jié)果的能力。如果發(fā)現(xiàn)自己有大量的技術(shù)債務(wù)，或者團(tuán)隊(duì)因?yàn)樾碌墓δ苄枨蠖坏貌恍冀馍?，那么?duì)抗這種情況并擺脫債務(wù)的最好方法就是專(zhuān)注于提高流程能力。

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

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

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

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

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

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

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

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

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

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

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

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

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

OpenTelemetry讓你從四個(gè)來(lái)源收集數(shù)據(jù)：日志、指標(biāo)、追蹤和Span事件。

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

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

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

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

如果你不熟悉OpenTelemetry，我強(qiáng)烈建議你熟悉它，并參與到工作小組中來(lái)，甚至對(duì)源代碼做出貢獻(xiàn)。

成功開(kāi)發(fā)可觀察系統(tǒng)的團(tuán)隊(duì)表現(xiàn)出以下特點(diǎn)：

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

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

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

3、可觀察性驅(qū)動(dòng)的開(kāi)發(fā)

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

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

圖3.用ODD擴(kuò)展TDD

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

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

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

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

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

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

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

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

譯者介紹：

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