AWS 架构最佳实践（十二）

可靠性

基本概念

可靠性

• 系统从基础设施或服务故障中恢复、动态获取计算资源以满足需求减少中断的能力
• 系统为最坏情况做好准备，对不同组件实施缓解措施，对恢复程序进行提前测试并且自动执行。

可靠性实践

• 测试恢复程序
  • 在本地环境中，证明系统在特定场景下是可以正常运行的，测试系统是如何发生故障并验证恢复程序。
  • 使用自动化来模拟和重现故障，确认故障路径，以便在故障发生前进行测试和纠正，从而降低为测试组件出现故障的风险
• 自动从故障恢复
  • 通过监控系统的KPI指标，达到阈值时就触发自动化进程，实现自动故障和跟踪故障，启动可解决或修复故障的自动化进程，甚至在故障发生前就预测和规避它
  • 水平扩展提高聚合系统的可用性
• 横向扩展以提升系统可用性
  • 将大型资源替换为多个小型资源，以降低单点故障的影响
  • 在多个小型资源间分配请求，以确保他们不会发生同样的故障而成为单点故障
• 停止猜测容量
  • 本地系统发生故障的原因通常是资源达到饱和，即需求超过容量
  • 在云中，可以监控需求和系统的使用率，从而自动添加删除资源
• 自动管理变更
  • 基础设施内的变化都应该以自动化的形式实现

备份与恢复

• 基本的灾难恢复系统，将数据备份存储到S3中
• 恢复时，使用AMI创建EC2实例，然后通过S3将数据复制到EC2的数据卷中
• 需要注意：
  • 选择合适的AMI或根据自己的需求创建AMI
  • 如何从备份中还原系统 - 提前准备就绪的AMI、ELB模板
  • 如何做一致性的配置部署 - 利用CloudFormation自动化部署核心网络
  • 如何切换到新系统 - 调整DNS指向

• 冷备份
  • 提前将数据库数据复制到AWS，且前端服务器已经准备好但并未运行， Route53实现两套系统间的网络切换
  • 故障时，启动EC2实例并使用数据的最新副本，然后Route53重定向到新的服务器。
  • 是一种成本效益比较高的方案

• 完全运行的低容量备份
  • 两个正在运行的系统，一个主系统一个AWS低容量系统，使用Route53分配请求
  • 主环境不可用时，Route53 切换到辅助系统，并且自动向上扩展容量
  • 随时可以处理部分工作，同时又相对节约成本
  • 适合于持续测试的甚至AB测试环境

• 多站点主动备份
  • 完整功能的系统同时运行在本地和AWS上面
  • 可以随时处理所有生产负载
  • 对所有生产负载进行故障转移

• AWS 用于灾难恢复的优势
  • 可以灵活使用各种构建模块
  • 对成本精细控制和RTO/RPO之间的权衡
  • 轻松有效的测试灾备计划
  • 可以在全球多个位置运行

可靠性Q&A

• 如何管理账户的服务限制？
  • 监控和管理限制，评估AWS潜在使用量，适当增大限制并允许计划的使用量增长
  • 设置自动化监控，实施相应工具，以便在接近阈值时发送提醒
  • 了解固定的服务限制，并围绕这些限制进行架构
• 如何在AWS上规划网络拓扑？
  • 在云内和云外使用不重叠的私有IP地址
  • 在云内规划足够大的IP子网，以满足未来扩展的需求
  • 使用高可用的网络连接，如多条Direct connect，VPN隧道或Marketplace 设备
  • 使用系统的高可用配置，如ELB和代理，基于DNS的解决方案等
• 如何适应需求变化？
  • 使用自动扩展服务，包括S3，CloudFront，AutoScaling，DynamoDB，Elastic Beanstalk
  • 采用负载测试方法来衡量扩展活动是否将满足应用程序需求
• 如何监控AWS 资源
  • 通过CloudWatch 或第三方工具监控应用程序
  • 配置通知，以便接收告警等信息
  • 在检测到故障时自动化采取措施
  • 根据重大事件经常审核和评估架构
