DevOps 组织中应用架构师的新定位与实践

DevOps 组织的成功，很大程度上来自于聚焦培养强有力的 DevOps 团队。“乌合之众：未有效地管理组织变革”是 DevOps 组织需要避免的六大“焦油坑”之一（详情请关注“如何避免 DevOps 变革的六大‘焦油坑’”）。然而随着 DevOps 深入实施，DevOps 组织却面临窘境，在交付团队与流程中无法为应用架构师定义相应的角色与活动。

在 DevOps 实施中 DevOps 组织努力引入应用架构看护，却发现与 DevOps 价值观、目标与实践难以协调一致。同时，由于缺乏应用架构指导，DevOps 组织难以将 DevOps 行动规划化推广。华为云 DevCloud 专家也发现，大量客户关注最多的焦点问题之一就是应用架构师作为公司的高价值员工在 DevOps 中如何发挥应有的价值。

DevOps 组织面临的应用架构相关的窘境，概括来讲，主要体现在以下 3 方面：

• 应用架构师与 DevOps 团队间关系越发失调，同时缺乏沟通基础与机制，难以有效沟通；

• 开发流程中没有阐述何时寻求应用架构指导，导致应用开发缺乏架构指导，同时难以协调浮现式架构（Emergent Architecture）与前期架构需求；

• 产品管理中没有定义应用架构角色，跨应用影响（例如协同与依赖）可能没有被有效识别。

针对应用架构相关窘境，在现代化的应用开发中，DevOps 组织需要定义应用架构师职责，使应用架构师与 DevOps 团队各角色更有效的沟通，交付更有价值的产品。在多数情况下，应用架构师不是 DevOps 团队的成员，因为架构技能非常稀缺，必须服务多个团队。架构师应该成为具有独特视角的领域专家、在团队内提升架构知识与技能的教练、帮助团队做出最佳决策的指导者。具体来讲，应聚焦以下 3 方面：

• 建立 DevOps 团队与应用架构师的沟通机制，使 DevOps 团队将应用架构师视为 SME、教练和指导者。

• 让应用架构师提供架构原则和模式来指导单个解决方案的浮现式设计（Emergent Design）。

• 让应用架构师维护产品 Backlog 的高层次视图以及跨 DevOps 团队协调来发现系统之间的影响，例如接口、重用等。

应用架构师与 DevOps 团队不同角色有效地沟通

通常情况下，DevOps 团队最初先使用敏捷框架（Agile Framework）（例如 Scrum）来定义以开发为中心的角色和活动，然后增加面向运维的角色和活动，以帮助团队成员更好地协同工作。DevOps 团队的主要角色如下图所示：

典型 DevOps 团队角色

DevOps 团队的成员每天面对面一起工作。随着时间的推移，通过持续改进，DevOps 团队形成了透明、信任、高效的工作氛围。DevOps 这种以团队为中心的方法很难容下外来者。例如， ScrumMaster 的职责之一就是保护团队免受外部打扰。

DevOps 应该确定并促进 DevOps 团队与应用架构师之间的关系，使 DevOps 团队将应用架构从干扰者转变为合作伙伴，应用架构师成为领域专家（SME）、教练（Coach）与指导者（Guide），来共同负责有价值软件的成功交付。

在传统软件开发实践中，应用架构师可能只与开发团队的技术领导人或者项目经理进行沟通交互。然而，在 DevOps 团队中，应用架构师需要理解典型 DevOps 团队的角色，并与之建立关系，形成有效沟通。

• ScrumMaster：ScrumMaster 是团队的教练（Coach））、促进者（Facilitator）、保护者（Guardian）和指导者（Guide）。他们可以确保所有人理解并且遵从开发流程的应用架构的方方面面，并与团队和应用架构师一起优化流程，促进团队和应用架构师的交互。应用架构师应将 ScrumMaster 视为非常有价值的联盟。

• Product Owner：PO 是客户（或者业务）的代表，保证应用中包含了有价值的特性。他们与应用架构师一起工作确保 Backlog 中涵盖了应用架构需求。PO 和应用架构师合作来识别并理解跨团队影响以及调整 Backlog。

• Developers：将应用架构师视为指导者和潜在的教练和顾问。如同与任何 SME 工作一样，开发人员应该在必须的时候寻求应用架构师的输入和澄清。在故事的开发与设计中，开发人员可与应用架构师讨论架构重要性或者影响。拥有架构知识的开发者可以作为应用架构师的代表和代言人。

• Platform 团队：与架构师确保应用更合适地使用平台的服务。反过来，架构师为平台的演进提供反馈。例如，架构师可以建议将功能创建为应用服务，而不是应用本身的一部分。在多个平台选择的情况下，架构师帮助确定哪个平台是合适的。

• Operations 团队：与应用架构师共同工作来识别方法最大化应用的可运维性、弹性、可持续性与安全。这些方法包括增加度量、增加或者修改工具链组件、与安全事件监控等管理工具集成、为应用行为提供可配置选项。

• Support 团队：是架构师的关键反馈来源，这些反馈包括设计决策的实际的、生产有效性。

除此之外，应用架构师通常与产品价值流的总体解决方案有关，因此应用架构师能够以更广的视角来识别 DevOps 团队间的协作，并提供权衡方案；同时可以帮助 DevOps 团队充分理解只有应用组合更强大，客户才能获得最大化的价值。

应用架构师为解决方案持续提供原则与模式并拥抱反馈

在传统的软件开发组织中，应用架构师一直致力于提供大量的前期设计，为开发团队提供应用架构输入。在 DevOps 组织中，DevOps 团队通常会引用敏捷宣言，特别是 “最好的架构、需求与设计出自自组织团队” 这条原则。DevOps 团队采用迭代增量方式来构建应用，不断演进解决方案，以不断增进和改善对干系人需求的了解以及如何最好地满足需求。因此，应用架构师交付的大量静态架构规范无法演进，也无法提供价值，从而变成了浪费的源头与价值流的一种约束。

