a. 运维是否正确认识敏捷，什么是敏捷？速度快就是敏捷吗 b. 敏捷的介绍，包括敏捷由来，常见敏捷流派和方法，敏捷发展过程 c. 运维人员是否参与到敏捷中的所有环节，包括需求评审、架构设计、研发、测试等 d. 运维人员应该关注哪些环节、重视哪些环节

在许多工作场景中运维经常遇到的很多问题实际上和研发、质量、测试是有关联的，运维作为产品交付的最后环节遇到的很多问题其实和研发遇到的也非常类似。于是我向廖君仪老师询问能不能把敏捷看板带到运维团队内部，使用敏捷的方法来解决这些问题。

接下来我们会从上到下跟大家分享以下五部分：运维面临的挑战，敏捷开发方法，还有我们的运维看板，以及敏捷软件生命周期，最后是我们的结论：运维也可以敏捷。我们希望通过这次分享向大家交付两个内容，第一点，理解敏捷是什么，第二点大家回去后能尝试进行看板实践。

运维的挑战

运维到底能在DevOps里面做什么？这其实是在解决DevOps在运维部门如何落地的问题，也是在解决怎么横向在部门之间扩散的问题，作为一个质量部的负责人和作为运维部门的负责人，相互之间怎么合作，怎么做这个事情？

先来看看运维的发展方向

大家都知道运维的发展要经过这么几个阶段，标准化、流程化、自动化。但是这样分类太过于局限性。因为我们很多公司的运维部门在很多时候都会面临一个问题，就是我没有达到最终自动化之前，那我该如何更优雅的过渡呢？

在我们看来这其实是一个复利的问题。

我在运维工作中会遇到紧急的问题和重要的问题，这就考验我们如何高效处理紧急问题。因为只有更高效的解决掉紧急问题，才能腾出更多的时间精力来解决重要问题。比如运维部门持续不断的减少紧急任务的处理时间，持续不断的优化工具，比如跟质量部门一起在公司把整个产品交付做得更好，这就是我们运维在DevOps里面的定位。

那我们看一下运维走向终极目标前会遇到哪些问题

第一个，常见的任务反馈不及时，导致呈现出来“效率不高”。

第二个，紧急任务繁多，严重挤压到重要任务完成进度。基本上运维整年都是一样，一年到头发现我们部门没有什么变化。

第三个，虽然很忙，但是无法改变平行部门的评价“效率不高”。到年底的时候，各个部门的领导都非常揪心，因为平行部门经常会评论“运维部门效率高不高，我只能给你打很低，因为好多时候你反馈非常慢。”

第四个，任务被严重挤压，而且没有办法量化，化解。

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

第六个，运维人员的个体能力、经验差异、经常会偷偷的给团队带来风险。风险难控制。我们团队里面都存在一些英雄，我们非常崇拜一些英雄，经常在关键时刻帮我们团队化解危机，但是往往当我们对英雄依赖变得很强的时候，英雄一旦离职，可能这个部门某一段时间就会遭受很大的打击。

Ok，带着这些问题我们看看是否只有运维团队遇到这些问题，是否其他部门也遇到过，他们是怎么解决的呢？

实际上在这个图里面，对比运维交付跟产品交付，虽然呈现出来阶段是不同的，但是我们仔细想里面隐藏的关联和矛盾性，产品交付和运维交付里面都是存在的。而产品交付过程中敏捷起到至关重要的作用，那敏捷是否可以同样解决运维的问题呢？我们先了解一下什么是敏捷。

大家看到敏捷这个词的时候，首先会想到什么？大部分的人可能想到提高效率，通过很快的发布，还有降低成本，提高质量这些，但是我要说的是，这些东西其实都是我们目前看到的，这个只是敏捷可能带来带来的一些结果。

但是敏捷到底是什么意思？敏捷最开始的解释是”flexibility灵活性”的意思，发展到现在业界对于敏捷的公认解释是:是灵活而优雅。

敏捷的流派

开始认识敏捷的时候，我们会面临很多的敏捷的流派，比如说精益、敏捷与Scrum、看板还有XP。

我们看到上面外围的图片左边是一些精益思想屋，右边是敏捷宣言，外围的来看其实是一个思想和文化层面，就是在我们组织里做精益做敏捷都是有一些文化和价值观的东西在里面，里面我们可能看的比较多的就是Scrum，看板和XP的方法论。

