Daniel Bryant：面向开发者与架构师的平台工程

我的三个核心观点是：平台工程需要产品思维，把开发者视为客户；平台架构与应用架构相互影响；良好的 API、抽象和自动化对整个系统都很重要。

回顾开发经历，我记得自己使用过 Heroku、Cloud Foundry 等环境，后来又面对云原生工具带来的认知负担。开发者希望构建、交付和运行软件，而不必亲自掌握每一个运维细节。

开发者门户是平台的一部分，并不是平台的全部。我喜欢把平台定义为由自服务 API、工具、服务和知识组成的内部产品。软件开发仍然需要团队合作：目标是减少不必要的协调，而不是消除人。

平台需要业务目标。我把它们概括为提高速度、降低风险和提升效率，再针对不同受众使用他们能理解的语言。开发者可能关心好用的抽象，而高管可能关心交付和风险。

我使用一个三层模型。在应用层，开发者通过门户、命令行或声明式配置等接口组合并交付应用。基础设施层提供和维护底层构件，通常使用基础设施即代码。

两者之间是平台编排层：它把基础设施能力转化为开发者可以使用的服务和工作流。每一层都有自己的生命周期，需要对自身价值流负责；平台团队不应只是处理工单的瓶颈。

应用团队交付可观察的业务价值，平台团队提供服务、补丁和改进，基础设施团队维护自己的基础。清晰的责任归属使每个团队都能改善自己的部分，而不必每次变更都依赖临时交接。

Team Topologies 描述了团队互动的多种方式：协作、促进和以服务形式提供能力。每种方式都有适用场景。设计良好的服务边界可以降低协调成本，同时让提供者获得采用情况和用户满意度的反馈。

API、抽象和自动化把各层连接起来，但信息流是双向的。开发者受益于合理默认值，同时也需要对底层基础设施有足够理解，才能判断行为和限制。

我记得早期的单体应用中，用户界面的变化可能一路传到数据库；企业级抽象有时还隐藏调用是在本地还是远程执行。发生故障时，这些隐藏细节让诊断很困难。

六边形架构提供了一种通过端口和适配器将核心与外部依赖分离的方式。松耦合有助于独立测试组件和演进实现，但架构仍需要符合组织的实际需求。

我讨论了 Netflix OSS 以及向应用提供平台能力的库。一个困难是不同语言的实现和语义可能逐渐偏离。Sidecar 和 Dapr 等工具提供了另一种通过更清晰 API 暴露能力的方式，但底层服务仍然需要存在。

我倾向于同时用“黄金积木”和黄金路径来思考。单一规定路线可能变成黄金牢笼；可组合、受支持的构件能让团队选择所需的数据库、内部服务和交付工作流，同时保留有用的默认值。

微服务可以形成高内聚、松耦合的服务，但需要快速配置、监控和部署。有些组织在具备这些能力之前就采用了这种架构。我见过团队起初进展很快，后来却难以理解和运维整个服务群。

Log4Shell 事件向一些团队展示了责任归属问题：他们不知道存在漏洞的依赖运行在哪里，也不知道如何协调大量服务的升级。问题不只是编写基础设施代码，还包括知道谁能维护和更新它。

Heroku 和 Cloud Foundry 提供了有用的铺设路径，虽然也有权衡。我把生成的基础设施比作一只小狗：创建只是开始。必须有人负责维护、安全变更以及第一天之后发生的事情。

工作负载定义和平台编排可以表达应用需要什么，并让平台管理基础设施和策略。我还提到单元架构：它有助于组织服务群，但跨单元的路由与升级仍需要仔细工程设计。

为 API、命令行和用户界面设计控制平面。我经常看到太多平台逻辑被放进门户，导致行为与单一界面耦合，也可能在其他地方重复。API 优先的设计可以一致地服务不同接口。

即使背后的基础设施、策略和合规要求很复杂，初始接口也应保持简单。渐进式披露让用户先使用少量选项，需要时再展开高级选项。简单不应意味着隐藏所有有用细节。

开发者不希望面对无法解释的魔法，即使自动化很有价值。耦合、内聚、可组合性和抽象泄漏对平台与应用代码同样重要。如果用户依赖未记录的实现细节，平台就难以修改。

度量应将平台健康状况与结果联系起来。我区分采用率、入职时间和提交拉取请求所需时间等领先指标，以及反映交付表现的滞后指标。单一数字无法概括开发者体验或平台创造的价值。

我把 DORA、SPACE 和 DevEx 框架作为讨论交付与开发者体验的互补方式。平衡的框架有助于团队避免只优化一个指标，却忽视摩擦、质量或人的体验。

最后，要把开发者当作客户，设计良好接口，并追求规模化情况下的速度和安全。平台与应用架构共同演进；可组合构件和清晰的责任归属使两者都更容易改进。