前言：

首先，我們先發散一下思維，後收斂。天下武功為快不破，網際網路時代，讓大家可以充分的分享資訊，運維大會這類平臺再早5年的話，在中國做運維不會這麼苦也不會那麼累。

本文、我分享的主題是全棧資源下做自動化。做運維到現在，參加過7*24小時值班，抗過機器，敲過程式碼，也玩過資料庫，這個課題也是在幫我回顧總結這些年的運維經歷苦難後留下的一些思考與總結。

我覺得我沒有遇到運維的好日子，我真正從推板車模式裡走出來，才發現原來大家都是這麼玩的，大家都在玩自動化，都是以這個方法論、方向在玩，都在向 AIdevops 前進。

好的東西大家都會認同，長的帥的，基本帥的差不多。大家都知道美好的運維長什麼樣，但達到這個目標的路線是大家最關心的，我們也正在這條路上。

工程師與科學家的不同在於，工程師專注於這件事情怎麼做，像步兵一樣，一步一個臺階往前進，我接觸的大多是運維“工程師”，戲稱高階小步兵。我喜歡這樣去呼

一、伺服器資源KPI時代

我們迴歸正題。講自動化之前，我先講講我們所處的資源環境及規則。先講一下伺服器KPI。借用三個經典哲學的問題來思考為什麼伺服器資源的KPI不能忽視。

我是誰？我們是哪個行業？我們做運維，我們是IT行業；我們在這個行業當中，我們為什麼站在這個風口浪尖上，為什麼大家這麼關注運維？

我前端時間看到有個朋友圈分享的資訊：“老闆說，你覺得你的公司需要運維嗎？運維經理回答說，過獨木橋的時候，老闆你覺得需要欄杆嗎？獨木橋上沒有欄杆你也可以走過去，但是有欄杆你走的更放心，運維就是一家公司的護航、類似醫生。你造一個航母要有人維護這個航母。”

在這巨大的包含了思想、技術、智慧的靈魂流入IT行業的時候，同樣需要強大的肉身來裝載，肉身在這裡我狹義的定義為基礎硬體，廣義的大家可以理解為運維。伺服器資源作為基礎架構三大元件資源之首，逃脫不了被KPI規則化。

1.1、伺服器資源KPI時代-我是誰

順豐伺服器的增長迅猛增長，2013年伺服器數量到2017年翻了20倍。伺服器增長快到什麼地步，2013順豐機房的兄弟人手不夠，做系統、虛擬化、windows的同事全部前線支援上架。

IT部門目前是納入成本中心，伺服器的每筆採購必須是把背景、技術框架、物理部署架構、上線計劃、容量評估依據等講的清清楚楚，這就需要完整的容量管理體系，在這個體系裡哪些點才是key呢？在這快速增長過程中，我們的人員實際上是沒有翻倍增長的，這些就是運維技術發展帶來的紅利。

我常與我們同事分享一個理念：我們追求運維新技術，重新整理自己的技能不是為了追趕潮流，而是學習多一種新手段，在解決問題的時候會多一種選擇。在這種引導下，現在我們再去給老闆彙報預算的時候，都有資料支撐，我們把所有的從底層自伺服器安裝到OS標準化，到虛擬化模板，到應用、資料庫的配置，及容量效能監控採集資料全部入庫，並可展示。

還有下面一張圖，是摩爾定律的，每26個月電晶體數量翻一番，現在來看摩爾定律遇到最大的問題就是如何解決散熱，如果晶片設計不出現根本性變革，摩爾定律可能被打破。

說到這裡，大家認為伺服器KPI需要設定嗎，怎麼設定？是看使用率、看故障率、看採購價格、根據應用場景看使用率區間？如果使用率設定為KPI，那就是為performance tune埋坑，資料庫、應用優化做的越好，使用率反而更低，不合適。

好的KPI應該是伺服器資源交付快，快到小時級別；硬體故障率低，低到整機千分之5以下；使用率在考慮HA及最優配置及業務高峰後，越接近服務效能極限越好。後面我們來說這些我們的行動路線。

1.2、伺服器資源KPI時代-我從哪裡來

我們從哪裡來？這裡要回到伺服器資源投入到哪個業務上，帶來的預估價值上來。之所以是預估價值，是因為這些涉及太多邊際成本，我們只能狹義的去預估這個業務的價值，同樣從業務到IT投入的價值評估模型建立我們也在進行中。

X86伺服器不像小型機那樣“高貴”，硬體的供應多選擇，所以在選擇的能力上我們要有，怎麼做：建立硬體效能指標體系,看右側的圖就是我們底層用的工具。

