运维助力敏捷交付

毕宏飞

作者简介

前言

今天我们的分享主要有以下5个部分：

1、运维面临的挑战
2、敏捷开发方法
3、我们的运维看板
4、运维与敏捷软件生命周期
5、运维也可以很敏捷

我们做这个分享之前想过很多，要不要从工具入手？要不要从思想入手？后来发现实际上有很多的环节被忽视掉了，那就是运维在做 devops 的同时，会有很多的时候其实是一个中间灰度的情况，也就是工具没有达到的地方，我们该怎么样去解决我们平时碰到的很多棘手的问题，用看板的方法来解决。运维在这个大背景下它有什么挑战，它能做一些什么工作。我们也想展示一下在一个公司里面怎么打破这个部门的墙，在 devops 领域做一些事情，主要分享的就是实践的经验。

一、运维面临的挑战

1.1 运维的发展过程

我们都知道运维的发展过程，其实我们从以前最早的时候是很简单的，标准化，流程化，自动化，最终实现平台化，这个是一个比较大的里程碑式的阶段。

但是我们没有标准、流程、自动化，到平台，可能有些东西需要两到三年的时间，甚至有些更久。

我们知道运维被分成四大类：

• 第一类就是业务项目，包括服务的管理；
• 第二类是IT的内部项目，这部分的工作比如我们做工具，做服务，我们做IT内部的东西；
• 第三类是变更；
• 第四类就是我们最害怕的，就是救火。

但是我们发现你救火做的事情越多，你就越没有时间做前三类的工作，IT内部工作做的越好，你就会越少做事情。其实运维工作在整个的过程当中，时时刻刻都面临一种现象，这种状态一直存在的，我们不能忽视。如何让运维在这个过程当中过渡的更好？

1.2 运维遇到的问题

在这个过程当中会经常遇到什么样的问题？

第一个，反馈不及时。运维内部没有及时的反馈机制，其实我们做完了，或者我们已经达到一种地步了，但是业务部门不知道，他们就会觉得我们运维的效率非常低，因为每次跟他们说什么他们都没有任何反馈。

第二个，我们根本都不知道怎么样去预估明天的工作是什么，会有多少？因为工作救火或者临时性给的任务非常多，而且给你的就是必须要做。

第三个，我们没有办法衡量工作导致的问题，就是平行部门给我们的定义，效率非常低。

第四个，以工作导致的严重挤压，非常多的工作，四个运维工程师里面每个人手里有一二十个小事，非常多。每天问他们进度的时候都说正在处理，问处理到第几个或者怎么样，大家都不知道。

第五个，任务的风险经常被侥幸心理带到项目里去。

第六个，每个公司都面临的问题，就是个体能力的差异，偷偷给团队带来风险。有一些运维工程师很厉害，基本上什么问题都能解决，所以他的领导看待这个运维部门的时候，会觉得没有任何风险，因为什么问题都让他解决了。但是等到这个人离职时你会发现什么问题都出来了，因为很多问题解决都是他自己个人解决的，并没有分享给团队，这个就是给IT带来的风险。

而事实上我们看到所有的东西，所有运维面临的问题，就是运维交付的过程，跟产品交付过程实际上是比较类似的，风险是比较类似的。

他们集中要解决的就是两类问题：一个是人手资源冲突问题，另外一个是时间冲突问题。之前我们做敏捷，把产品、研发、测试全都拉到一块做这个敏捷开发，是为了解决冲突的问题，但是运维没有这个看板。而运维里面所爆发的问题都是现象，其实本质也是一样的，也是时间冲突跟人力资源冲突导致的。当时跟我们的敏捷教练说过，我听过一两次他们的看法，我问到我们现在每天碰到的问题，我看到我们项目组每天早上都有站会，都挺好的，就跟我们敏捷教练聊了一下，他说完全可以。也许这样能够解决运维的问题，而且把运维变得敏捷一些。所以我们今天讲这些其实最终是想交付给大家的，最想交付给你们两个东西：第一个听完这个分享大家都能够理解什么是敏捷；第二个回去之后你们就可以在内部直接上板一个内部看板，解决你们棘手的问题。

二、敏捷开发方法

敏捷的开发方法，为什么会想到这个主题？华东地区的敏捷教练也是非常多的，我是在外企工作了11年，为什么会有各种敏捷方法PK的出现呢？我2016年去了中交新陆，听我们公司像国企，确实有点偏传统的公司，但是我们公司是做智能交通的上市集团的子公司，而且货运车联网行业的第一。我们有一个500万货车的平台，每日产生的数据大概超过10亿，我们是一个车联网大数据公司。我进入这个公司以后就做了很多的尝试，我是怎么选择敏捷转型的方法，怎么把大家带到敏捷，或者是 devops 这个轨道上来的？

