背景
在《程序媛的人生觀》這篇文章中，一些朋友提出了自己的疑問：“看起來靜兒的發版上線很不規范，為什么一個大公司會允許這樣的事情呢？”這是個很好的問題，值得我好好總結分享一下。
在考慮上線標准之前，先考慮這么一個問題，你處於哪個通道？
通道
前端通道、系統通道和后台通道的發版上線流程差別會很大。
前端通道：用戶體驗、視覺效果會占很大比重，一般來說需要依賴專業人員進行人工測試。
系統通道：產品流程的理解和把控是其中的一個關鍵點。自動化測試基礎上還需要人工測試進一步驗證。
后台通道：也是靜兒所在的通道。業界有一個比較流行的理念：“開發人員應該測試自己的代碼。”
我們團隊中經常在說的一句話叫：“你不可能既當運動員又當裁判。”那怎么來解決這個沖突呢？
自動化測試。基礎架構這邊有專門的QA。他們大部分時間都在收集測試用例，開發自動化測試工具。
開發人員需要自己寫單體測試，單體測試是在設計階段，對功能進行建模階段就寫好的。所以對一個后台開發來說，完全可以在幾分鍾之內完成一套完整的上線前驗收。
能否在幾分鍾之內就可以進行一套完整的上線前驗收也和公司、部門或者團隊的策略有關系。
策略
不知道有的朋友有沒有注意到這個問題：有的公司雖然是大公司，但是門檻並不高。面試的時候着重考察面試者的理解力、溝通能力。如果背景不錯，不會太卡技術這一塊。當然，一般來講這種公司給的待遇也比較一般。
這並不是說這個公司不夠好，相反，正是因為公司有非常完善的流程把控，所以才擺脫了對成員個人能力的重度依賴。然而，一般來講，流程是用來保證底線的。一個注重成員成長的團隊希望的是能夠激發成員的上限。
所以靜兒所在的團隊有這么一種策略：如果成員對自己的流程把握足夠好，不出問題，上級會逐漸放寬對成員的監督。如果把控的不好，就會天天被盯流程。
這樣的好處：做的好的成員的創造性可以充分得到發揮。對於上級自身，也可以抽身出來cover更大的事情。
在《程序媛的人生觀》這篇文章中，靜兒用了一個很不專業的詞：「臨時決定」。從另一個角度來看這個問題，什么事情是可以臨時決定的？
定性
靜兒之所以可以臨時決定給序列化和反序列化接口新添加一個實現。這里面包含了兩點信息：
1.這是添加實現，最最壞的情況下，實現出問題了，是可以開關切換切換回原來的實現的。
2.這不改變完成的功能，就是說這是一個重構。
在開發的時候「忍不住覺得之前的代碼寫的太爛了需要重構」是一個工程師的基本素養。如果回過頭看覺得原來的代碼寫的不錯，這是一個信號：同學，你該看書學習了。
所以，對於新功能，靜兒團隊中是需要開會一起做DEMO驗收演示的。但是對於重構，開發人員完全有權利自己決定何時重構。因為功能不變，之前已有的自動化測試流程無需任何更改，完全可以覆蓋重構后的場景。
背后的技術支撐
「技術強就是任性。」這句話不錯的，但是技術強不是指靜兒個人的技術能力。而是我司的整套基礎設施。這里就不談我們強大的DevOps這些東西。我們就說《程序媛的人生觀》這篇文章中，靜兒提到終於用了整個晚上，到凌晨5點完成上線，靜兒最后把線上到哪里了呢？
上到了線下環境。這里線下環境是什么概念呢。靜兒所在的團隊負責的是容器的生命周期管理。容器有給廣大用戶直接訪問的線上環境。還有一個環境，業務部門是我們的用戶，他們用來測試、開發的容器，對我們來說是正式環境。如果線下環境出了問題，會影響我們的用戶滿意度。
一般來說，我們的代碼想上到線上環境，至少要經常兩天的線下環境觀察。這個觀察是什么意思呢？
發版前寫好發版checklist，在一定范圍內周知說我要發版了，如果有問題請及時聯系我。
然后采用灰度發布，每發版一組機器就要進行整個流程的檢驗，如果有問題最快的解決方法是將有問題的機器禁用。每組發版之間有強制的時間間隔，在間隔內不能發版下一組。
發布完成后QA那邊的自動化工具又一次起了作用，它會自動模擬用戶完成所有分支的操作。然后給出報告。
各方面都OK之后，周知說發版完成符合預期。第二天一大早起來業務巡查，看看是否一切正常。
一天的午高峰和晚高峰監控數據是一定要看的。CAT、OCTO、業務大盤、監控大盤……
最重要的是及時看看是否有業務反饋問題。這都是在線下環境做的。
《程序媛的人生觀》這篇文章中提到的那次發版，由於質量好。上周四發版線下，上到線上環境是這周一晚上9點后開始操作。
從「技術好就是任性」這個再延伸一下，為什么《程序媛的人生觀》這篇文章中看起來編碼很隨意？這是因為設計架構做的好。臨時決定給序列化和反序列化接口新添加一個實現。實現加在哪里了呢？每個產品至少有兩個服務組成：核心服務和非核心服務。我們的MQ都是用來數據預處理用的，都是在非核心鏈路上。出問題了，半夜臨時掛一下，就算有和靜兒一樣的程序員在半夜擴容測試機器。服務產生的最壞影響是數據反應有延遲😀
總結
昂貴的工具不一定能制作出更好的設計。--《程序員修煉之道》
相關閱讀