运维助力敏捷交付-我们的运维看板
2019-12-30
来源： 高效运维 许颖维&廖君怡
要做，然后贴在看板上。
看板上的任务卡写上达到什么目标，再跟领导确认实施时间。然后放到BackLog里面，领导就会知道你这个东西有没有做，有许多把我想的事儿放到看板上。如果领导改变主意了，那自然也可以再最短的时间内被取消掉。同时在每日站会进行确定和跟踪，这是看板第一点。
问题二、紧急任务繁多，严重挤压到重要任务完成进度。
这里也有一个场景跟大家分享：我们有集群，大家都知道集群里有一台服务器如果宕机，影响服务稳定性之后。作为运维第一个解决问题的原则是什么？原则就是先将故障的设备剔除出集群，并恢复服务，然后再找去问题。
但是集群中有问题的这个机器被剔除之后，由于原因比较隐晦，而且当时事情又比较多，接近一个月这个问题也没有找到。直到有一天一个同事说：“我今天在集群找到一个机器没有人用，太开心了，我们现在有一个项目没有资源部署，我现在捡到空闲的设备，刚好可以放进去化解一下资源紧张的问题”。
其实他不知道已经把一个地雷放到了另外一个集群内部。这就是问题没有解决，没有结论，没有跟进，没有持续反馈的结果，问题没有得到重视。还有就是一个任务的跟进太依赖于人。领导事情一多，这个事情基本上会拖，下属积极性弱一点，或者事情一多，这个事情同样会被拖，所以很糟糕。
改进方法：
这是我们目前在用的，我们会把我们所有的运维要做的一些事情放到看板上，看板又分几个类型：有虚拟化和持续交付、监控、自动化、安全、还有项目运维工具化，纵向也分几个区域。
以刚才场景为例子，我们就需要一开始将服务器的问题贴上去在BackLog中，并且会在每一天反馈，推进这个问题的同时进行跟进。同时在任务过期后我们需要怎么做呢？
这个时候会调整优先级，如果我发现问题一直没有人解决，会分给A同学，比如A同学手里已经有其他事情，这个时候就体现看板的价值了。我会把任务分给别的同学，这个时候内部资源能够得到调整，同时在看板上就可以体现出来。
问题三、虽然很忙，但是无法改变平行部门的评价“效率不高”。
作为支撑服务部门，由于没有管控工具，其他的团队提给运维部门的需求事件是容易产生积压的。而我们需要通过看板将其他团队的需要在板上体现出来，让他们很容易知道自己的需求到什么阶段，做到更快的反馈机制和方法。
而且有了看板以后很容易发现一些问题：有一些任务项长时间停留在doing里面，这就是所谓的堵塞。
比如我们一个安全部门说这次要做一个安全的实施。听起来很简单，但是任务卡滞留将近两周。原因是这个任务依赖于另外一个任务。而另一个任务的执行者是其他人。
改进方法：
当我们在追溯原因的时候才知道，执行者按照看板的理论中，他会自己选择更紧急的任务执行。这其实就是另外一个看板的原则：我们看板每天开会的时候不仅仅要描述我昨天做什么今天做什么，还要找出重点风险和阻碍的任务。
如果我这个任务卡被另外一个任务卡住了，那个就是阻碍，我要及时的提出来，这个时候我们应该及时的调整优先级，这样能够让任务的前置时间很短，能尽快进入到自己的过程。同时我们会增加WIP（Work In Process）的记录，也就是我们部门每一个运维人员手里不要超过三个事儿，因为要保持运维人员的聚焦。
因为系统工程师都知道上下的切换对机器来说是消耗比较小，但是对人来说是非常可怕的。如果你手里有
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
