如烹小蝦： 運維自動化閉環，騰訊是這樣作的

本文是數人云深圳技術分享課上優維科技聯合創始人彭鯉航的演講實錄，演講主題是《運維自動化實踐》。

精彩觀點搶鮮看

實現運維自動化閉環，最主要就是配置管理、狀態管理和變動管理能力。

治大國如烹小蝦，咱們來類比餐廳老闆，看如何實現炒菜的自動化：

• 首先，我要知道個人廚房裏到底有些什麼東西是可用的，好比備了哪些菜，有那些工具，這些就是配置管理。

• 此外，我要讓系統幫我去作菜，是炒、是燉仍是煮？是加水、加油仍是加火，這些都是變動管理的能力。

• 最後，系統還須要可以知道我炒的菜目前是一個什麼樣的狀況，有幾分熟，溫度有沒有過高，油是否是太少什麼的。這些就是狀態管理的能力。

無論是什麼樣的自動化系統，實現本質就是這三個能力的閉環。

正文

我結合本身在運維方面的一些工做經驗，介紹一下怎麼樣去設計和建設一套完整的運維繫統以便支持分佈式架構的系統。

首先簡單自我介紹下，本人從事運維相關的工做有很長一段時間了，應該有十幾年了吧。

個人第一份工做是作系統集成，期間建過網絡、建過機房、爬過天花、搬過服務器，感受全是各類體育鍛煉，鍛煉出來的身體正好就是幹運維的料子。由於運維首先得有體力搬得起服務器。

印象中我搬過最重的服務器是 IBM的RS6000，應該有個幾百斤吧，一我的根本扛不動，四我的搬都很是吃力。我原來身體好的時候能作一百多個俯臥撐，自從不搬服務器了，如今估計30個都作不動了。

2006我加入了騰訊，騰訊企業文化很好，常常會有不少小組活動、部門活動什麼的，可是作運維很苦。常常在外面玩得時候，人剛到電話就過來了。

有一段時間我專門負責值班優化，承包了全部的告警處理，那時候天天晚上要起來四五次處理故障，一個故障最少也要搞個半個多小時到一個小時，當時一直以爲這事只熬過來別的事情就應該都是小菜一碟了。

雖然當我有小孩以後，才發現原來還有比干運維更辛苦的事情的。

都說運維苦，但其實只要幹好了，也能夠是很是快樂和有成就感的。爲了讓運維都幹得比較快樂。

因此，2015年的時候咱們幾個騰訊的同事一同創業，但願把咱們的想法和經驗可以傳遞出來。經過推進和幫助各個企業進行運維平臺的建設，來解放運維的壓力，幫助運維進行轉型，並造成運維技術的企業競爭力。

一、運維的趨勢與挑戰

先說說目前的運維的一些變化。

首先，從運維的職能來看。只要幹好一件事就能夠，那就是讓咱們管的機器，或者業務可以一直正常運行，只要它不故障，基本就沒有運維的事了。

但若是出了異常，無論什麼事都會有咱們的責任，這就是運維。

爲了作好運維，須要關注的事情不少很廣。從能力維度來看，咱們須要關注運營產品的質量，效率成本。從產品的生命週期過程來看，咱們須要關注發佈前、發佈中和發佈後的整個過程。

其次，從運維服務的發展趨勢來看。不少年前咱們常常很是會YY一下，咱們在騰訊所作的運維優化和支持是否是能夠打包成服務或解決方案去支持商業用戶，當年以爲是異想天開。

但隨着雲計算的出現，你們能夠看到，如今上面已經有不少的服務，其實就運維所作的優化和提供的服務。運維的價值不斷地從內部向外去傳遞。運維能力的建設也愈來愈受到企業的重視。

最後，來看看運維能力的發展趨勢。這裏我列出了騰訊互聯網運維團隊所經歷的三個階段。

最先的時候運維只要關注各類底層的東西，如服務器、網絡、交換機等，把安排的事情幹完就能夠。

但隨着你業務規模作大，須要作的事情就沒那麼簡單，不但要把事情作了，還得作得快，作得好，這就須要有能力平臺的積累。

經過運維平臺，一方面是把咱們好的、正確的經驗積累下來，二是可以經過平臺把咱們的工做變得更可靠、更高效。

