构建基础设施平台

制定具有可衡量目标的策略

“我们没有实现目标”可能是您在为某事工作数周或数月后从利益相关者那里听到的最糟糕的事情。在基础设施平台领域，这是一个问题，可能导致您的高管决定放弃这个想法，并将预算花在其他领域（通常是更多产品团队，这可能会加剧问题！）避免这种情况并不难 - 制定一个目标和一个实现目标的策略，让您的所有利益相关者都参与进来。

制定策略的第一步是召集合适的人员来定义问题。这应该是产品和技术主管/预算持有者的组合，由可以帮助提供有关组织中正在发生的事情的背景信息的 SME 提供帮助。以下是一些好的问题陈述示例

我们的前 15 个产品团队中没有足够具有基础设施能力的人员，我们也没有资源来雇用我们需要的人员，这将使我们的产品上市时间平均延迟 6 个月

在过去 18 个月中，我们的产品已中断 160 小时，损失收入超过 200 万美元

这些问题陈述诚实地阐述了挑战，并且易于理解。如果您无法提出问题陈述，那么您可能不需要基础设施平台。如果您希望通过创建基础设施平台来解决许多问题，那么请列出这些问题，但选择一个作为驱动因素和重点。拥有多个问题陈述可能会导致对基础设施团队将取得的成就做出过多的承诺，并且无法实现；对具有不同结果的过多事情进行优先排序，并且实际上无法实现任何目标。

现在将您的问题陈述转换为目标。例如

为前 15 个产品团队提供他们可以轻松使用的基础设施，以平均减少 6 个月的上市时间

在未来 18 个月中将中断时间减少到 3 小时以内

现在，您可以制定一个策略来解决您的问题。以下是一些有趣的想法

我们强烈建议进行这两个环节。使用过去和未来的视角可以为实现目标和解决问题所需采取的措施带来新的见解。首先进行事后分析，因为我们的大脑似乎更容易在未来之前思考过去！如果您只有一次机会，那么进行一次未来倒推环节，因为未来的范围稍宽，因为未来尚未发生，并且可以促进更广泛的构思和跳出框框的思考。

希望通过完成这两个环节中的一个或两个环节，您会获得一份非常实用的清单，列出实现目标需要采取的措施。这是您的策略（旁注：愿景和目标不是策略！！！请参阅理查德·P·鲁梅尔特撰写的《好策略坏策略》）。

有趣的是，您可能会决定组建一个团队来构建基础设施平台并不是您的策略，这很好！基础设施平台并不是每个组织都需要的东西，您可以跳过本文的其余部分，去马丁博客上阅读一些更有趣的东西！如果您有幸在您的策略中创建基础设施平台，那么请做好准备，获得更多出色的建议。

找出客户的需求

当我们敏捷主义者听说一款产品已经构建完成，但没有用户时，我们翻了翻白眼，知道他们一定没有进行适当的用户研究。因此，您可能会惊讶地发现许多组织构建了平台基础设施，但无法让任何团队使用它们。这可能是因为一开始就没有人生产需求。也许您构建基础设施产品太晚了，他们已经构建了自己的产品？也许您构建得太早，他们忙于其他积压优先级而无暇顾及？也许您构建的内容不完全符合他们的用户需求？

因此，在决定构建什么之前，请像对待面向客户的产品一样进行探索。对于那些以前没有做过探索的人来说，探索是一种（通常）按时间限制的活动，一群人（理想情况下是将构建解决方案的团队）尝试了解他们构建某项内容的问题空间/原因。在探索期的末尾，团队应该了解基础设施产品的用户是谁（可能有多种类型的用户）、用户有什么问题、用户做得好的事情以及团队将构建的基础设施产品的一些高级想法。您还可以调查其他可能有用的事情，例如人们正在使用什么技术、人们以前尝试过什么没有成功、您需要了解的治理等。

通过将我们的问题陈述定义为战略工作的一部分，我们了解了组织的需求。现在我们需要了解这与我们的用户需求有何重叠（我们的用户是产品团队 - 主要开发人员）。确保在考虑战略的情况下开展活动。例如，如果您的战略侧重于安全性，那么您可能会

• 突出显示安全漏洞的示例，包括导致这些漏洞的原因（如果您进行过事后分析，请使用事后分析中的信息）
• 采访参与安全工作的各种人员，包括安全主管、技术主管、技术负责人、开发人员、质量保证人员、交付经理、业务分析师、信息安全人员。
• 使用事件风暴等研讨会绘制产品的现有安全生命周期。在您希望基础设施平台提供服务的时限内，尽可能与尽可能多的团队一起冲洗并重复。

如果您只在探索中做一件事，请进行事件风暴。让一个团队或一群将成为您客户的团队在有物理墙的物理房间中或在有虚拟白板的电话中。在此图表上绘制一个有开始和结束点的时序图。对于基础设施平台探索，从项目开始到在生产中对用户上线进行映射可能很有用。

