可觀察性驅動開發，探索未知之地
可觀察性驅動開發與監控有什麼不同？隨著我們的分散式系統變得越來越複雜，隨著我們對 DevOps 測試、自動化和效率的追求，筒倉的打破，為了瞭解程式碼中未知的未知，ODD 作為一種超級監控而出現。本文包括 Honeycomb 創始人 Charity Majors 的見解。
本文要點
-
隨著微服務和容器使系統變得更加分散和複雜，未知的未知也在增加。
-
只在釋出後進行監控是不夠的，你只有在完全瞭解系統的潛在故障時才能獲得成功。
-
可觀察性驅動開發（ODD）通過工具和開發人員的結合來觀察系統的狀態和行為，通過這種方式你可以更多地瞭解系統的缺陷模式。
-
監控通常由運維人員在釋出後完成，而可觀察性則是生產環境中的事件優先測試。
-
可觀察性，就像整個 DevOps 運動一樣，是關於成為一個更好的軟體管理員，為接下來的開發人員留下線索，向他們說明你為什麼在產品中這樣做。
毫無疑問，系統越分散就越複雜。這使得 24/7 監控和隨叫隨到的輪流值班對大多數公司來說都至關重要。但是，可觀察性是如何影響我們越來越短的 DevOps 反饋迴圈的呢？本文概括介紹了從 Honeycomb 創始人和可觀察性的強烈支持者 Charity Majors 那裡瞭解到的關於可觀察性驅動開發的經驗。
用 DevOps 重新激發開發人員的活力
在倫敦舉辦的 CloudNative 2018 大會 上，Majors 說：“起初，反饋迴路是，當你造成了破壞，人們會對你大喊大叫，然後，當你修好它的時候，他們就會稱讚你。但後來，網際網路出現了，我們的系統變得更加複雜。”
Majors 回憶說，我們都是從擁有自己的軟體開始的——因為誰還會擁有它——但是，當我們距離擁有它越來越遠的時候，我們就失去了判斷錯誤的能力。筒倉讓開發人員越來越遠離程式碼的執行，DevOps 運動是“一種迴歸優雅、迴歸良性反饋迴圈狀態的嘗試，”Majors 這樣說道。
每個開發人員都需要擁有自己的程式碼，從編寫到部署，再到除錯和再次部署。Majors 認為，少了任何東西就不是完全的 DevOps：
它使軟體變得更好，除錯人員在軟體執行期間進行除錯時可以獲得最相關的上下文資訊。
她接下來介紹了 Charity 的 DevOps 原則：
編寫程式碼的人可以也應該部署他們的程式碼並在生產環境中提供支援。
DevOps 自動化的目的不僅僅是為了提高速度，它還是為了將開發人員從非創造性的、乏味的修復工作中解放出來，重新激發並利用開發人員的內在動機和創造力：
讓我們感到滿足和欣慰的東西全和自主性、感覺被授權以及構建一些重要的東西並關心它是否被完成好有關。
當然，這與 Dan Pink 提出的知識型員工的 三個關鍵內在動機 相一致：自主性、精通性和目的性。
然而，開發人員一次又一次地釋出在本地設定中看起來沒有問題的程式碼，而一旦部署，各種問題就接踵而至。發現問題可能就需要幾天時間，就更不用說解決問題了。Majors 警告說：
分散式系統的第一個教訓是，你的系統永遠不會全無問題——任何時候都存在許多災難性狀態。
然而，一旦你運用了可觀察性驅動開發，使用了合適的棧、工具，特別是視覺化，你就可以更快地發現和解決相同的系統缺陷，通常是幾個小時甚至幾分鐘。
可觀察性驅動開發如何幫助開發人員瞭解他們的系統
什麼是可觀察性開發？它利用工具和有實際經驗的開發人員觀察系統的狀態和行為，讓你可以更多地瞭解該系統，包括缺陷模式。實際上，ODD 是在查詢系統，而監控只是為系統設定閾值並進行測量。
Majors 認為，測試驅動開發——編寫測試，然後編寫通過該測試的程式碼的過程——現在已經準備好發展成可觀察性驅動開發。兩者都屬於行為驅動開發的範疇，但 ODD 對行為表現出了更好的理解。
Majors 說，你還可以通過可觀察性驅動開發過程實現隨時待命。可觀察性是 控制理論 的一部分，該理論研究如何控制複雜的分散式系統。
僅通過詢問系統的話，你能知道你的系統、你的程式碼裡發生了什麼。如果不提供新程式碼，你能夠回答新問題嗎？
Majors 強調，這關乎實現恰當的抽象級別，而不是生成更復雜的程式碼庫：
當你有一個可觀察的系統時，你的團隊將在沒有先驗知識的情況下快速可靠地跟蹤任何新問題。他們會理解程式碼和缺陷的使用者體驗、行為以及原因。
可觀察性並不否定監控，監控仍然是 DevOps 範疇的一個重要部分。但據專業人士稱，在過去的 20 年裡，監控並沒有跟上時代的步伐，仍然主要適用於內部需求。
它會把過去中斷時的殘餘資訊轉換為那些指示板需要表達的東西——只有大約 2% 的軟體工程師理解這一點。
Majors 引用自動化工具 Sensu 工程副總裁 Greg Poirier 的話說：“監控已死”。Poirier 認為，隨著時間的推移，對系統及其元件的行為和輸出進行觀察和檢查的行為——這是對可觀察性驅動開發的良好定義——使得對複雜系統進行監控成為一種過時的模型。
Majors 說，“很重要的一點是，要構建對人們有意義的工具，讓他們生活在同一個現實中。”他談了清晰的、跨組織的儀表盤的必要性。
對於 Majors 來說，可觀察性就是確保“已知的未知”大於或等於“未知的未知”。
有些問題只有你找到方法才能看出來。你必須收集細節資訊，這樣才能找到其中的任何一個。
Majors 將可觀察性稱為尋找異常值的遊戲——如果你有十幾個故障案例，根據收集到和查詢到的資料，它們有什麼共同之處？她說，你應該關心每個請求是否能夠成功，以及是否能夠讓資源端到端地工作。
分散式系統面臨著巨大的挑戰，因為它們實際上更類似於一個相互連線的系統網路，其中許多系統超出了我們的控制範圍。因此，無法直接觀察它們。
監控是監控，而觀察是生產環境中事件優先的測試
Majors 指出，“架構的每個部分都是獨一無二的，所以你必須測試它。你必須在生產環境中測試它，因為在進入生產環境之前，你只能測試這麼多。”她解釋說，部署程式碼不是一個只有開 / 關狀態的二元開關。
當然，你可以在部署到過渡環境之前和部署到生產環境之後進行測試，但這可能會耗盡通常有限的工程資源。Majors 建議接受這樣的現實，無論你是否打算在生產環境中進行測試，並建議使用類似於金絲雀測試這樣的技術作為保障，幫助你實現可觀察性。
她將可觀察性稱為缺失的環節，它允許軟體所有者在生產環境中進行測試，提供軟體的事件優先視角，軟體是如何被使用的，以及它對這種使用的反應如何。
Majors 說，良好的自動化監控包括以下最佳實踐：
-
許多可操作的活動檢查和警報
-
主動通知工程師故障和告警
-
維護一個執行手冊，保證生產系統的穩定性和可預測性
-
對緊密耦合的系統叢集同時崩潰有預期
但是，對於微服務，它變得更加複雜，有更多“未知的未知”。
有太多的元件和儲存系統，你無法在頭腦中對整個系統建模。系統的健康並不重要——每個請求的健康才是最重要的。
TDD 只覆蓋了已知的未知，這成為了一個支援問題。這些都是可預測的，可以在可預測的時間框架內進行處理，並且可以在儀表板上進行監控。
“未知的未知”仍然是一個工程問題。通常，在修復的過程中，這些問題是沒有預期結論的，需要對系統進行探索和創造力。這是開發者應該花時間去做的事情。可觀察性解決了這個巨大的未知。
可觀察性是尋找未知和發現事件
Majors 說，要想正確地觀察事物，你應該在考慮構建什麼東西的時候就把它加入進來，讓它成為你開發過程中固有的一部分。
她說，這是關於尋找未知，從內到外進行系統微調。它是關於成為下一個使用者的優秀軟體管理員，即使那個使用者六個月後想知道你為什麼會做出那樣的選擇。
進入軟體的內部，向你自己和天真的使用者說明這個軟體——找到那些線索，留下它們，這樣，未來的你就可以追溯到它的源頭。
監控主要與度量有關，而可觀察性則與事件有關。Majors 建議首先致力於除錯高基數事件——重要但通常是唯一的資訊，如標識號、使用者名稱和電子郵件地址——因為它們涉及大量上下文和跟蹤資訊。
她說，事件講述的故事可以幫助你發現來龍去脈和異常值，從而幫助你找出問題所在。她繼續說，頻寬和成本限制了你隨時儲存“所有資料”的能力，但“因為這是我們大腦的工作方式，這是我們程式碼的工作方式”，所以構建聚合資料日誌是至關重要的。
根據 Majors 的說法，建立儀表板並不是答案：“它是以往故障的產物。它會跳到答案，而不是從一個問題開始，”Majors 主張什麼都要實時，而不是掌握趨勢。她繼續解釋說，可觀察性要求能夠從取樣資料一直深入到原始請求。聚合不起作用，因為你永遠無法再次展開以前合併在一起的資料。但是，抽樣可以讓你保留足夠的細節，以便以後提出更多問題。可觀察性是關於問一個問題並追蹤答案。然後問一個新問題。重複這個迴圈，直到發現“未知的未知”。
服務所有者而不僅僅是運維者
服務確實需要所有者，而不是運維者，它們需要所有者在編寫一行程式碼之前就關心可觀察性。
在一個永遠線上的 DevOps 新世界中，這意味著開發人員需要具有更高的運維素養，並且能夠流暢地編寫自己的程式碼。Majors 說，要達到這種熟練程度並真正理解“異常”是什麼樣子，開發人員需要觀察他們的程式碼在生產環境中的執行。Majors 表示，這將使生產事件減少 80%。
她認為，在將來的某個時候，人工智慧和機器學習將使軟體達到能夠感知環境和自我修復的水平。
關於 Majors 的看法，有一個重要的前提，就是適當的可觀察性將大幅減少呼叫告警，只有延遲問題會被標記出來。
關於作者
Jennifer Riggins是一位科技故事講述者和作家，在這個領域，數字變革與文化交匯，她希望能使世界變得更美好。感興趣的讀者可以關注她的推特（@jkriggins）。
檢視英文原文：[Observability-Driven Development for Tackling the Great Unknown](