【翻译】什么是技术战略？

几年前，我开始了一个梦想的项目。客户联系我们，让我们设计和建立一个绿色的云原生平台。他们有一个新的和令人兴奋的硬件设备，将收集大量（很多！）数据并解决无数真正有趣的问题。他们拥有领域和硬件的专业知识，而他们需要的是我们的知识和技能来建立所需的云原生平台。

正如我提到的，这是一个梦想的项目。尖端技术、机器学习、大数据，以及从头开始设计和建立一个完全云原生平台的机会。在接下来的几个月里，这正是我们所做的。微服务、容器、事件驱动、Kubernetes、高可用性。这很美好。

当我们试图从数百个潜在的用例中确定哪一个我们将首先处理时，警告信号开始出现。优先级和重点开始迅速转移。最后，我们的客户给我们带来了 "好消息"：他们已经为这个平台找到了一个实际的客户。我们能不能在他们大楼里的一台服务器上运行这个系统，这台服务器不允许有互联网连接......？

我们的 "完美架构 "是没有用的。而且这也不是客户的错。他们要求一个现代化的云原生系统，但这并不是他们所需要的。我们没有与他们的业务目标保持一致。我们从来没有深入了解他们真正的目标是什么。

这只是一个例子，说明为什么你在建设之前需要一个技术战略。

技术战略是什么，不是什么

技术战略是任何企业的关键部分。虽然你很难找到不同意这种说法的人，但如果你四处打听，你会得到许多不同的答案：什么是技术战略？

战略本身就是一个经常被误解或误用的术语。此外，在科技界，事情的发展速度很快，跳过确定你的实际战略的艰苦工作，而依靠复制别人的技术、选择和方法，也许是模仿谷歌、Netflix等顶级科技公司（这被称为备忘录复制，或"我也是 "战略）。 这似乎是一个合乎逻辑的方法：如果另一家公司在某套技术上取得了成功，那么它不应该对我们也有效吗？但这样做，我们就犯了一个严重的错误，跳过了技术战略的第一个，也是最重要的部分。

为什么我需要一个？

"如果你不知道你要去哪里，你很可能会在别的地方结束"。

- 劳伦斯-J-彼得，教育家和 "等级制度学家"

在开始定义技术战略或任何任务之前，了解你为什么要这样做是很有用的。创建一个战略的背后有三个主要目标：

• 统一。一个明确的技术战略是确保每个人都在同一起跑线上的最好方法。我们经常认为我们都同意我们要去哪里，为什么，但一旦我们开始定义它，我们就会意识到每个人都有自己的解释。
• 重点和方向。 战略使我们清楚地知道我们在做什么，同样重要的是我们不做什么。它应该被传达给每个人，并作为一种持续的参考。不仅仅是执行战略的人，而是所有利益相关者。
• 实现自主性和分布式决策。我们雇用聪明的人，并付给他们可观的报酬。我们希望他们能够独立做出决定并取得进展。然而，没有指导的自主权会导致混乱。一个明确的战略给团队提供了正确的方向，同时为创造力留下了空间。

那么，WTF是什么？

解释技术战略的最简单方法是 "它定义了你将如何利用技术来支持你的业务目标"。现在，这当然是假设你已经有了一个总体战略，并且已经确定了你的业务目标是什么。如果不是这样，你就有比担心把你的技术战略放在一起更大的问题了。

以这些业务目标为出发点，你的技术战略应该确定哪些技术模式能够最好地帮助你克服挑战和实现业务目标。它需要足够高的水平，以便你在实施过程中留下决策和调整的空间。但是，它也必须足够具体，以提供一个明确的方向和不含糊，这样不同的团队就不会以不同的方式来解释你的战略。

技术战略的组成部分

根据作者Richard Rumelt在他的《好战略/坏战略》一书中对战略的定义，你应该有三个核心部分（他称之为 "内核"）来构成你的战略。

• 诊断。你所面临的基本或主要挑战是什么？
• 指导性政策。你解决上述挑战的总体方法是什么？
• 连贯的行动。 列出你的组织或团队可以采取的初步、具体、短期的行动。

诊断可以是技术性的，但同样地，它必须从商业目标中产生。例如，设想一个企业软件公司，它的业务目标是减少提供价值的时间。该公司目前每六个月发布一次新版本，并确定它必须能够每天发布功能和修复，以满足其客户并保持竞争力。

