作者介绍

顾宇
《七周七Web框架》译者，ThoughtWorks 高级咨询顾问，参与中国移动、中国联通省级BOSS系统以及呼叫中心系统的研发、实施。拥有丰富的大型系统开发及维护经验。

本文来自于 GOPS 2017 深圳站的演讲“DevOps可视化在大型电信运营商的落地实践”。

目录

1. DevOps 应用中的一些问题（见上一篇）

2. 通过可视化“看见” DevOps（见上一篇）

3. “看见” DevOps的组织上下文（见上一篇）

4. “看见” DevOps的价值流/技术上下文

5. “看见” DevOps的全景

上篇文章链接：案例 | 可视化的方式解决 Dev 和 Ops 的相爱相杀（上）

5.“看见”DevOps的价值流上下文

我们来看一下看见 DevOps 的价值流上下文。我们要知道神奇的 DevOps 工作在哪里，有几点：

1. DevOps 的工作范围

2. DevOps 的工作目标

3. DevOps 的工作内容

4. DevOps 的工作阻碍。

案例一：看不见的 DevOps 工作内容

一切看起来都是计划中进行，有一个工作被卡住了，我找不到 DevOps 的工作内容，他让我做 Ops，但是我找不到工作内容。

这是一个标准的故事卡片，我把 DevOps 加进去，ops 需要做什么事情，这才变成完整的 DevOps 内容。我用一个故事把两个内容串在一起。

他的特点是 Ops 内容是 Dev 不会做的，Dev 没有权限，再就是 Dev 不承担责任，在敏捷团队有体现。另外看到了 DevOps 的工作内容。

这个工作内容一定是和 Dev 合作，才反映 DevOps，再就是把 Ops 作为用户，如果你把敏捷宣言的用户改为 Ops，它就是 DevOps 的合作框架。还有Ops的工作都是可验证的，最后可自动化。如果一个 DevOps 的工作不可能自动化，那这个任务做得还不够，所以我们根据这一点把 DevOps 的工作在一张卡上展现出来。

案例二 看不见的流程约束阻塞点

还是这个板，我们把 DevOps 工作摘出来，发现这几张卡需要 DevOps 工作一下。

其实这个图有问题，你看不见在哪阻塞了。

所以我把所有的阻塞的 Ops 工作全部拿出来然后发现，其实所有的 Ops 都被阻塞了。这是我说的看不见的流程约束点。

如果你的工作被 Ops 工作阻塞，要第一时间汇报，第一时间处理。在不断汇报和处理的过程中要进行总结阻塞的规律，并以自动化的方式和组织改进的方式进行改进。

案例三：看不见的 DevOps 的工作效果

当我把这些做完之后我看不到 DevOps 的改进效果，于是我整理了一个花了多长时间，做了六个月，看见 DevOps 的改进效果。

每个月发布1次，backlog3个，Dev 每张卡片开发7天以上，QA 是大概3天，阻塞时间是8天，一个卡完成阻塞8天，返工4次，其中一半是在测试环节，另外一半是在 Ops 环节。

6个月之后有些变化，每个月发布一次到每个月发布12次。不能只看发布频率，还要看质量提升，质量提升就在于开发时间短了，7天以上变成4-6天，测试环境缩短，就不要说质量向前前进，阻塞时间变少了。

这是因为解决 DevOps 阻塞点的效果，Ops 阻塞少，但是返工效率降低并不多。开发和测试还没有适应这样的工作方式，这3次里面基本都是测试阶段打给开发的。

流程改进目标

1. 看见 DevOps 工作验证的条件和效果。

2. 看见 DevOps 的工作量越来越少，DevOps 的转型是一开始找到一堆 Ops工作量，经过两三个月，这个工作量越来越少，一部分自动化，一部分通过工具的方式可以提高其他开发的效率。

3. 减少开发流程的待办库存，我的 DevOps 相当于团队里面开发的润滑剂，让所有开发任务不断持续的很平滑的进入我的生长环境。

4. 构造单一方向工作流，减少返回次数，尽量把质量问题放到前面，减少浪费。一个开发刚开发一个需求，这个需求在测试中2天就有一个bug，你再开发另外一个需求，这样就会打乱你的节奏，影响你组织的效率。这个需求开发的过程是往下的，尽量不要返回，返回就要进行反思。

5. 不断进行反思和学习和回顾，只有经过反思、学习和回顾，团队在开发过程中、运维过程、配合过程中才能不断的改进。

衡量 DevOps 的性能指标

衡量 DevOps 的性能指标，强调了四点：

