本文轉載于：高效運維公衆号 作者：範倫挺
範倫挺，阿裡巴巴 基礎架構事業群-技術專家。花名蕭一，2010年加入阿裡巴巴，現任阿裡巴巴集團大資料計算平台運維負責人。團隊主要負責阿裡巴巴各類離線上大資料計算平台（如maxcompute、analyticdb、streamcompute等）的運維、架構優化及容量管理等
本文主要會從以下四個方面來寫，分别是：
阿裡大規模計算平台運維面臨的一些挑戰；
阿裡自動化平台建設；
資料精細化運維；
我對運維轉型的思考和了解；
在講挑戰之前，我們可以簡單看一下阿裡大資料平台演進曆史，我們的 maxcompute（原odps）平台是2011年4月上線的，2013年8月份單叢集超過5k，2015年6月單叢集超10k，目前在進行異地多活和離線上混布方面的事情。
<b>首先是規模大、小機率事件常态化</b>
對于小機率事件大家不能賭運氣，基本每次都會踩中狗屎的。譬如各類硬體故障，規模小的時候覺得硬體故障機率比較低，即使壞了也比較徹底，但是規模大了後會有很多情況是将壞不壞，類似這種奇葩事件會越來越多。 還有網絡鍊路不穩定，網絡鍊路會有很多原因導緻它不穩定。一方面是網絡裝置多了，網絡裝置出現故障的機率也大了，另一方面營運商日常割接、挖掘機施工等都會對我們帶來挑戰。 還有一部分是工具，機器的環境變得複雜以後，我們對工具穩定性就有更高要求，比如你要考慮到有些機器的 ssh 會 hang 住，還有某些機器 yumdb 是壞的，不能想當然的以為一條指令下去一定會執行成功。
<b>其次是多機房多地域</b>
幾千公裡距離會有幾十毫秒的延時增加，大家在布置異地多機房應用的時候，要考慮到應用之間的逾時設定是不是合理，需要重新 review 尤其針對多次往返的請求，累加效應是非常明顯的。還有一塊是資源不均衡，可能那個叢集早上忙一點，那邊是下午忙一點，但是因為計算任務依賴下面大規模底層資料，是以你不可能利用長傳帶寬直接來進行直讀直寫的計算，是以要考慮應用的合理布局。
<b>自動化平台建設</b>
關于自動化平台建設，自動化的意義我想讀者們應該是有共識的
第一自動化能夠提升穩定性，機器的操作比人要靠譜，固化的操作交給機器去做，可以減少人犯錯機會，提高線上穩定性。
第二自動化能夠提高效率，機器代替人做很多事情之後，把我們從日常繁瑣運維操作中解放出來，解放出來以後我們可以做更有價值和意義的事情。
今天因為時間關系，我會從以下四個最常見自動化方向做簡單舉例介紹，變更、問題排查、硬體維修，傳遞檢查。右邊是我們内部用的運維平台架構簡圖，下面介紹的東西都是基于這個平台的功能子產品。
<b>3.1 第一步：實作自動變更</b>
說到變更，做運維的總是有很多共同語言要聊。變更在我們日常工作中占的時間還是比較多的，包括變更方案整理，變更跟進執行，都是比較耗時的，另外變更也是非常危險的。原來有過統計，号稱70%穩定性事件是跟變更相關的，有可能是運維工程師直接變更操作引起的，也有可能是上線代碼有 bug 引入的，這兩類都歸結在一起，反正是“線上不作不死，一作就死”。但是不能因為這個不釋出，還有很多功能開發也是跟我們一樣，天天加班熬夜，搞出來的代碼不給他推上去也說不過去，還要滿足業務需求，那這個問題得解。怎麼解呢？
我們内部思路是首先會把最底層的一些操作進行原子抽象，比如像把一台機器從 vip 裡摘取出來，裝一些包進行固化，固化之後抽象出來，稱為工作流，然後把工作流進行組裝把它稱之為組合工作流。一個組合工作流對應一種日常的固化變更類型，比如控制叢集服務更新等等，這樣固化的變更就可以由對應的組合工作流去做。在組合工作流之上，還會有一層封裝需求單。主要解決開發的自助申請，審批等環節。在工作流執行頁面可以檢視詳情，包括對應的每個步驟具體指令，傳回資訊，執行逾時時間，逾時或者失敗的通知方式和人等等。通過這樣一套平台，基本上能夠解決日常固化的那一類變更請求，能夠做到變更由開發自己申請發起，運維隻需稽核一些參數、測試報告等等。
<b>3.2 第二步：高效穩定的解決問題</b>
第二個例子是關于問題排查的，上圖畫的是我們目前用的實時日志分析系統的架構，阿裡因為這塊的産品自研的都有，是以用的都是自研的産品。為了便于了解，我在邊上備注了對應的開源産品，基本上的流程或者邏輯也是比較好了解的，首先在伺服器上部署 agent，agent 會依據日志服務裡配置的規則進行過濾以後，将對應的資訊推送到日志服務。日志服務裡資料可以實時進入到流計算平台進行實時分析計算，并且把結果存到 rds 裡面，然後 tesla 通過 rds 進行調取和展現。另外日志服務存的資料，也會通過實時建立索引，提供 web 級别日志查詢，幫助使用者做日志查詢。同時也會導入 max compute 做永久存儲和進一步分析。
基于這套系統，我們舉一個例子：異常流量排查。流量打滿是很常見的問題，通過這樣的機制怎麼幫忙我們排查和定位這些問題呢？比如有n個機房，機房與機房之間有很多鍊路，每一條鍊路帶寬都是有限的，有時一個突發流量尖峰過來會導緻流量擁塞，假設平台上有一條鍊路，流量打滿以後，呈現黃色預警狀态，通過點選這條鍊路，就會進入流量分析實時界面。
這裡可以看到從某個時間段到某個時間段，從某個機房到另外一個機房最近十分鐘的情況，這裡顯示的是最近十分鐘對應作業流量總的情況，點選流量最高的點可以在右側看到每個作業對于流量貢獻情況及其最近10分鐘的變化趨勢。下面還可以列出來這些作業具體的項目歸屬，作業名稱等等。通過這個機制就可以很快定位到問題的原因。這裡收集的日志是阿裡雲飛天盤古 master audit log，盤古 master 有點類似 hadoop 裡的 name node 節點，它會記錄所有叢集發起的資料通路請求，包括來源 ip 是什麼，擷取資料大小是多少，發起的作業名稱等。把這些資訊通過前面介紹的實時架構收集完之後，放到流計算平台算，然後再結合網絡地域和 ip 歸屬，就可以畫出整個網絡拓撲和實時流量圖。
基于這套平台還可以做很多其他的事情，比如說網絡靜默丢包，這個理論上來講在網絡層很難做到監控。但可以通過收集作業執行日志，分析長尾和失敗的作業相應的源ip及目的ip分布情況，可以發現某些交換機的異常情況。做到先進行隔離，再讓網工去排查解決。
<b>3.3 第三步：更高效的硬體維護</b>
第三步是硬體維修，我們内部有個硬體全生命周期管理工具稱之為是 dam，在日常工作中它能夠涵蓋整個硬體循環的生命周期，上線以後如果發現線上有硬體問題，它會調應用自定義的下線接口，把這台機器從具體應用裡摘出來，從應用層面隔離完之後，再去調機房維修自動接口進行報修。報修以後會監測這個維修單子狀态，等維修結單後，自動做上線前硬體檢查，檢查通過以後會把這個工單關閉，同時調用應用自定義的上線接口，完成伺服器上線。是以這套東西基本上跟應用是屬于松耦合的，隻要應用提供滿足條件的上下線 api 接口，基本上都可以轉起來。
這是它的一個架構簡圖，主要有三大子產品：dam worker 、dam client、dam center.這裡面主要難點還是在于硬體資訊收集和分析，怎麼判斷這塊磁盤壞了，怎麼判斷 cpu 是有問題的。這其中需要長期的資料和經驗積累。這裡我可以簡單介紹一下我們現在采集的資訊源：
硬碟主要依賴于 kernel log/smartctl/tsar
記憶體是 ipmitool/mcelog/stream，
cpu/風扇是 mcelog/cpu 頻率/ipmitool，
網絡/網卡/交換機端口是tsar/kernel log。
主機闆方面如果我們分析以後都不是以上資訊，那可能就是主機闆的原因。
上面這個圖是一個最終的效果，這個系統在規模化場景下還是非常有用的，以前沒有這個的時候，值班人員是比較痛苦的，因為我們知道現在網際網路用的機器都不是高可靠的，去 ioe 都差不多了，都是廉價的伺服器，是以出現一些硬體問題還是比較常見的。很可能一個電話過來，客戶就開始抱怨作業又長尾了，你上去一看，這個機器硬碟有問題，加入黑名單，重跑一下，使用者和我們自己都搞得很痛苦。現在我們就不會因為單台機器的硬體問題而受到騷擾了。主要白天看看那些異常工單原因，不斷優化邏輯即可。
對于這類自動處理我們肯定采取比較保守的政策，任何系統拿不準的或者不是完全精準比對的就不動，先做隔離而不做進一步自動處理，放到異常工單池子裡，由人工介入分析異常 case 什麼原因，不斷完善我們硬體檢測判斷的模型。
<b>3.4 第四步：完善的傳遞檢查</b>
傳遞檢查分為軟體傳遞檢查和硬體傳遞檢查，軟體傳遞檢查就是用前面介紹過的工作流，硬體傳遞檢查主要針對 cpu、記憶體和磁盤，對于 cpu 做法是綁定每個 cpu 算 π，算算它的消耗時間分布，最終把曲線畫出來，标準就是看曲線的偏離程度。
其實大家可以看出，大部分還是很規矩的，會集中在一起，類似上面有幾條偏離曲線的就是我們認為有問題的。那麼這裡大家可能會問，為什麼你這裡集中在兩個區段，是不是有一半的機器都是有問題的，其實是因為這個叢集機器是異構的，本來就有兩種類型的 cpu。記憶體壓測采用通用的 stream 方法，就是對記憶體做拷貝、讀取相加，讀取做乘法諸如此類的，對于性能名額明顯偏離的機器也是有問題的。磁盤主要用 linux fio 指令按照不同的讀寫比例和塊大小，來看它的表現。
其實這裡并沒有用到什麼高深的技術，我之是以拿來說是告訴大家這個極其重要，尤其是對于離線場景。離線計算在公司裡一般給的是都是更廉價，更低成本的硬體裝置，甚至很多時候線上應用退役的機器也會拿來用，即所謂的利舊。這種時候再加上機器是經過搬遷的話，那硬體的壓測就必須做，否則線上會很長時間不得消停。
下面我們講講資料驅動精細化運維，今天主要是講一些點，舉一些例子，以此來表達我的一些想法。
大家都知道資料是有很大價值的，我們通過曆史資料分析，能夠知道平台過去是發生過的事情，對于現在的資料分析，可以知道平台現在正在發生的事情，還可以通過模組化預測未來可能會發生的事情，是以資料可以說是能夠通曉過去未來之事。
我們運維的大資料平台上每天都在産生海量的各種運維日志、資訊，我們手裡擁有線上、離線，各種大資料平台，我們也想把運維做得更精細化一些，可以說是有資料，有需求，有平台，正可謂天時、地利、人和，是以一直在這方面做些嘗試。
<b>4.1 實時大屏背後的精細化運維實踐</b>
第一個例子是關于雙十一大促的，這個屏相信大家不會太陌生，這是雙十一大促在深圳晚會現場直播的一個媒體屏，上面有雙十一大促最終定格的成交額 1207億。
這是一個 gmv 翻牌器，它的作用就是實時彙總目前每一筆成交，并且把成交額顯示在上面，在光鮮亮麗的媒體屏背後，其實我們還有很多保障用的技術屏，今天就帶大家一起來看看其中的一塊技術屏。
這上面的數字都抹掉了，簡單介紹一下我想說的事情，左邊部分是用于承載翻牌器成交額實時計算作業主備叢集負載情況，在它的右邊顯示的就是幾個關鍵的核心作業目前實時的延時情況，機關是毫秒。這裡最右邊的這幾個白色的數字，代表了每個作業對應的延時，有了這個之後我們才能知道目前算的成交額比真實的使用者下單時間，它的延時有多大，超過一定的量，我們就要進行鍊路切換。是以有了這個數字以後，可以更好地幫助我們判斷現在哪條鍊路是好的，哪條鍊路不好的，不好到什麼程度，好的話什麼程度，不能盲目的去拍腦袋判斷，需要有實時化的量化名額做評判。
這裡還要強調說明一點，這裡用不同的顔色深淺分成三段，這三段分别代表這個作業它的日志采集延時、消息隊列讀取延時和讀到之後計算的延時，把三段延時進行了分開展現，這個有什麼用呢？當鍊路有問題之後，我們可以知道哪段出的問題，因為實時計算整個鍊路是非常長的，對于秒級應用來講，每個環節消耗的時間都是需要被清晰度量的，也就是說，有了這個時間你才能準确判斷現在是因為哪裡出現的瓶頸導緻整體延時不達标。也就是說，不但能夠知道哪條鍊路有問題，還可以知道鍊路具體問題點在哪，加快問題定位。是以對于這個核心名額我建議大家做到三化：
量化，這些壓力值都可以清晰看到。
細化，每個名額再分細一點，可以更精準判斷和定位問題。
持久化，這些實時屏不能看完就算了，還要把資料存起來，非常有用。
是以做到三化，量化、細化、持久化，在核心名額量化分析裡是很重要的。
<b>4.2 存儲分析在精細化運維中的實踐</b>
下面講一個存儲分析的例子，這個例子起源是因為叢集規模太大了，每年都被老闆盯着能不能省出一點錢來，我們分析了下存儲的資料，看看每個 byte 是被什麼占用了，這是可以分析的。
我們通過分析之後得到右邊的圖，這個是真實的圖。看了這個圖之後，你會注意到，原來存儲是這麼被消耗的。其中我們可以找到一些應用層的優化。譬如平台是分層的，每一層為了資料安全都會做自己的資源回收筒（延遲删除）功能，站在每一層獨立去看都是合理的，但各種資源回收筒累加在一起就會發現資源回收筒占用比例有些高（尤其是對于頻繁删除類型應用）。可以從整體運維的角度去看，對于各層資源回收筒政策做評估。另外我們還發現一個優化點，就是 inode。我們可以計算下看看我們要不要用到這麼多 inode，按照ppt公式計算可能隻需要原來的1.75%就夠了，萬台叢集可以是以省下6pb的存儲。當然這裡面實際适用 inode 大小還是要根據自己應用場景去評估。大家經常做資料營運，資料分析，其實它在很多地方都在那兒等着大家，有很多點可以去做，包括我們日常忽略的，司空見慣的，覺得不值一提的地方，大家可以細究一下，會發現那裡有另外一番天地。
<b>4.3 精細化運維在資源優化上的成果</b>
還有一個是資源優化例子，大家知道資源排程器裡有一個使用者資源申請的值，和申請之後真正跑起來的實際消耗值，我們建立了一個使用者實際消耗和使用者資源申請的比例，理想值我們希望接近100%，這個名額能夠說明排程模型的資源使用狀态，有了這樣的衡量名額之後，我們做進一步細化分解，看看怎麼優化這個名額。
這個是實時計算裡面作業的情況，每個作業我們會去看它的資源使用趨勢，這上面紅色的兩條直線是作業裡設的申請值，下面藍色波動比較大的是這一周來資源使用的尖峰值，大家可以看到即使按照這一周作業使用實體資源峰值來看，離申請值也是很遠的。是以這裡面還是有不少優化的事情可以做，包括提醒使用者自己做優化，也可以在平台層面自動做優化，來達到節省成本的目的。因為一旦排程器認為可以申請的資源都配置設定出去了，哪怕這時平台實體水位非常低，它也不會排程更多的作業了，是以這件事情也是我們可以深度去做的。
<b>5.1 轉向營運或許是破解之道</b>
我個人對于運維轉型的一些了解和思考。運維轉型最近被談的比較多，有一個論調就是運維向營運轉。
這個問題我是這麼看的，傳統運維更多關注的是平台穩定、安全，也就是非常傳統的兩個領域，更多關心的是平台是不是活着，這個平台沒有出問題，沒有挂掉，這是傳統運維關心的事情，重點關鍵詞活着。對于營運來說，除了活着，還要看平台品質怎麼樣，使用者用得好不好，這個平台本身它的效益怎麼樣，它的成本是不是還能進一步優化，使用者感受怎麼樣，使用者滿意度怎麼樣。而對運維來講，包括營運，我們大部分都是跟垂直的具體産品或者平台綁定的。不可能完全脫離他們，去談運維的價值。是以營運是以一種更積極開放的态度，去看待我們所運維的對象，多看一點，不光看它的活着，還想想怎麼能夠幫助它和自己一起去成長和發展。
<b>5.2 自動化在轉型過程中的四個階段</b>
然後講到轉型逃不開自動化，我個人認為自動化可以分為四個階段：
<b>第一個階段人肉時代</b>--這時候人就是一切，你說了算，你說什麼指令就是什麼指令，這時候沒有任何校驗标準機制，就像交警純人肉指揮交通一樣，什麼時候讓你走就走，什麼時候讓你停你就停。
<b>第二階段工具時代</b>--好比交警手裡的指揮棒和哨子，這些工具提升了他的個人能力，比如哨子可以讓更遠的車輛聽到他的指令，棒子可以在天氣不好的時候讓汽車看到他的指令。 這個階段還是以我們人為主體，工具在能力上做了一定延伸和拓展，但是始終還是人為主，器為輔。還是人在決定這個操作要不要做，什麼時候做，參數應該是什麼。隻是人做完決定後，可以由工具搞定具體落地執行，提升了執行效率，節約下來了時間。但是離開了人還是什麼也不是。是以這個時代，單兵作戰能力增強了，但是人逐漸成為整個運維的瓶頸點，因為工具的能力是遠遠大于人的能力的，更多需求就堆在你手裡的，你怎麼編排和控制。你成為瓶頸點了，工具越多，人的瓶頸點就會凸顯。
<b>第三個階段平台時代</b>--這個階段過渡到器為主，人為輔的階段，還是以交通舉例，這裡面大家可以看到由很多工具沉澱變成了完整的交通疏導指揮平台，包括紅綠燈，包括限速和車道劃分等等，這一系列規則和工具，最終不是零散的在那裡放着，而是通過一個有序組織變成一個固化的平台，通過這個平台，能夠完成交警日常工作中交通疏導的事情。 對于我們運維也一樣，我們怎麼把我們的經驗、想法和技能放到平台裡，最終變化自助或者自動化運維平台，這樣的時代才能稱之為平台時代，就像我剛才前面說的變更平台一樣。 我不知道大家有沒有經曆過，其實很多公司經曆過，變更平台可能有很多不同的人開發過很多撥，第一撥可能是開發寫的，第二撥可能是工具團隊寫的，第三撥可能是運維團隊自己寫的。 這裡做一個變更平台并不難，難的是怎麼把運維的想法和思考沉澱到平台裡面去，怎麼讓平台有和你相當的能力，這時候它才能代替你日常的職責，是以它這裡面的靈魂和思想很重要。 同樣是做開發變更平台，開發考慮的是怎麼快速高效的執行變更，那運維做的時候會有些什麼更多的思考呢？你會考慮是否有灰階功能，是不是應該先灰階釋出一部分，然後有自動冒煙機制，冒煙過了我再引流，然後有沒有快速復原機制，這就是差別，為什麼我們要自己去做，自己轉型，我覺得别人很難了解我們，也很難救我們，是以要自己轉型做自己想要的運維平台。 這裡面大家多想想你平常怎麼工作的，重要的是把你的能力進行平台化，而不僅僅是簡單開發一個系統。
<b>第四個階段智慧時代</b>-- 第一個時代是人解決問題，第二個時代是人借助工具更好的解決問題，第三個時代是讓平台能像人一樣解決問題，第四個時代是讓平台超越人類能力去解決問題。這張圖是阿裡雲栖大會上王博士釋出城市大腦的照片。城市大腦是解決城市交通擁堵問題，這個問題已經突破人的能力極限，安排多的交警到各路口執勤也搞不定這件事。但城市大腦可以，它通過對每天的車流量預測資料，再加上其他的一些補充資料，包括實時紅綠燈，每個探頭采集到的實時流量等等，把這些資料進行綜合判斷，它就能夠智慧的實時控制所有的交通信号燈，進而達到緩解城市擁堵的目标。在這裡其實一樣的，當上升到一個智慧時代以後，平台能力就能夠突破人的極限，做到一些人的能力以外的事情，譬如故障的預測、快速自恢複等等。這也是未來的方向——智能運維時代。
<b>5.3 運維效率向運維價值轉型</b>
假如我們前面的自動化事情做得不錯了，有時間了，該幹點什麼，原來有一句老話叫做“喝着咖啡幹運維”，我個人認為這個觀點從生活的角度來講是不錯的，但從工作和個人發展的角度來看還是太過于消極了。當你達到這個階段，如果你真這麼去做的話，慢慢你可能有時間喝咖啡，但卻沒錢喝了，很有可能會被淘汰掉。我們應該轉變思路，更多的去關注資料分析，可視化及運維平台的産品化。當我們建立了前面說的自動化運維平台以後，可以更多去想一想如何通過資料分析，讓我們運維平台更加智能，達到一個智慧運維的時代。利用計算機強大的計算能力，最終實作機器管理機器的目标。另一方面也可以借助資料分析和營運，幫助我們所運維的産品做改善，如性能、易用性、成本等等。另外我們也要更多的去思考怎麼把運維平台進一步産品化，使我們的運維能力可以輸出，産生更大的價值。這些目标都是可以實作的，當然有很多的事情需要去做，我們可以分階段的，先從一些簡單的事情做起，逐漸深入。
最後用一張圖來總結我對于運維轉型的思考。運維應該始終以穩定性為基石，一旦脫離穩定性，其他一切都是扯淡，都是浮雲。在穩定性基礎之上，我們應該以更積極的營運思路來思考我們自身的發展和平台的發展，借助于資料分析和運維能力産品化這樣兩個翅膀，實作華麗的轉型。運維的人生不止苟且，還有詩和遠方！