关键要点
- 在生产环境中采用服务网等新技术将会对你和你的同事产生影响,注意这些影响,可以为利益相关者提供更好的支持。
- 明确你要解决的问题,并确定适当的验收标准。通过实验向各个利益相关者展示服务网格将如何让他们的生活变得更美好。
- 通过演示小规模的解决方案来吸引盟友和拥护者,并让他们知道服务网络将如何让这些东西变得更好。
- 对失败进行规划,并了解整个旅程中可能存在的风险,这样做实际上是在为成功做好准备。可以在早期收集关注点时进行这类规划,尽早解决每个可能的风险,它们就不会成为问题。
采用新技术并将其部署到生产中并不是一件简单的事情,而进行成功的发布并实现真正的改进更加艰难。在研究新技术(例如服务网格)时,了解你将面临的组织挑战与了解技术本身同样重要。不过,在将新技术推向生产环境方面,有一些清晰的步骤可以遵循。
首先,要搞清楚服务网格能够为你解决哪些问题。请记住,这不仅仅事关采用什么技术。一旦服务网格投入生产,就需要产生实际的好处,这是大前提。一旦确定了将要解决哪些问题,就可以进入成本模式了。无论成本是多少,要将服务网格投入生产都需要一定的投入。这项投入不仅仅涉及到你,也会影响到其他同事,因为他们需要学习新技术,甚至会打乱他们原先的任务计划。
我最喜欢的一句名言是“计划赶不上变化”。有多少次,生产环境的部署给你带来了惊喜?如果我们假设某些事情会出错,可以预先进行计划,这是“良好”工程实践的一部分。可惜的是,我们通常很容易看到事情进展顺利的一面,却忽略它们可能会出错的一面。某些事情可能出错,并成为未知数的一部分,这是很常见的。
还记得你要解决什么问题吗?现在是验证问题是否真正得到解决的时候了。即使你已经完成了技术方面的概念验证,产品与新技术在现实世界中所能起到的作用之间仍然存在很大的鸿沟。在逐步将产品部署到生产环境的过程中,花点时间进行验证,确保你是在做正确的事情,而不是在给系统造成伤害。
你正在解决什么问题?
你可以使用服务网格来解决很多问题,关键是要先确定最重要的问题是什么。这可以作为验收标准——这一切都值得付出的努力吗?那些有多种可能解决方案的问题就是好问题。如果某个问题的唯一解决方案是使用某种特定的技术,那么就好像你有一把锤子,在你眼里一切都是钉子。
服务网络能够让微服务所有者做他们最擅长的事情,而不是把精力浪费在应该由平台提供的东西上:如可观察性、可靠性和安全性。
实施微服务太难了,特别是为了找出为什么有些地方会出错而对服务间通信进行调试时,难度就更大了。通过与服务所有者合作,并让他们构建工具来提供所需的可见性,完全有可能解决这个问题。而使用服务网格可以以更少的工作量提供所需的可见性。试想一下,让服务所有者把更多的精力放在其他地方,并尽可能减少用于交互调试的时间,这将极大提升他们的效率。
在微服务领域,每个服务都会依赖很多其他的服务。当一个服务失效时,会发生级联效应,影响到栈里的其他服务。服务可能会陷入漫长的重试循环中,并凭空地消耗资源。如果不加以管理,一个小故障就有可能会成为足以引起用户抱怨的大问题。断路器提供了一种原语,用于中断那些冗长的循环重试,并防止发生级联故障。使用服务网格来解决这些问题,可以帮助服务所有者轻松构建更具弹性的服务。
到了某个时候,合规人员可能会找上门来,比如审计人员会要求加密流动的数据。更新和审计每个服务所需的工作量可能非常大,还有很多细节问题,比如证书的撤销和更新。使用服务网格,你就可以将所有这些问题变成运营问题而不是开发问题。使用一种方法来加密流动的数据,而不是在数百种方法中去选择,这样审计会进行得更加顺利。
对于美国教育和贸易出版商 Houghton Mifflin Harcuort 来说,他们要解决的是开发人员的敏捷性问题。工程总监 Robert Allen 说:“通过使用 Linkerd,团队可以继续推进工作合同并保持领先,而不会破坏他们的部署时间表。我们可以更多地解耦团队,变得更加敏捷。这是一个巨大的好处。“
有了具体的问题描述和明确的验收标准,就等于迈出了在生产环境中采用服务网格的第一步。在向其他人介绍服务网格的价值时,你就有了依据,在进行发布部署时,也有了可衡量的标准。你还可以解决其他的一些问题,这里提到的只是一些常见问题。
推广
很少有人是独自工作的,服务网不可能在没有其他人帮助的情况下投入生产。如果你没有(或不能)说服你的同事,告诉他们这样做的好处,那么走向生产的道路就会变得更加崎岖。带着正在解决的问题、定义好的验收标准以及对价值清晰的描述,你就有机会汇集到更多的盟友。将你的同事变成盟友,让他们一起为服务网格发声。组织的支持可以避免在走向生产的道路上可能会出现的一些失误。
每个利益相关者都有自己的关注点。开发人员可能更关心学习新技术和编写集成代码会超出他们的最后期限,管理团队可能更关注停机时间以及新的业务依赖。对于每一个利益相关者,有必要与他们谈谈,了解他们在关注哪些内容。他们的关注点有助于形成你的发布服务的方式,并提供一个平台来描述他们将获得的好处。
当你在为组织解决正确的问题时,也是在为所有利益相关者创造福利。在了解了每个关注点之后,就有可能提供一系列利益和激励措施,你就有机会向同事们解释解决此问题将如何更好地帮助他们。想象一下,安全团队在知道服务之间的加密是一致的时候一定会非常兴奋。
利益相关者的关注点
利益相关者
动机
关注点
平台工程师
-
统一所有服务的可见性
-
故障隔离
-
是否可靠?
-
是否会引入复杂性?
开发人员 / 服务所有者
-
移除复杂的交互代码
-
更容易并行运行服务
-
需要做出哪些修改?
-
需要学习复杂的技术吗?
安全团队
-
一致的 TLS 和认证 / 授权机制
-
策略
-
会降低安全性吗?
-
将引入哪些新的攻击模型
管理团队
-
更快的开发速度
-
更少的停机时间
-
在业务中引入了哪些依赖?
为失败做好规划
生产部署中每一步都有可能发生错误。为每个步骤做好规划,可以让整个过程更顺利地进行。即使在投入生产之前,也有可能会出现故障。在走向生产的每一步,对可能出现的风险都要倍加小心。它们可能来自任何地方,并且在你开始实现该过程的某个阶段之前,很多都是未知的。
不要好高骛远,应该要专注于你正在解决的问题。随着项目范围的扩大,风险和所需的时间也会随之增加。始终将注意力放在问题及其验收标准上,你就可以将范围蔓延降至最低,并让你充满信心地向前迈进。
从小处开始,并逐步做出改进。有时你会觉得这样做是不可能的,但你总归可以从一副大拼图中找出一小块作为入手点。通过将大项目分成小的可交付成果,可以消除大部分因为引入变更而引起的风险。你能想象在生产环境中一下子对所有重要的东西做出变更将会发生什么后果吗?
你是否曾经花时间解决风险?了解风险只是解决风险的第一步,你还要花时间来解决它们。清楚地传达应对风险的计划,并让同事们参与其中,这是将网格服务推向生产的关键策略。
向利益相关者展示服务网格的价值需要花很长时间?人们可能很难理解为什么将服务网格推到生产环境需要这么长时间。采用增量小步骤方式的好处是,这样不仅可以解决风险,还可以在每一步都进行清晰的沟通。每一小步骤都应该包括验证和沟通。
对每个增量小步骤进行回顾,看看哪些步骤走得很好,哪些走得不行,这也是一种有效的策略,可以让你的服务网络变得更好。通过回顾,你可以进行更好的诊断和沟通,准确地解释发生了什么问题。随着问题得到解决,验证就成为服务推出过程的一个组成部分。
对失败进行规划也意味着需要进行咎责。当出现问题时,你恰好正在修改系统,那么你就是第一个需要为之承担责任的人。但其实并不一 定总是你的错!被误解的技术经常因为它们不可能做到的事情而遭到指责。在发生这种情况时,需要伺机向你的同事做出说明,告诉他们服务网络能做什么以及不能做什么。
需要做出什么样的权衡?尝试解决每一个可能的风险让人感觉良好,但通常这样做是没有必要的。了解每种风险的潜在影响,其中有一些不太可能发生,但影响范围极大。其他风险有可能发生,要缩小它们的影响范围。缓解这些风险都需要特定的成本。一旦了解了缓解成本和风险的影响,就可以做出权衡,并进行清晰的沟通。经过沟通,并基于特定的风险做出权衡,有可能解除利益相关者特定的关注点。
结论
在生产环境中采用服务网等新技术将会对你和你的同事产生影响,注意这些影响,可以为利益相关者提供更好的支持。第一步是明确你正在解决的问题。选择一个你正在解决的真实问题,定义明确的验收标准,用于验证问题已被修复,并使用它来展示服务网格如何让生活变得更美好。
通过展示那些经过验证的解决方案获得更多的盟友,并告诉他们服务网络将如何帮他们把事情做得更好。因为这种显而易见的好处,他们才会支持你,这也就是你增加额外支持者的方式。你需要了解他们的关注点是什么,还必须接受变更始终伴随着风险的事实。将这些与对问题的清晰认识以及验收标准相结合,就有可能吸引更多的盟友到你的项目中。
最后,对失败进行规划,并了解整个旅程中的风险,这将为你的成功奠定基础。早期收集的问题有助于你进行失败规划。每个可能的风险都可以在早期解决,就不会变成问题。
Form3 公司将 Linkerd 推向了生产环境,并最终获得了他们可以信赖的成果。Ed Wilde 提到它与以前的系统之间存在巨大差异:
“Form3 很清楚一件事,就是现在的错误少了非常多。在以前的系统中,你会看到很多低级别的错误,但我们也只能接受现实。而现在,错误几乎消息不见了。事实证明,Linkerd 是你可以信赖的组件,而且非常可靠。它没有任何运营方面的问题。“
这不是一个万无一失的计划。但是,遵循这些步骤可以更好地将服务网格投入到公司的生产环境中。将服务网格投入生产不仅仅与技术有关,更重要的是要知道如何让同事们感觉到服务网格将为他们带来超能力。
关于作者
Thomas Rampelberg 是 Buoyant 公司的软件工程师及 Linkerd 服务网格的作者。在他的职业生涯中,他构建基础设施软件,让开发人员和运营人员能够专注于对他们来说更重要的事情上。在 Mesosphere 工作期间,他帮助一起创建了 DC/OS,这是很多财富 500 强企业使用的第一个容器编排平台。他已经转向该领域的下一个大问题:挖掘与服务间通信相关的洞见、提高它们之间的可靠性,并使用最佳实践来保护他们之间的通信渠道。
查看英文原文: How to Adopt a New Technology: Advice from Buoyant on Utilising a Service Mesh
评论