案例 | 可视化的方式解决 Dev 和 Ops 的相爱相杀（上）
案例 | 可视化的方式解决 Dev 和 Ops 的相爱相杀（上）
前言
我是ThoughtWorks的高级咨询师，工作9年，曾参与中国移动、中国联通手机BOSS系统以及呼叫中心系统的研发。担任过售前、项目经理、维护工程师和开发工程师等职务。在乙方公司除了销售没有做，其他职务都有做过，主要负责维护和开发这些系统。
加入ThoughtWorks之后接触敏捷，并在不同敏捷项目中担任不同的角色。我做过BA、QA最后做到 DevOps，现在专注于 DevOps 以及微服务相关领域的咨询和实施。图片下面这是我服务的客户，其中10个客户里面有8个都是做DevOps。
DevOps原本的问题
关于我们 Dev 和 Ops 的一些问题，主要原因是 Dev 和 Ops 遇到问题经常性的相互甩锅，在这种层面往往会吵架。
DevOpsDays 是一个吐槽大会，大家相互伤害、相互吐槽。然后在相互伤害之后还要相亲相爱，因为还要相互合作去工作。
所以 DevOps 最后决定如何优雅的相互背锅。
DevOps 原本的答案—共同背锅
我们原先的 DevOps 给的解决方案，DevOpsDays 总结出来，这个锅开发、运维都不背，大家一起背。
DevOps 如何优雅的背锅
所以就有了这么一个模型，这个模型讲了 DevOps 的两个基本的核心和一些重要的技术活动和管理活动。
DevOps 核心
以快速交付业务价值为目标，通过技术升级和流程改进，减少业务价值交付中的浪费,这是DevOps的核心。
DevOps 实践中遇到的一些问题
常见的问题，这是大家经常看到的图，DevOps 的概念已经很大了。上一个被玩坏的概念是敏捷，敏捷下面有很多东西，下一个被玩坏的概念就是 DevOps，里面也有很多东西。
很多东西都是片面性的，可能是看板，可能是自动化，然后从组织结构上面又要求合作，所以它有很多不同方面的东西。
DevOps 忽视组织改进
在我参加 DevOps 国外咨询项目、转型项目之后，了解我们国内的项目，大部分问题是忽视组织改进。
这里面要强调的是，康威定律。
康威定律：设计组织，其产生的设计和架构等于组织建的沟通结构，如果组织部转型，仅仅做技术转型是不行的。
如果你考虑技术，不考虑组织转型，你的微服务也是半成品。还有很多厂商用的很多工具，不管是开源还是买来的，企业级工具都是变成玩具。
很多企业在和我私下交流的时候，都是提到 DevOps 就是如何快速交付软件、如何快速上线、如何自动化、如何更加稳定。
很多人忽视了质量，我们强调一点，DevOps 提升速度的前提一定是质量不能下降，它可以维持，不能因为要提高交付速度而牺牲质量。还有一点是人员的技能培养和团队建设。
DevOps 缺乏度量和约束分析
DevOps 缺乏度量和约束分析，这是大家长期应用的图，流程图，里面找到一个约束点是和 DevOps 合作的部分，并不是所有企业在 Dev 和 Ops 都有冲突。
如果有些企业的质量管控措施十分严格的话，做得非常好的话，质量也会好，做质量提升的效果和 DevOps 做出来的度量效果是一样的。既然一样的，DevOps 和我的质量提升到底有什么分别呢？
这来自《凤凰项目》，我做 DevOps 缺乏度量和约束分析，只是在于如何更快交付项目、如何更快上线我的业务，那是没有达到目的的，一定要找到自己的约束点，这个约束点就是你让整个系统变慢的点，这个话来自《凤凰项目》，对非约束点的一切改进都是假象。
DevOps 缺乏技术栈管理
他错误引用一些工具，然后造成更多成本的浪费，这是 DevOps 实现的另外一个问题。DevOps 缺乏技术栈管理，这是 DevOps 概念有，包括之前产生的框架，这个东西塞给每个人，大家都会觉得很恐怖，现在你实施 DevOps 或者微服务，你会看到大而全的基础栈，里面有很高 DevOps 的门槛，这是我比较反对的一点。
最主要的问题是：
第一，不知道选择什么样的技术 第二，不知道如何进行技术升级 第三，不知道该培养哪方面的能力 第四，不知道招聘什么样的人
综上所述，这是我们发现 DevOps 的三大问题。
- 我对 DevOps 约束点是把握不准的
- 技术管理不到位
- 我对 DevOps 的理解是片面的
DevOps 在不同的上下文里面意义不同
最早讲 DevOps 的时候，就一个开发人员和一个运维人员，后来他们的合作变成 DevOps，这是最初的 DevOps。
后来在开发人员扩展到开发部门，开发部门可能又有 BA，这是敏捷的团队，有BA、QA，对应业务分析和质量分析师或者测试人员。在 Ops 团队里面多 DBA 和网络工程师，最后形成开发团队和 Ops 团队之间的 DevOps。
在这有一个问题是，DevOps 最早是来自于互联网企业，把互联网企业先进的 DevOps 合作思想放到传统企业去应用，对于传统企业来说，我是一个IT部门，对于互联网企业来说我可能就是一个产品部门。
所以对互联网企业来说，我可能会有一个业务团队和开发团队一起工作，这就变成我的业务开发团队以及我公司的业务运营团队，这是另外一个层面的 DevOps。
DevOps 是一种组织特质
从这一系列来说，由于我的 DevOps 组织上下文是不同的，所以我们可以看到 DevOps 是一种组织特质。
这是来自一篇博客。我们说 DevOps 是一种组织特质，不仅仅是 Dev 和 Ops 放在一个团队，让他们产生合作，不管是组织还是技术，另外不仅仅是一个职位，是一种工作特性，如果是一个职位叫 DevOps，那要促进整个团队的 DevOps的合作化，包括技术和管理上两方面的改进。
DevOps 不仅仅是技术，我们最前面说的忽视了组织转型的 DevOps 一定是不完整的 DevOps。不仅仅是自动化运维，我今天听到很多演讲，它都讲如何做运维工作的自动化，所以 DevOps 不是自动化运维，不仅仅是，所以它是一种组织特质，是一种工作方式，大家在一起的工作方式。
如何判断 DevOps 转型是否完整
所以在这里面，我们通过如下模型来判断 DevOps 转型是否完整。
- 是否有 DevOps 的团队建设，可以考量自己的团队。
- 是否有责任边界的变动，因为不同的团队的组织有不同的 DevOps 的工作方式和组成模式，它是不一样的。如果你的责任比以前开发变得更多，这是责任边界的变动，这是 DevOps 转型的重要标志。
- 是否有技术升级，技术升级一般是一定有的，这是大部分做 DevOps 要强调的。
- 是否处于不断改进的状态。像我之前的一些客户做完一期 DevOps 之后，还获得短期的效果，效果很好，我离开这个团队之后，这个团队没有再进行自我改进和不断改进，那就是死的 DevOps，不是活的。
所以要通过不断改进的方式，比如敏捷的回顾会议让团队不断自我改进，这是很重要的一点。因为有了 DevOps 团队之后，技术真不是很大的问题。
通过可视化“看见”DevOps
第二部分，通过可视化看见 DevOps。讲到 DevOps 有一个问题，神奇的 DevOps在哪里？如果看不见就找不到。我们看一下为什么需要通过可视化看到 DevOps。
为什么要可视化？
- 第一点，人们只关注自己看见的东西，看不见的东西往往不存在。很多非DevOps 只关注技术的团队只看到技术的变更，看不到组织带来的发展和组织带来的这种生产效率的提升，很重要的是大家只关注自己工作的那块，没有全景图。
- 第二点，人们选择性接受信息，只会看到和听到自己想听到的信息。所以团队要建设可视化的上下文，世界上60%的人都是视觉动物，所以建立可视化的上下文是很重要的。
- 第三点，看见是改变的开始，看见这些问题，你才知道下一步怎么改进。我们通过可视化看见 DevOps 有几点，人们总是看到自己做什么，但是不知道自己为什么做，以及不知道如何做。
通过可视化看到 DevOps
这是人脑的一个模型，最外层是大脑皮层。人们总是看到自己做了什么，而不知道为什么要这么做，以及不知道应该如何做。
那么我们接下来讲可视化会将三点，可视化分三点
- 一是告诉你做了什么
- 二是如何去做
- 三是为什么要这样做。
“看见”DevOps 的组织上下文
我们现在第一个看的是电信企业的组织上下文。
如果大家在电信企业工作，中国移动、中国联通、中国电信，他们都有非常高权力的部门叫市场部门，下面有一个digital部门，通过网上查询自己的余额、充值都是这个部门做的接口。它还有 Boss 部门，是核心部门，它经过相关的APP把对应的业务请求传递给 Boss 部门。还有客服部门来对应客户的反馈和服务请求。
如果有新的市场活动，比如 iPhone 下礼拜要问世了，新一代 iPhone 的市场部要下三个任务，给客服部门做好客户宣传工作和各种问题的答疑，再给另外两个部门分别下命令。然后他们会把所有的需求都汇应到Boss部门，之后再和市场部门拉一个会，大家一起去讨论各方面的诉求，相互扯皮，最后自己干自己的事。
案例一：Digital 部门内部 DevOps
在线市场移动APP的部门，他们说我们需要 DevOps，这里面有个问题你为什么需要 DevOps？他说我们有些任务处理不过来，你一般找一个 wonder，有些业务需要是外包的。
我们有一个 DevOps 的团队，有两个产品团队，一个产品负责的是用户自助服务，另外一个产品是负责客户在网上选套餐。
我把这个图画下来的时候，我就发现第一个问题，分离的 DevOps 团队，这是不好的实践，但是是一个团队从0到1做 DevOps 转变的必要阶段，它需要一个 DevOps 的团队去组织它的一些技术，达到统一化和定制化。DevOps 团队转移初级阶段必要，后期阶段肯定会出现饭模式阻碍你发展。
我把组织上下文放了之后，它上面有一个老大，下面有两个 manager，一开始我们以为三个团队会在 managerB 下面管，managerA 不负责这些事，但是我们通过进一步梳理，发现 DevOps 团队不归这两个管，是归 Boss 管，但是你在企业的组织结构看不到这一点，它有职位表，他的职位和实际的权力不划等号。
我们碰到的问题是 DevOps 的工作太饱和，DevOps 的团队都在加班，所以当时他们决定再加两个人加两个 DevOps，但这仍然是分离的 DevOps 团队。
我们把这两个新加的 Ops 角色，其中一个是我，我在这个团队里面，建议加到和开发团队一起，我们从这个部分的工作分一部分和开发团队一起的工作来做，这才是完整的 DevOps 团队。
而且我们解决的痛点，虽然看起来是这个团队在不断的加班，实际上是这个团队很多的 Ops 需求自己处理不了，而把这个交给 Ops 团队，这样造成他们加班。
案例一反思
所以我到的第一个建议是我们和开发团队一起，了解他们的痛点和诉求，帮助他们解决他们的问题，分担这个团队的工作量，达到了很好的 DevOps 效果。
从这个案例里我们可以看出区别 DevOps 特性的团队应该是一个全功能的团队，DevOps 是一个跨产品团队的虚拟团队。
虽然我和另外一个 ops 团队在产品开发团队里面，但是仍然组成一个 DevOps 的虚拟团队进行交流和相互学习和改进。
还有一点是从资产管理视角转向产品演进视角。DevOps 的 Ops 团队找到客户的核心资产，我的主机、网络、存储、安全性很高的信息，这是资产管理视角，但我如何把我的产品和资产结合起来发挥更大的价值，这就是 DevOps 的视角。
我们通过产品的引进，以产品为核心来讨论，我们的 Ops 如何给我们带来团队提供更好的开发体验。
案例二： DIgital 部门和 Boss 部门的 DevOps
很多团队我做 digital 团队要和 boss 打交道，它是另外一个部门，这是两个部门之间的关系，我在里面，如果客户通过我们开发手机 APP 的产品，到 Boss查话费，boss 这边反馈数据，我们反馈给客户，客户会看到话费是多少，这个版本更新很慢，三个月才更新一次，一年更新四次。能做 Boss 的厂商世界上没有几个。
我们是已经开始演进的团队，但是 DevOps 的速度很慢，一个月出一个版本，更新一次，还有大量的测试工作。
我们在这里面做一个事情，对于两个团队需要合作，而且发布速度不一样的团队来说，我们中间做了一个 Stub，我们做的虚假接口是通过自动化的手段，根据业务场景去找人把它收集下来，形成我的测试，然后每天去自动跑。
跑了之后，就可以把 Boss 团队和开发团队解耦，我知道 Boss 这边有更新，我要和他同步更新，改变我打桩的框架，以符合业务发展。
这相当于两个组织之间建立速度齿轮，让两个不同速度的IT团队之间有一个比较好的协同的速率转换的装置。这样对两个来说压力都很小，我不会因为它的阻碍而导致我的业务不能继续发展。
案例二反思
- 第一、跨部门 DevOps 组织变更之前要进行技术变革。 在这里面我有几个启示，组织变更之前要先进行技术变更，我再一个部门很难推动另外一个部门的转变，我们需要提出技术解决方案，技术解决方案，部门的 boss 相可以理解。
- 第二、构建部门间的差速轮。 我们通过这个齿轮协调两方的工作速度，以进行两方工作耦合度的解耦。
- 第三、构建沟通机制和责任共担机制。 沟通机制和责任共担机制，如果出问题就相互查一下是谁的问题，最后开会，到市场部，市场部老总各打50大板。现在是有问题我们一起商量，目前还没有进行，这是我们期待的方式，我们和他们的工程师进行底层的沟通，还没有通过高层 Boss。
案例三：Digital 部门，Boss 部门，和 Customer Service 部门
案例三，这是跨三个部门之间的 DevOps 合作，方案呈报上去了，但是没有实施。也是因为组织变更是比较难的事情。
一个手机用户用 APP 查话费，根据后台应用转到 Boss 部门，这个用户15秒钟触发很多请求，结果直接把 Boss 弄成宕机，还好有紧急的热备份装置。
然后让我们查找原因，两个人查找了将近两周，一共10天，每天付1万左右，也就是20天花客户20万，解决这个问题还没有解决出来。
因为当时有告警，但是当时没有查，是两周之后才知道这个问题，通过搜日志，翻以前的浏览记录来看这个用户究竟发生什么问题，花了这个部门将近20万的预算做这个bug修改。
如果让我这样做我们如果直接联系客服部门，说我给用户一个简单的流量礼包，10块的优惠或者流量包，你告诉我刚才出了什么问题，在我们三个工程师一起解决这个问题，客户肯定是很愿意的。就不会通过两周的时间再重新对接这个问题，还没有查出来是什么问题，白白花了客户20万的预算。
这是一种联动方案，但是我知道这种方案很难执行，因为你动了别人的奶酪。
案例三反思
反思一—为什么要看到 DevOps 的组织上下文？
1、DevOps转型的困难在于制度而非技术，你构建很好的DevOps团队，这些DevOps技术是通过自我改进而发展的，这是自趋势的团队。 2、你要在组织转型中看到谁是Dev，谁是Ops。 3、明白自己所能触及的改进范围。 4、基于制度的转型都是幻想，逃脱不了康威定律。你的制度和系统的结构是强关联关系。 5、明白权责以及给DevOps带来的阻碍以及责任共担所带来的益处，这样通过转型前和转型后，组织的结构图、上下文结构图，可能很快就可以看到带来的益处和阻碍。
反思二—如何可视化 DevOps 组织上下文呢？
1、找到 DevOps 改进的利益相关人。 2、找到 DevOps 的组织边界。 3、可视化全责层级关系。 4、构建组织间的差速轮，也就是组织间速度协调的齿轮，可以达到沟通协调机制。
反思三—可视化 DevOps 的组织上下文的意义
构建可视化 DevOps 组织上下文的意义在于 DevOps 转型一开始就是自上而下的，如果平级或者上级转型是推不动的，刚才的三个案例只有第一个成功，剩下两个技术成功，还没有完成。