[[382559]] 

【51CTO.com原創稿件】如今，隨著ITIL 4在業界的落地和推廣，企業的IT治理目標趨向于打造一個閉環式的服務價值鏈(SVC)。也就是說，通過構建一套可靠、可控、完備的服務運維實踐模型，為企業的日常業務運營保駕護航。

那么既然是治理，我們就需要從用戶的角度，來看待IT服務的交付過程。通常，用戶主要關注的是三個方面：服務本身是否可用，提供服務的團隊是否到位，以及他們能否調動必要的資源。顯然，由于疫情的原因，這三個方面已不再能夠通過統一的辦公場所交付出來。因此我們需要從遠程，保障它們能夠被持續且準確地提供給用戶。下面，我們來逐一進行討論。

可用性管理

不光是“身在家中，心在崗”的IT打工人們，其實整個公司的上上下下，都在高度關注疫情期間信息系統與服務的可用性狀況。簡單而言，可用性管理的目標可以被歸納為兩個方面：

• 在事故發生前，保證業務服務和系統架構的穩定性。
• 在事故放生后，盡量減少中斷所持續的時間、以及此類事故的發生頻率。

對此，我們團隊從當下的服務類型、系統的業務價值、外部可能帶來的威脅、以及內部存在的弱點等維度出發，從如下三個維度開展了可用性狀態調查：

• 掌握各個應用組件的最大允許中斷時間(MTD)。通常，我們可以從業務職能的重要性出發，粗略劃分為：關鍵(1-4小時)、緊急(24小時)、重要(72小時)、一般(7天)、以及非必要(30天)五大類。
• 了解各個應用組件的自身復雜程度，以及與其他組件的依賴程度。通過梳理，我們制定出了類似如下的表格。 

• 整理當下各種SLA(Service Level Agreement，本企業向外部客戶提供的服務協議)、OLA(Operational Level Agreement，企業內部IT向其他部門提供的服務協議)、以及UC(Unpinning Contract，外部供應商向本企業提供的IT設備支撐合同)，提取各項性能指標，進而建立組件的現狀基線、以及閥值警報機制，以便為可能出現的性能問題，提供可參考的診斷依據。

當然，上述基本狀態是比較容易掌握的，關鍵是如何落實到可用性程度的計算上。通過大家的集思廣益，為了化繁為簡、迅速地找到可衡量的抓手，我們引入了業界常用的“幾個九”的計算方法。其中，對于單個服務組件，我們采用了：

• 平均故障間隔時間(MTBF)=(約定提供服務時間-總宕機時間)/發生中斷的次數
• 恢復服務的平均時間(MTRS)= 總宕機時間/發生中斷的次數
• 可用性程度 = MTBF/(MTBF+MTRS)

而對于較為復雜的服務系統而言，我們聰明的理科男們采用了如下算法方法：

• 串聯系統的整體可用性 = A組件可用性 × … × N組件可用性
• 并聯系統的整體可用性 = 1–(1 – A組件可用性)× … ×(1 – N組件可用性)
• 混聯系統的整體可用性 = 串聯部分的整體可用性 × 并聯部分的整體可用性

可見，為了縮短MTRS的用時，我們需要提高對于事故的綜合處置能力。例如，我們在維護一套現有的云端業務環境時，就從整個生命周期的各個環節予以管理和提高。其中包括：

• 在檢測與識別階段：我們分別抓取和過濾來自各個虛擬機的系統事件、以及基于網絡的異常流量信息，然后持續將經過篩選的日志信息寫入HBase數據庫，為后期的各種關聯分析、以及必要的取證提供重要依據。
• 在調查與分析階段：我們運用工具按照特征代碼，對事件的種類予以分組、對事件的發生頻率進行統計。同時，我們引入了應用性能分析(APM)模塊，精確地定位在應用服務中是哪個URL的訪問速度出現了驟降，或是用戶在提交哪個SQL語句時出現了延時，以便我們更快地定位根本問題。
• 在抑制與補救階段：我們可以通過暫停出問題的虛機鏡像，來隔離它與其他系統及服務之間的邏輯聯系，此舉既不會破壞該虛機上的證據，又能夠阻止事態的惡化。