Scrum是业界最流行的一种敏捷项目管理的框架，包括了一些敏捷的实践。敏捷的流行，Scrum功不可没，在最开始的时候，Scrum的一些实践和做法可以让团队很迅速的照搬一套初具样子的方法和实践。

Kanban 方法是近几年上升最快的敏捷方法之一，Kanban最早起源于丰田生产方式，所以它和精益的关系很紧密。 2004年Daid Anderson的小蓝书出现，是Kanban方法从制造业到软件业应用的一个转折点。

XP是90年代末最早出现的，最初是由13个工程实践组成的，也最受程序员的欢迎。后面我们会展开来讲一下敏捷最普遍的使用的三个方法论。

敏捷宣言

敏捷宣言可能大家都听说过，我可以讲一些历史，比如说2001年敏捷这个词怎么来的，是上世纪九十年代到这个世纪初的时候，在欧美有很多的软件方法学的流派出现，是对抗传统的大型软件开发的流程，出现的各种方法，比如特征驱动开发，水晶方法族，自适应软件开发，但是他们这些流派也是互相都有各自的特色，没有办法说服别人，怎么办？

在2001年的时候，这些大牛大概一共有17位大师凑到美国的盐湖城的一个叫SnowBird的滑雪场，做了两天的封闭式讨论，最后达成了一个敏捷宣言，其实方法论上也没有说服对方什么，你会发现现在还有很多敏捷的流派在这里存在，但是他们达成了一个共同的宣言，这个就是大家看到的这个敏捷宣言，个体的交互重于过程和工具，可工作的软件重于面面俱到的文档，客户合作重于合同谈判，响应变化重于遵循计划。

敏捷宣言发展到现在，其实有一点点的误解，就是一定要说的，我们强调的是左向的价值，虽然右向也具有价值，但是左向具有很大的价值，我发现现在很多的团队刚接触敏捷有一个误解，认为右边完全没有价值，其实不是的，做敏捷过程和方法的，从来没有说我们不需要过程和工具，不需要文档和计划。敏捷从来没有说这个。

精益思想

精益思想其实是比较复杂的，也有好几本书，最开始是从丰田生产方式起源的，我们用一个故事大家可能更容易明白，上世纪五六十年代丰田汽车想打入美国市场的时候，他遇到很强劲的对手是通用汽车，通用在美国是一个大规模生产的代表，大概是一个流水线生产几十万台车，推向市场，丰田用什么方式最后打败通用汽车的？

一开始丰田也是用了一些广撒网的方式做一些市场调研和设计，但是区别是当一个设计出现的时候，他并不是把自己的设计和产品大规模的推向市场，而是他用了一些小规模换模的技术，在同一个生产线上可以一次只生产几十台的汽车，在这种小规模的小批量生产上，他会很快的试错，以及当车销量不好可以及时的停止生产方面的浪费，那么如果销量好，就会持续扩大生产以达到一定规模生产。

最后用这种小批量的用市场反馈来指导生产方式远远超过了大规模生产的通用汽车，背后的原理是什么？具体的制造业的做法，我们不是需要太关注的，从制造业到软件业，我们更关注的是精益思想。精益思想的五个原则，我这边简单介绍下，有兴趣《精益思想》这本书大家可以看一下。

原则一：价值

首先要重新定义一个组织的价值，这个价值是去识别给客户带来的价值，从而去指导这个价值所需要的工序。

原则二：价值流

其次，根据工序的画一个价值流图导向，只要跟这个新定义的价值没有关系的生产，都把它称为浪费。

原则三：流动

第三点，我们根据建立起来的价值流图的指导让工序的流动速度越来越快。

原则四：拉动

整个的生产方式是拉动的，并不是推动的。推动的意思就是我要生产什么东西，我设计生产开发测试到发布，这个是从前往后的推动的过程，拉动的过程就是客户需要一个什么零件，他直接到一个汽车零件的代理商那里去要一个零件，这个代理商会到丰田的工厂里去提交一个需求订单，倒过来去推我需要交付这样一个零件，那么我应该怎样做设计，怎样做生产，开发测试和发布。这样从后往前去走拉动的过程。

原则五：尽善尽美

追求善美，从定义价值到拉动的生产，这四个原则我们不停的循环，通过不停循环的过程达到组织流程不断的完善以及追求尽善尽美的目的，组成了这个第五个原则，这个是有一点抽象的。精益思想的价值远大过于丰田的生产方式和丰田管理的具体做法，特别在软件业里面能用的地方要多的多，比如现在的精益产品设计，精益创业，和精益企业的一些方法。

