AWS：结构完善？现代云应用程序的体系结构评论

小提示：您能找到这篇{AWS：结构完善？现代云应用程序的体系结构评论}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的AWS：结构完善？现代云应用程序的体系结构评论内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

< ">在应用程序开发和后续操作的上下文中，时不时地会出现一个问题：“我实际上是否正确地做到了这一点”？可以使用体系结构审查来确定是否遵循最佳实践以及体系结构中是否存在任何风险。

< ">AWS架构完善的框架支持云架构师为其应用程序开发安全，高性能，故障安全和高效的基础架构。本文说明了如何在实践中实现“结构完善的框架”中的概念。使用行业的轶事和最佳实践，作者还将解决来自德国中型公司的IT经理的关注。

< ">事实证明，架构评估是识别薄弱环节的有效工具。我们理解“架构”一词是指软件和基础架构的结合。通过有针对性的问题，可以发现可能危害项目成功的风险。我们还可以确定是否已应用行业最佳实践，质量和合规性标准得到满足，并获得了项目状态的真实概况。

< ">根据项目的规模，体系结构可能非常庞大和复杂。多个团队参与其中，将多个服务的架构整合在一起，这并不有温度危机公关少见。在这样的环境中，通过体系结构评估检查项目的预定义质量，技术和功能目标就显得尤为重要。为此可能有不同的评估方法。

< ">一种可能的方法是架构权衡分析方法（ATAM[1]），该方法于2000年在卡耐格梅隆大学提出。这种方法主要用于分析软件体系结构，是基于在每个主要项目中都会进行权衡的知识。此方法的目的是了解与系统质量要求有关的体系结构决策的后果。

< ">但是，形式化的体系结构评估也受到批评，认为部分评估不适用于实际项目。特别是，当项目具有不断变化的技术或业务需求，由小型团队进行监督并因此依赖于某些折衷方案（例如，缺乏内部文档，架构图等）时，很难通过正式的架构评估来检查架构方法。Neil B.Harrison和Paris Avgeriou在2012年提出了“基于模式的架构审查（PBAR）[2]”提案，以解决这些问题。）。基于软件开发中已知的设计模式，Harrison和Avgeriou在PBAR中尝试使用模式和质量特征之间的关系，以实现“轻便，简单但集中的”架构评估形式。

< ">传统上，许多组织与架构团队合作，而架构团队通常位于产品和/或功能团队的上游。通常由跨学科专家组成的架构团队通常使用TOGAF或Zachman Framework[3]。现代的软件开发方法通过责任和能力的下放来保证优势。但是，各个团队之间决策权的分配也会带来风险。必须确保团队符合内部标准，并在最好的情况下超过内部标准。

< ">AWS开发和运营数百万用户使用的云服务。在AWS，我们与分散的开发团队合作，我们希望每个团队都能创建架构并根据最佳实践进行工作。为了减轻上述风险，我们借助数据定义了最佳实践。但是，内部开发团队只是经验的一种来源。此外，我们与AWS Cloud Platform的用户积极合作，收集小型初创公司对全球企业的反馈，并从中得出更多最佳实践。多年以来，我们将这些最佳实践形式化，并开发了构成完善框架基础的测试机制。该框架包含统一编译的，行之有效的方法客户和合作伙伴可借此评估体系结构。AWS架构完善的框架已经存在超过8年，并且正在不断开发中。版本8当前可用。

AWS架构完善的框架简介

< ">AWS架构完善的框架通过问卷调查使这些最佳实践切实可行。通过回答这些问题，可以探索架构与云最佳实践的协调程度。此外，该框架还提供了有关如何改善发现的漏洞的详细说明。

< ">AWS架构完善的框架基于5个考虑不同方面的支柱。具体来说，这些是：卓越运营，安全性，可靠性，性能效率和成本优化。在下文中，我们将仔细研究各个支柱背后隐藏的内容。

< ">卓越运营支柱负责所提供系统的执行和监视。目的是为业务创造实际的附加值，并不断优化流程和程序。重要方面是变更的自动化，有效地处理运营中断以及定义日常运营管理标准。在此基础上，本支柱考虑了有效组织团队的主题以及促进创新的手段。

