过去十年间，CIO每两年肯定会轮换一次，就像钟表一样有规律。他们在位的时间仅够理解各种首字母缩写的含义，知道卫生间在哪里，推行一堆计划和倡议，然后梦想破灭，再然后走人。
副总裁们整天做的就是互发PPT。
程序开发人员比网络维护人员更可怕。你要是能找出一个不给生产体系添乱的开发人员，我就能给你找出一个往镜子上哈气却不会起雾的人。或者更有可能的是，他们业务今天又放假了。
想要知道供应商有没有在撒谎，只要看他们的嘴唇有没有在动。
我挠着头。作为一家企业，我们已经对虚拟技术投入巨资。尽管看起来像是 20 世纪 60 年代的主机运行环境，但虚拟技术改变了韦斯的游戏规则。
昨天工资核算发生故障的时候，我们正在对一个 SAN 固件进行升级。布伦特认为 SAN 正在损坏数据，于是建议把调整的部分再改回去，我觉得这样做是符合逻辑的，但结果如你所知，他们只是在添堵。
她是整个 IT 部门的代言人。只要发生了 IT 故障，大家就会找帕蒂。无论是出现服务器崩溃、网页加载过慢，还是类似今天这种数据丢失或损坏的情况，她都是我们的专业辩护人。
我不喜欢财务部的人在工资核算应用程序之外手动更改工资数据。
我的怒气消散了。这只不过是一出办公室政治剧。虽然我不喜欢，但也只能接受现实。当初晋升为上士时，我差点儿就想终身投身于海军陆战队。如果你玩不来政治，就别想在海军陆战队里成为高级军官。
我猜想莎拉一定很喜欢这样：像蜘蛛一样结网而待，喜滋滋地看着公司的各色蝼蚁送上门来。
这个世界一定是哪里不对劲了，一半邮件都是紧急邮件。所有事情都那么重要，这可能吗？
这样的情况只能进一步加深我对开发人员的猜疑：他们经常粗心大意地弄坏东西，然后消失不见，让运维部的人收拾烂摊子。
比一名开发人员更危险的就是开发人员和信息安全部门的人联手。这样的组合把我们添乱的动机、手段和机会都弄齐全了。
信息安全部总是到处亮出他们的“尚方宝剑”，提出各种紧急要求，全然不顾这样对其他部门造成的后果，因此我们有很多会议都不邀请他们参加。只要有他们在，事情肯定办不成。
他们总能提出无数条理由来证明我们做的任何事都会造成安全漏洞，黑客会利用这些漏洞洗劫整个公司，偷走所有的代码、知识产权、信用卡卡号甚至我们的私人照片。这些情况可能确实具有潜在风险，但很多时候，我很难从他们提出的那些不依不饶、歇斯底里、自以为是的要求中，找出与切实提高环境防御有什么关联。
她要求我们用的那个应用软件简直就是垃圾。为了申请一个 5 分钟就能搞定的简单变更，得花上 20 分钟才能填完全部字段！我不知道是谁设计了那个流程，但我觉得那些设计流程的人以为我们都是按小时拿工资的，所以宁愿坐而论道也不肯真正去干实事。
他刚刚信口开河地确定了一个投产日期，全然不理会部署之前我们需要做多少工作。
我们和开发部甚至还没有对如何移交工作达成共识。以前他们总是指着一个网络文件夹说：“部署那个”。开发部给我们的操作说明少得可怜，连教堂门口的弃婴身边放的说明都比这详细。
结果从来不理想。通常情况下，软件产品实在太不稳定、太不可用，连那些曾经强烈要求这些产品的人最终也会说它不值得上市。到最后，总是 IT 运维部在通宵达旦地为那些糟糕的代码埋单，每隔一小时重启一次服务器，就像电影里的超级英雄那样，尽可能向世人隐瞒糟糕的真相。
这些只言片语无法让我对整体情况做出判断并给出真正的意见。我不想像海鸥一样，飞过来在人们头上拉完屎就飞走了，你明白吗？
想通过凤凰的成功来追上竞争对手，你肯定会像现在这样做。在我看来，你就像是傻乎乎地冲到枪战现场，不仅迟到了，还发现自己只带了把破刀。
创建约束理论的艾利·高德拉特告诉我们，在瓶颈之处做出的改进都是假象。难以置信，但千真万确！在瓶颈之后做出的任何改进则是徒劳的，因为只能等着瓶颈把工作传送过来。而在瓶颈之前做出的任何改进则只会导致瓶颈处堆积更多的库存。
你说得对，只有掌握了战术，才能实现战略目标。
但是，鉴于他们运作公司的方式，你在海军陆战队的那一套在这儿不管用。海军陆战队的指挥系统里只有一个将军，但这儿有十个将军在发号施令，而且他们全都有公司每一个二等兵的直线电话。
看起来你们过得很糟糕。IT 运维部似乎和所有的主要工作都脱不了干系，包括公司的首要项目。
“绝对不行，”我立刻说，“再也没有比阻止人们去做他们理应做的事更能毁掉大家的热情和支持了。我不认为我们还能有第二次机会让事情走上正轨。
“当然，不过不只是她一个人。”她回答，“公司的所有管理人员几乎都是直接去找他们喜欢的 IT 人员办事，不是请我们的人帮个忙，就是强迫他们做事。
帕蒂点点头：“我们早该这么做了。我们的紧要任务总是在不断累加，以致原有的任务不断往后拖，直到有人朝我们大喊大叫，想要知道我们为什么还没有完成并交付某项工作。
他翻了个白眼说：“听着，我现在就能告诉你接下来会发生什么。我们向管理层陈述目前的状况，他们不仅会驳回我们的要求，而且还会把我们的预算再削减 5%。过去五年来他们一直是这么干的。与此同时，大家还是会在同一时间让我们既做这又做那，不断地向我们的工作清单上增加工作量。
韦斯对约翰和蒂姆说，他显然已经气急败坏了，“运行制造 ERP 系统的一些服务器已经使用超过二十年了。如果它们坏了，业务就会陷入停顿，这些服务器的供应商几十年前就停业了！这些设备太脆弱了，哪怕你只是在错误的时间去看上一眼，它们都会崩溃，只能寄希望于巫术咒语来让它们重启。要是照你们打算的那样大动干戈，它们就再也活不下去了！
我们如同转轮上的仓鼠，陷入了永无止境的痛苦循环：一个季度接着一个季度，信息安全部都会无休止地发来各种安全漏洞修复建议，把大家的收件箱塞得满满的。
流程是用来保护人的。我们得想出保护布伦特的办法。
可能布伦特实际上并不像我们认为的那样聪明绝顶。也可能他是个技术界的爱因斯坦，别指望能找到和他同等水平的员工。还可能他是故意让自己显得无可或缺，以免其他人抢了他的工作。
显然，就连乌合之众也会有走运之时。
我们开发人员全部没做过任何变更。把我们从你的黑名单上划掉。故障可能是某个数据库变更引发的。
什么都没改，至少没改任何可能影响订单输入系统的东西。你确定不是操作系统补丁又出错了？
近三周以来我们没有安排过针对这些系统的更新。我赌 50 美元，故障一定是网络方面的变更引起的，他们的变更总是惹麻烦。
每次服务中断，总是网络维护组受到指责，这不公平。我们今天没有安排任何变更。
你这是要让我们证明我们没有做过任何事。你究竟怎么样才能拿出反证来？再说了，我估计问题出在防火墙变更上。过去几周以来，大部分服务中断都是这类变更造成的。
我们对虚拟化投入巨资，这本该让我们避免此类麻烦。但是，开发部解决不了性能问题，却归咎于虚拟化。所以，我们只能把所有东西都挪回实体服务器！
你也知道，为了行事高效，总得经历些曲折，对不对？在技术层面，总会有些始料不及的事情发生。要是你想做煎蛋卷，那总得打破一些鸡蛋才成。
问题是，把所有东西都设置好并运行起来，大约需要半小时，然后执行冒烟测试又需要三小时。在那段时间里，我们可能会从开发部那边收到另外三个版本。
面对层出不穷的版本，我们已经很乱了——我们在记录整个发布的版本编号方面做得太马虎了。他们经常在解决一些问题的同时，又弄坏了别的东西。所以，他们现在发来的都是单个文件，而不是整个软件包。
让我猜猜。前端程序无法与数据库服务器对话，是因为有人没告诉我们需要打开一个防火墙端口？
很多人在笔记本电脑上打开了谷歌搜索，另一些人则按部就班地鼓捣着服务器、操作系统、数据库以及凤凰应用程序的各种设置，试图想办法把事情都弄妥当。开发人员向他们保证过，这是可以办到的。
看，在我的笔记本电脑上，它已经在运行了。这能有多难？
