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

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

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



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

消除單點(diǎn)故障

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

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

監(jiān)控

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

發(fā)布管理

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

運(yùn)維架構(gòu)復(fù)審

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

配置管理

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

隨時待命和提升過程

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

不穩(wěn)定的組件

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

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