你好呀，我是歪歪。
昨天分享了一下《騰訊雲 4 月 8 日故障覆盤及情況說明》，較為詳細的描述了故障前後的具體情況。
按照慣例，這種大公司的故障說明，歪師傅都是要好好看一下的。
一來是看看有沒有可以學習的地方，多從別人的事故中總結經驗教訓，學習避坑指南。
二來還可以蹭個熱點。
表揚
首先，先說說我個人認為值得表揚的地方。
第一點是文中把“雲服務類比為酒店”這個比喻我覺得是真不錯。
先是刨去所有的細枝末節，把雲服務大概分為資料面和控制面，這兩大坨。
然後用比較正式的語言描述了資料面和控制面分別是啥：資料面承載客戶自身的業務，控制面負責操作雲上不同產品。
接著用了一個實際的例子，比如 IaaS（Infrastructure as a Service），即基礎設施服務，基本上都是以直接面向資料面為主，控制面僅在客戶購買或需要對資源層面進行調整操作時會涉及。
此次發生故障的控制檯和雲 API 是對控制面的影響。
這段話是相對比較技術性的，如果讓歪師傅用通俗的話來說就是：你買了騰訊雲的伺服器，馬上就要到期了，但是你在伺服器上部署了一個應用，還想繼續用，所以你想著去續費。
騰訊雲故障的時候，你伺服器上的應用是沒有問題的，但是如果你想續費，你得登入到騰訊雲管理臺，去充值。
由於故障期間管理臺完全登入不了，所以對應的功能就用不了，因此這個時候是充值不了的。
除了續費外，控制檯其實還能看很多的基礎資料，服務執行情況等等，是一個資訊收集門戶，還是比較重要的。
但是上面這些話，不管是騰訊雲的官方公告還是歪師傅舉的續費的例子，對於非技術人員，理解起來可能都有一點點門檻。
然後騰訊雲在公告裡面舉了一個例子：
通俗來講，如果把雲服務類比為酒店，控制檯相當於酒店的前臺，是一個統一的服務入口。一旦酒店前臺發生故障，會導致入住、續住等管理能力不可用，但已入住的客房不受影響。
...
但是，用API提供的服務類產品（需要“酒店前臺服務“）有不同程度的影響...
非常形象的比喻，一下就讓那一部分可能一點都不懂技術的騰訊雲客戶找到了一個容易理解的抓手。
公告中這個比喻，我覺得很好。
第二個我認為值得表揚的點，就是這篇故障公告。
看得出來騰訊的這份事故報告寫的還是有誠意的，較為詳細的覆盤了當時的情況。
我個人淺顯的認為，其實它完全可以不用對公眾釋出這樣一篇事故情況詳細說明，可以只是對事故情況進行簡單的描述，表達自己的歉意，然後做好客服培訓，做好使用者解釋工作，啟動相關賠償流程就可以了。
詳細說明，可以關起門來，仔細分析。
但是它發了，而且是在事情的熱度已經算是過去了的情況下，釋出的內容比較詳細，一定程度上做的了對使用者透明，在認錯態度上，這一點是值得肯定的。
第三個點是我確實領到了 100 元無框門代金券的賠償，也在不經意間帶領一些小夥伴薅到了這 100 元的賠償，相關情況在這篇文章裡面說過了，就不多說了：《騰訊雲，你怎麼回事？》
100 塊錢確實不多，對於企業使用者肯定是走另外一套賠償流程，但是對於只是受到輕微影響的個人使用者來說，總比沒有好。
對於完全沒有受到影響，純薅了 100 元羊毛的使用者來說，你就偷著樂就完事了。
我要說的表揚的點，大概就這三個了。畢竟是一次事故，也不能老是找表揚的角度，還是要找找可以改進的地方。
學習到的地方
表揚一般對應著批評。
但是歪師傅是個什麼玩意，憑什麼資格去批評騰訊雲？
不夠資格，所以我只是站在個人的角度，看看在這次事件中，我可以學習到的東西。
首先第一個還是“公告”，但是這個公告不是指前面提到的覆盤公告，而是在事故當天，騰訊雲官方微博釋出的這些公告：
在言語中是有“抖機靈”的傾向的，說老實的，我第一眼看到這些描述的時候沒有覺得任何問題，因為我已經得到了我想要的資訊。
但是看網友討論的時候，就相當一部分人在批評官方的“抖機靈”行為，看起來不是特別的正式，甚至有人說“讀出了一絲吊兒郎當的感覺”。
如果一個公司、一個企業的老闆，因為使用你們的產品，由於你們本次的故障，給公司、企業帶來了麻煩，甚至是巨大的損失，當他們看到你不正式的言語的時候，內心並不會覺得幽默。
我想騰訊雲微博的小編在對待整個事件，釋出相關描述的時候一定也是非常認真的，只是用了一種自己覺得無傷大雅的方式。
但是借用一句網路名言：被誤解是表達者的宿命。
話說出去，人們總是能找到各種解讀的角度的。
所以在這種較為正式嚴肅的場景下，用官方的書面用語來進行事實的描述，雖然少了一份“活潑”，但是至少不會弄巧成拙。
這是我學習到的一個點。這一個點和“技術”毫無關係，但是站在更長遠的視野中，比起技術，這個點的靈活運用可能更為重要。
寫這篇文章的時候我本來想去看看對應微博下的評論的，但是發現已經被刪除了，不知道背後有沒有什麼故事。
除了上面這個非技術的點外，當然也學到了一些技術方面的點。
整個故障覆盤及情況說明，其實總結起來還是這九個字：
可監控！可灰度！可回滾！
比如文中出現的這些監控相關的圖片：
基於這些監控的圖片，官方可以得出如下結論：
其他以非雲 API 方式提供服務的 PaaS 和 SaaS 服務，處於正常服務的狀態。 用 API 提供的服務類產品（需要“酒店前臺服務“）有不同程度的影響，比如騰訊雲端儲存服務呼叫當天有明顯下滑。
關於“可灰度”，文章中有這樣一句話，就直接提到了：
故障的原因是雲 API 服務新版本向前相容性考慮不夠和配置資料灰度機制不足的問題。
在改進措施部分，也是直接提到了“實施灰度釋出策略”：
這兩個點結合起來，我理解就是有故障的這次釋出沒有按照灰度釋出進行實施。
這一點確實是非常不應該的。
“可灰度”，在歪師傅公司是非常重要的一個指標，每次投產之前，有一個專門的檢查項就是“是否可灰度”。
灰度期間可以用小波流量驗證投產是否成功。如果沒有灰度，直接流量全部放進來，程式又有問題，到時候哭都來不及。
如果不可灰度，需要寫清楚不可灰度的原因，並且需要開專家評審會議，由專家再次討論，確定是不是由於某些實際情況，本次應用的釋出真的不可以灰度。
我也真的遇到過這樣的“不可灰度”的釋出，當時我是在關鍵邏輯處做了一個開關，在全面釋出完成之前開關關閉，保持原邏輯。在全面釋出之後，再把開關開啟，先用內部流量來驗證了本次投產是否成功。
結果真的有問題，本次投產失敗，但是由於開關的存在，我立馬把開關關閉了。
雖然投產失敗了，但是沒有引起大規模的問題，已經是不幸中的萬幸了。
而這次投產，我拉著開發和測試同學前後一共分析了三次投產方案，投之前我還是非常自信的。
百密一疏，最後還是失敗了。
但是投產失敗帶來的影響並不大，因為“可灰度”這三個字救了我，它讓我反覆去論證了投產方案，並進一步的考慮到了如果失敗時的應對措施。
另外，再歪個樓。
關於“新版本向前相容性考慮不夠”描述中的“向前相容性”，有一個朋友指出了描述不對：
實際情況也確實是“向後相容不足”，這一點算是公告中的一個小錯誤吧。
至於“可回滾”，也是本次事件中的一個大漏洞。
因為回滾版本之後，服務並沒有完全恢復，出現了意料之外的情況，說明實際情況並不滿足“可回滾”：
公告中還有這樣的描述：
“按照標準回滾方案”，我覺得其實就是選擇上一個版本重新發布，因為這個動作放在任何一家公司，都是標準的回滾方案。
其實，除了標準的回滾方案之外，還應該有一個“本次投產的回滾方案”，方案中應該要包含本次服務回滾之後對於業務的影響和對於上下游服務的影響。以便真的出現問題的時候，作為後續執行方案決策的一個重要考慮部分。
比如，如果在投產之前，分析出了本次投產可能會影響到控制檯，然後在分析“本次投產的回滾方案”時，理論上是能分析出可能會發生迴圈依賴的。
不要給我說你也不知道本次投產可能會影響到控制檯，你做為一個開發人員，服務投產會影響到什麼業務，應該是門清的，只是你可能沒有時間去仔細分析。
如果分析出了“可能會發生迴圈依賴”，那麼肯定就會進一步寫解決方案：如果發生了迴圈依賴，導致服務無法自動拉起。需要透過運維手工啟動方式使 API 服務重啟。
這樣，騰訊雲就能減少 48 分鐘的故障時間：
整體故障時間就是 39 分鐘，還能保住 4 個 9 的高可靠性。
反正我是建議所有開發，運維，包括測試同學，都應該把“可監控，可灰度，可回滾”這九個字貼在工位上，刻在腦子裡，做方案、寫程式碼、提測前、上線前都把這九個字拿出來咂摸一下。
這九個字，說起來簡單，但是落地是真的難。
雖然落地難，但是是真的可以保命的，至少保過我的命。
最後，還有一個點。
在重要的業務條線中、直接對客的核心業務中、基礎能力服務中、關乎到公司名譽的業務中，等等相關業務中，涉及到呼叫外部介面，或者強依賴外部服務的地方，都應該要考慮到外部服務不可用的情況。
我知道這很難，就像是要你考慮 MySQL 徹底崩盤之後，你的服務應該怎麼辦一樣的難。
但是怎麼解決，能不能解決，花多大力氣才能解決，這些問題都不重要，重要的是你要考慮到這個問題，並最好丟擲問題，列出解決方案，讓能決策的人進行決策，然後留痕，記錄在案。
以防在真的出現問題的時候，遇到領導丟擲這樣的問題：當時為什麼不考慮？不說？不給我說？
防止來自領導的致命追問是一方面，還有一個方面是其實大多數時候真的是有解決方案的。
還是拿騰訊雲這次事件，舉個最簡單的例子。
我看公告中提到了這樣一句話：
比如最後一個“驗證碼”，什麼是驗證碼？
我在騰訊雲查詢了一下：
說白了，其實就是我們經常看到的這個玩意：
一般來說我們在使用者登入註冊的時候會用到，可以有效防止撞庫攻擊、阻止序號產生器批次註冊小號。
現在你想象一個場景，你在登入某 APP 的時候要獲取簡訊驗證碼，正常流程是在獲取之前彈了個框，讓你“拖動下方滑塊完成拼圖”。
結果這個“拼圖”完成不了，你就獲取不了驗證碼，從而導致你不能登入這個 APP。
正常來說，你就是罵一句：什麼垃圾玩意。
然後就不登入了。
但是，如果這個 APP 是一個理財相關的 APP 呢？
站在使用者角度：我靠，我本來是要來取點錢出來的，怎麼登入不了了？不會是捐款跑路了吧？
你說使用者慌不慌，他根本不知道是因為騰訊雲故障導致的，他只是慌。
一慌就要打客服電話核實情況，結果客服功能也使用的是騰訊雲，假設也受到了影響。
使用者發現客服電話也打不通，心裡一緊：臥槽，真跑路了？
你說巧不巧，這個人剛好在一個群裡面，這個群裡面全是買了這個理財產品的使用者，平時在群裡吹水聊天，交流韭菜心得。
於是他在群裡喊一了聲：理財 APP 你們趕緊看看是不是登入不上了，取不了錢了，是不是跑路了啊？
這樣的輿情一旦開始發酵，輕則上面請公司負責人去喝茶，重則發生大規模擠兌事件，公司不一定扛得住。
而這一切，都是因為你核心業務的核心鏈路上依賴的核心服務出故障了。
怎麼辦？
很簡單嘛，要麼降級，根據實際業務場景，直接先跳過這個步驟，比如在這個火燒眉毛的時候了，獲取驗證碼就別彈窗了，直接放開就完事。
或者備份嘛，多對接幾個渠道，國內這麼多雲，再對接幾個雲的驗證碼服務，搞個熱備、冷備、負載均衡啥的，這種按照呼叫量收費的，應急場景下也花不了幾個錢。
我使用的圖床工具叫做 PicGo，就連這小小的圖床工具都提供了這麼多接入方式：
你的核心業務還不值得花點錢多做點冗餘嗎？
再說了，退一萬步說：
花的也不是你的錢。出了事兒，扣的可是你的錢。
你自己好好咂摸咂摸。