• 如何执行变更管理
  • 自动执行的部署和修补的变更管理
• 如何备份数据
  • 对重要数据进行备份以满足RPO - S3，EBS快照等
  • 对环境等进行自动备份
  • 保护和加密备份
  • 做定期恢复测试以确保是否满足RTO和RPO
• 系统如何承受组件故障
  • 在资源池前面部署ELB
  • 在多个可用区/区域间分配应用程序
  • 配置通知，接收重大事件的通知
  • 持续监控系统运行状况
  • 使用自动修复功能检测故障并执行修复工作
• 如何计划修复
  • 定义RTO和RPO目标
  • 明确并提高灾备站点的服务限制以适应故障转移
  • 制定灾难恢复策略
  • 定期测试和验证故障恢复场景以确保满足RTO和RPO目标
  • 使用AMI确保灾备站点为最新状态以避免配置偏差
  • 利用AWS或第三方工具自动实施系统恢复

性能绩效

性能绩效原则

• 能够高效使用计算资源满足系统要求，又在需求变化时能够维持该效率
• 将高级技术大众化
  • 将知识和复杂性转移到云服务提供商中，让传统难以实施的技术作为服务使用即可。
• 采用无服务器架构
  • 无需运行和维护服务器即可执行传统的计算活动，消除管理服务器的运营负担降低事务成本
• 数分钟内实现全球部署
  • 能够以最少的成本更加灵活的提供更低延迟和更好的体验
• 提高实验频率
  • 利用虚拟和自动化资源，可能对不同的配置进行快速执行对比测试
• 机器同理心
  • 无需深入了解所有服务，但是需要了解如何更好地使用各种服务，对业务进行设计

性能绩效实践

让基础设施更高效

• 选择适当的计算服务
  • 计算服务包括EC2，ECS 和 Lambda
  • 评估应用程序最重要的指标，并选择适当的实例系列和类型
  • 避免过度预置和预置不足
  • 随需求变化更改实例大小和类型
  • 应用程序设计支持水平扩展，并且可灵活的重启
• 选择适当的存储
  • 需要考虑特定的系统最优存储方案取决于访问方式（块存储、文件存储还是对象存储）、访问模式（随机还是连续）、数据吞吐量要求、访问频率（在线、离线还是归档）、更新频率（WORM [一次写入，多次读取] 还是动态）以及可用性和持久性的限制。

• 选择适当的数据库
  • 在选择数据库方案的时候，我们需要考虑到很多特性，比如数据库可用性、一致性、分区容错性、延迟、持久性、可扩展性喝查询能力等。

• 选择适当的网络
  • 设计系统最优的网络解决方案的时候，我们需要考虑到延迟、数据吞吐量等因素。
  • 我们可以使用S3传输加速、CloudFront内容分发服务、Route53基于延迟的路由、AWS DirectConnect等方案来解决延迟和卡顿的问题

性能Q&A

• 如何选择适当的解决方案？
  • 预计资源能力需求
  • 所需的内部监管标准
  • 成本/预算
  • 基准测试结果
  • 负载测试结果
• 性能调优的主要考虑
  • 计算主要考虑 实例的CPU、内存、存储和联网容量的不同组合，以及应用程序是否支持自动扩展，以及是否可以采用无服务架构根本上改变工作负载诉求
  • 存储主要考虑成本、容量、吞吐量、持久性和可用性的平衡，AWS 提供包括备份、存档和灾难恢复的选项，支持数据块、对象和文件存储
  • 延迟主要考虑物理距离，网络延迟和长时间运行导致的系统延迟以及缓存性能，需要从终端用户的角度考虑端到端的性能优化
• 随着新服务和新功能的推出，如何持续确保选择了最优的解决方案？
  • 定期检测并根据预计的资源需求重新选择服务和功能
  • 对每项新功能做基准测试和负载测试，并根据性价比做出最佳选择决策
