运维助力敏捷交付-我们的运维看板
2019-12-30
来源： 高效运维 许颖维&廖君怡
导言：
在许多工作场景中运维经常遇到的很多问题实际上和研发、质量、测试是有关联的，运维作为产品交付的最后环节遇到的很多问题其实和研发遇到的也非常类似。于是我向廖君仪老师询问能不能把敏捷看板带到运维团队内部，使用敏捷的方法来解决这些问题。
接下来我们会从上到下跟大家分享以下五部分：运维面临的挑战，敏捷开发方法，还有我们的运维看板，以及敏捷软件生命周期，最后是我们的结论：运维也可以敏捷。我们希望通过这次分享向大家交付两个内容，第一点，理解敏捷是什么，第二点大家回去后能尝试进行看板实践。
运维的挑战
运维到底能在DevOps里面做什么？这其实是在解决DevOps在运维部门如何落地的问题，也是在解决怎么横向在部门之间扩散的问题，作为一个质量部的负责人和作为运维部门的负责人，相互之间怎么合作，怎么做这个事情？
先来看看运维的发展方向
大家都知道运维的发展要经过这么几个阶段，标准化、流程化、自动化。但是这样分类太过于局限性。因为我们很多公司的运维部门在很多时候都会面临一个问题，就是我没有达到最终自动化之前，那我该如何更优雅的过渡呢？
在我们看来这其实是一个复利的问题。
我在运维工作中会遇到紧急的问题和重要的问题，这就考验我们如何高效处理紧急问题。因为只有更高效的解决掉紧急问题，才能腾出更多的时间精力来解决重要问题。比如运维部门持续不断的减少紧急任务的处理时间，持续不断的优化工具，比如跟质量部门一起在公司把整个产品交付做得更好，这就是我们运维在DevOps里面的定位。
那我们看一下运维走向终极目标前会遇到哪些问题
第一个，常见的任务反馈不及时，导致呈现出来“效率不高”。
第二个，紧急任务繁多，严重挤压到重要任务完成进度。基本上运维整年都是一样，一年到头发现我们部门没有什么变化。
第三个，虽然很忙，但是无法改变平行部门的评价“效率不高”。到年底的时候，各个部门的领导都非常揪心，因为平行部门经常会评论“运维部门效率高不高，我只能给你打很低，因为好多时候你反馈非常慢。”
第四个，任务被严重挤压，而且没有办法量化，化解。
第五个，任务的风险经常被“侥幸心理”带进项目里。
第六个，运维人员的个体能力、经验差异、经常会偷偷的给团队带来风险。风险难控制。我们团队里面都存在一些英雄，我们非常崇拜一些英雄，经常在关键时刻帮我们团队化解危机，但是往往当我们对英雄依赖变得很强的时候，英雄一旦离职，可能这个部门某一段时间就会遭受很大的打击。
Ok，带着这些问题我们看看是否只有运维团队遇到这些问题，是否其他部门也遇到过，他们是怎么解决的呢？
实际上在这个图里面，对比运维交付跟产品交付，虽然呈现出来阶段是不同的，但是我们仔细想里面隐藏的关联和矛盾性，产品交付和运维交付里面都是存在的。而产品交付过程中敏捷起到至关重要的作用，那敏捷是否可以同样解决运维的问题呢？我们先了解一下什么是敏捷。
大家看到敏捷这个词的时候，首先会想到什么？大部分的人可能想到提高效率，通过很快的发布，还有降低成本，提高质量这些，但是我要说的是，这些东西其实都是我们目前看到的，这个只是敏捷可能带来带来的一些结果。
但是敏捷到底是什么意思？敏捷最开始的解释是”flexibility灵活性”的意思，发展到现在业界对于敏捷
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