这不意味着应用架构输入对 DevOps 团队没有帮助。如果没有应用架构输入，DevOps 团队创建的应用将缺乏重要特性（例如缺少安全性、扩展性或可靠性等），无法为客户提供足够的价值；同时应用也可能因基础平台不同及集成性弱等而无法很好地与产品组合中的其它产品相匹配。此外，如果团队不能利用可重用模式中的知识，将增加 SME 的负担，因为 SME 不得不重新发明轮子。最终，导致专家将用完容量，阻止规模化扩展。

尽管被视为深思熟虑架构的障碍，浮现式架构使敏捷团队参与到应用架构的创建中，并且更好与应用架构匹配。应用架构师和 DevOps 的团队目标是统一的，即为客户创建有价值的应用，但是他们有不同的视角。DevOps 团队主要聚焦应用本身，而应用架构师更关注应用在企业应用组合中的位置，并在应用组合间提供一致的客户体验。因此，DevOps 团队与应用架构师之间的紧张关系是不可避免的。然而，应用架构师必须愿意摒弃先入之见，并将架构决策延迟到最后时刻。

为实现持续的指导，应用架构师不被鼓励事先为敏捷团队提供大量的应用架构工件。敏捷团队会没做好使用的准备，或者会视为控制应用设计的尝试。相反地，应用架构师应该每次输入一些，按照敏捷团队的节奏，随着应用创建过程中出现的问题和机会。这需要应用架构师持续与 DevOps 团队沟通。

应用架构原则形成了持续指南的基础。应用架构师需要从基础中提供指南。应用架构师应该全面理解企业应用架构原则，并且一致地运用这些原则。应用架构师应该准备好传递基于原则的理由，来阐明为什么需要引入给定的需求，或者推荐某个特定模式的使用。实际的应用架构在应用架构师和 DevOps 团队的讨论中浮现。

定期的反馈应该在整个过程中收集。团队创建应用过程中浮现的实际的应用架构，不但与应用架构原则保持一致，而且经常会揭示这些原则新洞察。应用架构师领导者应该使用这些洞察来演进应用架构原则和实践。应用架构领导者应该考虑使用敏捷“回顾”技术，与应用架构师团队来增强反馈回路。

应用架构师维护产品待办事项的高级视图并影响事项

待办工作列表（Backlog）是 DevOps 团队活动的主要驱动力。待办工作列表中的工作项初始是粗粒度的，DevOps 团队会分解为更细粒度的故事（Story）。随着工作的开展，待办工作列表越来越大，导致不同团队的跨单个 Backlog 的影响难以识别。反过来，这导致了某些冲突只能在生产环境上发现，需要昂贵的重复工作。也导致重用或者协同的机会没有得到实现。发现这些冲突与机会，同时采取行动避免或者利用他们，是应用架构师的作用之一。通过持续地指导应用开发团队，应用架构师将维护 Backlog 视图，此视图既有广度又有深度。这样，他们就可以相应地影响 Backlog。当敏捷团队需要应用架构指导时，理解并监控 Backlog 是准备提供指导的关键。应用架构师可以在 3 方面影响 Backlog：Item 优先级、跨团队影响和 DoD（Definition of Done）。

应用架构师应该评估每个待办工作列表中工作项与应用架构相关的方方面面，并且聚焦高优先级的工作项。这样做的目的是准备刚刚好、即时的指导，避免 Backlog 变更时的重复工作。某些工作项应用架构意义更大，更复杂或者不确定，将需要应用架构师相应地与敏捷团队更多交互。某些工作项是更好的机会使团队探索替代的应用架构，或者重构现有软件。应用架构师应该与 PO 讨论，如何对这些 item 进行优先级排序。一些 PO 会为应用架构需求创建单独的工作项，而另外一些 PO 会将应用架构需求作为其他工作项的一部分。无论哪种情况，应用架构师与 DevOps 团队必须协商解决最重要的应用架构需求而牺牲其他需求，但是应该使 DevOps 团队意识到这将导致技术负债。

应用架构师应该看护所有敏捷团队的 Backlog，同时对应用组合有共同理解，以便来识别跨团队的影响和协作，这些主要包括接口、用户体验一致性与重用。重用对于 DevOps 团队来讲，是一个问题泛滥成灾的领域，因为重用设计会引入额外工作，而不会交付即时价值。应用架构师与 DevOps 团队可以使用 Pay Twice 模型来达成协议来减轻这种影响。

增加与敏捷团队的交互将使应用架构师的已经很紧张的安排雪上加霜。一些合规性和安全的需求经常出现并影响大部分团队。与其投入时间去持续重新介绍这些需求，不如考虑将他们纳入到 DoD（Definition of Done）中。DoD 是所有工作完成前必须满足的标准集合。这种方法是非常有效的。DevOps 团队可以结合自动化测试和静态代码扫描工作，减少人工评审、耗时的低价值的应用架构工作。

长期来讲，客户不仅仅满足于软件立即提供的新特性，更需要持续的可靠性、可用性、性能和安全。因此，DevOps 组织需要在软件交付中重新定义应用架构师角色，使应用架构师成为 SME、教练和指导者，保障应用架构原则在 DevOps 团队落地，实现 DevOps 价值观、原则与实践能够规模化应用，最终为客户提供有价值的软件。

本文转载自 华为云产品与解决方案 公众号。

原文链接：https://mp.weixin.qq.com/s/y2wCr_Qw_cPoRB7LiZvaUg