DevOps健康度雷达@SAFe

Posted 2021-04-16 AgileRunner

#整理及翻译：林伟丹(Wand)，校对：姚冬

#本文内容源自scaledagileframework.com上的公开资料，仅供个人学习及交流用途。

前言

作为精益企业的一个核心竞争力，有必要评估组织在DevOps方面按需发布（Release on Demand）的能力。通过自我评估，版本发布火车（ART）能够理解它们的优势和弱项，识别出需要关注及改善的维度。

下图展示了SAFe DevOps与按需发布的健康度雷达。它帮助版本发布火车与解决方案火车评估它们持续交付流水线的成熟度，共分成16个子维度。对每一个子维度的成熟度，可以相应的评分为“坐（Sit），爬（Crawl），走（Walk），跑（Run），飞（Fly）”。

基于健康度雷度，版本发布火车或解决方案火车确认它的问题领域之后，就需要相应的改善流动（flow）。由于SAFe企业采用系统视角，相对于只改善一个维度到“飞”，而让其他维度都还在“爬”而言；更好的做法是，先把雷达中各个维度从“爬”移动到“走”。重要的是改善持续交付流水线的整体价值流动，而非在任意一个子维度。

 

以下是DevOps健康度雷达4个维度、对应业务目标及16个子维度的详细评估指引。

维度一：持续探索

• 子维度1：假设

假设是以预期要交付的业务价值来表达一个业务想法（epic）。这个假设随后以一个最小可行产品（MVP）通过持续交付流水线来进行实施，并在发布后评估价值的准确性。

请评估一下，你们团队将业务想法转换为清晰、可度量的epic假设陈述的能力。

坐（1-2）：想法模糊或未经定义

爬（3-4）：想法被定义（如epic），但不包含假设陈述

走（5-6）：有些想法被表达为假设陈述，并带有可度量的成果

跑（7-8）：大多数想法被表达为假设陈述，并带有可度量的成果，且包含MVP

飞（9-10）：所有想法都被表达为假设陈述，并带有可度量的成果，且包含MVP

• 子维度2：协作&研究

协作&研究涉及到产品经理直接与最终用户、利益相关方以及领域事务专家一起工作，以便理解客户需求、定义具体的业务成果及相关指标以指导解决方案交付。

请评估一下，你们团队与客户侧、IT侧专家一起协作，定义最小可市场化特性（MMF）以支持假设的能力。

坐（1-2）：产品管理者的角色与职责未经定义、或未被遵循

爬（3-4）：产品管理者以很大的批量创建需求，很少与客户或开发协作

走（5-6）：产品管理者在定义需求时有与业务侧或开发侧专家协作，但不是两者

跑（7-8）：产品管理者定期与业务侧、开发侧、运营侧专家协作，但未定义最小可市场化特性

飞（9-10）：产品管理者总是与业务侧、开发侧和运营侧专家协作，并定义最小可市场化特性

• 子维度3：架构

持续交付的架构，包括采用“足够就好（just enough）”倾向的架构，在不牺牲产品开发流（flow）的前提下确保政策合规，保证解决方案是松耦合的，以及持续偿还技术债务。

请评估一下，你们团队基于持续交付架构设计的有效性。

 

坐（1-2）：架构是单体架构且脆弱，变更比较困难，且涉及管理多个组件与系统间的复杂依赖

爬（3-4）：单体架构占主导地位，但有些应用／系统是松耦合的

走（5-6）：架构大部分可以解耦，但不允许按需发布

跑（7-8）：架构基于价值交付协调一致，组件与系统间有少量依赖

飞（9-10）：架构面向按需发布与可运营性来构建

 

• 子维度4：综合

综合涉及到整合假设、协作&研究、架构的产出，以产出格式良好的、经过优先排序的特性。这些特性此后成为主要的价值载体，流经持续交付流水线的剩余环节。

请评估一下，你们团队综合持续探索活动的结果使成为精心设计、优先排序、可落实的特性待办列表的能力。

坐（1-2）：Program待办列表不存在，或未共享

爬（3-4）：Program待办列表存在，但特性不完整、或排序未事先进行

走（5-6）：Program待办列表包含完整定义的特性，但未使用WSJF（最短加权作业优先算法）进行排序

跑（7-8）：Program待办列表中的特性完整，使用WSJF进行排序，并与版本发布火车的交付容量进行校准

飞（9-10）：Program待办列表是应用BDD创建的最小可市场化特性（MMF）的集合，并使用WSJF进行排序

 

• 业务目标一：协同一致

业务与IT的高度协同一致，是持续探索的至关重要的目标。这里的协同一致使能着持续交付流水线其他部分的高速率与高质量。无法协同一致的话，无一例外的会导致返工、延迟以及削减下游的价值。

 