當平臺建設達到必定的水平以後，就進入到了第三個階段，即數據分析和雲計算的階段，在目前大數據分析能力快速發展的狀況下，數據的價值不斷地被你們發現和有效利用。

運維做爲數據的直接管理人，咱們能夠在數據的層面上去挖掘不少的價值，尤爲是在服務優化和成本優化等方面，運維能夠經過把有價值的數據實時採集和分析出來，並反饋給研發、產品團隊，來推進產品的不斷優化。

從這個角度來看，這裏有不少的挑戰，好比說雲計算帶來的一些新技術，對人能力的要求。這些不一樣的新開源組件，新的技術，新的方法，都會對傳統的運維工做帶來變革的要求。

甚至今天主題提的分佈式存儲，分佈式架構，各類新的架構方案和技術的流程也對運維工做帶來不少衝擊，這些都是須要咱們去面對，去變革的。

舉個例子，我剛到騰訊的時候，騰訊有一個很奇怪的面試官，叫通道委員會。他反覆問我什麼是ITIL，那個時候徹底不懂，你們作運維的應該沒有人不熟悉這個東西了。之前流行經過ITIL，經過流程的理念來管理IT系統。

這東西雖然有用，但運維來講很是的煩人，它會設定沒多的門檻和流程，其實這裏面不少是不科學的。

好比，咱們之前要求作故障單管理，故障修復完必定要關閉故障單，我故障早都已經恢復完了，但系統老是記錄我忘記結單，處理超時。爲了關閉事件單，我就須要浪費額外 的時間去登錄系統，去手工關閉流程。

這種時間上的浪費，當你維護的系統變大的時候，效率的損失就邊得很可怕了。因此ITIL的管理理念如今已經不流行了。

如今你們都講DEVOPS，提研發、測試和運維的協同。之前ITIL講分工，發佈就是運維的責任，如今DEVOPS強調協同，發佈就都讓研發去作了。

這樣很合理，由於程序發佈這事你讓運維去負責，其實大部分狀況下出了問題運維根本識別不出來，你說別人寫的代碼到底有沒有問題我怎麼知道，真出了問題，耽誤了時間，最後事情仍是得交由開發來定位和處理。

而DEVOPS重視的就是高效，整個團隊協同去處理這個事情，什麼樣的模式或什麼樣的人去作這個事情會變得更高效，誰就是第一責任人，咱們就讓他去負責，這樣團隊的流轉就更高效和科學了。這是理念上的一些變革。

對應這些變革，運維人員的能力要求也有所變化。之前咱們搬搬服務器，寫個腳本什麼的就能夠了。可是隨着技術和管理理念的變化，如今不同了，運維也要開始寫代碼了，JAVA、PYTHON、C++什麼的。

運維在公司的角色定位也不太同樣了，之前就只是任務實施，如今慢慢朝平臺建設，甚至朝運營分析方向轉變。咱們不但要有能力寫代碼還得有能力和研發一塊兒討論架構，和產品進行運營溝通。

真要想把運維作好，你要學的東西太多了。對於各類新技術的學習、應用和融合，若是說每一個公司或每一個運維都要去重頭開始琢磨，那成本會很是大，對人的要求也會很是高。

二、平臺建設理念

剛纔提了不少挑戰和趨勢，總的來講，若是咱們要去作一個運維平臺，去解決運維遇到的這些問題和挑戰，咱們要怎麼作，怎麼樣纔可以把運維的能力經過平臺去不斷地提高？

我這裏給了一些本身的想法，這些也是咱們在騰訊這麼些年積累下來的經驗。

首先想講的是平臺建設的理念。不少時候作事情時，事情背後的理念每每會比作事情的方法會更重要，不知道你們認不認同這一點。

技術人員特別容易陷進一個誤區，我要作一個事情，只要關注最新潮的方法和手段，背後的一些背景和因果所有都無論。

就比方說有些技術人員，他們喜歡用Markdown來寫文檔，但他們就歷來不考慮寫出來的東西商務人員該怎麼使用，結果咱們公司的全部商務也得學用Markdown。在公司內部也許這種妥協是容易的，但放到市場環境下這種妥協就不現實了。

因此我以爲在建設運維平臺以前，有必要先溝通一些成功的經驗和方法輪。

任何公司想要建設它本身的運維平臺都會是一個龐大並複雜的系統工程。這裏面牽涉到方方面面。不少人每每在設計的時候會但願一步到位。

