vlambda博客
学习文章列表

因为疫情原因，困守在香港已经整整2个月了，使本身忙碌的自己彻底的放松下来。我最喜欢的一句话是：你只有不停的奔跑才能停在原地。所以这个长长的假期把很多之前欠下的书籍都读完了，在网上买了一些比较潮流的课程学习，这也使得我每天的生活更加的充实，也更让我去思考实际工作和理论之间的结合；我一直觉得理论固然美好，但也给我们提供了做事的思路，再将这种思路用于指导平日的工作，这就叫“完美”。最近看了很多关于精益看板的书籍，结合运维的工作，我们来聊聊如何将精益看板用于运维工作。

在运维工作中每每提到“看板”，大家想到的都是Dashboard（仪表盘）；对于这两个概念我的简单认识是：

• 仪表盘（Dashboard）– 侧重于技术，关注于技术指标。例如：网络的情况、CPU使用率、设备可用性等等

• 看板（KanbanBoard） - 侧重于管理，关注的是一件事情的生命周期。例如：工作的堆积情况、处理时长等等

对于运维的发展来讲，我认为有三个阶段：

阶段一：组件管理，这种运维管理方法停留在运维早期阶段，往往是主机、网络、数据库哪里出了问题哪里就有运维团队的身影，故障指挥着运维团队，而运维团队也是疲于奔命，哪里有火扑哪里，就像救火队员一样。

阶段二：流程管理，随着组织的运维成熟度的提高，组织会认为很多人为的故障往往都是管理出现了问题，需要加强管理，通过这种方法可以提升IT的价值，减少服务成本；而很多企业的IT部门也会选择ITIL V3等国际最佳实践进行落地；

阶段三：业务管理，这个阶段可以说是IT部门的最高阶段，神州数码有一句非常经典的话：IT服务随需而动！这就是要让IT以业务目标为导向，充分体现IT的价值，当然这也是ITIL 4所宣传的SVS；为业务创造价值。

基于上面三个阶段，你想想你的组织处于哪个阶段呢？我相信大多数的组织基本都处于阶段二，花了N多年时间和金钱建设ITSM体系，做流程、建系统，貌似一起都正轨了，面对故障、变更、服务请求等等都有了相应的流程标准，我们可以通过流程进行完美的甩锅，我们也可以事不关己高高挂起，并且轻松自如的应对年终审计；但是这一切的背后，你有没有听到过这样的声音：

• 服务交付经理：技术、流程、团队管理等等这些活都是我来干，即使我有三头六臂，我也忙不过来，领导每天还在这里催着干各种各样的活，还有各种的突发事件……

• 技术团队A：遇到黑心老板了，让我一个人干三个人的活；天天给我压N多任务

• 技术团队B：面对复杂的流程我已经开始怀疑人生了……

• 领导A：你们的效率怎么这么慢，这点活还干不完？

• 领导B：怎么背着我又干了非法变更的事情？

• … …

在运维团队中出现这些抱怨是再正常不过的事情了，因为运维工作本身身处整个IT生命周期的尾端，再加之业务对IT的依赖性很弱，公司在IT的投入方面并不是很高；最终导致运维团队出现各种各样的问题，我记得当时在神州数码工作时，一位领导说过：问题的出现不是坏事，只有问题暴露了，我们才会知道自己的不足，我们才会想办法去解决，从而持续改进。所以面对以上的问题，我们应该怎么解决呢？

首先，在这里想给大家介绍精益管理中的两个概念：资源效率和流动效率。我们看一下如下这张图：

图中描述的这家医院的医生们工作量都非常的饱和，也就是说资源利用率接近于100%；而这来这家医院看病患者的体验却不是很好，从开始挂号到最终复诊完毕，可能需要几天甚至十几天的时间，也就是说流动效率很低。

一般针对这个问题，给出的解决方案如上图的一站式服务，也就是类似于高端私人医院，里面有专门的导医服务，会带着就诊者无需排队等待直接全流程走完，客户体验极佳，流动效率极高。使用这个例子是为了能直观形象的解释清楚资源利用率和流动效率这两个概念，同时能说清楚为什么我们应该更加关注流动效率，进而引导出限制WIP概念。

