本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 工程文化方面的注意事项
<a name="engineering-cultural-considerations"></a>

Well-Architect AWS ed 框架的支柱之一是卓越运营。团队必须明白[运营模式](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operating-model.html)，以及他们在实现业务成果方面所起的作用。当团队知晓自己的职责，能够承担责任，并知道如何做出决策时，才能专注于实现共同的目标。

由于处于早期阶段的公司发展迅速，因此团队中的每个人都扮演着多个角色。这些用户拥有对 AWS 账户的高权限访问权限的情况并不少见。随着公司的发展，他们通常希望遵循*最低权限*的原则，并且仅授予用户完成工作所需的权限。为了帮助限制范围，您可以使用 [AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) 查看用户或 IAM 角色实际使用了哪些权限，从而方便您移除任何多余的权限。

要决定贵公司中哪些人有权限创建 IAM 角色可能很困难。这通常是提升权限的途经。提升权限是指用户可以扩展自己的权限或访问权限范围。例如，如果用户的权限有限但可以创建新的 IAM 角色，则该用户可以通过创建并担任已应用 `AdministratorAccess` 托管策略的新 IAM 角色来提升其权限。

一些公司将 IAM 角色配置限制为由可信人员组成的集中式团队。这种方法的缺点是，这个团队很快就会成为瓶颈，因为几乎所有团队都 AWS 服务 需要一个 IAM 角色才能运作。作为替代方案，您可以使用[权限边界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)仅向开发、测试、启动和管理您的云基础设施的用户授予 IAM 访问权限。有关策略示例，请参阅[权限边界示例](https://github.com/aws-samples/example-permissions-boundary) (GitHub)。

开发运营 (DevOps) 团队，也称为*平台*团队，通常需要在多个内部开发团队的自助服务功能与应用程序运行稳定性之间取得平衡。在工作场所培养一种弘扬自主性、精通能力和目标的工程文化可以帮助激励团队。工程师们希望以自我指导的方式完成工作，而不必依赖他人为自己做事。如果 DevOps 团队能够实施自助服务解决方案，则还可以减少其他人依赖他们完成工作的时间。