討論失敗并從中吸取教訓(xùn)

利用每一次失敗來學習，吸取重要的教訓(xùn)。采用事后分析方法，在故障較少的環(huán)境中推測故障。應(yīng)用理由:我們從失敗中才能獲得最深刻的教訓(xùn)，而不是從成功中。不要讓任何失敗浪費掉。從每次失敗中學習，發(fā)現(xiàn)需要改正的技術(shù)、人員和流程上的問題。
在聚會中，每當談到世界大事時，我們中的許多人都可能會說“我們好像從未吸取歷史上的教訓(xùn)”。但又有幾個人能真正在工作中對我們自己、我們創(chuàng)造的東西和我們的團隊執(zhí)行這個標準呢?在這個具有高可用性和高可擴展性的技術(shù)平臺上，存在一個有趣的悖論，即最初構(gòu)建的系統(tǒng)最好，不常發(fā)生故障，因此讓團隊學習的機會不多。這個悖論的內(nèi)在含義就是，流程、系統(tǒng)或人員定負載的條件下測試腳本，確保在應(yīng)用程序使用數(shù)據(jù)庫時，它仍然能夠執(zhí)行。

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

文章名稱：討論失敗并從中吸取教訓(xùn)
網(wǎng)址分享：http://www.bm7419.com/news42/145192.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供App開發(fā)、軟件開發(fā)、全網(wǎng)營銷推廣、移動網(wǎng)站建設(shè)、網(wǎng)站設(shè)計、App設(shè)計

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)