你看到敏捷这个词，会首先想到的是什么呢？可能大家会想到提高效率，或者降低成本，还有一些提高质量，快速发布这些东西。其实这些是敏捷可能会产生的一些结果，但是有的时候做的不好，就不会产生这个结果。最初这个词的含义只有一个，渐渐演化为对敏捷公认的解释就是灵活而优雅。

下面这个图是现在大家口中名词比较多，精益、敏捷、看板 、XP。

左上是精益思想屋，右上角是敏捷宣言，所以在外围这个行业，精益是代表在转型中的一种文化和思想的东西。下面看到的就是目前使用最广泛的三个敏捷方法：Scrum，看板，XP。

2.1 精益思想

敏捷宣言稍微强调一下，我们现在有一些创业团队或者是初创的团队，他可能会觉得在敏捷实施的过程中虽然有价值，但是右向也是有价值的，就是在敏捷过程中，很多公司发现敏捷有的团队认为是必须要过程和工具，或者不需要文档，或者不需要遵循计划，其实不是这样的。敏捷其实还是需要一定的过程或者是计划的。

精益是怎么过来的呢？它来自于丰田的生产方式，在五六十年代是来自于制造业的。精益现在非常火爆，一直到现在的精益创业和精益企业的思想，我们不一定把所有制造业的具体方法都搬到软件业这边，但是比较重要的一个精益思想就是一个五大原则。

• 1、重新定义价值
• 2、识别价值流
• 3、建立不间断的流动的工序
• 4、实施拉动式的生产
• 5、重新建立不停的循环过程，以追求尽善尽美

这样说可能在概念上不太好理解，我举一个例子，精益思想的核心是美国人总结的一个丰田生产方式，为什么要总结呢？因为丰田汽车想打入美国市场，那个时候碰到一个很大的竞争对手那就是GE，那时GE是大规模生产的代表，丰田公司怎么做的呢？一开始的时候他不是从产品设计到开发到测试，最后推到市场，这样从前往后推的过程。他是先设计，然后铺到各种市场上去调研，然后一个小规模的技术，就是生产汽车一次只生产一个十几台的小批量的规模，这样建模的技术会发现哪些车非常受欢迎。在这个过程中他先利用小批量的生产，会减少巨大的浪费，然后后面包括有一些丰田普瑞思这样的车型在市场上大受追捧，这样打败了美国的一些汽车制造厂商。因此美国人从这个总结出来，把日本人做的这些思想总结出来，所以这本书其实是美国人写。

2.2 Scrum

Scrum是一个项目管理的框架，Scrum它就是三个角色和五个事件。

三个角色就是项目、团队、敏捷教练，这个敏捷教练其实有点取代于以前的项目经理的角色，因为很多团队没有项目经理。五个事件，首先建立一些条目化的概念，还有迭代的概念，其次就是要有一个时间核，然后做完计划以后会产生的对于迭代的产品，在中间还有一个事件就是 Dily serum 。然后在迭代结束我们把可攻破的软件演示出来，最后一个就是回顾会议。在这个里面我们可以看到它是一个项目管理框架，在敏捷最开始流行的时候，它有一个标准的做法，而且对于团队来说非常好去模拟，所以在敏捷的传播过程中起到了一个非常重要的作用。敏捷迅速的发展起来，但是它有一个问题，就是大家可以知道在 Scrum 转型过程中，可能要求有三个拆分：一个是要把团队拆分成大概五到九个人；二是拆分产品，可能把一个很大的产品线拆分成小团队可以做的小的产进模块；三是拆分时间线。所以像我们以前这种纯外企，或者有一些偏外企风格的公司，会比较容易接受这个过程。但是我们现在面临的很多传统的或者中国公司，在很多时候直接上 Scrum 就会有一些问题。

2.3 看板

我进入这个公司以后也是因为机缘，花了很多时间去研究这个看板，而且看板也是近两年上升最快的敏捷看板之一，它也是尊重各级的现有的流程和领导力，所以在这个过程中大家看到的可能只是一个看板墙，但是其实里面的东西很深奥。

这是在2004年出版的小蓝书，从制造业转到敏捷业标志性的事件。其实这个和制造业的做法还是有很多的差距，这个看板核心的标志上面有很多WAP，还有一些紧急通道这些，还有一个流动，这个就是看板的标志。

在这个精益里面，还有一个就是不希望库存太多。你在做的东西，我不希望你放太多的产品在这个环节，这样就会导致我们很多精力没有办法马上交付，我们宁可做的东西少，但是我们希望能做一些就马上交付一些。