好比，但願要一步到位，但願直接就設計一個能力很是全面的平臺，這個平臺要包含全部須要的功能，要把權限管理好，要把安全控制住，要把穩定性作高、要把用戶體驗作精。

這種狀況下，平臺的建設就會很難，建設的週期也會很是的長，不少狀況下項目可能尚未建設完成，需求就已經變了，項目也就爛尾了。

其實，咱們應該考慮先從0到1，而後再從1作到N。先考慮把核心最迫切的功能功能先快速實現，只有用起來纔是好平臺。簡單的功能能夠先實現，再不斷地慢慢再完善，不斷地豐富它的功能，這樣過程當中的平臺收益纔會最大化。

第二，標準先行。作過運維的人都知道，我要管理的事情很是多，環境會很是複雜。當咱們推行標準化的時候，它帶來的最大好處是下降平臺設計和實現的難度。

標準化能力和系統建設能力是一個翹翹板。咱們在業務架構標準化方面作得好一點，那麼系統建設的複雜度就低一點。

好比說，若是咱們的運維標準化作得較差，咱們有10種不一樣的硬件，每種配置都不同，上面操做系統也不同，這種狀況下咱們的平臺就須要作不一樣系統和環境作兼容性，系統實施成本就很是的高了。

標準化先行，這樣系統的建設複雜度和難度都會相應下降。

第三，快速嘗試。複雜系統的設計和建設都是很是難的，並且對於沒作過的東西，其實不少方面在一開始的時候跟本想不清楚，也想不明白，這種狀況下，應該先簡單一點快速實現DEMO原型，而不是停留在反覆的討論和設計。

只要系統在應用環境中跑一陣子，很快你就會發現問題和找到相應對策的。

第四，接受不完美。騰訊如今自動化運維平臺對外有兩個品牌，織雲和藍鯨，而我恰好在兩個團隊都待過，也都經歷了兩個平臺的建設和成長。

好比織雲平臺的建設，最先是從打包規範的推廣開始。早期的平臺只是一個簡單的腳本工具平臺，以後才逐漸補充了一此管理功能，如Web管理，組件管理，包發佈、配置發佈等，最後才逐漸建成面向全業務管理和調度的織雲平臺。

這裏必定是個逐步完善、逐步演進的過程。騰訊也有不少一開始就規劃得很大的項目，如今看起來，基本上這些大項目都死光了。因此，這裏在設計和建設中，你們都要可以接受或是忍受不完美。

對技術人員來講，這點也許會有點困難吧。記得上次參加GOPS全球運維大會的時候大衆點評的一個講師提到一點頗有道理：

咱們在面對不完美的平臺時，要知道沒有任何一個平臺是完美的，也沒有任何一個技術是完美的。但咱們決策用不用它的時候，能夠評估，若是我用它，它帶來的好處、優勢比缺點更多，那這個平臺和技術就是有價值的。

第五，業務導向。建成的平臺可否發揮做重就看咱們的推廣能力，這裏實際也是有一些技巧的。任何一個新的東西，任何一個新的技術、在推廣的時間其實都會遇到阻力。

就騰訊內部的平臺推廣經驗來看，最有效的手段就是先找一些比較配合的團隊、或是重點的業務，這些團隊和業務相對的資源也比較豐富。當咱們快速完成了這些試點業務的推廣，就可以在公司內部創建業務標杆，並造成影響力和口碑。

當創建了業務標杆以後，後面的業務再去推進就會容易不少了。因此，過程當中平臺快速的上線，儘快輸出成效，是很是重要的。

三、平臺建設實踐

講完方法論，如今回到具體的系統設計和實現。咱們應該如何來設計這個運維平吧呢？做爲一個完整的運維平臺，必定要考慮造成運維管理能力的閉環，並逐步實現自動化。

如何才能實現運維的自動化閉環呢？最主要就是掌握配置管理、狀態管理和變動管理能力。

運維的自動化你們可能不太好理解，我舉個簡單的例子。好比我是餐廳老闆，我但願實現炒菜的自動化。那要怎麼實現呢？其實很是簡單：

首先，我要知道個人廚房裏到底有些什麼東西是可用的，好比備了哪些菜，有那些工具，這些就是配置管理。
此外，我要讓系統幫我去作菜，是炒、是燉仍是煮？是加水、加油仍是加火，這些都是變動管理的能力。
最後，系統還須要可以知道我炒的菜目前是一個什麼樣的狀況，有幾分熟，溫度有沒有過高，油是否是太少什麼的。這些就是狀態管理的能力。

