在聚會中，每當談到世界大事時，我們中的許多人都可能會說“我們好像從未吸取歷史上的教訓”。但又有幾個人能真正在工作中對我們自己、我們創造的東西和我們的團隊執行這個標準呢?在這個具有高可用性和高可擴展性的技術平臺上，存在一個有趣的悖論，即最初構建的系統最好，不常發生故障，因此讓團隊學習的機會不多。這個悖論的內在含義就是，流程、系統或人員定負載的條件下測試腳本，確保在應用程序使用數據庫時，它仍然能夠執行。
口對應用中的SQL查詢進行約束。開發團隊需要消除所有SQL語句中的歧義，刪除所有 SELECT*查詢，并且給 UPDATE語句加上要更新的列的名字。
口數據的語義修改。在發布版本中，開發團隊不能修改數據的定義。舉個例子。票務表中的一列用于存放狀態信號，其中有三個值assigned、 fixed和closed。在應用的新版本中，如果沒有發布處理新狀態的代碼，就不能添加第四個狀態。
口Wire On/ire Off』。應該讓應用結構化，使其能根據外部配置，讓有些用戶能夠訪問某個代碼路徑和功能，而有的用戶則不能訪問。這種設置可以存放在配置文件中，也可以存放在數據庫表中既能夠根據角色賦予訪問權限，也能夠根據隨機百分比分配權限。有了這種結構，就能夠讓有限的用戶對新功能進行beta測試，而且能夠迅速地刪除主要bug的代碼路徑，從而不必回退整個代碼。我們得到的教訓雖然慘痛，但是很有價值，有了這次教訓，我們再也不會發布不能回退的代碼了。即使以后和其他團隊一起工作，我們也會這樣要求自己的。可見，這些原則并不復雜，而是相當簡單，仟何團隊都能夠應用它們，都能具備回退的能力。方面的每一次失敗都給我們提供了執行事后分析的機會，從而讓我們能夠有所長進并修改系統。若不能把握好這些寶貴的機會來提高自身水平、改進流程并改善技術，我們就不能像今天這樣正常運轉下去，從而導致又一次失敗。如果這種情況發生在超高速友虔而要積被進付抄的冏業現，那一足公慘遭經當失敗。當我們在快速發展時，會發生太多事情，兩年甚至一年前設計的解決方案是無法支持相當于構建系統時10倍的業務量的。
核電時代我們可以更深入地了解為什么要從失敗中吸取教訓。1979年，三里島核電站第2組反應堆的部分熔毀，成為美國歷史上最重大的核電事故。這一事故為多本書和至少一部電影提供了素材，還產生了兩個重要理論，涉及的是在很少發生事故但一旦發生代價很高的環境中學習的必要性。
Charles Perrow提出了正常事故理論。該理論推斷，現代耦合的系統的內在復雜性使得事故不可避免。這些系統的內在耦合性會使交互急劇升級，致使人或控制系統根本沒有機會進行成功的交互?；叵胍幌?，你是不是經常遇到這種情況，正在監控的解決方案突然從“綠色”全部變成了“紅色”，而在此之前，你甚至來不及對第一個警告信息作出反應Todd Laporte提出了高可靠性組織的理論。他相信，即使沒有發生能夠讓一個組織學習的事故，也會有一些組織策略能夠實現高可靠性。2)雖然這些理論的作者沒有就這些理論是否能共存達成共識，他們還是有一些共同點的。首先，失敗過的組織有更多的機會學習，通常比沒有失敗過的組織發展得更快，當然，這里假設他們會利用這些機會從中學習其次，和前者相似，很少出故障的系統提供的學習機會少，如果沒有其他的方法，那么相關的團隊和系統就難以發展和提高。
討論完從失敗中吸取教訓從而獲得提高這個主題后，我們簡單介紹一個輕量級的流程，通過這個流程我們可以學習和提高。對于經歷過的每個重大問題，我們認為相關組織都應該對這些問題進行事后分析，可用如下三個階段來解決問題。
口階段1，時間軸。為造成問題或危機的事件生成一個時間軸。這階段只討論時間軸。我們經常發現，即使已經完成了時間軸，在下一個階段，人們還是會想起或者發現值得標注到時間軸上的事件。
口階段2，發現問題。該流程的主持者會與相關的團隊一起工作，按照時間軸逐一檢查，發現其中的問題。第一個監控器在早晨8點發現了客戶故障，但是直到中午都沒有人對其進行響應，這樣可以接受嗎?為什么數據庫沒有進行自動故障恢復?為什么我們認為刪除用戶授權表會使應用重新開始運行?從時間軸中發現每一個問題，但是在問題識別階段結束之前，不能執行任何修改或其他操作。當然，團隊成員要提出建議執行的操作，但讓團隊在階段2專注于問題識別是該流程的主持者的責任
口階段3，說明操作。對于發現的每一個問題，至少要有一個與之關聯的操作。該流程的主持者會與相關的團隊一起遍歷問題清單，標識出要執行的操作、這個問題的負責人以及預期的結果和應該完成操作的時間。根據 SMART法則，每個操作應該是具體的、可衡量的、可實現的、現實的且及時的。即使一個操作需要一組人來完成，也需要標識出一個負責人。
直到造成故障的人員、流程和技術方面的問題都解決了，一次事后分析才算完成。我們]經常發現，客戶會把“服務器死機”作為一個偶然事件的根本原因。任何一個偶然事件的根本原因，都不能歸咎于單一的失敗，無論是硬件故障，還是人員和流程的失誤。任何擴展性和可用性方面的失敗，真正的問題都是“為什么整個系統不能運行得更好呢”。如果數據庫失敗是由于負載問題，那么為什么相關組織不能早點兒發現負載需求呢?應該采用什么樣的流程或監控措施，才能幫助組織發現問題呢?為什么需要花費這么長時間從故障中恢復呢?為什么沒有劃分數據庫，讓故障對客戶或服務的影響小小一些呢?為什么沒有一個數據庫的讀副本迅速地被提升為寫人副本呢?根據我們的經驗，至少要回答五個覆蓋不同方向的“為什么”的甚
既然已經討論過了應該做什么，那么下面來看看沒多少出故障機會的例子。有些組織幸運地擁有能夠有效擴展且很少出故障的平臺，Weick和 Sutcliffe為這樣的組織提供了一個解決方案。我們根據需求對他們的方案稍加修改，改后的方案如下所示。
口關注故障。這個實踐就是監控產品和系統，實時地報告發生的錯誤。他們認為，成功會麻痹感覺，滋生自負心理。要與這種自滿情緒作斗爭，組織需要保持系統故障和失敗徹底透明。監控報告要廣泛地分發下去，并且要在每日例會這樣的環境中頻繁討論平臺的運維。
口拒絕簡化解釋。對一切都不要掉以輕心，尋求多種弓引人問題的可能。不用認為故障是正常的，是系統固有的。人們習慣把小小的波動解釋為“正常的”，其實它們可能是即將發生的故障的最早指示信號。
口關注運維。査看分鐘級別的詳細數據，包括實時數據的使用，不斷進行評估，并持續更新這些數據。
口培訓多技能員工。讓員工在不同的崗位上輪換，給他們培訓新技能，可以讓他們具備額外的能力。eBay以前的運維人員能夠證明這一點，它的DBA、SA和和網絡工程師都曾經在運維中心做過運維工作。此外，一旦給系統打了補丁，相關組織就應該迅速為下一次出現狀況做好準備。
口尊重專家。在危機事件中，要把領導權交給處理該問題最專業的人?？梢钥紤]在運維中心的危機管理機制中創建一個新職位，如“技術責任人”。
絕對不要浪費從網站制作失誤中學習的機會，因為這是對系統或平臺進行正確修改的最佳機會。把一種流程(例如事后分析的流程)落實到位，確A所有大中字的機公。如果你的條統設計得很好，即便超負荷作，也不常出故障，那么可以實踐一下預警能力，仔細觀察數據，以便發現將來可能出現的故障。在這種情況下，人們很容易自滿，你可以組織頭腦風暴或者推理活動，發現可能發生的各種故障事件。
本文地址：http://m.123beaconmarketing.com//article/3493.html
