無數據，不工作！運維“數據思維”有多重要？

作者簡介

顧黃亮，十年研發運維經驗，涵蓋基礎架構、應用架構、數據庫、DevOps，有互聯網，電商，金融從業經歷。

專注於 DevOps 在企業中的應用和落地，致力於企業智慧運維體系的打造。參加多個行業、國家標準的編寫，《開源許可證使用指南（2018）》作者之一，國標《研發運營一體化（DevOps）能力成熟度模型》作者之一，《企業IT運維發展白皮書》作者之一，曾供職於航天晨光、上汽集團雲計算中心，現任蘇寧消費金融安全運維部負責人。

前言

在上一篇文章《建立數據指標體系，推動 DevOps 全鏈路度量閉環》中，我們描述了基於數據來建立數據指標體系，通過指標體系達到主觀事件客觀呈現的效果。信通院的一些分析數據表明，企業IT的信息化歷程逐漸完成，同時企業對IT的精益運行的需求越來越迫切，在這個場景下，數據的思維和使用能力成爲制約提升IT生產效率的桎梏。

筆者以爲，企業數字化的範疇放在運維領域，更多的場景還處在數據量化的擴展，因此除了服務輸出和業務連續性能力輸出以外，還有一個重要的場景需要開闢，其中就包括運維的數字信息能力輸出。同時根據《企業IT運維發展白皮書》所述，在數據驅動的基礎上，運維的重要職能已由安全、穩定逐步延展至高效和低成本。在本文中，我們重點以運維的數據思維和數據的場景運用進行展開。

一、運維方式和運維數據的發展歷程

從企業的信息系統規模、複雜程度變化以及運維技術的應用等方面考慮，我們大致可以把運維方式的發展分爲五個階段： 手工運維、流程化運維、自動化運維、DevOps、AIOps 。在這五個階段中，運維的場景輸出能力在不斷的提升，從最初的各類資源的分配控制到容量管理，資源交付到持續部署，被動的問題受理到提前預測問題，乃至到現在已經主動介入用戶體驗和增值服務投入的技術運營場景。

因此運維方式的發展也遵循運維無邊界的思路，“浸潤式”的進入整個IT服務體系，從業務的角度來提升運維價值，提升技術的投入產出比和減少企業成本的壓力。

運維數據根據上述運維方式的發展歷程逐步構建數據生態，如果我們把運維方式的發展濃縮成運維技術提升和工具建設，那與之相對應的，運維數據的發展也有四個階段：自動化運維能力、平臺化運維能力、數據化運維能力、智能化運維能力。

在數據化運維能力中，運維數據已初步形成初步數據生態標準，具備構建運維數據中臺和數據可視化，同時也能對數據的進行血緣能力和影響能力的初步分析。在智能化運維能力中，運維數據已形成較大的規模，因此將運維經驗和大數據、機器學習的技術相結合，開發成一系列智能策略，提升運維數據的輸出能力，讓運維的數據邊界延伸至更多的場景。

二、什麼是運維的“數據思維”

運維方式的發展提升了運維人員的基礎門檻能力，在現在很多的企業中，運維人員的日常離不開數據，運維的過程和結果靠不靠譜，都可以通過數據來驗證。

（1）數據對運維打通業務服務鏈路的價值

數據的價值，在企業數字化實踐過程中處在覈心地位，對於運維來說也亦然。不同的數據對於不同的運維人員價值也不一樣，同樣數據對於不同的運維人員來說價值也不一樣，因此對於運維來說，數據對運維打通業務服務鏈路的價值主要有以下。

在產品的運營階段，快速發現業務問題。公司管理層通過經營指標發現公司運營中的問題，同樣的，運維人員也能通過業務數據發現產品運營中的問題。業務數據的背後是每個用戶行爲的堆砌，如數據有波動，一定是某些節點和步驟不同於往常，需要重點關注。

舉一個簡單的場景，如多個第三方渠道出現訪問量、成功率下降，而系統無故障的情況下，是不是第三方渠道出現問題，還是新上線功能出現bug導致了數據變化，還是某些開關和策略遺漏，因此在產品的運營階段，數據是溝通科技和業務的橋樑。

對於運維來說，監控着力點的前置，有助於更快速的發現業務問題，在業務監控中，數據波動的點是公司運營的問題點，也是運維在工作中的重點。

輔助運維人員做決策。在實際的運維資源輸出工作中，一般會有一些特殊場景是流程無法覆蓋的，如重大活動的資源擴容和緊急情況下的系統降級。在鏈路系統擴容方面存在A系統擴容和B系統擴容，如果有數據支撐能直接證明A系統擴容比B系統擴容方式好，那就採取A系統擴容。可能有人說，爲什麼不用鏈路壓測來決定，在龐大的業務系統鏈路中，涉及外部第三方系統的多級調用，並不一定能夠協調到足夠多的資源，因此只能基於現有的數據支撐進行決策，緊急情況下的系統降級也一樣。

在數據積累過程中，如果數據表現向好的方面發展，要放大這個效應，全面去應用讓數據好轉的措施。如果數據表現向不好的方面發展，快速定位導致數據波動的真正原因，給予解決。不管是運維方向的決策還是運維方案的決策，都能通過數據來指導。

運維成本覆盤和項目的後評價。對於企業來說，每個項目和需求的上線，有且只有一個最合適的指標來評估其結果，因此項目後評價是進行成本覆盤的重要手段。是判斷人力資源、軟硬件資源的投入和產品運營後的產出對比，也是判斷項目或產品的成功與否，更是從較高的視野來進行項目和產品優化的重要手段。

