据悉，马士基 Triple-E 级集装箱货轮长 1300 英尺，可装载 18000 个集装箱，航程横跨欧亚 1.1 万英里，船上的所有船员都可以舒服的住在客舱里。
以前，我曾经是一名造船工程师，现在在一家创业公司做营销顾问。我发现，带领 13 名船员驾驶世界上最大的集装箱货船，航行到半个地球之外的一个港口而不出现事故，这样的经验，同样适用于有着业绩增长需求的创业公司:
系统越简单，宕机时间越少。
船上的系统比较简单，易于操作，容易理解，所以即使出现问题也容易修复。如此，因故障停船的时间就会减少。对于一艘超大货轮而言，“故障停船”意味着它被困于数千英里之外却求助无门。这样看来，“简单”真的很有必要。
以船舶的操舵系统为例。方向舵由金属杆向左或向右推动。这些金属杆是由液压驱动的，液压由液压泵控制。泵是由舵手室发出的电子信号控制。而信号是由自动驾驶仪控制的。当出现问题时，不需要船舶专家或造船工程师来寻找问题的原因和解决方案:
如果自动驾驶仪失灵，就从舵手室手动操纵船只。
如果电子信号失效，可以到舵控室手动控制泵，同时通过一个简单的声能电话与舰桥通话。
如果液压系统出现故障，可以使用机械连接的应急方向盘。
如果机械装置坏了，你可以在舵的两边各挂一根链条，朝你想要的方向拉!
与船舶类似，创业公司无法承受系统宕机的后果。销售、市场营销、网络、客户支持、招聘、产品和其他系统的长时间停滞可能会对增长率造成不可弥补的损害。
(虽然在现代船舶上自动化应用很多，但这些只会对做事情所消耗的时间和监控方便性产生影响。推进和辅助系统反而比以往任何时候都要简单，这主要由于现代的柴油和电力推进系统取代了以往满载管道的蒸汽发电装置。）
为什么简单能减少宕机时间
1. 可以快速熟练掌握
如果负责这个系统的人离开了、落水了或者被车撞了，又或者被安排到另一个项目中去，另一个人可以在没有多少学习或培训的情况下快速接手。这意味着很多人能介入并解决问题。
例如，用 Tableau 构建的分析仪表板可能比用自定义脚本和 API 拼凑而成的仪表板让人更容易上手，解决问题。我们不应该让数据科学家或产品开发人员来构建数据图表展示程序，那样程序就会变复杂。
2. 排除故障花费的时间更少
在一个系统中，每个组件的行为及与其他组件关系越容易理解，排除问题并找到出问题组件 (根本原因) 也越快。
例如，如果一个公司在其网站上提供许多可下载的白皮书，并且它们都被限制在某一个表单 (而不是每个白皮书对应一个自定义表单) 之后，那么当白皮书下载出现问题时，我们只需要排除一个表单和一个下载工作流的故障就可以了。
3. 更多的可替代方案
当系统的每个部分功能清晰明确时，就更容易找到替代方案。
例如，假设有一个 Salesforce 流程，它使用自动化和第三方工具配合的方式来评分、筛选、分类和分配新的销售线索。如果出现问题，那就很难找到替代方案。这会耽误所有事情，直到该流程得到修复或被相似的解决方案替代。
现在，再来假设另一个销售流程，在这个流程中，仅仅通知销售团队每一个新的销售线索以及相关的细节，让他们决定是否跟踪该线索。如果 Salesforce 通知步骤失败，那么很容易就会有 100 种其他方式将该信息传递给销售团队：报告、Slack 通知、查询信息列表、人工观察，或者使用 Zapier 通过任意媒介发送警报。工作耽误的时间最多只有几分钟。
初创公司案例
之前，我的一个客户一直用一个比较老的企业营销自动化平台 (Marketo)，并用该平台在几年时间内构建了 629 个自动化流程。当某个东西坏了或需要调整时，150 多名员工中只有一个人能做这件事。每个问题都需要几天甚至几周的时间来解决，而营销活动只能停滞不前。每打一个补丁，整个系统都会变得更加复杂。
当那个人离开公司时，就没有人会操作这个系统了。之后，每个星期都会出现一个新问题，比我们找到并修复它们的速度还要快。
为避免营销运作陷入停顿，我赶紧将公司从 Marketo 迁移到 HubSpot 上，这是一个更简单的平台，更易于操作和排除故障。
迁移只花了一周时间。然而，在这个过程中，另一个复杂的系统出现了：Salesforce。Salesforce 有 10 个自动化流程，100 多个组合操作，所有这些都依赖于 Marketo 中各种微妙的定时自动操作。我们花了两周时间 (是迁移时间的两倍) 来理解并将这些流程与新的营销平台集成。
总的来说，这两个复杂的系统 (Marketo 和 Salesforce) 导致营销团队有六周的“宕机”时间，而销售团队有三周的“宕机”时间。这还不包括他们在过去几年中经历的“宕机”时间，也不包括如果我们不彻底检查底层系统，他们将要经历的“宕机”时间。
最后，我们的系统减少 97% 的进程 (从 629 个减少到 20 个)，不过却提供所有相同功能。几天后，一个被发现的 bug 在四分钟内就解决掉。
这段经历让我总结出一些东西，是关于初创公司可以采用哪些原则来规避复杂系统陷阱的。
简单系统的 3 大原则
“拆换”项目很痛苦，具有破坏性，即便从长期利益来看是值得的。许多创业公司就像船舶一样，它们在初始阶段没有足够时间和资源来进行大修。
以下是我在评估或实施新系统时要遵循的三条原则:
1. 满足特性并不一定要复杂
如果一个复杂的飞行控制系统总是让飞机停飞，或者像 Marketo 这样的企业营销平台经常使营销活动停滞，那么它又有什么用呢?
选择易于操作的工具，而不是承诺提供最多特性的工具。
2. 复杂的设想导致复杂的实现
如果解释或理解一个设想需要太长时间，那么实现它将会更加复杂。当某些东西不可避免地出现故障时，修复它的时间就会很长。
例如，一个销售流程假如要演示一个小时，不管它看起来有多好，后期想要维护都很困难。
3. 尽量改变而不是添加
当新的需求出现时，我们总是倾向于通过其它方式或在现有系统上集成添加新功能。实际上，我们应考虑是否可以通过改变核心系统来满足新的需求。
就像从 marketo 到 hubspot 的迁移示例一样，这个改变可能会导致预先的计划停滞，但是从长期来看，停滞时间会更少 (计划外的)。
稳定最重要
事物越简单，无序化的可能性就越小，对无序化问题的修复就越容易。——Thomas Paine, Common Sense, 1776
毫无疑问，人们在创业过程中肯定会遭遇挫折，就像在环球航行中一样。然而，如果船上的系统很简单又稳定，这些问题就不会让创业公司无助地漂在大海中了。
英文原文：
Simple Systems Have Less Downtime