• 如何监控坚决方案以确保按预期方式运行？
  • 使用CloudWatch或第三方工具进行持续监控
  • 定期检查监控仪表盘
  • 基于告警的通知，在指标超过阈值时自动提醒
  • 基于触发器的操作，通过自动操作修复或上报问题
• 如何确保解决方案满足容量和吞吐量的需求？
  • 对系统的需求量会因不同周期需求而异，包括产品生命周期、峰值周期、不可预测周期和可预测周期。
  • 通过手动检查指标作出响应
  • 根据指标和已计划的事件来计划未来的容量和吞吐量
  • 针对指标实现自动化
  • 定期检查缓存使用率和增长
  • 不断监控使用率并和需求进行对比
  • 通过脚本工具和AutoScaling 进行自动管理

安全

AWS 安全责任界定

AWS 全球基础架构安全

• 物理环境安全
  • 数据中心建设在隐蔽的建筑物汇总
  • 使用包括视频监控，入侵检测等物理手段
  • 授权人员必须通过至少两次双因素认证
  • 供应商需要授权人员确认和持续陪同
  • 自动火灾探测和气体灭火系统
  • 冗余的电力接入
  • 提供UPS、发电机等备用电源设备
  • 实时的温湿度监测和控制
  • 严格的设备和存储退役流程，防止数据泄露
• 业务连续性
  • 数据中心在全球以集群形式建立
  • 提供全部热数据中心的N+1 高可用部署
  • 每个可用区都设计成一个独立的故障区，各种基础架构是物理分离的
  • 7*24的故障支持团队和流程
  • 多种内外部沟通的渠道和工具，包括用户可订阅的各种支持服务
• 网络安全
  • 部署防火墙等网络安全设备对外部网络流量的监视和控制
  • AWS会强制执行基准的ACL规则确保基础架构安全
  • 用户可以在各个管理接口自定义设置各种ACL及流量策略
  • 有限数量的网络接入点便于管理出入站流量
  • 各个接入点都有专用于连接不同ISP的设备
  • 所有通信可以支持SSL或HTTPS连接
• 多种网络攻击应对方案
  • DDoS攻击：专用的DDos缓解技术
  • 中间人MITM攻击： SSH主机证书，鼓励所有交互都使用SSL
  • IP欺骗： EC2不允许发送欺骗性通信，如欺骗性IP和MAC
  • 端口扫描： AWS不允许EC2进行未经授权的端口扫描行为，同时EC2默认关闭所有入站端口也避免被扫描
  • 数据包嗅探： AWS不允许你任何形式的对未发送给本机的流量进行侦听行为，即便在同一个子网中且将端口置于混杂模式也不行。同时始终建议使用加密流量进行传输

安全性实践

• 保障基础设施各个层面的安全
  • 隔离基础设施的各个部分
  • 加密传输和保存数据
  • 最低权限原则精确控制访问
  • 多重身份验证
  • 利用托管服务
  • 记录资源访问日志
• 在各个层面实现安全
  • 主要利用安全组实现
  • 还包括每个边缘防护墙，每个虚拟服务器，每个负载均衡器，每个子网
  • 记录并审核针对环境的所有操作和更改，以及针对服务的访问
  • 监控并自动触发由时间或条件引发的提醒和响应
  • AWS和用户的责任共担模型，AWS专注于基础设施安全，用户专注于应用、数据和操作系统安全
• 自动执行安全最佳实践
  • 使用基于软件的安全机制提高安全的快速扩展能力
  • 创建并保存虚拟机基准镜像
  • 使用模板定义和管理完整的基础设施

• 主要攻击的应对技术
  • AWS Shield 提供DDoS防御服务
    • Shield Stand - 免费， Web 应用程序免受 DDoS 攻击。
    • Shield Advanced 能为 Elastic Load Balancing (ELB)、Amazon CloudFront 和 Route 53 上运行的应用程序提供额外保护，使其免受更大型、更复杂的攻击。
  • WAF 提供基于4层的ACL，以及Cross Site Script 攻击，可以基于String， Size 和IP设置条件筛选
  • Macie 提供基于机器学习的对敏感数据的保护
