“事件”被定義為計(jì)劃外停機(jī)或中斷，向用戶提供較低質(zhì)量的服務(wù)、部分或完全中斷服務(wù)。如果是重大事件，那么它就是一個“危機(jī)”。

 

當(dāng)事件開始影響提供給客戶的服務(wù)質(zhì)量時，它就會成為一個問題，因?yàn)榇蠖鄶?shù)服務(wù)提供商與消費(fèi)者簽訂了服務(wù)等級協(xié)議，這些協(xié)議通常內(nèi)置了懲罰措施。

 

行業(yè)專家指出，大多數(shù)企業(yè)并沒有設(shè)置實(shí)時處理與IT相關(guān)的事件或危機(jī)的機(jī)制。很多企業(yè)采用傳統(tǒng)的方法應(yīng)對危機(jī)，因?yàn)樗麄儧]有考慮采用云計(jì)算或者SaaS模式，而一些數(shù)字原生公司也并不太重視危機(jī)管理。

 

特別是對于“永遠(yuǎn)在線”的需求和要求，事件可能隨時發(fā)生，而且經(jīng)常發(fā)生在周末和節(jié)假日。當(dāng)事件發(fā)生時，準(zhǔn)備充分的企業(yè)必須處于識別、評估、管理、解決并有效地將其傳達(dá)給客戶的狀態(tài)。

 

這里要注意的另一個關(guān)鍵問題是安全事件和服務(wù)事件之間的區(qū)別。安全事件是指發(fā)生數(shù)據(jù)泄漏的情況。數(shù)據(jù)泄露的緩解和危機(jī)管理涉及采用一組不同的程序，從禁用帳戶到通知利益相關(guān)者和帳戶所有者以及將問題上報給安全和身份識別團(tuán)隊(duì)。服務(wù)事件是指部分或全部發(fā)生服務(wù)中斷。它需要DevOps、開發(fā)人員和Ops團(tuán)隊(duì)進(jìn)行處理。由于它們有些相似，一些危機(jī)管理程序可能會重疊。但是，如果企業(yè)的支持團(tuán)隊(duì)不知道正確的升級流程，那么他們可能會在緊急情況下向錯誤的渠道發(fā)送嚴(yán)重警報。在此只討論服務(wù)中斷，盡管安全事件也有很多相似之處。

 

 

在任何情況下，避免出現(xiàn)問題都比解決問題要好。企業(yè)可以做很多事情來避免這種情況，例如漏洞審計(jì)、預(yù)警監(jiān)控、代碼配置審計(jì)、發(fā)布審查、異常檢測等。企業(yè)還應(yīng)該投資于適當(dāng)?shù)目捎^察性、監(jiān)控、日志記錄和跟蹤解決方案。

 

 

大多數(shù)企業(yè)在發(fā)生事件時并沒有準(zhǔn)備或制定行動計(jì)劃。在數(shù)字世界中，事件不會等待數(shù)天的時間才能解決或管理。

 

 

在行業(yè)專家發(fā)布的一份名為“在數(shù)字經(jīng)濟(jì)中，應(yīng)該快速失敗但必須快速恢復(fù)”的文章中，討論了需要比客戶或合作伙伴更快地發(fā)現(xiàn)問題的速度。軟件開發(fā)已經(jīng)完全采用了DevOps和敏捷原則，但是運(yùn)營團(tuán)隊(duì)還沒有完全接受DevOps方法論。例如傳統(tǒng)的監(jiān)控系統(tǒng)，無論是應(yīng)用程序性能監(jiān)控、基礎(chǔ)設(shè)施監(jiān)控還是數(shù)字體驗(yàn)監(jiān)控系統(tǒng)，都可以很快發(fā)現(xiàn)是否存在服務(wù)中斷。然而在當(dāng)前的環(huán)境中，識別導(dǎo)致問題的微服務(wù)，或者識別導(dǎo)致這一問題已生效的更改是復(fù)雜的。

 

 

當(dāng)發(fā)生重大事件時，應(yīng)該是全員參與的情況。一旦確定了關(guān)鍵事件(第1級)，就應(yīng)為事件分配一名事件指揮者，必須立即打開協(xié)作作戰(zhàn)室(虛擬或物理)，并邀請服務(wù)所有者參與。如果可能的話，必須立即將問題上報給能夠解決問題的人員，而不是經(jīng)過L1到L3等工作流程，這會進(jìn)一步拖延進(jìn)程。此外，如果有太多人被邀請到這些協(xié)作作戰(zhàn)室，則必須有一種機(jī)制來識別故障平均調(diào)查時間(MTTI)，這樣，如果被邀請的人員沒有直接關(guān)系，也無法幫助解決問題，那么他們可以離開繼續(xù)開展他們的富有成效的工作。

 

 

