通过 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 的团队，

应该采用 基础设施即代码