而為了提高MTBF，并及時獲悉目標系統的可用性程度，我們在各個辦公站點都設置了可靠性工程師(SRE)角色。他們的日常工作主要體現在預防性例行檢查上。其中在硬件和機房環境方面，SRE們在疫情期間利用有限的返回現場工作的機會，在各個機房安裝或利用既有的攝像頭，實時監控關鍵設備面板上的狀態燈或LED屏，以便結合手冊上的相關說明，迅速地發現、并定位各種硬件部件上的問題。而對于軟件應用而言，我們通過已部署的常規日志與事件監控工具(如開源的Zabbix)，以遠程和集中的方式，審查并跟蹤各項性能指標。

當然，我們事先已針對監控過程中捕捉到的事件信息，根據其重要程度進行了如下分類：

• 信息性事件，例如：某個用戶的入職和離職，都會觸發人事管理系統，向相關運維人員群發一封內部郵件，以便他們采取相應的設置與操作。
• 警告，例如：在去年2月份的疫情初期，大量居家辦公的用戶遠程連入企業內網，造成服務器的CPU使用率，接近甚至超過設定的閾值。
• 異常，例如：到了去年的3月底，歐美疫情大爆發，遠程用戶數出現了猛增。上述服務器的CPU使用率和最大連接數迅速并持續超過了設定閾值，直接導致了新的用戶無法連接和使用遠程網絡。

值得一提的是，我們的計費模塊持續記錄著各個用戶所觸發的、滿足計費條件的打印與復印作業。然而，在去年五月份的某次局部升級調整之后，它出乎意料地影響到了我們全球各個辦公站點的打印與復印作業的輸出性能與速度。幸好有SRE通過對打印速度的例行監控，及時發現了該瓶頸問題。通過后續整個團隊抽絲剝繭地分析，終于在其造成規模性影響之前，予以了糾正。

關系管理

由于疫情阻斷了我們IT團隊，以現場或面對面的方式直接提供技術服務，因此遠程桌面和電話交流成了我們常用的支持方式。為了避免由于無法見面，而造成IT人員與最終用戶之間、與管理層之間、以及IT團隊內部等維度上的關系疏遠，我們借用管理學中的SWOT分析法，圍繞著IT團隊進行了全方位的關系梳理：

• 優勢(Strengths)：由于本企業持有ISO27000認證，因此在管理規范、技術設施、文檔覆蓋面等方面比較充足。同時，我們有配置管理數據庫(Configuration Management Database，CMDB)和問題知識庫(Knowledge Base，KB)，可供按需查詢。
• 劣勢(Weaknesses)：用戶使用的軟硬件本該在去年初進行更新換代，但是疫情阻礙了設備替換、系統重裝、以及軟件升級的計劃。此外，用戶家中的網速與帶寬，也在一定程度上限制了遠程技術支持與更新的能力。
• 機會(Opportunities)：遠程的“非接觸”服務方式，在某種程度上消除了用戶對于支持人員的既有成見。當然，本企業用戶的普遍學歷較高，有一定的電腦技能和理解能力，也對技術人員報有信任和尊重。
• 威脅(Threats)：敏感信息在原有辦公內網之外的環境中被查閱和編輯，用戶以“不可見”的遠程交流方式開展協作，這些都潛藏著較大的被攻擊的風險點。

疫情期間，用戶的服務需求可謂只增不減、林林總總、紛繁復雜。根據上述分析，我們預先排定了優先級，并合理分配響應資源的基礎上，制定了如下具有“疫情”特征的服務溝通與支持方法：

• 及時調整并向用戶公示，全新的疫情期間IT服務流程，既讓公司上下看到我們仍在“行動”、仍在提供服務，又讓他們對IT服務的運作機制有所了解，增加對支持人員的諒解和耐心。
• 在獲悉用戶的需求或問題后，及時給出處理用時的預估，以方便用戶調整后續的工作或作息(畢竟是居家，不是在辦公室)。
• 定期開設技術專題直播，方便感興趣的用戶隨時加入學習。當然，我們也會對這些“公開課”進行錄制，并將視頻資源與配套的文檔發布到內網上，供無法參加直播的用戶，按需點播學習。
• 考慮到疫情可能對于大家居家工作效率所造成的影響，我們邀請用戶以投票的形式，參與決定對某些服務何時進行變更或升級。
• 定期群發對于一些普遍性問題的回復與通告，既體現IT部門的服務意識與關懷態度，又在無形中培養了用戶針對同類問題的基本意識，以及簡單的處置能力。
• 推行“多一步(One more thing)”的服務理念。即，支持人員在遠程服務用戶完畢后，可以貼心地和對方聊兩句健康狀態，或是本著主動關懷的態度，詢問是否還有其他方面的IT需求。

