3.4 持续服务改进
每一个被组织采用的流程都应该从这个视角来考虑：这个流程到底多有效？还可以怎样改进？这个流程如何适应公司整体流程框架？
我们讨论的所有运维服务（硬件和软件的供给、IT支持功能、服务级别协议的规格说明和监控、容量规划、业务连续性和信息安全）都是组织层面的流程。需要从我们提出来的几个问题的视角来进行监控和评估。
从组织层面来说，每一个服务都应该有一个负责人，并且这个服务的负责人需要负责检查监控、评估和改进。
持续服务改进的主要焦点是要在IT服务和业务需求之间达成一致——不管这些需求是否已发生变化还是维持不变。如果这些需求已经发生变化，则对IT服务的期望变化可以关注范围、功能或者服务级别协议。如果业务需求相同，则可以扩展IT服务来更好地支持它们，但对它们的改进也可以专注在提升效率上。DevOps关注更快、更可靠地把这些变化引入实践中。
图3-3描绘了ITIL建议的7步骤改进流程。这个数据驱动的流程开始于一个明确的愿景、策略和目标，这些能够驱动当前的改进周期。基于此，第1步定义应该度量什么，以便理解应该改进什么，并且当改进完成后，是否达到了期待的目标。指标可以粗略地分成3类：技术、流程和服务。
图3-3 服务持续改进流程（改编自ITIL）
实际的数据收集是在第3步发生的。这对于建立基线是非常重要的（如果它们已经不存在了）用于以后的比较。而且，数据的收集（谁收集和如何收集、什么时间、什么频率收集）需要明确定义。第4步，处理数据（例如，将不同数据源的数据进行聚合或按照指定的时间间隔进行）。分析数据是在第5步进行。在第6步，演示分析中得出的信息，并决定改进措施。而第7步将已制定好的改进措施付诸实施。这些行动将影响服务的整个生命周期的所有阶段——策略、设计、移交或运维。