Scrum

Scrum应该算是相对比较简单的一个部分，Scrum是一个项目管理框架，纯Scrum的方法目前创业团队还有之前所在的外企用的比较多，核心重点有一个时间盒的概念，在一个时间盒范围内，比如两周会发起一次冲刺。

在两周这个过程中会交付一些潜在的可交付的产品增量。在这两周的冲刺中，会有一些项目管理的实践。开始就是建立一些计划会议，就是迭代的计划，在这个过程会有每日站会，两周快结束会有一个演示会议。

最后团队坐在一起做回顾，大家看一下Scrum框架本身还是对于启动来说是比较简单的，也是为什么在最开始的时候敏捷能够迅速风靡全球，Scrum起到一个很重要的作用，因为他开始起来很简单。

Kanban

Kanban看板是今年来上升最快的一些敏捷实践方法，04年David Anderson出版的《看板方法》这本小蓝书把整个精益看板方法，从制造业第一次带到软件业做最全面的阐述开始的，近两三年看板方法非常热。

看板方法相对来说出来会晚一点，因为开始看板的方法是从制造业过来的，大家可以看到我们平时在白板写一些队列和泳道，上面的数字叫WIP下面有一个紧急的通道，红色的卡片这块，还有一个很重要的方法，就是流动。

刚才体现的怎么加快流动，当然看板方法并不是等于大家看到的看板墙，看板墙只是一个白板，而看板方法反映的一系列的方法，看板方法是通过这面墙改进流动。

XP

XP时间也很久了，是从上世纪九十年代开始的，是带有一些敏捷工程实践比较多的一些实践在里面

XP研发出身的人了解多一些，它是上世纪九十年代出现的比较早的开发实践，包括一些持续集成，结对编程，重构，代码集体所有等等。这些工程实践是现代软件工程的很重要的贡献。包括我们现在很热的持续交付，DEVOPS，离不开XP的铺垫。

敏捷开发方法选型 方法对比

我们给大家讲一下各种敏捷开发的对比，Scrum看有9种实践，XP有13种实践，而看板只有3种实践，我自己其实对于哪一个流派的优劣没有特别大的偏见，因为这是组织适应的问题。但通过对比我们还是能看出，看板在实践数量上要求要更少，所以适应性更强。

情景分析

我们公司（中交兴路）是做货运车联网的，我们有全国最大的货运定位平台，搭载460万的车，还有跟中石化合作发行柴油联名卡的项目，我进入这个公司，自己也是从外企完全做Scrum出身的，过来以后我就发现，我到这个公司做敏捷转型，如果只走Scrum可能走不通，因为有很多各方面的问题。那个时候刚开始看小蓝书，就想到了从看板方法开始。

选择看板方法

看板有什么好处？是可以带来一个渐进式变革的开始，但是现在我们大概有七八个团队都在用敏捷的看板，甚至有业务比较新的团队在用Scrum都用的不错，我们是听起来有点像国企的上市公司子公司。用看板转变是很好的办法，改变一点点，慢慢的开始，而不是一开始就上来一堆名词，PO,Scrum master，这些。

看板是一个非常好的启动变革的方式。当然其实你在接触多一些的敏捷的方法的时候，你会发现你看板走得好，你走到后面会越来越像Scrum。

看板方法-三大核心实践

第一步，是可视化工作流，有一个好处，你不用预设任何的流程，你就把你现在所在的组织开发的流程直接搬到板上，第一步就是可视化就可以了。

第二步，在制品（WIP）限制我们通过一些手段，比如说在制品的个数的控制，从上一个阶段到下一个阶段流转的规则，去调整整个看板的设计或者是给开发团队制定原则。

第三步，是整个团队的流动的速度的提高，以渐进的方法进行度量和管理这个流动，这是三大实践，后续我们会把这三大实践在我们的运维看板例子里详细的讲。

看板实践案例

先讲一下我们其他团队的看板，再进入到运维看板实践过程中，当然我也是属于何勉老师的忠实粉丝，所以我们公司的大部分看板的实践都结合了何老师的微信公众号的一些内容。

案例一、物理看板

这个看板是我们一个APP叫“车旺大卡”平台的看板，目前有一百多万卡车司机在用这个平台，看板上开发测试到完成的工作，这边都可以看到，有意思的是刚才说我们有一个待开发，这是缓冲区等待区的概念，我们在待开发的这些需求的过程，到开发的过程中，我们会把需求拆分成任务，拆分了以后我们测试环节又会合并，这样体现开发和合并的过程，左下角可能还会有一些废弃区，右下角是何老师的每日站会“非常6+1”实践的提示。

