文章轉(zhuǎn)載自公眾號??純潔的微笑?，?作者 微笑很純潔

“有一個讀者問我：你認為一個程序員具備什么樣的能力，才算得上是厲害的程序員？我答：擁有解決問題的能力的程序員。這個回答貌似有點抽象，不要緊看下面的文章你會慢慢有所了解。

圖片來自 Pexels

解決問題的能力

很多年前，當我還是一個小菜鳥的時候，我的領(lǐng)導經(jīng)常告訴我，解決問題的時候，不要局限于技術(shù)本身，并且形象的給我舉了一個例子。

有一次兩個程序員一直討論，如何判斷兩臺服務器之間是否網(wǎng)絡(luò)正常，爭爭吵吵了很久。

旁邊的一個測試說，Ping 一下不就知道了嗎？就這樣他們用 Java 代碼實現(xiàn)了 Ping 操作解決了這個問題。

多年以后，雖然我知道有更優(yōu)雅的方式來解決這個問題，但是我仍然覺得之前的那個測試人員很聰明。

后面我們持續(xù)打過一年交道，她能力真的很強，在小公司相當于產(chǎn)品經(jīng)理+測試的職能。

需要給大家說明的是：解決問題的能力和技術(shù)能力是兩個能力區(qū)間，我見過很多程序員源碼玩得一溜，生產(chǎn)出現(xiàn)問題的時候仍然不知道如何去解決問題。

生產(chǎn)出現(xiàn)問題的時候，是考驗一個程序員的最高水準，在面對高強度高壓力下，動作不變形，能夠冷靜思考、分析、解決問題，能達到這個水平的程序員，這在古代可以拜為上將軍。

我一直非常喜歡能夠快速解決問題的程序員，我也樂于在各種生產(chǎn)出現(xiàn)問題的時候，第一時間去研究去分析。

說一句不厚道的話，好程序員都是在解決問題中鍛煉出來的，特別是生產(chǎn)環(huán)境出現(xiàn)問題時，能夠站出來的程序員。

凌晨遷移數(shù)據(jù)出大事故

下面跟大家分享一個發(fā)生在深夜的技術(shù)故事。

老平臺和新平臺

公司有一個老系統(tǒng)，一個新系統(tǒng)。老系統(tǒng)使用了很多年，早已經(jīng)超出了它能支持的極限，最早在 2013 年上線這套系統(tǒng)的時候，預估每天的交易量在一兩個億，實際上現(xiàn)在每天已經(jīng)跑出了 40 億的交易量。

從 2013-2017 年，技術(shù)團隊做了很多努力，老系統(tǒng)使用的是 Oracle 數(shù)據(jù)庫，為支持最大的交易量，讀寫分離分庫分表+各種最強硬件搞上；系統(tǒng)拆分、重構(gòu)、優(yōu)化了很多次，仍然滿足不了公司日益增長的交易量。

說實話，團隊能把一個老系統(tǒng)整成這個樣子，也確實不易。最初的架構(gòu)設(shè)計不合理，縫縫補補終究解決不了大問題。

研發(fā)新平臺成為公司發(fā)展必須要做的一件事情，新平臺一期設(shè)計可以支撐日百億的交易量，最重要的是支持后期日千億的擴展。

經(jīng)過兄弟們的艱苦奮戰(zhàn)，新平臺終于上線了。新平臺上線是成功的一小半，后面的數(shù)據(jù)遷移才是最最重點的事情。

運行了好幾年的老系統(tǒng)，使用的是傳統(tǒng)的垂直架構(gòu)，（架構(gòu)演進可以參考這篇文章：從架構(gòu)演進的角度聊聊 Spring Cloud 都做了些什么？），各種業(yè)務、政策、活動、風控都揉在了一起。

新平臺使用的微服務架構(gòu)，光微服務就搞了上百個，數(shù)據(jù)庫 MySQL HA。兩個系統(tǒng)在架構(gòu)設(shè)計上隔了一代，在設(shè)計時為了兼容老系統(tǒng)的部分功能，還做了部分冗余設(shè)計，反正這兩個系統(tǒng)就不是一個時代的產(chǎn)物。

