前言
卓越操作定义
卓越操作支柱是AWS架构完善框架的五大支柱之一，侧重于运行和监测系统以提供业务价值，并不断改进流程和程序。关键主题包括：管理和自动化变更、响应事件以及定义标准以成功管理日常操作。
这份白皮书阐述了AWS架构完善框架五大支柱中的卓越操作支柱，它讨论了操作筹备、操作实施、操作演进三个方面的概念、设计原则和最佳实践，指导架构师、软件开发人员在基于AWS平台设计、交付和维护软件时应用这些最佳实践。
下面的内容是我阅读AWS架构完善卓越操作白皮书时整理的笔记和心得。
卓越操作设计原则
- 使用代码进行操作
应用基础设施即代码、使用代码进行变更、使用代码响应事件，减少人为操作失误导致的失败，快速响应事件。 - 为文档做注释
手工创建文档时自动生成注释、每次构建时自动生成注释文档，注释文档能够被人或系统使用（作为操作代码的输入），具体应用场景？ - 进行高频、小型、可逆的变更
代码尽快入库、入库的代码尽快上线生产环境，尽可能保证一次变更的变更内容单一，从而提高变更成功率、缩短变更时长、缩短变更失败回退所需时长。 - 持续改进操作流程
在操作过程中注意不足之处，寻找能够改进的地方，确定一个固定的时间对操作流程进行回顾、讨论、完善，确保团队熟悉这个过程。 - 预见错误的发生
即提前进行故障场景梳理，分析影响，并制定必要的应急响应预案，确定一个固定的时间（“竞赛日活动”）进行运维演练，检验响应预案的有效性以及团队是否具足够的故障响应能力。 - 从所有操作失败中学习
从所有操作事件和失败中汲取经验来推动改进，将经验在团队内部，以及整个组织范围内进行分享。
筹备
确定优先级
团队内处理问题时有必要对问题优先级进行讨论，建立共识。这样能够大大减少因认识不统一，目标不统一导致的团队内冲突。
举个例子，实现运维需求时，需要根据业务要求对需求进行排序，如果我们把运维的需求划分为两大类：
- 第一类：对系统发布速度有提升的需求
- 第二类：对系统可靠性有提升的需求
如果客户希望能够快速看到运行起来的系统原型，对于可靠性要求暂时不高时，那么可以适当地把第一类运维需求的优先级提高，以快速迭代交付新的演示功能；反之，若是在服务已公测或商用，使用者数目较大时，则需要优先实现第二类运维需求，提高系统可靠性，确保SLA达成。
再举个例子，当on-call接收到现网事件时，对于用户报障类的问题，应该优先考虑恢复，而后再进行定位问题。如果是开发兼任on-call，而不是训练有素的专业on-call，很可能会习惯性地花费大量时间定位根因。这样客户可能会不满意，客户迫切想要的可能是快速规避问题，恢复业务，减少损失，降低名誉伤害。
设计时考虑操作
AWS建议在设计工作负载时，就考虑把部署、变更、监控，告警纳入考虑。这些领域主要包括：基础设施即代码，持续集成与持续部署，监控，告警，分布式追踪等。
相关的AWS服务：AWS CloudFormation，AWS Developer Tools（AWS CodeCommit、AWS CodeBuild, AWS CodePipeline，AWS CodeDeploy, and AWS CodeStar），AWS CloudWatch，AWS X-Ray…
有经验丰富的SRE或是擅长CICD工程师在服务孵化的早期就参与进来，对于服务卓越操作目标的达成将非常有帮助。
准备度评估
阅读过《Google SRE运维解密》这本书的同学，看到这个小标题时一定联想到到了书中提出的PRR模型吧！PRR（Pilot Readiness Review，试点准备度评估）模型是Google提出的用于评估一个系统的运维能力是否满足上线生产环境的要求的模型。
回顾一下，这个模型都讲了些什么呢？其实就是一份Checklist，比如：服务的架构设计是否满足规范、基础组件的选型是否使用公司内部基础设施工程部提供的标准的公共组件、可靠性（系统可靠性，数据可靠性，运维可靠性，可靠性管理）是否满足要求、可运维能力（监控，告警，日志采集，调用链能力是否具备）、基于业务场景的故障梳理，进行运维演练，测试故障处理流程，应急响应预案是否有效…
不在这个模型里的一点应该是对处理事件的人员进行培训，确保他们具备足够的知识和技能。
相关的AWS服务：AWS Config（配置基线话，如果更改了配置导致系统故障，能够快速回退到上一份正确的配置，快速恢复环境），AWS System Manager
操作
理解操作健康
一次成功的操作代表新的配置生效了，或者新的特性上线了，并且原有的和新增的拨测用例都还能执行成功。AWS建议通过定义明确的业务和技术指标，并把它们呈现在看板上，以便在操作失败时快速得到反馈，并及时作出响应。
相关的AWS服务：Cloud Watch Log/Event，Personal Health Dashboard，Service Health Dashboard，AWS Elastic Search。
响应事件
这部分谈论的是事件管理费流程。事件分类，预料的和未预料的。处理事件需要依据一个不断完善的事件处理流程。这个流程需要保证事件的处理进展和问题影响能够及时地同步到关心事件的相关团队，处理阻塞时要分层上升，以便请求更强的资源帮助问题解决！问题解决要追求根因分析，从源头上解决问题，避免再次出现相同的问题。
相关的AWS服务：AWS提供了一些服务能够监控某些事件的发生（Cloud Watch），配置规则（Cloud Watch Rules），触发目标服务（Cloud Watch Target）执行预定义的操作（Cloud Watch Event）作为响应，比如：发送短讯通知（SNS），执行Lambda函数（AWS Lambda），执行EC2实例任务，自动伸缩动作（Auto Scaling）
另外，AWS也对一些第三方的监控，数据处理软件提供了支持，能够把数据通过API发送给第三方应用。
演进
通过经验学习
定期分析失败用例，并从中学习，避免团队，或者所处的更大的项目组避免重蹈覆辙，这是非常有意义的。
AWS能够帮助聚合操作活动，工作负载，或者基础设施的日志（CLOUD WATCH），并提供相关的工具帮助分析我们的操作，趋势或者不同系统在不同配置下对操作的响应结果，基于此，我们能够分析计划改进。
相关的AWS服务：Amazon QuickSight，Amazon Athena，Amazon S3，Amazon CloudWatch
分享学习收获
在团队内、不同团队间、组织内分享文档，标准的基础设施模板，有需要时可对分享的资源设置必要的访问权限。
相关的AWS服务：AWS Identity and Access Management，Amazon SNS，AWS CodeCommit，AWS Lambda，AWS CloudFormation，Amazon Machine Images（AMI）
总结
以上筹备、操作、与演进三部分内容可总结提炼出以下卓越操作最佳实践：
- 运维人员需要理解业务和客户需求才能有效、高效支撑业务
- 运维人员创建操作流程并在实践中检验流程是否有效支持业务需要
- 运维人员需要通过制定、采集指标来衡量目标达成情况
- 业务场景、业务优先级、客户需求会不断发生变化，在变化来临是，需要能够及时调整操作流程以适应改变
心得感想
从持续改进操作流程到当责文化
确保团队熟悉相关的重要流程很重要，但是制定符合实际、具备可操作型的流程更重要，制定安排工作计划时也是。如果流程规范/工作安排不是切实可行的，团队成员默默接受遵循/进行不切实际的流程规范/工作的要求，放弃主动思考流程规范中存在的问题、工作的实际内容合理的工时并提出自己的看法，可以预见的是团队成员将无法遵循规范或按时完成工作，这对团队内当责文化的建立非常不利。
AWS卓越操作支柱与Google SRE
AWS卓越操作支柱中的设计原则和最佳实践与Google提出的SRE指导思想和最佳实践具有相似性：
| AWS架构完善之卓越操作支柱 | Google SRE |
|---|---|
| 运维人员需要理解业务和客户需求才能有效、高效支撑业务 | 制定针对用户的服务质量目标，并且努力去达到这个质量目标 |
| 运维人员创建操作流程并在实践中检验流程是否有效支持业务需要 | 用超过10年的时间打磨发布流程，并发现好的发布流程具有的一些特征：轻量级、鲁棒性、完整性、可扩展性... |
| 运维人员需要通过制定、采集指标来衡量目标达成情况 | 建立全方位的监控与警报系统 |
| 从所有操作失败中学习 | 事后总结哲学 |
参考链接
- https://d1.awsstatic-china.com/whitepapers/architecture/AWS-Operational-Excellence-Pillar.pdf
- https://amazonaws-china.com/cn/architecture/well-architected/
- https://amazonaws-china.com/cn/blogs/apn/the-5-pillars-of-the-aws-well-architected-framework/q