起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識運營中斷怎么辦？企業會犯的10個錯誤
小編導讀：世界上沒有不存在缺陷的軟件，互聯網產品也都會遇到運營中斷，那么遇到運營中斷應該如何處理呢？
沒人喜歡談論運營中斷問題，如果你是一名公司員工，經歷過這種體驗一定會感到非?？膳隆Ｆ髽I一旦遭遇運營中斷，首先受到重創的就是顧客信任，其次也對企業未來的收入產生巨大影響。但是，它的確會發生。
即便是很多已經上市的科技巨頭，比如eBay和微軟，他們所擁有的資源可能比任何一家初創公司都要多，但是可悲的是，這些大企業也都深受過運營中斷之害。當這個悲劇發生之后，企業的所有業務都無法開展了，他們的股東和高管團隊也會因此非常懊惱，后悔沒有及時做好準備。事實上，根據全球權威調研機構Aberdeen Group估計，企業由于故障導致停擺的平均成本已經高達每小時16.1萬美元。
運營中斷的根本原因包括：
l 臭名昭彰的“烏龍指”(人為錯誤)
l 對于復雜系統和他們之間相關性了解不足
l 設備故障，包括設備過期，或者是設備沒有得到正確配置
l 被黑客攻擊，或是存在其他安全漏洞。
l 流程設備不夠完善，或是存在流程缺失
l 也可能是上述數個原因綜合在一起。
運營中斷導致的后果包括：
l 不可挽回地損失收入，比如在今年六月，Facebook被爆出現了半個小時的運營中斷，估計公司損失達到了50萬美元。
l 生產力嚴重損失，比如最近Office 365出現了故障，導致他們的客戶陷入困境之中，無法使用電子郵件服務。
l 客戶會感到憤怒，比如最近eBay斷斷續續出現了很多服務問題，這讓依靠eBay服務的很多小企業感到非常惱火。
l 導致企業徹底失敗，比如Codespaces公司之前受到了黑客的DDOS攻擊，給整個公司帶來了毀滅性的嚴重后果。這個黑客的目的是企圖敲詐勒索該公司，他們獲得了Codespaces公司亞馬遜EC2控制面板的訪問權，然后刪除了公司客戶數據，悲劇的是，這些數據都無法恢復了。
對于運營中斷是否會發生在你的公司，貌似已經不是個問題了(因為肯定會發生)，現在的問題是，它神秘時候會發生。企業想要在競爭中生存下來，那么就要更好地去應對、處理運營中斷問題，同時，還要從其他公司犯過的錯誤中吸取教訓。沒有人是完美的，而且即便有一次你把問題處理的很完美，也無法保證你每次都能如此。但是我們希望通過討論這些過來人所犯過的錯誤，并從現在努力做起，幫助你避免在未來重蹈覆轍。
在處理運營中斷時，企業犯的最多的十個錯誤：
1、 沒有一個經過檢驗且靠得住的運營中斷響應計劃
下面這段，聽上去是不是覺得耳熟?
運營中斷發生了?？蛻糁С謭F隊不得不向技術運營團隊發送大量電子郵件，及時報告故障情況，因為情況已經十萬火急了。公司的高管們會要求下屬每個五分鐘就匯報問題處理進展。技術團隊里的每個人都打開自己的監測工具，時刻關注數據何時可以疏通，但通常他們也只能看到問題的一部分而已。更大的混亂也會隨之而來，團隊之間開始互相指責對方，推卸責任，此時系統管理員更無法確定究竟是否要按照老板的要求，通過更新去解決問題，還是繼續處理問題，或是進行一個可行的修補。市場營銷部門和法律部門這會兒也跳了進來，他們也要對外做出回應。營銷部門會說，“我們的社交媒體正在被垃圾充斥!我們需要給用戶發送電子郵件，或是在官方博客上發帖，告訴大家到底出了什么事情!”;法律部門會說，“不要承認責任!”牛頭不對馬嘴，整個世界都要爆炸了!
好吧，世界當然不可能爆炸。但是如果上述中的前半部分讓你感到非常熟悉，那么你的公司正在犯錯誤，也就是，沒有一個經過檢驗且靠得住的運營中斷響應計劃。
那么，如何可以避免這個問題呢?
在處理運營中斷問題時，一個“格式正確的”流程是必須要確定的，誰來負責解決問題，誰來負責升級系統，以及誰來負責針對問題進行交流溝通;這些都需要落實到人。另外還要有事后剖析流程，分析究竟是什么原因導致出現的運營中斷故障，并且解決各種漏洞。事后剖析的范圍可以放得寬泛一些，從建筑物冗余，到各個相關系統，此外你還可以改變監測工具設置，這樣就能及時捕捉到問題原因，并及時解決，而且還能避免日后再次發生同樣的運營中斷故障。
2、在運營中斷發生時，缺乏與受影響的客戶溝通
一旦運營中斷發生，你肯定會迫不及待地希望自己公司能夠重新回到正軌，但是就在這最緊張的時候，反而最容易忙中出錯。不幸的是，如果你沒有及時和客戶進行溝通，那么往往還會引發一系列負面結果，比如客戶投訴電話將如潮水般涌入，等待時間會因為故障而變得更長，客戶體驗也會變得一塌糊涂，更可怕的是，運營中斷很可能給用戶造成一種惡劣印象，他們會覺得你的公司反應非常遲鈍，而且不值得信賴，靠不住。
故障往往還會讓公司內部面向客戶的團隊和你的技術運營團隊之間的溝通出現問題，要么溝通不到位，要么溝通完全不暢。如果你沒有一些可以發布公告，通知客戶的系統，比如博客、論壇、批量電子郵件、RSS訂閱，等等，那么將會造成很嚴重的問題。還有，公司之所以在發生運營中斷時不愿意與客戶溝通，其實還有一個錯誤的觀念，他們認為客戶可能不會注意到發生問題了，實際上，客戶肯定會注意到;另外他們還會覺得損失將會降到最低，但正是由于缺乏溝通，從而讓情況變得越來越糟糕。
如何避免：
無論是內部溝通，還是外部溝通，在運營中斷發生的過程中，或是在故障發生之后，你都要確保有一個明確的溝通流程，而且每個人都要清楚地分配好相應的職責。要確保每一個人明白自己所擔負的責任。不要簡單地把自己的工作職責掛在公司的網站上面，因為當運營中斷故障真的發生時，這么做一點作用都起不到。
3、逃避責任，玩兒“指責游戲”
為了對運用中斷故障有所回應，企業有時會把責任歸咎于合作伙伴或是供應商。但這么做很少能取得什么好的效果，因為客戶會把這種做法看成是你在逃避責任(誰選的供應商和合作后瓣?還不就是你嘛)。如果你不愿意去承擔責任，那么公司就無法從中吸取教訓，既無法避免同樣的問題再次發生，也不會讓公眾感到滿意。
如何避免：
你需要承擔更多的責任，并且要開始調查與故障有關的供應商，設置好冗余和審核過程，這些都有助于解決問題，解決問題的方法越多，就越不會出現推卸責任的狀況。要確保事后監督是無可責備的，并使用“五個為什么分析法”來找到運營中斷故障的根本原因。(“五個為什么分析法”，是一種提出問題的方法，用于探究造成特定問題的因果關系，類似于“碰到問題，多問幾個為什么”)
4、他們從一開始就不知道自己正在發生運營中斷故障
最糟糕的事情，是你從自己的客戶嘴里聽到發生運營中斷故障了(或者還有一種可能，就是從你的老板那里知道發生故障)。在數據中心的監控基礎架構同樣也需要被監控，這是一個不錯的方法，因為有時候發生運營中斷故障時，你根本無法得到提醒，其中一個原因就是你的監控系統并沒有及時運轉起來。即便是像亞馬遜這樣的大公司也曾遇到過這種情況，幾年前他們曾經發生過外部運營中斷故障，好在他們用了Loggly云監測軟件開發平臺才解決了相關問題。
最好的方法：你需要有一個基于“軟件即服務”的統一平臺，并且它能夠給你發出報警，提醒你是否數據中心出現故障了。你的監控平臺也需要覆蓋到方方面面(包括對各種綜合交易的復核檢查)，比如網站，應用程序，數據庫，網絡，服務器，虛擬機，以及云服務(無論你的IT基礎架構部署在什么地方)。這樣你就能領先一步，至少可以在客戶發現問題之前主動發現問題，并搞定它。
5、對于運營中斷故障，做出了不適當的溝通
Dreamhost公司曾經在他們計費系統的客戶體驗上出現了一些問題，該公司自以為是，用了一種幽默的口氣做了解釋，想以此回應問題。但是他們這種做法引起了部分客戶的強烈不滿，他們覺得Dreamhost公司用“吉普森一家”動畫片做回復，完全是不把他們當回事兒，他們應該做出正式道歉，并做出合情合理的解釋。于是，這些客戶在網上和社交媒體上瘋狂攻擊Dreamhost公司。
如何避免：
如果運營中斷故障影響到了你的客戶，讓他們無法正常辦理業務，請務必要認真對待。如果你的客戶是一家公司，并選擇你作為供應商，那么如果你出現了運營中斷且沒有合理的解釋，那么肯定會對你的服務有所懷疑。
6、沒有處理好上述五個要素中的任何一個，就無法實現有效的運營中斷溝通/致歉
“我很抱歉會發生運營中斷故障，但是我真的幫不了你。的確，我知道我們沒有給您提供任何有用的信息，向您解釋為什么會發生故障，以及為了解決這個故障我們做了些什么。我們的解決方案也沒有給您提供一個故障恢復時間，對于我們是否會計劃防止此類故障再次發生，我們也暫時無可奉告。而此次運營中斷故障給客戶的賠償應該也不會如您所愿，但是給客戶所造成的不便，我感到最深、最衷心的抱歉。我知道您需要依賴我們，作為客戶，我們也非常重視你們，我們真的非常重視這次運營中斷故障?！?/p>
永遠不要說上面這段話。這種錯誤說明了在你的客戶支持團隊以及技術運營團隊之間沒有做好溝通，至少這個溝通不夠直接和開放，或是你的道歉申明沒有經過法律和財務部門的審核。
如何避免：
如果你要給外界一個正式的道歉申明，那么前面介紹的五個要素(就是上面的五個黑體字標題)是非常重要的。如果你無法給客戶一個有效的致歉申明，那么最后付出的代價是巨大的，除了收入遭受重創，而且也會導致客戶大量流失。
7、災難恢復，最后自身變成了一個“災難”
事實上，企業在構建災難恢復解決方案的時候，也一樣會犯很多錯誤。首要問題，其實也是最常見的一個問題就是，很多企業沒有把災難恢復(DR)放在首要位置。其次就是，企業在構建災難恢復解決方案的時候，沒有把二級系統的負載考慮進去，因為二級系統故障一樣會發生，而且也會對主系統造成影響。絕大多數計算機負載并不是成線性比例的，如果有兩個站點，每個都是在一個40%負載的數據庫上運營，這并不意味著的一個網站可以在80%的負載上處理工作，很可能負載率會達到120%，也就是說，企業在進行災難恢復時，如果有一個網站失敗了，可能會導致兩個網站都無法運營。
如何避免：
在你的系統上面，要進行容量測試，這樣你才能知道網站的動態余量，以及在負載狀況下網站的運營表現。還有一個方法，就是災難恢復網站不需要把所有功能都激活，而是把它看作是一個生產網站的理想替代品。這么做可以避免在災難恢復時出現配置錯誤，除非你真的想再犯下一個錯誤……
8、不經過實踐練習，就期待完美
Chelsey “Sully” Sullenberger是一位傳奇機長，他曾經將一架美國航空的A320客機成功地降落在哈德森河上，挽救了幾百人的生命。但是在此壯舉之前，他已經有超過2萬小時的安全飛行時間，而且完成了無數次模擬緊急狀況的練習。在每次危機發生的時候，他都能提前知道該做什么。但是，許多公司卻無法做到這一點，他們的應急計劃測試不通過，或是測試結果無法滿足專業性要求。最后到問題出現的時候，他們根本就沒有做好準備。
如何避免：
要形成一個業務連續性計劃，還要經過大量測試。在測試的過程中，你會發現什么地方有問題，然后及時解決，畢竟這要比實際發生運營中斷故障要好的多。
9、責任分散
有研究顯示，當人們面對很大一群人的時候，他們很少會在緊急情況發生時采取行動，或者，他們在這種情況下很少會覺得自己也需要負一定責任。責任分散往往被用于解釋這一現象，而且在困境中的個體很少可能得到援助，特別是當有一大群人在現場的時候。本質上來說，群體中的個體們會等待一個集體決策，如果其他人沒有做決策，“我”也不會。
在發生運營中斷故障時，企業往往在責任分散上存在問題。他們沒有把解決問題的責任明確地分配到個人頭上，團隊之間還會相互指責，最后誰都不會對問題負責。如果你有太多監控解決方案，或是升級路徑不清晰，就會發生類似的狀況。
如何避免：
在制定運營中斷響應計劃的時候，就要把每個人的職責分配清楚，還要包括各種系統升級的時間進度。公司內部所有團隊必須使用同一個故障監測平臺(比如LoGICMonitor)，這樣做的目的，就是當問題發生時可以根據問題的類型，定位到正確的人頭上。公司需要有一個問題解決的升級鏈，如果某個人在預定的時間內無法得到解決某個問題，就需要把這個問題自動轉移到下一個人頭上。
10.變成了一個“處理急事的奴隸”
“我們越來越感到進退兩難，其實并不是缺少時間，而是在優先級安排上存在問題。”
– Charles E. Hummel, 《Tyranny of the Urgent》(Charles E. Hummel的《緩急之辨》、這本講時間管理的小書，原書名Tyranny of the Urgent，有人譯為「急事的奴隸」，也有譯為「燃眉的暴政」，是幫助忙碌異常的現代人，在許多緊急事情中分辨先后的實用手冊)
筆者在寫這篇文章的時候，聯系和很多快速發展的“軟件即服務”公司CEO。其中一個人告訴我的話，讓我感到十分驚訝。他說，“我對題目非常感興趣，但是我恐怕沒有時間和你一起，針對運營中斷故障問題展開討論了?！蔽覇柕?，“為什么?”他回答，“嗯…..我們現在正在發生運營中斷故障?！?/p>
他做了一個錯誤的回答。
你很容易就會變成一個“處理急事的奴隸”，把所有時間都用在救火上面。
但通常來說，這都是因為優先級安排的管理不當造成的，有些事情很重要的，但是還沒有到緊急的程度，如果經常處理應急事件也會消耗企業大量資源。實際上，你完全可以做些預防工作，做些準備和具有前瞻性的工作是明智的。
如何避免：
為了預防運營中斷故障，你可以要求團隊花一些時間，做些前瞻性的措施，你的股東和客戶將會為此而感激你。另外還要提升運營中斷事故的管理水平，這樣對你的公司員工，客戶，以及股東都有好處。做這些事情并不容易，但是非常值得。你可以先從避免一些基本錯誤開始，比如那些之前人們犯過的錯誤。
正如十九世紀德國“鐵血宰相”俾斯麥曾經說過，“傻瓜說他們從經驗中學習。而我喜歡從別人的經驗中受益?！?/p>
本文作者：@shark ?來自：快鯉魚
- 目前還沒評論，等你發揮！
