早晨在瀏覽 36kr 看到一條資訊：
最近的互聯(lián)網(wǎng)故障太多了，先有10月23日語雀7小時宕機故障，后有11月27日滴滴十余小時宕機故障，接下來騰訊視頻也不甘示弱。 互聯(lián)網(wǎng)產(chǎn)品出現(xiàn)故障屢見不鮮，印象最深刻的是支付寶527事件（2015年5月27日，支付寶宕機），那次之后，每年的5月27日都會搞很多攻防演練檢驗系統(tǒng)的穩(wěn)定性。 為啥各種演練還是避免不了故障呢？ 除了流量激增，咱來看互聯(lián)網(wǎng)宕機常見問題主要有三個：①系統(tǒng)問題，②云產(chǎn)品問題，③網(wǎng)絡(luò)異常。 那這些問題是否能提前預(yù)防呢？技術(shù)經(jīng)常提到的「變更三板斧」，針對任何變更，包括系統(tǒng)發(fā)布、改配置、修數(shù)據(jù)等各種形式的變更，都應(yīng)該遵循這個原則。 這三板斧是：可監(jiān)控、可灰度、可回滾（用于應(yīng)急）。 首先是可監(jiān)控。 有任何變更，相關(guān)人員需提前部署好版本的監(jiān)控和報警策略，目的是及時發(fā)現(xiàn)問題，比如應(yīng)用監(jiān)控（響應(yīng)時間、成功率和錯誤率等）、網(wǎng)絡(luò)監(jiān)控（帶寬異常、丟包率等）、日志監(jiān)控（應(yīng)用日志、系統(tǒng)日志等）、安全監(jiān)控（掃描漏洞、惡意攻擊等）…… 然后是可灰度。 灰度能力是互聯(lián)網(wǎng)產(chǎn)品必備技能，比如支付寶抖音這種過億體量的 C 端產(chǎn)品，發(fā)布一個新功能后一定是先讓員工體驗體驗，提早發(fā)現(xiàn) Bug。這還不夠，正式對外的時候還得按照百分比逐步放量。如果苗頭不對，得立即想辦法回滾，否則就是史詩級災(zāi)難。 對于體量小的產(chǎn)品，一般不會這么復(fù)雜，甚至對于一些 B 端產(chǎn)品，可能就幾個客戶，直接就發(fā)了，完全沒有業(yè)務(wù)灰度的必要。但是，請注意，即使沒有業(yè)務(wù)灰度的必要，在執(zhí)行變更的時候，在機器層面，也應(yīng)當(dāng)遵循灰度的原則逐步生效，這樣可以早點發(fā)現(xiàn)變更問題，而不至于讓整個機器集群瞬間癱瘓。 灰度直至全量放開結(jié)束如果未發(fā)現(xiàn)問題，不代表一定不會出現(xiàn)問題，可能到達某個臨界點因為產(chǎn)品邏輯問題才會觸發(fā)。這時候應(yīng)該配合 可回滾 ： 這里需要判斷，是否比較明確判斷和變更相關(guān)，若相關(guān)，就應(yīng)該無腦回滾，先止血再說；若不能通過直接回滾修復(fù)故障，那就需要備用方案。我了解到語雀利用的是： ①先備份差異數(shù)據(jù)：防止數(shù)據(jù)丟失或損壞而進行的復(fù)制； ②后一致性校驗：當(dāng)我們在多副本或分布式系統(tǒng)中存儲數(shù)據(jù)時，為了確保所有副本中的數(shù)據(jù)都是一致的，需要進行一致性校驗。 核心是保證數(shù)據(jù)的完整性和可靠性。 在執(zhí)行上線操作時，團隊所有成員都應(yīng)該慎之又慎，大膽小心…… 上次聽說一互聯(lián)網(wǎng)公司裁員，首先裁掉了部分運維，愚蠢，真是愚蠢，緊接著好像就出問題了……
檢查作業(yè)，《創(chuàng)造：用非傳統(tǒng)方式做有價值的事》這本書看了多少了？
記得再看點贊轉(zhuǎn)發(fā)喲。感謝。
產(chǎn)品經(jīng)理基本功提升可以看這兩個專輯：
產(chǎn)品經(jīng)理工作流（點擊可以訪問）
產(chǎn)品方法論和思考（點擊可以訪問）