遷移的要求是，從老平臺遷移到新平臺的時候，不能影響到商戶的正常交易。

打個比喻就相當于，你開著車在高速公路上跑，在行駛的過程中換掉車輪，而這個過程還得讓坐車的你不能有任何感覺。

于是我們研發(fā)了一套遷移系統(tǒng)，本來計劃著一批一批的遷移，給新平臺一次切一兩個億的交易量，慢慢看看效果再根據(jù)節(jié)奏來走，但是突然來的一次政策（活動）打亂了這個節(jié)奏。

新政策帶來的變化

對于第三方支付公司來講，經(jīng)常會隨著市場環(huán)境推出一些新政策（活動），有些政策比較簡單，但大多數(shù)政策很復雜，往往需要很大的開發(fā)量。

當時新平臺已經(jīng)切換了一段時間，大家慢慢對新平臺有了一定的信心，就決定把這個新政策在新平臺實施。

計劃在執(zhí)行政策的當天晚上，把其中一個老平臺上剩余的商戶全部遷移到新平臺。

方案定下來之后，各部門開始各司其職，運營中心對外發(fā)通知，我們要在元旦的時候搞個大動作，可能會有什么樣的變化；營銷中心負責聯(lián)系各代理進行分批培訓；商務部門開始出公司的紅頭文件，下發(fā)各分公司。

我們提前和客服、運營部門做好溝通，可能會面臨哪些問題提前做預案；公眾號、公司官網(wǎng)、App、郵件對外通知政策變化，公布開始執(zhí)行日期；產(chǎn)品中心負責政策落地需求梳理，研發(fā)中心開發(fā)新政策確定的方案。

最最最重要的是，要確保元旦晚上可以把剩余幾百萬的商戶，一次性平穩(wěn)的遷移到新平臺。

半夜開始遷移

遷移程序之前已經(jīng)執(zhí)行了很多次，所以大家對這塊相對比較放心，但仍然和主要負責遷移的同事確認了好多次，開發(fā)環(huán)境提前兩周必須測試完畢，UAT 環(huán)境需要在遷移一周前測試完畢，研發(fā)和測試雙驗證。

直到距離遷移還有三天的時候，我還專門找到負責遷移的那名程序員了解進展，問有沒有在生產(chǎn)上進行過模擬測試。

確認沒有問題后，根據(jù)主負責人反饋的時間預估三四個小時可以遷移完畢，這樣凌晨 1：00 開始，凌晨 4：00-5：00 之間可以遷移完畢。

在真正執(zhí)行遷移的前一天，又拉著各部門做了一次溝通會，大家一起討論可能出現(xiàn)的各種情況，以及各部門需要留守的人員。開完會之后，大家感覺都還不錯，靜等晚上這一場大戰(zhàn)！

當天晚上留下來十幾名開發(fā)和兩名測試，以及一些其它部門的同事，大概二十幾人左右，12 點之前大家說說笑笑，打打游戲靜等凌晨 1 刻遷移，因為剛好是元旦，辦公室一片過節(jié)的感覺。

時間過得很快，凌晨 1 點的北京，窗外星光點點，辦公室內(nèi)一片緊張。

十幾名同事都圍在了主要負責遷移的這名程序員旁邊，能明顯感覺到這名程序員很有壓力（哈哈，我估計這種事情放誰身上都會有壓力）。

不過他還是熟練的按照之前多次測試的那樣，核查了多遍數(shù)據(jù)之后，點擊遷移按鈕。

首先在生產(chǎn)環(huán)境遷移一個代理商，看看數(shù)據(jù)是否正確，執(zhí)行完畢后相關(guān)人員開始核驗數(shù)據(jù)。

運維人員核查日志，開發(fā)人員確認相關(guān)節(jié)點正常、數(shù)據(jù)庫工程師核對遷移數(shù)據(jù)；測試人員在運營平臺查詢數(shù)據(jù)核驗、測試 Pos 刷卡情況，一切正常！

