知識星球
來源：InfoQ
ID：infoqchina
識別運維平臺的邊界在哪兒，才能更好地構建平臺，從而協助運維的日常工作。
在之前的文章中，談到過“運維的本質——視覺化”，在視覺化的篇幅中，著重介紹自動化的視覺化和資料的視覺化；在後續的篇章中又介紹了“網際網路運維的價值體系”，裡面分解了幾個維度：質量、成本、效率、安全等。以上都是為了清楚地梳理運維的內容邊界，基於這個邊界，我們再考慮如何進行平臺支撐。可以說前兩篇文章都是為今天這篇文章作為鋪墊，用理念先行，然後再考慮平臺落地，最後再細化其中每個內容。我更習慣用如下的方式來整體表達運維的工作方法和思路：
首先，價值導向。找到一個價值方向來牽引整個團隊很難，但又必須找到，因這個牽引力就決定了團隊的氣質及後續的工作方法；之前的文章“運維價值體系”有詳述，在此不細談。
其次，要有一個分而治之的系統，最後面向業務自底向上的整合，此時便能幫忙實現更好、更快、更省的交付價值。平臺的建設需遵循一些的方法（自底向上、先後順序等），先建設各個運維專業子系統，透過API的方式對上暴露服務，最後不同的業務平臺去呼叫這些服務介面即可。缺少平臺的支援，運維的質量、成本、效率都會直接受到影響。如果要做好伺服器精細化成本控制，此時需要一個平臺來處理從伺服器資源上採集的資源使用狀態資料，並生成視覺化資料報表，共享到所有團隊中，在一致理解下，去驅動成本最佳化，越海量的業務對這個平臺的要求就越高，從採集、處理、模型演演算法等都有很高的要求。
不要忘了這個平臺還包含面向業務技術棧構建的平臺。這地方有一個非常好的例子，在2012年左右，我瞭解到Google有一個非常強大的資源管理平臺Borg（後面叫Omega），它的設計標的是“把資料中心看成一個晶片”。Google研發人員將開發的服務交給Borg，後續的服務生命週期（擴容、縮容、排程）都由Borg統一接管，服務被Borg部署到哪個IDC、哪個伺服器，研發人員不用關心。後來Twitter根據Borg的思想，也開源實現了一個平臺——Mesos，不過Mesos對LongTime的服務排程（如Nginx）支援不是太好，更適合MapReduce的事務排程。這兩個資源管理平臺背後的思想都值得深究，建議看看。
第三，基於平臺，提供透明服務，確保服務提供者和服務互動者之間的互動越少越好。有了整合性的平臺，透明提供服務也成為可能。平臺整合就是避免服務被碎片化，從而讓使用的使用者看到的不是一個一個工具或者孤立系統，而是面向業務的整合服務。此時成本便可降低、變更的質量也會變成一個穩定態。不同的人、不同的時間執行相同的事務流程都能取得一致的執行結果。
最後，資料驅動。因所有線上業務服務和線下運維服務都有狀態，需資料平臺提供服務狀態資料的採集、處理、分析處理能力，最後還能讓運維人員自定義分析報表。技術運營資料和產品資料的一個很大的區別是，前者在資料挖掘方面的能力要求很少。這個地方有個建議，把線上服務的資料驅動作為重點（80%），把運維內部服務的資料驅動為輔（20%）。因為線上服務的狀態會反作用於運維內部事務的最佳化。比如說從資料中發現現網的服務有一個故障，需要緊急釋出版本，此時就會直接檢驗運維的變更部署流程、平臺的完備性。
在平臺體系部分，我採用逐級構建的方法，不斷去細化其中的內容，因此會有一級檢視和二級檢視，在這個地方，我不敢到三級的模組級別，基本上不可看，下圖是參照的是eTOM模型構建方法。
繼續往下，可以分解出二級檢視。
有了整體的平臺體系檢視，接下來看看每一部分到底是乾什麼的。
工作流引擎、許可權管理。這兩者都是基本的功能，因為其中會涉及流程，所以需要統一的流程引擎平臺。另外需要部門、角色、使用者的許可權管理統一管理，不同業務配置不同系統的使用策略即可，這一塊可以統一實現在單點登陸系統中。
基礎設施物理層。這個視角和傳統樣式有些不同，主要是公有雲的存在。因此在基礎設施物理層這塊，已經把雲端資源當作一個底層基礎設施來看待，後續的資源獲取完全不同，其他的資源物件依然沒有變化，依然是機房、機櫃、網路、伺服器，等等。
配置及服務，把配置當作服務來看待。在ITIL中叫CMDB，Configuration Management Database， CMDB也可以理解成統一的元資料庫，比如說機房資訊、伺服器資訊、人員資訊、服務資訊、業務資訊以及他們之間的物理和業務拓撲關係等，上層的所有系統都應該關聯到CMDB，變更後的資訊必須實時反饋到CMDB中，確保其他系統能同步這份變化。因此大家都把CMDB系統當作運維的核心繫統來對待，便於後續各個系統之間的互通。
在我的經驗中，CMDB建設還是有非常多的坑。如果你把iTop或者oneCMDB的產品當著標桿（都是開源，沒見過商業的），那你的CMDB建設就完了。之前在一家傳統企業，他們把檔案都放到CMDB中管理，不建議這麼做，檔案就是SCM的事情。CMDB建設的核心準則：CMDB管理的資料一定要為了業務管理，業務管理上不需要的東西，就果斷捨棄，比如說檔案，和業務沒有任何關係，就可以不考慮納入，後續會有專門的文章介紹。
ITIL服務——基礎、ITIL服務——高階。在早期的文章中把DevOps和ITIL做了對比，ITIL是面向流程的，這個可以在運維平臺建設中不做重點，不要主動去構建流程，會影響運維的敏捷性。基礎部分實現一個事件和HelpDesk即可，事件管理在告警轉換成事件之後，可以完整地記錄，便於我們事後的原因分析，能挖掘一些問題，比如說是否某個業務、某個人、某類機器經常性故障，那就需要重點關註下。高階服務的部分，大家需關註一下，它是可以帶來價值的，比如說可用性管理、能力管理和連續性管理。可用性直接的導向就是業務的質量；能力管理直接的導向就是成本管理；連續性管理也是和質量慼慼相關，如業務的容災、備份管理等。但這些管理都不要在流程層面上去看，需要在一個平臺中進行全面的視覺化管理。後續的篇章也會有相應的介紹。
基礎設施及服務。把底層運維資源的管理封裝成一個一個的服務，供業務自動化平臺使用。我把DNS、LVS（或者F5）甚至OS上的配置管理都看著基礎設施部分，適當地向上延伸了一下。簡單的劃分原則是，在業務架構之外的，都可當著基礎架構部分了。很多運維團隊的建設重點都在這塊。
架構及服務。把業務架構中的共性需求都剝離出來，抽象成一個一個的服務，最終讓研發只需要關註自己的業務程式碼即可，比如說統一檔案儲存、統一Nosql儲存、統一RDS儲存、統一佇列等。這塊對運維的質量、效率、能力等影響最大，在之前的文章“如何化解研發和產品之間的矛盾”中重點闡述過服務公共化是唯一的解決之道。現實中如果有研發開發了一個公共元件交給運維，而不提供完整的Webadmin或者API的話，你也就可以認為他是在耍流氓，運維必須有嚴格的完整性交付要求。
資料及服務。只要有線上服務在執行，服務資料流經過的一切節點產生的資料，你都要採集、儲存和分析起來，供不同的運維場景使用。比如說自動化排程，可以根據業務涉及的基礎節點資源使用情況，制定對應的自動化排程策略；可以在資料中直接進行故障定位；可以在資料中做安全分析。之前的文章“資料驅動運維”中介紹過我做的一個資料分層體系。
監控及服務，有資料的地方才有監控。脫離這個原則，你做的都是告警，並且告警的成本會越來越大，不成體系。個人觀點：所有的監控檢視都是來源於我們對資料的採集以及我們到底有多少經驗來看待資料。
持續整合。這條線是把一個個的程式包交付到各個環境，在【持續部署】之上的部分可以透過和持續整合工具Jenkins或者Go作對接即可。持續反饋非常重要，一個程式部署到生產環境之後，需要實時的執行報告反饋回來，確認變更的效果。如果持續部署平臺化之後，真正的執行部署工作會不斷前移，甚至可能直接交付給研發。此時的狀態報告，更是有必要，不需要人去登入主機tail日誌看是否正常。這個地方和“資料及服務”的能力關聯很大，沒有前面強大的資料服務能力。
面向業務的運維平臺。不同的業務會有不同的排程策略和服務使用策略，需要在更上層完成面向業務的統一排程，這個是全應用的視角，和持續整合是有一些區別的。在沒有這個平臺之前，一個完整的業務上線，需要做很多操作，比如說DNS變更、LVS變更、OS初始化、自動化測試、持續部署、持續反饋、監控、業務呼叫關係配置，等等。面向業務的排程平臺，就需要有一種排程能力，指揮底層各個平臺為它服務，它本身不實現任何服務介面，是一個服務的整合者。
運維統一門戶。每個運維繫統都有任務或者資訊與自己相關，如果運維人員每天要去面對那麼多的運維繫統，會非常痛苦。在統一門戶裡面分成兩個部分，一部分是任務中心，把底層所有的事務狀態都同步到任務中心中，表示我要做什麼；資訊中心，就是讓運維人平時關註的業務狀態Dashboard直接推送到資訊中心中，表示我要關註什麼。
平臺的標的就是自動化和資料化一切，並且最終視覺化，從而確保質量、效率和成本幾者之間的平衡。但對於這麼一個龐大的複雜體系來說，不可能一蹴而就，可以借鑒一下經驗。
自底向上。一定要把握這個原則，這就相當於我們造車一樣，把各個零件造好了，最後就是組裝。
加強跨團隊之間的合作與溝通。很多事情一旦研發、測試和運維彼此合作，事半功倍。在合作的過程中，把彼此的需求都統一到平臺中，這樣有利於後續的推廣和使用。
平臺建設先後有序，優先順序順序如下：
l P1（最高）：CMDB、基礎架構及服務、資料及服務、監控及服務、持續整合；
l P2（次高）：面向業務的運維平臺；
l P3（低）：ITIL相關、運維統一門戶。
作者簡介
王津銀 07年進入騰訊公司接觸運維，先後在YY和UC參與不同業務形態的運維，對運維有一些理解。極力倡導網際網路價值運維理念，即面向使用者的價值是由自動化平臺交付傳遞，同時由資料化來提煉和衡量。微信公眾號：網際網路運維雜談。
《Linux雲端計算及運維架構師高薪實戰班》2018年07月16日即將開課中，120天衝擊Linux運維年薪30萬，改變速約~~~~
*宣告：推送內容及圖片來源於網路，部分內容會有所改動，版權歸原作者所有，如來源資訊有誤或侵犯權益，請聯絡我們刪除或授權事宜。
– END –
更多Linux好文請點選【閱讀原文】哦
↓↓↓
