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

精彩觀點搶鮮看

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

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

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

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

正文

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

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

我的第一份工作是做系統整合，期間建過網路、建過機房、爬過天花、搬過伺服器，感覺全是各種體育鍛煉，鍛煉出來的身體正好就是幹運維的料子。因為運維首先得有體力搬得起伺服器。

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

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

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

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

都說運維苦，但其實只要幹好了，也可以是非常快樂和有成就感的。為了讓運維都幹得比較快樂。

所以，2015年的時候我們幾個騰訊的同事一同創業，希望把我們的想法和經驗能夠傳遞出來。通過推動和幫助各個企業進行運維平臺的建設，來解放運維的壓力，幫助運維進行轉型，並形成運維技術的企業競爭力。

1、運維的趨勢與挑戰

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

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

但如果出了異常，不管什麼事都會有我們的責任，這就是運維。

為了做好運維，需要關注的事情很多很廣。從能力維度來看，我們需要關注運營產品的質量，效率成本。從產品的生命週期過程來看，我們需要關注釋出前、釋出中和釋出後的整個過程。

其次，從運維服務的發展趨勢來看。很多年前我們經常非常會YY一下，我們在騰訊所做的運維優化和支援是不是可以打包成服務或解決方案去支援商業使用者，當年覺得是異想天開。

但隨著雲端計算的出現，大家可以看到，現在上面已經有很多的服務，其實就運維所做的優化和提供的服務。運維的價值不斷地從內部向外去傳遞。運維能力的建設也越來越受到企業的重視。

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

最早的時候運維只要關注各種底層的東西，如伺服器、網路、交換機等，把安排的事情幹完就可以。

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

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

當平臺建設達到一定的水平之後，就進入到了第三個階段，即資料分析和雲端計算的階段，在目前大資料分析能力快速發展的情況下，資料的價值不斷地被大家發現和有效利用。

運維作為資料的直接管理人，我們可以在資料的層面上去挖掘很多的價值，尤其是在服務優化和成本優化等方面，運維可以通過把有價值的資料實時採集和分析出來，並反饋給研發、產品團隊，來推動產品的不斷優化。

從這個角度來看，這裡有很多的挑戰，比如說雲端計算帶來的一些新技術，對人能力的要求。這些不同的新開源元件，新的技術，新的方法，都會對傳統的運維工作帶來變革的要求。

甚至今天主題提的分散式儲存，分散式架構，各種新的架構方案和技術的流程也對運維工作帶來很多衝擊，這些都是需要我們去面對，去變革的。

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

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

比如，我們以前要求做故障單管理，故障修復完一定要關閉故障單，我故障早都已經恢復完了，但系統總是記錄我忘記結單，處理超時。為了關閉事件單，我就需要浪費額外 的時間去登陸系統，去手工關閉流程。

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

現在大家都講DEVOPS，提研發、測試和運維的協同。以前ITIL講分工，釋出就是運維的責任，現在DEVOPS強調協同，釋出就都讓研發去做了。

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

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

對應這些變革，運維人員的能力要求也有所變化。以前我們搬搬伺服器，寫個指令碼什麼的就可以了。但是隨著技術和管理理念的變化，現在不一樣了，運維也要開始寫程式碼了，JAVA、PYTHON、C++什麼的。

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

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

2、平臺建設理念

剛才提了很多挑戰和趨勢，總的來說，如果我們要去做一個運維平臺，去解決運維遇到的這些問題和挑戰，我們要怎麼做，怎麼樣才能夠把運維的能力通過平臺去不斷地提升？

我這裡給了一些自己的想法，這些也是我們在騰訊這麼些年積累下來的經驗。

首先想講的是平臺建設的理念。很多時候做事情時，事情背後的理念往往會比做事情的方法會更重要，不知道大家認不認同這一點。

技術人員特別容易陷進一個誤區，我要做一個事情，只要關注最新潮的方法和手段，背後的一些背景和因果全部都不管。

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

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

任何公司想要建設它自己的運維平臺都會是一個龐大並複雜的系統工程。這裡面牽涉到方方面面。很多人往往在設計的時候會希望一步到位。

比如，希望要一步到位，希望直接就設計一個能力非常全面的平臺，這個平臺要包含所有需要的功能，要把許可權管理好，要把安全控制住，要把穩定性做高、要把使用者體驗做精。

這種情況下，平臺的建設就會很難，建設的週期也會非常的長，很多情況下專案可能還沒有建設完成，需求就已經變了，專案也就爛尾了。

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

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

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

比如說，如果我們的運維標準化做得較差，我們有10種不同的硬體，每種配置都不一樣，上面作業系統也不一樣，這種情況下我們的平臺就需要做不同系統和環境做相容性，系統實施成本就非常的高了。

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

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

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

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

比如織雲平臺的建設，最早是從打包規範的推廣開始。早期的平臺只是一個簡單的指令碼工具平臺，之後才逐漸補充了一此管理功能，如Web管理，元件管理，包釋出、配置釋出等，最後才逐漸建成面向全業務管理和排程的織雲平臺。

