專訪劉毅：阿里巴巴云計算平臺運維故障分析與排查
原創【51CTO原創稿件】任何計算機系統都有出現故障的時候，小到一個終端的軟件無法使用，大到整個系統癱瘓，所有業務不能辦理。這也是系統管理員或者運維工作者最擔心的事情。如何做到快速定位故障問題，合理分析故障成因，找出排查方案是管理者們需要了解的事情。在阿里巴巴集團主辦的ADC·阿里技術嘉年華大會上，51CTO記者有幸采訪到了從事阿里集團云計算平臺的一線運維劉毅（@毅毅），看看他是怎么做到的吧。
以下是采訪實錄：
不同平臺運維工作的對比
51CTO：劉毅你好，首先請大概介紹一下你自己的經歷和現在的工作職責。
劉毅：我之前在eBay COC負責UNIX系統運維，離開COC之后，2010年加入阿里集團，其實最開始招我進來的是阿里云，集團的云計算平臺也是剛剛開始，差不多三年，我就伴隨著云計算平臺逐步成長，在一線參與了集團云計算平臺一線運維工作。
51CTO：所以你主要關注的一些領域就是云計算相關的？兩家公司的工作模式和工作職責相差大嗎？
劉毅：區別還是比較大的，在eBay負責運維的是成熟的應用，整個應用架構是全冗余的，高可用性，并且較多的使用商用解決方案，而且他們在商用解決方面的預算是不菲的，相對來說，運維對底層的穩定性會依賴于廠商支持，商用負載均衡設備的廣泛使用也不會因為單臺的服務器不可用而給我們運維造成困擾。
***次接觸到云計算平臺運維的時候，我感覺一下回到了石器時代。大概意思是運維環境非常惡劣，每天有個兩三臺服務器宕機是再正常不過的事情。沒有存儲，沒有帶庫，數據都是存放在本地硬盤，每塊硬盤上的數據隨時都可能丟失，數據的冗余全靠云平臺自身解決。這就苦逼我們運維了，我們要幫助云平臺去解決各式各樣的問題，它解決數據冗余的問題，并不意味著機器不用恢復，硬盤不用替換，緊急情況不用處理了。前3個月，最的最多的就是重復勞動，感覺沒有價值，簡直是勞動密集型產業。怎么辦？我們需要工具，自動化工具來幫助我們擺脫重復勞動，shell、perl、python，只要能提高效率的，我們不區分工具語言，不過還是Python使用的最廣泛。漸漸的從命令行自動化做到web自動化，點點鼠標完成5000臺服務集群的停起，升級、查看狀態信息等工作。感覺很***了？還沒有，這些僅僅是表面的改善，我們現在期望從運維著的這些上十萬臺服務器，每天產生的硬件日志、系統日志、應用日志之間，在這些龐大的數據里，就像挖金礦一樣，挖掘出能夠改善我們運維、應用的方法，今天的我演講的主題就是一個數據化運維的例子。
51CTO：目前你們團隊的規模大概是什么樣的情況？
劉毅：我所處的團隊目前人數20人不到，也是從4-5個人發展起來的。他們有負責離線平臺運維，在線平臺運維，還有負責相關運維自動化。基本上每個人都會了提高運維效率而寫代碼，看代碼。花費大半的精力來維護優化自己的運維工具。工具寫的越多越感覺到需要用數據的分析來幫助我們判斷怎么樣做才是高效的，借助我們身后平臺的力量。
51CTO：你們的客戶相當于就是為阿里云提供？
劉毅：我們主要是服務內部的開發客戶，但是我們的運維業務呢也有服務外部客戶的。比如藥品監管碼。通過監管碼，可以追蹤藥品從生產、倉儲、銷售的全過程，這些數據就存儲在我們運維的服務上。但是呢這些還是少數，我們目前主要是支持集團內部的業務和開發客戶。#p#
阿里巴巴云平臺運維故障排查
51CTO：你們平臺平時出現故障頻繁嗎？
劉毅：平臺建設的初期，因為不穩定，故障比較多，當時挺累的。隨著平臺穩定，自動化工具的成熟，局勢已經扭轉過來了。
舉個最最簡單的例子：過去做運維，因為底層硬件可用性、冗余度高，宕機率都是按年來計算。而現在這些廉價的PC服務器，幾乎每天都會有宕機，這對同樣是處于初期的云計算平臺的沖擊還是有的，所以一臺服務器，或者一塊硬盤都可能會影響到整個服務集群的穩定性。而現在有了這些經驗的積累，不管是平臺自身還是運維手段都有辦法來規避底層硬件不穩定的問題。
再舉個更細節的例子：過去運維不需要關心硬盤的維修，我們都知道甄別壞盤是存儲設備的基本功能，而且往往能貼心的亮起指示燈，可以說整個過程除了主動向廠商報修，運維不需要做任何事情。但是在我們云計算平臺初期不行，開始運維就像保姆一樣要跟蹤整個過程，我們要主動發現，要及時修復，發現晚了，可能就是一個故障、修復不及時可能空間就緊張了，聽起來好像很夸張，如果你看了我分享的幾個運維數據，真是那么一回事兒了。這些事情很重要，重復度又很高，特別是在大規模服務器下，我們不能每天去重復勞動，對運維價值的提升不大、對平臺穩定性也毫無益處，我們就用自動化解決，把這些廉價服務所不能做的帶來的問題，用我們的自動化工具變得像之前昂貴的存儲設備那樣的智能。這很有意思，你會感覺你和云平臺一起在成長，停不下來，比如說，僅僅是發現還不夠，我們還要做預測，硬盤作為機械設備，隨著時間增長，肯定會老化，老化會帶來各種各樣的問題，比如性能慢，不響應。那么我們通過研究磁盤參數，做到磁盤健康的預測。首先這些參數都是廠商定義的，偏理論，但能不能用 ，好不好用，但是我們擁有龐大且真實的實際數據，把這些數據采集并且在云平臺下做數據分析挖掘，提煉適合我們不同業務場景下的磁盤監控度的預測，最關鍵的是取到好的效果和反饋，特別是在關鍵戰役，雙11之前，做到預測結果不好的硬盤提前下線，避免關鍵時刻掉鏈子。
舉了2個例子，平臺不穩定、故障多不會是常態，通過運維自身的演變，可以讓那些緊急的、危害大的運維異常變成可控的、影響小的運維事件。
51CTO：除了你剛剛提到的硬盤，其他的還有哪些比較容易導致故障？
劉毅：硬盤只是一個例子，我們把它歸結為硬件故障，除此之外呢，還有就是軟件bug。再者就是人為的疏忽造成的。
51CTO：你剛剛說運維分了很多種。出現什么故障的時候是不是流程也會復雜？
劉毅：復雜是相對的吧，如果公司人少，再復雜也不復雜到哪里去，想阿里這么大的公司，相對來說肯定要復雜一些，但是我們集團內部有團隊會負責和改進流程，不管是故障流程，還是日常的各種流程。
51CTO：是說出現哪個方面的故障，然后是有人判斷，然后確定是哪個組負責的，然后就派那組去解決？
劉毅：對的，會有一個責任人或者責任部門，但是原因和改進措施需要大家一起來配合做。
51CTO：你們這邊工作的效果是怎么考核的？因為這幾天也是聽了阿里其他團隊的人來講，比如說像是做云的，他可以說我提供這個服務給你們。或者是提高軟件性能的，他也可以說我作為業務，我提供給你們，幫助你們的服務做的更好。對于你們來說，客戶已經固定了，成了一個保障部門。那你們這邊的具體考核方法是什么？
劉毅：考核并不是恒定不變的，個人的考核辦法一定是保障團隊目標的前提，而團隊一定是保障公司目標的，具體來說，作為運維，至少要有東西運維，才能說有價值吧，這時候又不能挑業務，不能說這個業務容易出彩，運維風險又小，我就要去運維，憑啥讓給你？對吧，開始只能有什么運維就運維什么，主要考核就是你有沒有運維好，有沒有故障，有沒有提高效率這些硬性的運維指標吧。隨著業務的壯大，運維的場景變多，招人也算是考核指標吧，一個是業務擴大、一個是團隊成長，都需要新鮮的血液。還有就是資源利用率、怎么用好手上的服務器，這非常考驗我們運維。還有雙11，這也是個重要的考核指標吧。
51CTO：***談談你個人的未來發展問題吧，你自己是怎么規劃的？是一直做運維？還是轉開發，或者別的？
劉毅：我想我不會轉開發，我覺得運維不錯，一直做下去。因為我覺得現階段運維很有趣，也很有挑戰。想想怎么把各種系統數據、應用數據收集起來，用云平臺幫我們分析，提煉出有幫助、有價值的內容，真是太有意思了。因為***、很多方面我們沒接觸過，比如數據挖掘，需要我們不斷的充電，第二、經常有被顛覆的感覺，不是這樣的感覺，比如我們預測硬盤健康的時候，并不是說我們拿一個值，越大越好或者越小越好，真實數據告訴我們是有臨界區間的，而且找到這個臨界區間。這很有意思、很有挑戰，把日常無序、雜亂的運維數據變得有用的，很有成就感。在云計算時代，真真切切的感覺到數據的強大，我想我會沿著數據化運維的方向走下去，把那些運維異常變成可控的運維事件。
51CTO：變成一個可控的。
劉毅：是的，這很有意義，做到可控就很有意義，但是很難，以前我們會說憑經驗，憑感覺，世界變化這么快，怎么知道經驗是可靠的？如果還靠一次次故障堆積經驗，是否還合算呢？業務千變萬化，適應客戶要求，我們運維怎么辦？很多事情，可以這么做，可以那么做，我怎么說服你呢？其實***這些的答案就是數據，現在感覺所有自動化都是為了數據運維而準備的，在數據化運維我還不知道我有沒有找到大門，我不知道在哪兒，我剛才舉的介個例子，可能是對的，可能是數據樣本不夠，還不夠準確，這就是又有趣又有挑戰的地方，我想我暫時還癡迷著這些，呵呵。
好的，本次采訪到這里就結束了，非常感謝劉毅的分享！如果您還有其它的問題或者建議，歡迎留言討論。
【編輯推薦】
【責任編輯：黃丹 TEL：（010）68476606】
