审查流程
需要持续不断对架构进行审查，同时要允许试错，建立良好的研究探索氛围。架构审查本身应该是一个简单流程（数小时，而不是几天），是一种对话，而不是审核。审查架构的目的是找出任何需要解决的关键问题或可以改进之处。审查后应采取一些措施，以改善客户体验。
正如在“关于架构”部分讨论的那样，团队中的每位成员都应该对架构质量负责。我们建议负责架构的团队利用架构完善的框架持续检视架构，而不仅仅只是召开一个正式的审查会议。持续的审查使团队成员能够随着架构的演进不断获得知识体系与对架构认识的更新，并在您推出新功能时改进架构。
AWS Well-Architected Framework 高度借鉴了 AWS 在内部审查系统和服务的方式，并与之保持一致。它基于一套可以影响架构方法的设计原则，并确保不会忽略常见于根因分析 (RCA) 中的那些因素。当内部系统、AWS 服务或客户遇到严重问题时，我们会查看 RCA，寻求改进所用审查流程的可能性。
应在产品生命周期内的关键里程碑阶段和设计阶段早期进行多次审查， 以避免单向决策， 因为它们很难进行更改，然后在正式投入使用之前再次审查。（许多决策都是可逆的，是双向的。这些决策可以采用简单流程。单向决策很难，不可逆，所以在做出决策之前需要更加全面的检查。） 进入生产阶段后，您的工作负载会随着您不断添加新功能和更改技术实施而继续演进。架构也会随之演进。您需要遵循良好的架构实践，避免出现架构退化。当架构面临重大变更时，您应遵循一套系统健康规范与流程，包括执行 Well-Architected 审查。
如果您想把审查用作一次性快照或独立的衡量方法，则需要确保让所有相关人员参与对话。我们经常发现，通过审查，团队才第一次真正了解他们实施了什么。在审查其他团队的工作负载时，一种有效的方法是围绕架构展开一系列非正式的对话，在此过程中您可以收集到大多数问题的答案。然后通过一两次会议进行跟进，来帮助您理清思路，或深入了解不明确的方面或已感知的风险。
下面建议了一些召开会议需要准备的事项：
-
配有白板的会议室
-
任何图表或设计说明的打印件
-
需要带外研究来获取答案的问题（例如，“是否已启用加密？”）
完成审查后，您应有一个问题清单，并基于您的业务环境来确定这些问题的优先级。您还需要考虑这些问题对团队日常工作的影响。如能及早解决这些问题，您就可以腾出时间开展创造商业价值的工作，而不是解决重复出现的问题。在解决问题时，您可以反复进行审查，来确认架构的改进效果。
虽然在完成审查后，审查的价值显而易见，但您可能发现新团队在开始时可能会对审查抱有抵触情绪。可以通过与团队沟通审查的益处来解决下列异议：
-
“我们实在太忙了！”（一般会在团队准备重大发布时这么说。）
-
如果您正在为重大发布做准备，您会希望一切进展顺利。审查能够帮助您发现您可能错过的任何问题。
-
我们建议您在产品生命周期早期执行审查，以及时发现风险，并制定与功能交付路线图一致的规避计划。
-
-
“我们已经没有时间了，结果已成定局！”（一般会在他们面临无法改变的事件 [比如超级碗] 时这么说。）
-
这些事件是无法改变的。您真的想在不了解架构风险的情况下将它投入使用吗？ 即使不能解决所有问题，您仍然可以编制一个潜在问题处理手册。
-
-
“我们不希望其他人知道我们实施解决方案的秘诀！”
-
如果您向团队指出 Well-Architected Framework 中的问题，他们不会在这些问题中发现任何商业或技术专有信息。
-
在您与团队进行多次审核后，您可能会发现一些问题。例如，您可能发现一些团队在某个支柱或主题方面出现较多问题。建议您以全局眼光看待所有审查，找出能够帮助解决这些问题的任何机制、培训或首席工程师会谈方案。