無論是什麼樣的自動化系統，實現本質就是這三個能力的閉環。

對於運維平臺來講，咱們經過配置管理能務來收採和管理全部的系統資源，經過狀態管理能力實時的監控資源的運行狀況，最後再根據監控的結果來對現多的資源進行變動和調度。

能力閉環實現了，自動化能力也就實現了。

在運維平臺的設計實現上。我裏有一張PPT，你們應該常常可以在老王的演講中看獲得。

爲了實現一個完整的平臺能力，咱們須要對整個平臺進行分層設計，最底層是各類硬件和資源的管理平臺，它可以抽象地去管理各類物理資源和邏輯資源，和這些資源自身有關的管理能力也都會放在這一層。

再往上是通用能力層，這一層其實是把運維所負責的常規服務都實現成爲系統能力。 好比運維平常的配置管理、域名管理、文件管理等。

經過第二層的平臺把運維的工做所有服務化，而這裏服務化的核心就是把平常手工工做都進行系統封裝，變成服務接口。這種服務接口能夠供外部的服務或更上層的系統進行調用和擴展。

當運維繫統的服務能力構建成熟，咱們就能夠上更上層構建基礎能力平臺，好比說用於管理交付的持續交付平臺，用於管理服務狀態的智能監控平臺等。

當這些基礎能力平臺完成後，最後咱們能夠開始建設各類向向業務場景的精細化管理平臺。好比：

咱們但願可以提高產品服務質量，咱們能夠建設相應的業務可用性分析平臺；
咱們但願下降產品成本，咱們能夠建設相應的容量優化平臺；
咱們但願提高變動效率，咱們能夠建設相應的設備擴容調度平臺等等。

從這裏能夠看到平臺的分層設計，必定是從去場景化的基礎能力開始向場景化的服務能力延伸，因此咱們的系統建設步驟也應該遵循這個規律。

進一步展開運維平臺的實現，如今讓咱們來看一下每個模塊的重要功能和設計挑戰。

四、配置管理平臺介紹

首先說說CMDB配置管理。其實配置管理這個東西很是簡單，無論什麼樣規模的公司，確定都會有本身的配置管理的系統或是辦法。最簡單的配置管理，它其實就是一個excel文檔。

若是複雜一點，咱們能夠搭建一個數據庫，它同樣也能夠實現CMDB的功能。可是若是真正要把這個東西作好，要考慮的問題就比較多了。

好比說，傳統的ITIL理念是很是重視CMDB的，但它把全部精力都集中在硬件資源的管理，如機房、機櫃、交換機、網絡，這些層面的東西。ITIL下的CMDB會把這些東西管理得很好。

但就運維所維護的業務來講，這些信息只有其中的一個很小的一部分，並且它們對業務自動化運維所可以提供的價值實際上是很是低的。由於這些硬件信息無論管理得再怎麼精細，在具體操做的層面仍是須要依賴人來進行操做。

相反，在應用程序的層面，咱們能夠作的事情就不少。若是能力到位了，咱們甚至能夠實現故障自愈、自動調度、彈性計算等高級的自動化能力。而這些能力，須要咱們的CMDB可以關注和管理面向業務的配置信息。

好比說我業務資源是什麼樣的，個人程序是什麼樣的，個人應用是什麼樣的，個人權限是什麼樣的，個人流程，個人策略是什麼，這些東西是很是有價值的。

只有把這些東西全面管理起來，纔可以真正去驅動整個業務的自動化流程。舉個例子，好比說常規的一些磁盤空間告警，我要想實現故障治癒，首先我得有明確的處理策略。

好比每一臺機器對應的磁盤空間清理策略是什麼，而這些是須要在CMDB中管理起來的。當出現任何異常的時候，咱們的自動化系統直接到CMDB裏查詢相應的策略，就能夠實時針對不一樣的業務去實現自動恢復。

除了業務信息的管理，CMDB設計還須要考慮到數據模型的管理能力，即怎麼樣去支持和實現靈活的數據存儲結構。

咱們要管理的數據不會都象EXCEL同樣簡單，相反在真正的業務環境中，必定會是多層的關聯數據結構。並且這個數據結果也不可能就是一成不變的，它必定會在業務運營的過程當中須要進行動態的調整和修正。

