审查流程

需要持续不断对架构进行审查,同时要允许试错,建立良好的研究探索氛围。架构审查本身应该是一个简单流程(数小时,而不是几天),是一种对话,而不是审核。审查架构的目的是找出任何需要解决的关键问题或可以改进之处。审查后应采取一些措施,以改善客户体验。

正如在“关于架构”部分讨论的那样,团队中的每位成员都应该对架构质量负责。我们建议负责架构的团队利用良好架构框架持续检视架构,而不仅仅只是召开一个正式的审查会议。持续的审查使团队成员能够随着架构的演进不断获得知识体系与对架构认识的更新,并在您推出新功能时改进架构。

AWS 良好架构高度借鉴了 AWS 在内部审查系统和服务的方式,并与之保持一致。它基于一套可以影响架构方法的设计原则,并确保不会忽略常见于根因分析中的那些因素。当内部系统、AWS 产品或客户遇到严重问题时,我们会查看 RCA,寻求改进当前审查流程的可能性。

应在产品生命周期内的关键里程碑阶段,设计阶段早期,进行多次审查,避免单向决策« [ 许多决策都是可逆的,是双向的。这些决策可以采用简单流程。单向决策很难或者不可逆,所以在做出决策之前需要更加全面的检查。 ] »  很难进行更改,并在正式上线之前再次审查。上线后,随着时间变化,伴随着新功能和新技术的出现与发展,架构也会随之演进。您需要遵循良好的架构实践,避免出现架构退化。当架构面临重大变更时,您应遵循一套系统健康规范与流程,包括执行 Well-Architected 审查。

如果您想把审查用作一次性快照或独立的衡量方法,则需要确保让所有相关人员参与对话。我们经常发现,通过审查,团队才第一次真正了解他们实施了什么。在审查其他团队的工作负载时,一种有效的方法是围绕架构展开一系列非正式的对话,在此过程中您可以收集到大多数问题的答案。然后通过一两次会议进行跟进,来帮助您理清思路,或深入了解不明确的方面或已感知的风险。

下面建议了一些召开会议需要准备的事项:

完成审查后,您应有一个问题清单,并基于您的业务环境来确定这些问题的优先级。您还需要考虑这些问题对团队日常工作的影响。如能及早解决这些问题,您就可以腾出时间开展创造业务价值的工作,而不是解决重复出现的问题。在解决问题时,您可以反复进行审查,来确认架构的改进效果。

虽然在完成审查后,审查的价值显而易见,但您可能发现新团队在开始时可能会对审查抱有抵触情绪。可以通过与团队沟通审查的益处来解决下列异议:

在您与团队进行多次审核后,您可能会发现一些问题。例如,您可能发现一些团队在某个支柱或主题方面出现较多问题。建议您以全局眼光看待所有审查,找出能够帮助解决这些问题的任何机制、培训或首席工程师会谈方案。