業務發展往往驅動着IT運維管理的同步轉型或升級，企業IT部門往往習慣於通過採購服務或管理工具滿足要求。
但我們常常發現，在各類採購活動中，甲乙雙方很容易陷入各自的思維定勢，如乙方樂於強調產品工具的功能優勢、市場競爭差異或性價比，而甲方用戶實際更關心的是平臺工具落地時背後所帶來的各類成本與後續維護，當中存在着結構性偏差。
即使雙方達成合作，充其量是購買了工具能力，而非完整意義上的解決方案，可能在運行一段時間後出現各種不適應，迫使再一次進入新的採購輪迴。
本文結合近年來面向企業在IT運維管理轉型或升級項目的成功經驗，梳理當中關鍵的驅動因素，歸納規劃與選型時關鍵考慮要點，以供大家參考。
IT運維管理升級驅動因素
經驗源於實踐，一線管理團隊在日常工作中的關注點往往以小見大，反映出本質問題。我們與企業單位的IT運維管理團隊交流時，常常聽到各種疑慮，比如：
- 近來新上一套APP和小程序應用，部分服務跑在雲上，每天可能有幾萬用戶訪問，現有的監控工具能管理起來嗎？
- 新業務應用發佈和變更非常頻繁，每週都要耗費大量人力時間在上面，如何改善？
- 現在特別關注大數據分析，經常需要從不同業務系統中抽調數據進行統計，但不同系統取數方法各異，廠商定製接口成本很高，很不靈活，如何解決？
- 新採購一套運維平臺，對原來的工具會不會衝突？原來的管理人員能不能很快上手，要不要再招人來管理？要求什麼水平？
- 現在單位有很多業務由外包廠商管理，新運維平臺怎樣給他們用？分工界面如何？
- 如果業務屬於多層級架構，每個層級都由獨立團隊管理，包括採購、建設和維護，他們使用情況無從得知，有什麼方法可以自動收集上來，統一分析？
- 運維的人一天忙到晚，到底在做什麼，系統出問題怎麼定位排障這麼慢，有沒有方法可以快速看到問題所在？
- 單位有敏感甚至涉密業務，新採購的運維平臺對現有系統有什麼影響，是否滿足安全部門要求，有沒有專業安全評測證明？……
我們發現這些不只是技術問題，更多會涉及到諸如組織分工、流程管理、成本分析，甚至是制度規範等。看似雜亂無章，事實上一件事或決策的驅動往往存在複雜因素。仔細分析，上述問題可以歸納兩大類：
滿足對外的服務要求：
對外服務核心來自於業務，包括新業務系統上線及變更、大數據分析等，關注的是平臺工具的能力，體現在敏捷迭代、用戶體驗、新技術兼容性等。
響應來自內部的管理需要：
對內管理則是圍繞如何有效地整合各類IT活動要素，確保滿足對外服務的效率和質量，要求在組織、制度、流程、工具和安全等各層面進行分析。
IT運維管理升級外在驅動因素
所有IT規劃都來自業務的訴求，包括IT運維管理，脫離業務討論運維管理需求並不現實。用戶鮮少一開始明確自己的運維管理需求，需要持續分析其業務轉型升級特點，評估對應所需的服務或能力，然後才能總結爲具體的運維管理需求。
IT運維管理存在一定共性，但嚴格來講只有在技術層面存在跨行業通用的可能，真正解決方案的落地，勢必要緊緊圍繞行業特點與發展趨勢，深刻剖析，因地制宜，方得要領。
隨着互聯網+潮流發展，很多單位業務模式逐步從內轉外，比如數字化政府、互聯網+醫療。面向公衆的互聯網應用增多，應用系統向移動化、海量化、敏捷化轉變，相較於傳統業務，對可用性、敏捷性、用戶體驗都提出較高要求。以下是一些常見的新業務模式對IT運維管理影響和要求：
01 新業務模式對組織分工的要求
在新業務落地過程中，我們發現僅僅依靠傳統技術管控方式已經無法滿足管理要求。很多信息化部門或團隊過往主要是人、事、資源協調的角色，業務由其他部門或外部廠商管理，實際上兩者存在一定脫離，形成了以資源類型的橫向分工管理模式，比如按網絡、服務器系統、雲與虛擬化、數據庫等維度設立管理崗位。這種模式非常普遍，但其弊端在於，一旦業務出現問題，往往需要多方人員共同排查，難以定位，效率不高。
新業務模式所涉及的技術層次將更加複雜，比如前端放到雲上、使用CDN引流、多種緩存或消息隊列組件並存，導致應用調用鏈條加長、專業性更高，勢必提高對專業人員垂直化管理業務的能力要求。比如用戶訪問，從CDN到反向代理、前端、緩存、中間層、數據庫甚至到服務器與網絡，若要確保用戶體驗流程，則要求實現端到端鏈路監控，並快速利用可視化手段表達，異常時及時知曉問題環節，加快排障效率。
它所需要的並非單純技術手段升級，更多是組織分工與協作模式的適配與優化，需要設立垂直化、全棧式的應用維護角色。反映到運維管理平臺上，也要求能夠靈活適應組織管理模式的轉變，比如按業務維度切割管理、運維工具開發與使用權限分離、細顆粒度授權等。
02 新技術架構對技術水平的要求
新業務系統很大可能引入新型技術架構，比如異構化平臺、開源軟件等，傳統管理工具或人員經驗在短時間內無法跟進，整體管理水平不能滿足要求，短時間內拉齊並不現實。
所以運維管理平臺需要與時俱進，在技術兼容性、開放性、性能容量等方面處於或接近業界前沿，能夠驅動調度各類新工具軟件，避免盲目選型東拼西湊，缺乏體系化。
同時，運維管理平臺應該降低其使用複雜度，降低用戶學習門檻，最大程度屏蔽底層技術，使之騰出更多精力專注在業務邏輯之上，相當於賦予管理員撬動複雜技術的槓桿，使之能夠平滑過渡技術轉型期。
03 快速迭代對自主調度編排能力的要求
新型互聯網業務最大特點之一是快速迭代更新，如醫療機構發佈的APP達到每週發版更新十幾個功能的地步，每次上線都是大量重複性工作與等待，這對於過往的研發和運維團隊都無法想象。他們迫切希望利用平臺提升持續發佈變更的能力，當研發部門發版時，平臺可以自動化部署到生產環境，減少人工審覈與執行工作量。
這背後本質是一種自主調度與編排的思維，它要求並非一個個固化的好工具，而是賦能團隊新能力，一種可以屏蔽底層複雜技術或傳統開發複雜性、並專注於將業務邏輯快速轉化實現（比如WEB頁面化配置）的自定義能力，從而可以應對因不同管理對象、不同動作、不同角色而衍生的無窮運維甚至運營管理場景。
04 業務綜合分析對數據融通處理的要求
大數據分析成爲熱點，但其本質更多在於多維度數據綜合分析，比如跨系統取數統計。很多企業單位一直都在做，只是進入互聯網+、雲計算、AI時代，此類業務需求不斷升級放大，不少單位還專門成立數據治理部門團隊，但面對不同系統，數據存儲或調取標準不一，若按照過往方式，每套系統分別定製接口，勢必成本較高且響應遲緩。
在長期實踐中，我們逐步總結出需要構建一套規範化的數據融通底座，制定統一接口標準，降低接入和調取的成本，同時平臺作爲集散地加強接口調度的安全管控，比如鑑權與審覈，纔是長遠之計。再進一步，平臺還應該支持通用的數據分析能力，兼容不同類型數據或對象、提供主流算法模型以及便捷的展示框架。
IT運維管理升級內在驅動因素
爲了確保對外服務輸出持續穩定，完善的內部管理體系必不可少。運維管理的狹義理解，就是針對各類IT資源對象的運行保障，如：數據中心、雲平臺、虛擬化、系統、數據庫、中間件、應用等，圍繞其生命週期展開部署、操作、監控、分析等日常活動，最終滿足業務或服務輸出需求。
若從這點出發，市面上很多專業化、精細化的運維管理工具確實能很好的滿足要求，可是再好用的工具，在企業單位實際落地時也會出現一些水土不服的現象，像是反映難用、和實際流程脫節等。
借鑑“運維聖經”——ITIL，運維管理同樣是一個寬廣領域課題，絕不僅限於工具平臺，甚至說它只是最後的表達與載體環節。實際上，IT治理決策者還需要從人員組織、制度規範、流程管理以及技術支撐幾個維度進行體系化規劃，它必定是一套自上而下逐步延展的設計過程，如下圖所示：
一套完善的運維管理體系，絕不是將某個工具軟件機械化插到當前業務系統環境中即可實現，事實上它更多作爲管理策略與方法的具體表達與載體，是把管理思路轉化爲具體執行過程的媒介，故而對運維管理平臺提出了多層次要求。
01 需切合組織管理特點
每個企業單位都有獨特的組織架構，尤其在一些政府單位，從國家到省級到地市，同一套業務牽涉到多層級架構管理，且在過往中早已形成分層自治模式，除了統一採購標準外，各層級單位可以自主把握系統設計、部署實施、人員組織、維護運營等，形成較大差異。即使同一層級單位中，也可能分爲單位內部與外包廠商運管分離的狀況。
面對這種人員角色衆多、團隊關係錯綜複雜，運維管理平臺是否可以明確職責分工與邊界？對現有組織架構產生什麼影響？需要多大學習和管理成本，建設、維護、運營需要新增多少人員？對人員技術水平有什麼要求？是否需要獎懲機制，引導用戶更積極使用？……
這些實實在的落地問題，一方面是管理者的制度建設，另一方面反映到運維管理平臺上，要求有足夠可塑性與細緻管理顆粒度，真正切合到組織管理特點。
02 需符合制度規範依據
在很多項目的前期可行性研究與初步設計階段，用戶單位與諮詢設計團隊需要聯手製定貼近其生產環境的制度規範體系，根據該體系對運維管理具體方法、流程乃至平臺工具形成指導依據作用，便於後續工作開展。
運維管理制度的制定，首先爲流程制定提供細化依據，然後流程作爲指導日常運維的主要手段，規範了具體技術操作手段與步驟。對於流程產生的執行記錄，可以重新反饋到制度和流程中，覈對確認IT日常運行是否遵循已建立的制度。如下圖所示：
這對運維管理平臺提出了很多無形的要求，它必定結合人員具體活動才能準確表達，往往間接體現在細節上。平臺至少需要具備完善的執行記錄與溯源分析能力，力求顆粒細、同時跨度廣，爲制度規範和流程執行提供審覈依據與優化基礎。
03 可以對流程進行質量審覈
流程是IT日常工作中最重要的體現環節，是有效協調不同角色組織共同協作、具體化制度規範的手段。事實上很多成功案例中，流程管理工具相較於其他運維工具使用頻率更高。對應地，流程的質量審覈也成爲了運維管理中關鍵組成部分。結合ITIL服務交付與服務支撐的理念，運維管理平臺可以提供以下維度保障：
過程管理：
包括髮布管理、變更管理、問題管理、事件管理、服務檯、知識庫，通過考覈具體過程的關鍵指標，比如不同業務提單數、工單完成數、工單好差評率等，從側面保障服務執行質量。
技術指標：
可以通過平臺或具體業務的技術量化指標衡量，比如服務訪問請求數、請求成功率、請求耗時、每分鐘/秒交易數等。
業務指標：
可以通過更進一步的內容分析進行衡量，比如每次請求的用戶信息、請求地址、返回內容等，嚴格而言這些也並非真正意義上的業務數據，充其量也是側面反映其事務執行質量。
實際上這也是常見的過程管控思路，透過直接或間接的評審指標，運維管理平臺有能力從多方面監測流程具體執行效果，進而提高整體服務管理質量與水平。
04 需靈活滿足技術支撐需求
具體到技術支撐方面，不同企業單位定會存在個性化需求，傳統運維管理平臺工具往往針對性滿足細分領域功能要求，但無法應對隨着快速迭代業務帶來的無窮場景需求。常見的幾類場景有：
- 業務存在多級管控架構時，每層級自主管控程度高，上級單位往往無法有效採集下級單位數據。隨着業務發展，數據集中難以實現。倘若各層級使用相同的運維管理“底座”，在其上運行各自業務及打造專屬管理工具，則既便於實現數據共享，同時又保留各層級單位自主可控，實現了兼顧平衡。
- 很多運維管理工作都是背後默默進行，團隊工作量巨大而不爲人知，彙報效果也不理想，運維人員也常被譽爲“背鍋俠”。這對運維管理平臺可視化能力提出了新要求，它應該能夠快速以報表、大屏、門戶等方式對工作結果進行表達。
- 各部門、單位、團隊所使用的自有工具雜亂，無法一站式管理，但鑑於個性化也無法隨意廢棄，則要求運維管理平臺能力很好兼容各類管理工具，形成集中化、體系化的管理模式，成爲一個“總指揮協調”的角色。
- 不同部門、單位、團隊在實際管理中，肯定對於管理工具或多或少的個性化調整，比如很多自動化腳本，要求運維管理平臺可以提供豐富的開發環境與資源，允許用戶按需快速開發專屬的管理工具，實際減輕工作負擔。
- 同時平臺還要求易維護，不容易出問題，擁有完善的自身監控體系……
這些場景化需求將無窮無盡，運維管理平臺此時作爲管理的核心載體，必定要求具備豐富的能力，能夠支撐用戶體現個性化的適配性，在落地過程中與人員、制度、流程相互磨合滲透，最終達至動態良性互促的狀態。
05 要滿足安全管理要求
安全永遠是貫穿企業單位IT管理的考慮因素。用戶往往非常關心引入新平臺系統是否符合單位安全要求，有沒有第三方安全評測？是否符合現行的安全政策要求，比如國產化？平臺傳輸和存儲的安全防護手段是否達到業界水平？……這需要運維管理平臺在傳輸與存儲、鑑權與審覈，乃至程序代碼層面，都不同程度的滿足安全要求。
IT運維管理平臺如何選擇
我們很清楚，沒有最好的運維管理平臺，但我們需要選擇擁有足夠可塑性與靈活性的平臺，歸結起來它應該具備以下特點：
對外服務：
同時面向傳統穩態業務與新型敏捷業務模式，它應賦能IT服務團隊：彈性而細顆粒的組織分工方法、業界領先技術管理水平與兼容能力、滿足複雜場景的自主調度與編排能力、高效低成本的數據融通框架。
▲ 騰訊藍鯨PaaS+嘉爲藍鯨SaaS模式
對內管理：
引入新的運維管理平臺工具，實際上背後代表着一種新的管理思路與體系，它務必符合企業單位IT管理方針：切合組織管理特點、符合制度規範依據、具備流程質量審覈能力、滿足複雜多樣的技術支撐以及安全管理要求。甚至在落地過程中反過來優化現有的制度與流程，形成一種相互促進的良性循環。
▲ 嘉爲藍鯨圍繞組織、流程、技術等維度提供建設經驗與表達能力
再進一步思考，任何管理思路與體系都並非憑空生成，它不可能因由某位天才技術人員靈光乍現而誕生，它必然經歷過多年實戰、洗禮、反思、優化而沉澱，是一方領域中的智慧結晶。
一套成熟的管理工具與體系，不可能只來自一個團隊或企業，它背後很可能還隱含着多方共建力量，或是專業領域的合作伙伴和ISV，或者百家爭鳴的技術社區論壇，或者引領行業標準的聯盟協會，也可能是代表未來的產學研新生一代。
當企業單位在選擇一套運維管理平臺的時候，它絕不僅僅在選擇工具本身，更多的是在選擇一個生態圈子，或者說是一股多方共建、良性共生的生態力量。
▲藍鯨生態
總結
如今，IT運維管理今非昔比，不再是技術人員埋頭苦幹、被動救火的局面，已逐步升級演化爲企業單位中一項關鍵的體系化建設工作。它將直接間接地影響着整個企業單位IT戰略落地與業務發展方向，是擺在決策者與管理者面前的一個大挑戰，也是一個新機遇。我們一方面要從自身實際出發，另一方面應該更多借助業界的成熟與領先力量，融入生態，攜手共進，邁向共贏。
作者：曾嘉成