事后分析的后續工作有哪些？

發布：2018-06-23 14:40:37 瀏覽：1880

對糾正措施必須進行追蹤，直到執行完成。要記住，在糾正措施沒有得到完全執行之前，事故重發的風險會一直存在。必須確保執行人和完成日期都落實到位，而且執行人要一直負責到底，哪怕原來的事件已逐漸成為過去。要在錯誤追蹤系統或其他類似工具中將其標記為高優先級項目，這樣有助于確保正確的信息都記錄下來了，從而避免丟失。

改正性活動常常會和開發活動競爭資源的優先權屬。對于網站的穩定性和新功能，在重要程度上給予同等對待，在這點上取得管理層的支持，非常重要。聲稱網站穩定性最重要的公司，對于確保改正性活動的完成，大有幫助。糾正措施要根據能夠防止的類似事故的數量來確定優先順序，假如一項措施只能糾正當前發生的事故，而另一項措施卻能修復一批可能的類似事故，則肯定后者會得到更高的優先級，從而工程部門也會將精力集中在這項措施上。

另外，確保將事后分析的數據錄入到最終工具中，為事件賦予一個根本原因類別，以便對其進行數據挖掘，從而管理層也能夠對長期趨勢進行識別。我們使用這樣的事故類別，如硬件失效、與更新有關、容量/流量事故、已存在的軟件錯誤，對事故進行歸類。使用歷史數據，對申請哪些資源、使用什么樣的工具、啟動什么樣的自動化項目進行更加明的策。要將資源用在多發的事故類別上，從而在整個公司范圍內有組織地降低這些事故的發生率。有宕機的歷史數據，對于調整有難度、耗資源的項目是特別有用的。

經過了多年的事后分析經歷，我發現了一些內容，你可能會考慮將其用于改正性活動，我稱其為網站可操作性。

消除單點故障

硬件可能，也將會，失效。使用冗余進行防護。不要讓硬件失效成為發生影響客戶的事件的原因。

容量規劃

了解網站將來的容量需求。將容量規劃建立在主要的約束條件(如CPU、內存、I/O及存儲)的整體利用率的基礎上，而不要建立在次要約束條件(如用戶數量)的基礎上。對于這些你所需要的東西，要在需要之前，就做好預備。

監控

監控對于檢測和診斷事故是非常重要的。本書的其他章節對于監控已經提供了大量的建議。

發布管理

從歷史上看，更新是引發事故的主要原因。要確保你的發布過程具有適當的質量控制，要考慮這樣的實現概念，如自動測試、預演環境、受限的生產部署、暗啟動(部署代碼，但不激活其功能，直到證明代碼是穩定的)以及立即回滾的能力。

運維架構復審

在發布之前，對架構進行復審，對新的發布或產品在生產環境中將會如何執行進行審查，要考慮可維護性、失效場景、對事件的響應以及架構的可靠性和可伸縮性。

配置管理

隨著系統的增長，生產環境中的配置也會變得越來越復雜。無法理解更新對生產配置的意義往往會導致人為事故的發生。有一個易懂、好用的配置管理系統，將有助于工程師避免這些無意中發生的問題。請參閱本書第5章，查看更多的建議。

隨時待命和提升過程

識別問題，盡快提交給能夠解決問題的人。

不穩定的組件

標識并修復那些發生過崩潰以及人為事故的軟件組件，將其標識為高優先級，即使它們易響于手工修復。這些手工修復累積起來，會對客戶體驗、伸縮能力以及效能都造成負面影。

要采取積極主動的行動，確保網站建設內容的可操作性，能避免很多痛苦的事后分析。