試了兩個代理商都沒有問題，下面就準備 All In 了，剩下幾百萬商戶，上千個代理商就計劃一把梭了。

負責遷移的程序員，將所有代理商編號，配置到執(zhí)行程序中，點擊了執(zhí)行按鈕，生產(chǎn)跟蹤了一下日志，一切正常。

留下幾個人監(jiān)控數(shù)據(jù)，其他人就散了，等遷移完成后再進行后續(xù)工作。我也回到了工位，點起了一根煙，想著今晚還比較順利。

突發(fā)事故

凌晨的夜晚比較困，當我點起第三根煙的時候，負責遷移的這位程序員，急匆匆的跑過來找我了。

“強哥，出現(xiàn)問題了！”

心中一驚，猛吸一口煙，把煙掐滅，忙問到：“出現(xiàn)啥問題？”

原來這位程序員在遷移程序執(zhí)行后，就一直在跟蹤遷移的進展，發(fā)現(xiàn)過了半小時才遷移了 10 萬商戶，老平臺總共幾百萬商戶，按照這個速度，全部執(zhí)行完需要幾天后。

這個事可大了！如果在上午 8：00 之前不搞定這個事情，那就完全是重大事故了。

先不說怎么處理新老平臺數(shù)據(jù)割裂，如果公司政策推遲執(zhí)行，怎么在這么短的時間內(nèi)把信息通知到幾百萬商戶、幾千個代理商，就是一個不可能完成的工作量。

可以想象第二天都會出現(xiàn)什么樣的狀況，客服 400 電話被打爆、運營人員溝通到吐血，因政策推遲執(zhí)行可能導致的公司損失，針對代理商的補償行為......

如果這個問題我們沒有在一個小時內(nèi)解決掉，就需要立刻上報公司副總經(jīng)理，然后估計連夜公司所有的管理層，都需要來公司開會商量后續(xù)處理方案。

大腦中雖然閃過遷移失敗后的嚴重后果，但眼前還需要壓下所有的想法，先分析到底是哪里出現(xiàn)了問題，有沒有什么樣的降級方案或者補救方法。

①分析原因

經(jīng)過查詢?nèi)罩尽⒑藢?shù)據(jù)基本查明了原因，開發(fā)人員在生產(chǎn)測試的時候，都使用的是中小型代理商進行的測試。

但忽略了公司不同代理商規(guī)模之間差異極大，最大的核心代理商一家的數(shù)據(jù)，可能占平臺整體交易量的 5%-6%。

所以根據(jù)中小型代理商評估的時間肯定是不準確的，事已至此先不說誰的問題。

如何快速解決問題才是接下來的關(guān)鍵，大家一起想解決方案，有什么辦法可以讓遷移速度更快一點。

②補救方案

比如先同步核心數(shù)據(jù)，其它內(nèi)容后續(xù)再進行處理，先保障第二天的交易。

比如可不可以全部使用人工導表來處理，數(shù)據(jù)庫工程師聽到這個方案的時候，差點哭暈過去，上千多張表，關(guān)系極為復雜；各種各樣的方案......

在大家七嘴八舌討論優(yōu)化方案的時候，才發(fā)現(xiàn)遷移程序的主流程沒有使用多線程來遷移。

遷移程序提供了一個界面，每次遷移的時候開發(fā)人員會在頁面填寫需要遷移的代理商編號，后臺接收到頁面?zhèn)鬟f的參數(shù)后，開始 for 循環(huán)執(zhí)行遷移。

雖然代理商下的商戶使用了多線程遷移，但是遷移代理商的主程序入口，卻沒有使用多線程，因此大家想是否把代理商這塊也用多線程來加快遷移速度。

人工多線程救場

大家討論之后，覺得多線程來遷移代理商應該是目前比較好的一個方案，但是如果讓現(xiàn)場寫，沒有經(jīng)過測試直接就生產(chǎn)執(zhí)行，風險還是比較大。