< ">安全支柱涉及信息和系统的保护。最重要的主题包括机密性和数据完整性，权限管理（包括个人授权的定义和管理），系统保护以及建立用于检测安全事件的控件。

< ">可靠性支柱致力于确保工作负载在正确的时间正确，一致地执行其预期的功能。弹性工作负载可从中断中快速恢复，以满足业务和客户需求。这里的重要方面是分布式系统设计，恢复计划和变更处理。

< ">性能和效率的支柱涉及IT和计算资源的有效利用。首要问题包括根据工作量选择合适的资源，监视性能以及制定明智的决策以随着业务增长保持效率。

< ">成本优化支柱致力于避免不必要的成本。成功的关键是创建成本可见性，定义预算并定期分析支出，并在此基础上不断优化支出。

< ">AWS架构完善的框架基于通用设计原则，有助于实现云中应用程序的良好设计。例如，一种这样的原理就是开发数据驱动的体系结构。测量架构决策的影响并基于此对架构进行基于事实的进一步开发已成为可能。该体系结构的每个新版本都提供了新的数据点，可以在这些数据点上建立持续的演进。

< ">基于一般设计原则，为每个支柱导出了特定原则。现在可以使用适当的问题来测量要测试的体系结构的实施程度，然后可以从中得出审查结果。

进行结构完善的框架审查的最有效方法是什么？

< ">要进行成功的审查，首先必须确保每个人都在谈论同一件事。乍一看，这似乎是微不足道的，但实际上，对于一个看似明确的评论主题，人们有很多不同的看法。例如，电子商务堆栈下的评论的一个参与者可能仅理解提供在线商店的应用程序，而其他参与者还包括运行时环境，例如容器运行时。还有一些人还将在术语“电子商务堆栈”下添加库存系统。两种观点都没有错，但是在审查开始时就建立通用观点极为重要。为此，您可以共同定义要考虑的工作负载。

< ">在我们同意要分析的工作负载之后，另一个重要步骤是就工作负载的通用版本达成一致。开发人员可能会在工作负载的当前状态下考虑其最后的代码更改，而从操作的角度来看，这种更改尚未实现。反过来，架构师可以考虑已经设计但尚未实现为当前状态的改进。在这里，将当前的生产系统定义为审查的基础非常有用。

< ">我们已经看到，不同的参与者带来了不同的工作负载视图。除了达成共识之外，我们还必须让适当的参与者参与审查，他们可以共同涵盖《结构完善的框架审查》的各个方面。显然，由结构完善的框架的五个支柱定义的主题范围非常广泛。根据公司的组织，涉及的人员和专业部门的数量可能会很大。在一个具有功能结构的组织中，必须将来自各个部门的参与者聚集在一起，以便可以将开发，运营和安全性等各个方面都包括在内。在基于敏捷和独立团队的组织中，涵盖了工作负载的各个方面，在大多数情况下，邀请团队进行审核就足够了。无论公司的组织结构如何，重要的是不要忘记业务方面。IT系统并不是为自己而建立和运行的，而是为客户服务并创造附加值的。因此，这些也是重要的方面，应在结构完善的框架审查中予以考虑。因此，重要的是，参与评审的人员也应满足这一要求。在敏捷团队中，与您一起代表客户观点的产品所有者就足够了。不要忘记业务方面。IT系统并不是为自己而建立和运行的，而是为客户服务并创造附加值的。因此，这些也是重要的方面，应在结构完善的框架审查中予以考虑。因此，重要的是，参与评审的人员也应满足这一要求。在敏捷团队中，与您一起代表客户观点的产品所有者就足够了。不要忘记业务方面。IT系统并不是为自己而建立和运行的，而是为客户服务并创造附加值的。因此，这些也是重要的方面，应在结构完善的框架审查中予以考虑。因此，重要的是，参与评审的人员也应满足这一要求。在敏捷团队中，与您一起代表客户观点的产品所有者就足够了。

