[[382559]] 

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

那么既然是治理，我們就需要從用戶的角度，來看待IT服務(wù)的交付過程。通常，用戶主要關(guān)注的是三個(gè)方面：服務(wù)本身是否可用，提供服務(wù)的團(tuán)隊(duì)是否到位，以及他們能否調(diào)動(dòng)必要的資源。顯然，由于疫情的原因，這三個(gè)方面已不再能夠通過統(tǒng)一的辦公場所交付出來。因此我們需要從遠(yuǎn)程，保障它們能夠被持續(xù)且準(zhǔn)確地提供給用戶。下面，我們來逐一進(jìn)行討論。

可用性管理

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

• 在事故發(fā)生前，保證業(yè)務(wù)服務(wù)和系統(tǒng)架構(gòu)的穩(wěn)定性。
• 在事故放生后，盡量減少中斷所持續(xù)的時(shí)間、以及此類事故的發(fā)生頻率。

對(duì)此，我們團(tuán)隊(duì)從當(dāng)下的服務(wù)類型、系統(tǒng)的業(yè)務(wù)價(jià)值、外部可能帶來的威脅、以及內(nèi)部存在的弱點(diǎn)等維度出發(fā)，從如下三個(gè)維度開展了可用性狀態(tài)調(diào)查：

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

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

當(dāng)然，上述基本狀態(tài)是比較容易掌握的，關(guān)鍵是如何落實(shí)到可用性程度的計(jì)算上。通過大家的集思廣益，為了化繁為簡、迅速地找到可衡量的抓手，我們引入了業(yè)界常用的“幾個(gè)九”的計(jì)算方法。其中，對(duì)于單個(gè)服務(wù)組件，我們采用了：

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

而對(duì)于較為復(fù)雜的服務(wù)系統(tǒng)而言，我們聰明的理科男們采用了如下算法方法：

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

可見，為了縮短MTRS的用時(shí)，我們需要提高對(duì)于事故的綜合處置能力。例如，我們?cè)诰S護(hù)一套現(xiàn)有的云端業(yè)務(wù)環(huán)境時(shí)，就從整個(gè)生命周期的各個(gè)環(huán)節(jié)予以管理和提高。其中包括：

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

而為了提高M(jìn)TBF，并及時(shí)獲悉目標(biāo)系統(tǒng)的可用性程度，我們?cè)诟鱾€(gè)辦公站點(diǎn)都設(shè)置了可靠性工程師(SRE)角色。他們的日常工作主要體現(xiàn)在預(yù)防性例行檢查上。其中在硬件和機(jī)房環(huán)境方面，SRE們?cè)谝咔槠陂g利用有限的返回現(xiàn)場工作的機(jī)會(huì)，在各個(gè)機(jī)房安裝或利用既有的攝像頭，實(shí)時(shí)監(jiān)控關(guān)鍵設(shè)備面板上的狀態(tài)燈或LED屏，以便結(jié)合手冊(cè)上的相關(guān)說明，迅速地發(fā)現(xiàn)、并定位各種硬件部件上的問題。而對(duì)于軟件應(yīng)用而言，我們通過已部署的常規(guī)日志與事件監(jiān)控工具(如開源的Zabbix)，以遠(yuǎn)程和集中的方式，審查并跟蹤各項(xiàng)性能指標(biāo)。

當(dāng)然，我們事先已針對(duì)監(jiān)控過程中捕捉到的事件信息，根據(jù)其重要程度進(jìn)行了如下分類：

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

值得一提的是，我們的計(jì)費(fèi)模塊持續(xù)記錄著各個(gè)用戶所觸發(fā)的、滿足計(jì)費(fèi)條件的打印與復(fù)印作業(yè)。然而，在去年五月份的某次局部升級(jí)調(diào)整之后，它出乎意料地影響到了我們?nèi)蚋鱾€(gè)辦公站點(diǎn)的打印與復(fù)印作業(yè)的輸出性能與速度。幸好有SRE通過對(duì)打印速度的例行監(jiān)控，及時(shí)發(fā)現(xiàn)了該瓶頸問題。通過后續(xù)整個(gè)團(tuán)隊(duì)抽絲剝繭地分析，終于在其造成規(guī)模性影響之前，予以了糾正。

關(guān)系管理

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

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

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

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

當(dāng)然，正所謂“有人的地方就有江湖”。同樣，有服務(wù)就難免會(huì)出現(xiàn)問題。因此，為了處理好由于問題本身或不理解所產(chǎn)生的各種投訴，我們不但保證了問題升級(jí)渠道的暢通，又通過按需與其他部門協(xié)作，及時(shí)給予當(dāng)事人答復(fù)，變被動(dòng)為主動(dòng)，向管理層證明IT團(tuán)隊(duì)在非常時(shí)期的價(jià)值。

