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