打破甩锅文化,开发与运维如何实现高效协作

发表时间: 2019-11-14 17:10

1. 我升职了,但我不开心

我叫 Bill,是一家公司的运维经理。上周我的顶头上司跑路了,我临危受命,被老板钦点升(jie) 职 (pan)。事实上我并不想升职,上周 HR 找到我,异常热情地告诉我这个“好”消息。我当时很纳闷,于是问她:“没听说我上司提过要走啊,他为啥走了?”她说:“当然是有更高的追求了,你想知道可以去问他!”

俗话说得好,如果你同事主动告诉你要离职,那多半是自愿的。但是如果其他人告诉你的,那他们一定是被迫的。看来我上司被炒了。我很抵触,因为我只想带着我的团队做好事情,我可不想像其他经理一样,每天只知道互甩 PPT。

2. 无休止的甩锅何时停止

早上 8:00,我一边喝着咖啡一边打开笔记本电脑,我想在 9 点开会前处理好电子邮件。在过去的 24 个小时里,我已经收到了 526 封新邮件外加 300 多条语音消息。

一眨眼九点了,我快步走到会议室,老板正在部署财政预算。我强装欢笑,因为手机已经在裤兜里震了一会儿了,我知道大事不妙。于是掏出手机,瞬间五雷轰顶:“1 级严重级别事故:信用卡处理系统故障。所有门店都受到影响。”

屁股还没坐热,我夹着笔记本就冲到网络运营中心,我们部门的 IT 服务支持部总监小王正在调整电话。“咳咳,Bill 来了。目前进度是订单输入系统无法使用,现在发布了一个 1 级严重级别的事故。正在设法查证开展过哪些变更。”

他顿了一下,看着我:“话说,我可不敢肯定我们真能搞清楚。”

我说:“大家想想,今天实施的所有变更当中,哪些可能会导致这个服务中断?”

最怕空气突然安静,一阵沉默不语,左顾右盼。

我刚想说话,一个声音打断我:“我是负责人小张。我之前跟小王沟通过,现在再跟你说一遍,我手下的开发人员全部没做过任何变更。你赶紧把我们从你的黑名单上划掉。谁知道故障是不是某个数据库变更引发的。”

另一个老哥忍不住了,愤怒地说:“啥?我们可什么都没改,至少......没改过任何可能影响订单输入系统的东西。你确定不是操作系统补丁又出问题了?”

紧接着,一个人气呼呼地说:“怎么可能!我可三周没更新这些系统了。要不是网络变更引起的,我把头砍下来给你坐。他们每次变更总是惹麻烦。”

这时,网络维护主管,委屈地说:“凭什么每次服务中断,总是网络维护组受到指责,这不公平!你把话说清楚。”

“那你倒是证明给我看啊。”数据库经理挑衅地说。

网络维护主管拔高了声音:“简直胡说八道!我没做过的事情,你要我怎么证明?说不定是防火墙,上周中断就是他们造成的。谁的锅谁背,别扣我这里来。”

小王很愤怒,他对我说:“小李的团队没人来参加这个电话会议。所有防火墙变更都是他的团队在处理的。看来要想办法联系他才行。”

这时有个声音说:“emmm......现在谁能试一下?”大家停止了争论,在键盘上打着字,他们正尝试进入订单输入系统。

“等一下!刚才是谁在说话?”一阵尴尬的沉默。

“是我,大步。”

大步是分布式运维部门的,我忍住火气说:“你下次在行动之前是不是要先通告大家一下。我们最不愿意做的事,就是让情况变得更糟糕,让原因变得更复杂。”

话还没说完,一个人打断我:“嘿,系统重新启动了。干得好!大步。”

我沮丧地抿紧嘴唇。我想我要做点什么了。

3. 变更可视化

这次的突发情况就是由变更引起的。我约了小王和小李(分布式技术运维总监)来聊聊如何解决。

“针对 1 级别的严重事故,我们怎么能只凭感觉做事,小王,作为 1 级事故的处理负责人,从现在起我要你弄清楚相关事件,尤其是相关变更的时间线。”

小王疲惫地说:“那我会写好流程文档,并且尽早实施这个流程。”

“这还不够,”我说道,“我要你每两周就组织一次排查故障的实战演练。需要让每个人都养成运用合理方式来解决问题的习惯。在召开应急处理会议之前,是不是要先把时间线搞清楚。如果不能在预演中做到这点,那又怎么指望我们在紧急情况下这么做呢?”

然后我转向小李:“你回去转告大步,紧急情况下要把自己想到的变更提出来讨论,还有那些他们实际上已经实施了的变更。虽然没法证明这次的行为跟大步有关,但是我猜八九不离十了。他意识到出问题之后,就撤销了变更。”

“小李,你能不能管管你手下,不准再出现未经授权的变更,也不准在服务中断期间再次出现未经公开的变更。”

小李看着我,无奈地说:“好的,老大。”