1. 变更前置期，出来变更之前这个需求花多长时间。

2. 发布频率，大部分做 DevOps 转型都要衡量的指标。

3. 故障恢复时长，这是我强调频繁变更，我的故障恢复时长是不是变长了，或者变多了，这是总计的时长，更多的频率带来更多的失败，这对客户来说感受并不好。

4. 变更失败率，我上线多少次，有多少次成功、有多少次失败。

衡量 DevOps 的五个原因

• 第一，你的 Dev 和 Ops 有没有合作完成这个需求。

• 第二，是通过版本来管理住所有的变更。

• 第三，是主动式监控，就是做的时候设计好监控，主动监控，上线之后发现有问题再监控。

• 第四是高度信任组织文化，如果 DevOps 一个团队中大家还是相互甩锅，没有相互合作，那转型就没有效果。

• 第五是 Dev 和 Ops 有没有双赢的关系，相互帮助、相互成长。这样会减少双方的冲突。

可视化工具简介

我们用可视化工具来计算和度量我们的时间改变。

1. Jira，这是很强大的工具，不是做广告，确实非常强大，真的很好用，推荐大家使用。
   

2. 二是 Trello，上个月 Jira 把 Trello 收购了。
   
   我们用的其实是 Trello，它能满足我们端到端的需求。其次 Trello 有自己的API，可以用它来计算自己的时间。

大家要把自己的度量指标和改进效果记录下来，我非常乐意和大家分享和改进中的各种经验，也希望大家把更多的问题和我交流。

6.“看见”DevOps 的技术上下文

最后能看见 DevOps 的技术上下文。这是一个公司的 DevOps 的技术站，我们可以看到它把整个 DevOps 的技术站分两部分，左边是 Dev，右边是 Ops，中间是 integration 形成一个交互的闭环。

但是这里面缺乏一个内容，我在这个技术站里面看不到 Dev 和 Ops 的合作和沟通，所以现在最主流的工具是在上面加一个Slik（音），大家都在一个闭环里面，最主要的是你要在技术站的选择里面体现一方面是集成，另一方面是沟通。

这是一个产品图，是不一样的方式，是整个环，分几部分，每个部分有什么工具，这些可以在网上找到。

案例一：有Ops辞职了……

技术管理有一个问题，这是我碰到的一个案例，Ops 辞职，很多团队中经常发生。

Ops 辞职要交接，通常是有交，没有接，上一个人走了，下面的人很难把上面的业务接得很好。

交接都要从头学习，开头难、中间难、结果也难。

当一个Ops离职之后，他没有留下地图，你就只有徒步。这个图大家可能看不完整，意思是如果你迷路了，你就在原地等死。

这是我做的第一件事，就是梳理产品架构图，上面还有我的标记，我们用的是亚马逊 AWS，这是一个微服务框架。

我们现在重新做了产品的架构，把架构图画出来。之前我到团队之后才发现 Ops 没有架构图，每个人都只知道一点，我只有一点一点摸索才画出来这个架构图，这大概花了我两个礼拜的时间。

案例一：看不见的系统架构

这就是我所谓的看不见的系统架构，系统架构图为什么重要，我相信很少技术团队是有系统架构图的，很少人看这个东西，除非给领导汇报。

我去年参加的客户里面，我们会把系统架构图画出来，然后做成大的海报去贴到墙上，让每个员工看到我们的系统架构是什么样。

系统架构图给了所有员工产品技术点的上下文，大家都知道我们的产品用到什么东西，大家对这个产品共担责任。

所有人可以进行学习和改进，我看到产品架构图我知道什么是我知道的、什么是我不知道的，我对不知道的就进行学习。

最重要的是从你不知道你不知道做什么到你知道你不知道做什么，这样通过系统架构图可以同步很多信息。

案例二：看不见的 DevOps 技能

案例二，大家做 DevOps 的时候，会有看不见的 DevOps 技能，大家会技术栈，每个人掌握程度怎么样不知道。

之前看到有人进行能力矩阵，有一个问题是，比较虚，你很难用一个客观的指标衡量，我们定义的指标是 DevOps 需要哪些技能，我招聘一个 Ops 或者 Dev进来，我需要哪些技能？

我定义了四个熟练度：

• 第一类就是，没有听说过，记为0。

• 第二类就是，我用过，记为1。

• 第三类就是，是可以讲出原理，最佳实践。记为2。

• 第四类就是，可以训练别人。这是我们非常看中的。记为3。如果在一个DevOps 团队里，这一点我们是非常看重的。