如果你是该组织的一员，你将对你目前的技术栈和流程进行分析。你确定了实现这一目标的最大障碍；你的诊断是软件的复杂和紧密耦合（单体）架构，由于复杂的代码库、未知的依赖关系和耗时的测试，即使是微小的错误修复也需要数周时间来部署。

接下来，必须定义指导性政策。这应该为你如何解决这个问题提供一个明确的方向。每当有争论或讨论的时候，参考指导性政策应该有助于决定哪种方法是最好的。 回到我们上面的（简化的）例子，在这种情况下，指导政策可能是"在拥抱自动化的同时使团队自主"。这样的政策可能会导致架构迁移到较小的、解耦的服务中，这些服务由一个团队拥有。

最后，我们要定义一致的行动。这就是我们变得具体的地方。为了开始执行我们的战略，首先要进行的具体任务是什么？

糟糕的技术战略

糟糕的技术战略有很多形式。我见过很多，自己也做过一些。根据我自己的经验，这些是最常见的不良技术战略形式：

与业务不一致

正如我前面提到的，不良技术策略的主要原因是没有与你的业务目标保持一致。不管你设计的架构有多优雅，也不管你使用的技术有多现代。如果你所构建的东西不能支持你的组织试图实现的目标，你就构建了错误的东西。在这种情况下，拥有现代的云原生工具和实践只会帮助你更快地构建错误的东西。这其实并没有什么帮助。

没有正确的架构，也没有理想的技术栈。这取决于你的使用情况。你在建造什么？你的限制条件是什么？谁是你的用户？

跟随潮流

在科技行业，我们经常犯的错误是对新的和闪亮的东西的吸引。我们阅读博客或观看会议谈论最新的技术，以及FAANG（Facebook、Amazon、Apple、Netflix和Alphabet/Google）公司之一是如何利用它来获得巨大利益的。我们想跟随行业趋势，担心我们的技术栈被视为传统。但我们中很少有人以Netflix的规模运行，所以我们真的需要和他们一样的技术吗？

这种方法有明显的风险。我们已经不止一次看到这种模式：向一个新的技术堆栈或平台进行艰难而昂贵的迁移，完成后，你并没有比开始时更好（通常更差）。除此之外，你现在还被锁定了：你被捆绑在一个特定的技术上，也许还受制于供应商的合同，而且你不可能轻易摆脱这种关系。

即使你已经正确地确定了一项可以解决你的具体挑战的技术，你的战略也应该围绕这些挑战而不是具体的技术来制定。否则，你就有可能失去你最初的动机。

解决不存在的问题

公司在制定技术战略时遇到的另一个常见的陷阱是试图解决一个他们实际上并不存在的问题。这通常采取预先优化的形式--即解决一个你期望在未来出现的问题，或者对你目前的系统和其中的挑战有一个不正确/不完整的看法。后者是一个比较容易纠正的错误。

为了确保你对当前的挑战有一个准确的看法，必须进行必要的分析。在这里，一些真正有帮助的练习包括价值流图。

例如，如果你想减少一个新产品功能从想法到生产所需的时间，一个常见的寻求改进的地方是你的构建管道。也许通过引入一些聪明的技术，你可以将软件的构建时间减少一半！这似乎是一个巨大的收获，但这并不意味着你可以将它变成一个新产品！这似乎是一个巨大的收获，但如果你的构建被部署到一个暂存环境，而QA团队需要一个星期的时间来进行手工测试呢？在这种情况下，减少构建时间是徒劳的。执行价值流图的工作可以快速而容易地确定你应该把你的努力集中在哪里。

更具挑战性的是建立一个战略，以解决你预期会进一步遇到的问题。当然，战略应该预见到未来，但我们经常误判明天的挑战是什么。一个常见的例子是先发制人地建立规模。

我们都愿意相信我们的平台和产品会在某个时候达到Netflix般的规模，但这很少是现实。即使你的流量确实大幅增加，你是否有信心你会扩展到正确的部分？你是否已经知道你的问题是横向扩展还是纵向扩展？这些都是事先难以回答的问题。

我所看到的解决这个问题的最好方法是建立旨在改变的系统。进化的架构，有明确的接口，完全自动化的CI/CD管道，以及全面的测试覆盖，这些都是很好的投资，可以让你在真正遇到挑战时进行必要的改变。

