可觀測性驅動的軟件開發（Observability Driven Development，縮寫為 ODD）鼓勵開發團隊在整個開發過程中考慮應用程序的可靠性和軟件質量，利用工具或是開發人員的插樁來觀測系統的狀態和行為。可觀測性并不是要直接調試代碼邏輯，而是在每次新功能或者版本發布到生產環境后，檢驗生產環境的狀態，幫助發現并定位潛在問題，找出系統中需要調試的代碼所處的位置。
這里有一些最佳實踐和準則可以遵守，包括建立文化、有意義的代碼插樁，還有選擇合適的可觀測工具。
建立文化
開發不應該只是關注于產品功能的實現，也需要為系統整體的可靠性負責。在這個認知的前提下，我們也需要建立可觀測性驅動的開發文化，鼓勵開發更好地參與到可觀測性的建立上來。
擁抱失敗：與其害怕失敗，拼命避免失敗，不如認清現實，那就是 100% 可靠的系統在現在這個時代是不存在的。所以我們首先需要承認，我們不可能預測到代碼在生產環境中出現問題的所有方式。所以說，如果仍然只采取測試驅動的開發方式，是無法有效地編寫所有的測試用例的。
允許犯錯：同樣，也正是由于這個世界上沒有 100% 可靠的系統，如果不能容忍一個因為無心之失引發的錯誤，那整個團隊就會變得畏手畏腳，抵觸改變，進入一種少做少錯的狀態。這絕對不是我們的初衷。我們事件后審查的目標應該是識別系統和流程中的弱點，并通過建立可觀測性和工程化來避免這個錯誤再次發生。
拒絕個人英雄主義：英雄文化是建立可觀測性的文化的障礙。如果你的團隊中只有極少數人擁有在生產環境中進行故障排除所需的知識，風險就比較大了。因為現代分布式系統比幾年前的系統復雜得多，繼續依靠少數人甚至一個人的能力來理解和調試這些系統是不可信的。我們應該去讓大家都能夠理解可觀測性，學會使用工具分析問題，減少對少數“專家”的依賴。
更新之后盡早排查：當開發人員把代碼部署到生產環境后，應及時通過可觀測性來查看生產環境的狀態，而不是被動地等著最終用戶反饋問題。構建系統的開發人員比任何人都更了解系統，如果及時注意到那些可以在早期修復的異常，可觀測平臺的效果就充分顯現出來了。
鼓勵有意義的代碼插樁
我們在代碼設計階段，就必須考慮和確定系統在生產環境運行時需要達到的目標。比如說，定義好服務水平目標 SLO，為了提供預期的服務質量，你需要什么程度的可觀測性？你的用戶關心什么？他們會注意到什么？試圖找出可能出錯的地方，以及提前發現錯誤的方法。
極客時間版權所有: https://time.geekbang.org/column/article/575311
代碼插樁主要包括下面幾種類型。
第一種類型，日志推薦，它是以 JSON 方式輸出的。這個方式最重要的是在日志輸出過程中能夠添加與業務分割相關的標簽（即我們常說的 tag），以便后續的日志分析統計。
第二種類型是鏈路追蹤。一般情況下，我們可以通過無埋點的方式進行追蹤，但是如果開發工程師針對部分業務可以進行深入的埋點，或者集成更多業務相關的標簽，那會更有意義。
第三種類型是用戶體驗監測，即 RUM（Real User Monitoring）。如果前端或者 App 端開發工程能夠將用戶體驗也納入到整體的可觀測性范圍內，那么就可以進一步地保障用戶的服務質量，更有效地發現和定位問題了。前端或者 App 端團隊要對用戶體驗進行集成，可以采用插樁或集成更多業務相關標簽等方式。
最后，我們還可以建立統一的數據規范。例如，相同的指標命名規范、相同的日志格式、相同的鏈路系統（即使都遵循 OpenTelemetry 標準，仍會出現不同），定義串聯整個系統的統一標簽規范（如，所有錯誤都是 Status: Error）。
《深入淺出可觀測性》課程筆記 day08
