IT运维支持如何转化为服务

孤独的骗子

关于IT服务能力的介绍，本期标题中主动式、可量化、构建IT运营服务三个关键词概括了我对IT服务能力的理解，其中IT运营服务在上一篇《》作了一些分析，本篇从ITIL、ISO20000、ITSS方法论对服务做补充。另外，IT服务能力主要以ITSM方式提供IT服务，关于ITSM的实现方式在之前关于servicenow的文档中也作了介绍，本篇不介绍在ITSM上的服务具体实现，而是从主动式、可量化两个角度进行扩展。

一、ITIL、ISO20000、ITSS中的服务

老规矩，第一章先来对全文命题的名词做分析调研，本篇的名词是IT运营服务，其中IT运营在上一篇文章作了分析：即以业务为本，以稳健运维、风险可控为底线，从组织、流程、工具三个维度构建一套标准化、可扩展性的运营管理体系，持续提升服务水平，提高企业效能、降低成本。以“控底线、优服务、提效能、降成本”作为实施的业务指导思路，它要为组织架构调整、流程标准化、运行保障、效率提升、服务交付、成本优化提供技术支撑。

至于服务，在运维领域中成熟的方法论有个：ITIL、ISO20000、ITSS数据中心运维服务能力成熟度。三者虽然同为指导方法论，也有一些区别，三者的边界大致为：从定位看，ITIL是一套IT服务管理最佳实践框架，ISO20000与ITSS数据中心运维服务能力成熟度是一种标准；从内容看，ITIL针对管理流程或服务的最佳实践做了定义，即告诉我们IT服务应该要做成什么样，ISO20000是在ITIL基础上设计的标准，告诉企业要如何获得标准化的IT服务管理能力，ITSS从人员、流程、技术、资源四个方面，以PDCA为指导思想对服务成熟度制定了四个持续优化的可测量的级别；从对象与认证看，ITIL针对个体，ISO20000、ITSS针对组织的认证。

1）ITIL

ITIL最早来自英国，经历了V1到V3的升级，其中V3的最大进步是在V2的基础上引入了服务生命周期的理念，这5个生命周期包含在服务战略、服务设计、服务转换、服务运营、持续性服务改进（分别对应ITIL的5本核心书籍），包括了IT服务从企业业务需求到服务支持、交付，再到持续优化的内容。5个生命周期大概的意思分别是：

• 服务战略：制定IT运维或运营组织的定位，角色，需要提供服务范围，是针对IT服务的战略性决策。
• 服务设计：根据服务战略对服务的规划，对服务进行设计，以满足企业对IT服务的要求。
• 服务转换：是将设计的IT服务替代己有管理手段的过程，这个过程要兼顾己有的IT能力有序与新设计服务的可用。
• 服务运营：是将服务真正开始推广使用在服务支撑过程阶段，需要适应企业对IT服务能力的需求。
• 持续性服务改进：是对服务的实施过程中存在的问题进行持续的优化。
  

总的来说，这5个生命周期的设计能看到PDCA的思路，能够适应业务变化来不断提高IT服务质量。ITIL可以让IT运营组织从原来技术驱动的角度转化为业务驱动，提高IT与业务的一致性，将IT内部管控、可用性、安全性、容量、连续性等管理标准化，提高IT服务质量，可以促进被动到主动，从非透明的管理到可量化、数字可视的管理精细化转变。

在ITIL的实践过程中，通常是ITSM的方式进行落地，事实上ITSM也主要以ITIL作为理论基础进行设计，虽然ITIL提出了差不多30种服务，但用户在应用ITIL时可以自行决定落地哪些流程或服务，也可以对IT服务进行扩展超过ITIL的定义，通常在国内主要应用在事件、变更、问题等内部控制类的流程服务。从我的认识来看，IT服务的思想应该落地在整个生命周期，运维组织中的每一个小团队，每一个人都应该以主动服务供给作为工作导向，才能发挥ITIL更大的价值。

2）ISO20000

ISO20000是基于ITIL最佳实践进行构建，是一套通过管理和规范服务流程确保IT服务质量的国际标准。ISO20000的认证适合IT服务的提供者，可以是甲方内部的IT组织，也可以是提供IT服务的乙方，通常来说，获得ISO20000在一定程度上说明这个组织对管理流程进行了标准化，具备较好的管控能力。ISO20000由规范与实施指南两部份组成。因为具备标准的认证作用，规范介绍了企业要实施ISO20000的服务管理需要完成的工作，列出一份强制的流程控制清单，认证的企业需要达标。实施指南则描述了一些最佳实践，是对第一部份规范中的标准进行补充，是希望认证的企业去做这些实践。