那還有什么不用改程序就可以實現(xiàn)這種代理商并發(fā)遷移的效果嗎？確實有！

大家知道我們平時開發(fā)的 Web 應用，前臺的每一次請求到后端就會分配一個 Servlet 來處理響應，這個 ?Servlet ?其實就是一個獨立的線程。

那么每次多打開幾個頁面，同時執(zhí)行遷移請求不就實現(xiàn)了多線程遷移代理商的效果嗎？

說干就干，把之前的遷移程序停掉之后，選擇十幾個代理商進行多線程遷移測試，同時打開了 4 個頁面，每個頁面輸入不同的代理商，開始遷移測試，測試后發(fā)現(xiàn)一切正常。

開始加大測試量，使用幾十個代理商，在不同的頁面輸入后，先后點擊了遷移程序，在第二次并發(fā)遷移的過程突然發(fā)現(xiàn)不時的會報一些錯誤。

停止遷移程序，開始尋找原因，根據(jù)報錯的原因發(fā)現(xiàn)是出現(xiàn)共享數(shù)據(jù)了。

我們知道 Servlet 是線程不安全的，當出現(xiàn)多線程訪問的時候，如果有全局共享變量就會出現(xiàn)線程安全問題。

這個問題好解決，使用 ThreadLocal 來修飾就行，ThreadLocal 為每個使用該變量的線程提供獨立的變量副本。

所以每一個線程都可以獨立地改變自己的副本，而不會影響其他線程所對應的副本。

這個問題解決之后就繼續(xù)打開多個頁面執(zhí)行，但同 1 個 Tomcat 并行超過 6 個線程的時候，機器負載就會比較高，因為每個線程內(nèi)還會再次調(diào)起另外的線程池來處理商戶、業(yè)務員的遷移邏輯。

于是就立刻安排運維人員，在生產(chǎn)環(huán)境找 10?臺服務器，在這 10?臺服務器上都部署上遷移的主調(diào)度程序。為了防止開發(fā)人員手抖出現(xiàn)問題，我讓運維給我開了權(quán)限。

于是在我的電腦上（我使用了多個屏幕），分別打開了 10?臺服務器上的遷移程序頁面，把所有需要遷移的代理商按照每次 15 個分組，每次在 1 個頁面輸入 1 組代理商來遷移，如此循環(huán)依次在每臺服務器開始遷移代理商。

當我循環(huán)執(zhí)行了 6 次的時候，數(shù)據(jù)庫工程師檢測到明顯數(shù)據(jù)的遷移速度加快，就這樣我用了 2 個小時，在頁面把所有的代理商分別進行了遷移。

大概到凌晨 4 點的時候，我的工作基本上搞完了，剩下的就讓程序慢慢跑了；凌晨 5 點的時候，大部分商戶數(shù)據(jù)都已經(jīng)遷移過來，只剩下 2 臺服務器還在繼續(xù)跑；到了凌晨 6 點的時候，10?臺服務器的遷移程序全部跑完。

安排把所有相關(guān)數(shù)據(jù)一一進行了核對后，大家長長的舒了一口氣。

早上 7 點一起下來吃早餐的時候，大家還在說，感覺昨天晚上差點就過不去了。

開玩笑說，如果凌晨 2、3 點的時候，給我們老板打電話，老板會是什么樣的感覺。

那時候想，出現(xiàn)這么大的事故，老板把我們開除了都是小事，如何收場才是我們最關(guān)心的。工作丟了可以再找，事情不管怎樣都是需要我們這批人來解決處理的。

上午 9 點打開交易后，又陸陸續(xù)續(xù)出現(xiàn)了一些小問題，但都是小面積的、不影響交易的問題，整體范圍可控，晚上遷移的這幫人，幾乎都堅持到了下午沒有太大問題了才回去睡覺。

事后回想時，大家都一種劫后余生的感覺。

事件回顧

事后我們開復盤會的時候，總結(jié)了這里面疏漏的很多點，但這些都不是本文的重點。我們還是回到文章的開頭，什么是厲害的程序員？

