标签：apach 控制 展示 迁移 就会 崩溃 复杂 一段 下载
为什么说系统越简单，宕机时间越少马士基三E级集装箱船长 1,300 英尺，在欧洲和亚洲之间 11,000 英里范围内运载超过 18,000 个集装箱，并且…所有船员可以塞进一辆中巴车里。
作为一名前海军架构师，和现任初创公司的市场咨询师，我发现让 13 名船员驾驶世界上最大的集装箱船到世界任何港口而不会中途崩溃的原则，也适用于努力实现积极增长的初创公司：
使用简单系统的船舶，更易于操作和理解，这使得它们易于修复，因此停机时间更少。考虑到船舶的“停机”可能是被困于千里之外，因此不停机这是一项重要的指标。
以船舶的转向系统为例，方向舵由金属杆向左或向右推动，这些杆通过液压移动，压力由液压泵控制，泵由来自驾驶室的电子信号控制，信号由自动驾驶仪控制。不需要火箭科学家或海军架构师，就可以找到问题的原因和解决方案：
像船运这样的初创公司承受不起系统故障的停顿。销售、市场营销、网络，客户支持、招聘、产品和其他系统的不正常，可能会对业务增长造成无法弥补的损害。
如果负责系统的人员离开、掉落、被车撞了或被拉入另一个项目，则另一个人可以在不需要太多学习或培训的情况下接手。这意味着可以有更多的人可以介入故障排除和修复工作。
例如，使用 Tableau 构建的分析仪表盘，可能比由定制脚本和 API 拼凑而成的分析仪表盘，有更多符合资格的人员来修复。谁都不想去找数据科学家或产品开发人员来修复一个条形图的小问题。
如果一个系统中每个组件的行为与其他组件的关系易于理解，排查问题并找到损坏的组件（以及根本原因）就更加容易。
例如，如果一家公司在其网站上有许多可下载的白皮书，并且都被封闭在一个表格中（而不是为每个一个表格），那么如果下载白皮书，则他们仅需要对一种表格和一种自动化工作流程进行故障排除。
当系统的每个部分都具有明确的功能时，更容易找到替代方案。
例如，假设有一个 Salesforce 流程，该流程使用大量自动化和第三方工具来对得分、筛选、分类和分配新的销售线索进行评分。如果出现问题，则没有明显的替代方法。一切将被搁置，直到该问题解决或被类似的复杂解决方案替代。
现在想象一下一个销售过程，在该过程中，销售团队会被简单地通知每个新的销售线索以及相关的详细信息，让他们决定是否跟进该线索。如果 Salesforce 通知步骤失败，很容易想出其他一百种方法来将这些信息发送给销售团队：报告，Slack 通知，列表导出，手动观察，或者使用 Zapier 通过几乎任何媒介发送警报。停机时间最多只能持续几分钟。
我的一位客户使用传统企业营销自动化平台（Marketo），该平台在过去几年中建立了 629 个自动化流程。当一些功能出现问题或需要调整时，150 多名员工中只有 1 人熟悉搞这个。每个问题都需要花费几天甚至几周的时间来解决，此时各种营销活动只能卡在这里。而且随着每个补丁的发布，整个系统只会变得更加复杂。
当那个人离开公司时，没有人可以管理这个系统。每过一周，就会出现新的问题，出现问题的速度比我们发现和解决它们更快。
为了避免营销活动陷入停顿，我急忙将客户从 Marketo 迁移到 HubSpot，这是一个更简单的平台，易于操作和排除故障。
迁移只花了一个星期。然而，在此过程中，另一个复杂的系统崭露头角：Salesforce。Salesforce 有 10 个自动化流程，其中有 100 多个组合操作，全部取决于 Marketo 中各种精确定时的自动化。它花了我们两周时间（是迁移时间的两倍）来了解这些流程，并将其与新的营销平台集成。
总体而言，这两个复杂的系统（Marketo 以及 Salesforce）导致营销团队的故障时间为六周，销售团队故障时间为三周。这还不包括他们在过去几年中经历的数周故障时间。如果我们不对基础系统进行全面升级，他们将来还将经历的数周故障时间。
最后，我安装的系统在提供所有相同功能的同时，进程数减少了 97％（从 629 减少到 20）。几天后发现的一个 bug 在 4 分钟内得到了解决。
这次经历使我在思考初创公司应该采用哪些原则，来避免复杂系统的陷阱。
淘汰和替换项目是痛苦的，也具有破坏性，即使从长期看它的收益可观。许多初创公司（如轮船那样）一旦启航，就没有时间和资源进行大修。
以下是我评估或实施新系统时遵循的三个原则：
功能需求不能证明系统复杂的合理性。如果一个复杂的飞行控制系统导致整个机队停飞，或者像 Marketo 这样的企业营销平台导致无法进行市场营销活动，那么复杂的系统对大家有什么好处？选择易于操作的工具，而不是承诺最多功能的工具。我对初创企业的常见建议是选择 HubSpot 作为其营销平台，而不是诸如 Marketo，Eloqua 或 Pardot 之类的企业平台。
复杂的想法导致复杂的实现。如果解释或掌握一个想法花的时间太长，那么它的实现将会很复杂，并且当不可避免地发生问题时，修复它所需时间将会很长。例如，一个新提议的销售流程需要一个小时来作展示，那将是一场噩梦，无论它看起来多么强大。
先考虑修改，再考虑堆砌。当出现新需求时，常规的做法是在已有系统上堆砌新功能。但是，可以尝试看下修改原有系统的核心是否可以满足新需求。与前文提到 Marketo 到 HubSpot 的迁移方案，短期可能会导致更长的（计划内）停机时间，但长期来看（计划外）停机时间会更少。
“……任何事物越简单，承担混乱的责任就越少，而且在遭受混乱时更容易修复。”
托马斯·潘恩（Thomas Paine），常识，1776年
毫无疑问，初创公司的旅程会碰到各种问题，就如一艘穿越地球的轮船。但是，如果你使用的系统足够简单，那么这些问题将不会让初创公司无所适从。
图片来源：
http://maritime-connector.com/ship/maersk-mc-kinney-moller-9619907/
原文：
https://www.gkogan.co/blog/simple-systems/
参考阅读：
本文作者 Greg Kogan，由高可用架构翻译。技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。
标签：apach 控制 展示 迁移 就会 崩溃 复杂 一段 下载
原文地址：https://blog.51cto.com/14977574/2546277
