注意平台执行间隙

成功平台策略的先决条件

开发人员生产力平台越来越被认为是管理工程团队认知负荷和减少新特性上市时间的一种方式。然而,为了成功执行平台战略,组织需要培养一些基本能力。平台团队需要将平台视为一种软件产品,需要与用户进行对话,关注可靠的运营,以及一个健康的团队环境。

2021年4月27日


Cristóbal García García图片

Cristóbal的职业生涯主要集中在IT服务提供商行业的领先工程团队。两年前,他加入Thoughtworks,在产品和金宝搏亚洲体育博彩基础设施团队工作。他关注的领域是分布式系统、工程实践和软件开发过程,以及不时出现的数据科学和编程语言。188比分直播完整手机版

克里斯·福特照片

Chris在Thoughtworks做了10年的顾问,目前是Thought金宝搏亚洲体育博彩works西班牙公司的技术主管。他的专业知识包括函数式编程、持续交付、数据网格和伸缩工程组织。


软件开发组织的领导者承188比分直播完整手机版受着巨大的压力,以确保他们的员工把时间花在增值活动上。实现这一点的一种方法是使用SaaS将不属于其组织核心业务的功能外包出去。另一种方法是将许多团队和服务所需的基础设施功能合并到一个数字平台(这可能反过来依赖于SaaS和云提供商)。通常,内部平台是内部开发和外部采购能力的组合。

Evan Bottcher对数字平台的关键元素有一个很好的描述:

数字平台是自助api、工具、服务、知识和支持的基础,这些都被安排为引人注目的内部产品。

--埃文Bottcher

开发人员生产力平台的目的是让构建最终用户产品的团队专注于他们的核心任务。平台服务的例子包括像管道基础设施这样的交付服务、像Kubernetes集群这样的应用服务、像监控这样的运营服务以及像漏洞扫描软件这样的安全服务。一个内部的平台团队通常会使用云提供商和其他供应商提供的工具和服务,并对其进行托管、调整或扩展,以便于他们的软件开发同事能够方便地使用它们。目的不是改造商用功能(世界不需要另一个本土Kubernetes)但桥之间的差距,你可以买到真正需要的是什么(你的团队可能欣赏一个简化Kubernetes经验,利用假设你的基础设施和更易于管理)。

这些服务通常依赖于基础设施,但我们将其视为实现细节。我们对平台有一个广泛的看法,其中包括任何内部提供的促进工具开发人员效率.按照Evan的定义,我们将文档和支持视为平台的重要方面。我们认为,对平台的看法更可取的是“它是干什么的”,而不是“它是如何制造的”,因为向内部团队提供平台服务是一种减少摩擦的制度化方法。对于平台工程师来说,对于减少摩擦的最佳方法保持开放的心态是义不容义不容当的。有些日子将是基础设施的供应。其他时候,它可能会让构建脚本更容易使用,或者帮助研讨会帮助团队定义他们的sslos。

如果执行得当,平台战略有望降低成本,并让产品开发团队专注于创新。当出现问题时,平台的问题会直接传递给整个软件开发组织。188比分直播完整手机版在我们与客户的合作中,我们注意到在构建内部平台方面存在大量的行业热情(或称为炒作),但我们也看到了一个潜在的执行缺口,需要解决。

一名乘客在离开一列标有“炒作列车”的列车时,上面还写着“注意空隙!”

请注意炒作列车和平台之间的差距。

建立一个有效的平台和一个组织来支持它是一个值得但雄心勃勃的目标,它需要比直接为服务提供基础设施更成熟。和其他雄心勃勃的技术演习一样,例如,微服务体系结构188比分直播网 坚持原创这些基本能力是持续成功的先决条件。在你踏上平台之路之前,它们不一定都要成熟,但你必须有开发它们的欲望和决心,否则你的数字平台不太可能为你投入的大量投资带来回报。

业务价值

决定使用内部开发人员生产力平台是一个经济的决定。支持这一观点的理由是,效率、质量和上市时间带来的好处,超过了其构建和演变过程中产生的财务、人才和机会成本。如果你不能清楚地表达出你的平台的商业案例,那么你就不能负责任地采用它。你的计算必须考虑到商业服务的能力,因为除非你的平台提供商业服务不能提供的功能、针对你的背景的特殊性或便利性,您最好还是把它留给市场,避免维护负担——毕竟您的平台策略依赖于减少无差别的工作量,而不是增加它!

决定建立一个数字平台只是你的责任的开始,以证实你的数字平台的商业价值。平台策略的动机在高层次上可能是引人注目的,但在决定提供哪些功能以及如何提供这些功能时,还涉及许多精细的决策。让事情变得更复杂的是,随着技术的进步、组织的需求的发展、云提供商和其他供应商发布新的改进的产品来与您自己的解决方案竞争,您的功能的业务合理性将会随着时间的推移而改变。