• DDoS攻击应对方案示例
• 攻击手段
  • 通过各种手段消耗网络和其他资源，最终导致服务终端，是利用多个木马主机进行的定点攻击
• 防御手段
  • 尽量减少攻击面区域
  • 减少不必要的Internet入口，消除非关键性入口
  • 将用户流量和管理流量分开
  • 模糊处理必要的Internet入口，仅允许受信任用户访问
  • 隔离各个入口点，以最大程度减轻影响
  • 利用扩展功能缓解攻击带来的压力，包括： 选择合适的实例，ELB和AutoScaling，Route53内置的扩展
  • 启用ELB，因为ELB只支持有效的TCP请求，可以防止UDP和SYN攻击到达
  • CloudFront具有初步筛选功能，仅通过有效的TCP和HTTP请求
  • 启用Web应用防火墙（WAF），通过对HTTP包头和正文、IP、URI字符串设置规则来筛选Web请求，从而防御非法流量。

安全最佳实践

• Amazon Inspector 自动安全评估服务
  • 评估应用程序是否有漏洞，是否偏离最佳实践，并生成一份详细报告以及补救措施建议。
  • 通过内置的知识库和规则，映射常见的安全合规标准和漏洞定义
• 数据加密 及 KMS服务
  • 将密钥与加密算法（如AES)相结合对数据进行加密，其中对称数据加密适用于对任意数据进行快速加密的场景。
  • 但是，将密钥和加密文本放在一起明显是不安全的，所以最佳实践是使用其他密钥对数据密钥进行加密，再单独存放在系统中。

安全实践Q&A

• 如何加密和保护静态数据
  • 支持AWS服务器端加密，包括S3 SSE， EBS加密卷，RDS TDE透明数据加密
  • 支持客户端加密，包括开发工具包支持，操作系统支持，Win Bitlocker，dm-crypt， Trend Micro SafeNet等
• 如何确保加密的数据传输
  • 启用SSL/TLS 进行通信
  • 使用SSL/TLS API加密终端节点
  • 基于VPN或者Direct Connect的解决方案
  • AWS Marketplace的相关解决方案
• 如何确保AWS根账户安全
  • 非常谨慎的使用根账户，仅针对必要操作使用根账户
  • 使用MFA硬件设备关联到根账户，且不应有API秘钥
  • 使用AWS MarketPlace 解决方案
• 如何定义系统用户和职责
  • IAM用户和组
  • 明确定义用户、组和角色
  • 定义和加强员工生命周期策略
  • 仅授予达成业务要求所需的最低权限
  • 使用SAML集成
  • 联合身份认证
  • 使用AWS STS
  • 用于跨账户的IAM角色
  • AWS Marketplace 解决方案
• 如何限制对AWS资源的自动访问
  • 不要使用硬编码的方式将凭证写入脚本和源码
  • 使用IAM实现角色管理
  • IAM用户凭证
  • SAML集成
  • AWS STS
  • 针对特定EC2的特定控制
  • AWS Marketplace 解决方案
• 如何管理密钥和凭证
  • 不要使用硬编码的方式将凭证写入脚本和源码
  • 使用合适的密钥和凭证轮换策略
  • AWS CloudHSM
  • 支持AWS托管密钥的AWS服务器端加密技术
  • AWS Marketplace 解决方案
• 如何强制实施AWS服务级保护
  • 配置最低权限凭证
  • 划分职责
  • 定期审核权限
  • 定义并使用特定服务的要求，定义不同资源级别的控制
  • 针对敏感API调用使用MFA身份验证和加密等
  • AWS Marketplace 解决方案
• 如何在EC2上保护操作系统完整性
  • 针对EC2实例的控制包括文件完整性和基于主机的入侵检测
  • 使用自定义AMI或者配置管理工具（Puppet，Chef）等实现一致性部署
