一、服务级别协议的devops可以怎么做？
简而言之，就是要通过devops，以信息化和系统化的手段管理服务级别数据，在提高数据准确性和完整度的同时，也降低了建立和实施服务级别协议管理的难度。结合使用自动化的监控技术和数据分析与生成统计报表技术，大幅减少以前需要人工手动处理才能完成的工作内容，让机器做更多的脏活儿、累活儿，把处理结果或发现的问题“通知到”管理人员即可。把管理人员从繁重的重复性工作中释放出来，把时间和精力投入持续的流程优化、过程自动化与服务改进中去。
可以简单地归纳为下面几个建设目标：
- 简化和自动化部分管理流程以提高运转效率
- 自动化对服务水平的监控和报警通知以有效提高服务质量
- 信息化对服务级别协议数据的管理以支持统计分析
- 系统化的挖掘服务级别协议中的数据价值
- 可视化的多维度的展示重要统计结果，定期自动生成和输出统计报表
- 集成化的管理上述功能并展示统计数据
在ITIL中已经提供了针对服务级别协议管理的最佳实践，下面先简要介绍一些ITIL的最佳实践知识，这些是我们做好这件事情必备的一些背景知识。但这并不是说，我们在自己的公司落地这个管理过程时，需要一成不变得按ITIL说的做。尤其是在结合使用devops技术后，我们更加有必要量体裁衣，根据自己的业务服务特点、需求和管理痛点，对“标准答案”进行适当的删减和定制调整。
需要特别注意的一点是，itil+devops并不等同于就是把原来通过excel来管理的工作内容做信息化。缺少足够深入的思考和设计优化，简单地制作和交付“web版”的excel，价值有限。
二、在ITIL中怎么管理SLA
1、术语说明
SLA：Service-Level Agreement的缩写，意思是服务等级协议。服务供应商和客户之间签订的书面协议，该协议中明确规定了服务和约定的服务等级。一个完整的SLA同时也是一个合法的文档，包括所涉及的当事人、协定条款(包含应用程序和支持的服务)、违约的处罚、费用和仲裁机构、政策、修改条款、报告形式和双方的义务等。同样服务提供商可以对用户在工作负荷和资源使用方面进行规定。传统上，SLA包含了对服务有效性的保障，譬如对故障解决时间、服务超时等的保证。但是随着更多的商业应用在Internet的广泛开展，越来越需要SLA对性能（如响应时间）作出保障。这种需要将会随着越来越多的商业在Internet 的开展而重要起来。
SLO：Service-Level Object，服务等级目标。
实际上，SLA的保障是以一系列的服务等级目标（SLO）的形式定义的。服务等级目标是一个或多个有限定的服务组件的测量的组合。一个SLO被实现是指那些有限定的组件的测量值在限定范围里。SLO有所谓的操作时段，在这个时间范围内，SLO必须被实现。但是由于Internet的统计特性，不可能任何时候都能实现这些保障。因此SLA一般都有实现时间段和实现比例。实现比例被定义为SLA必须实现的时间与实现时段的比值。例如：在工作负荷<100 transaction/s前提下，早上8点到下午5点服务响应时间<85ms，服务有效率>95%，在一个月内的总体实现比例 >97%。
OLA：Operation-Level Agreement，运维操作级别协议。
与SLA一般是面向公司外部客户所不同的是，OLA是公司内部多个相互之间有服务提供与服务消费关系的部门间所签订的关于指定服务的服务等级规定。
服务目录：服务目录以客户的语言对服务进行描述，同时对IT部门能够提供给客户的相关服务级别做出概要说明。
2、服务级别管理的目标与主要活动
服务级别管理的目标：
- 定义、设计与客户商谈制定服务级别协议并进行管理；
- 维护提高IT服务质量，与客户的业务需求保持一致；
- 监控，衡量汇报IT服务交付水平并制定服务改进计划。
服务级别管理的主要活动：
- 服务级别协议的建立，这个大多是位于服务合同的恰谈和签订阶段，本阶段运维运营团队需要参与到对合同中的服务级别条款的审核工作中去。
- 计划
- 制定服务目录、起草SLAs
- 与客户商谈
- 协助起草供应商支持合同、运营级别协议并回顾
- 与客户签订SLAs
- 服务级别协议的实施
- 实施SLAs
- 监控
- 生成服务报告
- 服务级别协议的定期回顾和改进
- 定期召开回顾会议
- 制定并实施服务改进计划
- 对服务级别进行变更
- 针对流程的质量控制
- 现有流程评估
- 制定改进计划
- 审批改进计划
- 执行改进计划
- 回顾
3、服务级别管理的主要角色
- 服务级别经理（领导）
- 协议维护人（干活儿的小兵）
- 质量经理（审核与监督者）
服务级别经理和协议维护人的主要工作内容基本上就是从事服务级别管理的几个主要活动方面的工作内容，这个比较容易理解。
那么，质量经理是怎么做审核与监督工作的呢？
- 确保各流程完成服务级别协议中的目标；
- 制定改进计划持续提高整体服务质量。
即，发现问题和改进问题。
4、服务级别协议的输入项与输出项
非常有必要了解一下一般意义上的服务级别协议管理，都需要收集哪几类材料，都需要交付哪几类的成果。
输入项：
| 编号 | 输入项 | 来源 | 周期 |
|---|---|---|---|
| 1 | 业务需求 | 客户 | |
| 2 | 服务级别需求 | 客户/业务关系管理 | |
| 3 | 支持合同 | 供应商管理 | |
| 4 | 运营级别协议 | 运营支持部门 |
输出项：
| 编号 | 输出项 | 去向 | 周期 |
|---|---|---|---|
| 1 | 服务目录 | 客户/各运营部门 | 1年 |
| 2 | 与客户签订的服务级别协议 | 客户/各运营部门 | 1年 |
| 3 | 已回顾的支持合同 | 供应商管理 | 需要时 |
| 4 | 已回顾的运营级别协议 | 各运营部门 | 需要时 |
| 5 | 服务级别履行情况报告 | 客户/质量经理 | 1年 |
| 6 | 定期回顾会议纪要 | 客户/各运营部门负责人 | 1月 |
| 7 | 服务改进计划 | 相关人员 | 需要时 |
5、服务级别管理与ITIL其它管理流程的联系
服务级别管理在IT服务管理流程中扮演了一个中心角色，它与其他服务支持和服务交付流程都有密切的联系。服务级别管理充当IT部门与客户之间沟通的一座桥梁，它需要以客户的语言充分与客户沟通、了解掌握客户业务需求，而后IT运维部门在组织内将这些业务需求转化成具体的技术说明和活动。服务级别管理流程为其它各流程提供服务级别协议和服务级别目标，IT运维部门为能实现服务级别协议中规定目标提供支持交付服务。
如上图所示，有很多工作任务都可能会影响到我们是否最终可以按照约定的服务等级协议向客户交付服务。
三、ITIL+DEVOPS在服务级别管理流程的实践案例
下面简单介绍一下我做过的实践案例，主要是以介绍我们需要做什么以及怎么做的简单示例说明为主，结合一些图示辅助理解。
1、流程建设要求
如果还没有明确的服务级别管理流程方面的制度或规定，那么首先要解决流程建设的问题，需要有一份关于这个流程管理的制度性文件。这份制度文件需要能够得到公司管理层的认可并在公司范围内作为强制性规程文件予以颁布。
通过这份制度性文件要能够保障服务级别的建立、实施、定期回顾和改进这些工作能够得到顺利的贯彻执行，需要设立专职或兼职的岗位，以支持落地流程经理、协议维护人以及质量经理的流程角色。
2、信息化系统建设要求
信息化是手段，并不是目的。如果没有几个客户，且总共也只是几份服务合同，就不必搞什么信息化啦，不够成本的。
信息化可以是方方面面的，在面对很多的部门、很多的对接人、很多的设备和应用系统以及很多的客户的时候，信息化是帮助我们管理好这么庞杂的信息的一种重要工具。
简单列举一些比较重要的信息化管理工具：
- 流程管理与审批类工具，如办公OA系统、任务协同系统，最好是能把针对服务级别的建立、实施、变更与回顾都落地为一个个信息化的申请与审批管理流程，体现出多个重要角色之间的分工。
- 项目管理类工具，如jira、禅道、project，为需求、项目、任务工单的定义、分派、执行和审计提供支持。
- 监控类工具，如zabbix、cacti、promethus、grafana、监控宝等，为服务质量的监控提供全方位的支持。
- 客户信息管理类工具，如各种CRM系统。
- 知识共享类工具，如mediaWiki、Confluence等，我们制作的服务报告、我们定期召开的回顾会议以及制定的服务改进计划，这些知识仅仅做到备份归档是不行的，需要能在部门或团队范围内方便地分享。
3、一些工作会议方面的要求
总有一些事情是需要放在部门或团队的工作会议上讨论的，比如对近期团队工作的回顾、对近期重要故障事件的分析与讨论、一阶段的工作安排以及对服务改进计划的讨论等等。
如果要做好服务级别协议的管理，以下几个会议是不可少的：
- 定期召开回顾会议，回顾与服务级别管理有关的重要事件、问题和故障，建议每半月或1个月召开一次，可以与团队内部的定期工作会合并召开；
- 定期召开客户服务级别协议评审会议，对客户服务合同中的协议条款进行评审，更新过时的服务条款，评审近一年的服务级别履行情况报告，这类会议一般是每年安排一次；
- 定期召开服务改进会议，讨论服务改进计划和相关的任务安排，会议召开周期——需要时；
- 定期召开流程改进会议，讨论流程改进计划和相关的任务安排，会议召开周期——需要时；
关于怎么召开会议需要特别注意的三点是：
- 不要召开没有充分准备的会议，如果你准备为这次会议安排两小时的时间，应该花1.5小时用于准备会议内容。
- 会议需要有内容模板，需要有会议流程，最好也做一个会议效果的评审。
- 会议纪要不该停留在大家的本子上面，需要有团队知识共享的信息化平台可以管理、搜索、查阅历史会议纪要，方便大家随时回顾会议内容并安排相关的工作任务。
4、利用DEVOPS打破你的信息孤岛
如上所示，各种用途的管理工具可谓是五花八门，在此之外，很多公司还有大量自研的一些特殊用途的工具或系统。
我们再回顾一下利用DEVOPS来提高ITIL服务级别管理水平的几个目标：
- 简化和自动化部分管理流程以提高运转效率
- 自动化对服务水平的监控和报警通知以有效提高服务质量
- 信息化对服务级别协议数据的管理以支持统计分析
- 系统化的挖掘服务级别协议中的数据价值
- 可视化的多维度的展示重要统计结果，定期自动生成和输出统计报表
- 集成化的管理上述功能并展示统计数据，可以有很多个分散的小系统实现一些专业用途的功能，但应该有一个提供数据集成与功能集成的大平台，聚沙成塔！
上述建设目标中每一项都很重要，不过要属最后一个的功能集成是难度最大的。
举个例子，我们新合作的一家客户，提出一项比我们当前监控级别更严格的服务指标要求。我们能不能直接在一个统一的管理平台上，为这个客户新增一个关于服务指标的监控项。能不能直接查看到一个指定的客户，当前都关联了哪些监控项的信息。
再举个例子，我们能不能根据服务级别协议数据对客户进行分类，例如客户的优先级、是否需要服务报告、是否要求故障通知、是否要求故障报告以及是否会触发索赔等。根据分类统计信息，我们可以为优先级高的客户提供更多的服务质量保障措施，也可以及时发现哪些客户有服务报告的使用要求，并安排人工、甚至是自动化的服务报告定期发送服务。
服务级别管理流程，与ITIL的十几个其它管理流程有接口关系。这些关联关系该怎么去建立、维护和发挥出应用的数据价值来呢？
下图是一个简单的针对服务级别协议管理功能的设计脑图，展示了怎么以devops的方式把SLAs服务级别协议管理起来！帮助大家有一个更直观的认识。
5、DEVOPS技术栈简介
（1）Python/Django
运维界的运维开发web平台框架的最佳实践。当然也有很多人会使用flask或tornado等框架，但无疑Django是门槛更低，功能更丰富的实力选手。
（2）SaltStack
配置管理界的瑞士军刀。不像Puppet那样复杂，说起来其实并不会有那么多公司能有机会拥有超大规模、超复杂的技术系统。也不像Ansible那样简易，处在二者之间，刚刚好。
我们使用SaltStack处理所有需要与远程的业务主机交互才能完成的任务，无论是远程执行命令、重启应用、安装软件、更新配置或是传输文件。SaltStack的消息总线设计和事件管理设计，使得我们在管理分布在全国各地IDC中的服务器与应用服务时，非常得心应手。
考虑到批量运维操作的潜在风险，我们禁止在生产环境中手动执行批量管理操作，必须在经过了反复得验证测试并集成到了自动化运维平台中后，在web界面中使用。
（3）Javascript/JQuery
各种在web页面上的小功能以及异步调用后台服务接口的技术实现。