以業務為中心重塑運維崗位能力

【摘要】隨著運維能力持續提升，硬件、系統軟件的工作更加標準化與自動化，而業務運維復雜性越來越高，運維崗位能力需要以業務為中心，重塑崗位能力。

運維體系的發展，是一個不斷從“組織、流程、平臺、場景”四個維度不斷適應IT環境變化的過程，整個過程形成了一個運行數字世界的適應性系統。這個適應性系統由不斷改進的組件與越來越復雜的連接組成，系統的持續改進目標是為了更高效的適應復雜性、不確定性的變化。在運維適應性系統組件包括硬件、系統軟件、業務系統、人、運維效能工具。隨著“需求（need）、改變（change）、風險(risk)、適應(adapt)”的循環飛輪的運維能力持續提升，硬件、系統軟件的工作更加標準化與自動化，而業務運維復雜性越來越高，運維崗位能力需要以業務為中心，重塑崗位能力。如何適應變化在筆者文章“構建運維適應性系統”中，提到運維適應性系統的建設是一個圍繞“需求（need）、改變（change）、風險(risk)、適應(adapt)”4個節點循環，達到能力螺旋上升的飛輪循環。即，運維能力的提升來源于更高（質）、更多（量）、更快（速度）的需求驅動；為了適應新的需求，組織引入新的技術與新方法；新改變通常會產生新的風險；綜合優化組織、流程、場景、平臺能力，解決風險，形成適應性能力；建立了適應性能力后可以支持更高、更快、更多的需求。本節先看運維面臨的變化。IT部門面臨加快交付效率，提升運維質量的挑戰。以金融行業為例，按照金融業信息技術“十三五”發展規劃目標，“十三五”期間金融經營機構的重點任務主要包括：進一步完善金融信息基礎設施，健全網絡安全體系，推動新技術應用，深化金融標準化戰略，優化信息技術治理體系，提供更加集約、高效、安全的金融信息技術服務。信息化時代，國內領先的金融企業構建了大量的IT系統，并利用了金融信息化契機獲得商業上的成功。隨著市場復雜性與不確定性不斷加快，線上應用的壽命越來越短，以蘋果應用市場為例2019年上半年平均每天下架的應用接近2300款應用，環比增長45.58%，前端的應用必須能夠快速響應政策環境、監管要求、用戶需求才能在不斷加快的大背景下獲得企業競爭力。但在信息化傳統封閉架構下，金融企業IT系統形成一個個垂直的煙囪，缺乏信息互聯和共享，為了滿足業務日益多樣化的需求，主要采用先豎向滿足業務，再橫向打通，交付業務需求的成本越來越高。所以，如何確保系統穩定和業務合規的前提下，提供敏捷交付管理及業務需求的能力是金融企業IT部門面臨的第一挑戰。另外，生產系統業務連續性保障形勢不容樂觀，以證券行業交易所為例，今年以來，全球各地交易所技術故障風險事件頻發：德意志交易所于今年4、7月因軟件故障導致中歐及東歐幾個國家衍生品和股票交易受阻；8月新西蘭交易所連續6天收到網絡攻擊被迫多次中斷交易；10月東京交易所因系統切換異常導致全天暫停交易；10月墨西哥交易所因交易引擎斷開暫停交易；10月泛歐交易所因中間件系統問題暫停所有產品交易；11月澳洲交易所開盤后交易中斷停業一天等。如何在企業快速發展過程中，加強業務連續性保障能力則是第二個挑戰。推動基礎架構云化、云原生應用興起正當其時。交付效率與運行質量的挑戰可以轉換為：降低運營成本、提供高效彈性、防范信息安全、提高交付效率、保障連續性風險等技術目標，需要引入架構云化、云原生方法三個技術/方法。當前，大部分中大型企業都確定了基礎設施層面云計算戰略，一些有能力或對信息安全性要求高的企業，重點推進私有云建設，并結合大型云服務廠商提供的公有云或行業機構提供的行業云，形成混合云的運營模式。可以預想，云計算集中了企業資源，通過集約化帶來的成本優勢，將為企業提供更穩定、高彈性、低成本的基礎設施、數據庫、中間件，及其它平臺層的PAAS組件。伴隨著云基礎設施的落地，企業不僅是簡單的將現有應用系統分步搬上云，也面臨如何更好的利用云計算彈性擴展、分布式、按需獲取、安全可靠等優點，這就推動了應用架構在開始設計時都要考慮將來能夠運行于云環境，由此帶動了云原生應用的興起。對云原生的定義，云原生計算基金會（CNCF）作出以下定義：“云原生技術有利于各組織在公有云、私有云和混合云等新型動態環境中，構建和運行可彈性擴展的應用。云原生的代表技術包括容器、服務網格（ServiceMesh）、微服務、不可變基礎設施和聲明式API。”以下摘自互聯網中關于云原生的定義、要素、設計理念的圖：云化基礎設施、云原生方法，簡化了上層應用的交付效率，但將復雜性落在運維側。云化基礎設施，使得企業不再需要按項目或需求去購買、部署、維護硬件和系統軟件，無需資源消費方參與復雜硬件及系統軟件的維護，標準化了基礎設施、系統軟件運維，用自動化替代了原來大量操作性工作。但云化基礎設施架構必然面臨要對企業原有系統進行改造，由于傳統企業大部分重要交易業務系統均采用煙囪部署架構，且運行多年后，現有系統架構越來越復雜，“動則生變，變則異常”己成常態。采用云原生方法，雖然幫助業務快速迭代，但廣泛使用的開源技術與分布式節點粒度的分解，也帶來了架構的復雜性，交易鏈路節點數量迅速膨脹，同時軟件代碼與項目交付流程也發生了改變，都提高了業務運維的復雜性。在技術的應用上，還需要關注新技術的選擇時機，很多新技術通常是解決一個軟件研發過程的問題，但是新技術的坑需要經過一系列質量內建手段、線上生產事件來填，如何在一個合適的時機引入一個新技術是一個風險。