坐（1-2）：业务、开发和运营是分离的筒仓，以各自的流程运作；需求模糊，且开发组织感觉像订单接收者

爬（3-4）：业务、开发和运营参与在一个共享的交付流程中，但协作很少；协商范围和优先级像是一场搏斗

走（5-6）：业务、开发和运营参与在一个共享的交付流程中，偶尔有些协作；协商范围和优先级很耗费时间、但还算有效

跑（7-8）：业务、开发和运营定期协作，一起积极参与SAFe的事件，范围和优先级总是能够同步

飞（9-10）：业务、开发和运营作为一个统一团队来运作；信息流动顺畅，有高度成熟的相互信任和尊重

维度二：持续集成

• 子维度5：开发

持续交付流水线中的开发需要将特性分解为故事，使用测试驱动开发（TDD）以小的垂直切片来实施故事，代码编写后提交变更給版本控制。

请评估一下，你们团队快速、可靠地定义与开发故事的能力。

 

坐（1-2）：团队待办列表不存在，或没有用来管理日常工作

爬（3-4）：故事不完整、或太冗长；单元测试基本上没写；同行评审没有进行

走（5-6）：故事完整；大多数变更有单元测试；同行评审经常进行

跑（7-8）：代码每日提交；单元测试覆盖率达到80%+；同行评审总是会进行

飞（9-10）：代码每日提交多次；测试在代码之前编写（TDD）；结对工作及其他内建质量实践成为工作规范

 

• 子维度6：构建

构建在代码签入的那一刻被触发，涉及编译、单元测试（及其他形式的组件级验证）、成功归并到主干、提交到代码仓库并产生可部署的制品。

请评估一下，您的团队持续构建与集成的有效性。

 

坐（1-2）：构建的频率低于一个迭代一次，且／或完全手工操作

爬（3-4）：每个迭代运行一次构建，部分自动化；开发分支开放一个月或更长时间；构建经常失败

走（5-6）：自动化构建每日运行一次；失败的构建在2-4小时内被修复；每次构建后进行手工单元测试；开发分支开放2-4周

跑（7-8）：构建在每次代码提交后自动化运行；失败的构建在1小时内被修复；每次构建后运行自动化单元测试；开发分支在每个迭代合并回主干

飞（9-10）：构建在每次代码提交后自动化运行；构建包含静态代码分析与安全测试；有把关的提交防止了缺陷进入版本控制；开发分支在每次提交时合并回主干

 

• 子维度7：端到端测试

测试涉及在类生产的环境上进行特性层级的功能验证。典型情况下，包含功能测试、继承测试、回归测试、性能测试和探索性测试。

请评估一下，您的团队在端到端类生产环境上持续测试的有效性。

 

坐（1-2）：测试手工执行，测试环境与生产环境差异较大；测试在一个计划好的“测试”阶段大批量进行

爬（3-4）：测试大部分是手工的，测试环境不太类似生产环境；故事在一个PI（Program增量）内被独立开发和测试

走（5-6）：半数的测试是自动化的，每个PI在类似生产或模仿生产的环境上运行

跑（7-8）：大多数的测试是自动化的，在类似生产的环境中运行；故事在每个迭代中被开发和充分测试

飞（9-10）：成功的构建触发自动化部署到类似生产的环境中；所有测试都是自动化的；测试并行运行，变更在每次提交后即经过了充分的验证

 

• 子维度8：模拟生产

Staging意味着部署特性到一个生产环境的完整拷贝上，在这里向利益相关方做演示、执行用户验收测试以及在发布生产前用于培训用途。

请评估一下，您的团队在完全类生产环境上演绎特性的有效性。

 

坐（1-2）：不存在staging环境，或者用一个测试环境来作为staging

爬（3-4）：特性被手工部署到staging环境，每个PI部署一次

走（5-6）：特性每月一次被部署到staging环境，并向产品管理者演示

跑（7-8）：特性与基础设施每个迭代被自动化部署到staging环境，并由产品管理者验收

飞（9-10）：故事、变更与基础设施被自动化部署到staging环境，经过验证，并立即流转到部署

 

• 业务目标二：质量

Q1：关于质量

高质量的产品是持续集成至关重要的成果。通过“（测试）左移（shiftingleft）”、小批量工作、在类似生产的环境上集成与测试变更、以及不允许缺陷往下游流转，团队在每个产品中构建质量，降低发布过程的风险，并确保价值以一种持续的方式进行交付。

 

坐（1-2）：没有对质量工作的清晰理解

爬（3-4）：许多缺陷和安全问题在生产环境被发现

