印度登月最關鍵一步！月船三號今晚進入環月軌道
8月5日消息，據印度官方消息，月船三號將于北京時間今晚21時30分左右開始近月制動進入環月軌道。這是該探測器能夠成功的最關鍵步驟之一，如果成功將開始圍
阿里云史詩級故障已經過去差不多兩周了。
使用阿里云產品的公司也難以幸免，有所波及。最近聽說了一些公司內部的故障復盤，感觸頗多。
想到一個問題，穩定性問題的本質到底是什么？
從網上的各種“空穴來風”到阿里云給出的故障復盤報告，大家基本上對這個故障原因有了一些大致的了解。
是一個鑒權服務的白名單變更，沒有做好容錯處理，導致了災難發生。
阿里云也給出了相關改進技術措施的說明。
所以，這是一個技術問題。
有的公司受到阿里云故障的波及，可能變成了一場真實的故障演練，暴露出其他額外的問題，比如容災失效、降級失效等等。
從一個故障，能定義出幾個額外的故障，并且列出若干改進措施。
變成了一系列技術問題。
但是，這一系列改進措施未來能夠避免故障發生嗎？甚至有人能保證不出現類似故障的發生嗎？
沒人敢說可以。
所以，穩定性問題好像又不是一個技術問題。
至少，不是一個用技術能夠完全解決的問題。
“發展能解決一切問題，不發展一切都是問題。”
其實，穩定性問題的本質也是“發展”的問題。
當業務高速發展的時候，誰有空關心穩定性？
業務真正高速發展的時候，大家忙著開新項目提高營收，“敏捷至上”，哪有什么穩定性問題。
甚至不需要什么設計文檔，直接CRUD一把梭上線。出了問題直接在線Debug，在線改代碼。
只要能提高營收，這些都不是問題。
公司賺大錢，員工升職加薪。
穩定性問題？無傷大雅。
當業務發展停滯了，開始“降本增效”了，高度重視穩定性。
降本怎么做？最直接有效的方式就是砍服務器資源，砍人員計劃。一個人多干兩到三個人的活。
業務發展停滯，不代表產品需求停滯。
業務發展停滯，不代表線上運行的服務、組件停滯。
業務發展停滯，不代表歷史Bug、技術債停滯。
所以，活不一定會變少，只能是一個人多干兩到三個人的活。或者美其名曰，按優先級處理，進一步提高人效。
這種情況下，必然導致故障頻發。
這個時候，故障往往又能帶來直接的“降本”，比如低績效甚至直接走人。
這種環境下，故障會進一步被“放在顯微鏡下觀察“，每個人要從中找到別人的鍋。流程問題？系統問題？可觀測性缺失？有什么漏洞都盡量甩出去。
畢竟甩鍋給別人，扣的是別人的績效，走的是別人的人，是不是根本原因或者有效的改進措施又有什么關系呢。
公司高速發展，穩定性問題不攻自破。
如果不能高速發展，應該如何解決穩定性問題？
控制合理的人員配比。
如果真的要通過縮減人員降低成本，也應該控制合理有效的業務需求，保證人員的配比是合理的。
不要試圖改變客觀規律，或者自欺欺人。
否則只會陷入惡性循環。
建設合理的機制與風氣。
不管業務是否高速發展，其實對待穩定性問題的態度應該是一致的。
除非是明確違反流程規范引起的故障，其他問題不應該跟直接獎懲掛鉤。
每次故障復盤，應該真正反思的是，能不能從架構設計、流程、機制、工具角度找到真正原因，去避免下次同類型的錯誤。
通過獎懲來高壓控制，只會帶來甩鍋風氣，掩蓋真正有效的改進措施。
對穩定性保持長期合理的投入。
避免運動式治理穩定性，只在故障發生后的一周或者一個月有重視。
隨著系統不斷迭代，整體穩定性水平一定會處于一種“熵增狀態”，逐步惡化。
所以，穩定性任務，應該持續貫穿在全年，按照合理的比重，與業務功能迭代任務一起評估考量，才能確保長期處于相對高的穩定性水平。
本文鏈接：http://www.www897cc.com/showinfo-26-34671-0.html從阿里云故障想到，穩定性問題本質是什么
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號