看板的三大实践：一个是可视化工作流，把这些工作完整的在看板可视化就可以了；第二个是在一些制品限制上，慢慢把你这个团队流速加快，然后带到一个更敏捷的轨道下面；第三个是我们要通过看板目前的团队度量去管理你自己这个团队的流速。

2.4 XP

XP不管是 Scrum 还是 kanban 都是要采用的，在九十年代出来了 Kent Beck ，出来13个工程实践。

我们看各种敏捷开发的对比，前面的RUP就是传统的开发流程，而 Scrum 就归结为九个事件，但是看板就只有三个了。所以对于一些不想采取很激烈的组织或者公司来说，看板是启动敏捷非常好的一个方法，但是对我个人来说我并不是说不喜欢 Scrum ，如果说做纯粹的创业团队，用 Scrum 也是有很多优势的。

三、我们的运维看板

这就是为什么我们运维人一定要看看，因为它简单。刚才第一部分我们讲了运维的情况是什么，有哪些方面比较糟糕，在后面我们看了运维怎么做。

3.1 看板实践

这个是我们一个大卡，是300万左右的卡车司机用的APP，这个产品包括了待开发和开发，待测试区、测试和完成，这个就是我们日常比较常用的看板。我们每人会贴大概三个人头像在这里，每个人会领一个工作，为什么贴三个？是因为每个人不能同时超出三项工作。因为我们知道每个人手里超过三个事，它的效率就会下降非常厉害。所以我们用人头表示他今天做了几个事。

上图是我们平时用的电子看板，有些团队喜欢用电子看板，大家可能开一些电话会议，然后就做了这样一个 JIRA 电子看板。

3.2 看板出现的原因

运维看板出现的原因跟诱因是什么？

首先看第一个问题，领导说：“上次跟你说关于《服务器使用优化率》，你有什么进展？”这个时候下属应该会跟领导延伸对视五秒以上，说一句这个不是说一说吗？其实不能怪下属，因为领导的思路变的太快了，也有可能变的跟不上，不确定因素太多了。我们需要什么？当时我们就定了这样一个机制，我们放一个看板。

首先我们把运维所有人，包括我们的SA、NA，包括我们业务支持的人，所有人都叫过来站会的时候都说一下你今天做什么事情，进行确认，大家都上来讲。然后看到那个下属就会在写一张条，说领导你跟我说要做服务器优化的事，还要不要做，领导也想不清楚就说先这样贴着，有可能做，也有可能不做了。

然后第二个问题是一些问题没有解决，没有结论，没有跟进。

有一次我们有一台服务器出现故障，出现故障的时候我们第一反应就是解决故障，然后再找问题。我们把问题踢出去了，问题就解决了，这个时候就会安排其他工作，这个机器放外面半个多月，结果慢慢的这台机器就被人遗忘了。过了好久有一个新项目上线，资源还不够，这时候有人告诉我机房里面还有机器使用率很低。这个问题说明的就是没有解决的时候，没有结论也没有跟进，这是最重要的。还有一个就是天天忙，但是不断被投诉效率低，为什么？就是因为做的运维反馈慢。其实内因是任务的跟进太依赖于人，没有依赖于制度和工具，这个时候我们需要一个看板。

这是我们现实当中的一个看板，我们把工作分成四大类，虚拟化、持续交付、监控系统、自动化巡检、项目支持，还有运维工具优化。这样的话大家感觉很默契，或者有一个机制来保障。

第三个是我们把所有的木桩当做是我们的任务，然后这个河流当做是我们部门所有人的战斗力，或者叫工作的能力极限。

它会导致这个地方阻塞，因为我们很多东西都 Doing 这个地方。

上面这个就是我们在运维看板的时候需要关注任务类型的重点、风险、阻碍。我们也跟下面的人说，如果你手里有三件事以上，你来跟我说，我来安排第四件事不要落到你身上，这样我也好控制，他也开心。这样老大也是在做我们该做的事情，而不是单纯的做一个路由器等等。

第四个问题我们经过了一段时间发现有两个任务卡差距特别大，一个任务卡写的是自动化运维平台2.0的开发，另一个就是货运平台某台服务器修改ssh参数。这个后面的修改可能只要五分钟，前面的是要将近三个月的时间，这两个就完全不合理。这个工作量大的卡片放在这个地方会埋很多的雷在这，有可能三个月以后你问他，他还没有做好，那我们怎么做？

我们就需要把大的木桩切开成多个小的任务，打比方，我们先把一个大的平台分解成二十几个小功能，然后又区分优先级，这样领导也能够正确评估一个东西。这个是我们所要讲的，我们要管理跟加速这个流动，如果有任务卡，再一个地方长期滞留，那是一个大问题。

