采用 DevOps 故事落地 DevOps

在 2009 年第一届 DevOpsDays 上，《敏捷教练》的作者 Rachel Davies 作为第一届 DevOpsDays 上的第一位分享嘉宾。分享了在 BBC 采用用户故事跟踪非功能需求的经验。然而这一实践并不如 DevOps 的其它实践那样广泛。这个实践实际上很简单，就是把非功能需求做为用户故事的 AC 放入故事卡里。

在我过去实践 DevOps 的经历里，发现每次开始的时候都需要团队做同样的一些事情。而这些事情往往是和用户故事独立的，不能作为用户的一部分体现在工作量里。但这些事情又提升了团队之间的 DevOps 能力，于是，我把这一类的工作固化为 DevOps 故事用来落地 DevOps 实践，而且 DevOps 故事同样遵循并体现 CLAMS 原则的。

所谓 CLAMS 原则，指的是：

Culture（文化） Lean（精益） Automated （自动化） Measurement （度量） Sharing （分享/共担责任）

我把一个团队是否遵循 CLAMS 原则当做是否正确实践 DevOps 的标准之一。

DevOps 故事由 DevOps Epic （DevOps 史诗）和 DevOps Story （DevOps 故事）组成。和用户故事对应，DevOps 史诗故事可以依据具体情况的不同拆分成不同的 DevOps 故事。

而无论 DevOps 史诗 还是 DevOps 故事，都包含以下三个因素：

1. 一定包含 Dev 和 Ops 两个方面

2. 一定包含 Dev 和 Ops 核查的内容

3. 一定包含可以度量的内容

编写 DevOps 史诗故事 #

DevOps 史诗故事对于大部分组织来说是类似的，因为这些场景是 DevOps 的核心特征。也就是说，当你的团队完成了 DevOps 史诗故事。那么，你的团队就可以被称作是 DevOps 团队。

一个 DevOps 的史诗故事格式如下：

作为一个 DevOps 团队 应该采用*<某一种 DevOps 实践>* 团队中的Dev*<应该如何做>* 团队中的Ops*<应该如何做>* 得到<什么样的结果> 可以获得*<什么益处>，从<某一度量指标>*中得到。

举例1：持续部署流水线 #

作为一个 DevOps 的团队， 应该采用 持续部署流水线 团队中的 Dev 提交代码后 团队中的 QA 可以根据需要部署相应版本 团队中的 Ops 无需操作 就可以看到应用部署在生产环境上 可以 提升交付速度，通过部署时间度量 可以 提升反馈速度，通过部署频率度量 可以 节约 Ops 的部署时间，通过 Lead Time 度量

举例2：基础设施即代码 #

作为一个 DevOps 的团队，

应该采用 基础设施即代码

团队中的 Dev 用代码构建和生产环境开发环境

团队中的 Ops 需要通过代码和配置构建基础设施

就可以 看到应用部署在生产环境上

可以 提升交付速度，通过部署时间度量

可以 提升反馈速度，通过部署频率度量

可以 节约时间，通过 Lead Time 度量

可以 减少人为变更失误次数和变更失败次数

以上的两个例子中，都包含了 DevOps 史诗故事的几个原则:

首先，DevOps 作为一个团队属性，放在第一行标识了出来。这是为了向团队强调 DevOps 的概念。

其次，需要注明 DevOps 所采用的最佳实践，在这里，最佳实践是不需要有具体的实施工具的。具体的实施工具要在 DevOps 故事里体现。

然后，下来的几行包含了各个角色要达成的效果，以及最终的效果。这里体现了 CLAMS 里 Culture 和 Share （分担）的原则。

最后，要标明 DevOps 史诗故事带来的益处以及度量方法。这里体现了 CLAMS 里的 Measurement 原则。

然而，仅仅有了 DevOps 史诗故事是没有办法落地的，我们还需要更加具体的 DevOps 故事来辅助。

编写 DevOps 故事 #

DevOps 故事的原则要比 DevOps 史诗更加具体，并分成两种不同的故事。一种叫做“给 Dev 的 DevOps 故事”（DevOps Story for Dev），另一种叫做“给 Ops 的 DevOps 故事”（DevOps Story for Ops）。两者的格式相同， 但内容不同。

DevOps 故事的编写原则如下：

1. 只包含某单一角色

2. 和某一史诗故事关联

3. 包含所用 具体技术和最佳实践

4. 完成的效果

5. 可以自动化 (可选)

6. 要有 AC，定义什么算完成。

