可觀察性驅動開發與監控有什麼不同？隨著我們的分布式系統變得越來越複雜，隨著我們對devops測試、自動化和效率的追求，筒倉的打破，為了了解**中未知的未知，odd作為一種超級監控而出現。本文包括honeycomb創始人charity majors的見解。毫無疑問，系統越分散就越複雜。這使得24/7監控和隨叫隨到的輪流值班對大多數公司來說都至關重要。但是，可觀察性是如何影響我們越來越短的devops反饋迴圈的呢？本文概括介紹了從honeycomb創始人和可觀察性的強烈支持者charity majors那裡了解到的關於可觀察性驅動開發的經驗。
在倫敦舉辦的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說，良好的自動化監控包括以下最佳實踐：
但是，對於微服務，它變得更加複雜，有更多「未知的未知」。
有太多的元件和儲存系統，你無法在頭腦中對整個系統建模。系統的健康並不重要——每個請求的健康才是最重要的。tdd只覆蓋了已知的未知，這成為了乙個支援問題。這些都是可**的，可以在可**的時間框架內進行處理，並且可以在儀表板上進行監控。
「未知的未知」仍然是乙個工程問題。通常，在修復的過程中，這些問題是沒有預期結論的，需要對系統進行探索和創造力。這是開發者應該花時間去做的事情。可觀察性解決了這個巨大的未知。
majors說，要想正確地觀察事物，你應該在考慮構建什麼東西的時候就把它加入進來，讓它成為你開發過程中固有的一部分。
她說，這是關於尋找未知，從內到外進行系統微調。它是關於成為下乙個使用者的優秀軟體管理員，即使那個使用者六個月後想知道你為什麼會做出那樣的選擇。
進入軟體的內部，向你自己和天真的使用者說明這個軟體——找到那些線索，留下它們，這樣，未來的你就可以追溯到它的源頭。監控主要與度量有關，而可觀察性則與事件有關。majors建議首先致力於除錯高基數事件——重要但通常是唯一的資訊，如標識號、使用者名稱和電子郵件位址——因為它們涉及大量上下文和跟蹤資訊。
她說，事件講述的故事可以幫助你發現來龍去脈和異常值，從而幫助你找出問題所在。她繼續說，頻寬和成本限制了你隨時儲存「所有資料」的能力，但「因為這是我們大腦的工作方式，這是我們**的工作方式」，所以構建聚合資料日誌是至關重要的。
根據majors的說法，建立儀表板並不是答案：「它是以往故障的產物。它會跳到答案，而不是從乙個問題開始，」majors主張什麼都要實時，而不是掌握趨勢。她繼續解釋說，可觀察性要求能夠從取樣資料一直深入到原始請求。聚合不起作用，因為你永遠無法再次展開以前合併在一起的資料。但是，抽樣可以讓你保留足夠的細節，以便以後提出更多問題。可觀察性是關於問乙個問題並追蹤答案。然後問乙個新問題。重複這個迴圈，直到發現「未知的未知」。
服務確實需要所有者，而不是運維者，它們需要所有者在編寫一行**之前就關心可觀察性。她認為，在將來的某個時候，人工智慧和機器學習將使軟體達到能夠感知環境和自我修復的水平。
關於majors的看法，有乙個重要的前提，就是適當的可觀察性將大幅減少呼叫告警，只有延遲問題會被標記出來。
jennifer riggins是一位科技故事講述者和作家，在這個領域，數字變革與文化交匯，她希望能使世界變得更美好。感興趣的讀者可以關注她的推特（@jkriggins）。
檢視英文原文：[observability-driven development for tackling the great unknown](
可觀察性驅動開發，探索未知之地
可觀察性驅動開發與監控有什麼不同？隨著我們的分布式系統變得越來越複雜，隨著我們對devops測試 自動化和效率的追求，筒倉的打破，為了了解 中未知的未知，odd作為一種超級監控而出現。本文包括honeycomb創始人charity majors的見解。毫無疑問，系統越分散就越複雜。這使得24 7監控...
可觀察性驅動開發，探索未知之地
可觀察性驅動開發與監控有什麼不同？隨著我們的分布式系統變得越來越複雜，隨著我們對devops測試 自動化和效率的追求，筒倉的打破，為了了解 中未知的未知，odd作為一種超級監控而出現。本文包括honeycomb創始人charity majors的見解。毫無疑問，系統越分散就越複雜。這使得24 7監控...
可觀察性驅動開發，探索未知之地
可觀察性驅動開發與監控有什麼不同？隨著我們的分布式系統變得越來越複雜，隨著我們對devops測試 自動化和效率的追求，筒倉的打破，為了了解 中未知的未知，odd作為一種超級監控而出現。本文包括honeycomb創始人charity majors的見解。毫無疑問，系統越分散就越複雜。這使得24 7監控...