不操千曲而后晓声，观千剑而后识器。这篇文章主要讲述除了关注业务连续性，运维还能创造什么价值？相关的知识，希望能为你提供帮助。
1
前言自从我学习并通过了精益、敏捷和DevOps相关认证后，对运维管理和运维工作本身有了新的思考和启发。本文我们将围绕保障业务连续性、敏捷交付业务价值和提升员工满意度3个阶段进行探讨，同时分享不同阶段的实现思路供各位参考。
2
正文
2.1
运维管理的终极目标——BVSSH运维管理的最重要的职责之一是保障业务连续性——负责系统的运行维护，保障业务安全稳定地运行。时过境迁，在VUCA的数字化时代，运维管理仅关注业务连续性保障是远远不够的。新的时代提出了新的要求——BVSSH，更快（Sooner）更安全（Safer）地交付更好（Better）的价值（Value）给到客户，同时让客户和员工满意（Happier）。
图片源自书籍《Sooner Safer Happier：Antipatterns and Patterns for Business Agility》
l
Better（更好）: 代表的是质量，比如：更少的生产事故、更短的灾难恢复时间、更少的产品缺陷和返工工作；
l
Value（价值）: 代表的是业务价值，如：增加营业额、增加利润、增加客户数量；
l
Safer（更安全）: 意味者持续合规（GRC）——治理（Governance）, 风险（Risk）和合规（Compliance）；
l
Sooner（更快）: 端到端的交付效率，也是精益和敏捷的核心。常用的度量指标有前置时间（Lead Time）、流动效率（Flow Efficiency）、吞吐量（Throughput）等；
【除了关注业务连续性，运维还能创造什么价值（）】l
Happier（更快乐）: 关于员工和客户的满意。这是一种更人性化、更吸引人的工作方式。
在本文中，我们将运维管理发展分为3个阶段：
l
第一阶段：保障业务连续性（Safer），保障业务安全稳定的运行；
l
第二阶段：敏捷交付业务价值（Sooner），快速响应市场变化交付业务价值；
l
第三阶段：提升员工满意度（Happier），提升员工和客户满意度。
2.2
第一阶段：保障业务连续性（Safer）2.2.1
定义
通过事前预防、事中管控、事后处理的全过程管理，保障业务安全稳定的运行。
2.2.2
如何度量业务连续性？
业务连续性比较常用的衡量指标有MTTR/MTBF、SLA/OLA和RTO/RPO，介绍如下：
1)
MTTR/MTBF
a)
平均恢复时间（MTTR，Mean Time To Repair）：指系统从发生故障到恢复结束之间的时间段的平均值；
b)
平均故障间隔时间（MTBF ，Mean Time Between Failure)：指系统两次故障发生时间之间的时间段的平均值。
2)
SLA/OLA
a)
服务水平协议（SLA， Service level Agreement）：是服务提供商与其客户之间关于提供满足客户期望的服务的协议或合同。SLA都是关于满足业务级别要求和管理业务期望的，例如，如果发生中断，业务可以期望服务中断多长时间；
b)
操作级别协议（OLA, Operation Level
Agreement）：是服务提供商为其内部客户建立的遵守SLA的承诺或协议。 OLA用于监视内部服务协议，例如事件的响应时间，分配给IT组的问题，支持多个应用程序的服务器的可用性等。
3)
RTO/RPO
a)
恢复时间目标（RTO，Recovery Time Objective）：当业务发生中断后，从业务发生中断时开始，到将业务恢复到正常所需要的时间，此两点之间的时间段称为RTO
b)
恢复点目标(RPO，Recovery Point Objective)：是指可接受的数据丢失的最大数据量，也就是容忍丢失的最大数据量。RPO表示为从丢失事件到最近一次备份的时间度量。
2.2.3
如何保障业务连续性？
关于业务连续性管理和保障方面业界都有成熟的标准体系和实践了，这里不做详细的阐述，仅列举国际标准ISO
22301业务连续性管理体系和Google SRE 服务可靠度层级模型。
ISO 22301业务连续性管理体系，能够帮助企业制定一套一体化的管理流程计划，使企业对潜在的灾难加以辨别分析，帮助其确定可能发生的冲击对企业运作造成的威胁，并提供一个有效的管理机制来阻止或抵消这些威胁，减少灾难事件给企业带来损失。
书籍《SRE：Google运维解密》提出了Google SRE 服务可靠度的7层模型，包括：
l
产品设计
l
软件开发
l
容量规划
l
测试+发布
l
事后总结和问题根源分析
l
应急事件处理
l
监控
2.3
第二阶段：敏捷交付业务价值（Sooner）
2.3.1
定义
通过优化快速高效的价值流动，快速响应市场变化，快速迭代、反馈和学习，并将价值交付给客户。
2.3.2
如何度量业务交付效率？
关于对业务端到端交付效率（Sooner）本文采用了精益的3个关键度量指标：
1)
前置时间（Lead Time）：从用户提出需求到最终将价值交付给客户的端到端的时间。减少前置时间可以促进快速的反馈和学习；
2)
流动效率（Flow Efficiency）：工作时间（如：软件开发、测试、部署）除以前置时间得到的百分比。与工作时间（Working）相反的就是等待（Waiting）时间（如：流程审批）。需要特别注意的是，流动效率关注的是“事”，而资源利用率关注的是“人”；提升流动效率需要通过识别减轻流程的障碍，限制正在进行的并发工作，而不是增加人的工作。
3)
吞吐量（Throughput）：吞吐量是给定时间内交付到客户手中的有价值的项目的计数。
2.3.3
如何提高业务交付效率？
精益价值流映射方法可以帮助企业识别以客户为视角的整个交付过程，同时有助于建立整体思维，避免局部优化，提高端到端的交付效率。具体操作可以通过以下三个步骤：
1)
通过价值流映射，确定优化的价值流类型
a)
主要价值流：从用户提出需求到交付给客户的全过程。如：从“需求-设计-开发-测试-部署-运营”的全过程。
b)
价值流片段：是相对于主要价值流而言的，如：软件设计、代码编写、功能测试、和应用投产等都是价值流片段。
c)
支持价值流：为价值交付提供支持的，典型的例子有：招聘、员工培训、预算处理等。
2)
识别并消除不必要非增值活动：
a)
增值活动：直接为顾客创造价值的活动，如：功能开发；
b)
必要非增值活动：不直接创造客户价值但又是必要的，如：计划变更、流程审批、人员培训；
c)
不必要非增值活动： 即是浪费，应当优先消除。最为明显的浪费就是等待——比如医院的排队挂号、排队看病、排队缴费和排队取药。IT常见的就是等待流程审批和等待资源采购。
3)
识别并消除瓶颈：价值流思想是以客户为中心的，识别瓶颈需要具备整体思维。只有当这个阶段或步骤成为整个价值流瓶颈时，你优化它才有价值，否则这只是一种局部优化。这里我们以“应用发布“为例进行说明：
如上图所示，我们在企业看到做应用发布自动化项目，大体上可以分为三类：
1）发布执行自动化（图中绿色部分）：将发布步骤的人工操作交给工具执行，实现发布操作的自动化；毋庸置疑这有利于提高发布过程的标准化和规范化。请思考：将发布执行自动化能否明显缩短端到端的交付效率呢？答案是不一定，有可能你的发布方案制定、发布排期和发布审批就花费了2个月的时间，那对于“发布执行“手工操作从1小时提升到自动化执行的5分钟价值是不大的。如同医院的例子，让医生看病的时间从3分钟/每人缩短到2分钟/每人，这省下来的1分钟对于用户半天的等待时间来说只是冰山一角。
2）发布过程自动化（图中蓝色部分）：实现从发布请求开始到发布方案关闭的过程自动化，能够明显提升应用发布过程效率，这个提升至少是在运维团队能够明显感知到的。请思考：发布过程自动化是否会极大提升业务价值端到端的交付效率吗？答案仍然是不一定。除非你的发布过程是整个全过程的瓶颈。
3）全过程自动化（图中灰色部分）：实现从需求到客户的全过程自动化，可以显著地提升交付效率，缩短产品上市周期，快速反馈和迭代。很显然，全过程的优化需要从传统的部门思维和筒仓思维转变为整体思维和全局思维。
2.4
第三阶段：提升员工满意度（Happier）
2.4.1
定义
越来越多的企业开始关注客户成功，然而客户的成功来源于客户的满意，而客户满意的前提是内部员工的满意。
2.4.2
如何度量员工满意度？
净推荐值：NPS（Net Promoter Score），净推荐值，亦可称口碑，是一种计量某个客户将会向其他人推荐某个企业或服务可能性的指数。NPS既可以用于度量产品服务，也可以用于度量员工的忠诚度。通过密切跟踪净推荐值，企业可以让自己更加成功。
图片源于互联网
净推荐值使用方式也比较简单，可以向员工提问并在0－10之间来打分，例如你是否愿意向朋友及同事推荐该公司，根据得分情况分为3个范畴：
l
推荐者（得分在9－10之间）：是具有狂热忠诚度的人，他们会继续将公司或产品并引荐给其他人；
l
被动者（得分在7－8之间）：总体满意但并不狂热，一般不会向其他人引荐公司或产品；
l
贬损者（得分在0－6之间）：对公司不满意或者没有忠诚度，不会向其他人引荐公司或产品，甚至还好进行贬低。
最终净推荐值(NPS)=(推荐者数/总样本数)×100%-(贬损者数/总样本数)×100%
?
2.4.3
如何提升员工满意度？
关于提升员工满意度，当然方式有很多，本文中列举3个思路：企业服务管理（ESM）、为运维人员赋能和应用精益持续交付实践。
1)
思路1：企业服务管理（ESM）
企业服务管理（Enterprise Service Management）是将IT服务管理应用到企业或组织的其他领域的实践，包括但不局限于：HR、财务、法务、行政、市场、采购和安全等团队，目的是提高效率、服务交付和用户体验。简而言之，它将在IT服务管理(ITSM)中工作良好的东西应用到整个企业中。
图片源于BMC官网
正如BMC官网所展示的，应用ESM的六大好处之一——提升用户满意度（Increase user satisfaction）。随着流程帮助定义角色和职责，内部用户将对请求期望更加满意。(满意的内部用户会影响到你的外部客户，他们也会看到这种改进。)
企业服务管理（ESM）平台至少具备4个核心能力：
l
自服务门户：提供多终端（手机、平板和PC）的用户自助入口，让用户自助按需申请所需要的服务，显然服务门户的用户体验设计至关重要；
l
知识库：用户可以自助查找并解决一般性问题，同时对知识库的知识沉淀和标准化提出了新的要求；
l
自动化交付：用户提交服务申请后，自动调度后台系统完成服务的快速交付；
l
服务编排能力：通过拖拽式免代码或低代码的服务流程编排引擎，快速组装编排满足各种不同场景的服务流程。
2)
思路2：为运维人员能力赋能，减轻运维人员危机感
在2022得到“时间的朋友“跨年演讲中，罗胖提到《全球人力资本趋势报告》中有一句话——“企业要为员工的生存能力负责“。在云原生时代，基础设施都云化了，资源交付都自动化了，运维操作也都工具了，敢问运维人员未来的路在何方？作为运维团队和IT部门需要为员工提供一个职业升级的平台和赋能培训。
作为运维人员我认为至少有3个方向可以走：
l
运维开发：开发统一化、规范化和自动化的运维工具，将重复性手工操作和经验沉淀到工具平台，提供运维效率；
l
运维经理：统筹协调，并带领运维团队左移，提前参与项目团队，与项目组讨论非功能性需求和可运维性；
l
运维专家：运维技术栈的“定海神针“（如：DBA）
当然，运维开发的工具除了解决运维本身的需求，还可以间接赋能测试人员（如：测试环境资源开通）和开发人员（如：日志查询），与此同时制定运维规范。
3)
思路3：应用精益管理和持续交付实践
书籍《Accelerate》根据多年研究发现，应用精益管理实践、软件开发实践、持续交付和文化变革都会影响到员工的满意度。具体细节可以阅读原书。
图片源于书籍：《Accelerate：Building and Scaling High Performance Technology Organizations》
3
结尾本文结合个人多年工作经验和自身思考总结了运维发展的3个阶段，其中第一、二阶段更多还是聚焦在“事”本身，而到达第三阶段需要回归到“以人为本”，同时借助精益、敏捷和DevOps思想，让员工满意，让客户成功。
以上仅代表个人观点，欢迎吐槽和探讨，共创运维未来之路！
推荐阅读
- k8s集群Job Pod 容器可能因为多种原因失效，想要更加稳定的使用Job负载，有哪些需要注意的地方（）
- LVS负载均衡群集概念NAT模式LVS负载均衡实战部署
- Android C++系列（Linux线程线程原语）
- Apache Doris 编译部署
- 实践丨SpringBoot整合Mybatis-Plus项目存在Mapper时报错
- IN和EXISTS谁效率更高
- hive数据导入（文件导入）
- 详解golang的json解析方法Marshal跟 Unmarshal（复杂的对象直接用神器生成对象）
- Linux系统的安全设置