3年计划

在大型企业组织中，一个常见的执行策略是让一群架构师坐在一个房间里，定义整个系统的重新设计，并提出一个三年计划（总是三年），然后强迫开发团队去实施。然后，无一例外地，问题出现了，最后期限滑落了，就像芝诺二分法悖论的一些验证，该计划从未完成。

这些类型的计划不起作用的原因有很多，计划设计者和计划执行者的分离是一个重要原因。这种方法的另一个重要错误是过于具体，尤其是在这么长的时间范围内。一项战略并不是要定义所有要做的事情。它给你一个明确的目标（诊断），一个一致的方法（指导性政策），并且只定义了最初的一套行动。一旦这些初始行动开始，我们就已经有了新的信息，这些信息必须被纳入我们的计划，并帮助确定后续行动。

良好的技术战略

定义战略最具挑战性的部分之一是在方向和灵活性之间取得适当的平衡。如果你没有给出足够的方向，你最终会得到一份任务书。在这种情况下，人们要么选择以符合他们思维的任何方式来解释你的战略，要么就一动不动。无论哪种方式，这都不是你想要的结果。然而，如果你不为灵活性留下空间，那么你就剥夺了那些最接近地面的人做出任何决定的机会。你也不允许自己对新信息做出反应。 一个好的战略必须具有适应性。

我们发现有两种技术可以帮助实现这种平衡。首先是建立一个强有力的总体指导政策。这可能包括一个原则清单。例子可以是：

• "你建立它，你运行它"。
• "自动化一切"。
• "为改变而设计"。
• "利用管理服务"。

当需要做出选择时，你的原则将作为一个指南。这给最接近行动的人留下了做决定的空间，但也为哪些决定与整体战略相一致提供了强有力的指导。

对原则的一个很好的测试是，它们可以识别出不遵循整体战略的潜在选择。例如，如果我们采用 "利用管理服务 "的原则，那么选择托管我们自己的SQL数据库（同时在公共云上运行）显然会违反这一原则。

第二个技巧是有具体的、短期的行动。我们看的时间越远，我们知道的就越少。技术和工具会改变，行业会调整，我们的市场会转变，而我们自己也会获得新的见解。

我们最自信的时刻就是现在。这就是为什么我们在开始时明确界定要采取什么行动是有意义的。然而，一旦我们开始采取这些第一步，情况就会发生变化。我们必须留有余地，以便根据我们所学的东西进行调整。

反馈回路

我们已经强调了技术战略来源于商业目标是多么的关键。然而，这往往不是一条单行道。技术引导业务也是可能的，而且往往是可取的。

技术决定了什么是可能的。当把整体业务战略放在一起时，你会考虑到什么是技术上可行的。例如，一家希望开发远程驾驶系统的公司将需要极低的延迟。以前这是不可能的，但随着5G网络的引入，这成为可能。科技领域的变化很快。当新的信息、工具或技术出现时，这些信息应该被反馈到你的最初目标中。

通过现代的云原生系统，我们可以获得对产品和用户的关键洞察力。通过利用部署技术，如A/B测试，功能标志，以及通过分布式跟踪和可观察性平台的高级指标，我们可以学到很多东西。运行实验变得便宜而容易。这些洞察力也应该定期反馈给企业，以便有可能调整方向。

总结

拥有一个坚实的技术战略对每个公司都很重要。在竞争激烈的市场中，它可以成为差异化的因素。

建立一个好的技术战略是一项艰苦的工作。它需要做出艰难的决定和权衡。简单地看看别人的成功经验，并从中复制，可能是非常诱人的。虽然从别人的经验中吸取教训是很重要的，但你不会找到另一个与你有相同挑战、历史、目标和限制的组织。

技术战略远不止是所使用的技术。一项战略必须从你所面临的具体挑战开始。你要解决的问题是什么？一旦你确定了这一点，你就可以继续确定你的指导政策，以及你将在短期内采取的具体行动。 你的组织文化也起着至关重要的作用，正如IBM的Holly Cummins之前在WTF Is Cloud Native的博文中所说。

在制定技术战略时，有很多陷阱。但是，如果你坚持关键的组成部分，与你的业务目标保持一致，并允许有灵活性，你就有很大的机会取得胜利。