明知晶片速度的提升已經達到難以為繼的境界，但是人類對速度的追求卻並沒有絲毫停歇的意思。那怎樣在不燒燬計算機的情況下滿足人類漫無止凌的貪婪呢？

質量上不行，數量上補：多核結構出現。這當中，美國的一個研究室得到一個結論，並不是買機器的時候核數越高越好，伺服器的核數對於OLTP型的應用效能提升最高是在八核的配置下；這些就讓我們知道在選型的時候不會盲目追求核數越多越好，也知道應用遷移的時候，核數的增多帶來的應用效能提升不一定對等。

1.3、伺服器資源KPI時代-將要去哪裡

我有個朋友在一家上市的電子公司工作，他們有全國有6個工廠。IT系統基本靠5臺小型機承載；然後他問我，能不能也搞自動化？我說，你們用的小型機也挺穩定，而且運維共計就三個人，自動化沒有必要做，但可以學習其中有用的理念：精益運維、主動預防。

做運維自動化，很多同事會問你的目標是什麼，投了多少人，產出的如何，實用性如何？資源這塊，我沒辦法解決，但目標我們不能變，不能因為資源影響我們運維人對美好運維生活的嚮往。

只有目標不變，我們才會自發的向這個方向走，當大家嚐到好處，接受的人會越多，公司也就越支援，自然得到的資源就會越多。

首先強調是說，運維開發，為什麼不是開發，它是運維出身的，你程式碼的邏輯都是用運維的思維沉澱下來寫的；

我以前以為外面的和尚會念經，我招了一個，然後我讓他寫個自動化綁IP的API功能，就是VIP的；後來他2、3個小時寫出來了，我看了一下，幾條命令搞定了；我開玩笑說，你瘋了，你入參這個不判斷一下，別人輸入字串呢？掩碼不判斷下，別人輸入的不同網段呢，不限定數字，別人輸入260呢?

所以就是說，做開發的，他會寫程式碼有這個開發能力，但是沒有這個邏輯，根本寫不出來你想要的東西。

這裡有個能力三條邊模型，類似字母“Z”，最下面的這條邊我們可以叫做我們掌握的運維的邏輯規則基線，類似CAP理論、高可用、災難應對、容量管理邏輯、應用日誌輸入規範、安全基線要求等等；最上面的邊，我們可以叫做我們要做的事情或者目標；中間的斜線就是我們要達到目標的路徑或者說的步驟，你會發現能力基線與目標與接近，斜率越小，也約容易。

招一個沒有運維經驗的研發，就好比基線在地底，你要完成運維開發的目標，斜率接近90度，挺難的。

我開始帶團隊只有2個人，現在有18個人，我當時因為去內部新生ITclass分享工作心得，贏得兩位新大學生的青睞，2個研究生分組自願到了我們團隊

來了之後，我說你給我把所有的工單做一下，而且不用太分邊界網路、資料庫，這都要理解其中的原理；我會給他們強調：崗位有邊界，但是技術是沒有邊界的（其實是引用的一位科學家的愛國之言，科學沒有國度，但是科學家有祖國。）之前大家都是寫sh，後面我提要求，所以自動化編碼預設都使用python，這種自覺的推動下，大家的這種基本編碼能力建立起來了。

為什麼在愛因斯坦那個年代那麼容易出偉大的物理學家；挺老一輩講那時的大學老師去講課的時候，都會很謙虛的說，今天講相對論，我還太不懂，大家一起互相交流，相對論提出來的時候全世界懂的只有2.5個人；因為當時做物理研究的人很少。

現在做運維的很多的知識充分的交流，充分的去學習之後，大家已經知道了做的好的是什麼樣，已經知道了藍圖，如何去實現變的有跡可循。走這條路，沒錢沒資源，你有那麼多坑要填，還是負責運維，要交付資源，交付網路，交付各種工單，真做這個事情需要領導認同；給予編制、給予支援、給予容錯、給予嚴厲的價值要求。我很幸運遇到了一個這樣的老闆，他是這條路線的支持者，給予了我們很大的幫助。

二、作業系統的母體效應

講到硬體，我們不得不談談作業系統。

2.1、作業系統母體效應-認識篇

大家目前公司用的作業系統都是什麼版本，版本的選擇依據是什麼，有沒有現在生產上用centos7.4的？大家為什麼更新作業系統，是被迫，還是有這種比較先進的觀念？我覺得我技術很好，就要玩新的東西，這背後的內驅動是什麼？為什麼你更新你的系統版本。

