情景
我們想搭建一套線上變更前，上線程式碼的一個迴歸驗證環境，跑測試用例的平臺工具已經有了，苦於整套鏈路沒有搭建好，並且總有問題，測試用例跑不通。
目標
1.專案的目標是15分鐘(有可能的話儘量控制在5分鐘內)跑成功100w案例(測試用例)；案例包含兩套環境，每套環境不僅要和預期的結果一致，而且要求同一個案例兩套環境結果要相同(目前回歸驗證平臺的做法是一個案例要等兩個環境結果都返回才算一個事務結束，這會增長用例執行時間)。
2.專案的目標並不是我的目標，我們團隊實際上不是自動化迴歸環境的開發者而是使用者，我們希望儘量少的投入人力成本最好是不投入人力成本讓環境穩定執行。
行動
小處著手，各個擊破
如果開展一個新專案，同事之間之前沒有合作過。這時候一個比較好的融入方法是小處著手，踏踏實實的做些事情，解決問題，建立一定的影響力，再去協調大家，讓別人來配合自己的思路。
我剛做這個專案第一週解決了十幾個小問題，比如有個現象是超時的問題，最終定位是mock（模擬外部服務的打樁）服務磁碟被打滿導致。解決方法是首先手工清理磁碟，先不block別人，然後給自己制定了一個任務：將服務改成自動歸檔和清理日誌的模式，作為一個低優先順序的事情進行(最終在1周後完成了自動清理日誌)。
這個例子裡涉及到2個小的做事方法，第一是時間管理的四象限理論。
事情要分輕重緩急，人工清理日誌不block別人是緊急的事情。自動清理日誌是長期從根本上解決問題，是必須要做的事情，但是沒有那麼緊急，這時候只要將事情記錄下來，在自己相對空閒的時候來做。
第二是做正確的事而不是容易的事。
長期從根本上解決問題是正確的事，但是相比手動清理日誌而言要難一些。因為我從來沒有接觸過這部分的程式碼，連程式碼許可權都是託人給開通的。後續程式碼改好了測試好了要釋出，釋出的許可權也沒有，一系列的問題很繁瑣。相比較而言手動清理日誌更簡單，但是為長遠考慮，如果哪段時間我忘了要把日誌清理一下，又出了問題，結果就是別人發現超時了，找到我，我遇到這個環境的問題80%是超時問題，所以需要重新排查，最終定位到問題清理了日誌，告知大家原因，大家跟我說感謝及時響應解決了問題，心裡暗暗給我打上了【同樣的問題反覆出現，做事不靠譜】的標籤。所以做事：事前要推演，事中要敬畏，事後要覆盤。
採用科學方法應對效能問題
對於效能問題的排查效果的衡量採用《效能之巔》中的USE法配合科學法進行驗證。
排查採用USE法，USE法應用於效能研究，用來識別系統瓶頸，就是對於所有的資源，檢視的使用率、飽和度和錯誤。
效果衡量採用科學法，科學法研究未知的問題是通過假設和實驗，總結下來有以下步驟：
1.問題 2.假設 3.預測 4.實驗 5.分析
在此專案中舉例來說，就是對於效能問題從CPU、IO、記憶體SWAP等系統指標和業務日誌中的錯誤來找到影響效能的因素。在驗證的時候先明確問題：比如返回一個錯誤，檢視日誌是呼叫超時引起。使用USE工具檢視指標，得出假設記憶體是影響效能的瓶頸。預測記憶體的減少會提高或降級效能。實驗時只改變記憶體一個因素，確保其他環境和上次驗證時一致，對實驗結果和假設進行對比分析，得出如果將所有2核4G虛擬機器合成半數4核8G虛擬機器提供服務效能可能會顯著提高的進一步假設。這個問題的具體分析後面會講。
以終為始
在專案目標中提到，我們團隊實際上自動化迴歸平臺的使用者，不是開發者。所以我做這個專案對團隊的產出很有限。我也會面臨一些壓力，需要從這個事情中抽身出來，集中精力加入到我們團隊的重點專案當中。
於是在我加入兩週後，我梳理了一些解決問題的文件，跟專案其他同事溝通說如果遇到問題能不能先按照文件排查，如果問題解決不了再找我。當時，他們勉強同意。結果第二天，就是上面提到的2核3.7G虛擬機器重做成了4核8G虛擬機器的事情，那天衝做好的沒有部署服務的機器交付過來了，這時候需要重新搭建環境，我請別人幫忙別人自然沒有時間處理。
我搭建好環境之後，我也把怎麼搭建一套我們這邊服務的流程寫成文件，看看自動化迴歸環境那邊可否出人來cover這件事。因為當時也是有點壓力，所以溝通上也比較生硬，很強硬的希望能把問題分擔出去。
溝通到最後，我自己的理念價值觀又回來了:成就別人就是成就自己；解放自己最根本的方式就是處理好自己的問題。所以我最後說我們團隊的問題我們自己來處理，這點沒有分歧，掛了電話，後來又就自己的行為跟當事人道了歉。
這件事情我處理的不好，根本原因是沒有以終為始的做好事前推演。事情本來很簡單，如果我在溝通前推演一番就知道：
如果目前回歸環境的問題沒有徹底解決，就算有文件也還會找到我。這時候我會很被動。找我解決問題，我再去解決，不從源頭上分析問題根源，頭痛醫頭腳痛醫腳，總體對我時間的佔用是延長的。
對自動化迴歸環境這個專案來說，我們團隊在整條鏈路中起著至關重要的作用，核心鏈路裡面3/5的專案都屬於我們團隊，我由於有著程式碼許可權、我們團隊的人力配合資源、加上技術和工作經驗等原因，實際上在主導著專案的推進，是每週完成預定目標的重要原因，如果我這邊為專案考慮的少了，整個專案就會不能完成既定的目標。我沒有成就這個專案，雖然我不是專案的主責任人，專案失敗的負面影響會一點不少的都回饋身上，甚至我們團隊上。很明顯會得不償失。
從第一週開始，我就總結出了要想做好這個專案的根本方針就是刨根問題，解決所有問題，並且也知道只有解決問題才能解放自己，但是沒能時刻以終為始的堅持，和以此原則和各方溝通，闡述自己的觀點，是其中的失誤。
結果
按照每週目標完成了任務。
問題分析
我們回到有個超時問題，將所有2核4G虛擬機器合成半數4核8G虛擬機器來做為解決方案的那裡。用5why做一個根本原因分析。
1.為什麼會超時？
同樣部署在2C3.7G機器上的同樣的服務，有的機器超時，有的不超時，初步排查是效能原因。
2.怎樣判定是否是效能原因？
超時的機器特徵為：GC頻繁（其他機器GC為每分鐘3次以內，問題機器為每秒2次以上）、IO高。記憶體使用上較其他機器多出約100M(JAVA程式，經過測試，JVM堆配置為3G效能高，其他機器佔用總記憶體為3.5G左右，問題機器佔用3.6G)
3.GC頻繁、IO高、記憶體高之間有什麼關係？
GC頻繁的根本原因，是記憶體不足，需要垃圾回收導致。
GC頻繁和IO高的關係：從原理上JVM引數有配置GC開啟寫GC日誌，寫GC會呼叫作業系統write()操作，這是一個IO操作。GC造成stop the world停頓，停頓會造成響應時間的延長，IO連線不釋放，極大的加劇了IO問題。造成滾雪球效應。
記憶體不足會造成頻繁的在磁碟上進行檔案交換，加劇IO問題。
4.為什麼會記憶體不足？
線上機器都是4C8G，而我們團隊的系統也是按照這個配置來設計，利用了很多記憶體快取的技術，是造成記憶體不足的根本原因。
5.為什麼超時是個別機器？
因為我們壓測併發量是一點點加上去的，所以是壓測到了有機器有問題就不再增加併發量，實際上再增加併發量會有更多機器暴露超時問題。記憶體不足，會造成頻繁的在磁碟上進行檔案交換。雖然這些機器CPU、記憶體、磁碟的大小是相同的，但是磁碟轉速是不相同的。磁碟與記憶體之間檔案交換慢會進一步加劇記憶體問題，產生蝴蝶效應。
總結
化平凡為神奇
金庸經典《射鵰英雄傳》裡，黃蓉為了讓洪七公交自己和靖哥哥武功，天天對師傅美食相待，在做了“玉笛誰家聽落梅”這樣一些世間珍品之後，信心滿滿的告訴自己的吃貨師傅七公說今天要做的是"炒白菜"。七公立刻兩眼放光，面露欣賞之色，說：“好，我倒要看看你怎樣化平凡為神奇。” 最後，黃蓉以自己的獨家神技成為了丐幫第十九代幫主。
我選擇了專注於穩定性這個領域，就意味著選擇了時刻準備著加班、半夜被叫起來，每天以以後不需要加班，不會半夜被叫起來為目標。想實現這個目標單純靠隔離、限流、熔斷等工程手段是做不到的。通常面臨的是枯燥的發現問題、排查問題、解決問題、線上運維這些看起來並不高大上的工作，而在做這種工作的過程中能夠使用技術和方法，集腋成裘，將平凡的小事做成很牛的大事，就是穩定性領域努力的方向。
相關閱讀