前面提到了IT團(tuán)隊(duì)內(nèi)部關(guān)系的保持。為此，我們將疫情前分散的各部門例會(huì)形式，合并為每個(gè)季度的全技術(shù)部在線會(huì)議。在會(huì)上，我們除了集中討論現(xiàn)有的問題，供大家集思廣益之外，也會(huì)通報(bào)并表揚(yáng)表現(xiàn)出線、特別是得到了用戶點(diǎn)贊的個(gè)人，從而在整體團(tuán)隊(duì)中形成“正循環(huán)”。

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

總之，建立與增加良好的溝通關(guān)系，是我們推動(dòng)各項(xiàng)服務(wù)的增值，以及確保IT項(xiàng)目順利推進(jìn)的必備條件。

財(cái)務(wù)管理

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

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

• 對(duì)于被用戶直接使用的硬件成本，可按照用戶數(shù)、或節(jié)點(diǎn)數(shù)量進(jìn)行分?jǐn)偂?/li>
• 對(duì)于軟件與應(yīng)用的成本，可按照使用的部門、分配的許可證數(shù)量進(jìn)行分?jǐn)偂?/li>
• 對(duì)于網(wǎng)絡(luò)連接設(shè)備和技術(shù)支持等成本，由于缺乏參考計(jì)算的標(biāo)準(zhǔn)，可按人數(shù)比例與規(guī)模，分?jǐn)偟礁鱾€(gè)部門或分支機(jī)構(gòu)。

• “支”：IT管理層協(xié)同財(cái)務(wù)部門，向外支付IT服務(wù)的購置與支持費(fèi)用。

有了上述對(duì)于IT服務(wù)花銷的全面掌握，以及收支分類的合理管理，我們從去年九月初開始，相繼開展了如下以預(yù)算為驅(qū)動(dòng)的財(cái)務(wù)管理實(shí)踐：

• 早在上半年間，我們便全面梳理了軟、硬件的當(dāng)下資產(chǎn)價(jià)值，以及為保證各項(xiàng)業(yè)務(wù)服務(wù)和日常運(yùn)營所需的IT費(fèi)用開支清單。

• 我們將資產(chǎn)項(xiàng)和服務(wù)條目細(xì)分為：用于添置或更新IT服務(wù)的資產(chǎn)支出;用于維持機(jī)房環(huán)境和云端系統(tǒng)的運(yùn)營開支;用于獲取設(shè)備維護(hù)、軟件支持的定期固定支出;用于處置特定項(xiàng)目、變更事件的變動(dòng)成本。

• 我們是在各個(gè)業(yè)務(wù)部門已經(jīng)確立了2021年的業(yè)務(wù)目標(biāo)，以及企業(yè)發(fā)展與投資方向之后，才能著手分析相關(guān)領(lǐng)域的成熟技術(shù)和產(chǎn)品，并借鑒了業(yè)界其他企業(yè)的技術(shù)落地經(jīng)驗(yàn)，最終制定出了謹(jǐn)慎且合理的預(yù)算。

• 就前瞻性而言，我們從“可能的服務(wù)”而不是“現(xiàn)有的功能”出發(fā)，既顧及到了內(nèi)、外部的各方面的變化因素、又參照了來年市場上的各種可能性調(diào)價(jià)方案。

• 在外包服務(wù)方面，鑒于疫情對(duì)于現(xiàn)場例行服務(wù)的需求驟減，我們?cè)谙鳒p了此類開支的基礎(chǔ)上，適當(dāng)?shù)卦黾恿耸潞蠹m正類服務(wù)水平的占比。

當(dāng)然，除了在預(yù)算上下功夫，我們也根據(jù)上述分?jǐn)傇瓌t，參考前面提到過的CMDB，制定了一張成本映射表。通過不斷新增開銷記錄、并動(dòng)態(tài)調(diào)整成本項(xiàng)，我們及時(shí)地跟蹤了各項(xiàng)成本開銷，并將其與預(yù)算進(jìn)行及時(shí)比較與修正。

小結(jié)

在疫情期間，IT支持部門難免會(huì)受到各方面的影響，甚至?xí)?ldquo;寒風(fēng)中瑟瑟發(fā)抖”。不過，我們團(tuán)隊(duì)卻能夠意識(shí)到：與其得過且過，不如乘機(jī)“修煉內(nèi)功”，提高競爭力，在當(dāng)下IT架構(gòu)和服務(wù)的可靠性(Reliability)、可維護(hù)性(Maintainability)、以及可服務(wù)性(Serviceability)上進(jìn)行加固，保持、甚至提高用戶的滿意度，與企業(yè)“共振”。正如一位IT同事在去年底的那句充滿文藝范的神總結(jié)：“用戶見與不見，我們團(tuán)隊(duì)都在那里，不舍、不棄。”

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】