1. 我升职了，但我不开心
我叫 Bill，是一家公司的运维经理。上周我的顶头上司跑路了，我临危受命，被老板钦点升（jie) 职 (pan)。事实上我并不想升职，上周 HR 找到我，异常热情地告诉我这个“好”消息。我当时很纳闷，于是问她：“没听说我上司提过要走啊，他为啥走了？”她说：“当然是有更高的追求了，你想知道可以去问他！”
俗话说得好，如果你同事主动告诉你要离职，那多半是自愿的。但是如果其他人告诉你的，那他们一定是被迫的。看来我上司被炒了。我很抵触，因为我只想带着我的团队做好事情，我可不想像其他经理一样，每天只知道互甩 PPT。
2. 无休止的甩锅何时停止
早上 8:00，我一边喝着咖啡一边打开笔记本电脑，我想在 9 点开会前处理好电子邮件。在过去的 24 个小时里，我已经收到了 526 封新邮件外加 300 多条语音消息。
一眨眼九点了，我快步走到会议室，老板正在部署财政预算。我强装欢笑，因为手机已经在裤兜里震了一会儿了，我知道大事不妙。于是掏出手机，瞬间五雷轰顶：“1 级严重级别事故：信用卡处理系统故障。所有门店都受到影响。”
屁股还没坐热，我夹着笔记本就冲到网络运营中心，我们部门的 IT 服务支持部总监小王正在调整电话。“咳咳，Bill 来了。目前进度是订单输入系统无法使用，现在发布了一个 1 级严重级别的事故。正在设法查证开展过哪些变更。”
他顿了一下，看着我：“话说，我可不敢肯定我们真能搞清楚。”
我说：“大家想想，今天实施的所有变更当中，哪些可能会导致这个服务中断？”
最怕空气突然安静，一阵沉默不语，左顾右盼。
我刚想说话，一个声音打断我：“我是负责人小张。我之前跟小王沟通过，现在再跟你说一遍，我手下的开发人员全部没做过任何变更。你赶紧把我们从你的黑名单上划掉。谁知道故障是不是某个数据库变更引发的。”
另一个老哥忍不住了，愤怒地说：“啥？我们可什么都没改，至少......没改过任何可能影响订单输入系统的东西。你确定不是操作系统补丁又出问题了？”
紧接着，一个人气呼呼地说：“怎么可能！我可三周没更新这些系统了。要不是网络变更引起的，我把头砍下来给你坐。他们每次变更总是惹麻烦。”
这时，网络维护主管，委屈地说：“凭什么每次服务中断，总是网络维护组受到指责，这不公平！你把话说清楚。”
“那你倒是证明给我看啊。”数据库经理挑衅地说。
网络维护主管拔高了声音：“简直胡说八道！我没做过的事情，你要我怎么证明？说不定是防火墙，上周中断就是他们造成的。谁的锅谁背，别扣我这里来。”
小王很愤怒，他对我说：“小李的团队没人来参加这个电话会议。所有防火墙变更都是他的团队在处理的。看来要想办法联系他才行。”
这时有个声音说：“emmm......现在谁能试一下？”大家停止了争论，在键盘上打着字，他们正尝试进入订单输入系统。
“等一下！刚才是谁在说话？”一阵尴尬的沉默。
“是我，大步。”
大步是分布式运维部门的，我忍住火气说：“你下次在行动之前是不是要先通告大家一下。我们最不愿意做的事，就是让情况变得更糟糕，让原因变得更复杂。”
话还没说完，一个人打断我：“嘿，系统重新启动了。干得好！大步。”
其实，二八法则在变更这里同样适用，因为 80% 的风险是由 20% 的变更造成的，看得见的变更会让故障的恢复加速 200%。于是小王给大家安排了任务，让大家把需求变更写在卡片上，然后讨论下哪些是优先的，哪些是待办的。就连小李都说：“这下好了，批准一个变更只要 23 秒，比上一次的最短时间少了 59 分钟。”
其实不只是我们运维部门，想象一下，如果一个公司中产品经理、开发人员、QA 人员、IT 运维人员和信息安全人员都能互相帮助，朝着一个共同的目标努力奋斗，建立出从产品计划直至功能上线的端到端的快速服务交付流水线（例如每天执行几十次、数百次甚至上千次代码部署），在系统稳定性、可靠性、可用性和安全性方面均达到了世界一流的水平。
在那里，跨职能团队可以严谨地验证他们的假设：哪些功能最能取悦用户并能促进企业目标的实现。QA 人员、IT 运维人员和信息安全人员也会共同投身于团队文化建设，致力于创造能使开发人员效率更高、产能更大的工作环境。甚至连小团队也能够快速独立地开发、测试和部署代码，并且可以快速、安全、可靠地向客户交付价值。
DevOps（Development 和 Operations 的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运维工作必须紧密合作。
第三步，建立具有创意和高可信度的企业文化，支持动态的、严格的、科学的实验。通过主动地承担风险，不但能从成功中学习，也能从失败中学习。
所有 IT 人都要读的一本书
三部工作法，实现高效运维
译者：成小留，刘征 等
中国首批参加凤凰项目沙盘讲师授权培训的合影
中国首届IT管理最佳实践沙盘挑战赛，2017年7月，北京
几个陌生人一起组队，在几个小时内，通过角色扮演，参与到日常真实的开发和运维工作中去，一方面可以提高大家的决策思维，另一方面也提升了大家跟不同性格人团队协作的能力。还是蛮值得试一下的。
另外，在书中，有一个世外高人，他以工厂的产品作为类比，将 IT 项目中不完整的项目比作半成品，大多数情况下，我们的公司希望我们快速输出成品，其实这个成品的质量如何，是值得考究的。成品质量不过关，欠下的技术债，如果不及时发现后面还是要吃亏的。俗话说，出来混迟早是要还的，这些不过关的半成品我们要争取将他们控制在产生前。提高工作效率，将自己从繁琐中解放出来。
题图来源：Unsplash by Luca Bravo
推荐阅读：