< ">能够与参与者一起涵盖“结构完善的框架审查”中提到的所有领域是基本的，但限制参与者的数量同样重要。在太大的小组中，重要的讨论常常会进行得太远，并且很难在合理的时间内实施审核。如果参与者组由不同的专业部门组成，则通常只需在每个部门中包括一个替代人选即可。前提是他们可以在审查的背景下充分，充分地代表团队。开发和操作工作负载的关键角色必须在那里。此外，通常更容易找到较小的团体的约会。这是两个披萨规则适用的地方适用[4]。会议的团队和参与者的人数不应超过对两个比萨饼（美国比萨饼，即8至10人）感到满意的程度。为了进行有效的审查，这里通常少花钱。

< ">审查会议中的讨论是必要的，也很有价值。这种审查会议通常是将所有相关观点汇集在一起的少数场合之一。我们要避免的是陷入无用的，可能太详细的讨论。这里需要积极的节制，以实现一个共同的目标。这种审核可以由经验丰富的人员（通常是建筑师）很好地进行，他们不直接参与工作量，因此可以毫无偏见地领导审核。争论和其他主题可以在以后的某个时间点记录下来并进行处理。如果无法就问题的共同答案达成共识，则也应注意这一点。如果有分歧，无论当前是否已实施某种方法，流程或最佳实践，我们都应记录为未实施，然后再进行检查。在绝大多数情况下，分歧是一个很好的指示，表明至少没有整体实现，因此存在优化的潜力。在“结构完善的框架审查”期间的讨论经常会发现信息空白。尤其是在审查更复杂的工作量时，在跨团队经理的参与下，团队发现，例如，已经定义了有关特定主题的准则，但是这从未涉及到团队。在这种情况下，直接进行内部跟进任命以弥合这些差距并不少见。

团队如何处理审查的想法？有什么问题吗？

< ">重要的是在实际审核之前定义审核的目的。动机可能多种多样。例如，负责工作量的团队可能想自己分析当前工作量架构存在哪些弱点。缺陷通常可以快速分析。但是即使在这种情况下，也线上营销推广怎么做必须确保没有任何涉案人员害怕承认错误，或者很容易为自己的工作辩护或使自己看起来更好。实现此目的的最简单方法是事先澄清，审核结果仅保留在直接参与的人员中。

< ">另一个动机可能是记录发现的弱点以及纠正这些弱点所需的工作，以便在此基础上要求额外的资源，例如员工或时间。如果清楚地传达了这一点，也可以取得良好的结果。

< ">当从外部（例如，由管理层委托）进行审核或甚至有动机为外部审核提供数据点时，这是最困难的。尽管存在这种潜在的不舒服的情况，但是在创建一个可以公开解决问题的信任环境方面需要付出很多努力。这样的审核的主持人必须更加严格地质疑答案，以实现现实的审核结果的目标。

< ">一个重要方面是调整参与者的心态。检测到的不可访问性-即使与高风险（高风险项目）相关联-不能记录故障，但是可以进行改进。最好在审查中确定这一点，不仅是在发生风险并可能引起生产损失的时候。

< ">< color: rgb(0, 112, 192);">如何使AWS Well-Architected Framework适应我的工作负载？

< ">AWS架构完善的框架的目标是提供可应用于各种工作负载的一致原则和最佳实践。至关重要的是，一方面，不能涵盖特定工作负载的所有可能方面，另一方面，必须以特定工作负载所需的深度来处理所有方面。

< ">为了获得最佳结果，可以将不适用于正在检查的工作负载的各个方面隐藏起来，这是有帮助的。但是，经验表明，在大多数情况下，经过仔细考虑，这些方法在工作负载的开发中将应用或将在以后应用。然后有意义的是将这些方面留在审查中，并根据当前状态进行回答。这确保了这些不会丢失，并且可以在适当的时间计划和采取任何必要的措施。

< ">现在，我们已经确定可以调整评论的宽度，现在我们必须确保也可以修改评论的深度，以使其对我们的工作量有意义。这就是AWS结构完善的框架透镜发挥作用的地方。这些是AWS Well-Architected Framework的扩展。提供各种行业和技术特定的镜头。例如，可以详细检查包含机器学习的工作负载的细节。

使用AWS架构完善的框架可以实现什么结果？