然后要求每个人将从项目开始到在生产中上线的所有内容映射到一种颜色的便利贴上。

接下来要求团队用另一种颜色覆盖任何痛点、令人沮丧的事情或并不总是顺利的事情。

如果您有时间，可以覆盖任何其他信息，这些信息可能有助于您了解潜在用户面临的问题空间，例如所使用的技术或系统、不同部分所需的时间、可能参与不同部分的不同团队（如果您决定在会议后深入研究某个领域，此信息很有用）。在会议期间和会议之后，促进者（即进行探索的团队）应确保他们了解每个便利贴周围的背景，在需要时深入研究并进一步调查感兴趣的领域。

一旦您完成了一些探索活动并了解了用户交付面向客户的产品所需的内容，那么优先考虑哪些内容可以最快地提供最大价值。有大量的在线资源可以帮助您塑造您的探索 - 一个很好的资源是 gov.uk

尽早让用户参与

“这行不通”可能是你最不想听到的关于你的基础设施平台的话，尤其是在你已经做了所有正确的事情并且真正理解了你的用户（开发者）和他们的最终用户需求之后。事实上，让我们来问问你是如何陷入这种境地的。当你将正在创建的基础设施产品分解为史诗和故事并真正开始深入了解细节时，你和你的团队将对产品做出决策。你做出的某些决策可能看起来很小而且无关紧要，所以你不会向你的用户验证每一个小细节，而且你当然不想在每次必须定义一个小实现细节时减慢或停止你的构建进度。顺便说一下，这是可以的！但是，如果你几个月没有收到关于你所做的这些小决策的反馈，而这些决策最终构成了你的基础设施产品，那么你正在构建的内容可能无法为你的用户正常工作的风险将会越来越大。

在传统的产品开发中，你会定义一个最小可行产品 (MVP) 并获得早期反馈。我们一直都在努力解决的一件事——尤其是在基础设施平台方面——是如何知道什么是“可行的”产品。回想一下你构建基础设施平台的原因，可能是当你降低了安全风险或缩短了团队的上市时间时，它就是可行的，但是如果你不向用户（产品团队中的开发者）发布产品，直到它从这个定义中“可行”，那么“这行不通”的回应就变得越来越有可能。因此，在考虑基础设施平台时，我们喜欢将价值最短路径 (SPV) 视为我们希望我们的第一个用户加入的时间。价值最短路径听起来就像它的意思，无论对你的团队、你的用户、你的组织还是混合，你都能获得价值的最早时间。我们喜欢 SPV 方法，因为它可以帮助你不断思考学习的最佳时机并推动更薄的切片。因此，如果你还没有注意到，这里的重点是尽早让用户加入，以便你可以找出什么有效，找出什么无效，并决定你应该将你的下一个开发工作投入到哪里，以改善这个基础设施产品，以便在你的组织中更广泛地使用。

传达你的技术愿景

也许毫不奇怪，这里的关键是确保你尽早阐明你的技术愿景。你希望防止多个团队构建与你相同的东西（这会发生！）。确保你的利益相关者知道你在做什么以及为什么。这不仅会建立对你的解决方案的信心，而且是获得早期产品洞察的另一个机会！

你的愿景不必是一些高保真系列的 UML 杰作（尽管那里有很多常见的建模格式非常有用）。拿一块白板和一个马克笔/可擦记号笔，尽情发挥。当你试图传达想法时，事情会变得混乱，因此能够轻松擦除并重新开始是关键！尽量避免立即跳入 CAD 程序来绘制此类图表，它们最终会让你远离创作过程。

话虽如此，有一些有用的工具足够轻量级，可以在此阶段实施。例如

一旦你能够构建你的技术愿景，就使用它来传达你的进度！将其带到你的冲刺演示中。使用它来指导与你的团队的设计对话。带着它去你的下一次威胁建模练习中进行一次短途旅行。我们在这篇文章中仅粗略介绍了 C4 图表。有很多很棒的文章深入探讨了这一点 - 要进行探索，请从这篇文章开始 InfoQ 上的文章。

不要止步于此！请记住，尽管上述技术将有助于指导现在的对话；软件是一个生命体，在你退休后可能还会存在很长时间。能够将你的技术愿景传达为一系列能够指导你的手的决策是另一个有用的工具。

设身处地为用户着想

如果您在组织中拥有任何内部工具或服务，并且您发现使用它们非常容易且轻松，那么您很幸运！根据我们的经验，当您获得想要的东西时，这仍然令人惊讶。因此，想象一下一个世界，您花费时间和精力来构建您的基础设施平台和团队，他们会说“哇，这太容易了！”。无论您出于何种原因构建基础设施平台，这都应该是您的目标！如果您必须强制使用您的基础设施产品，事情并不总是那么顺利，因此您将不得不努力让人们愿意使用您的产品。

