在6 月5 號,唯品會發布了23 年3 月29 號的故障報告,因為南沙IDC 冷凍系統故障導致唯品會線上商城停止服務,造成了數以億計的損失(作為小運維的我,瑟瑟發抖)。
對於唯品會來說,線上商城是其核心業務入口,故障不可避免,但是故障如此之長卻不能容忍,為什麼會造成這種事情發生呢?在我們這種小運維的眼裡,這種事故不應該發生在這種量級的公司中,我們都是在模仿、學習他們的 PPT 中尋找運維之路。
但是,PPT 的高大上,無法壓住故障不發生,這是為什麼呢?
我個人鬥膽說幾個猜測:
現在國內各種技術大會,然後邀請一些知名企業的CTO、技術負責人等到場演講,從演講來看,每家公司都很強(至少PPT 上是這樣展示的),每次我聽完都會豁然開朗,大受裨益,打心底佩服這些公司,佩服他們超強的思維、超高的能力以及超酷的團隊。
但是,PPT 畢竟只是一個輔助工具,它不能取代現狀。
漂亮的 PPT 只是給想看的人看的,不漂亮的事情是要獨自去承受的。
之前有看多唯品會在GOPS 上的分享,PPT 上呈現的確實很棒,如果拿著這個向上匯報,老闆也會覺得我們公司的技術真厲害,做的真好,給了老闆一切都很好的假象。
出了問題,不辦你辦誰?
從自己嘴裡吹出去的牛逼,也會回到自己嘴裡。
在《SRE:Google 維運解密》這本書中,故障演練佔了很大的篇幅。透過故障演練,可以提高系統的可靠性和容錯性,可以讓團隊更好的了解系統的架構和工作原理,可以更好的理解各模組的相互影響,可以更快的發現系統架構中的漏洞和故障。
可以說,故障演練是整個穩定性保障的核心環節,因為它可以幫助團隊最大限度的減少實際故障的同時,也能更有效率的應對可能出現的問題。
但是,實際上是這樣的麼?
在實際進行故障演練的時候,要預定故障點,要整理輸出具體的應對措施,要指定全面的計劃,要準確描述每個人的工作職責和任務。
光這些前置工作就需要耗費很大的人力物力,很多團隊、很多人就會精簡步驟、精簡措施,抱著做了就行的心態看待故障演練,抱著僥倖心態看待故障本身,把希望寄託在別人不出問題的情況下。
例如把希望寄託於公有云,公有云不出問題,整個系統就是穩定的,但是公有云≠ 完全可靠,谷歌雲、阿里雲、騰訊雲等都發生過重大事故,然而買單的還是使用者自己。
所以,對於維運團隊或SRE 團隊,需要認真對待故障演練,不僅要做好演練的前置準備工作,在演練中也要密切關注計劃,發現問題及時採取措施並進行修正。
不要讓演練成為走過場,不要讓演練成為 KPI,不然你就是下一個最佳化物件。
3 月 29 日唯品會的問題,可以從側面反映:多活,也許真是說說而已。
隨著業務的發展,系統架構會不斷演變,因為我們對高可用的要求越來越高。
例如,從單機架構在同一機房升級到主備架構,再升級到同城多機房架構,最後到達兩地三中心架構等級。
如果唯品會做了同城多機房,就算最簡單的同城主備,也不至於宕機 12 小時。
更別說如果做了同城雙活。
但是,我只是站在上帝視角猜測。也許他們也做了多活,只是假多活罷了。
上面總總,到頭來都會走到財力、人力、物力上來,就拿多活來說,搞一個同城災備,投入的成本就不是dubbo 那麼簡單,每當SRE 負責人向上報告申請資金的時候,如果上面的領導不予支持(錢,錢沒掙,還要花這麼多),什麼都是白搭。
領導要壓成本,下面要錢做事,成本不足導致入不敷出,也就會出現 PPT 漂亮,實際很爛的局面。
縱有一腔抱負,乃無用武之地。
出了問題,還要用你祭天。
上面所說純屬虛構,如有雷同,請按讚~
在許多公司,維運的話語權很低,低到離譜,這就導致維運在做事或推進事情的時候寸步難行。
但是,一旦出現問題,維運卻是被第一個推出來的,所以「背鍋俠」一直被扣在維運頭上。
那當作運維該怎麼做呢?
最後,說歸說,鬧歸鬧,別拿生產開玩笑。
以上是流水的運維,鐵打的鍋的詳細內容。更多資訊請關注PHP中文網其他相關文章!