• 如何捕获和分析AWS日志
  • AWS CloudTrail
  • Amazon CloudWatch
  • ELB日志
  • VPC 筛选日志
  • S3存储通日志
  • 操作系统或第三方日志
  • AWS Marketplace 解决方案

AWS 合规性

概述

• 实现合规性治理的基本方法：
  • 采取整体方法。查看AWS提供的信息以及所有其他信息，尽可能多地了解IT环境并记录所有符合性要求。
  • 设计和实施控制目标以满足组织的合规要求。
  • 识别并记录所有第三方拥有的控制。
  • 确认所有控制目标均已达到，并且所有关键控制措施的设计和运行均有效。
  • 传统上，控制和控制目标的设计和运行有效性由内部和/或外部审计人员通过流程演练和证据评估进行验证。通常由客户或客户的外部审计师直接观察和验证以验证控制，

具体控制方法

• 关键控制对于客户的控制环境至关重要，并且需要外部证明这些关键控制的运行有效性以满足合规要求，
• SOC 1审核是对设计和运营有效性的深入审核的AWS定义了控制目标和控制活动（包括AWS管理的基础设施部分的控制目标和控制 活动）。“类型II”是指报告中描述的每个控制措施不仅要评估设计是否充分，还要由外部审核员对操作有效性进行测试。
• 如果AWS客户需要满足广泛的控制目标，则可以执行AWS行业认证评估。
  • 通过ISO 27001认证，AWS符合广泛而全面的安全标准，并遵循维护安全环境的最佳实践。
  • 通过支付卡行业（PCI）数据安全标准（DSS）认证，AWS符合一套对处理信用卡信息的公司很重要的控制。
  • AWS遵守联邦信息安全管理法案（FISMA）标准意味着AWS符合美国政府机构要求的广泛的特定控制。
  • AWS遵守这些通用标准为客户提供有关AWS云中控制和安全流程综合性质的深入信息。

风险与合规计划

• 风险管理
  • AWS制定了战略业务计划，包括风险识别和实施控制以减轻或管理风险
  • AWS每年重新评估两次业务风险计划
  • AWS安全推按对会定期扫描任何面向公众的IP地址以查找漏洞
  • 独立安全公司还定期执行外部漏洞威胁评估
• 控制环境
  • AWS管理由策略、流程和控制活动组成综合环境控制
  • AWS控制环境是一套至上而下的框架和实践
• 信息安全
  • 使用正式的信息安全计划以保护客户系统和数据的机密性、完整性和可用性

标准符合

• 符合以下安全标准
  • SOC 1/2/3
  • FISMA
  • DoD DIACAP
  • FedRAMP
  • DoD SRG Level2 and 4
  • PCI DSS Level1
  • ISO9001 / 27001
  • ITAR
  • FIPS 140-2
• 其他工业标准
  • CJIS
  • CSA
  • FERPA
  • HIPAA
  • MPAA

成本优化

概述

设计原则

• Pay-as-you-go的消费模式：
  • 我们仅根据自己业务消费的要求来申请资源，同时随时添加和减少资源的数量，最终只为实际的消费付费。
  • 规模经济效益： 数十万家客户都使用AWS的云服务，因此我们可以获得更加优惠的服务单价。
• 不需要为数据中心运营支出：
  • AWS会负责数据中心的搭建、服务器机架安装、部署和电力供应等问题。我们不需要花费大量人力物力到这些事情上面，我们只需要专注于我们的业务即可。
• 支出分析和原因分析：
  • 云环境中的所有花销都可以很清楚、很准确地被看到，我们可以更加透明地对IT成本进行归因，从而帮助我们量化投资回报率（ROI）和更好地为削减成本提供决策。
• 使用托管服务来降低拥有成本：
  • 使用AWS托管服务，我们可以不需要操心例如邮件发送或者数据库管理等工作带来的负担。而且托管服务以云规模的方式运行，我们可以享受到更低的每事务/每服务的单价成本。

成本意识

