說到軟體變更審核可能很多大型軟體公司或科技公司都有一套防止軟體上線後之問題的上線之前嚴密的＂軟體變更審核程序＂，這樣做的目的在於防止上線時或上線後軟體服務出錯而導致故障，是一種事前把關的重要動作，聽起來似乎沒什麼不對，但是在以市場為導向(因應市場快速變化，軟體變更速度也加快)的時代，這樣做卻是有問題的。
之所以這樣做會有問題，是因為大家都忽略了一個事實：＂遠離工作現場愈遠的決策者，對問題真正了解的程度也愈遠，只有現場工作者才是最了解問題的人！＂別小看這個事實，正是因為它，讓審查軟體變更這件事成了萬惡的罪身。
回想一下實際情景：通常我們在軟體上線前會由誰審核變更？當然是軟體專案經理、軟體架構師、部門經理之類的，但假設軟體變更出了嚴重錯誤，這時候可能的合理做法大概就是加入更多更高層級的人來審核未來的變更請求，於是可能更高層的CTO技術長甚至是執行副總裁之類的超高層級也加入審核行列，這樣軟體變更應該更安全了對吧？
不！事實恰恰相反！加入更多人審核只是意味著審核程序變得更加複雜，上線的前置時間也因為要等層層審核而愈拖愈長，更糟糕的是這樣不但沒讓軟體變更品質增加，反而會發生的問題還是會發生，變成只是讓上線變更這件事完全沒有效率而已。
為什麼是這樣呢？因為當你把審核工作交給離工作現場愈遠的高層決定，審核的問題愈大！因為他們不會知道每一批專案中軟體變更的細節，身上所扛的事以及要決定的事又多如牛毛，即使他們花盡量最多的時間在你的軟體變更審核案件上，也不可能了解整個軟體或是真正的部署問題在哪裡！
而唯一最了解問題的開發及營運工程師，反而沒有權利決定上線變更的細節，這想想豈不荒缪，嗚呼哀哉！所以，簡單的說，軟體變更審核這件事其實是反邏輯思維的，只是直覺上我們覺得這樣做應該是正確的而已。
不管如何，不要再把軟體變更審核的控制權交給不能夠了解現場狀況的人了！還記得布魯斯威利演的世界末日嗎？當大伙在太空中為是不是該直接在隕石表面引爆核彈爭吵不休時，男主角布魯斯威利最後說了一句話：＂為什麼你要聽命離我們遠在數千公里外的地球上的人的命令？＂他當下的意思就是為何要聽不在現場的人的命令？他們不可能比我們了解狀況！
這正是軟體變更審核真正的問題所在，多一個不在現場的人做決定，核彈就更接近被引爆的時刻！
因為覺得這件事有趣而且重要，所以我決定要記下來，至於不做軟體審核變更那就這樣直接上線嗎？
其實這邊我就不多談了，因為DevOps強調要快速迭代，交付軟體價值，所以快速持續的整合與部署成了DevOps的常態，但一切要透過完整的CI/CD與自動化測試流程，同時Follow小規模變更部屬原則，持續的實行Chaos軟體反脆弱測試，並全面化遙測監控軟體服務狀態的指標，在軟體變更過程中加入＂同儕評閱＂的程序（例如軟體程式碼的Pull Request, PR），把審核責任放回最接近工作現場的工程師手上。
簡言之，就是自動化加拿回軟體變更審核權，並且加強從故障中快速修復軟體服務的能力！徹底取代不合時宜的軟體變更審核流程。
2019年11月11日星期一
留言列表
