Azure DevOps：善用可觀察性事件和警示！

如果您在大型分散式環境中使用微服務，那麼您可能已經完全控制了監控和登入，甚至還利用通過檢測的 APM (分散式追蹤) 來處理客服需求。但是，您知道您在可觀察性上仍可能有所不足？

在您處理過的事件中，有多少是在經歷數小時的偵查後，還是得讓一個團隊回溯某個部署才能搞定？情況比你想像的更常見！ 

正如之前在 Splunk 部落格文章中提到的：Jenkins、OpenTelemetry、Splunk 可觀察性，除非您善用上述事件和警示的最大潛力，否則您可能會錯失軟體生命週期和持續整合/持續交付 (CI/CD) 流程的關鍵要素。以事件為基礎的 CI/CD 資料可能會出現 MTTD/MTTR 從數分鐘變成數小時的差別！

透過我們的新 Azure DevOps 整合功能，包含向 Splunk 可觀察性發送事件和以警示為基礎的版本閘道，您可以開始將 CI/CD 整合到企業的監控實務中！

處理事件並利用部署事件和警示
請花點時間自問：
•    「我知道我的軟體何時部署嗎？」
•    「我需要點擊多少次才能知道部署何時進行？」
•    「我是否知道我的軟體所依賴的上游服務何時部署？」
•    「我如何知道這些服務的部署何時開始影響我的軟體？」

Splunk 可觀察性為事件提供高度可見性，並可以容易地在儀表板上使用事件標記/參考線，而且它們基本上是「免費資產」，不需要費用。想像一下，您可以在儀表板上放進各種相關資訊，以及用來標記部署開始、成功、失敗等事件的標記。除了觀看自己的服務，還也可以掌握您依賴的上游服務！

 

圖 1-1在您的儀表板圖表上快速查看來自 Azure Devops 的 CI/CD 事件

CI/CD 事件對我的技術部門有什麼好處？
成功的監控 (以及關聯事件管理) 完全取決於整體情境和溝通！透過幫助軟體團隊快速確定某部署是否影響了他們的服務或其他服務的效能，可以縮短他們的平均檢測時間 (MTTD) 和平均解決時間 (MTTR)。
1.    IT 營運/支援分析人員：作為 IT 營運團隊的成員 (或負責人)，我希望獲得重要服務的最新版本資訊，以便在部署導致服務中斷或與其有關時快速通知軟體團隊。 

2.    開發營運/網站可靠性工程師 (SRE)：作為 DevOps 或 SRE 團隊的成員 (或負責人)，我需要確保服務是健康的，若否，就必須快速追查原因。讓相關負責人有能力了解因部署應用程式和基礎架構而引發的問題，可幫助他們改進軟體開發和部署實務。

3.    軟體開發人員：作為軟體開發團隊的成員 (或負責人)，我想在用戶受到影響之前就知道近期我部署的軟體或上游服務是否有問題，而且無須在不同的工具和介面之間切換。
 
重點在於使用單一介面管理，減少在多個工具之間切換並提供更多情境內容！但是，我們的另一個 Azure DevOps 整合功能還有其他優點。 

請試用 Microsoft Marketplace 中的 Splunk 可觀察性事件整合功能！

閘道有問題！發出警示！
如上所述，建立與軟體部署相關的警示和/或事件非常有價值。了解您的服務或上游服務何時部署，是開發、SRE、CI/CD 和 DevOps 團隊的重要信號。但是，下一步應該是主動開始根據 Splunk 可觀察性警示來設置版本閘道。

例如，下圖 1-2 所示的設定有三個步驟。首先，在管線啟動時它會向 Splunk 可觀察性發送一個事件，以便標記這次部署，然後檢查是否有觸發服務警示，最後在完成發布的其他程序時，再次檢查是否會觸發上游服務的警示。

圖 1-2根據 Splunk 可觀察性警示設置部署閘道