案例二、电子看板

第二个是我们一个纯创业的团队，现在可能多了一个人，之前是六个人，这是我们定制的一个纯Scrum的看板，因为他们是创业团队，所以没有什么其他的旧的流程，完全是重新做，大家基本上接近Scrum。一开始在公司里当然有很多的物理看板在这里运行，目前电子看板的采用也越来越多。

我们的运维看板实践 问题一：常见的任务反馈不及时，导致呈现出来“效率不高”

首先我有一个故事场景给大家分享一下：

有一次领导跟下属在聊天，当时听到聊的挺好，后来领导话锋一转“上次跟你说关于服务器优化的事情有没有进展？”接下来的画面是：同事跟领导五秒钟的对视，说“那个事儿不就说一说，还要做吗？”…… 这种场景我觉得应该不罕见吧。

领导的想法太多，变化太快，下面的人跟不上，所以你不确定。任务的不确定因素太多，不是说领导变化太快，别尝试跟上，因为如果能跟得上，那你肯定就是领导了。

改进方法：

我们如何解决这个问题呢？这个时候我们需要一个看板，具备可视化。我们可以把领导跟我分配的内容记录下来，筛选一下，哪些是真的要做，然后贴在看板上。

看板上的任务卡写上达到什么目标，再跟领导确认实施时间。然后放到BackLog里面，领导就会知道你这个东西有没有做，有许多把我想的事儿放到看板上。如果领导改变主意了，那自然也可以再最短的时间内被取消掉。同时在每日站会进行确定和跟踪，这是看板第一点。

问题二、紧急任务繁多，严重挤压到重要任务完成进度。

这里也有一个场景跟大家分享：我们有集群，大家都知道集群里有一台服务器如果宕机，影响服务稳定性之后。作为运维第一个解决问题的原则是什么？原则就是先将故障的设备剔除出集群，并恢复服务，然后再找去问题。

但是集群中有问题的这个机器被剔除之后，由于原因比较隐晦，而且当时事情又比较多，接近一个月这个问题也没有找到。直到有一天一个同事说：“我今天在集群找到一个机器没有人用，太开心了，我们现在有一个项目没有资源部署，我现在捡到空闲的设备，刚好可以放进去化解一下资源紧张的问题”。

其实他不知道已经把一个地雷放到了另外一个集群内部。这就是问题没有解决，没有结论，没有跟进，没有持续反馈的结果，问题没有得到重视。还有就是一个任务的跟进太依赖于人。领导事情一多，这个事情基本上会拖，下属积极性弱一点，或者事情一多，这个事情同样会被拖，所以很糟糕。

改进方法：

这是我们目前在用的，我们会把我们所有的运维要做的一些事情放到看板上，看板又分几个类型：有虚拟化和持续交付、监控、自动化、安全、还有项目运维工具化，纵向也分几个区域。

以刚才场景为例子，我们就需要一开始将服务器的问题贴上去在BackLog中，并且会在每一天反馈，推进这个问题的同时进行跟进。同时在任务过期后我们需要怎么做呢？

这个时候会调整优先级，如果我发现问题一直没有人解决，会分给A同学，比如A同学手里已经有其他事情，这个时候就体现看板的价值了。我会把任务分给别的同学，这个时候内部资源能够得到调整，同时在看板上就可以体现出来。

问题三、虽然很忙，但是无法改变平行部门的评价“效率不高”。

作为支撑服务部门，由于没有管控工具，其他的团队提给运维部门的需求事件是容易产生积压的。而我们需要通过看板将其他团队的需要在板上体现出来，让他们很容易知道自己的需求到什么阶段，做到更快的反馈机制和方法。

而且有了看板以后很容易发现一些问题：有一些任务项长时间停留在doing里面，这就是所谓的堵塞。

比如我们一个安全部门说这次要做一个安全的实施。听起来很简单，但是任务卡滞留将近两周。原因是这个任务依赖于另外一个任务。而另一个任务的执行者是其他人。

改进方法：

当我们在追溯原因的时候才知道，执行者按照看板的理论中，他会自己选择更紧急的任务执行。这其实就是另外一个看板的原则：我们看板每天开会的时候不仅仅要描述我昨天做什么今天做什么，还要找出重点风险和阻碍的任务。

