這些年我們與通宵上線的那些事兒
突然想寫這個文章是因為最近一家公司，也是出現了類似通宵上線這樣的事情，通宵也并非是真的通宵，而是搞得比較晚上線這種，總結一下通宵上線的事兒
第一種：自動化運維能力弱
本人作業比較早，最早的時候還沒有運維自動化工具，那個時候還是比較落后的時代，需要達成jar包，然后發郵件給SCM審核，然后審批通過后發送給運維，手動傳包上線，每次上線等到半夜開始，但是每次都有各種各樣的問題，需要發布第二遍，第三遍，甚至第N遍，每次半夜給scm的同事打電話讓她起來給我們批郵件，得虧還是個妹紙脾氣好，然后給運維打電話給我們上線，經常熬通宵到第二天同事過來上班這種，甚至有時候一周兩次，
怎么解決的呢？
后面自動化能力上來了，發布上線可以用發布系統了，這種人工操作就減少了很多，效率自然得到了一定的提升，但是還是沒法解決業務的需要，因為業務要上班到12點，還是只能12點后發布，每次都把人搞那么慘，身體吃不消是一方面，不過那個時候人還年輕，大家都是這么過來的，另一方面呢，通宵完了，第二天是沒法正常好好作業的，大家都摸魚去了，團隊是一個整體，需要有持久的戰斗力，才能做好更多的作業，所以這種通宵上線的做法其實是非常錯誤的，
后面就開始做服務拆分，架構升級，將后端功能與業務功能拆分，業務功能中核心接入點等與非核心拆分，就是后面類似的微服務架構，那個時候還沒有微服務這種特別火的概念，光拆分還沒法解決通宵上線的問題，后面加上服務穩定性等需要，開始搭建多集群環境，灰度環境，上線前將用戶切流到一個集群，發布成功后切到已發布的集群，然后再發布另一個集群這種形式，再加上自動化運維能力的提升，基本解決了大部分通宵上線的問題（注意是大部分），因為不是所有的業務都是單純的web請求，所以不是說ng自動切就能解決的問題，這里不過多聊，
第二種：敏捷沒有做好
中間第三家公司，過去也是出現需要因為上線搞得很晚的情況，后面發現是因為應公司要求，必須兩周一個迭代上線完成，兩周時間，需要跟產品聊需求、做設計、寫代碼、聯調、測驗，跟臺北那邊異地溝通，最后算下來只有3天左右的時間開發加測驗，這種顯然是有問題的模式，3天完成開發自測，然后后面就是各種介面有問題改改改，這兒調整改改改，，，
解決
因為2周一個迭代，暫時肯定沒法改變，只能改變敏捷的程序，后面拉齊臺北，測驗等，找出矛盾點，問題點，其實也并不是只有三天，因為他們想早點要到介面方便臺北那邊寫代碼聯調，所以最后溝通就是，需求確定后一天內給出所有的介面資訊，然后給出mock介面供使用，最后我們有了6天的開發時間和自測時間，質量得到了保證，上線也順利了很多，從此也是基本脫離了很晚上線
第三種：業務與第一種類似
第四家公司業務與第一家類似，也是即時通訊相關，上線就比較麻煩，因為待狀態，但是老大比較開發，允許晚上回家之后發布，遠程溝通發布，但是要等到業務方沒有使用了再開始，基本還是很晚，有時候1、2點，到這家公司之后，定了個目標，解決通宵上線的問題，因為公司也不大，想著繼續沿用之前的模式，多集群來做，系統重構了一遍，該抽離的抽離，服務分層，分級都做了，準備開始做集群的時候呢，老大自己研究k8s，然后弄了一套特別方便的自動化上線工具，k8s用過的都應該清楚，服務發布好了以后再下線，整體還是非常友好的，然后有了這套基礎架構以后呢，也沒有去研究集群模式了，基本能夠滿足80~90%的發布是不用等到晚上12點以后了，后面通過普羅米修斯接入業務監控，監控業務指標，發現我們的業務在早上11~12，下午3~6點都是業務低峰，比晚上10，11點上線甚至影響更小，然后就非重大變更開始光明正大的上午跟下午發布上線，當然也有出現過問題的時候，敏捷迭代快步小跑的模式，肯定會出現發布上的問題，這個問題在最后環節來說，
不需要通宵上線的
第二段作業去了阿里，在阿里呢，就沒有通宵上線這樣一個概念，因為基礎運維能力，基礎架構能力，服務治理能力，服務上下線能力都非常好了，基本上是想上線隨時可以上線，所以沒有這種煩惱，但是在這兒呢，學會了怎么去上線，
重點來了
怎么上線，這個其實是決策問題，當然通常發布的checklist、發布順序、發布后需要回歸的功能等等基本的東西要備好，減少上執行緒序中出現問題，
這都不是重點是出了問題怎么搞？
其實可以任務整個發布到你發已經算是成功了，那驗證有問題怎么辦？或者說中間發布出問題了，這個時候應該來當成一個線上故障來看這個問題了，這樣就很明確了，通常情況是什么呢，驗證有問題了，A，B，C，D，測驗，開發全部都盯著這個問題開始找，找問題來解決呀，開發有時候甚至是這次上線的負責人，都盯著這個問題來看怎么解決，如果我們把這個當成一個線上故障的邏輯，來做處理呢？而且這個問題比線上故障要好處理的多，因為你已經知道是什么問題造成的了，
當成線上問題處理：
第一件事情，負責人界定影響范圍？留一個這塊熟悉的或者這塊誰負責的人來排差問題，測驗繼續測驗剩下的，
第二，是否是阻斷性的？如果影響范圍很大，還是阻斷性的，不用考慮，直接回滾就完了，
非阻斷性的，少部分人影響，可以讓人來查這個問題，測驗繼續測，可能還會出現其他問題，
整體都測驗完成或者中間阻斷了回滾的問題之后，定位問題，如果短時間內能夠找到問題，問題修復比較簡單，可以進行修復，如果改動多，就可以停下來了，考慮是否終止今天的上線？這些都是決策問題了，
很多研發甚至是決策人都比較軸，呃，有問題了，我要找出來修好，要多思考，這個問題是不是一定要修，影響程度不大，不一定能觸發的，可以先放著，后面打個補丁修復即可，（此處是說明這是晚上上線，很多時候晚上找問題都非常費時間，費精力，加班太晚了頭腦也會不清醒，改一個問題可能引起其他問題，無情無盡...）
寫到最后：如果你發現你現在的作業還在很晚上線，應該來說是一個基礎架構比較薄弱，自動化運維比較薄弱的公司，決策者比較薄弱的管理，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/350279.html
標籤：其他