DevOps 故事的格式如下：

作为 DevOps 团队里的 <角色> 要实现 <某一 DevOps 史诗故事> 要采用 <什么工具> 完成 <什么事情> 对 <另一角色> 带来什么好处

例如，对于上文的持续部署流水线的 DevOps 史诗故事就可能会有以下几个 DevOps 故事组成：

DevOps 故事1 #

作为 DevOps 团队里的 Ops 要实践持续部署流水线 我需要采用 Jenkins 作为持续集成服务器管理持续部署 让 Dev 提交的代码可以通过持续部署流程 让 QA 可以部署到测试环境上验证功能 验收条件：

1. 有 jenkins 服务器对应的 URL
2. 有 每个用户的用户名和密码
3. Lead Dev 具有管理权限和配置权限
4. 其它 Dev 具有执行权限
5. QA 有部署在测试环境和生产环境上的权限

DevOps 故事2 #

作为 DevOps 团队里的 Ops 要实践持续部署流水线 我需要采用 Gitlab 作为代码仓库，提交代码。 让 Dev 可以提交代码。 验收条件：

1. 采用自动化的方式创建一个 Gitlab 服务器。
2. 在 Gitlab 上创建一个代码库。
3. 给 Jenkins 配置对应的访问权限。

DevOps 故事3 #

作为 DevOps 团队里的 Dev 要实践持续部署流水线 我需要用 git 提交代码并实现 单一主干发布分支 让 Ops 通过 Master 分支发布 让 Dev 在开发分支上开发 让 QA 可以选择对应的提交进行部署测试 验收条件：

1. 创建一个 Jenkins Job，跟踪代码库 Master 分支的变化
2. Master 分支如果有变化，自动立即构建并部署到开发环境。
3. 测试环境和生产环境不能直接部署。

通过以上三个 DevOps 故事，我们可以看出：完成一个 DevOps 史诗故事是需要不同角色的共同参与的，而且每个角色都能通过自己的 DevOps 故事让其它团队成员获益。此外，在以上三个 DevOps 故事中，都包含了 DevOps 故事的几个原则：

1. 一个 DevOps 故事有且只有一个角色执行。

2. 和 DevOps 史诗故事一致，对应的度量指标和 DevOps 史诗故事也一致。

3. 包含具体工具和具体工具的实践。

4. 包含对其它团队成员的操作指引。

5. 虽然并不是每一个 DevOps 故事都可以自动化，但是自动化是需要第一考虑的因素。

用 DevOps 故事塑造 DevOps 文化 #

通过以上例子你可以感觉到，DevOps 故事实际上就是一个 DevOps 实践的落地说明。它采用 史诗故事确立了 DevOps 的文化和原则。有用具体的 故事 指导每个成员的技术实践。通过每日站会，我们在不断通过重复和强化每个人对 DevOps 文化和原则的认识。

有人曾经说文化无法落地和改变，这句话说对了一半。

作为 《DevOps Handbook》 的合著者之一，以及 DevOps 的早期布道者。 John Willis 的 “DevOps Culture（Part1）” 这篇文章里，引用了 一句话：

“You can’t directly change culture. But you can change behavior, and behavior becomes culture”

翻译过来就是：你无法直接改变文化，但是你可以改变行为，行为会演变成文化。

DevOps 故事就是通过类似于用户故事的方式将 DevOps 的相关行为可视化并落地的一个方法。这也给 Scrum Master 和敏捷教练一个指导团队落地 DevOps 的工具。

正确的认识和使用 DevOps 故事 #

DevOps 也有 INVEST 原则 #

DevOps 故事源于我在学习用户故事（User Story）中受到的启发。而用户故事中最重要的原则就是，INVEST 原则，它们分别是以下六个单词的缩写：

Independent：独立的 Negotiable：可讨论的 Valuable：有价值的 Estimateable：可估计的 Small：小的 Testable：可测试的

DevOps 故事和 用户故事都满足 INVEST 原则。然而，这六个原则在 DevOps 的上下文里则需要一点补充和解释：

1. 由于 DevOps 故事的价值不是最终用户（End-User），因此所有的原则是对内部用户（Internal User）讨论的。Internal User 包括团队里的 Dev、Ops、BA、QA、UX、PM 等等角色。

2. 对于 Independent （独立的）原则而言，在用户故事的上下文里，是要避免故事间的相互依赖。但在 DevOps 故事里，是指角色独立。也就是说，每个角色所做的事情是独立的。但是这些角色之间的故事可能是相关，甚至是依赖的，我们需要对这样的 DevOps 故事按照依赖关系排列优先级。

