有趣的DevOps,记凤凰项目沙盘演练

社区广播:运维派(Yunweipai.com)是国内最早成立的IT运维社区,欢迎大家投稿,让运维人不再孤寂的成长!

本文转自公众号:曈伴儿

关注公众号的朋友,或许已经看过前几篇翻译的关于DevOps的文章,这段时间我确实一直在通过各种渠道学习DevOps。恰好前段时间去北京,非常幸运地参加了公司组织的凤凰项目的的沙盘演练,近距离地感受DevOps的理念,体会精益文化。

沙盘演练(simulation game),又叫沙盘模拟培训、沙盘推演,源自西方军事上的战争沙盘模拟推演,是通过引领学员进入一个模拟的竞争性行业,由学员分组建立若干模拟公司,围绕形象直观的沙盘教具,实战演练模拟企业的经营管理与市场竞争,感悟经营决策真谛。

凤凰项目沙盘演练是以《凤凰项目》小说为背景进行模拟,通过扮演小说中各种角色,运用DevOps的理念,模拟再现小说中的场景,挽救濒临破产的无极限零部件公司。这是我第一次参加沙盘演练的培训形式,对培训形式本身来说,就像英文名字一样,的确是一场有趣的游戏,但从培训的内容来说,她带来的不仅仅是有趣。参加沙盘差不多也有一个月了,回头看看,总结一下培训的感受是非常有必要的。

感受主要有以下几点:

1、角色职责,正确理解

演练前,每人选择一个角色,有CTO/CISO/Test team/IT Support等,我选择了Test team,虽然已经看过小说,但其实并未真正做过测试工作。演练第一轮开始,大家跃跃欲试,急于提升“公司股价”,却又不知该如何下手,于是围成几堆,在一起叽叽喳喳地讨论不休。作为Test team中的一员,我转转悠悠,这里瞅瞅,那里看看,不知道能做些什么,甚至以为就是在最后检查大家的工作。就从我自身的状态,也可以想见,这一轮并没有完成什么实质性的工作,果不其然,在第一轮游戏结束后,公司的股价急剧下跌。

第一轮中,我范了一个严重的失误,就是没有搞清楚自己的角色职责是什么,存在的价值在哪儿或者说能创造什么价值?实际演练中,伴随着角色名称,还有一张关于角色职责的说明书,而在第一轮中,并没有一个人想要仔细研究一下,每个角色具体的职责要求是什么。公司经营实现利润,整个价值流中每个岗位,每个角色都有其恰当的位置,或许可以缺少某一个人,但却不能缺少这样的职责。举个最简单的例子,公司的总经理可以由不同的人担任,但一个公司却不能没有总经理这个角色。实际工作中,这种情况并不少见,以自己为例,从事一份新的工作之前,很少去了解一下,我所担任的角色存在的价值在哪儿,为什么要有这样一个角色,具体的职责到底是什么。反而会说,“以前就是这样做的”,常常用经验主义来检验实际工作,不能快速地理解并进入角色,延缓了角色岗位带来的价值。

2、利用工具,提升效率

第一轮热热闹闹地结束后,公司不仅没有起色,反而岌岌可危。第二轮开始了,这一轮情况更多,不断爆发出的紧急事件,一个接着一个,形势有点闹人。CEO召集紧急会议,不断提醒利用工具,于是,“大看板”终于请了出来。

看板仅仅是演练中利用的工具,实际工作中还会用到的工具还会更多,有有助于技术实现的,有有助于提升管理效率的,看板就属于后者。与另一个词总是同框出镜的,就是可视化。通过看板,通过任务的可视化,所有人轻松获取目前工作的状态,同时,所有人都盯着同一个看板,能够集中精力做最重要的事。

第二轮过后,发现公司股价虽然还在下跌,但相较于第一轮,下跌的速度已经明显减缓。为什么没有达成事半功倍的效果呢?因为,在管理策略并不清晰的情况下,工具效率提升是很有限的。DevOps并不只是工具。

3、目标导向,价值提升