這裡一定是個逐步完善、逐步演進的過程。騰訊也有很多一開始就規劃得很大的專案，現在看起來，基本上這些大專案都死光了。所以，這裡在設計和建設中，大家都要能夠接受或是忍受不完美。

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

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

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

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

當建立了業務標杆之後，後面的業務再去推動就會容易很多了。所以，過程中平臺快速的上線，儘快輸出成效，是非常重要的。

3、平臺建設實踐

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

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

運維的自動化大家可能不太好理解，我舉個簡單的例子。比如我是餐廳老闆，我希望實現炒菜的自動化。那要怎麼實現呢？其實非常簡單：

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

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

對於運維平臺來說，我們通過配置管理能務來收採和管理所有的系統資源，通過狀態管理能力實時的監控資源的執行情況，最後再根據監控的結果來對現多的資源進行變更和排程。

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

在運維平臺的設計實現上。我裡有一張PPT，大家應該經常能夠在老王的演講中看得到。

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

再往上是通用能力層，這一層實際上是把運維所負責的常規服務都實現成為系統能力。 比如運維日常的配置管理、域名管理、檔案管理等。

通過第二層的平臺把運維的工作全部服務化，而這裡服務化的核心就是把日常手工工作都進行系統封裝，變成服務介面。這種服務介面可以供外部的服務或更上層的系統進行呼叫和擴充套件。

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

當這些基礎能力平臺完成後，最後我們可以開始建設各種向向業務場景的精細化管理平臺。比如：

• 我們希望能夠提升產品服務質量，我們可以建設相應的業務可用性分析平臺；
• 我們希望降低產品成本，我們可以建設相應的容量優化平臺；
• 我們希望提升變更效率，我們可以建設相應的裝置擴容排程平臺等等。

從這裡可以看到平臺的分層設計，一定是從去場景化的基礎能力開始向場景化的服務能力延伸，所以我們的系統建設步驟也應該遵循這個規律。

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

4、配置管理平臺介紹

首先說說CMDB配置管理。其實配置管理這個東西非常簡單，不管什麼樣規模的公司，肯定都會有自己的配置管理的系統或是辦法。最簡單的配置管理，它其實就是一個excel文件。

如果複雜一點，我們可以搭建一個數據庫，它一樣也可以實現CMDB的功能。但是如果真正要把這個東西做好，要考慮的問題就比較多了。

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

但就運維所維護的業務來說，這些資訊只有其中的一個很小的一部分，而且它們對業務自動化運維所能夠提供的價值其實是非常低的。因為這些硬體資訊不管管理得再怎麼精細，在具體操作的層面還是需要依賴人來進行操作。

相反，在應用程式的層面，我們可以做的事情就很多。如果能力到位了，我們甚至可以實現故障自愈、自動排程、彈性計算等高階的自動化能力。而這些能力，需要我們的CMDB能夠關注和管理面向業務的配置資訊。

比如說我業務資源是什麼樣的，我的程式是什麼樣的，我的應用是什麼樣的，我的許可權是什麼樣的，我的流程，我的策略是什麼，這些東西是非常有價值的。

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

比如每一臺機器對應的磁碟空間清理策略是什麼，而這些是需要在CMDB中管理起來的。當出現任何異常的時候，我們的自動化系統直接到CMDB裡查詢相應的策略，就可以實時針對不同的業務去實現自動恢復。

除了業務資訊的管理，CMDB設計還需要考慮到資料模型的管理能力，即怎麼樣去支援和實現靈活的資料儲存結構。

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

這種情況下，我們的CMDB就需要考慮到儲存可靈活性和可擴充套件性。我們需要實現可配置、可定義，並支援分級資料模型的配置，這些都是建設CMDB時候考慮的事情。

CMDB這裡最後要講講配置資訊的維護，做過運維的人應該都會有同感，配置資訊的維護是非常討厭這的事情。

騰訊在早期的時候，配置資訊也都是手工維護的，如果我們進行了伺服器的上、下線，事後一定要記得登陸系統去手工更新資訊，不然其他人再進行操作就會出錯。時間久了資訊的失去價值了。

所以我們以前的做法公司會考慮配置準確性，也即一段時間運動一次，人工的去修正資訊。

更好的方法，應該是要去做資訊的自動發現和自動更新。怎麼實現呢？

• 一方面這裡我們可以做CMDB的探針，它直接去採集裝置上的狀態和資訊，實時的上報回CMDB並更新。
• 另一方面可以提供介面和外圍的管理系統對接，當每一次變更結束了以後，都通過介面把變更的資訊實時回寫和更新CMDB，以止實現資訊的自動維護。

5、變更管理平臺介紹

關於變更管理平臺的實現。這裡可以考慮分階段的實現方案。對於一些基礎比較差的團隊來說，要想一步到位是非常困難的，而且如果能力沒有達到一定的水平，有一些自動化能力也不一定可以用得起來。

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

建議先從指令碼平臺開始，先實現最基礎的作業管理能力，之後再實現業務管理和流程管理能力。

作業管理也可以理解為指令碼管理。實現自動化最簡單的辦法，其實就是編寫指令碼。每個公司的運維團隊都一定會有些積累的指令碼。這些都是運維人員最寶貴的資產。