實際上這個問題，是硬體的迭代帶來的一些作業系統版本的變革。作業系統的原理，一致沒有怎麼變，值得大家花些時間去理解一下。

作業系統本身是一個系統，可以通過這個系統瞭解到很多的技術原理及軟體開發的邏輯，可以從底層瞭解一下，什麼叫做很牛的軟體，他的好壞的評判標準是什麼，大家可以看看右下方的公式，大學裡計算機專業的都會學這個。

2.2、作業系統的母體效應-生態篇

同時作業系統衍生出許多輔助工具，例如DNS、NTP、SAR、OSW、YUM、rsync、SSH、pacemaker、ipmi、megecli等等，來共建了自己的生態，作業系統很重要，作為上層的業務運維來說，對於應用來說是透明的，重要的像空氣一樣，大家每天都呼吸

因為它重要的就像空氣，但是你又不能忽視它，我不知道有沒有人被安全基線要求做漏洞檢測，要求打補丁包。

作業系統生態出問題，相當於空氣被汙染，當汙染出現，大家都會有恐慌。所以我們就要把這些淨化工作放到日常工作中，規則迭代中，讓作業系統的生態健康不被汙染。從硬體到作業系統，這一塊每個焊接都是大家需要運維當中的實踐出來的，純粹寫程式碼是不能體會這種生態的。

所以說，其實真正做運維開發最累的是運維，他要把他的邏輯整理成開發需求文件，這個邏輯沉澱的過程，我們的同事可能要脫層皮，思維模式的轉變，及謹慎、全面的溝通是必不可少的。

對於做運維來說是大家都不能忽視的環節，底層的引數配置不合理、不標準，自動化運維是不牢靠的，這個是共識，我們要積極的維新，維持我們的軟體版本、引數配置、人員腦海裡理解的技術規則都是不斷在重新整理的，但這個重新整理的過程是肯定需要控制的，得有個流程、過程，可以看左下這張圖，要考慮相容性、新功能等，快速試點迭代，批量推行。

積極維新帶來什麼好處呢？最右下的圖是因特爾官方網站的一張關於每一代CPU的更替帶來的效能提升圖，每次CPU更替帶來的效能增幅在30%；而每年大概迭代兩次，硬體更替之後你要看看與現有作業系統的相容時間還剩多久，現在的版本是否可以發揮伺服器硬體最大的效能？

所以硬體的更迭推進作業系統版本的更新，作業系統版本的更新又會給資料庫、中介軟體帶來改變，這就是作業系統的母體效應，這就是在做運維開發過程中要考慮進去的場景。

中介軟體、資料庫技術的更新，要站在作業系統的基石上，我覺得IT規模大的公司，公司裡面一定要有一個團隊或者某個人告訴你，現在的應用標準配置是什麼樣的，引數怎麼用，讓整個應用環境是不斷的得到淨化的，不會出現五花八門的版本、軟體，不會有太多汙染帶來病痛。

2.3、作業系統的母體效應-建設篇

所以作業系統的選擇帶來你的生態的改變是非常大的，資料庫、中介軟體結合作業系統運維這個是最佳的方向，做運維開發的時候，開發邏輯從資料庫、中介軟體上層往作業系統沉澱是較容易打通的；我們在做作業系統標準化有很多的初始化程式碼，實際上很多標準需要我們程式碼裡面抽離回來重新寫成文件。

借用作業系統核心態、使用者態的名詞，我這是這麼定義的，我跟我們團隊這樣說，如果你研究的模組你能夠看的懂程式碼並能夠根據需要改寫，那麼你可以把這個模組納入你的“使用者態“；如果你掌控不了，你不知道這個模組底層的邏輯是怎麼實現的，那你就把它標記為核心態。

其實作業系統層面，你研究的東西大有可為，效能現場提取工具osw，我們基本上就改寫了，根據自己需要的資訊重新定義採集項、採集頻率，保持時長，更貼近實際運用，另外基於cgroup我們也在做一些工具，應用與多庫共計一臺主機，某個庫發瘋失控的場景。

例如I/O的任務排程策略有四種Anticipatory、cfq、 noop、 dealine，預設策略是cfq，但mysql資料庫場景下dealine才會是最佳實踐；CPU、MEM的排程演算法同樣要根據場景定義最佳配置。

這些”核心態“的深入，擴大了我們的”使用者態“，讓我們掌握更多的技術武器，來武裝我們的運維部隊，讓大家處理異常情況時不再那麼恐慌。看右圖，仰望星空與腳踏實地，帶這這種心態，我讓我們的團隊一步步向核心態發起探索。

三、全棧資源的建立