• 确保资源规模适当，可根据需要扩展或缩减，并且可以利用不同的定价规则
• 需要考虑应用相应的应用规模需求
• 资源使用频率
• 监控指标
• 可否用托管服务替代服务器
• 确保未使用的资源处于禁用状态

成本优化定义

• 使用成本效率高的资源
  • 我们需要确保对配置的资源进行优化调整，控制其容量处于合理的水平。
• 供需匹配
  • 最优供需匹配应能够为特定系统提供最低的成本，同时还可以具备充足的资源来满足业务的需求，我们可以利用监控指标和自动化机制来保证我们的工作，以及确保不产生过高的成本。
  • 我们可以使用CloudWatch服务来监控我们的需求
  • AutoScaling可以帮助我们事先动态的弹性伸缩
  • Serverless无服务架构也可以帮助我们实现完美的供需匹配
• 支出认知
  • 使用AWS服务，我们不需要再介入到冗长的采购流程中
  • 我们可以点几下鼠标就创建了我们需要的服务和基础架构
  • 我们可以使用Tag标签来追踪我们不同类型的服务支出
  • 我们可以使用账单告警来防止我们误操作导致的高费用
  • 我们可以使用整合账单（Consolidated Billing）来对账单进行整合
  • 我们可以使用成本管理器来估算我们年度的AWS费用
• 不断优化
  • AWS的发展速度非常快，每一年会创新出成千的新服务（可以参照下图）。因此我们在为架构进行设计的时候，也可能需要不断地对架构进行优化。
  • 以前我们可以使用Mysql数据库，现在可以使用Amazon Aurara数据库来作为替代品
  • Lambda和Serverless也可能是替代一部分EC2的更新的方案
  • 我们可以使用Trusted Advisor服务来查看推荐的改进方案

成本优化思路

• 持续避免或消除不必要的成本或非最优资源的能力
• 以透明的方式确定支出归属
  • 可以标识IT成本并将其归属到各个业务所有者
  • 确定的投资回报率NOI，激励业务所有者降低成本
• 使用托管服务降低拥有成本
  • 托管服务可以移除运营服务器的运行负担，从而降低事务的服务成本
  • 将资本投入变为运营投入
  • 无需提前投入大量资金采购资产，而仅需要按需付费
• 从规模经济中受益
  • 由于AWS自身的规模化从而降低服务价格，使各个客户受益
• 停止在数据中心运营方面投入资金
  • 利用AWS，不用再自行建设或租用数据中心或机柜，可以更专注于客户和业务

成本优化实践

• 通过 AWS Trusted Advisor 获取成本优化建议
• 通过缓存优化成本
  • 可以分流的内容越多，需要维护、扩展和付费的基础设施就越少
  • 常见的分流包括CloudFront 和 S3 以及引入缓存

• 所有内容均可缓存

• AWS计费工具
  • 月度成本结算工具
  • 根据使用情况估算AWS云中运行解决方案的成本
• 总体拥有成本TCO计算器
  • 估算使用AWS节省的成本
  • 详细报告可用于演讲
  • 修改最能满足业务需求的假设

成本问题Q&A

• 如何确保容量匹配而不会大幅度超出所需容量
  • 避免过度利用和过度配置
  • 使用AutoScaling 按需提供容量
  • 利用SQS基于队列提供容量
  • 使用计划功能根据时间来提供容量
  • 适当的预配置
• 如何优化AWS服务使用率
  • 针对具体服务优化
  • 最大限度降低EBS的IO
  • 避免上传小文件到S3中
  • 针对EMR广泛使用竞价实例
• 是否选择适当的资源类型来满足成本目标
  • 通过需求来匹配实例配置文件
  • 通过CopperEgg 或 New Relic 等第三方产品来确定适当的实例类型
  • 使用Amazon CloudWatch 来确定处理器或内存负载
  • 根据应用程序确定使用哪种EBS （磁性、通用性、预配置IOPS等）
• 是否选择了适当的定价模式满足成本目标
  • 针对特定工作负载使用竞价实例
  • 定期进行使用情况分析，并相应购买预留实例
  • 选择区域时，考虑成本因素
  • 不需要时，自动关闭未使用的实例
  • 在预留市场中出售不再需要的预留实例或购买其他实例