所以在變更管理平臺建設的過程中，我們應該首先考慮把這些資產的價值發揮出來。

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

如果團隊能力更強一點，就可以開始考慮實現業務管理能力。通過指令碼來實現自動化雖然比較簡單，但面對業務管理的場景時，我們就會發現即使是一個簡單的業務，都會需要大量的指令碼才有可能夠把業務的關聯環境維護好。

這種情況下，我們需要考慮整合的業務管理能力，需要把業務通用的維護手段和管理方法封裝成通用的平臺功能：

• 比如業務釋出後的程序守護、日誌清理、啟動初始化；
• 再比如業務本身的版本管理、叢集管理、例項管理、回滾管理等等。

這樣做最大的好處是把業務維護的複雜度封裝在平臺內部，對外只需要關注到一些通和的服務介面即可。

變更管理的第三個階段是流程和排程管理。

當我們把所需要的各種原子操作和業務管理能力都實現之後，那麼我們就可以考慮實現最終的自動化流程和排程管理能力。

比如我們希望實現放牛式的伺服器管理，伺服器掛了可以直接把伺服器殺掉而不影響業務。這時需要流程化的自動管理能力，它不但需要和資源池互動調動新裝置，而且還要和業務管理平臺互動，把業務例項釋出上去。

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

整個複雜的過程不但需要把各種基礎工具和平臺組織起來，還需要根據介面和各個不同的系統進行互動，並根據互動的結果進行工具和後續流程的決策。

分階段的變更管理平臺建設，可以有效的降低平臺建設的啟動成本，並且不同的平臺能力也可以較好的適配企業不同團隊在IT能力發展過程中所處於的不同階段的需求。

6、狀態管理平臺介紹

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

一個好的監控系統需要能夠實現端到端的監控。

目前市面上有很多開源的監控元件，但基本都是單一緯度的監控，比如主機監控或是日誌監控的產品。

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

比如：我們希望關注業務的執行情況，而採用了CPU的監控，它雖然可以發現到CPU的異常。但對於程式有否有BUG就無能為力了。所以一個全面的監控體系一定是需要考慮端到端的監控能力。

每一個系統的終端使用者都一定是人，所以我們可以從使用者的角度，模擬使用者的訪問路徑，從而實現一個全面的端到端監控能力。

我們可以把使用者請求過程中所經過的節點和鏈路全部監控起來。再通過綜合的分析和匯聚，從而有效果的掌握業務的執行狀態，並及時發現異常。

具體實現時，我們可以從最底層的基礎網路和鏈路逐步往上是應用伺服器、應用元件、元件請求、服務質量、到最上層的業務狀態實現全部的監控覆蓋。

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

內部採集方式，我們需要在伺服器上部署監控的的探針，它會根據需要定時的去檢查業務的執行狀態，並收集有價值的日誌資訊。

由於不同業務所需要的採集邏輯和收集的資訊都不一樣，所以監控的探針需要設計成一種外掛化的模式，以便支援不同業務的靈活擴充套件。

對於外部探測的監控模式，一般的實現是在業務生產系統的外部尋找合適的探測節點，如公網上的伺服器或外網CDN上的快取節點。通過這些節點的訪問，我們可以模擬使用者的訪問路徑，並還原使用者的鏈路質量對業務的影響。

對於比較強的團隊來說，我們在建設監控系統時，可以同時考慮整合兩種不同的監控通道能力，並實現監控能力的互補。

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

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

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

1. 我們可以取到告警的資訊，告警裡會告訴我這臺機器的IP地址和告警的值；
2. 通過IP，可以從CMDB中查一下這個機器屬於哪個業務，再根據業務資訊可以查詢到同業務下還有那些機器；
3. 然後我們通過同業務的IP地址把其它機器的當前CPU值都查詢出來，得出的平均值再去和告警的CPU值來對比；
4. 最後判斷出是否需要系統干預。如果需要修復，系統會根據告警的IP地址到CMDB中去查詢相應的恢復策略，再進行處理。

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

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

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

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

我們可以先從標準化開始，通過推動標準化來降低運維繫統的設計和實施複雜度，然後才是具體的系統實現。

• 第一步是配置管理，最簡單的配置管理可以先從搭建一個MySQL開始。
• 之後的變更管理，可以先梳理運維常用的指令碼，形成團隊的指令碼庫或的操作標準。
• 監控能力的建設可以依賴外部的開源元件，也可以通過運維指令碼加CRONTAB來實現。

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

對於運維自動化管理平臺來說，不管具體的實現手段是什麼，只要我們能夠覆蓋之前所介紹的領域，能夠滿足業務的需求，那麼這個平臺就一定會非常的有生命力，非常的有價值。

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

重新定義運維，你怎麼看？

運維發展至今

早已不是刀耕火種的時代

我們不應該仍然是背黑鍋俠，背伺服器俠

運維可以更高逼格、更高價值

運維明天可以更美好！

6大利器，讓重新定義運維不僅是口號。詳情請猛戳如下連結，或點選文末“閱讀原文”：