高管如同飞行员 云企业战略博客

高管如同飞行员

关键要点

今天的高管们肩负重大责任。不仅商业环境变化快速，技术发展的步伐也相当惊人。这些技术不再是“IT部门在引擎室里做的事”，而是企业实现灵活应对的关键要素，而不需牺牲品质、可靠性或安全性。那么，高管该如何在商业策略与技术设计决策之间架起桥梁，以不被分心，却能在需要时把握方向？幸运的是，我们可以从一群同样需要在技术依赖下做出关键决策的人飞行员身上获得启发。

飞行员不仅是飞行操作的专家，也是确保所有乘客安全到达目的地的关键角色。他们操控著令人惊艳但极其复杂的机械。要做出至关重要的决策，他们必须理解所操控的设备以及他们所处的环境。尽管飞行员不必单独进行这些工作，他们仍依赖于空中交通管制、地面人员、维护中心和气象服务的支持，但最终的责任是无法移交的。让我们看看高管，尤其是在云端旅程中的高管，能如何从飞行员的培训和操作过程中学习一些经验。

在 35000 英尺上管理复杂性

飞行员必须随时准备做出安全关键的决策，通常是在短时间内且基于不完整或矛盾的数据。让我们加入从多伦多飞往里斯本的Air Transat 236航班，在一段平稳的跨大西洋飞行中，飞行员注意到第二台引擎的油温低于正常值，而油压却高于正常值。在维护中心的建议下，他们持续监控情况，直到半小时后，左右两侧翅膀的燃料不平衡引起了他们的注意。他们决定通过将左侧油箱的燃料灌入右侧油箱来纠正这一点。接下来的45分钟一切顺利，直到第二台引擎因缺油而熄火。所幸，所有双引擎喷气机都设计为可以安全地在单引擎运行。可惜的是，又过了10分钟，第一台引擎也熄火，让飞机在大西洋上几乎没有燃油和任何运行中的发动机。这也意味著几乎所有的液压和电力系统都关闭了，让这架搭载293名乘客的空客330几乎变成了一个原始的滑翔机。经过一个小奇迹和大量飞行员的技术，这架飞机安全降落在距离75英里的亚速群岛的军事空军基地。

这次飞行发生的事情有著技术上的解释。喷气发动机是快速旋转的涡轮，像汽车引擎一样使用机油进行润滑。油通过热交换器来冷却，该装置在使流经引擎的油冷却的同时，让从油箱流向引擎的燃料变得更热。236航班因为靠近引擎的燃料管路错误安装，与引擎外壳摩擦而破裂。泄漏的燃料导致热交换器过度冷却引擎油，使得油温过低、油压增加冷却的油有更高的粘度。

所有飞行员在驾驶舱中看到的警告来源于一个单独的问题：破裂的燃料管。如果飞行员知道热交换器的机制，他们可能会推论出燃料不平衡与他们观察到的低油温之间的联系。他们会意识到，在大海上向一个泄漏的油箱转移燃油是一个非常糟糕的主意。

高管如同飞行员

飞行员必须在复杂和不确定的环境中快速做出决策，这就是他们进行大量训练并遵循严格程序的原因。尽管现代IT高管不太可能在大西洋上耗尽燃料，但他们所处的环境具有高度的复杂性，对商业至关重要。让我们更深入地看一下现代IT高管如何受益于像飞行员一样操作：

时刻准备掌控全局

飞行过程中，大部分时间都在自动驾驶系统下进行，这有助于避免飞行员疲劳和分心，处理保持飞机按规定航道飞行的例行工作。飞行员设定航向和高度，自动驾驶系统便会自动完成大部分的飞行。然而，自动驾驶系统并不能取代飞行员理解他们所操控的机械设备的能力。这也是为什么飞行员需要定期进行手动驾驶的原因，通过手动操控，飞行员能够理解他们所处的技术环境的动态，包括该环境对输入的反应，以及不同部件如何彼此互动或干扰。

IT高管同样习惯于在自动驾驶模式下运行。这种情况被称为“按目标管理”：高管资助IT项目并指定可交付成果和时间表。这种设置中的自动驾驶是中层管理：他们检测小的偏差并纠正，以确保任何事情都能顺利进行。十几年前，这种运行方式是有效的，因为商业环境和可用技术的变化速度相对较慢，保持稳定相对容易。但今天动荡的IT环境却截然不同。技术创新正以前所未见的速度发生，结合商业环境的快速变化，使得CIO及其IT部门不得不随时保持警惕。

IT高管需要能在情况变得紧急时掌舵，就如同飞行员一样。为了实现这一点，他们需要了解IT“引擎室”内发生的事情技术系统运行的场所及做出关键决策的地点。理解系统和技术之间的依赖性能够教导IT高管如何对仪表板上不寻常的读数做出反应，这就像飞行员一样。这个“红灯”是一个简单的警告还是严重的问题？飞行员无法选择“等著看”。对于今日快节奏的IT环境，IT高管的处境也是如此。

中层管理是IT的自动驾驶。它处理例行调整，以便高管专注于关键任务。但是，自动驾驶也可能掩盖问题。因此，高管必须随时准备在情况变得紧张时掌控全局。

自动驾驶系统虽然很有用，但也可能掩盖潜在的关键问题。由于它们会自动补偿偏差，某些问题可能在问题严重之前都不会被发现。因此，对于飞行员和IT高管来说，不能盲目依赖自动驾驶系统。这也是为什么在亚马逊，我们将“深入探究”作为我们的16项领导原则之一。亚马逊的高管被期望深入了解他们所管理的内容不依赖于自动驾驶。

