共计 4757 个字符，预计需要花费 12 分钟才能阅读完成。
简介：生产环境的突袭演练是咱们迈出的艰巨但无力的一步，锤炼了研发运维人员的应急响应能力，在实在用户场景下锻炼零碎，推动了产品的轮班制度，晋升了云原生底座的稳定性和竞争力。
作者：智妍（郑妍）、浣碧（何颖）
什么是混沌工程，云原生大潮下的混沌工程特点
通过应用云计算厂商如阿里云、AWS 等提供的服务，古代服务提供者得以用更低廉的老本，更稳固地进行丰盛的软件服务提供。然而真的所有如此轻而易举吗？支流云计算厂商在 SLA 承诺的范畴内，都各自呈现过一些历史故障，可参见这份血淋淋的 github 上的报告列表[1]。另一方面，各个云产品提供给了用户应用的一些高可用能力，常常仍然是须要用正确的姿态来配置和应用的。
混沌工程能够帮忙业务零碎服务提供者通过创立破坏性事件、察看零碎和人员响应形式、针对优化改良这 3 个步骤来发现生产服务中软弱的环节，并依据预期的 SLA 指标进行施行改良。除了指出须要改良的零碎组件设计问题之外，混沌工程还可帮忙发现须要监控和告警上的盲点、发现人员对系统了解、应急响应 SOP、排查能力上的有余，进而使得业务零碎及其研发、运维人员整体的高可用能力水位大大上浮。因而 Netflix 提出此概念后，各大软件厂商纷纷进行了对内实际和对外产品提供。
云原生在传统云计算根底上，提供了更快更低成本的弹性，更好的软硬一体化灵活性，曾经成为云计算倒退最快的技术方向。云原生帮忙开发者大幅度降低资源老本和交付老本，从而更快更好地博得市场。同时，云原生也给传统运维、研发形式带来了彻底的改革，这就使得传统的混沌工程伎俩须要追随演进。
云原生背景下，其上的应用服务的混沌工程施行和传统有什么不同呢？从咱们在阿里电商、中间件云原生化的大量实际中，总结出以下次要差别：
在这样差别的背景下，用云原生的伎俩，施行更加针对植根于云原生利用的场景的混沌工程，是更加恰到好处，可能提供更多能力晋升的。
混沌工程施行模式的阶段和倒退
既然混沌工程能带来如此多的益处，一个基于云原生的应用服务或体系想要实际，要如何落地呢？
从演练工具和落地施行来看，一个组织的故障演练常常分为几个倒退阶段：手工演练，流程工具自动化演练，常态化无人值守演练，生产突袭演练。
这几个阶段的施行难度是从低到高，当然相应的收益也是从低到高。一个组织（云用户）能够随着本人业务应用服务体量的增大、复杂化和高可用能力的增高的历程，依据理论状况须要抉择本人适合的阶段，而后随之进行降级和倒退。即便从最简便的手工演练开始做起施行，常常也能带来相当显著且久远的高可用能力系统性晋升。
那么每个阶段别离有什么特点，又该如何抉择呢
手工演练：个别在高可用能力建设初期阶段，或者一次性验收的状况下手工注入故障实现。通过人为查看告警是否失效，零碎复原状况来进行演练。在这个阶段只须要一些故障注入的小工具或者脚本，不便后续应用即可。
自动化演练：高可用能力建设到肯定阶段后，往往会有定期检查高可用能力是否进化的需要，自动化演练开始排上日程。自动化演练步骤个别包含：环境筹备 -> 故障注入 -> 查看 -> 环境复原。在每个步骤中配置相应的脚本来造成演练流程，下一次就能够一键点击自动化执行了。
常态化执行：演练进行到下一阶段，咱们会有更高的要求，心愿演练能够自主混沌化执行，以无人值守的形式进行，这又对系统的高可用能力有了新的挑战。这要求零碎有不仅有监控告警能够发现故障，也有对应的预案模块来负责复原，而要做到无人值守，须要零碎进行更智能准确的判断故障状况，主动执行相应预案。
生产突袭：以上演练大多在灰度环境进行，不会影响到业务，生产突袭则要求零碎有能力在生产环境管制爆炸半径的前提下进行故障演练，以期发现一些业务相干、规模相干、配置相干、应急响应相干的，在灰度环境脱漏的局部，生产环境的演练对系统的要求较高，须要有一套执行标准，对系统的隔离能力也有较高要求。大多数的工作，能力建设都在灰度环境实现验证，但生产突袭仍作为一个无效且必要的演练伎俩，用更实在的场景给研发体感，让其实在执行预案，也锤炼了应急能力，对系统有更多信念和认知。
如何进行一次残缺的故障演练施行
当利用首次应用 Kubernetes 进行利用部署和扩容时，最先关注的更多是性能是否可用，故障演练则是更高级别的要求，咱们假如以后的零碎曾经初步通过了性能验收，但对于一些故障状况下零碎的体现还未知的前提下，来开始咱们的故障演练之旅。
故障演练自身作为一种破坏性的操作，须要循序渐进，遵循肯定的标准和流程来落地。上面咱们从环境建设、零碎能力剖析、高可用能力建设、演练施行倡议几个方面来介绍一下，一个首次在 Kubernetes 中部署起来的利用应该如何循序渐进的施行故障演练。
Step 1：隔离环境建设
故障演练，特地是首次执行之前，咱们须要明确好以后注入故障的环境状况，是否可能影响到业务流量，是否会造成无法弥补的损失，在阿里外部，咱们有简单的环境隔离和变更管控，以防故障注入影响到业务流量。
在环境类别上，咱们会辨别为以下几类：
业务测试环境：用来进行 e2e 测试，全面的性能验收，这个环境和有业务流量的生产网络是隔离的，从网络上防止了流量谬误进入到其余环境，因而能够在这个环境上纵情的进行各种容错性测试。
金丝雀环境：能够了解为是一种全面的链路灰度环境，这个环境有以后零碎的所有组件，个别用来做上下游联调，零碎外部的链路灰度应用，这个环境是没有理论业务流量的；
平安生产灰度环境：这个环境咱们会引入 1% 的生产流量，并提前建设了切流能力，一旦这个环境呈现问题，能够把流量迅速切换到生产环境中，该环境个别用来联合用户流量做一段时间的灰度，免得全量公布导致的不可控；
生产环境：实在用户流量的环境，这个环境的任何运维动作都须要进行严格的变更审核和前几个环境的灰度通过能力变更；
故障演练个别会开始在金丝雀环境引入，能够在全链路、无实在流量的环境中做一些高可用能力的建设和验收，常态执行的演练，在这个环境演练屡次的场景，可定期在灰度环境和生产环境中、管制爆炸半径的前提下进行实在突袭，作为能力的验收。
个别状况下，思考到老本投入和零碎复杂度，业务利用可能不会建设 4 个隔离环境来循序渐进的推动，但咱们举荐利用应该至多有两个环境来辨别用户流量，环境上至多有一个和生产隔离的灰度环境，至多初期必须如此。环境建设中须要关注的问题如下：
隔离性：灰度环境和生产环境尽量做到隔离，包含但不限于网络隔离，权限隔离，数据隔离等，思考到一些容灾的能力，还能够将两个集群建设在不同地区的 Kubernetes 集群中。
真实性：灰度环境和生产环境尽量保持一致，比方内部依赖，组件版本。
环境建设达标后，才具备了演练的准入条件。
Step 2：故障场景剖析
在剖析零碎的高可用能力时，往往没有一个对立的答案，每个零碎的薄弱点，瓶颈都不尽相同，但整顿零碎高可用能力时，咱们能够提供一些通用的思路。
历史故障：
历史故障通常是疾速理解一个零碎单薄能力的教科书，通过剖析历史故障，进行分类，能够疾速得出以后零碎那些组件更容易呈现问题。
比方零碎能力须要进行疾速的弹性伸缩，伸缩失败可能影响业务流量，能够推断出它强依赖 Kubernetes 的扩缩容能力，须要监控关注此能力的可用性；比方零碎数据读写频繁，历史呈现过数据不统一问题，则能够思考在数据层面进行稳定性建设，减少备份能力，回滚能力等。
架构剖析
零碎的架构在肯定水平上决定了这个零碎的瓶颈，通过剖析零碎的依赖也能够更理解零碎的边界，也更便于进行运维上的优化。
比方一个利用的部署形式是主备模式的，那必须要查看的能力就是主备切换是否顺畅，切换过程是否影响到业务流量；比方一个利用强依赖底层存储，一旦存储挂掉，业务会大面积故障，则在整顿高可用能力的时候就须要想到存储挂掉后是否有降级计划，存储问题是否能够提前预警。
社区教训：
很多零碎的架构都是大同小异的，参考社区或友商的教训就像提前看了模仿考题，总会有意想不到的播种。咱们总会在业界爆出一些故障时进行自我反思和重新整理，屡次发现了本身的一些问题。网线被挖断、删库跑路等贵重的教训库，都在咱们定期演练的列表中。
在阿里云原生的架构上，咱们整顿了如下所示的演练模型供参考，在这个高可用能力模型中，咱们依据零碎架构依照管控层组件、元集群组件、扩大组件，数据存储，节点层，整体集群进行辨别，在每个模块中有一些通用的故障能够相互借鉴。
Step 3：零碎高可用能力建设
在理论进行故障注入前，咱们还须要问本人几个问题。根据上述曾经剖析到的咱们想让零碎领有的高可用能力列表，零碎是否具备当这些故障来长期有麻利的发现能力，人员有迅速的响应能力，零碎自身是否具备自愈的能力或一些可用来在故障过程中应用疾速复原零碎的工具呢？上面咱们从发现能力和恢复能力两个方面来给一些通用的倡议。
发现能力
监控和告警是可能发现零碎是否处于稳态并让利用负责人高深莫测的形式。阿里外部团队建设了两种监控告警形式，一种是白盒告警，借助零碎外部裸露进去的各种维度的可观测性数据的异样稳定来发现潜在问题；一种是黑盒告警，从客户视角把零碎当做黑盒，探测正向性能。
恢复能力
故障降临后，最优的后果是零碎稳固丝滑，毫无影响，这对系统的能力建设要求极高，而理论的状况往往更为简单。在阿里外部的实际中，除了对系统自身专门建设了根本的过程自愈、切流能力、迁徙能力、限流能力等，也建设了预案核心，中心化的积淀咱们所有的止损能力到零碎中，白屏治理，接入，运行，依据专家教训建设止损能力集，作为故障时的重要工具。
Step 4：演练施行
以上步骤实现之后，咱们认为零碎已具备了初步的高可用能力，能够开始施行故障演练。
个别状况下首次演练咱们会筛选一些外围场景进行，在预发或测试环境，工具上应用半自动化的脚本或仅蕴含故障注入模块的流水线来触发，在研发和运维人员在场的状况下进行首次试验。试验前确认场景的预期，比方故障注入后须要 1min 进行告警，10min 内零碎自愈复原，以便在演练过程中随时确认。演练执行后须要各局部人员进行人工确认零碎体现是否合乎预期，演练完结后及时复原故障和环境。场景在演练过程中不符预期的局部，须要屡次在此阶段一直验证和演练；合乎预期的场景进行标记，能够开始进入到常态化演练阶段。
常态化演练阶段的关键词是混沌化、无人值守，Kubernetes 集群因为架构的劣势，自身具备肯定的自愈能力，因而更适宜无人值守的演练。咱们会筛选曾经通过半自动演练的场景汇合，组织为一些故障演练流水线，每个流水线中个别蕴含故障注入、监控查看、复原查看、故障复原等步骤，来闭环实现单个演练流程。同时阿里外部应用云原生技术进行混沌化触发，实现在演练对象、环境、工夫、场景上的随机，使得这些演练场景能够混沌化、常态化、无人值守的执行。通过常态化故障演练，助于发现一些偶发性零碎问题，并能够在系统升级过程中帮助查看已有的高可用能力。
生产突袭的施行须要依据零碎的架构状况进行，在阿里外部的施行中，一种管制危险的形式是抉择流量低峰去进行，并提前准备一键切流预案，一旦呈现故障无奈复原的状况，立刻切流止损。其余突袭相干的危险管制设计咱们会在后续的系列文章中详细分析。
结语
在外部云原生畛域施行故障演练的过程中，咱们剖析了 200 多个演练场景，通过 1000+/ 月的频次进行常态化故障演练，无效的发现了 90 多个问题，防止了问题半径进一步扩充；通过演练流程的搭建、校验和混沌化执行，定期监测零碎的告警和预案恢复能力，无效的拦挡 50 多个新增高可用问题上线。生产环境的突袭演练是咱们迈出的艰巨但无力的一步，锤炼了研发运维人员的应急响应能力，在实在用户场景下锻炼零碎，推动了产品的轮班制度，晋升了云原生底座的稳定性和竞争力。
原文链接
本文为阿里云原创内容，未经容许不得转载。