當然，正所謂“有人的地方就有江湖”。同樣，有服務就難免會出現問題。因此，為了處理好由于問題本身或不理解所產生的各種投訴，我們不但保證了問題升級渠道的暢通，又通過按需與其他部門協作，及時給予當事人答復，變被動為主動，向管理層證明IT團隊在非常時期的價值。

前面提到了IT團隊內部關系的保持。為此，我們將疫情前分散的各部門例會形式，合并為每個季度的全技術部在線會議。在會上，我們除了集中討論現有的問題，供大家集思廣益之外，也會通報并表揚表現出線、特別是得到了用戶點贊的個人，從而在整體團隊中形成“正循環”。

此外，為了讓長期不能謀面的IT人員刷出“存在感”，激發他們的參與意識，我們每隔一、兩個月都會舉辦形式多樣的技能征集和知識競賽等活動，讓大家在各施其才的同時，塑造出了相互學習、取長補短的氛圍。

總之，建立與增加良好的溝通關系，是我們推動各項服務的增值，以及確保IT項目順利推進的必備條件。

財務管理

需要保障的第三項，莫過于財務管理了。眾所周知，防疫的這一年，絕大多數企業無不捂緊了錢包。實際上，這對于IT部門來說既是挑戰，又是機遇。說是挑戰，是因為對于我們這樣的“燒錢”部門而言，可添置軟、硬件，以及可繼續或新增的項目，比以往更難獲取了;而說是機遇，則是指我們需要以“花得值”的方式，更加有效率地利用能獲取到的資源，并創造和體現自身價值。對此，我們利用去年上半年的時間，認真厘清了如下兩種收支關系：

•  “收”：IT部門在向其他部門提供服務的過程中，轉嫁核算出去的人力、資源消耗等方面的成本。例如：

• 對于被用戶直接使用的硬件成本，可按照用戶數、或節點數量進行分攤。
• 對于軟件與應用的成本，可按照使用的部門、分配的許可證數量進行分攤。
• 對于網絡連接設備和技術支持等成本，由于缺乏參考計算的標準，可按人數比例與規模，分攤到各個部門或分支機構。

• “支”：IT管理層協同財務部門，向外支付IT服務的購置與支持費用。

有了上述對于IT服務花銷的全面掌握，以及收支分類的合理管理，我們從去年九月初開始，相繼開展了如下以預算為驅動的財務管理實踐：

• 早在上半年間，我們便全面梳理了軟、硬件的當下資產價值，以及為保證各項業務服務和日常運營所需的IT費用開支清單。

• 我們將資產項和服務條目細分為：用于添置或更新IT服務的資產支出;用于維持機房環境和云端系統的運營開支;用于獲取設備維護、軟件支持的定期固定支出;用于處置特定項目、變更事件的變動成本。

• 我們是在各個業務部門已經確立了2021年的業務目標，以及企業發展與投資方向之后，才能著手分析相關領域的成熟技術和產品，并借鑒了業界其他企業的技術落地經驗，最終制定出了謹慎且合理的預算。

• 就前瞻性而言，我們從“可能的服務”而不是“現有的功能”出發，既顧及到了內、外部的各方面的變化因素、又參照了來年市場上的各種可能性調價方案。

• 在外包服務方面，鑒于疫情對于現場例行服務的需求驟減，我們在削減了此類開支的基礎上，適當地增加了事后糾正類服務水平的占比。

當然，除了在預算上下功夫，我們也根據上述分攤原則，參考前面提到過的CMDB，制定了一張成本映射表。通過不斷新增開銷記錄、并動態調整成本項，我們及時地跟蹤了各項成本開銷，并將其與預算進行及時比較與修正。

小結

在疫情期間，IT支持部門難免會受到各方面的影響，甚至會在“寒風中瑟瑟發抖”。不過，我們團隊卻能夠意識到：與其得過且過，不如乘機“修煉內功”，提高競爭力，在當下IT架構和服務的可靠性(Reliability)、可維護性(Maintainability)、以及可服務性(Serviceability)上進行加固，保持、甚至提高用戶的滿意度，與企業“共振”。正如一位IT同事在去年底的那句充滿文藝范的神總結：“用戶見與不見，我們團隊都在那里，不舍、不棄。”

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】