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

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

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



經(jīng)過(guò)了多年的事后分析經(jīng)歷，我發(fā)現了一些內容，你可能會(huì )考慮將其用于改正性活動(dòng)，我稱(chēng)其為網(wǎng)站可操作性。

消除單點(diǎn)故障

硬件可能，也將會(huì )，失效。使用冗余進(jìn)行防護。不要讓硬件失效成為發(fā)生影響客戶(hù)的事件的原因。
 
容量規劃

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

監控

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

發(fā)布管理

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

運維架構復審

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

配置管理

隨著(zhù)系統的增長(cháng)，生產(chǎn)環(huán)境中的配置也會(huì )變得越來(lái)越復雜。無(wú)法理解更新對生產(chǎn)配置的意義往往會(huì )導致人為事故的發(fā)生。有一個(gè)易懂、好用的配置管理系統，將有助于工程師避免這些無(wú)意中發(fā)生的問(wèn)題。請參閱本書(shū)第5章，查看更多的建議。

隨時(shí)待命和提升過(guò)程

識別問(wèn)題，盡快提交給能夠解決問(wèn)題的人。

不穩定的組件

標識并修復那些發(fā)生過(guò)崩潰以及人為事故的軟件組件，將其標識為高優(yōu)先級，即使它們易響 于手工修復。這些手工修復累積起來(lái)，會(huì )對客戶(hù)體驗、伸縮能力以及效能都造成負面影。

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