第二轮之后,利用了看板工具,虽然公司股价下跌的速率明显减慢了很多。但是工作中,太多的紧急情况接踵而至,导致正常工作被打断,所有人都忙着应付紧急情况,疲于奔波,似乎忘了我们的最终目标是要提升公司股价。于是在第三轮,调整策略,将一小部分精力用来挽救哪些紧急情况,另外有一大部分精力用来完成那些最赚钱的工作。

运维工作中,确实有很多紧急情况的出现,运维人员甚至一度都用“消防员”戏称自己每天的工作。这好似一个恶性循环,系统越却弱,问题越多,紧急情况也越多,更加没有时间考虑系统优化的问题,如此往复,运维人员只能充当“消防员”的角色,哪里有火情,第一时间赶赴火场。避免恶性循环的方法之一,就是在问题发生之前能够提前主动修复,修复的问题越多,紧急情况也就越少。“工作四象限”中,也就是把更多的精力放在那些重要但不紧急的事情上,有条不紊,价值才能能到提升。

4、one piece flow

熟悉工厂生产模式的人都知道,编排一个好的生产计划,既要求每一道工序产能利用率达到最大,又要防止产生生产堵塞,所有工作卡在一道生产工序。演练到了第三轮,发现Lean Engineer有大量的工作要处理,确苦于工作时间和精力的限制,无法全部完成,导致有些任务不得不进入等待状态,而无法继续进行。在这里Lean Engineer 就称为整个过程中的“瓶颈”,实际运维工作中,那些技术水平较高的人,会处理更多的问题,积累更多的经验,演变至最后变成只有他们才能处理复杂的情况,而这样的人往往也就1-2个,这时“瓶颈”出现,导致上游工作不得不停止,下游工作不得不等待Lean Engineer完成后才能继续。

工作中,提前考虑“瓶颈”问题,减少制约,通过培训、知识转移,工作流程的标准化等方式,一方面减轻这些“瓶颈”的压力,一方面可以提升团队的整理工作能力。

5、减少转接,提升效率

经过了三轮的演练,到了最后一轮。所有参与的人员,不仅对整个工作流程和方法有了清晰的认识,甚至发现,遇到问题,最有效的就是大家坐在一起沟通交流。有一个著名的效应叫做“沟通漏斗”,就是说, 人与人沟通时,一个人通常只能说出预想的80%,对方听到的最多只能是60%,听懂的却只有40%,执行时,只有20%了。也就是说,一个人所说的80%,对方只能执行到20%。更何况需要层层转述呢?沟通环节越多,沟通效果也就越差。同时,沟通的人员越多,效果也会越差。在保证沟通层次减少的情况下,又要保持小而美的团队,才能对沟通效率的提升大有裨益。

说了那么多,其实也只是我自己的一点感受,那么,凤凰沙盘演练更适合哪些人参与:

首先,凤凰沙盘演练是一次意识的培养,如果一家公司正在或者打算进行DevOps的推进,那么凤凰沙盘演练是一次全员意识提升的好机会。做顾问以来,对于推行一套工作机制,感到难度最大的还是意识的提升,思想的转变,沙盘演练恰好提供了这么一个机会,能够真实地感受DevOps的理念,非常适合于公司组团参与

其次,凤凰沙盘演练是一次普及性的培训,从事IT运维工作的你,如果还没有听过DevOps,你就OUT了,可以通过沙盘演练的形式,生动形象的向你讲述一下DevOps是什么,非常适合于对DevOps一无所知的IT运维人员

最后,凤凰沙盘演练是一次知识总结型培训,就职于互联网公司的你,或许公司正在或多或少地践行一些关于DevOps的理念,却苦于如何提升至理论高度,从而进行DevOps的推广,非常适合于已经有一些DevOps实践经验,但又没有提升至理论高度是IT运维管理人员

网友评论comments

发表评论

电子邮件地址不会被公开。 必填项已用*标注

暂无评论

Copyright © 2012-2017 YUNWEIPAI.COM - 运维派 - 粤ICP备14090526号-3
扫二维码
扫二维码
返回顶部