其实,二八法则在变更这里同样适用,因为 80% 的风险是由 20% 的变更造成的,看得见的变更会让故障的恢复加速 200%。于是小王给大家安排了任务,让大家把需求变更写在卡片上,然后讨论下哪些是优先的,哪些是待办的。就连小李都说:“这下好了,批准一个变更只要 23 秒,比上一次的最短时间少了 59 分钟。”

4. 引入新方式 DevOps

其实不只是我们运维部门,想象一下,如果一个公司中产品经理、开发人员、QA 人员、IT 运维人员和信息安全人员都能互相帮助,朝着一个共同的目标努力奋斗,建立出从产品计划直至功能上线的端到端的快速服务交付流水线(例如每天执行几十次、数百次甚至上千次代码部署),在系统稳定性、可靠性、可用性和安全性方面均达到了世界一流的水平。

在那里,跨职能团队可以严谨地验证他们的假设:哪些功能最能取悦用户并能促进企业目标的实现。QA 人员、IT 运维人员和信息安全人员也会共同投身于团队文化建设,致力于创造能使开发人员效率更高、产能更大的工作环境。甚至连小团队也能够快速独立地开发、测试和部署代码,并且可以快速、安全、可靠地向客户交付价值。

这样的画面可能让你觉得不真实,好吧,这其实不只存在你的想象中,DevOps 可以帮你实现这样的场景,提高工作效率。

DevOps(Development 和 Operations 的组合词)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。

它是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

它的出现是由于软件行业日益清晰地认识到:为了按时交付软件产品和服务,开发和运维工作必须紧密合作。

近年来,很多大公司都投入到了 DevOps 的使用中,提高开发和运维之间的协作,不再相互甩锅。Devops 三步工作法更是给你的工作带去新的方向。

DevOps 三步工作法:

第一步,实现开发到运维的工作快速地从左向右流动。为了最大程度地优化工作流,需要将工作可视化,减小每批次大小和等待间隔,通过内建质量杜绝向下游传递缺陷,并持续地优化全局目标。

第二步,在从右向左的每个阶段中,应用持续、快速的工作反馈机制。该方法通过放大反馈环防止问题复发,并能缩短问题检测周期,实现快速修复。

第三步,建立具有创意和高可信度的企业文化,支持动态的、严格的、科学的实验。通过主动地承担风险,不但能从成功中学习,也能从失败中学习。

5. 凤凰项目:所有 IT 人都要读的一本书

一本运维圣经,但是对于开发人员同样适用,作者亲身经历的每一个工作场景都是我们现实工作的写照。如何跟开发人员协同,如何将自己从无休止的“救火”工作中解放出来,DevOps 传递给你的不只是一种思维还是一种全新的工作方法。日益增加的工作任务以及不断削减的预算,都是大部分公司的部门里会面对的问题,每个开发人员每天应对繁重工作已经很辛苦了,可能很少有时间去想如何改变和解决这些混乱。怎么让自己不在洪流中迷失呢,这本书给了你一个很好的方向。

三部工作法,实现高效运维

《凤凰项目(修订版)》

作者:[美] 吉恩·金,凯文·贝尔 等

译者:成小留,刘征 等

广受读者欢迎的运维名著。讲述了一位 IT 经理临危受命,在未来董事的帮助和自己“三步工作法”理念的支撑下,最终挽救了一家具有悠久历史的汽车配件制造商的故事。小说揭示了管理现代 IT 组织与管理传统工厂的共通之处,让读者不仅能对如何管理 IT 组织心领神会,更重要的是将以完全不同于以往的视角来看待自己的工作环境。

这本书的第一版在豆瓣上获得 8.7 分好评,这次的修订版除了新增第四部分内容之外,还附赠了一个超级牛气的沙盘游戏。小伙伴可以在读完书后,通过这个游戏感受到 DevOps 的精髓。

凤凰项目沙盘游戏证书样品

凤凰项目沙盘被全球 IT 管理权威认证机构 EXIN 国际信息科学考试学会指定为 DevOps Master 认证考试实践作业的考核部分之一。

2016年,国际最佳实践管理联盟将凤凰项目引入中国,并邀请到了凤凰项目沙盘开发者简·希尔特先生在北京举办了“凤凰项目沙盘”中国首期授权讲师研修活动。

中国首批参加凤凰项目沙盘讲师授权培训的合影

中国首届IT管理最佳实践沙盘挑战赛,2017年7月,北京

凤凰项目沙盘大赛成员合影,2018年11月,中国深圳

几个陌生人一起组队,在几个小时内,通过角色扮演,参与到日常真实的开发和运维工作中去,一方面可以提高大家的决策思维,另一方面也提升了大家跟不同性格人团队协作的能力。还是蛮值得试一下的。

另外,在书中,有一个世外高人,他以工厂的产品作为类比,将 IT 项目中不完整的项目比作半成品,大多数情况下,我们的公司希望我们快速输出成品,其实这个成品的质量如何,是值得考究的。成品质量不过关,欠下的技术债,如果不及时发现后面还是要吃亏的。俗话说,出来混迟早是要还的,这些不过关的半成品我们要争取将他们控制在产生前。提高工作效率,将自己从繁琐中解放出来。