在引擎室进行巡视

在任何飞行员登机前，他们会进行一次全方位的检查：他们会到停机坪上，检查轮胎、传感器和引擎进气口。这是为了确保一切都在良好工作状态。他们不会盲目信任仪表和指针。尽管技术人员会仔细维护设备，但飞行员仍需与他们所驾驶的机械保持联系。毕竟，他们承担著从头到尾的责任当飞机在大西洋上燃油不足时，你不能说“那不是我的部门”。全方位检查还表明，即使飞行员工作职称尊贵，踏在停机坪检查机器也绝不会让他们羞愧。

同样，现代IT高管需要了解他们所控制的机械。这并不意味著他们需要阅读或编写代码，但他们应该了解关键组件，在选择解决方案时可能带来的后果，以及系统之间的关键相互依赖关系。开展现代工作模式如DevOps或敏捷开发所需的技术基础设施是什么？平台策略能否在增强创新同时促进协同？什么是使这种策略成功的关键成分，无论是技术上还是组织上？对于那些对以上问题有清晰答案的高管，将不仅能做出更好的决策，还能成为相关IT倡议更强有力的赞助者。

现代IT高管需要造访引擎室，以建立对所控制机械的理解。

“边走边管理”这句话在70年代和80年代相当流行。今天IT的日益复杂性可能会使高管不愿意走进引擎室，但实际上这比以往任何时候都更为重要：这些引擎决定著你的企业是否能够翱翔。

多问“为什么”

在复杂系统中，理解各部分之间的相互连结是很困难的。当一切运行正常时，人们可能从不会了解到燃油和油类热交换器的存在。讽刺的是，当发生不寻常情况最糟糕的情况是燃料泄漏我们才能学会引擎室是如何运作的。但只有提出足够的问题，我们才有机会了解到。

航空安全委员会会问很多问题，以查明问题的根本原因。他们不仅停留在技术问题上，还会考虑程序、管理实践以及监管指导原则。IT项目的延误和失败的原因似乎也各不相同。因此，高管应参与回顾会，并提出很多“为什么”的问题。丰田提出的“五个为什么”方法便是为了通过反复询问为什么事情发生来查明问题的根本原因。这里的重点不是去找出“有罪的一方”，而是要解决问题的真正根源，而不仅仅是治疗症状。

一切按计划进行或许是最舒服的状态，但意外状况却带来更多学习机会如果你问够多的问题的话。

所以，下一次当事情未如预期般进展时，急于找到快速解决方案可能会错过最具价值的学习机会。当问题神奇地消失后并不意味著问题得以解决，只有当根本原因被理解并得到解决后，问题才得以解决。只有当你先询问够多的“为什么”后，这一过程才能实现。

使用模型来应对复杂性

飞行员和技术人员无法把整架飞机拆解以了解其运作原理。他们依赖手册、示意图和工程图。这些文件是抽象模型：它们强调重要部分，特别是哪些组件相互连接。它们也省略了很多细节，比如电线或燃油管的确切长度，因此它们能减少复杂性而不失去重要方面。

架构模型对于像飞行员一样运作的高管而言，同样是重要的工具。这些模型提供了有意义的抽象，消除了噪音，突出重要选择及其取舍。这是征服当今IT中不可避免的技术复杂性所必需的方法。没有这样的模型，管理复杂性就像打地鼠游戏：你解决了一个问题，却让另一个问题似乎随意冒出来就像飞行员平衡燃料箱却不到一小时就耗尽燃料一样。因为复杂系统中的问题通常发生在部分之间，如燃油管线或故障的软体整合中，因此使用描绘部件之间联系的模型是至关重要的。

如果没有架构模型，解决IT问题将会像打地鼠游戏一样骤然困难。

架构团队在这方面是很好的资源。因此，现代架构团队应该与IT高管紧密联系。他们能够创造清晰，帮助做出更好更透明的决策。这些架构师将决策者与IT引擎室连接起来，我将这一概念称之为“乘坐架构师电梯”。

专注于语法，而非词汇

过多的行话让许多IT高管在进入引擎室时感到困惑。与引擎室的人士交流时，往往会感觉要使用一门外语。“我们偏向使用声明式的IaC流程，但将API包装在面向对象的语言中，以促进频繁的重构”这样的话你可能会听到。你可能会想忽略这些细节，直到下一条消息是“我们共享的IaC库中的错字导致生产系统故障，因为它关闭了所有服务器。”此时代掌控全局将变得十分困难，将责任推给实习生将无法成立。

更糟的是，IT术语不断变化：是DevOps、DevSecOps、PostDevOps、新运营还是无运营？这些是不是其实是一回事还是应该称其为SRE站点可靠性工程？仅仅就这一辩论就可能持续数小时。

幸运的是，并不需要记住一整本巨大的IT词典。要学会一门新语言，你需要掌握两个要素：词汇，提供可用词的集合，和语法，定义如何结合这些词以表达有意义的事物。作为高管，即使是像飞行员一样行事，也是几乎不可能掌握当今的IT词汇：其变化太频繁，且不存在广泛接受的字典。

随著当今IT词汇的变化，跟上步伐非常困难。因此，更应专注于语法以理解关联。

高管若想崭露出如同飞行员一般的风范，应该专注于IT的语法：哪些词的组合是有意义的？在迁移云端之前，我能否建立DevOps实践？使用无伺服器平台是否会影响我实施DevOps的方式？企业是否应该参与这一转型？这些问题揭示了IT语