对于我们金融企业来说，通过ISO20000认证的过程中也是一种标准化梳理与落地的过程，这个过程能让企业的IT运维组织的工作可量化，为数字化工作提供了数据基础。

3）ITSS.1

ITSS的数据中心服务能力成熟度模型是以数据中心作为研究对象，以人员、流程、技术、资源四个维度的服务能力水平作为分析评估切入点，是由国内提出的标准规范。ITSS提供的这个能力成熟度以PDCA的持续优化的思路，将成熟度分为4级，并将能力细分为30几个能力项，不同级别下的能力项要求有所不同，是一个不断提升的过程。我对ITSS这个模型的认识是去年做所在团队能力水平调研时进行了解，从有限的资料学习看，ITSS涉及的面比ITIL或ISO20000更广，而且更接地气，从战略发展、运营保障、组织治理等多个方面进行细分，是企业细化IT整体服务能力，量化能力成熟度的一个比较好的模型。

4）其它

关于运维/IT运营方法论，业内分享更热的是以devOps、AIOps这类思想，有不少新兴的2B厂商或业内大牛会认为ITIL的流程管控过重，认为ITIL己不能适应现在运维管理的发展需要，应该采用更敏捷的方式构建运维管理体系。现阶段，我对这种观点几点想法，第一，devOps、AIOps是一种更为先进的理念，也有不少组织获得了成功，但现在更多的声音是认为devOps这类是一种思想，标准化程度与及周边的工具支撑还远不如ITIL、ISO20000、ITSS成熟；第二，很多认为ITIL是落后思想的观点可能是出自未真正落地ITIL的组织，或将ITIL理解为框住自动化流程的审批类思想，或是因为很多ITSM的厂商在推动业务时主要以内部流程管控为主等等原因，其实如果真正以ITIL的服务全生命周期的思想去构建ITSM，ITSM的构建不仅能提高IT管控、服务水平能力，同样也能提高组织的工作效率，就像servicenow官网中提到的ITSM产品特点：提升效率与交付能力，转变IT影响力；第三，在金融行业内，以务实的角度看，ITIL、ISO20000、ITSS能为企业带来更快、更经济的成效，适合在整个组织中落地，devOps则可以作为局部环节的关联补充。

2、从被动到主动

被动一词很好的体现了运维人员的工作状态，很多运维团队以事件驱动的被动操作为主，这种工作方式会导致运维人员的工作无法连续性，服务交付碎片化，IT资源缺乏统筹协调，不利于服务质量的持续提升。我归纳了几点关于主动服务的思路：

精细化分工：要打破被动式运维的工作状态，最重要的是要有一个IT服务可持续优化的机制，通过不断的分析当前组织存在的效率、质量、安全等问题，并标准化流程，构建工具来持续优化问题。精细化分工可以从两个层次改善持续优化的问题，首先，针对以往操作性的工作进行归纳，有助于提高这类工作的熟练程度与服务质量，也有利于集中资源对这类集中式的操作性工作进行分析优化，类似于ECC的事件集中管理、服务台、集中数据维护、办工支持等；其次，从整个组织看，流程的标准化、工具的引入也需要有独立的人员去受理痛点需求，主动分析流程管控不足、自动化程度不够、效率不高等现状，精细化分工有助于从原来被动的人力资源中释放一部份独立的人员进行这类计划性工作。同时，有些岗位分工需要进行调优，比如以往维护经理的一些职能可以考虑独立出服务经理的角色，这类角色也可以考虑是一个横向兼职的角色。

客户管理意识：客户管理是区别于用户管理，即需要IT运营组织内的每个角色都要有主动提供IT服务的意识。一方面，组织内的成员需要理解企业、IT运营组织在企业的核心价值是以业务为本，为业务更好的运营提供IT支撑。同时，要让IT运营组织里不同的团队清楚所在岗位的具体职责，理解哪些重要的IT服务能力，哪些是工作底线，针对底线的服务能力需要标准化，并通过数字量化到KPI，建立服务能力的及格线。同时，要在底线的基础之上，不断的优化服务能力，由围绕运行保障的能力基础上丰富到其它IT服务能力上。另一方面，要理解服务消费方。团队成员要理解服务的消费方是谁，消费方有什么诉求，比如业务运营的团队的主要消费方是业务人员，业务的诉求是业务的连续性，更高效IT资源支持；DBA的主要消费方是业务运营团队，业务运营团队的诉求是数据库的高可用、高性能，出问题时快速的数据库问题定位所需的工具支持；运营工具开发团队的消费方是业务、系统、硬件、网络的纵向运营团队，他们的诉求是需要更快的拥有IT工具支持。