如果我这个任务卡被另外一个任务卡住了，那个就是阻碍，我要及时的提出来，这个时候我们应该及时的调整优先级，这样能够让任务的前置时间很短，能尽快进入到自己的过程。同时我们会增加WIP（Work In Process）的记录，也就是我们部门每一个运维人员手里不要超过三个事儿，因为要保持运维人员的聚焦。

因为系统工程师都知道上下的切换对机器来说是消耗比较小，但是对人来说是非常可怕的。如果你手里有超过三个事儿，基本上工作效率下降非常高。所以我们每个人手里三个事儿，如果超过三个事儿，我会尽量不让其他事情流到同事的手里。

看板帮我们目光聚焦在控制在制品上，其实控制在制品的概念就是我们理解部门在并行需求处理极限值，需要我们关注并行处理的合理值，在成员处理的效率和并行处理数量中找到平衡点，并不断的优化。保持任务项流动的更快。

这也是通过看板进行一个变革，一个改善流程工序，加快流动的最核心的基点所在。所谓短板效应，木桶的容量不取决于最长的那个木板，而且取决于最短的那个木板。看板最大的优势就是帮助你从系统层面用可视化的方法发现瓶颈并尽快的解决，以达到系统整个加速流动的目的。

问题四、任务严重挤压，但是没有办法量化、化解

有一次我们看到看板上有两个任务卡，一个是“自动化平台运维2.0的开发”，一个是“货运平台某台服务器修改ssh参数”，同样是两个任务卡，但是里面存在的风险和周期差异非常大。

任何一个任务卡蕴含太长的执行周期是不合理的，因为就像一个河流在运输木桩场景一样，木桩越长，运输过程越容易被卡住，容易造成很多的风险产生。

改进方法：

我们需要把长木桩截成多段。也就是我看到任务卡不合理时，需要截断。类似“自动化运维平台2.0开发”，需要截成多个任务，变成功能一、功能二、功能三、功能四，每一个功能我只给不大于两周的时间，我可以保证每一个任务卡可量化，风险可控。避免两个月以后再进行判断任务的执行情况。

一旦任务卡的流转速度变快，团队每个人都会比较有信心，“今天完成了三个，完成了两个，完成了五个”，大家都会觉得很棒，会有很强的成就感，因为任务能量化，而且大家都看得见。

问题五、运维人员的个体能力、经验差异、经常会偷偷的给团队带来风险

有一些运维部门负责人可能会有比较深的感悟，年底写总结的时候，需要对年初做的计划进行回顾，结果经常是十个任务里好像只有五个完成了。同时今年完成的另外五个任务是年初没有定的。这周情况并不罕见，运维看板能否解决这个问题呢？

改进方法：

你看我们这个图，也是我们现在的看板。最右面会把我们这半年要做的任务打成纸制，作为参考和校对。每一次新增任务卡的时候，都会关注一下这个事情跟我前年定的大计划任务是不是一致，如果是一致的，我们当成重要任务，并且放比较大的精力，能保证短期目标和长期目标的一致性。如果不是我们会保证质量的同时加快速度完成。

其次，红色标注显示九分之三或者九分之一，这个主要是体现了产能分配的问题。我们加入看板一共有九个人，代表这一阶段负责这一块任务有多少个人，这样大家心里就有数了，而且脑袋里很清晰，知道我们大约多少人做这个事儿，大约知道今年有空闲时间应该把精力放在什么地方。

同时会体现WIP的现状，也就是罗列出来，九个人一个人手里有三个事儿。

讲到这里，如果你把这五个点理解了以后，我觉得回去做一个运维的看板一点问题没有，我们现状玩得很嗨。因为我们在运维内部解决问题的时候，跳出来站到更高的高度看，运维跟敏捷的生命周期关系是什么？

软件开发生命周期：越来越协作化

颖维刚开始找我策划这个话题的时候，我对运维在敏捷能做什么还是有一点模糊，但是后面我翻阅了很多的资料，跟行业的朋友交流，其实运维同事可能更关心这块，就是在软件开发生命周期里，运维这个职业向什么方面发展，在软件开发生命周期能做什么事情。

看一下从传统到敏捷DevOps这块的生命周期整个最大的变化在哪，左侧图我们看到从设计开发测试部署管理评估这些，DevOps最开始都是各个一波人在做一系独立的事情，Dev做Dev的事情，Ops做Ops的事情。