這種狀況下，咱們的CMDB就須要考慮到存儲可靈活性和可擴展性。咱們須要實現可配置、可定義，並支持分級數據模型的配置，這些都是建設CMDB時候考慮的事情。

CMDB這裏最後要講講配置信息的維護，作過運維的人應該都會有同感，配置信息的維護是很是討厭這的事情。

騰訊在早期的時候，配置信息也都是手工維護的，若是咱們進行了服務器的上、下線，過後必定要記得登錄系統去手工更新信息，否則其餘人再進行操做就會出錯。時間久了信息的失去價值了。

因此咱們之前的作法公司會考慮配置準確性，也即一段時間運動一次，人工的去修正信息。

更好的方法，應該是要去作信息的自動發現和自動更新。怎麼實現呢？

一方面這裏咱們能夠作CMDB的探針，它直接去採集設備上的狀態和信息，實時的上報回CMDB並更新。
另外一方面能夠提供接口和外圍的管理系統對接，當每一次變動結束了之後，都經過接口把變動的信息實時回寫和更新CMDB，以止實現信息的自動維護。

五、變動管理平臺介紹

關於變動管理平臺的實現。這裏能夠考慮分階段的實現方案。對於一些基礎比較差的團隊來講，要想一步到位是很是困難的，並且若是能力沒有達到必定的水平，有一些自動化能力也不必定能夠用得起來。

這裏須要建設根據團隊的技術實力，選擇合適的節奏分階段進行建設。

建議先從腳本平臺開始，先實現最基礎的做業管理能力，以後再實現業務管理和流程管理能力。

做業管理也能夠理解爲腳本管理。實現自動化最簡單的辦法，其實就是編寫腳本。每一個公司的運維團隊都必定會有些積累的腳本。這些都是運維人員最寶貴的資產。

因此在變動管理平臺建設的過程當中，咱們應該首先考慮把這些資產的價值發揮出來。

經過實現做業管理平臺，來提供統一的可視化腳本管理能力，它一方面可以經過分享和複用來下降腳本開發的成本，另外一方面也能夠實現集中控制，並保證操做的可靠性。騰訊目前的藍鯨平臺，其實本質上就是一個做業管理平臺。

若是團隊能力更強一點，就能夠開始考慮實現業務管理能力。經過腳原本實現自動化雖然比較簡單，但面對業務管理的場景時，咱們就會發現即便是一個簡單的業務，都會須要大量的腳本纔有可可以把業務的關聯環境維護好。

這種狀況下，咱們須要考慮集成的業務管理能力，須要把業務通用的維護手段和管理方法封裝成通用的平臺功能：

好比業務發佈後的進程守護、日誌清理、啓動初始化；
再好比業務自己的版本管理、集羣管理、實例管理、回滾管理等等。

這樣作最大的好處是把業務維護的複雜度封裝在平臺內部，對外只須要關注到一些通和的服務接口便可。

變動管理的第三個階段是流程和調度管理。

當咱們把所須要的各類原子操做和業務管理能力都實現以後，那麼咱們就能夠考慮實現最終的自動化流程和調度管理能力。

好比咱們但願實現放牛式的服務器管理，服務器掛了能夠直接把服務器殺掉而不影響業務。這時須要流程化的自動管理能力，它不但須要和資源池交互調動新設備，並且還要和業務管理平臺交互，把業務實例發佈上去。

隨即還要調動自動化測試能力，檢測一下新上的服務器是否是好的，並加載灰度上線的邏輯，把服務器慢慢上線到運營環境中去。

整個複雜的過程不但須要把各類基礎工具和平臺組織起來，還須要根據接口和各個不一樣的系統進行交互，並根據交互的結果進行工具和後續流程的決策。

分階段的變動管理平臺建設，能夠有效的下降平臺建設的啓動成本，而且不一樣的平臺能力也能夠較好的適配企業不一樣團隊在IT能力發展過程當中所處於的不一樣階段的需求。

六、狀態管理平臺介紹

對於狀態管理平臺。說得簡單一點就是監控平臺。對運維自動化來講，監控平臺是一個最主要的活動觸發源。若是我不知道業務運行的狀態，不知道業務有沒有異常，那麼自動化也就沒法發揮它應有的價值。