主动服务的工作氛围需要标准化支撑，精细化的分工，团队文化、持续的优化需要标准化的管理流程与工具、专业的人员进行管控才能有序的落地。同时，IT服务标准化可以避免无原则性的服务供给。比方说，业务或研发团队肯定希望变更交付越快越好，但IT运营团队需守住业务可用性保障的底线，有些计划性的流程还是必须要有，我们在实施上要多考虑计划性，比方说CAB的计划评审机制就需要在多个层面让业务、研发、测试提前知道相关规则，让他们能提供做好计划来适应这个规则，可以考虑在公司内提前修改应用变更管理办法，每一年、每个月根据实际情况提供更细化的CAB计划。

3、从尽最大努力到可量化与可视化

运维组织里的管理考核通常以服务台咨询响应率，工单处理及时率，应用可用性等指标，故障处理的时效性等，这些考核指标有底线思维的特点，这种特点容易造成运维组织只有及格与不及格的评价，组织内对员工的要求更多的是尽最大努力做好基本保障，这种工作特点不利于IT运营服务水平的持续提升。造成这个问题的主要原因是团队缺乏量化IT服务能力，没有量化能力就无法给组织整理一条服务能力的基线，自然无法动态的评价IT服务能力做得好不好，所以IT服务能力要持续提升需要有量化IT服务能力的运营数据支撑，运营数据包括监控（事件、性能KPI）、日志、CMDB、业务指标、流程或运营操作数据，具体介绍参见ITOA的文章。

有了量化IT服务能力的运营数据，还需要有良好的可视化。一直以来，不少人觉得可视化只是一个面子工程，是一个锦上添花的环节，我的观点是对可视化的一个误解与低估，可视化是工具建设中极为重要的一环，良好的可视化可以促进工具的落地效率，事实上很多工具项目失败的原因就是因为不重视可视化的建设。另外，可视化其实是将人头脑中形成的最佳实践以计算机的方式呈现出来，它体现出我们对运维工作的理解达到什么程度。同时，我们将运维数据公开、透明，实现数据共享，并通过可视化让数据的理解得到一致化，将实现对IT资源与服务能力全局掌控，进而发挥数据驱动运维。引用一位朋友对可视化的描述：可视化是将复杂世界简单化，让人能更好的理解。

可视化的实施不仅仅是单个工具，还需要从工具体系角度进行全局性的可视化设计，建立可视化标准化，比如主色彩的配置，字体，风格，操作交互方式等，同时，建立场景驱动的可视化也是一个方向，场景驱动的可视化区别于传统意义上的门户，通常来讲门户主要是信息、调用链的整合，场景驱动是以日常工作的最佳实践为基础进行数据、操作、流程等多环节的可视化，关于场景驱动的可视化后续再专门写文章总结。

其它：

最近，有朋友提近来写的文章码字太多，信息量太大。为减少枯燥程度，本篇在收尾部份增加一个最近设计的IT服务入口的工具场景来收尾（仅思路，暂未落地）。

1）背景：IT运营工具体系涉及很多工具，且大部份工具是以IT的术语进行设计，对于工具的客户准确找到工具或服务并不容易，所以需要设计一个IT服务统一入口辅助各类工具更好的服务交付，需支持工具、服务、文档、可视化看板等服务支撑。

2）参考思路：

参考了servicenow与百度的设计

3）设计说明：

图一是初始视图，主要包括服务检索区域与常用工具区域。图二是检索后的视图，主要包括检索后的视图：

- 初始视图：

在检索视图方面，考虑到了IT服务涉及面向IT组织内部的服务与面向企业内IT部门以外的服务，两者区别主要是后者更关注服务的结果，他们对技术语言的理解能力层次多样化，往往是采用自然语言的方式获取IT服务，像一个新入职的业务人员想要IT运营组织为他办理入职所需要的IT环境的服务全部清单，而不希望了解服务目标中细化的办工机器申请、电话申请、终端IP服务、互联网权限、OA权限、文档协作权限等零散服务入口，为了更好的优化服务，检索需要为非IT人员提供面向自然语言的IT服务检索入口，检索后将提供服务清单。

-检索后的视图：

检索后的视图主要按不同的内容进行分类，从IT运营服务的特点进行了以下分类：工具、服务、文档、看板，其中工具是指工具入口，由工具工厂支持，服务主要由ITSM支持，文档由运维文档管理工具支持，看板主要是为了支持己有的grafana可视化工具的定制化视图