本文來自微信公眾號“twt企業(yè)IT社區(qū)（talkwithtrend.com）”，【作者】Bryan，某國有大型銀行資深架構師。
數(shù)字化轉型大勢所趨，各企業(yè)通過深化數(shù)字技術在生產、運營、管理和營銷等環(huán)節(jié)的應用，實現(xiàn)企業(yè)的數(shù)字化、智能化發(fā)展，不斷釋放數(shù)字技術對經濟發(fā)展的加速倍增作用。企業(yè)業(yè)務重塑和基礎設施的信創(chuàng)的同步推進，給IT運維帶來巨大挑戰(zhàn)。本文將結合多年經驗淺析金融行業(yè)的信創(chuàng)運維體系建設。
一、業(yè)務方面
各家銀行正在以客戶為中心重塑業(yè)務。通過定義商業(yè)策略、管理、組織和流程等重新梳理業(yè)務，拆分重組業(yè)務要素，設計領域模型并抽象現(xiàn)實業(yè)務。這會帶來大量業(yè)務系統(tǒng)建設升級。
二、技術方面
云計算、大數(shù)據、人工智能等新興技術使用進入深水區(qū)，分布式架構應用日漸廣泛，DevOps、AIOps等新研發(fā)運維模式擴大推廣。業(yè)務和技術的改變均帶來極大的運維挑戰(zhàn)：
1）分布式架構加劇運維復雜性
分布式微服務架構的推廣使得交易鏈條變長，系統(tǒng)和應用各環(huán)節(jié)間的依賴關系錯綜復雜，僅單一環(huán)節(jié)故障就可能拖垮多個系統(tǒng)。從主機下移到開放平臺后，裸金屬、虛擬機、容器等物理資源數(shù)量呈現(xiàn)指數(shù)級增長。這使得監(jiān)控節(jié)點增多且復雜、參數(shù)配置繁多且易出錯。
2）信創(chuàng)設施穩(wěn)定性有待時間檢驗
從各種異構CPU到操作系統(tǒng)，再到各類中間件，信創(chuàng)設施正在從外圍系統(tǒng)逐步推廣到核心業(yè)務系統(tǒng)。但各類產品之間及其自身的兼容性和穩(wěn)定性的生產運行時間較短，尚未經過高并發(fā)、大數(shù)據量等各種復雜業(yè)務場景的驗證，組織級信心還有待提升。
3）系統(tǒng)業(yè)務連續(xù)性要求更高
應用架構變化和基礎設施升級給系統(tǒng)業(yè)務連續(xù)性帶來挑戰(zhàn)，運維工作正處于能力提升和爬坡的關鍵階段。外部監(jiān)管部門的運維要求不降反升，提出了更高的RTO和RPO的業(yè)務連續(xù)性要求。
4）新技術能力體系建設尚需時間
運維平臺建設和日常故障處置對人員技能的要求較高。云計算、大數(shù)據、人工智能等創(chuàng)新技術涵蓋范圍廣、更迭速度快。建立全面合格的企業(yè)級人員技能儲備還需要較長時間。
三、應對方案
面臨數(shù)字化轉型和信創(chuàng)帶來的運維挑戰(zhàn)，企業(yè)應建立以用戶為中心的理念，全面對標行業(yè)最高運維標準，聚焦平臺能力沉淀，建設可感可知、可管可控、可計可析的運維能力，全面提升企業(yè)運維水平。
1）優(yōu)化完善企業(yè)運維制度和機制
傳統(tǒng)運維時，操作系統(tǒng)、中間件和網絡等部門職責明確，易于定位，但是，云時代的容器等平臺模糊了系統(tǒng)和應用之間以及系統(tǒng)內部的邊界。在定位問題時，部門間的配合方式和職責都發(fā)生較大變化，傳統(tǒng)機制難以適應，需要企業(yè)調整組織架構，優(yōu)化各團隊的技術背景。在研發(fā)部門，建立基礎設施團隊，發(fā)揮熟悉研發(fā)的特長，加強對研發(fā)團隊的基礎設施技術支持；在運維部門，在新技術運維團隊中擴充具有操作系統(tǒng)、網絡等多種技術背景的人員，降低運維團隊之間的溝通成本，甚至從研發(fā)部門引入經驗豐富的研發(fā)人員，提升運維平臺的研發(fā)水平，加快應用故障的定位速度。
梳理現(xiàn)有規(guī)章制度和流程機制，結合新技術特點進行調整。比如，金融行業(yè)流行的WAS、Weblogic等換成了PaaS平臺的Tomcat等輕量級中間件，這需梳理各部門對YAML文件的配置規(guī)范和職責分工。研發(fā)部門需配合運維做好應用就緒和探活的配置，運維部門配合研發(fā)做好應用資源的估算和彈性擴縮容配置。在生產故障時，傳統(tǒng)方式下的中間件團隊確認其正常后，即由項目組自行排查相關故障，但現(xiàn)在，則需各團隊有序配合全方面的故障點定位，在故障定位前各團隊難以自證無慣性。
2）研發(fā)一體化運維管控平臺
面臨繁多的參數(shù)變更和冗長的交易鏈條等挑戰(zhàn)，將各種繁重復雜的工作沉淀整合到一體化運維管控平臺，聚焦監(jiān)控告警、配置管理、變更應急、運維分析等領域的平臺化建設。
面臨開放平臺幾何級增長的軟硬件資源，重點建設CMDB平臺，形成統(tǒng)一的完整、全面、準確的資源視圖。這有助于提升企業(yè)IT資產管理水平，有助于根據生產運行情況進行架構優(yōu)化管控，如外部監(jiān)管的數(shù)據統(tǒng)一報送、軟件升級和漏洞防控等專項治理工作推進、研發(fā)運維的工作后評價、IT資產及關聯(lián)關系管控等。
在監(jiān)控告警方面，通過各類基礎設施的管控平臺實現(xiàn)全面的“點式”監(jiān)控，通過全鏈路平臺實現(xiàn)交易級的“線式”監(jiān)控，通過IT資產平臺實現(xiàn)應用間的“面式”監(jiān)控。新型監(jiān)控平臺有助于事前建立視圖、事中定位問題和事后預測分析。
在配置管理方面，結合業(yè)務系統(tǒng)的投產、變更和下線的生命周期，一方面建立各類投產變更流水線，避免出現(xiàn)參數(shù)配置的遺漏和錯誤，一方面通過歷史版本的縱向對比和系統(tǒng)之間的橫向對比，發(fā)現(xiàn)潛在的配置風險，生成優(yōu)化建議。
在變更應急方面，在日常變更時，通過參數(shù)化腳本實現(xiàn)投產變更、應用驗證和監(jiān)控檢查的常規(guī)操作，降低各類操作的難度，提升變更效率，減少出現(xiàn)風險。綜合分析日常故障處置流程，對應用切換、服務啟停、版本回退、故障隔離、限流等常規(guī)操作建立響應操作流水線，實現(xiàn)一鍵處置，最大限度降低故障的影響時間和范圍。
在運維分析方面，研發(fā)智能運維分析平臺，利用歷史數(shù)據建立并優(yōu)化各類AI運維模型，一方面預測系統(tǒng)容量需求并及時調整，一方面預測潛在故障并及時介入處置。
在容災建設方面，建立兩地三中心的常規(guī)化容災演練機制，通過各類不定時切換演練發(fā)現(xiàn)運維短板和問題，確保發(fā)生生產故障時真正可切、可用。
3）加強研發(fā)過程管控標準
投產前，按“所測即所投”的方式完成性能壓測，確保關鍵交易性能等指標可滿足預期生產需求。通過自研混沌測試平臺逐步積累各類系統(tǒng)級和應用級的故障場景案例，在控制爆炸半徑前提下進行多種類、多場景的故障場景測試，不斷提升基礎設施的健壯性、應用系統(tǒng)的可靠性和監(jiān)控的全面性。將運維平臺接口規(guī)范沉淀到研發(fā)平臺，在減少研發(fā)工作量的同時提升應用的可觀測性、監(jiān)控的標準化和規(guī)范化。
投產后，建立生產事件單臺賬，全面分析問題根本原因，形成對應用研發(fā)指導的反饋閉環(huán)。比如，MySQL因美國夏令時的時區(qū)配置錯誤導致業(yè)務中斷一小時，研發(fā)部門修改數(shù)據庫配置規(guī)范和研發(fā)指導，對存量應用系統(tǒng)完成規(guī)范治理，確保不會出現(xiàn)類似錯誤。
4）提升全員技能水平提升
在員工方面，在企業(yè)內部通過技術分享、專題培訓等方式對員工進行分階段、分類別的技能提升；強化個人專項技能的同時，不斷擴充其技術視野。建立研發(fā)左移機制，讓員工全程參與應用研發(fā)全過程，熟悉其技術架構；鼓勵參加各類具有技術含量的官方認證考試，以考促練的形式逐步提升團隊技能。
在企業(yè)方面，通過聯(lián)合創(chuàng)新等方式，與合作企業(yè)針對企業(yè)的業(yè)務場景，不斷迭代打磨產品，讓員工在參與產品研發(fā)的過程中逐步提升對產品的認知水平和理解深度。
四、總結
由此可見，隨著信創(chuàng)工程不斷走入深水區(qū)，企業(yè)需要建立配套的組織和規(guī)章制度，加強一體化運維平臺的建設和人員技能軟實力的提升，在數(shù)字化轉型過程中逐步建立打磨出一套適合企業(yè)自身特點的運維管理體系。
