【51CTO.com原创稿件】我们常把企业的日常运营，比作一艘商船航行在瞬息万变的河道上。我们的IT支持与服务，虽起不到掌舵的关键性作用，却能够协助企业不断修正航向，避开险滩暗礁。通过前面两篇讨论，我们基本明确了IT团队当前有什么，以及要保障什么，但是光靠这两方面显然是不够的。有人说：“没有方向，任何风都是逆风。”下面，我们来重点讨论IT治理的具体目标与方向。
能力管理
我们在此处所讨论的能力，通常是指那些能够达到既定性能效果的服务。也就是说，服务提供方需要在恰当的时间，提供恰当的服务水平。而针对能力的管理，则要求我们以成本效益的方式，来持续满足这一水平。具体而言，去年初，我们在企业内部开展了如下三方面能力的管理实践：
• 业务能力管理。即：需要我们达到什么。
- 首先，我们通过对当下服务进行需求分析，参考相应的流程，以便精准地锚定业务性能的预期。
- 接着，我们通过针对关键业务功能(Vital Business Function，VBF)的压力测试、以及恢复切换测试，以制定出与其允许中断的时长和数据量(RTO和RPO)相符合的应急预案和备份策略。
• 服务能力管理。即：我们能够达到什么。
- 业务的实现离不开基础架构和应用程序的交付能力。而此类能力往往需要SLA和OLA所建立的服务状态基线标准、以及阀值警报机制等一系列服务，来持续进行衡量。我们经过部门讨论，并借鉴业界惯例，制定出了服务在出现性能问题时的如下判定与诊断依据：
- 当然，考虑到本企业在不同地区，在软、硬件上的配置有所不同，以及内、外部不同用户的职级等属性，我们对某些相同的OLA，采取了差异化的方案。例如：对于总部的VIP用户、以及区域性数据中心，我们所提供的服务级别承诺，会略高于其他分支机构的普通员工。据此，无论是用户还是支持部门，都可以对标不同的服务期望与要求。
- 此外，我们会适当地将OLA中的时间要求，设定得小于SLA里的时间定义，以免出现本末倒置的逻辑错误。
• 资源能力管理。即：哪些会影响我们达标。
- 支持人员、或提供服务的第三方会通过对各类资源使用情况的监控、记录、分析、报告，以发现配给上的不足，找到不同应用场景下的性能临界点，并在服务出现中断前事先调配资源。
- 同时，他们要据此发现那些闲置的资源，进而在成本效益的前提下，调整供求平衡。
鉴于日常能力管理是IT治理的一项重要目标，我们配备了如下完备的人员架构，来确保能力管理的落地：
• 一线：主要是日常负责监控、记录、报告等例行工作的服务台(Helpdesk)。他们捕获影响服务能力的事故，并予以快速解决。如果服务台无法及时处置，则需要向二、三、四线支持资源升级。
• 二线：主要是系统和网络等技术职能部门的工程师。他们能够提供更全面、更深层次的修复与还原服务，并按需制定变通方案。
• 三线：主要是指那些负责软件开发、系统架构、以及IT管理的角色。他们会从IT服务的源头、或代码级别，进行问题的跟踪与诊断。
• 四线：则是指提供外包服务的外援。他们从第三方的角度，提供客户企业技术人员能力之外的专业服务。
与此同时，整个内部团队需要定期通过有针对性的技能与规范培训，来加强自身对于现有业务和系统的熟悉程度，以及能力管理的各项实操。
当然，为了保证各种基础性的网络线路、硬件备机、应用支持、以及云服务资源能够按需提供支撑，我们IT部门也与各种外部供应商签订了支持合同(Underpinning Contract，UC)。例如，为了避免出现以往自购资源时代，所采取的、死板的预分配模式，以及对网络带宽的被动管理，我们在云服务的“弹性伸缩”特点上“做功课”。通过与云服务商的协作，我们对当下的云端应用处获取了端到端式的状态监控权限。有了第一手数据，我们就能够及时地了解到业务方的实际消费状况、乃至服务本身的健康状态。据此，我们便能够在实现成本效益的前提下，动态调整容量，实时改进运能，进而修正监控基线，并最终形成正反馈。
值得一提的是，上面提到的两种约定与一种合同之间的关系，可由下图来表示：
问题管理
在上述能力管理的过程中，为了抑制不良影响、以及快速恢复常规的服务运能，相关人员需要快速找到那些所谓能够“治标不治本”的变通方法。此类方法往往比团队花费更多的时间去研究问题的症结，更容易被用户所接受和认可。不过，顾名思义，这些并非最终解决方案。只要时间允许，我们仍然需要通过调查分析，来确定问题的根本原因，找到长期有效的解决方案，进而减少中断的数量和影响。
在去年上半年间，随着各项IT现场工作趋于放缓，我们的团队有了更多的时间，去仔细思考并整理当下的问题管理流程。我们通过远程协作的方式，成立了一个专门的问题管理委员会。在借鉴业界处置标准的基础上，大家整理出了如下问题管理与控制要点：
• 对于那些需要人工干预的问题，委员会根据问题的特征和以往的经验，评估其影响的范围与程度。
• 在分析过程中，处理人员通过检查过往的记录，来判断其是否属于重现。如果是，则根据已知的处置方式，按需调用内、外部资源，着手整改并进行效果测试。
• 如果属于首次出现的问题，我们则会根据职能角色(如：读取系统AD目录)，以及组群类别，参考相关人员的手头工作量，以及实际处理能力，分派问题，以便他们跟踪、协作、控制并解决。当然，如果某个问题超出了本企业自身的处理能力，我们也会按需添置专业的技术与工具，或者及时转呈给外部专家，以寻求援助。
• 对于一些经过了各方面努力，仍无法最终解决的问题，我们会将“由谁负责跟进，现存哪些困难”等信息，标注并记录到已知错误数据库(Known Error Database，KEDB)中，通过定期予以评审和更新，以寻求有效的解决方法。
按照上述抽丝剥茧式的探究，处置人员最终会填写并交付出如下跟踪表格：
可见，在问题管理的过程中，我们并没有所谓“一劳永逸”的不二法门，而是需要做好打持久战的心理准备，持续钻研甚至要不断试错。
知识管理
无论是前面提到的能力管理，还是问题管理，都离不开相关领域的知识积累与储备。过去，我们往往依靠处置人员的个人经验，以及他们向其他成员的口传心授，以及手把手式的演示。而在疫情期间，我们更大程度上需要依赖对于知识库的查询，以获取及时必要的实用信息。下面，我们来讨论一下知识管理的相关实践。
早在几年前，我们IT支持人员就通过与业务部门的协作，完成了“字典式”的知识库(KB)和“家谱式”的配置管理数据库(CMDB)的构建。但是，它们实际上只能被称为“陈列馆”而不是“图书馆”。也就是说：除了在建成之初导入的一些存量知识，它们在后期的运营中，鲜少有新的知识被录入，更谈不上为IT日常运维提供准确有效的参考依据。
同样乘此抗疫之机，我们一边将那些散落在各处，甚至是一线服务台、二线工程师头脑中的知识，进行了收集、整理与分类;一边对两大类知识库进行了重构与细分。其中包括：
• 在功能划分上，
- 让KB偏向于记录各类常见技术问题的解决方法，以及针对某些业务应用与协作平台的相关说明。此类文档与说明往往是那些一旦被录入，就少有改动的静态知识。
- 让CMDB偏向于体现IT系统(包括：存储、主机、网络、以及应用等资产)的特征状态，以及业务应用背后的逻辑映射关系。这些信息属于会被频繁更新的动态知识。
• 在组成结构上，
- 将KB细分为已知错误库(KEDB)、事故问题记录库、应急处理参考库、以及常见操作使用库等。
- 通过预定义各类项目的名称、属性与特征标签，以方便不同角色人员，通过输入关键字，精准地查询并匹配到相关知识内容。
• 在内容提供上，
- 与外部知识提供商、及搜索引擎打通，方便用户在无法从当前KB中检索到知识信息的情况下，参考外部知识库。
- 通过统计分析知识条目的查阅率，提供针对内容结果的定级与排名。
- 允许用户通过关键字去订阅更新，自定义知识条目的优先级，以及对知识的准确性进行修订等操作。
• 在日常运维上，
- 引入了“知识众包的活水”，允许各类用户录入有价值的知识信息，并设置可搜索、可编辑的权限控制。当然，我们也配有专门的小组进行内容审核与查重，以保证知识输入的规范性和实用性。
- 在数据库维护方面，我们严格控制用户的更新流程与版本，以免出现知识内容的误删或错换。
• 在内容安全上，
- 做好数据库的细粒度访问控制，保障各类知识的机密性和完整性，防止敏感业务数据之间的相互混淆。
- 通过对查询者身份予以匹配，并采用最小权限原则，以开放不同视图的方式，适当地隐藏掉了无关的内容。
在去年的一年中，我们通过后台采集的数据了解到，各类用户角色都有过与知识库的良好“互动”。不但是那些普通用户，能够通过自助式的查询服务，从“大后方”获取解答与纠正问题第一手资料，而且我们的技术人员也能够通过持续录入与查找，了解并回溯到某些根本原因(Root Cause)的来龙去脉，以便更加从容的处置那些特定问题。
服务请求管理
我们在前面主要讨论了各项需要保障的目标。总的说来，我们主要着眼的是存量、或者说是当下现有的系统与服务。不可否认的是，我们的服务，乃至整个系统，都是会随着时间的推移和业务的发展，增量式地持续产生新的需求。因此，我们需要以有效且用户友好的方式，管理好那些往往由用户提出的新请求，以便在保证服务质量的同时，合理地促进IT服务的健康发展。
去年六月份，我们乘着内网服务门户(Portal)的改版之机，不但更新了前面提到的服务目录，而且开放了自助式服务请求的在线提交入口。当然，我们也会持续受理那些经由电子邮件、或通过向服务台电话告知等途径，发送的需求。针对五花八门且繁简不同的用户请求，我们事先归纳出了如下类别：
•交付类操作。如：要求提交服务报告，或更换打印机墨盒。
•信息类请求。如：应客户要求查询文件交换平台的登录信息，或是某个应用所需的最低硬件配置信息。
•资源类请求。如：用户因居家办公而申请笔记本电脑，或是研发团队为某项业务申请虚拟机。
•访问类请求。如：请求访问某个内网应用，或是某个数据表中的数据资源。
•使用类反馈。如：抱怨某个应用的远程使用体验，或是为支持团队的服务点赞。
服务请求一旦产生，我们会根据预先设定的流程，通过人工识别，或自动化映射的方式流转到后台。后台相关的职能人员或进程，会及时进行分析评估或转发审批。当然，我们最为常见的当属如下服务请求或诉求：
•故障申告。即：因无法获取现有的服务，而告知一线服务台相关的错误信息，并申请技术援助。对于此类请求，一般服务台会启用事故管理流程予以处理。
•服务咨询。即：如何获取现有的服务，或是如何进行下一步操作。此类问题相对较为简单，服务台可以独立处理。为了提高解决的效率，我们会让服务台尽可能地与用户端的界面保持同步。
•超时投诉。即：抱怨响应超时，或对现有的服务质量表示不满等。此时，服务台不但需要安抚用户的情绪，详细记录诉求，而且要及时给出合理的变通办法，并转呈相关职能部门跟进处理。
•新的要求。即：因当前服务不足，提出新的服务需求。当然，此类要求有时存在着表述不清，甚至是类别或属性错配的情况。这就需要服务台等受理人员通过与请求方的深入交流，基于合理性的判断，予以补充、修改、甚至是酌情驳回。
具体而言，我们会对各种新的服务请求，从如下维度实施合理性管控：
•重要程度。即：结合现有和已规划的业务，判断需求的重要性和紧迫程度。
•实现难度。即：根据现有和已规划添置的资源，界定其可行性。
•所需成本。即：综合考虑前期的开发、测试与购置成本，以及交付后的运营与维护成本。值得注意的是，这一点在去年以及今后会显得尤为重要。
有了上述维度的分析，我们便可以做出如下三种类型的回应：
•对于不具备可行性的请求，应当和提出方“摆事实、讲道理”， 有理有节地予以回绝。
•对于确实合理但实现难度较大的请求，可以通过与提出方进一步沟通，尽量找到让双方都能接受的折中或替代方案。
•对于切实可行的请求，则立即进行分类、分级、分期实施。也就是说，我们会对此类需求按照业务领域进行分类;在重要性与紧迫度上进行分级;并根据现有资源和交付难度分阶段予以实施。
与此同时，我们还会保留针对每一种服务请求的有效记录，进而达到：
•及时跟进、并报告服务响应的进展情况。
•便于衡量、并在日后改进现有的需求处置流程。
•向其他管理流程(如事故管理、问题管理、以及变更管理等)提供第一手的参考信息。
总的说来，服务请求管理的目标就是：要在控制好成本的基础上，保障服务的顺畅交付，并让请求者满意。因此，除了作为请求方和服务资源方的中间桥梁--服务台，能够及时受理、过滤、分类、转发、跟踪、以及反馈之外，我们还会按需让具备业务能力和专业技术背景的人员参与进来，全面研究、解析、设计，以推进新需求的最终落地。
结语
算上这一期讨论，我已分三次从日常服务运营的角度，和您探讨了在防疫这一年中，自己在IT治理方面的思考，以及本企业的管理实践。想必您已经看出，企业的日常IT服务从来不是简单的技术堆砌，而是要通过对于各种流程的梳理，在夯实人员管理的基础上，提高现有资源的驾驭能力，不断提升IT团队对于业务的支持与促进水平，并最终克服由疫情造成的无法现场实施等困难。
不可否认，本次疫情给不少跨国企业，以及企业里的IT团队的头顶罩上了一朵乌云。希望本系列能够成为镶在那乌云的边上的一丝金边，给大家带来些许思考与启示。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