要向你的组织交付承诺的价值,计划更大比例的持续改进和产品创新,而不是面向终端用户的产品。为了保持平台的可管理性和成本的可控,与可操作性相关的项目必须在待办事项列表中占据重要位置。比起一连串的新特性,用户更喜欢一致性、稳定性和可靠性。此外,您提供的每一种产品,总有一天会被市场上的新产品、内部构建的继任者所取代,甚至会将这种能力的责任移交给您的产品开发团队。弃用是平台产品生命周期的一个基本部分,不考虑它可能会破坏您希望通过首先提供它而获得的业务利益。

产品的思考

您必须永远不要忘记,您所构建的产品是为了取悦他们的客户——您的产品开发团队。任何阻碍开发者顺利使用平台的因素,无论是API可用性上的缺陷还是文档上的缺口,都会对平台的商业价值的成功实现构成威胁。优先考虑开发人员的经验——没有人使用的产品不是成功的产品,不管它的技术优点是什么。为了实现内部平台的投资回报,你的产品开发团队需要使用它,并且要好好使用它。为了实现这一点,他们需要欣赏它,理解它,并意识到它的特性。正如马克斯·格里菲斯在他的文章中所描述的基础设施产品,平台产品和其他类型的产品一样,需要客户移情、产品所有权和智能测量。

内部产品的一个优势是,你的用户对你的产品的发展和成功高度投入。和任何一群顾客一样,你的同事们是怀疑论者、中立者和热情者的混合体。利用热衷者并帮助他们成为该平台的早期采用者和拥护者,将极大地提高您组织中对该平台的看法。传达您的路线图、接受反馈并从用户那里获得经验将有助于您的平台的持续相关性。幸运的是,你们都在同一个机构工作,所以你们有丰富的沟通渠道。内部平台需要营销。这和向公众推销产品是不同的,但它仍然是一种营销。

保持善意是被采纳的关键。因此,如果您有任何不可避免的中断,请告知它们,并可能调整您的计划,以减少对用户的影响。如果出了什么问题,你的服务中断了(提示:你会的),那么道歉和透明会让他们放心。抵制将管理授权作为采纳策略的诱惑。你可能俘虏了一些用户,但是强迫他们使用产品来为自己谋福利并不能培养一种有效的关系。

卓越运营

当您采用内部平台时,您需要向产品开发团队寻求极大的信任。您的平台现在是您的组织用于实现其功能的系统的关键依赖项。你的操作能力需要足以证明这种信任。

这意味着您的平台团队需要掌握软件基础设施的基本知识,比如网络、扩展和灾难恢复。如果您的平台工程团队在底层技术方面遇到困难,他们将不会为您的产品开发团队构建健壮的产品。此外,现代运营的卓越不仅体现在基础设施上,还体现在确保可靠性的实践中。这本书网站可靠性工程是对这一领域最新技术的很好描述。如果你的平台组织不具备诸如可观察性、监控和SLOs等SRE实践技能,那么你不仅面临着破坏产品团队信任的风险,还面临着这样做却不知道自己做了的风险。

您的平台组织还必须具备有效管理事件并从中学习的成熟度。工作时间外的支持、警报系统和无可指责的事件回顾应该是优先考虑的。你可能需要建立流程,修改雇主合同的措辞和预算,以使公平薪酬成为可能让随叫随到成为一种足够愉快的体验,以鼓励广泛的参与.这也会影响你的计划。当您需要进行重大更改(例如迁移)时,您需要进行适当的投资,以便将用户的停机时间降至最低。

卓越软件工程

平台组织不仅仅是一个运营部门,所以它需要超过运营能力。即使您不打算编写实质的自定义应用程序,您的脚本,模板和配置文件将迅速累积复杂性。如果您想保留快速安全更改平台的能力,则需要以正确的方式构建它。

对于基础架构环境下的软件工程卓越性,我们最喜欢的总结是基础架构作为代码的三个核心实践,正如Kief Morris在他的书中所定义的那样基础设施代码

  • 将所有内容定义为代码
  • 持续测试和交付所有正在进行中的工作
  • 构建你可以独立改变的小而简单的组件

如果您的组织能够始终如一地应用这些实践,那么就更有可能执行您的平台愿景。没有它们,您可能能够在某个时间点使您的基础架构处于良好状态,但是您将不能维持开发团队不断变化的需求所要求的发展速度。

使用内部产品也会对产品开发团队提出要求。好的产品开发团队知道由他们的依赖所提供的服务水平,将它们考虑到他们自己的设计中,并使用工程实践来减少那些可能影响他们的服务水平目标的风险。当这些依赖关系在内部提供时,这就更加重要了,因为无论您的平台质量有多高,它都不可能达到商业SaaS提供商的优化水平。

健康的团队

个人技能很重要,但长期保持卓越需要强大的团队纪律。当您的平台系统被业务的其他部分所依赖时,只有少数忙碌的人负责维护它们的专业知识是不可接受的。您需要具有明确任务的自治团队,避免单独的代码或系统所有权。它们必须在知识共享、文档编制和员工入职方面进行投资。一个中彩票的人永远不应该对你的平台的生存能力构成威胁。

为了保持这些平台工程团队的生产力,他们的计划工作系统需要成熟。他们必须有按其价值描述的项目的积压,并有按优先次序排列的过程,否则紧急的可能压倒重要的。意外事件和计划外的工作是不可避免的,但是如果团队花费太多的时间在辛苦工作上,那么它将永远没有能力投资于改进其产品。团队不应该同时管理太多的平台产品。