我們講一下作業系統上一層，我們講一下我們的資源棧。

3.1、全棧資源的建立-時間成本

我這裡給資源一個狹義的定義，就是開袋即食。

講的資源問題，其中兩個指標，一個是時間，一個是 穩定性。

• 在業務軟體產品迭代這麼快的情況下，時間成本同樣的重要。那麼我們快速的交付一個硬體韌體是達到基線的、相關os層、應用層配置是最佳實踐的、同時監控、cmdb、堡壘機授權這些是配套配置完整的資源，能否達到分鐘級別？部分應用場景，通過KVM、docker平臺我們是可以做到的，這些為我們換來了時間，引用SRE的話來說就是我們有時間去幹更有意義的事情。
• 同步看看右邊的圖，在追求減少時間成本的過程中，我們應該有一套完整的組織方法論來支援我們，避免走錯方向；ITIL是基礎，需要用ITIL這個武器來保障我們的基本運維穩中有序，這樣才有更多“可自由支配的時間”。有時間之後，我們可以做的事情就可多了，有意思的事情就在時間充裕的情況下發生了，我們開動了集中的自動化門戶建設，各專業組實現各自元件的API化。這種從內突破的理念也是在有時間的情況下，大家反思沉澱下來的，並可以親身踐行，因為我們有時間了。

3.2、全棧資源的建立-排兵佈陣

這張圖是我們的排兵佈陣，每種資源形態都是實際業務場景下催生出來的。

公有云確實好用，那好用要加個定語，就是輕量的應用型別，對於大資料量資料庫不一定好用。所以大家可以看看我們的資源有五種形態，這五種形態下我們要同步考慮對接到自動化門戶，光用ansible是搞不定的，要結合IPMI、監控agent，並且把各類資源定義好標籤。

大家可以看看右圖，就是我們整理資源自動化的前行方向。

另外說說，為什麼還有ESX，在於公司確實存在頑固的單點系統，我們的關務報關係統就是單點，並且是頑固的非內部可控的單點系統，ESX的vmotion功能這麼完善，所以我們用它來保障這個系統的穩定性。

那ESX資源的API我們就要搞定，包含運維管理、資源交付的，我們花兩個人力，集中火力，兩個月搞定了，現在ESX的搭建、VM交付已經可以自助，但應用場景、及昂貴的license費用，註定ESX不會成虛擬化的主流；我們的主流是KVM及docker。

下面我們來看看docker，我們的docker已為公司核心應用提供服務，並贏得一致好評。

3.3、全棧資源的建立-docker

docker這一塊，在2016年中我們開始投產使用，具體的技術點大家可以看看，在docker的使用上實際是需要深入與研發同事並肩作戰的，很容易被大家誤解為devops，其實不然，但docker給我們帶來的便利：底層資源足夠的情況下業務系統容量伸縮自如，硬體故障對業務基本透明。

目前我們還是基於Mesos+Marathon架構，我們下一步的工作會引入Kubernetes作為容器管理和編排框架，並在此之上引入Service Mesh作為下一代微服務框架。目前從業內反饋來看Kubernets好用，那麼好的東西大家都會認可，並去採用。

在使用容器遇到的最大的問題就是，Host主機核心bug，導致當一臺伺服器宕機後，容器消亡，但連線不釋放，導致應用的連線數滿。這個問題在我們升級作業系統核心後解決，這裡又回到我們提到的作業系統生態，這些都是相輔相成的。

3.4、全棧資源的建立-KVM

再講講KVM，實際上我在內部叫KVM平臺，它是基於Libvirt做的管理頁面開發，並把我們的容量管理邏輯沉澱進來；KVM的底層思想是在Linux內個的基礎上新增虛擬機器管理模組,重用Linux核心中已經完善的程序排程,記憶體管理,IO管理等部分。

因此KVM並不是一個完整的模擬器,而只是一個提供虛擬化功能的核心外掛,具體的模擬器工作是藉助QEMU來完成的。

在KVM中,一個虛擬機器就是一個傳統的HOST主機上Linux中的執行緒,擁有自己的PID號，也可以被kill系統呼叫直接殺死，相當於虛擬機器”突然斷電”；在一個HOST 上Linux系統中,有多少個VM,就有多少個程序，可以通過字元命令virsh來檢視。

在這裡我們講了一下基本的KVM知識，我們需要對標一下自己在這個平臺上開發的東西有哪些價值，同步vmware在虛擬化在穩定性、功能上業內公認是最好的。那麼我們開發的功能基本上就會向vmware對齊，找到自己的參照物，才會有基本線規則。