第五个问题是虽然做了不少的工作，但到年底发现年底总和年初计划对不上。年底做领导的基本上都快受不了了，因为年初领导跟领导做集合安排的时候，等到那个时候是十个任务里面有五个都没有完成。我们在做每一个小的任务卡的时候，都会让每一个人关注一下今年部门总体的目标是什么，如果你这个不明白，那基本上他今年是不可能及格的。

我们是希望每一个人知道的核心任务是什么，他就知道哪个任务应该做，而且做的更好，哪些东西勉强应付一下就行了。同时我们会在小红筐里标出来，这个是我们参加看板的部门一共有九个人，也就是某一个阶段，某一个是最核心的，需要投入非常多的人。这样的结果就是让我们能够每一个人都跟领导的思路是统一的。

四、运维与敏捷软件生命周期

现在 devops 这么火的前提下，大家可能比较关心的是我在越来越快的行业转化过程中我们运维在敏捷这个过程中它会站到一个什么样的角色，或者怎么样去转型适应一个新的软件开发的模式。首先我们看一下传统开发方法和敏捷的开发方法现在有什么样的变化。

之前看到的是从设计到开发，到测试，到部署，或者是管理，或者是评估，会发现每一个单独的过程，它是有单独的团队来做。现在 devops 的这种开发方法以后，最大的变化就是在每一个步骤中，他会加入了不同的团队，在一起协作。所以它很大的一个变化就是越来越协作化的开发，敏捷在设计业务这块，在整个软件开发过程中，会起到一个很大的作用。有的说是产品为王，所以在敏捷开发这个过程中产品经理这个角色会变得越来越重要。敏捷交付这个过程中我们运维能做到一些什么东西呢？

这个敏捷交付三阶段并不是一个标准化的，我用的是一个大功能开发DAD来做阐释，DAD一个是开始阶段，中间那个阶段是构造，最后是有一个转化的阶段，就是部署解决方案的阶段。在这三个阶段里面运维到底能做什么呢？

4.1 开始阶段

首先在软件开始阶段的时候很重要的要把需求的角度把运维作为首要干系人，如果没有运维参与这个评审，那就是日志与监控相关的需求。还有服务级别协议的规定，容量规划，业务连续性的服务和策略，信息安全。

4.2 构造阶段

在构造阶段，持续交付流水线。我们很多做运维的可能会把整个持续交付的工具会放在我们自己的身上。因为我们部门以前敏捷质量部，一直在强力的推，所以我是建议我们如果要做的话，就要靠跨部门来做。

4.3 持续交付平台建设

在 devops 持续交付平台建设中，其实它是有不同的过程。

它是一个有构建单元测试、打包，还有代码库的管理。由于我们原来传统的工作，测试环节就是有测试的动作，包括自动化的测试、手动的测试。然后预发布环境，做一些大型的模拟测试或有流量的测试。为了做一个 devops 持续交付平台，我想里面的内容不是最重要的，大家要看你能够做哪些事情，然后我们怎么打破这个链条。

我看到一本书，跟我们分享了两个东西：第一个叫做野蛮生长；第二个叫绞杀。我们知道每个公司里面它的发展是野蛮生长，最终要求业务的部门迭代。什么叫绞杀模式？就是在热带雨林的时候，有一颗榕树，一个小鸟吃了树的种子，然后小鸟粪便落在原来大树的身上，这样小树会偷偷长大，最后把这棵大树给挤死了。研发的痛点会要求质量和研发来做好，所以要等痛点来了，再几个部门一起来做这个事。

这个是中交兴路一个平台的数据，后台应该是 Jenkins pipeline 。点击进去会直接进入 Sonar 的平台，代码检查能不能通过。

后面是一个看板的说明，你可以选择一个项目，当前的版本，分支的名称等等，我们可以直接在上面提交。

4.4 转换阶段

最后一个阶段就是敏捷的开发转换阶段，刚才那个平台完全是运维部门的开发人员和质量部的开发人员全全合作的，中间讨论了很多的细节，比如说构建号怎么发布，还有一些后台的措施，完全是无缝连接才把这个平台做好的。

转换阶段我们在对解决方案进行部署，或者是运维可以做的监控部署的过程。还有一个就是现在比较热的的SRE工程师的概念，在部署和后续运行的过程中负责监控，在问题出现时排查问题。

五、运维也可以很敏捷

我们再回过头来想，这个就是我们所有IT工作的分类。我们一共分为四大类，救火、变更、IT内部项目，业务项目。

从下往上，救火包括操作事故和操作问题，通常有三种类型的工作导致。IT内部项目就是经常由以上两种类型的工作，在报修系统中被跟踪。然后就是变更。

我们用敏捷的思维方式武装自己，运维团队也可以先敏捷起来，更灵活，更优雅的管理繁杂的事务。