對於運維來說，除了基於容量管理，運維的成本覆盤也是至關重要的一個點。項目上線前的預期收益和項目上線後的階段性實際收益相對比，相關數據可以決定了軟硬件的投入是否形成收益，也能將此類數據作爲業務繼續迭代優化和下線止損的參考。

（2）運維人員的數據觀

無數據，不工作。在進入運維自動化階段，對於運維人員來說，日常工作如果沒有數據作爲參考，工作的方向和思路會造成嚴重的偏差。你所負責的業務線和系統已無法給予你最準確的狀態和及時的反饋。同樣的，資源的管理和分配也因數據的實時性和準確性大打折扣，導致不能高質量的進行交付。因此，對於運維人員來說，要充分使用數據的反饋和支撐。

數據讓一切問題及時暴露。線上bug，第一時間反饋在數據波動上；系統和資源的問題，第一時間體現在監控反饋上；代碼質量，第一時間反饋在持續構建環節；渠道質量不高，第一時間反饋在數據的同比環比上。總之，在業務連續性的問題上，數據讓一切問題及時暴露。

用好數據即可，不必成爲數據的生產者。運維領域集中了公司展業的所有數據，有資源數據、監控數據、業務數據、後臺支撐數據，因此運維人員只需要合理的使用數據，進行運維場景和數據輸出場景相互匹配。大數據工程師負責將業務經營數據進行分析並提供結構化，數據研發工程師負責滿足爲公司各類數據需求方出數，運營人員負責對業務數據給出建議和實時反饋。

而運維人員只需要將運維場景的數據和其他第三方數據進行有機的結合，因此運維人員隨時看數據，並不需要成爲他們，運維服務能力的邊界延伸並不意味運維技術的延伸，運維人員跟需要善於運用現有的數據來獲得想要的結果和反饋。

三、運維人員如何落地“數據思維”

在上一篇文章《建立數據指標體系，推動 DevOps 全鏈路度量閉環》中，我們講到了什麼是數據指標體系，如何進行構建數據指標體系。因此運維人員在落地數據思維中的第一步是形成初步的運維數據的生態，具備數據的輸出場景能力。

（1）具備運維數據生態

通俗點說，運維數據生態是集中了公司展業的所有數據，並讓適配場景的數據進行流動。對於資源管理來說，基於CMDB的數據大致有以下兩類，數據中心數據，包括了機房、機櫃、U位、設備、服務器和配件、系統版本、IP信息。雲管數據，包括了宿主機、虛擬機、容器、系統版本、IP信息、承載系統、負載均衡、系統信息、中間件信息、業務信息。基於系統的數據均來自有業務日誌，包括時間、請求號、系統、接口、方法、耗時、響應碼。基於業務的信息大致有pv、uv、轉化率、成功率、新客人數、利潤等。基於組織架構的信息大致有部門、團隊、人員等。另外還有一些文檔數據，如需求文檔，接口文檔，知識庫。

如下圖所列，具備運維數據的生態基礎需要將上述源數據進行採集、存儲、加工、分析，最終達到應用的效果。

（2）提供數據使用場景

運維的日常場景很多，看似複雜，終究離不開對穩定、安全、高效、低成本四項基本價值的更高追求。通過運維數據化能力，運維能爲企業決策提供有力支撐，實現穩定、安全、效率的提升，和對成本的合理把控。在本文中我們只對常見的場景進行簡單的描述，詳細的場景分析將在下一篇中體現。

知識圖譜，使用統一的語言來定義運維數據，將運維對象通過實體與實體間的關係來表達，整合運維領域內的實體關係形成知識圖譜。運維領域的關係包括但不限於產品、服務、集羣、服務器、網絡、IDC等。

數據中臺，建立面向運維域的數據中臺，統一納管如資源數據、告警數據、性能數據、業務數據、日誌數據、工單數據、指標數據、撥測數據等，面向上層運維分析場景提供統一的數據訪問路由、數據服務目錄、數據接入管理、數據可視化等功能，以期打破“數據孤島”，通過整合關聯和對外開放來深度挖掘運營數據的價值。識別前臺數據需求，整合後臺數據，對數據進行加工和輸出，建立數據中心級的數據服務共享平臺。通過對數據的梳理，數據源的規劃，數據流程的整合，對存量數據進行加工整合，達到以數據服務化的方式來實現數據監控，資源使用率分析。

數據可視化，通過對數據的可視化呈現，幫助運維人員直觀、便捷、快速的進行問題分析，還可提供一系列的工具組件讓運維人員根據自己的業務情況對海量數據進行快速進行視圖編輯、多層下鑽分析、多維度關聯分析、報表編排，橫向縱向大盤數據對比等，將傳統的運維經驗進行數字化轉變，大大提升了問題排查、風險發現和知識沉澱。

下一篇文章中，將進行更高階的場景描述，如無人值守變更、故障自動評估、故障自動預測。

（3）養成每天看數據的習慣

運維人員應具備看數據的好習慣，以筆者爲例，每天最重要的的事是隨時看監控數據，同時兼顧業務數據，同時保持對數據的敏感性。對於數據的表現，不管正常還是異常，都需要跟研發團隊、產品團隊、業務團隊保持溝通，讓大家知曉目前的項目和線上產品的數據表現。這樣做一方面能獲得來自團隊的反饋，有反饋會進一步強化我們看數據的行爲。另一方面也建立自己靠譜的形象，能做到每天看數據、看業務指標，這就是運維人員的靠譜。