3.2 运维服务
运维服务包括供给硬件、供给软件，或者支持各种不同的IT功能。由运维提供的服务，还包含服务级别协议（Service Level Agreement，SLA）的规格说明和监控、容量规划、业务连续性以及信息安全。
3.2.1 供给硬件
硬件可以是组织拥有的物理硬件，也可以是由第三方或云供应商管理的虚拟硬件，也可以是由个人、项目，或者大型组织中的一部分所使用的硬件。表3-1展示了这些可能性。
表3-1 个人、项目和组织使用的硬件类型
使用者 物理硬件 虚拟硬件
个人 笔记本电脑、台式机、平板电脑、智能电话机 用于开发和单元测试的虚拟机
项目 集成服务器、版本控制服务器 用于集成和版本控制的虚拟机
组织 用于打印机、网络基础设施等服务的服务器 用于组织范围的服务的虚拟机
物理硬件。
个人硬件。个人硬件包括笔记本电脑、台式机、平板电脑和分配给个人使用的电话机。通常，运维将使用他们提供的标准配置。实际的硬件订购和配置到底是由运维还是由个人自己完成，在不同的组织之间是有所不同的。标准化配置的强制程度在不同的组织之间也有所不同。一种极端情况是，运维提供给每一个员工一组被锁定的设备，而员工只能装载被批准的软件并进行配置。配置之间的兼容性是由标准化来提供的。
项目硬件。项目硬件通常包括集成服务器和版本控制服务器，尽管这些硬件可能在组织范围内进行管理。项目硬件的需求由项目来决定，运维可能会因组织范围内的指派，或项目与运维协商后参与订购、配置和支持项目硬件。
组织范围硬件。这种类型的硬件是由运维负责的。任何数据中心或者常规可用的服务器（如邮件服务器）都是由运维管理和运行的。
虚拟硬件。虚拟硬件也可以是个人、项目专属或者组织范围的。它遵循物理硬件的模式。项目通常负责虚拟项目硬件的规格说明和管理，而运维则负责说明和管理组织范围的虚拟硬件。运维通常负责虚拟机的整体使用情况，并且当项目考虑他们的虚拟硬件需求时，运维可以提供预算支持。注意，除了设备、打印机和数据中心的网络基础设施外，很多项目或组织级的物理硬件都是可以在私有云或公有云资源上被虚拟化的。
3.2.2 供给软件
软件可以是内部研发（也可能是通过合同外包），也可以从第三方购买。第三方软件可以是项目特定的，这种情况下，它遵循我们对硬件的处理模式（软件的管理和支持都由项目负责）；或者是组织特定的，这种情况下，软件的管理和支持由运维人员负责。防止内部研发的软件延期是DevOps的一个驱动力，我们将在本章的最后回到传统的运维和DevOps之间的关系。
表3-2显示了不同类型软件的职责。
3.2.3 IT功能
运维活动支持不同的功能。这些功能包含：
服务台的运维。服务台的员工负责处理所有的事件和服务请求，并作为所有问题的第一级处理者。
技术专家。运维团队通常有网络、信息安全、存储、数据库、内部服务器、Web服务器和应用程序以及电话的专家。
IT服务的日常供给。这些包含周期性和重复性的维护运维、监控、备份以及设施管理。
包含在DevOps的运维端中的人通常来自最后两类。日常IT服务包含提供新的软件系统或当前系统的新版本，并且DevOps的主要目标是改进这个过程。正如我们将在第12章中的案例研究看到的那样，信息安全和网络专家也要加入DevOps，至少参与持续部署流水线的设计，在理想情况下，部署流水线在组织内是共享的以提升标准化和避免随时间而发生漂移（drifting）。
3.2.4 服务级别协议
一个组织和外部服务供应商有大量的服务级别协议。例如，一个云供应商需要保障一定的可用性。传统上，运维的责任是遵守监控和确保服务级别协议。一个组织和它的客户也有大量的服务级别协议。运维按照惯例为确保组织实现其外部服务级别协议负责。与外部服务级别协议一样，运维通常负责实现内部服务级别协议的要求。例如，一个组织拥有自己的网站或电子邮件服务。在DevOps运动中，开发和DevOps变得要承担更多的应用服务级别协议和外部服务级别协议的责任。
所有这些功能都包含监控和分析来自服务器、网络和应用的不同类型的性能数据。参见第7章关于监控技术的大量讨论，以及第10章关于从业务视角来讨论监控什么内容。
3.2.5 容量规划
运维负责确保组织可以获得充足的计算资源。对于物理硬件，这包含采购和配置机器。包括采购和配置这些硬件的前置时间需要考虑在计划之内。
更重要的是，运维负责提供充足的资源，以便一个组织产品的消费者可以浏览产品、下订单和检查订单的状态等。这包含预测工作量和工作量的特征。有些预测可以基于历史数据，但有新产品上线或推广活动时，运维也需要与业务协作。DevOps强调运维与开发之间的协作，但还有其他干系人参与协作活动。例如，在容量规划中，其他干系人就是业务和营销的人。利用云的弹性、为使用付费的模型以及提供新的虚拟硬件的便捷性，容量规划越来越变为运行时监控和自动伸缩的工作，而不是规划硬件采购。
3.2.6 业务连续性和安全
在灾难发生时，一个组织需要保持关键服务可用，这样内部和外部客户都可以维持他们的业务。组织可以使用2个关键参数对能够维持业务连续性的多个可选方案进行成本/收益分析：
恢复点目标（Recovery Point Objective，RPO）。当灾难发生时，对数据丢失的最长容忍时间是多少？如果每小时备份数据一次，则恢复点目标为1小时，因为丢失的数据可能是自上一次备份后的累积量。
恢复时间目标（Recovery Time Objective，RTO）。当灾难发生时，不能提供服务的最长容忍时间是多少？例如，如果一种方案需要10分钟来获取在另一个数据中心的备份，再需要5分钟来实例化新的服务器以便使用这些备份数据，则恢复时间目标为15分钟。
这两个值是独立的，因为有些数据的丢失也许是可以容忍的，但不能提供服务则是不能容忍的。也可能能够忍受没有服务，但不允许丢失数据。
图3-2显示了3种可选的备份方案，它们有不同的恢复点目标。在第11章的案例研究中，我们描述了一个组织所采用的方案。另一个方案则会在第13章中讨论到，这种方案使用了云供应商的服务来进行复制。
图3-2 数据库备份策略：a）由一个独立的代理实施备份；b）由数据库管理系统实施备份；
c）数据库管理系统实施备份并将所有的事务记录到日志中[标注法：架构]
1）图3-2a显示了一个外部代理（备份进程），它定期复制数据库。不需要应用程序支持，但备份进程应该复制数据库的一致版本。也就是说，当时没有更新正在应用。如果备份进程对数据库管理系统是外部的，那么事务可以继续进行，因此备份应该谨慎地启动。这种情况下，恢复点目标为两次数据备份之间的时间间隔。也就是说，如果一个灾难正好先于启动备份进程，则从上一次备份后的期间内的所有变更都会丢失掉。
2）图3-2b显示了一个没有外部代理的可选方案。这种情况下，数据库管理系统定期创建一个复制版本。图3-2a和图3-2b的区别在于，在图3-2b中，确保一致性是由数据库管理系统完成的。而在图3-2a中，一致性则是由一些管理启动备份进程的机制来保证的。如图3-2a所示，恢复点目标为两次复制之间的时间周期。如果这个数据库是一个关系数据库管理系统（RDBMS），它提供一些复制（也就是说，一个事务只完成一次提交，当复制数据库也已执行了该事务时），则在灾难发生期间丢失的事务就是那些还没有提交给复制数据库的事务。然而，每一次事务的开销都会增加。
3）通过数据库管理系统对每一次的写入都进行日志记录，将图3-2b修改为
图3-2c。这样，数据就可以通过首先备份数据库，然后重放日志中的条目进行再创建。在恢复时如果可以得到日志和备份数据库，则恢复点目标为0，因为所有的数据或者在数据库中或者在日志中。提交事务到生产数据库的协议是，只有当各自的日志条目已经写入数据库中后才能提交事务。虽然这个方案中可能有些事务还没有完成，但是已经完成事务的数据不会丢失。这个方案被高可靠性的关系数据库管理系统使用，也被分布式文件系统使用，例如Hadoop分布式文件系统。当考虑恢复时间目标（即，在发生停电或灾难后让应用程序重新运行所需要的时间）时，备选方案包括：使用多数据中心（在第11章案例研究中讨论）；使用由云供应商提供的独立的可用区或域；使用多个云供应商。
通过考虑恢复时间目标和恢复点目标，业务可以对各种灾难恢复技术进行成本/收益分析。有些技术将包含应用系统架构，如在不同的副本上复制和维护状态一致性。其他技术，如周期性备份技术，可以和任何应用架构一起实施。使用应用层上的无状态服务器和云供应商提供的不同域，可以产生短的恢复时间目标，但没有解决恢复点目标问题。
传统上，运维负责计算机系统的整体安全。保护网络、检测入侵者、为操作系统打补丁都是由运维执行的活动。第8章将在一定深度上讨论安全及其维护。
3.2.7 服务策略
现在我们回到图3-1显示的生命周期。图的中央是我们枚举的每个服务的策略：硬件供给、软件供给、IT功能、容量规划、业务连续性和信息安全。
制定策略是决定你希望组织在特定时间内达到特定水平，它首先判断组织当前的位置，决定从当前位置到一个期望状态的路径。期望状态同时受到内部和外部事件的影响。内部事件包含人才流失、硬件故障、新软件发布、市场活动和商务活动等，它们都会影响期望状态。外部事件（例如收购、政府政策或者消费者反馈等）也会影响期望状态。可能发生的事件都有发生的概率，因此，策略规划和算命有一些共通的要素。
理解未来在资源和能力方面的需求将有助于加强当前还不能达到要求的部分。例如，如果你希望明年把一些组织的应用搬到云上，则了解组织内部是否有拥有这些技术的人是很重要的。如果没有，你需要决定招一些有潜力的新人，还是培养现有的员工让他们拥有这些技术，或者两者都有。未来需求将带来持续服务改进活动。
策略规划需要花费时间，并且需要协调不同的干系人。策略规划与其说是一个实际的计划，不如说它是从组织内的多个视角和限制做出的考虑。因此，不要太频繁地定义服务策略，而是应该将结果以易于在短期内实现的方法作为宽松的指导方针。我们将在第13章讨论微服务迁移的策略计划，及其案例研究的实施。
3.2.8 服务设计
在一个新的或修改过的服务实施之前，需要对它进行设计。与任何设计一样，你不仅需要考虑所实现服务的功能，而且还需要考虑其他类型的质量。在设计一个服务时需要考虑以下因素：
这个服务将涉及哪种自动化并将其作为服务的一部分？任何自动化都应该按照软件设计原则进行设计。总的来说，这些包括Thomas Erl对服务设计提出来的8个原则：
标准化合同
松耦合
抽象
可复用性
自治
无状态
可发现性
可组装性
服务的治理和管理结构是什么？服务需要管理和变革。人们为服务的绩效负责，而服务的修改应该从标题（如果不是从名称）加以区分。
服务的服务级别协议是什么？服务是如何度量的，需要哪种监控结构来支持该度量？
服务的人才需要是什么？这些服务可以由现有的员工提供还是需要招聘有特殊技能的新员工或者合同工？或者，这些服务可以全部采用外包人员吗？
服务的合规性影响是什么？服务满足了哪些合规需求，引入了哪些？
服务对容量的影响是什么？是否需要获取额外的资源，获取的时间是什么？
服务的业务连续性影响是什么？发生灾难时是否要求必须保持业务连续性，如何实现？
服务的信息安全影响是什么？哪些数据是敏感的，并且必须进行保护，以及谁对这些数据负责任？
在ITIL中，服务设计的章节讨论了这些问题的细节。
3.2.9 服务移交
服务移交包含服务设计和运维之间的所有活动，换句话说，将一个新服务或者修改后的服务成功运营需要的所有活动。因此，本书的很大一部分内容是关于服务移交的，因为它将影响软件新版本的引入。
移交和计划支持包含以下方面：资源、能力和变更计划；移交的范围和目标；文档需求；可应用规则和监管的考虑；财务计划和里程碑。本质上，服务移交包含服务的实施和交付两个阶段。DevOps和持续部署要求服务移交的交付部分高度自动化，这样它才能够处理高频率的移交，并提供更好的质量控制。第5章和第6章将有很多这方面的讨论。
除了实现服务设计部分中枚举的考虑外，服务移交还包括将新服务或者修订过的服务的相关知识扩展给用户或者运营中的那些中间支持者。
例如，设想一个新版本的部署工具将实施。需要回答下面这3个问题：
新版本能支持旧版本的所有功能吗？如果不能，支持旧版本的用户的移交计划是什么？
引入了哪些新功能？部署工具的脚本应该如何修改，以及谁将负责修改？
新版本是否要求或者支持不同的服务器配置，包含测试、预发布（staging）和生产服务器？
与其他软件一样，部署流水线中的工具也会发生变化。“基础设施即代码”的一个含义是那些变更与在为用户开发的软件的变更一样需要管理。这种管理在有些方面可能隐含在部署流水线中，而其他方面则需要注意。ITIL区分了3种模式：
标准变更（例如，经常发生和低风险的变更）
常规变更
紧急变更
每一种变更都应该使用不同的管理方式，也要求不同的管理重视程度和监督。在ITIL的服务移交章节有更多的细节讨论。
3.2.10 服务运维
虽然软件开发工程师和架构师更关注开发，但是只有在运营中，用户才能从好的设计、实施和移交中获得收益——或者不能获得收益。支持在这里扮演了一个重要的角色，尤其是在事故和故障管理中。监控和改造是另一个关注点。我们将在第9章进行更多的探讨。
3.2.11 服务运维概念
在运维过程中，ITIL把事件定义为“任何可检测或者可识别的事情，它对IT基础设施管理或者IT服务交付以及对造成服务偏移的影响评估具有重要意义”。事件是通过配置项、IT服务或监控工具创建的。更具体地，监控工具可以主动从配置项或服务中拉取事件信息，或者它们可以（被动地）收到这些信息。运维过程中关于事件的信息包括：
来自系统和基础设施的状态信息。
环境条件，如冒烟探测器。
软件许可证的使用。
安全信息（例如，来自入侵检测）。
正常活动，例如来自服务器和应用程序的性能指标。
事故，按照ITIL的定义，是“任何中断或可能中断服务的事件”。它们可能是由用户（例如，通过电话或邮件）、技术人员、支持台员工或者监控工具报告的。事故管理是DevOps将影响的一个领域。
事故管理的核心活动有：
将事故记录到日志中。
分类和排优先级。
初步诊断。
如果有需要，上报给有相应技术或授权的人。
调研和诊断，包括任何关于事故影响程度和范围的分析。
解决和恢复，不管是通过获得支持人员引导的用户，还是直接通过支持人员，或者通过内部和外部的专家。
事故结束，包含如果需要，则进行重新分类、用户满意度调查、存档以及判断这个事故是否还可能发生。
事故管理是DevOps改变传统运维活动的一个领域。与一个特定软件系统的运维相关的事件转交给开发团队。不管谁接到问题的报告，都必须记录事故并追踪解决过程。在第五部分中，我们将讨论如何在DevOps和过程视角的帮助下将故障检测、诊断和恢复自动化。
