【廉环话】防疫一周年后的IT治理思考 --能力、知识、问题与请求管理

原创
CIOAge
我们常把企业的日常运营,比作一艘商船航行在瞬息万变的河道上。我们的IT支持与服务,虽起不到掌舵的关键性作用,却能够协助企业不断修正航向,避开险滩暗礁。通过前面两篇讨论,我们基本明确了IT团队当前有什么,以及要保障什么,但是光靠这两方面显然是不够的。

[[383049]]

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

 

责任编辑:华轩 来源: 51CTO
相关推荐

2021-02-07 10:24:05

IT架构防疫

2021-03-11 09:00:00

IT防疫网络

2021-03-24 09:00:00

IT管理运营

2021-03-17 09:00:00

IT管理设计

2021-02-21 09:00:00

IT运维运营

2021-04-29 09:00:00

IT系统安全

2021-04-19 09:00:00

运维IT企业

2021-04-08 09:00:00

IT运维运营

2010-12-23 18:05:49

2019-07-19 13:54:26

2016-09-29 10:56:32

信息安全人员治理安全管理

2016-12-15 09:46:15

信息安全资源治理廉环话

2016-11-17 10:16:37

2016-09-18 09:42:50

2016-11-24 08:25:41

2012-02-13 10:09:01

2019-06-06 19:01:05

GDPR数据合规进程

2013-08-02 10:02:11

Windows 8 R

2009-07-07 17:47:43

App Store

2012-03-16 09:36:18

Amazon Apps亚马逊

51CTO技术栈公众号