American Express 执行副总裁兼全球基础设施负责人 Matthew Liste 认为，成功的技术平台不应以组件数量衡量，而应看其隐藏复杂性并为开发者提供稳定、清晰体验的能力。在 QCon San Francisco 的演讲中，Liste 分享了他在 Goldman Sachs、JPMorgan Chase 和 American Express 构建关键系统平台和基础设施的20多年经验。
Liste 所谈及的平台服务着大量内部开发者；American Express 约有2万名用户，JPMorgan Chase 约有6万名用户。尽管其规模与云服务提供商不同，但他认为，对于任何构建供他人依赖的基础层的团队而言，基本原则都是相同的。
优秀的平台隐藏复杂性，但不隐藏发生了什么
Liste 首先将平台定义为一组集成技术，为在其上构建应用提供基础。他将平台比作供水和排污服务：只要系统正常运行，用户不会思考其背后的基础设施；但一旦发生故障，用户就会立即注意到它。
因此，平台体验应当直观易用，并使用共享且可互换的组件，例如统一的监控、身份和命名空间基础。这种可组合性使平台更像 Lego 积木，而不是一组彼此独立、只有通过额外努力才能协同工作的服务。
稳定性、安全性和可扩展性并非可选项
Liste 将其称为“三大支柱”：稳定性、安全性和可扩展性。所需的可用性水平取决于系统的价值；按照他的介绍，American Express 的信用卡授权系统可达到六个九和七个九的可用性水平，而其他系统则可以承受更多停机时间。
他还强调，初期成功可能掩盖扩展问题。一个起步阶段运行良好的平台，在使用量增加后可能出现瓶颈，并直接影响稳定性。因此，必须与使用者确定服务等级目标（SLO），并随着时间推移持续遵守，而不只是满足发布当天的要求。
持续更新并减少无差别工作
Liste 认为，保持平台更新是最困难、也最容易被推迟的任务之一。延期升级不断累积，可能使迁移到更新版本的成本大幅增加，并影响客户。他提出了一项名为0114的内部标准：通过自动化实现日常维护所需人员为零，能够升级整个机群的所有组件，在一天以内完成升级，并且每14天或更短时间进行一次更新周期。
他还呼吁不要重新构建已有且质量足够的组件。例如，与其编写新的 PostgreSQL 引擎，不如构建一个控制层，将每日备份执行到对象存储中；这正是满足监管要求所需的部分。关键在于专注于组织需要的价值，而不是最具工程吸引力的任务。
明确决策，并与使用者建立契约关系
平台所有者应当倾听客户意见，但不应执行每一项请求。资源有限，而不淘汰旧功能会积累技术债务，并阻碍更重要功能的开发。因此，平台必须有明确的“立场”：确定将支持什么、将停止支持什么，以及什么能够服务大多数用户。
这还包括通过 API、服务等级协议和流程正式划分责任边界。团队了解自己提供什么还不够；使用者也必须了解哪些事项由自己负责，以及平台不会越过哪些边界。Liste 将平台比作形状固定的组件：一个规模有限的团队不可能为每位客户构建一款定制产品。
实践体验：尽早尝试，并在不隐藏细节的情况下使用抽象
Liste 建议，在决定构建之后快速且反复地失败，同时在迁移过程中保护客户。他以早期尝试 Linux 容器和不同编排工具为例，最终团队转向 Kubernetes；尽早进行实验，使团队能够在等待某个解决方案成熟之前完成学习。
另一方面，抽象层不应隐藏底层发生的事情。可以提供用户界面、API 和 Infrastructure as Code，例如 Terraform，但必须提供足够的可见性和细节，以便理解故障，并在需要时调整行为。Liste 最后强调，应建立在开源项目和开放标准之上，使平台团队能够专注于集成和增值，而不是从零重新创建每一层。
为什么这些原则重要？
Liste 的观点的核心价值在于，它将平台建设从发布一组工具的项目，转变为一项长期运营承诺。平台一旦被采用，就会影响许多团队，因此可更新性、责任清晰度和退役管理，比快速新增功能更为重要。这些原则仍是实践经验的指导，而不是能够保证成功的统一标准；可用性水平、自动化范围和抽象选择，仍取决于系统的性质及其用户的需求。