以業務為中心，推動運維能力提升，配套運維平臺化建設是當前行為有效的適應手段。行業不同，對業務連續性的理解并不一樣。以google提出的devOps其中一個原則：“愿意承擔一部分試錯帶來的損失”，在金融行業則不適用。以證券實時交易為例，業務停滯一秒均可能帶來巨大損失，證券自身的業務特點以及外部監管“零容忍”的要求，信息系統業務連續性的訴求會高于其他行業，確保業務連續性成為證券行業IT運維的核心任務，業務連續性管理的總體目標是提高公司的風險防范能力、有效地減少非計劃的業務中斷、防范運維操作風險，對于首次出現的未知異常能夠利用工作量化分析并快速定位，確保在重大災難性事件發生后能按計劃恢復業務連續性。在這樣的行業背景下，運維團隊的角色肯定不能僅會應急三把斧或工具研發的角色，而應該能夠深耕業務并運用工程能力的運維角色。運維平臺化的作用是對運維的賦能，而不是替代運維，運維平臺需要圍繞運維組織的“提高業務連續性保障、提升業務交易系統，輔助提升客戶體驗、提升IT運營服務質量”等價值創造，持續豐富“監管控析”的工具平臺體系，不斷推進工作線上化、自動化、服務化的落地。

從GoogleSRE到BRE與傳統運維崗位相比，SRE更加強調“可靠性”與“工程能力”。SRE（SiteReliabilityEngineering，站點可靠性/穩定性工程師），要從其名稱看看SRE的崗位角色。S（site），最初代表Google的運維服務，隨著團隊的擴大，實際上S的范圍也擴展到了其它應用系統。R（Reliability），google認為是運維組織要不斷的優化系統架構、運維流程，讓系統更加可靠，擴展性更好，能更有效的利用資源。可以看出，SRE相比傳統運維，明確強調了“可靠性”保障，這推動了SRE聚焦資源落到盡可能增加MTTF（不出故障的時間）和縮短MTTR（出故障后的恢復時間）兩個指標上，并圍繞這兩個關鍵指標加強系統運行風險排查與解除，并加強風險發生后的應急能力。E（工程師），工程師需要具備有工程能力，在google指需要具備軟件研發能力的工程師，能夠和業務研發團隊共同工作，研發系統以外的額外組件。再看看SRE日常工作：日常需求處理、容量規劃、資源部署、監控告警、預案梳理、災備演練、OnCall值班、應急事件響應、故障處置、影響分析、應急復盤、軟件研發、項目站立會、系統設計、項目進度推進、工具落地推廣等。可以看到，SRE區別于傳統運維崗位的第二個特征是“工程性能力”，狹義的講是軟件開發能力，但又與業務開發有些區別，SRE的開發偏向于提升業務連續性上的研發，業務開發偏向于業務功能研發。（關于SRE的更多信息，我摘一些在《SREGoogle運維解密》中一些SRE的觀點，見文章結尾，這里暫不展開）Google認為S、R、E三個詞中，最關鍵的是E，可能是因為這個原因，國內很多人把SRE等同于運維開發。站在金融行業，我個人認為如果SRE是金融行業運維崗位能力發展的參照方向，應該以S與R為本，E是手段，或者說應該是“BRE”（BusinessreliabilityEngineering）。首先，前面提到金融行業更加強調業務連續性，運維角色必須懂業務，去掉業務屬性，這支運維團隊就失去了靈魂。所以一個好的運維人員不僅是能夠操作各類監控、應急恢復、咨詢解答、變更操作等能力，他還應該是在整個IT團隊中具備最全局掌握所負責系統應用部署架構、可用性架構、上下游關系、最小功能模塊失效影響、容量性能分析等能力的角色。其次，從GoogleSRE由來看，SER是一支獨立成長于原有運維團隊的組織，也就是這支團隊是一支全新投入的人力資源。但金融企業的運維團隊通常比較穩定，相比研發團隊根據業務需求不斷擴大，運維團隊規模通常不怎么變化，運維團隊的工作能力就像海綿一樣擠擠又能承擔更多。所以，運維團隊的轉變重點是對現有運維人員能力建設。另外，運維團隊中資深的工程師比較多。資深說明運維人員沉淀了更多經驗，經驗有助于在業務連續性保障中更快的定位問題。但從現實情況看，資深也導致個人學習意愿與學習能力的下降，所以讓現有運維團隊的人都能掌握軟件開發能力并不現實，如何既發揮好運維人員的經驗，又能促進團隊的成長型思維是一個難點。所以，我覺得運維團隊可以基于BRE角色建設，提升業務連續性保障能力，再推動“提升業務交付效率”、“輔助提升客戶體驗”、“提升IT運營服務質量”的能力建設。如果要勾畫BRE角色，可以考慮以下方向：系統架構師：清楚應用系統部署架構，懂應用邏輯架構，掌握上下游系統、高可用、容災架構等。業務架構師：清楚核心業務功能業務邏輯，當核心功能不可用，甚至一筆關鍵交易異常時，能夠及時發現，并快速應急解決，或利用混沌工程加強業務風險點。可用性工程師：擅于利用工具，落實可用性改進，容量規劃，延遲優化，性能優化，業務架構優化，應急演練，應急預案編寫等工作。運營分析師：具備數據思維，能夠讓系統運行，業務運作，客戶體驗，流程管理等數字化，并利用掌握的運營數據驅動研發，測試，業務持續優化。運維操作員：各類監控發現、輿情感知、故障應急、根因分析、系統巡檢、咨詢反饋、變更交付、IT服務等工作。

加強被動性與主動性適應性能力結合上面提到的“系統架構、業務架構、可用性、運營分析、運維操作”五個維度，如果將運維工作分被動性與主動性兩類，可以大致分為：1、被動性工作：根據事件增加監控指標，加強監控覆蓋面，提高監控處理及時性，提升故障應急處置自動化，優化故障應急協同機制，落實故障后問題的閉環跟蹤，提高生產變更發布自動化水平，建立生產問題咨詢反饋的服務機制等。2、主動性工作：制定系統架構標準，運維工作前移參與系統設計階段工作，構建可視化的應用上下游調用鏈路，持續推進業務邏輯架構評估，加強對業務核心功能及數據的理解，推進混沌測試挖掘系統風險點，落實故障應急復盤機制，推進系統性能與容量、終端撥測、客戶體驗等分析工作，加強系統效能分析推動低效系統退出機制。可以看到，被動性工作主要面向傳統運維的業務連續性保障工作，線上化、自動化主要是面向被動性工作范圍；主動性工作主要是利用運維對架構、業務、運行數據的分析能力，增加運維全局可控能力，數字化、服務化主要是面向主動性工作。最后，雖然金融企業的BRE不強調軟件開發能力，但他要擅于運用運維平臺工具