大家可以看到這個問題并不是特別的復雜，處理時需要的技術(shù)手段也比較簡單，但最關(guān)鍵是解決了當時最最緊迫的問題。

所以說技術(shù)沒有什么高低之分，學習技術(shù)的本質(zhì)也是為了解決各種各樣的問題，不要對技術(shù)迷之自信，能用起來才是最好。

技術(shù)人要學會享受壓力，因為壓力就是動力，壓力就是讓你去成長的，越早遇到成長得越快。

人在高壓高強度的環(huán)境中，哪怕很簡單的動作可能都會變形，從而有可能引發(fā)更大的二次事故。

在高強度、高壓力的環(huán)境下穩(wěn)定保持一顆冷靜分析的心，只有你自己沉靜下來才能真正的發(fā)現(xiàn)問題解決問題。很多技術(shù)人，出現(xiàn)問題時你看他在忙，其實是沒有思路在那瞎操作。

冷靜下來，仔細分析整個鏈條，設(shè)想哪個地方可能會出現(xiàn)問題，然后通過查詢?nèi)罩净蛘呦嚓P(guān)命令，一步一步去排查、驗證問題的根源在哪里，只有真正找到了問題的根源，你解決的時候才可以胸有成竹。

當天晚上留守遷移的程序員，都是我司最核心的一批程序員，但是誰有能力上誰有能力下，在這一晚上很容易就能發(fā)現(xiàn)，優(yōu)秀的程序員就像金子一樣，關(guān)鍵的時刻它會發(fā)光的。

很多人遇到問題就自然的就會后退幾步，有的人遇到問題就喜歡沖上去。不管你平時源碼研究得多牛逼，不管你的 PPT 寫得有多好，公司需要的是遇到問題的時候，有人能夠頂上去把問題解決掉。

凡是能夠在關(guān)鍵時刻頂上去的程序員，基本上后面都很容易走上管理崗位。人和人其實就是在不斷磨合中建立信任的，領(lǐng)導在選擇提拔員工時，主要考慮就是能不能放心把事情交給你。

所以大家平時研究技術(shù)的時候，不要走偏，源碼、設(shè)計模式這些東西是應該研究，但更應該考慮的是研究后如何去應用，多專注一些實戰(zhàn)型的知識，這些東西關(guān)鍵時刻可以救你的命（職場）。

如何做一名有能力的程序員

那么作為一名程序員，如何培養(yǎng)自己解決問題的能力呢？實踐！實踐！實踐！平時的技術(shù)學習只是一種強力輸入，如果不進行實踐，這些能力就會很快流失了。

那如何實踐呢，多做項目，如果公司的項目用不到此技術(shù)，可以自己業(yè)余時間寫寫代碼自己去調(diào)試一番。

另外同事出現(xiàn)問題的時候多去幫忙解決問題，公司出現(xiàn)問題的時候，主動去幫忙解決問題；解決各種各樣的問題，是提升能力的最快方式。

實踐完成之后，最好還能復盤總結(jié)一番，把總結(jié)的內(nèi)容作為日志或者博客記錄下來。

記錄下來的內(nèi)容就會成為你的一個知識寶庫，以后遇到類似問題的時候，檢索一下即可解決，如此不斷豐富自己解決問題的經(jīng)驗。

最后，愿你成為一名真正的技術(shù)大拿！

作者：純潔的微笑

簡介：純潔的微笑，一個有故事的程序員。曾在互聯(lián)網(wǎng)金融，第三方支付公司工作，現(xiàn)為一名自由職業(yè)者，和你一起用技術(shù)的角度去看這個世界。我的微信號 puresmile2，歡迎大家找我聊天，記錄你我的故事。

編輯：陶家龍、孫淑娟

出處：轉(zhuǎn)載自微信公眾號：純潔的微笑（ID：keeppuresmile）

總結(jié)

以上是生活随笔為你收集整理的凌晨1点突发致命生产事故！看的我惊心动魄…的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。