昨天有道云筆記的服務當機，官網以及服務都不能使用，我幸災樂禍的發了一個朋友圈，強調了一下容災的必要性，還調侃性的說不要省那點備份和容災的錢，其實公司容災和備份方案都是我定的，老板哪知道該做些什么才能讓產品穩定。
最近我們一直在切換服務器，在切換負載均衡，在切換域名以及存儲，最后也就是在今天，我把發布腳本也切換了。發布內容出錯導致了公司服務短時無法使用(10分鐘內，我的感覺是斷了這么久)，斷當時還是有點慌的，還要決策是恢復還是繼續發布，后來相信自己的腳本，還是繼續找報錯，修了下去，還好結果還可以，影響不是很大。
起因
之前服務比較少，采用的是單機發布，也就是先登錄到服務器，再執行部署腳本進行發布，有多少服務就要登錄多少機器，一是慢，一是怕執行錯順序，好處就是心里不慌，掛掉就掛掉，有負載均衡撐著呢
這次服遷移，我們把原來的單服務進行了切分，要維護的服務器更多，服務也更多，所以也就打起了發布全自動化的主意。
過程
其實之前寫的腳本主流程還是可以用的，只是缺少很多檢測，比如tomcat殺不掉怎么辦，啟動后有沒有啟動起來，添加了相關的檢測后，我找了個我負責的另一個產品上做測試，經過一下午的時間總算是可以完美運行了。
今天就開始搞主服務，照著昨天的腳本改，為服務器做定制，寫好后，認認真真檢查了半個多小時。覺得沒問題后發布，一點，刷刷的日志滾滾而來，看到了報錯，可惜無法中止，等都執行結束，產品就不能訪問了。
這時心里還是有些慌的，回滾？還是繼續發？經過一番思想斗爭，決定還是繼續發下去，回滾也不是那么容易的，也要很多步驟的。這時客服就開始叫了，然后是公司其他部門的，產品經理就開始找我，群里各種消息接踵而至。沒辦法，我也急呀，拉到個產品經理，讓他替我回復。我就靜下心找到錯誤，修正，多機執行，經過一番折騰總算是恢復了。
總結
1. 經過這次事故，我覺得最好的方案是將發布由一次變為兩次甚至更多次，將服務器劃分為一些子網，每次都是先在一個子網中進行發布，無問題后再再其他子網中發布，如果出現問題，就將子網切斷隔離，進行修復。
2. 腳本也應該具有遇錯自動回滾功能，不過實際情況下報錯種類很多，也有一些是無害的，這種只能解決一小部分問題。
3. 能備份還是多備份吧
4. 腳本還是要多進行實際測試，別太自信，現在年紀大了，眼睛跟不上了，只能在思路上提意見。本以為是復制好的腳本，只改一些參數不會有問題，改好后，還認真看了半個小時都沒看出錯誤
5. 這種事情最好不要讓負責人去做，如果我當時交給運維同學去做，我去檢查，可能也不會出現腳本錯誤。負責人會有時會逾越一些必要流程以及些許的盲目自信。
