开发者学堂课程【容器服务混沌工程实践：容器混沌工程】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1078/detail/15562
容器混沌工程
内容介绍
一、背景信息-疫情之下云原生加速企业上云
二、主要问题-如何在以Kubernetes为基础的容器服务上构建完美的运维体系
三、整体架构
四、核心组件介绍
五、运维体系构建
六、用户角色分析
七、核心场景介绍
八、客户案例
本章分享主题为：阿里云容器服务混沌工程实践，主要介绍以容器服务为核心，基于混沌工程去完成用户运维体系构建。
一、背景信息-疫情之下云原生加速企业上云
1.企业转型原因分析
疫情时代，员工无法线下拜访客户、实体销售业绩大幅下滑、工厂无法复工复产，驱动了企业加速IT信息化转型（上云）的节奏。
由图中服务器可知，在中国服务器整体市场规模上近几年基本上有20%的增速增长，说明从云原生的角度而言，其业务在不停扩张，同时通过查看CNCF的一些数据统计，在过去两年的生产环境中云原生的运用增长超过200%，说明企业逐渐从上云的方法发展，同时云原生技术由于其优越性、稳定性导致许多企业IT化转型都向着云原生的方向走。从图中的两样数据来看，过去几年在做云原生转型的多为实力丰厚的公司，他们丰富的经验使其能够很好的实现云原生的转型。
2.云原生转型要解决的问题
云原生技术成为了很多企业T信息化转型弯道超车的最佳途径，云原生转型后，如何维持生产系统稳定和构建运维体系是首当其冲要解决的问题。
但随着近几年基于Kubernetes的云产品逐渐成熟，越来越多的企业开始转向以Kubernetes为核心的云产品，而过去常常是一些网站或不以其为核心业务，但随着产品逐渐成熟，很多大型政企，金融客户，银行等都开始使用云原生技术。
不仅是因为云原生是未来的技术主流，更是因为云原生有着丰富的生态，优越的功能，开发性和更丰富的解决方案，比如：弹性、快速扩容和微服务架构等等。
虽然此时开发该类产品有强大的功能，但于此同时也带来了复杂的架构和多样性，企业在使用容器服务时，对于保证生产期的稳定和高可用，往往也面临巨大的挑战和压力。因为在进行云原生改造后整个运维体系都会被重构掉，而想要在云原生体系下构建自己的运维体系就是进行云原生转型的一大问题。我们常说企业是生产体系的第一责任人，企业需要为自身的系统稳定性负责，因此在云原生转型中首先就需要考虑生产系统稳定和运维体系的构建。
二、主要问题-如何在以 Kubernetes 为基础的容器服务上构建完美的运维体系
l 基于疫情之下云原生加速企业上云的背景信息，主要得出以下几个问题：
第一，需要对故障场景进行分析，第二，要对系统进行完善告警，第三，当故障来临时对其进行快速定位和恢复，第四，将一些历史的经验，对系统的理解转变为自动化运维的工具，最后提高系统的运维能力和自愈能力。
1. 故障场景分析
Ø 分析生产系统的故障场景
Ø 难度：一星
l 都需要根据各自系统特点进行故障场景分析
历史故障：可根据当前系统过去发生的历史故障去做故障场景分析，从而针对性的去做场景增强。
系统架构：根据现在的生产系统架构，如：多活的，主位的或有单点问题等的架构去进行分析。
社区经验：常说“太阳底下无新鲜事”，自己遇到的问题，别人也常会遇到，将真实世界发生的案例引入我们自身系统中，观看在历史的故障中是否有类似问题。如：机房断点、光纤被拉断此类偶然会遇到的重大故障。
2. 监控及告警
Ø 也需要根据系统特性配置监控和告警
Ø 难度：二星
l 系统监控
对于各个业务的监控曲线，观察每个业务指标的趋势、异常时间点，出现毛刺、故障时间点的指标、常用指标都需根据系统特性进行配置。
l 故障告警
告警通知有效性和实时性：含有监控后，需在监控上表现异常的点，配置故障告警。故障告警重要的一点是如何了解告警的有效性和实时性，因为保证了该点，才能使得故障的快速恢复等，都需要系统的沉淀及思考。
3. 故障恢复
Ø 快速定位和恢复生产故障
Ø 难度：四星
故障来临后首要的是快速定位问题，然后恢复生产故障进行“止血”的操作，正常是基于现有的告警、日志和已有的故障处理经验，利用文档或工具快速定位和恢复生产故障。
4. 自动化运维
Ø 提高系统的自愈能力
Ø 难度：五星
在运维中希望的理想状态为在系统能高可用、能自愈，面对风险和故障的时候，能做到业务系统不受影响，但常难以完成，需要长时间的建设、沉淀和自理。通过通过自动化运维工具和优化系统架构，从而实现故障场景下系统的高可用和自愈能力
5. 总结
整体而言，不论是否进行云原生改造以上的运维体系都是需要的，而在进行“上云”时建设有效的告警体系、沉淀故障处理的手册和工具，同时优化系统运维流程是保证生产系统稳定性的关键措施。
三、整体架构
基于之前提出的问题，要使用容器混沌工程去优化运维体系，通过如下的整体架构图，可知混沌工程中有一个控制台，可通过其下发故障场景。
1. 运维体系的优化流程
混沌工程中首先会建设一系列的监控、告警、运维体系和工具，要验证该套体系的有效性。可通过混沌工程的故障演练，触发系统的故障，然后在系统的故障中去检验整个运维体系是否存在漏洞，然后再去优化整个运维体系，优化完成后可通过混沌工程去检验优化后的效果，形成一个正循环，由此往复的完成运维体系的优化。
2. 整体架构介绍
第一部分为混沌工程的控制台，通过控制台去下发各色的故障场景，如：在开发上的API Service故障、Node故障和Pom故障都可通过混沌工程的方式进行注入，下发故障场景后，还有管控组件，如：AHAS Service和AHAS Gateway,两者主要是用于集群交互，用于管理故障场景，之后通过管控组件将故障注入到整个开发集群中，在集群中的每个节点上会部署一个Ahas Agent，Ahas Agent核心为ChaosBlade组件，该组件为阿里云的组件。在Ahas Agent中可接受上层下发的故障命令，再去相应的Node上触发相应故障。
如：Node上的内存cpu异常等，同时还配套有监控和告警的组件产品，如：云监控（可做基础资源，节点监控，cpu内存等）;同时还有云原生体系下配套的Prometheus可对整个集群的数据进行搜集和分析，其次还有阿里云上的日志服务SLS能对异常的日志信息做搜集和告警。
通过这些工具和产品可将一些集群的状态做监控、资源曲线大盘、API组件的状态大盘，能够查看所有组件的运行状态、其次还可根据业务特性，自定义配置业务指标，如：业务运行成功率、延时等等。
其次，还可根据已有的经验配置告警规则，如：API节点的Docker进程异常，就需要触发告警并配置联系人，对其进行分组，以上都是我们建设好的能力。
最后告警发生时，需要进行故障处理，首先会在告警通知上明确现在是何组件的业务出现了异常而导致告警。同时在官方的文档中也提示有常见的SOP处理手册，可根据手册去处理已有故障，同时客户也可沉淀自己的处理文档，未来通过告警去进行文档关联故障的分析。
以上就是容器混沌工程的整体架构业务流程。
四、核心组件介绍
1. AHAS Service
主要用来接受控制台下发的服务
（1）核心功能
①混沌的后端服务，用来下发演练命令，管理演练数据
②通过流程编排来创建故障演练场景
③分布式部署，保证演练功能的高可靠
2. AHAS Gateway
（2）核心功能
①AHAS Gateway是混沌的代理网关服务，负责管理部署在各个集群内上的AHAS Agent。
3. AHAS Agent和Chaos Blade
两者是做混沌工程核心的组件。
Ø AHAS-Agent：
①使用Kubernetes的方式安装在指定的目标机器的Node上，用来执行服务端下发的故障注入命令
②采集演练相关的必要信息，上传到管控服务区去做数据展示，比如CPU、内存占用等
Ø Chaos Blade :
① 阿里云的开源组件，也是AHAS Agent的核心组件，用来解析、校验和执行服务端下发的故障指令
② 具有丰富的演练场景，如：对基础资源做故障注入和演练。
l 基础资源
CPU、内存、网络、磁盘、进程等
l Kubernetes
节点上CPU、内存、网络、磁盘、进程等
可对容器内的实验场景进行实现，例如删除容器某个pod、容器内CPU、内存、网络、磁盘、进程等做高负载的演变和验证。或随机kill掉容器的某个进程以此模拟业务容器故障的场景。
五、运维体系构建
要在容器服务的场景之下，构建一个运维体系，首先对于运维体系这个庞大的话题而言，是一个流程+工具的场景，既有要流程保证运维体系能够运转，同时还需工具保证流程能够持续优化。主要阶段分为以下几步：第一，需要构建用于演练的环境；第二，需要对系统和故障的场景进行分析；第三，需要在我们自己的生产系统上建造1-5-12的机制；第四，最后根据沉淀的内容作自动化运维的平台和工具。
1. 环境构建
通常，对于一个稳定可观的业务而言，需要以下的几个环境：
l 开发测试环境：
通常不稳定，是开发和测试用于随时作破坏、测试的环境。
l 验收测试环境：
通常较为稳定，在测试环境中用于和上下游做稳定联调的环境。
l 灰度发布环境：
通常希望在发布生产系统前就做灰度发布环境，因其通常和发布生产环境有着一样的规格、配置和资源，保证能将一部分流量导入灰度发布环境中，通过其灰度功能去验证新的系统是否能在灰度发布环境中去做验证。
l 容灾环境：
为了高可用，在生产环境外常建设一些容灾环境，如：异地容灾、同城容灾等不同容灾场景。对于容灾环境而言，更适合设置与生产系统环境一致，容灾环境上运行的生产系统的生产版本、配置往往都与生产环境一致。由此当真实生产环境出现故障后可将流量直接切入到容灾环境中去做同城容灾、异地容灾，以此保证业务的高可用和持续性。
l 生产环境：
生产环境是生产系统、业务系统稳定运行的环境，该环境通常需要稳定、可靠、24小时的运维。
以上就是所有的环境构建，更多考虑的是多方面，如成本、流程 管理，建议在进行混沌工程运维体系时最少保证有一套测试环境和一套稳定的生产环境，同时测试、生产环境要保证一次性和隔离性。如此在进行演练时可以在测试环境中先去验证，验证后再做生产环境的验证，以此保证生产环境的高可用。
2. 故障场景分析
首先需要含有故障场景，才可以去建设对应的应急预案和工具。对于容器服务而言，最核心的是开发集群，针对开发集群而言总结的场景如下：
l 管控组件故障
n Apiserver/KCM/Scheduler/CCM/Etcd等管控面的组件如何进行恢复。
l 系统组件故障
n 网络组件/存储组件
l 节点故障
n Kubelet
n 运行时Docker
n 节点CPU/内存/网络/磁盘等出现异常如何处理
l 业务容器故障
l 一直承载业务进程的载体也至关重要，但在运行中业务容器的故障往往最为常见
l 如：Pod状态异常、启动失败/CPU/内存/网络/磁盘等异常影响容器内进程的稳定运行如何处理
以上故障场景都需要进行逐个分析后去做预案，之后当故障来临后通过预案做故障恢复。
3. 1-5-12机制
在运维体系中需要建立1-5-10的机制，即希望达到1分钟收到报警，5分钟定位到问题，10分钟完成故障恢复的效果，此为对一个成熟运维体系的最低要求。要实现1-5-10的机制，通常会采取以下措施：
①故障发现
l 监控∶
流量模型/数据分析/度量趋势分析，以此通过事前监控去发现未来故障，如：做容量管理、趋势分析，去发现故障从而及时避免更大问题。
l 告警∶
是生产运维体系不可或缺的步骤，因为当故障真正来临时，需要第一时间做“止血”的操作，因此在告警规则/联系人的建设管理，需要一定逻辑。
②故障处理
l 应急预案︰
针对配置的告警和监控做应急预案的处理，如：ECTC异常后该如何恢复，或APS Service进程异常该如何恢复等等，这些常根据故障场景分析而来，同时也需依赖历史沉淀，因为还需根据历史沉淀去发现系统中的问题，从而弥补系统的不足，同时最好能做到告警关联，以此提高解决问题的时效，如：告警产生后第一时间就可关联应急预案，而后通过预案做直接的恢复，以此大大提升恢复的时效。
l 运维工具
除了预案，还需要一些运维工具去完成告警处理。如：运行时的异常、重启等操作都需要实现准备故障的运维工具。
③故障复盘
在故障发生时，除了了解故障还应该进行复盘，这样才能不停优化系统，而复盘时常有以下方向：
l 故障分析∶
对故障的根因进行分析，同时检查告警配置、联系人配置是否合理，同时检测处理时效、处理方式是否合理，响应处理。
l 故障验证∶
在发生故障并对故障进行完整处理分析后，还会进行优化，就可使用混沌工程的方式模拟同样的故障去检查验证之前优化是否合理，如：ETCT故障为例，给ETCT注入故障以此出发一个告警异常，由此检查整个运维体系的流程和预案关联是否合理、告警规则、联系人是否可收到对应的告警、处理手段是否合理。都可通过混沌工程的方式去发现运行体系的薄弱环节。
4.自动化运维
最终的理想状态为系统为自运维、高可用的。因此需要建设：
l 应急预案平台
l 预案告警关联
l 自动化运维工具
5.总结
简而言之，这一系列流程更多是系统性工程问题，需要使用固定流程和方式去保证生产系统稳定性，同时配合该套流程还需要有一定运维、验证、故障注入工具等，需要触发点去验证流程的可用性，而混沌工程同时也是很好的验证工具，使用混沌工程做故障注入，从而检查整个不论是监控、整个告警预案的准备等都可用一些机制的沉淀和流转。
六、用户角色分析
此为一个系统性工程问题，需要各方团队参与，在混沌工程这样的体系之下，各方如何进行混沌的试验等工作，主要的角色有：
1. 质量团队
①主要职责
负责系统整体测试和质量保证。
②实现方式:
在真实的生产系统中，可构建演练场景，可在测试或生产环境进行定时演练或突袭演练，从而检查系统的高可用和有效性。
通过质量团队的方式推动提高系统的稳定性。
2. 运维人员
①主要职责
负责生产系统的监控、告警和运维，保证生产系统的稳定性，是生产系统的第一责任人
②实现方式:
在混沌工程的体系中，运维人员需要配置生产系统的监控和告警，准备生产系统的运维工具及故障恢复手册，并通过混沌工程验证整个系统的稳定性及工具的有效性。
3. 业务研发人员
①主要职责
业务开发，配合运维人员优化系统架构
②实现方式:
通过混沌工程分析系统的薄弱环节，优化系统架构，提高系统稳定性效果。
4.总结
最后通过团队人员如此反复，不停进行迭代，保证生产环境的稳定性。
七、核心场景介绍
1.场景一：如何验证告警的及时性和有效性
第一步，需要配置监控告警，验证告警的及时性和有效性，因而混沌工程中提供了告警配置和演练的功能，首先需要在容器服务的控制台上配置对应的告警项，此处有丰富的告警项：节点上运行时的异常、进程的异常、资源的异常、cpu运行内存磁盘等都提供了对应的告警项，可通过勾选对应的告警项来开启告警。同时也提供了联系人管理的功能。
可针对每一种告警项作对应的联系人分组处理，如：节点该由那个运维团队负责，管控面API Service由哪个团队负责，可通过此类联系人的管理来连接告警联系人的触达。
在配置好告警项后可通过演练的方式，容器报警演练这项功能可一键发起告警演练，由此通过这种方式去检验报警配置是否合理，报警的有效性、实时性和触达是否合理，最终改善整个报警的体系。
2.场景二：如何利用混沌工程进行业务容器的故障演练
业务容器是承载整个业务体系的载体，其稳定性偶尔影响整个业务的稳定性。因而需要在容器内模拟各种故障场景，如：容器内的cpu、容器内资源负载、cpu磁盘、内存、网络等场景。
其次，对于容器内的进程管理，如：kill某进程、让进程负载变高等都是可进行演练。
图中，主要介绍在Kubernetes中一个常见场景：Prometheus容器场景，可利用混沌工程的工具一键给业务容器注入较高内存，然后触发容器的ON事件，通过监控去发现整个内存的异常曲线，同时结合告警去发现告警的有效性和实时性。
最后基于提供的Prometheus异常处理文档做相应配套的故障检查和处理。
3.如何示例混沌工程进行节点的故障演练
节点是Kubernetes上一个重要的核心资源，节点承载着各个业务容器，它的资源利用十分重要。同样可利用混沌工程的方式给节点通过内存消耗的方式注入较高的内存，在演练的页面中可看到当前页面节点的使用，通过Prometheus监控发现节点的使用率，最后如果配置了节点相关的告警，同时可在相应的告警中收到节点资源异常的告警，如：Prometheus使用率过高异常；同时配置的联系人可通过邮件或短信的形式进行告警接收。
以上就是在混沌工程中的几个核心场景，除此外的丰富场景也欢迎大家使用。
八、客户案例
1.传统企业客户
该类用户较传统，具备一定的T能力，正在逐步容器化的过程中，希望提供可落地的运维方案。容器服务提供了快速开启监控和报警的能力，并提供一系列故障处理文档。
①提供了基础设施层、容器性能层、应用性能层、用户业务层多维度的可观测能力，帮助用户查看系统运行状态。
②提供了统一管理容器并开启容器报警场景的功能，包括容器服务异常事件报警、集群相关基础资源的关键指标报警、集群核心组件及集群中应用的指标报警，支持报警自定义配置，支持在创建集群时默认开始报警功能。
③提供了一系列故障处理文档，如：Service异常、Node异常如何处理，故障来临时可根据文档进行故障分析及排查。
2.传统金融客户
该类用户比较关注生产稳定性，有成熟的运维团队，对监控、报警、系统高可用有较高要求混沌工程在容器生态下提供更大优势。
①可基于容器服务的监控、报警能力构建可观测能力。
②利用混沌工程验证业务系统的稳定性及运维系统的有效性，发现系统盲区，完善运维体系。
③运维团队可利用混沌工程驱动开发团队补齐系统的薄弱环节，提高系统的可用性。
3.典型互联网客户
该类用户风格比较激进，会使用产品多种特性，如弹性/自动扩缩容、抢占式实例等，造成系统架构更为复杂。
①基于容器服务的监控、报警能力构建可观测能力。
②利用混沌工程来测试系统在大压力场景下弹性能力的有效性，优化弹性配置。
容器混沌工程的介绍到此结束。