我们发现了认知负荷的概念,在Matthew Skelton和Manuel Pais的书中讨论过团队拓扑,这在保持团队任务可控方面很有用。如果一个团队经常切换上下文之间完全不同的任务,然后认知负荷太大,当发生这种情况时,不仅会团队不能够进行他们的日常工作,但它也将让新的团队成员难以获得信心,他们需要在所有的系统工作。

开始

如果你在你的组织中还没有这些能力,你是否就没有资格采用平台战略?您可能会问,在没有只能从经验中获得的教训的情况下,您应该如何构建这些能力?

秘诀不是在你的执行质量上妥协,而是在你的野心范围内保持适度——首先。一个平台计划,无论多小,都应该产生商业价值,以产品思维为指导,以卓越的运营和软件工程来实施,并得到一个能够维持新平台服务的团队结构的支持。如果你做不到这一点,那么你希望提供的提升很可能会成为一个拖累,损害你的新平台在你的组织中开发人员的声誉。

针对您的技术资产中易于理解的部分的小型、集中的平台服务具有较低的难度。他们不会让你从整体角度考虑平台问题,但他们会让你从这个角度开始开发。例如,提供一个可以减轻产品团队操作负担并提高跨服务可见性的日志集群具有明确的业务价值,而不需要建立复杂的财务模型。它仍然需要产品思维来确保它为客户服务(它的可用性、新鲜度和搜索UI满足开发人员的需求吗?),但是这种产品思维不需要具备提供统一开发人员门户所需的成熟度。而且,它仍然需要软件工程、操作技能和健康的团队来做好,尽管不如为你组织的所有微服务建立一个可观察的边车那么重要。

你要问自己的第一个问题是最小的东西是什么[1]我们可以建立这对产品团队有帮助吗?第二个问题是,当时机成熟时,我们如何升级或迁移?技术的发展非常迅速,厂商锁定也很痛苦,因为厂商是你自己的组织。如果弃用您的平台服务将需要数年的痛苦过渡,那么可能是时候回到绘图板并简化您的产品了。你不需要有一个详细的日程表和大量的替代技术,但考虑到现实生活(3到5年)和替代解决方案的架构接缝将迫使你的设计更简单和更去耦。

我们建议自愿采用您的平台。这在两个方面支持您的平台策略。首先,当产品团队有能力选择退出平台服务时,它会鼓励你保持你的服务松散耦合,当推出新一代服务或用商业产品取代它时,这将有利于平台。其次,当你的平台组织依赖于产品团队对平台利益的欣赏时,它会给你的平台组织带来巨大的压力,让他们始终把取悦客户放在首位。强制迁移到平台是一条捷径,它有侵蚀团队产品思维规则的长期风险。

您可能会发现一个简单的分类系统有助于设置对新平台特性成熟度的期望,例如表明新特性处于beta测试阶段。您可能希望将sslos和支持层与成熟度分类关联起来,因为实验性特性不需要提供与核心特性或您的平台相同的高可用性。例如,它可能不需要24小时的支持。一旦该功能得到全面支持,该平台的用户可以期待强大的SLOs,让他们在上面构建任务关键组件,但在此之前,一个要求较低的期望值让平台团队能够自由试验和验证他们对产品的假设,然后再做出坚定的(和长期的)承诺。

如果你能记住以上几点,你就有了一个额外的优势。您的平台团队将管理非常有效的产品组合。他们的认知负荷将会很小,他们的注意力将能够持续地减少开发团队的上市时间,而不仅仅是保持灯亮着。

结论

数字平台是技术产品的组合。和所有产品一样,平台通过使用产生价值。有了正确的基础业务论证、谨慎的产品管理和有效的技术执行,数字平台通过减少产品开发团队的认知负荷和加速组织的创新而获得成功。平台需要大量的资金、人才和机会成本投资。他们通过积极地影响产品开发团队快速有效地开发面向客户的高质量产品的能力来回报这种投资。

开发一个数字平台是一个战略决策,不能掉以轻心。除了直接的财务考虑外,数字平台还会对组织内的关系产生压力。产品开发人员已经体验过商业云提供商的产品,为了满足这些提高的期望,平台工程团队必须在产品管理和技术实现方面都成熟。产品开发团队还必须学会成为平台组织的良好合作伙伴,并接受他们对服务的运营所承担的责任。

数字平台是力量倍增器,所以在发展竞争优势和引入显著的生产力障碍之间有一条微妙的界线。你在产品生命周期中所做的决定将决定你是走一边还是另一边。好消息是,就像所有其他类型的软件开发一样,如果您从小处着手,同情您的客户,从您的成功(和失败)中学习,并牢记您的总188比分直播完整手机版体愿景,那么您就有机会成功。


脚注

1:“最薄的可行平台”团队拓扑

确认

感谢Brian Goetz, Emma Baddeley, Evan Bottcher, Fergus Orbach, Georgina Giannoukou, Martin Fowler, Mayur Wadhwa和Michael Fait的深刻建议和评论。

重大修改

2021年4月27日:发表