產(chǎn)品詳細介紹
運維誤操作
PEBKAC錯誤是常見的錯誤。江西服務(wù)器數(shù)據(jù)恢復(fù)公司盡管可能，考慮到該網(wǎng)站的業(yè)務(wù)量以及雇員規(guī)模，其幾乎沒有可能使用單服務(wù)器部署應(yīng)用。但觀察到的錯誤狀況是幾乎所有的服務(wù)全部下線，因此，單臺服務(wù)器誤操作導(dǎo)致的災(zāi)難是幾乎沒有可能的。
一種災(zāi)難發(fā)生的可能是cascading failure。假設(shè)運維團隊在發(fā)布版本時，發(fā)布了錯誤的配置文件，盡管這種分發(fā)是在可控狀況下進行的，但因為系統(tǒng)在低發(fā)布率時崩潰有自愈能力，在百分比的發(fā)布時，由于可用系統(tǒng)的負載，導(dǎo)致可用系統(tǒng)退出服務(wù)，終導(dǎo)致所有可用服務(wù)均退出服務(wù)，服務(wù)宣告不可用?？紤]到此公司業(yè)務(wù)的復(fù)雜性，并觀察到其技術(shù)棧是大部分基于西雅圖郊區(qū)某公司的技術(shù)構(gòu)建的，幾乎可以肯定的是，部分中間件的支持實際上是依賴外部技術(shù)支持的。若是中間件或是第三方vendor提供的組件導(dǎo)致錯誤，很可能本地團隊無法做到及時響應(yīng)。事件發(fā)生時大約是太平洋時間下午9點，此時的技術(shù)支持很大可能是在印度或是澳大利亞進行的。作者的行業(yè)從業(yè)經(jīng)驗表明，印度技術(shù)支持在很大程度上是無法很快解決技術(shù)問題的。若是本地團隊沒有對應(yīng)對災(zāi)難做出playbook，則很有可能在生產(chǎn)環(huán)境故障時束手無措。
