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

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

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

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

廣告

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