走（5-6）：少量缺陷和安全问题在生产环境被发现

跑（7-8）：几乎没有缺陷和安全问题在生产环境被发现

飞（9-10）：所有缺陷和生产问题都在开发期间被发现

 

Q2：您的客户对你们团队的交付质量有多满意？10 = 极为开心，1 = 极为不开心

 

坐：1或2

爬：3或4

走：5或6

跑：7或8

飞：9或10

维度三：持续部署

• 子维度9：部署

部署是将特性实际迁移到生产环境。因为持续交付流水线将部署与发布分离，部署的特性并不一定会直接给到最终用户使用。

请评估一下，你们团队持续部署特性到生产环境的能力，以及使用特性开关及（或）其他手段控制其可见性的能力。

 

坐（1-2）：特性每隔3+个月被部署到生产环境；部署痛苦地手工进行；“部署”意味着“发布”

爬（3-4）：特性在每个PI（program增量）的边界被部署到生产环境；部署大部分是手工进行；“部署”意味着“发布”

走（5-6）：特性每个迭代被部署到生产环境；部署大部分是自动化的；有些特性可以被部署而没有被发布

跑（7-8）：特性每个迭代被部署到生产环境，完全自动化的通过部署流水线；黑暗部署（darkrelease）是常用方式

飞（9-10）：特性在每个迭代全过程中持续进行部署；开发团队直接通过部署流水线工具发起生产部署；发布完全与部署解耦；黑暗发布成为工作规范

 

• 子维度10：验证

在发布给最终用户之前，部署必须经过完整性与完备性验证。

请评估一下，你们团队准确判断部署成功还是失败的能力，以及针对部署问题修复进行版本回滚或前向修复的能力

 

坐（1-2）：部署在发布给最终用户之前，没有经过生产环境的验证

爬（3-4）：部署通过手工的冒烟测试及（或）UAT进行验证；在规定的宽限期／分检期／保修期内处理部署问题；经常直接在生产环境上修复问题

走（5-6）：部署在发布给最终用户之前通过手工测试进行验证；回滚伴随着痛苦，或是不可能的；不直接在生产环境上进行变更

跑（7-8）：部署在发布之前通过自动化冒烟测试、人造交易和渗透性测试进行验证；很容易进行回滚或前向修复，以从部署失败中恢复

飞（9-10）：自动化生产环境测试以一种持续的方式运行，并提供信息給监控系统；失败的部署能够马上通过整个流水线进行回滚或前向修复

 

• 子维度11：监控

监控意味着对所有通过持续交付流水线的已部署特性的有效的全栈遥测，以便能够快速并准确的获知生产环境的系统性能、最终用户行为、事件以及业务价值。

请评估一下，你们团队监控全栈解决方案（前端、中间件、后端、基础设施等）的有效性，以及基于这些事件分析特性价值的能力。

 

坐（1-2）：不存在特性级别的生产监控；仅有基础设施的监控

爬（3-4）：特性的日志只记录错误和日志；分析事件涉及从多个系统手工关联日志

走（5-6）：特性的日志记录错误、用户行为和其他事件；手工分析数据来调查事件及度量特性的业务价值

跑（7-8）：有全栈的监控；事件能够在整体架构中被关联起来；数据通过系统相关的仪表盘展示出来

飞（9-10）：聚合的监控平台对全栈的数据洞察提供一站式访问；数据被用来度量系统性能与业务价值

 

• 子维度12：响应

侦测不可预知的生产事件并快速恢复的能力，对持续交付流水线来说是非常重要的。

请评估一下，你们团队主动侦测高严重级别生产问题、使用监控系统识别根因、通过流水线构建／测试与部署补丁（相对于直接在生产环境上进行变更）来快速解决问题的能力。

 

坐（1-2）：客户在我们之前发现问题；解决高优先级问题耗费时间，且被动响应；客户对快速恢复生产问题的信心很低

爬（3-4）：运营负责生产问题；开发的参与需要显著的问题升级；团队在面临危机时相互指责

走（5-6）：开发和运营协作式地负责事件解决过程；从重大事件中恢复是被动的，但团队一起努力

跑（7-8）：监控系统在客户发现之前侦测到大部分问题；开发和运营一起主动工作来从重大事件中恢复

飞（9-10）：监控系统基于仔细设计的可容忍阈值来预警危险状况；开发负责支持他们自己的代码，在用户受到影响之前通过部署流水线主动修复问题

 

• 业务目标三：响应市场时间

加速响应市场的时间是持续部署的至关重要的目标。虽然这个维度并没有实际把特性发布到市场（这是按需发布要做的事情），持续部署是使能业务达成响应市场时间的目标的关键所在，确保价值总是处在可发布的状态。

 

