通过 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 实践。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏即时通讯技术

写给小白的实时音视频技术入门提纲

这是由一篇我的演讲稿整理出来的文章,目标读者是对实时音视频开发感兴趣但是又不知道如何下手的初学者们,希望把我的经验分享出来,对大家有所帮助。

8053
来自专栏云计算D1net

为什么说在云服务中,移动APP开发者更需要PaaS而不是IaaS

创业大潮和“互联网+”凑在一起,让更多人开始了解互联网的技术术语,包括IaaS(Infrastructure as a Service,即基础设施即服务)、Pa...

4096
来自专栏Java架构

献给迷茫的Java程序员,没时间虚度光阴了!当前你感到迷茫吗?架构师的定义?

1965
来自专栏云计算D1net

云计算对其下游的行业产生及其深远的影响

云计算、虚拟化技术和其他IT技术的广泛使用正在重塑技术服务供应商与渠道合作伙伴之间的关系。而这些变化也将进一步对其下游的行业产生及其深远的影响,其正在改变经销商...

3123
来自专栏DevOps时代的专栏

DevOps 下的质保测试方法

前言 以 DevOps 为主,今天给大家聊一下作为一个咨询公司,从咨询方这个视角,所看到企业在 DevOps 的变革,在这个变革当中,我们关于测试的变化。有多少...

34110
来自专栏腾讯大数据的专栏

想要“延长产品生命周期”?看这里~看这里~看这里!

对于产品汪和市场喵们,在平时的产品决策和推广中,难免经常听到“产品生命周期“这么个理论。今天我们就来普及一下,作为一款移动互联网的产品,如何定位自己的所处周期...

2699
来自专栏数据猿

大数据精准营销必读的“三步曲”及“两误区“

<数据猿导读> 大数据浪潮,汹涌来袭,与互联网的诞生一样,这绝不仅仅是信息技术领域的升级,更是在全球范围企业加速创新、社会加速变革的利器。未来的营销会是精准化营...

37511
来自专栏SDNLAB

网络虚拟化是多云控制的关键

现在很多IT企业在云计算时代逐渐失去对正在开发和部署在公有云中的应用程序的控制,形成这种现象的原因是每个公有云对网络来说都是一个孤岛。 ? 网络虚拟化(NV)o...

3728
来自专栏SDNLAB

云疲劳:为什么企业从云端迁出应用?

尽管公有云在所有行业中似乎都很火,但是值得注意的是,近期有组织已经将其关键业务工作负载和应用从公有云中迁出到内部或私有云中部署。 ? Enterprise St...

3567
来自专栏WeTest质量开放平台团队的专栏

Hi,我们和Unity合作了全新的性能分析工具

早在2016年ChinaJoy开始,WeTest曾受邀出席过Unity中国的线下性能场的活动,介绍我们的自动化框架和王者荣耀的故事。当时的活动很成功,期间我们收...

1182

扫码关注云+社区

领取腾讯云代金券