反观整个IT运维，也会有资源效率和流程效率：

基于以上两张图，我们可以清晰地看到运维工作的资源效率和流程效率；在平时的运维工作中，我们更加关心的资源效率，每一个资源能够承担多少工作量，往往忽视的是在整个价值链中，我们产生一个价值所用的时间。对于最终的业务部门来讲，TA可能并不关心具体的每位工程师的工作量，而是有没有在最短的时间内把价值进行交付，所以在运维的管理中我们应该关注整个的链条，减少每个环节的等待时间。

注：在这里也会涉及到DevOps中所提及的“单件流”的问题，读者可以自己查询，这里不做过多的陈述。

然后，我们需要一种“光”来照亮这些问题的所在，这就需要将工作完全的可视化出来 – 建立运维看板；

如何使用运维看板：

1.  当每日工作结束时，需要每位团队成员对自己的工作进行更新

2. 每天选定固定时间（我一般比较喜欢早上，头脑清醒），开站立会议，团队从右向左进行遍历，团队以客户价值为导向拉动工作项；如果是分布式团队，需要有远程开会的系统以及电子看板，这个推荐使用TEAMS，TEAMS自带了电子看板。

3. 如遇到一些问题和阻碍项，需要单独提出进行解决。

4. 任务卡片可以包含的内容（也可以基于实际情况增加和减少内容）：

   ²ID号

   ²开始时间和计划完成时间

   ²责任人

   ²任务描述

对于运维看板，需要注意以下几点：

1. 准入项：因为这个看板定位在管理看板，所以我觉得并不是所有涉及到工作量的工作都要放进来，例如：故障或者用时在2小时以内的服务请求就没有必要放入（当然，这需要团队一致决定）；而客户的需求、变更、管理工作这样的事情可以放入

2. 工作项颜色：最好可以用不同的颜色代表不同的含义

3. 完成的定义（DoD）：在运维工作中，也可以在每个泳道的后面设置DoD

4. 在制品（WIP）限制：利特尔法则（见下图）告诉我们，并不是你把工作安排的足够多，产量就是高的，相反，只有在制品的数量越小的时候，平均前置时间才是越小的，才能更快的产生价值。所以只有横向的工作数量小于WIP的数值时，团队才能再次将新工作拉入进来。对于WIP的数值，可以通过尝试来确定，这个数值未必要足够的准确，只是一个大概的数值就可以，因为运维1个工作的工作量比较大；另外1个工作的工作量比较小；所以很难要一个准确的值；除非把工作都拆成同等大小的工作（这样做，对于运维工作的拆分也有难度）。有时管理还是需要艺术一些。

5.  需求的梳理：在看板的第一列是需求池，只要是已经确定要干的工作都可以放在这里，我建议是最好每天或毎几天拉上你的甲方或你的老板一起对需求池里的需求进行优先级的排序，当然客户也可以随时增加新的需求，但是新的需求必须也要进行优先级的排序。

对于运维周报和月报的一些建议：

1、      如果你的组织使用了运维看板，我的建议是可以取消周报，因为每周的情况完全可以通过看板展示出来，对于技术部分，可以单独形成技术周报。

2、      对于管理月报来说，应该关注以下内容：

• 总计完成的任务数量

• 平均LeadTime时间

• Block和问题数量（含解决率）

• 需要对流程的改进和提升点

问静园，北京航空航天大学硕士；近20年的IT工作经验；拥有DevOps Master、CSP、PMI-ACP、SAFe、Scrum@Scale等近50个国际认证；并且是EXIN DevOps Foundation、EXIN Scrum Master、埃及敏捷项目管理沙盘授权讲师。

专注于：企业级敏捷转型咨询、项目管理咨询、IT运维管理咨询、IT精益管理咨询

注：问静园老师文章，请尊重别人的劳动成果，如要转载，麻烦标明出处。