• 是否有可用来提高ROI的托管服务
  • 应用服务：SQS，SNS，SES
  • 标准化和成本控制服务： CloudFormation，Beanstalk，OpsWorks
  • 考虑适当的数据库： RDS， DynamoDB等
• 使用哪种访问控制和程序管理AWS使用率
  • 使用IAM创建组和角色，并精确控制对资源的使用权限
  • 跟踪、衡量并审核项目团队及环境的生命周期，并相互制衡方式来实现创新及避免超支
• 如何监控使用率和开支
  • 标记所有资源，并将资源使用变化与账单变化关联起来
  • 制定标准流程加载和解读详细账单报告
  • 在制定经济高效的架构同时，制定使用计划和支出计划
  • 使用CloudWatch等工具定期监控使用和支出情况
  • 设置通知以让管理员了解是否超支
  • 采用以资金为导向的逆向计费方法来将实例与资源分配到成本中心
  • 使用AWS 成本管理器
• 是否停用了不再需要的资源
  • 确保系统设计能够有效处理不再需要的实例终止
  • 制定流程以确定并停用孤立的资源
  • 根据系统或流程对已停用的资源进行协调
• 设计架构时是否考虑过数据传输费
  • 使用CloudFront CDN降低读取流量费用
  • 确保架构能优化数据传输
  • 分析如果使用AWS Direct Connect 是否能节省费用并提升性能
  • 平衡数据传输与HA和可靠性需求

卓越操作

设计原则

• 利用代码执行操作：
  • 我们可以将所有云环境中的基础架构都定义为代码，并且通过代码管理和更新它们。我们可以将操作步骤做成脚本，通过事件响应来触发脚本的自动执行。这样子可以减少人工的错误，保证对事件响应的一致性。
• 进行频繁、小型、可逆的变更：
  • 对工作负载中的组件进行定期更新，并且保证这些更新是小型的、增量的、可逆的。而不是大型的、批量的更新。
• 预见失败：
  • 通过“预演”来找出潜在的不足之处，并且从中找到并解决有可能的系统薄弱点。同时可以让操作人员熟悉这个响应过程和处理方法。
• 从失败中汲取经验：
  • 通过所有操作事件和失败中汲取经验来推动改进。将汲取的经验在团队内部或整个组织内进行分享。
• 注释文档：
  • 所有的文档可以在构建后自动注释，并且可以让注释文档作为你的操作代码输入。同时，需要保证文档的版本持续性地进行更新。
• 经常优化操作流程：
  • 寻找机会优化操作流程，组织定期的Game Day促销日来验证流程的有效性，并且让团队成员熟悉这么流程。

定义

• 筹备（Preparation）
  • 团队应该对整个工作负载，他们在其中的角色，以及共享的业务目标有一个共同的理解，从而设置能够帮助业务成功的操作优先级。
  • 你需要通过日志记录以及富有洞察力的业务和技术指标进行观察。
  • 你应该有一致的流程来了解何时准备好启动工作负载。
  • 核心服务：Cloudformation, AutoScaling, AWS Config, Tagging
• 操作（Operation）
  • 团队应该能够掌握工作负载的运行状况，你将系统通过基于运行结果的指标来获取有用的见解。你应该使用这些指标来实施具有业务和技术观点的仪表盘，来帮助团队成员做出明智的选择。
  • 你应该遇见操作事件，包括计划内的事件和计划外的事件，并且尽量自动化。
  • 可以创建CI/CD流程 （源代码仓库、系统搭建、测试/开发自动化等）。
  • 核心服务：AWS CodeCommit, AWS CodeDeploy, AWS CodePipeline, AWS CloudTrail
• 演进（Response）
  • 在出现故障时，保证你的团队能够从失败中汲取经验，并且制定改进计划。
  • 分享团队的学习收获，增加整个团队的收益。
  • 核心服务：CloudWatch