后面你会发现最大的变化不是运维方面的变化，其实是把业务加进来了，就是在整个研发过程产品是越来越重要的，现在是产品为王的时代。当然整个研发生命周期里，产品，开发和运维都是紧密的联系在一起，就是说可以看到一个很明显的特征，现在软件开发的过程提倡的是越来越协作化，每一个环节都有不同的团队在合作。

敏捷交付的三阶段

敏捷交付的阶段划分方法有很多种，这个只是其中的一种，不代表全部。我们只是用这种划分作为例子来讲，在这个敏捷交付三阶段里，运维大致是能做什么工作。我先大概的介绍一下敏捷交付的三阶段。

开始的阶段，可能在大型一点的软件组织里，可能会有一些初步的建模，比如领域建模，还有一些高级的排序，比如说业务哪些是重点，哪些是相对重点发布的计划，现在新一点的是用用户故事地图这种简单一点的方法，也是用各种卡片，就可以简单的一些业务排序做完了。

构造阶段，我们是Scrum，或者极限编程，精益生产和Kanban，还有开发解决方案在构造阶段。

软件部署和交付的阶段，我们称之为转换阶段交付出去了，就是一些部署的解决方案和交付以后一些最后的监控等等属于软件的转换的阶段。

开始阶段运维能做的

在开始的阶段，我们认为从DevOps的角度中我们运维可以做什么？我们从需求的角度其实是应该把运维作为首要干系人，可以在需求的过程，比如提出日志监控的需求和服务级别协议的规格和容量的规划，业务连续性的服务和策略还有信息安全，我觉得这个是稍微大型一点的组织，都是需要考虑这些方面的，除非你是非常纯创业的小型APP创业团队，从工程的角度发布计划其实应该比较严谨一点，可以包括发布调度和运维的配合还有运维人员可能需要做哪些培训。

构造阶段运维能做的

构造阶段，大家可以看到图很眼熟，这个图讲了一个比较理想的状态，大家可以看到代码提交到编译到单元测试分析，测试员可能会自动化一键部署测试环境，到验收测试的阶段，到运维人员可能去一键部署，中间会有容量测试，但是容量测试也是由运维还有开发还有性能测试人员一起来做这块的，最后是到一个部署和生产环境，那下面可能有一个总体的制品仓库在支撑这块的工作。

前面的图其实是描绘了比较理想的最终的目标的状态，我们部门跟运维部门其实也是正在合作开发DevOps的平台，我们从开发环境开始，到提交测试，其中从集成环境，代码质量检查，单元测试覆盖率，还有安全扫描，到最后一个预发布和发布环境，这块运维在里面也做了很多的工作，比如说是环境的管理，应用部署，容量的规划和管理，都是由运维团队配合我们的。

我们现在看到很多的公司，他可能都是用一些开源的框架来做这个流水线，由需要部署的人员直接实施。

但是我们公司里不一样，我们当时做了一个切割点，就在服务环境提供里，因为只有运维能接触到环境，因为我们本身有一个原有的运维和部署的系统，我们这边会区分，也就是运维负责怎么把包放到线上，怎么做容量管理。

而这个Devops的前面部分原来完全由质量部门做，怎么样持续集成，持续的打包，由他们来做，所以我们两个部门协同起来，把所有的模块合在一块，形成一个平台。重要的就是打破部门墙建设一个DevOps的平台。

对于测试这块，比如说我们也会加入一些自动化测试，冒烟测试，以及一些性能测试的东西，像现在的探索性测试还是手工为主，安全测试反而是运维来加入，因为我们安全测试属于运维部门做。运维在开发DevOps平台过程中，其实也是可以发挥一个很大的作用，特别是环境管理这块。

转换阶段

最后转换阶段肯定是已经转换到完全运维为主体的阶段，比如我们在软件部署完以后或者发布以后，我们需要为解决方案进行一个监控，确定一下是否需要回滚或者什么时候回滚，以及容量管理，还有调整这块，当然现在比较热的就是SRE工程师，在部署和后续负责监控和问题出现的时候进行排查。

现代运维工作分类

另外：

总结

运维与DevOps的整个过程这块等于把整个我们部署完以后运维怎么介入，以及运维在三个阶段里运维应该起到什么样的后续角色都描述进去了，其实就是SRE，还有解决部署的事情。

我觉得张乐刚才讲的刚好给我们这个主题做了很多铺垫，所以刚才有同学提到的那个问题，我们讲的就是解决T字的一横的问题，定义我们运维部门和其他部门之间的关系，以及工作的情况。

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

END