阿里云史詩級故障已經過去差不多兩周了。

使用阿里云產品的公司也難以幸免，有所波及。最近聽說了一些公司內部的故障復盤，感觸頗多。

想到一個問題，穩定性問題的本質到底是什么？

1、它是一個技術問題，但又好像不是

從網上的各種“空穴來風”到阿里云給出的故障復盤報告，大家基本上對這個故障原因有了一些大致的了解。

是一個鑒權服務的白名單變更，沒有做好容錯處理，導致了災難發生。

阿里云也給出了相關改進技術措施的說明。

所以，這是一個技術問題。

有的公司受到阿里云故障的波及，可能變成了一場真實的故障演練，暴露出其他額外的問題，比如容災失效、降級失效等等。

從一個故障，能定義出幾個額外的故障，并且列出若干改進措施。

變成了一系列技術問題。

但是，這一系列改進措施未來能夠避免故障發生嗎？甚至有人能保證不出現類似故障的發生嗎？

沒人敢說可以。

所以，穩定性問題好像又不是一個技術問題。

至少，不是一個用技術能夠完全解決的問題。

2、穩定性問題的本質是什么？

“發展能解決一切問題，不發展一切都是問題?！?/p>

其實，穩定性問題的本質也是“發展”的問題。

當業務高速發展的時候，誰有空關心穩定性？

業務真正高速發展的時候，大家忙著開新項目提高營收，“敏捷至上”，哪有什么穩定性問題。

甚至不需要什么設計文檔，直接CRUD一把梭上線。出了問題直接在線Debug，在線改代碼。

只要能提高營收，這些都不是問題。

公司賺大錢，員工升職加薪。

穩定性問題？無傷大雅。

當業務發展停滯了，開始“降本增效”了，高度重視穩定性。

降本怎么做？最直接有效的方式就是砍服務器資源，砍人員計劃。一個人多干兩到三個人的活。

業務發展停滯，不代表產品需求停滯。

業務發展停滯，不代表線上運行的服務、組件停滯。

業務發展停滯，不代表歷史Bug、技術債停滯。

所以，活不一定會變少，只能是一個人多干兩到三個人的活。或者美其名曰，按優先級處理，進一步提高人效。

這種情況下，必然導致故障頻發。

這個時候，故障往往又能帶來直接的“降本”，比如低績效甚至直接走人。

這種環境下，故障會進一步被“放在顯微鏡下觀察“，每個人要從中找到別人的鍋。流程問題？系統問題？可觀測性缺失？有什么漏洞都盡量甩出去。

畢竟甩鍋給別人，扣的是別人的績效，走的是別人的人，是不是根本原因或者有效的改進措施又有什么關系呢。

3、如何解決

公司高速發展，穩定性問題不攻自破。

如果不能高速發展，應該如何解決穩定性問題？

控制合理的人員配比。

如果真的要通過縮減人員降低成本，也應該控制合理有效的業務需求，保證人員的配比是合理的。

不要試圖改變客觀規律，或者自欺欺人。

否則只會陷入惡性循環。

建設合理的機制與風氣。

不管業務是否高速發展，其實對待穩定性問題的態度應該是一致的。

除非是明確違反流程規范引起的故障，其他問題不應該跟直接獎懲掛鉤。

每次故障復盤，應該真正反思的是，能不能從架構設計、流程、機制、工具角度找到真正原因，去避免下次同類型的錯誤。

通過獎懲來高壓控制，只會帶來甩鍋風氣，掩蓋真正有效的改進措施。

對穩定性保持長期合理的投入。

避免運動式治理穩定性，只在故障發生后的一周或者一個月有重視。

隨著系統不斷迭代，整體穩定性水平一定會處于一種“熵增狀態”，逐步惡化。

所以，穩定性任務，應該持續貫穿在全年，按照合理的比重，與業務功能迭代任務一起評估考量，才能確保長期處于相對高的穩定性水平。