你们团队以什么频率部署价值到生产环境？

坐（1-2）：每6个月+部署一次

爬（3-4）：每1-3个月部署一次

走（5-6）：每2个星期部署一次

跑（7-8）：每个星期部署一次

飞（9-10）：持续部署

维度四：按需发布

• 子维度13：发布

发布意味着让已部署到特性对最终用户可用。

请评估一下，你们团队使用功能开关、蓝绿环境、金丝雀发布等手段发布特性給用户的能力。

 

坐（1-2）：发布与部署紧耦合，客户对发布频率极为不满意

爬（3-4）：发布与部署紧耦合，客户对发布频率有些不满意

走（5-6）：发布与部署耦合，但两者都能持续或者按需进行

跑（7-8）：发布与部署解耦，已部署的特性基于业务就绪来发布給最终用户群体

飞（9-10）：已部署的特性可以发布到用户群体的个别部分，功能开关在不再使用时会被重构

 

• 子维度14：稳定

持续交付流水线需要持续稳定、可靠、可用、可支持且安全的生产环境。

请评估一下，你们团队维护稳定解决方案、避免计划外宕机与安全漏洞的有效性。

 

坐（1-2）：频繁经历计划外宕机及／或安全漏洞，恢复时间很长

爬（3-4）：偶尔经历计划外宕机，但可以在服务级别协议内恢复

走（5-6）：比较少出现计划外宕机，可用性、安全性与灾难恢复手段是有效的

跑（7-8）：没有出现计划外宕机，主动规划和演练失败并进行恢复

飞（9-10）：通过有意设计的向生产环境的缺陷注入与容灾演习程序，最大化弹性（resiliency）

 

• 子维度15：度量

度量涉及到收集已部署特性价值的事实信息，并评估其是否符合初始的假设陈述。

请评估一下，你们团队收集部署的特性所实现的实际价值的客观信息、以便制定战略财务决策的能力

 

坐（1-2）：没有定义或度量特性的价值

爬（3-4）：定义了什么是“价值”，但不知道如何度量它

走（5-6）：从业务获取关于特性价值的定性反馈

跑（7-8）：从业务及监控系统获取关于特性价值的定性与定量的反馈

飞（9-10）：聚合定性与定量的反馈，来客观验证初始的假设，以作出“转向或维持”的决策

 

• 子维度16：学习

学习涉及对初始假设有效或无效的判断，基于对业务价值、系统性能及客户反馈的客观度量。

请评估一下，你们团队基于经验性能数据制定战略性“转向或维持（pivot-or-persevere）”决策、并承诺应用这些洞察来持续改善流水线的能力。

 

坐（1-2）：特性在发布之后从不做评估

爬（3-4）：特性有时候使用主观信息及／或片面观点进行评估

走（5-6）：使用客观度量来评估假设，但行动受到公司政治的严重影响

跑（7-8）：使用客观度量来评估假设，毫无怜悯地做出“转向或维持”决策

飞（9-10）：持续学习和实验成为组织根深蒂固的DNA

 

• 业务目标四：业务价值

您计划的业务价值实际上实现了多少？

 

坐（1-2）：少于10%的计划价值与成果在发布后实现

爬（3-4）：25%的计划价值与成果在发布后实现

走（5-6）：50%的计划价值与成果在发布后实现

跑（7-8）：75%的计划价值与成果在发布后实现

飞（9-10）：100%的计划价值与成果在发布后实现。团队在创造力与基于客户需要的转向能力上，超越了预期

小结

DevOps健康雷达图是一个强有力的评估工具，帮助团队勾勒出一个完整的现状视图，并为持续改进提供了方向指引。下图展示了基于上述DevOps健康雷达图的一个评估结果示意，以及与业界基准数据的对比情况。

（全文完）

---

EXIN DevOps Professional认证课程（广州1月4-6日，上海3月29-31日）

【课程介绍】DOP以被业界誉为“DevOps圣经“的《DevOps Handbook》为核心教材，以DevOps“三步法”（流动、反馈、持续学习与实验）完整实践体系为内容主线，穿插精心设计的模拟沙盘，并研讨Google/Amazon/Facebook/Netflix/Etsy等10+个国内外顶尖科技企业DevOps实战案例。

【讲师介绍】林伟丹（Wand），Lean/Agile/DevOps专家，Exin授权DOP讲师及凤凰沙盘引导师。有丰富的一线IT研发、测试、运维、产品及管理经验；曾在某大型金融集团作为首席敏捷教练多年主持企业级敏捷与DevOps转型工作，成效斐然。

详情请“阅读原文”