一個好的監控系統須要可以實現端到端的監控。

目前市面上有不少開源的監控組件，但基本都是單一緯度的監控，好比主機監控或是日誌監控的產品。

但真正作過運維的人都應該清楚，現網中出現的不少故障都並無那麼簡單，大部分狀況下，這種單一惟獨的監控都沒有辦法很好的覆蓋業務的監控需求。

好比：咱們但願關注業務的運行狀況，而採用了CPU的監控，它雖然能夠發現到CPU的異常。但對於程序有否有BUG就無能爲力了。因此一個全面的監控體系必定是須要考慮端到端的監控能力。

每個系統的最終用戶都必定是人，因此咱們能夠從用戶的角度，模擬用戶的訪問路徑，從而實現一個全面的端到端監控能力。

咱們能夠把用戶請求過程當中所通過的節點和鏈路所有監控起來。再經過綜合的分析和匯聚，從而有效果的掌握業務的運行狀態，並及時發現異常。

具體實現時，咱們能夠從最底層的基礎網絡和鏈路逐步往上是應用服務器、應用組件、組件請求、服務質量、到最上層的業務狀態實現所有的監控覆蓋。

在監控的通道上，目前有兩種主流的方式。一種是外部的探測，別一種是內部的主要採集和上報。

內部採集方式，咱們須要在服務器上部署監控的的探針，它會根據須要定時的去檢查業務的運行狀態，並收集有價值的日誌信息。

因爲不一樣業務所須要的採集邏輯和收集的信息都不同，因此監控的探針須要設計成一種插件化的模式，以便支持不一樣業務的靈活擴展。

對於外部探測的監控模式，通常的實現是在業務生產系統的外部尋找合適的探測節點，如公網上的服務器或外網CDN上的緩存節點。經過這些節點的訪問，咱們能夠模擬用戶的訪問路徑，並還原用戶的鏈路質量對業務的影響。

對於比較強的團隊來講，咱們在建設監控系統時，能夠同時考慮集成兩種不一樣的監控通道能力，並實現監控能力的互補。

監控能力對於自動平臺來講，最大的價值是可以完成事件的觸發。也即實現從數據發現、分析、定位、到問題解決的閉環。

經過這個閉環咱們能夠構建各類故障的自愈能力。經過及時的發現異常，快速的恢復，可以有效的提高業務的可用性和質量。

舉個實例的例子：當系統發現機器的CPU有異常的時候，須要對 CPU高負載進行故障干預和恢復，這種狀況下我怎麼作？

咱們能夠取到告警的信息，告警裏會告訴我這臺機器的IP地址和告警的值；
經過IP，能夠從CMDB中查一下這個機器屬於哪一個業務，再根據業務信息能夠查詢到同業務下還有那些機器；
而後咱們經過同業務的IP地址把其它機器的當前CPU值都查詢出來，得出的平均值再去和告警的CPU值來對比；
最後判斷出是否須要系統干預。若是須要修復，系統會根據告警的IP地址到CMDB中去查詢相應的恢復策略，再進行處理。

經過這種靈活和完整的驗證處理閉環，咱們就能夠構建出各類可靠的自動故障恢復策略。

最後，讓咱們再來總結一下以前提到一些方法論。

先是標準先行、小步快跑、容忍缺陷、業務導向。

對於複雜的運維繫統，不要貪大求全，關鍵是先構建出配置管理、狀態管理和變動管理的能力閉環。

咱們能夠先從標準化開始，經過推進標準化來下降運維繫統的設計和實施複雜度，而後纔是具體的系統實現。

第一步是配置管理，最簡單的配置管理能夠先從搭建一個MySQL開始。
以後的變動管理，能夠先梳理運維經常使用的腳本，造成團隊的腳本庫或的操做標準。
監控能力的建設能夠依賴外部的開源組件，也能夠經過運維腳本加CRONTAB來實現。

從最簡單的平臺，逐步積累標準化和服務化能力，等你們造成標準化和服務化的意識和習慣了，以後再逐步完善和豐富運維繫統的能力。

對於運維自動化管理平臺來講，無論具體的實現手段是什麼，只要咱們可以覆蓋以前所介紹的領域，可以知足業務的需求，那麼這個平臺就必定會很是的有生命力，很是的有價值。

以上這些就是我對運維自動化平臺建設和經驗和理解，謝謝你們。