这是我们的一个例子，这个列表很长，一共38项，从开发到运维的所有技能都列在里面。比如我们 splunk 作为打包工具，会的只有一个人，我们这个团队就是风险点，我们需要提升，我们会降低这个风险点让其他人提升能力。

另外我们看到 NPM，大家都会，这个能力我们并不是很担心，这也不是我们亟待需要提升的能力。所以我们会把这个能力多花点时间让大家集体进行培训。

案例二反思::
 我们在做DevOps技能的时候可以做到以下几点。

1. 从团队的角度出发，而不是个体，我招聘的不是一个人，而是一组人，我要带来的是组合转变，而不是一个人转变。

2. DevOps 是自治的，鼓励每个人去学习，提升团队的短板。

3. TruckTest，卡车测试，意思是一个人今天被卡车撞死了，这个团队会有什么影响？我们做的是，每个迭代做交接，交接的事情工作量就变得很少，真正有人有问题的时候，那工作量就不会那么大了。

4. 客观评价和主观评价，刚才说四点，从没有用过到用过到知道原理、最佳实践，到可以训练别人，前面两点是主观评价，后面两点是由团队的技术专家，技能。

到3、4的人来评价你是否达到3、4，不可能都是客观评价或者主观评价，都是客观评价太浪费时间，都是主观评价也不行。

案例三：看不见的 DevOps 技术债

看不见的 DevOps 技术债清理，现在用的 jinkins 是一个很老的版本我们一直用到现在，我们现在碰到一些新的技术栈，很多插件我们用不了。我们做版本对比之后，版本有一个流水线即代码的功能，这样可以摆脱很多流水线的问题。

其次我们支持 Docker，因为我们要使用 Docker，以及安全性、稳定性的更新，这对电信企业和金融企业很重要。

我们看到大部分已有技术栈的原因是这样的，基础设施不一定是一成不变的，基础设施的软件也要更新。

技术债也会产生利息，随时都要明白自己欠多少钱，如果信用卡透支或者债务逾期会给你带来毁灭性打击。

常见原因是没预算、没时间、没人，无论任何经理怎么规划，它的资源都是不够的。

所以这个东西我们把它放到平常做，平常自己花一点时间，比如我们工作8小时，留下1-2个小时做这些事情，只挑1-2个人，业务能力强，技能比较强，让他做这方面的事情。

案例三反思

第二点是饭要一口一口吃，路要一步一步走，如果步子太大就会“扯蛋”。我们清理技术债的时候，首先要建立技术债清理清单。二是评估升级的风险和收益。三是建立优先级。四是进行并行和替换。

案例四：构建 DevOps 的技术雷达

根据以上的总结，我们构建了一个 ThoughtWorks 的技术雷达，二是持续交付的实践，三是团队技能。

第一步构造端到端的活动，我从开始计划到运维监控和发布，我做这些活动。

二是列出很多技术栈，有了技术栈，这只是一部分，最重要的是要知道最佳实践是什么，这些是和工具无关，这是要做这件事怎么做到最好。

像前面说的，我根据之前的熟练度来谈我这些技术团队的优先级，优先级排完，我找到侯选工具，因为后面用Docker，在最佳实践上就有些侯选工具。

根据这些侯选工具来培养下一阶段 DevOps 转型要清理的技术债，以及清理技术债要的人，推进团队不断改进，这不仅仅是 Ops 的工作，也是 Dev 要参加的工作。

把这些 Dev 在一起就变成这样的技术雷达，最中间是可以采用的。这对应几个流程，有了这个过程之后，每过三个月或者每隔半年，我们把大家学习到的技术和碰到的痛点拿来总结，形成技术雷达来指导 DevOps 团队技术的转型、技术的培训和组织的更新。

这是 DevOps 的技术雷达。

7.“看见”DevOps 的技术上下文

---

通过以上看到 DevOps 转型的全景，这个全景是通过组织上下文确定 DevOps 的改进目标和范围。二是 DevOps 工作流上下文，我知道它整个端到端的工作流是什么。

大家看过《凤凰项目》一定了解三步工作法，通过三步工作法度量整个 DevOps 的转型效果，构建 DevOps 的团队和文化。最后通过 DevOps 的技术上下文，尤其技术雷达，这是我总结出来的方式，来提升团队 DevOps 的技能，以及技能在 DevOps 团队的落地。

记住： DevOps 永远不是一个人的事，而是一群人的事。

谢谢大家！

没看过瘾？

来 DevOpsDays 上海站吧！

顾宇老师将带来更精彩的演讲

《 无服务器化的微服务持续交付 》