【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】