軟體團隊通常會根據警示建立版本閘道。但是，在和您本身服務有關的事件中，這種作法可能會適得其反。在緊急的意外事件期間，您最不應該做的一件事情就是不部署修正程式。在這些情況下，只需單擊介面即可輕鬆略過 Azure DevOps 管道中的版本閘道。

在大多數情況下，更好的作法是根據上游服務的健康狀況來控制您的部署或版本。以下是一個範例列表，或許有助於您的版本控制實務：
•    如果貴公司的邊界路由器出現問題，您就很難確定某特定的部署是否能正常運作。應該考慮延後部署，直到這些問題和相關警示解決，消費者反應再次流動為止。

•    如果您依賴另一個團隊的服務來獲得正確和及時的回應，則您可以考慮根據他們服務的健康狀況設定版本閘道。您最不應該做的，就是部署更多變更到環境中，使已經發生的事件更複雜。

•    雲端中的相關服務，無論是完全託管還是其他類型 (例如 DynamoDB 或 BigQuery)，也可能發生中斷。當這些無法控制的情況使部署的健康狀況變得更加複雜時，阻擋這些事情可以避免部署遭到變更。

•    以 Splunk APM、Splunk 綜合監控 (Synthetics) 或 Splunk 真實使用者監控 (RUM) 指標為基礎的警示，可為您提供更緊密監控特定 Web 資產或使用者操作的版本閘道。對於需求更進一步的組織，這項功能可以作為客戶如何與您的軟體互動的最終檢查。
版本閘道是保護整個軟體環境完整性的主要工具。在事件持續期間防止進一步變更，將有助於保護服務的可用性 KPI。在遇到麻煩時主動防止錯誤的部署，也能改善您和同事在事件管理時的關係！

請試用 Microsoft Marketplace 中的 Splunk 可觀察性警示閘道整合功能！

前往未來的狀態！
如前所述，Splunk 可觀察性中的事件和警示無須擷取、儲存或使用的成本。大多數組織都沒有利用這種「免費資產」，而這些資訊卻可以為軟體團隊、事件管理和 CI/CD 流程提供巨大的價值。

標記部署、版本甚至是基礎架構變更事件，可以為監控作業提供所需的相關資訊。

警示通常被用於通報服務運作狀況和通知待命人員，可以將軟體環境的一些相關資訊傳送到您的部署管道。 

但是，警示和事件不必只侷限於內部因素。善用其他 Splunk 可觀察性產品的警示和事件報告，可以為貴組織提供更多尚未被利用到的相關資訊。 
•    綜合測試：「顯示 US-West-2 的 AWS 狀態頁面是否已經當機？什麼時候開始的？」

•    真實使用者監控 (RUM)：「從我們上週二變更 CDN 設定開始，歐盟地區行動使用者的延遲似乎開始緩慢而穩定地增加了……」

•    APM：「在上個月的 AMI 變更之後，使用者在結帳時開始遇到斷斷續續的問題。」
 
除了對內之外，開始對外檢視對 SaaS 服務、廠商設定或外部流程的特定變更是否影響了您的軟體！  

下一步
對相關內容有興趣嗎？想要在單一管理平台中獲取更多監控資訊，並將您的開發營運 (或開發安全營運) 作業提升到最高層次？請查看 Splunk 可觀察性！

請註冊並開始免費試用 Splunk Observability Cloud 產品套件！
________________________________________
這篇文章由 Splunk 可觀察性現場解決方案工程師 Jeremy Hicks 撰寫，並感謝 Splunk 的 Doug Erkkila、Adam Schalock、Todd DeCapua 和 Joel Schoenberg。

 
作者
Jeremy Hicks
Jeremy Hicks 是多家財星 500 大 (Fortune 500) 電子商務公司的可觀察性推廣大使和 SRE 專家。他對監控、韌性工程、雲端運算和開發營運實務極具熱情，為可觀察性領域提供了獨特的觀點。