在常规产品开发中，我们可能有具备用户研究、服务设计、内容撰写和用户体验专家等能力的人员。在构建平台时，很容易忘记填补这些角色，但如果您希望组织中的人员喜欢使用您的平台产品，那么这一点同样重要。因此，请确保您的团队中有人负责基础设施产品的端到端服务设计，无论他们是开发人员、BA 还是 UX 人员。

入门的一个简单方法是绘制您的用户旅程。我们以入职为例。

即使不了解此旅程的背景，也有一些需要注意的事情，这些事情可能表明用户体验不太友好

• 开发人员用户和您的平台团队之间的交接
• 有一些循环可能会让开发人员用户在入职过程中退缩
• 缺乏自动化 - 平台团队正在做很多事情
• 我们的开发人员用户需要完成 9 个步骤才能完成入职，期间可能会有等待时间和延迟

理想情况下，您希望您的入职流程如下所示

如你所见，平台团队不参与入职，因此它完全是自助服务，我们的开发人员用户只需遵循三个步骤。要为你的用户提供如此出色的体验，你需要考虑可以自动执行什么以及可以简化什么。简单的用户体验和简单的代码库之间会有权衡（如“不要把事情复杂化”中所述）。两者都很重要，因此你需要一位强大的产品负责人，他可以确保这种权衡符合你最初提供平台的原因，即如果你正在构建一个平台，以便你可以更快地将产品推向市场，那么一个无缝且快速的入职流程非常重要。

实际上，你的入职流程可能更像是这样

尤其是在你发布你的 MVP 时（参见上一部分）。将这种思考应用于团队在使用你的产品时可能必须经历的任何其他交互或流程。通过创造出色的用户体验（当然，还要拥有一个基础产品人员想要的产品），你不仅应该拥有快乐的用户，还应该在你的组织内拥有良好的宣传，以便其他团队想要加入。请不要忽视此建议，并让自己陷入组织强制使用你的噩梦般的基础设施平台并且所有开发人员团队都感到悲伤的境地 :(

不要把事情复杂化

所有软件都是有缺陷的。不要对事情过于悲观，但你编写的每一行代码都极有可能很快过时。每个 If 语句、设计模式、每一行配置都有可能中断或引入奇怪的副作用。这些可能表现为难以重现的错误或全面中断。你的平台也不例外！仅仅因为你的产品没有花哨的、响应式的 UI 或高可用性 API 并不意味着它不会出现错误。如果正在构建的内容是一个平台，其他团队正在其上构建自己的服务，会发生什么情况？

当你正在开发一个其他团队依赖的基础设施平台时；你的客户的开发环境就是你的生产环境。如果你的平台出现问题，你最终可能会带着其他人一起倒下。你真的不想冒着将停机时间引入其他团队的开发流程的风险。它会侵蚀信任，甚至最终损害你试图帮助的人际关系！

软件中出现错误的主要（且非常阴险的）原因之一与复杂性有关。支持的功能越多，平台尝试执行的操作越多，可能出错的地方就越多。但是平台团队中出现复杂性的主要原因是什么？

康威定律，对于那些可能还没有非常亲密地了解的人来说，指出组织倾向于设计反映其自身内部沟通结构的系统。从软件角度来看，这意味着系统通常可能会设计为具有某些“警告”或“解决方法”，这些警告或解决方法适用于组织历史中的某个时间点。虽然这不一定是一件坏事，但它很容易影响我们在现场做出的设计决策。如果你正在构建一个 API，那么团队内部可以轻松处理这些类型的设计决策。但是，如果你正在为许多不同的团队（及其众多不同的细微差别）构建一个具有许多不同集成的系统，这将成为一个更大的问题。

那么，在编写大量与业务流程紧密耦合的细粒度组件与构建一个能够支持组织发展的平台之间，最佳点在哪里？

一般来说，作为团队编写每个组件都是需要衡量、维护和支持的另一件事。当然，你可能会受到现有架构债务、合规性约束或安全保障的限制。我们在这里的收获是，在为解决方案引入另一个组件之前三思而后行。开发的每个活动部分都是对后期支持的投资，也是另一种潜在的故障模式。

衡量重要内容

一篇关于构建更好的基础设施平台的文章，如果没有关于衡量事物的说明，将是不完整的。我们之前提到过确保使用可衡量目标定义策略。那么成功是什么样的？这是你可以用代码提取的东西吗？也许你想通过减少运营摩擦来增加用户的部署频率？也许你的真正目标是提供一个稳定且安全的工件存储库，团队可以依赖它？花点时间看看你是否可以将这个成功指标转化为一个轻量级仪表板。能够庆祝你的胜利对团队士气和帮助在整个组织内建立对平台的信心都有极大的好处！