談到如何評判虛擬化技術的好壞，這裡有個學術的專有名詞，叫做“指令轉化率”。Vmware宣稱可以做到97%的轉換率，只有3%的損耗，我們實測只有90%，不曉得是否我們哪裡配置不當，目前沒有找到問題點。

但我們實測KVM的轉換率，確實不如vmware，只有80%左右，但這不影響我們採用KVM做我們的主流虛擬機器元件，這個大家應該都懂得。

四、Ansible自動化運維的核心靈魂

講到最後，我們來完整的講講自動化，說到自動化都離不開執行通道的採用什麼元件，chef、saltstack、Puppet。我們用的ansible+agent，下面講講Ansible。

4.1、Ansible自動化運維-概覽

Ansible實際上我們在2014年我們就開始小部分用，那時候我們經常做變更發現我們的機器數量增長太快，如果還是手工做，一晚上也搞不定，我們的同事自發的研究其批量管理工具，發現ansible輕量、好用，大家嚐到甜頭，慢慢的ansible key的配置就成為了資源交付的標準化中的一項了；ansible底盤就這樣無形的被控制了。

到目前為止，ansible的模組已經被我們改的面目全非，但是挺適合我們順豐自己的環境適應。

我們定義十幾個模組，sfsoft、changesudo、changeuser、changepasswd、checkafterreboot、checkbeforereboot、oshealth、osinfo、osservice、linux_sec_check、dbopration、dealwithmultipath、get_log、get_top_file、mid_check、osmount、osvip等等。

對於放開全部的執行許可權，這裡要解決的難題就是如何鑑權，讓對於的運維人員只能執行對於的指令，並在對的伺服器上執行。

4.2、Ansible自動化運維-細看實現

它本身來說， Ansible server是很集中的，本身就是個很大的安全問題存在，如果做好ansible本身server端的安全管控，這個也是個話題。大家可以看看上圖，我們通過7種手段來嚴防死守，把這個安全問題通過其他的手段來彌補掉。

說到缺陷，ansible還有個非常嚴重的缺陷，那就是ansible不能自動發現新搭建伺服器資源的ip。我們是通過監控的agent來做新主機的自動發現的。Ansible的好用大家都知道，我們就不多說，主要來看看它有哪些不足，我們針對性的想辦法對彌補這些不足項。

4.3、Ansible自動化運維-彌補不足

對於有一定技術功底的團隊，技術沒有好壞之分，團隊能掌控的，我認為就是合適的技術。

基於這個態度，我們看的ansible也有挺多的缺陷，當我們要想辦法彌補這些缺陷，讓這些缺陷無關痛癢，這個時候ansible就在這個團隊中生根了，有生命力了。

Ansible server端如何做成分散式？大批量任務下發有任務卡死無法輸出最終結果？如何提高任務執行的併發數？這些都是我們使用過程中遇到的實際問題，把server端做成分散式後，很多問題都不會再是問題。

那這些問題的解決思路我只是參與，真正解決問題的是我們的高階小步兵們，他們才自動化能順利推行的根本。

4.4、Ansible自動化運維-靈魂

這幾年帶團隊給我的核心的感觸，就是技術是以人為本。團隊裡有沒有能抗起事情的人，解決問題的本質是要找對人。

自動化運維的細節，都是靠高階小步兵們一步一步實現的，領導能給的是方向、目標、資源和信任，同樣我們作為高階小步兵不能辜負領導的信任，當這種信任被建立起來，整個組織才能邁入運維自動化的快通道。

這種運維氣質在內心的，形成內驅動，要有改善運維環境志向，我們要把運維做的更精彩。

工作要出業績，需要一支專業性強、目標很清晰的團隊，同時領導的嚴格要求也是有助團隊成長的，用嚴格的要求去善待我們的隊友。專業性是被逼出來的，目標是否清晰是指揮官的責任，所以指揮官不能太多，如果多位指揮官，需要目標一致。

絕大多數的運維人，都是高階小步兵，用我們整齊劃一的步伐推動運維行業走向美好的明天。

上面都發散的很厲害，結尾我收斂一下：技術以人為本，找對人、招對人，善待隊友，讓團隊形成一股匠心力，把運維做成美好的行業，讓運維在前行中更精彩。

作者：

陳天宇
順豐科技系統技術管理部負責人，07年參加工作，先後任職於中國電信、平安科技、順豐科技，專注運維領域10年，從公務員到運維工程師，再到高階小步兵，一路堅守用技術解決問題的理念。目前任職於順豐科技，負責作業系統相關的技術管理工作。

原文來自微信公眾號：高效運維