3. 对于 Negotiable （可讨论）原则而言，在用户故事的上下文里，是对功能的简短描述，细节将在客户和开发团队的讨论中产生。但是在 DevOps 故事里，是指最终达成 DevOps 的效果是依据团队的构成不同可讨论的，目的是要让 DevOps 在团队资源能力水平合适的方式下落地，而不是提出一个无法达到的要求。此外，DevOps 史诗故事是对 DevOps 落地的简要描述，而 DevOps 故事是对 DevOps 落地的详细描述，在 DevOps 史诗故事中，可以讨论的余地并不多，它代表了某一种最佳实践，而这样一种最佳实践是有上下文的。而 DevOps 故事，则是某一种最佳实践的具体落地，团队可以讨论商议具体的落地内容。比如：对于没有 Github 访问条件团队，我们可以讨论用 Gitlab 服务器。如果团队不会用 git ，可以讨论使用 SVN 或者 CVS。而对于 DevOps 史诗故事来说，这些细节是无关紧要的。

4. 对于 Valueble (有价值）原则而言，这个价值体现在两个方面：一个方面是对最终用户的价值，被称之为外部价值，这点和用户故事是一致的。另外一个方面是对团队的内部价值，这里是要在编写 DevOps 史诗故事和 DevOps 故事的时候就要明确的。每一个具体的实践对某一具体的角色提供了什么价值。

5. 对于 Small（小的）原则而言，这里的控制维度是按 AC 的可完成性而言，如果每一个 AC 都是通过讨论可以明确完成的，这样的 DevOps 故事就是小的，而跟时间无关。和用户故事相同的地方是，如果某一个 DevOps 故事因为不确定而复杂，可以将它分成两个故事：一个做调研的故事和一个完成的故事。这里需要强调注意的是，调研故事必须有进度产出。举个例子，如果 DevOps 故事的内容是要做监控管理，团队不清楚应该用哪种工具或者框架。我们就需要一个调研工具的 DevOps 故事，而这样一个调研故事，是需要每天，甚至每半天要有产出分享的。这是遵照了 CLAMS 里的 Share（分享）原则。因此，在 DevOps 上下文里，分享不是一个可选项，是一个必选项。

6. 对于 Testable（可测试）原则而言，测试是每个角色的职责，这体现了 CLAMS 原则的 Share（共担）原则，而不仅仅是最终用户。和用户故事相同的地方在于：无论什么时候，只要有可能，就要把测试自动化，这也体现了 CLAMS 原则里的 Automation（自动化）原则。

DevOps 故事不同于技术卡（Technical Card） #

有些读者可能会发现 DevOps 故事有点像某些项目里的技术卡。但它们有以下几点不同：

1. DevOps 故事更强调团队对 DevOps 文化和原则的落地。而技术卡强调是某一技术的创建或者变更。

2. DevOps 故事中的技术是手段，目的是最佳实践。而技术卡可以是仅仅是技术工具本身。

3. DevOps 故事中强调技术对团队的价值。而技术卡可以不用考虑这一点。

DevOps 故事不同于非功能需求（Non-Function Requirements） #

DevOps 故事不同于非功能需求主要是面向用户不同：DevOps 故事是对于应用交付团队或者内部用户（Internal User）的。而非功能需求是针对于引用最终用户（End-User）的。因此，它们的关系也不一样。用户故事是应用功能的一部分。而 DevOps 故事是和应用功能无关的。

请用 CLAMS 原则和 INVEST 原则校正你的 DevOps 故事 #

当你开始编写 DevOps 故事的时候，可能会出现一些问题，这不要紧。你需要编写 DevOps 故事之前，要牢记 CLAMS 原则。当你举棋不定时，团队是最好的答案来源，因为 DevOps 是关于团队本身，而不是终端用户的事情。不过当你开始咨询团队的意见之前，请和团队达成 CLAMS 原则的共识，在这样的共识之下，做出什么样的 DevOps 故事都会通过度量和反馈机制来衡量效果。

此外，DevOps 故事的 INVEST 原则也可以帮助你更好的实践 DevOps 故事。我采用 DevOps 故事作为落地 DevOps 的方法的时间和案例始终都很有限，还有更多未知的情况等待区处理。但我始终不忘用 CLAMS 原则去审视它。如果你发现有无法处理的状况，欢迎来信和我一起讨论，并形成新的 DevOps 实践。