當(dāng)發(fā)生重大服務(wù)中斷時，企業(yè)的用戶需要知道，服務(wù)所有者需要知道，企業(yè)主管需要知道。也就是說相關(guān)人員都應(yīng)該知道。其中一部分原因是外部溝通。最起碼要顯示一個狀態(tài)頁面，顯示服務(wù)的狀態(tài)和質(zhì)量，讓每個人都時刻了解服務(wù)狀態(tài)。此外，應(yīng)該對出現(xiàn)問題的原因、正在采取什么措施進(jìn)行修復(fù)以及可能的問題進(jìn)行初步解釋，或者作為狀態(tài)更新或在LinkedIn、Twitter、Facebook和企業(yè)所在的其他社交媒體平臺上的帖子中發(fā)布。企業(yè)的用戶通過社交媒體可以知道服務(wù)已關(guān)閉。如果用戶沒有得到任何更新的信息，那么企業(yè)的競爭對手可能就會散布謠言來破壞企業(yè)的品牌聲譽(yù)。

 

這是大多數(shù)數(shù)字公司比較薄弱的地方，因?yàn)樗麄儧]有做好準(zhǔn)備。而在工程師和支持團(tuán)隊(duì)試圖解決問題的關(guān)鍵時刻，實(shí)時危機(jī)和聲譽(yù)管理至關(guān)重要。使用情緒分析和聲譽(yù)工具找出誰在說極端負(fù)面的話也是一個好主意，并嘗試讓他們離線直接處理或?qū)崟r回應(yīng)，以避免進(jìn)一步升級。

 

 

在很多企業(yè)看到的一個共同模式是，在解決了危機(jī)和事件之后，每個人似乎都很快轉(zhuǎn)向下一個問題。可能是因?yàn)閱栴}太多，導(dǎo)致企業(yè)的支持團(tuán)隊(duì)、DevOps和Ops團(tuán)隊(duì)不堪重負(fù)，或者他們認(rèn)為沒有必要分析發(fā)生了什么或?yàn)槭裁磿l(fā)生。危機(jī)/事件管理的一個特別重要的部分是弄清楚出了什么問題，為什么會出錯。更重要的是，企業(yè)如何才能根除這個問題，這樣就不會再發(fā)生這種情況。在找出解決方案后，將其正確記錄，還需要有一個存儲庫來存儲這些解決方案，以便在再次發(fā)生事件時，知道如何快速果斷地解決這個問題。

 

 

此外，與受其影響的頂級客戶討論這種情況;企業(yè)解釋為解決問題所做的工作以及如何解決問題，以避免重復(fù)。更重要的是，討論在事件發(fā)生之前是如何做好準(zhǔn)備的，這將給企業(yè)增加巨大的信心。這樣企業(yè)不僅不會失去客戶，而且會因?yàn)槠涮幚矸绞蕉@得更多收益。

 

此外，危機(jī)管理公司的建議是在事件發(fā)生之后取消企業(yè)計(jì)劃舉辦的其他活動。例如如果企業(yè)的關(guān)鍵服務(wù)中斷數(shù)天，而其高管正在拉斯維加斯參加大型會議，那么社交媒體對此也會十分關(guān)注。監(jiān)控社交媒體平臺(至少LinkedIn、Twitter、Facebook或企業(yè)在其他社交媒體平臺，包括對企業(yè)的博客網(wǎng)站的負(fù)面評論)的語氣;企業(yè)甚至可以使用基于人工智能的情緒分析工具來識別仍然不滿意的客戶，以討論他們擔(dān)憂的問題以及如何解決這些問題。在解決這些問題之前，企業(yè)的事件還沒有完全解決。

 

另一個最佳做法是在重大事件發(fā)生后的一段時間內(nèi)避免炒作或宣傳。一些企業(yè)繼續(xù)執(zhí)行這一計(jì)劃并得到客戶的強(qiáng)烈反對，而他們都在空談并且沒有產(chǎn)生任何實(shí)際效果。

 

 

每個企業(yè)遲早都會面臨這個問題。沒有人是無敵的。當(dāng)問題發(fā)生在自己身上時，企業(yè)準(zhǔn)備好應(yīng)對它了嗎?處理得當(dāng)?shù)钠髽I(yè)可以獲得客戶的信任，表明他們已準(zhǔn)備好應(yīng)對未來再次發(fā)生的事件。

 

那么，企業(yè)是通過正確的方式來獲得客戶的信任，還是通過弄虛作假和掩飾而失去信任?這將決定企業(yè)的未來發(fā)展。

 

企業(yè)需要在云計(jì)算時代的工具選擇、最佳實(shí)踐、趨勢和適當(dāng)?shù)腎T事件/危機(jī)管理設(shè)置獲得建議，以便在發(fā)生這種情況時做好準(zhǔn)備。

 

版權(quán)聲明：本文為企業(yè)網(wǎng)D1Net編譯，轉(zhuǎn)載需注明出處為：企業(yè)網(wǎng)D1Net，如果不注明出處，企業(yè)網(wǎng)D1Net將保留追究其法律責(zé)任的權(quán)利。