< ">AWS架构完善的框架审阅的结果可能多种多样，并以不同的方式使用。在极少数情况下，审核结果将是：一切都已完美实施，没有进一步的建议。但是即使这样，由于您现在可以确定工作负载已合理地进行了构造，所以这样的检查非常有价值。

< ">完善的框架审查报告大部分都揭示了许多已识别的风险以及具体的提议解决方案和建议。这是理想的起点，可以将这些任务包括在下一个版本的计划中，并根据已识别的风险确定优先级。架构完善的框架审查的结果被转化为敏捷方法的世界，它产生了许多用户案例，这些案例已经非常有资格转移到待办事项列表中进行优先级排序。形象地讲，团队在审查后留下一张桌子，上面贴满了帖子。

< ">AWS架构完善的框架的基本思想是超越一次性审核的用途。在这里定期进行检查是有意义的，这样可以使完成结构合理的工作负载的进度可见，而发现的薄弱环节可以根据生成的建议根据优先级进行逐步处理。这避免了可能需要压倒一切的事情，阻止了实际的实现。团队可以以结构化的方式来解决这个问题。

< ">另一个应用程序是将AWS Well-Architected Framework Reviews纳入您自己的开发流程中。该框架可以为定义新开发的标准要求提供很好的启发。实际上，建议在“完成的定义”中包括结构完善的框架审查。此支架可用于确保新的开发尽早考虑结构完善的框架的各个方面，并从一开始就将其纳入设计和实施中。这样可以避免在开发阶段就已经进行了后续的错误纠正。这将对服务团队的生产力产生重大影响。众所周知，系统中的缺陷导致计划外的工作，使我们无法进行实际工作[5]。

我可以使用哪些工具进行AWS架构完善的框架审查？

< ">另一个重要方面是工具的良好支持，这些工具使AWS Well-Architected Framework Review得以有效执行。良好地访问问题目录非常重要，这样团队可以一起舒适地回答问题。AWS控制台中结构良好的工具[6]可以用于此目的。在这里，团队可以定义要考虑的工作量并填写调查表。该工具在回答问题和详细说明方面提供了积极的支持。

< ">对于发现的每个漏洞，都会显示优先级，并建议采取特定的补救措施，使团队可以更轻松地计划和实施通往AWS架构完善的工作负载的旅程。“尝试胜于学习”的座右铭也适用于这些措施的实施。如果您有兴趣，可以使用AWS Well-Architected Labs[7]，在实验室环境中尝试重要的措施并更好地理解它们，然后再将其应用于您自己的，可能很复杂的工作负载。

< ">如前所述，有意义的是，不仅要分析给定的工作负载一次，而且要连续进行分析。该工具支持服务团队创建和管理评论的多个版本。里程碑也可以直接在工具中定义。

< ">借助AWS Identity and Access Management（IAM）服务[8]，可以定义和控制对审阅数据的访问权限，以便根据需要保护此敏感数据。

< ">通过提供的API接口[9]，AWS Well-Architected-Tool可以集成到其他系统中，例如B.可以集成集中的报告工具；识别出的风险也可以无缝地转移到现有工具和流程环境中。

下一步是什么？

< ">如果您将其实际应用于现有工作负载，则可以很好地访问AWS架构良好的框架。通过这种方式，您不仅可以对工作量和AWS Well-Architected框架有更深入的了解，而且还可以对基础设计原则有更深入的了解，从而可以构成未来架构决策的基础。详细的在线文档[10]提供了对该框架的更深入了解。

< ">祝您实施AWS架构完善的工作负载取得成功！

资料来源

[1]ATAM-Method for Architecture Evaluation

[2]Pattern-Based Architecture Reviews

[3]TOGAF und Zachman Framework

[4]Two-Pizza-Regel

[5]The Phoenix Project:A Novel about IT,DevOps,and Helping Your Business Win,Gene Kim,IT Revolution Press;1.Edition(1.Februar 2018),ISBN-10:1942788290

[6]AWS Management Console

[7]AWS Well-Architected Labs

[8]AWS IAM

[9]AWS Well-Architected Tool-API Reference

[10]AWS Well-Architected Framework

< ">原标题：Well-Architected?Architekturreviews fr moderne Cloudanwendungen