上周提到，混沌工程是“为了发现系统架构风险及应急处置能力问题，并跟踪问题改进”所进行的工程实验。和朋友聊起混沌工程与应急演练区别，我觉得金融企业应急演练主要是基于事先模拟好的生产事件，组织应急管理体系中各个协同组织，验证已知故障中应急预案的有效性，架构可用性的可靠性，以及各组织在突发事件中的应对能力。在执行应急演练前，组织各方通常会在事前作出计划、应急预案、排练。与混沌工程相比，应急演练是对于一个已知故障在应急预案下的演习，验证已定方案可靠性、增强应急信心、提升应急处置协同是重点；混沌工程是为了发现未知故障下的系统风险与应急管理问题，发现问题是重点。所以，你会发现应急演练结束后通常是喜报，比如某公司圆满完成2021年同城切换应急演练，XX公司顺利进行UPS不间断电源应急演练。
本文接下来梳理一下我对应急演练的理解。
1、应急演练的作用
我们常说的应急演练，通常是先出一个异常事件场景，提前做好参与方的准备工作，按应急预案指挥整个演练过程，IT内多个团队、业务、供应商分工协作，形成整体联动，实现了从问题发现到启动应急响应机制，到故障诊断，现场应急恢复。通过演练过程，检验应急预案是否有效，可用性架构是否可靠，应急处置过程中判断是否准确果断，处理及时有效，内部分工明确，应急操作是否规范等，最终评价演练是否达到预期效果。
应急演练是检验、评估、提高运维组织可用性管理的一个重要手段，通过事先模拟已知故障的发生，作好相好应急预案，并在执行中发现软硬件运行环境、系统架构、应急预案、协作沟通、人员技能等存在的不足，并改进应急管理体系。在这样的背景下，演练前会做相关准备与优化工作，演练过程发现的问题通常比较少。应急演练的作用主要有：
- 提高应急意识。通过模拟真实事件及应急演练，将演练作为一项常规性工作，在企业内在事前形成应急管理意识，让参与人员提升对风险事件的警惕性，时刻警钟长鸣，同时加强业务、IT、外部供应商等之间协调，提前作好应急预案。
- 检验预案有效性。应急演练通常与应急预案配套，演练可以发现应急场景与预案之间差距，检查预案的完整性、可操作性、有效性，验证应急管理过程协同机制。
- 检验可用性架构的可靠性。高可用是运维管理的重点工作，通过演练可以发现系统高可用架构问题，冗余资源是否可靠，故障转移是否有效。
- 提升实战应对能力。通过应急演练，发现并解决应急协同问题，增强应急处置过程各个角色应对事件的处理、协调、决策能力，提升在实际事件中应急熟练程度，增加应急事件处置信心。
- 协助决策层或监管层推进业务连续性管理。在金融企业，借助行业、经营机构内专项、例行的演练工作，决策层或监管机构可以推进整体性的业务连续性管理的落实。
总结起来，应急演练重点是增强应急意识与信心，提升应急预案有效性，验证可用性架构可靠性，增加应急实战能力。在操作上，因为演练涉及多方协同，大部分团队用来模拟处置较大的风险事件。在实际演练操作过程中，由于演练针对已知故障开展，形式类似演习或排练，所以你会发现演练结果公告时通常都是喜报为主，发现问题为辅。
2、应急演练常用方法
在应急演练时事前会对演练涉及的组织、场景、剧本、预案等环节做准备工作，归纳起来大概有以下环节：
- 明确整体目标：明确演练的目标，比如容灾、技术架构等技术层面的可用性管理，或对于像重要业务系统业务连续性中断、主机宕机、网络中断、疫情、断电、火灾等涉及的跨团队协同管理等。
- 确定组织架构：建立应急演练涉及组织架构，通常包括决策、应急执行、应急保障小组，涉及IT内的运维、研发，IT外的业务、合规，以及第三方供应商。在IT运维团队中又涉及决策、流程经理、服务台、职能小组等。
- 制定演练剧本：剧本由场景组成，场景需要有角色、时机、时间、具体的事，通常是基于时序，制定应急演练计划，形成可操作的剧本。
- 应急预案：演练通常由一个或多个应急场景组成，每个场景需要配套应急预案。
- 演练培训：由于演练通常是对已知故障的演练，有些企业会有事前培训的环节，来加强演练的顺利。
- 线上工具实现：一是对于剧本顺畅运作，最好有线上化的时序管理工具；二是具体场景下涉及的自动化操作，协同，数据观察的工具。
- 演练总结：总结演练过程经验。
3、一些场景
1）与应急预案的关系
演练通常与预案配套。在业务连续性保障过程中，理想情况下，如遭遇安全性、可用性、性能等系统紧急事件时，应立即启动应急预案并采取相应的补救措施来恢复故障，应急预案包括对特定场景的应急处置流程，包括场景描述、启动条件、协同机制，工具使用，应急执行措施。应急三把斧就是典型的应急预案的具体措施。在形式上，应急预案通常是一份文档，也有团队为了更好实施将文档拆成细化的应急卡片。在操作过程中，一方面，演练过程中涉及的针对特定场景的应急执行，通常就是对于应急预案的操作执行。另一方面，通过定期演练，能对应急预案起来保鲜作用，发现预案的不足并加以改进，从而提升预案的有效性。
2）关于可用性演练
可用性通常用几个9来计算，9越多可用性越高。为了实现高可用性，通常要关注“资源冗余”与“故障转移”两点：冗余关注单点风险，小到磁盘阵列，服务器集群或主备架构，两地三中心等架构都是一种冗余的解决方法；故障转移强调节点发生故障后，能够按高可用性方案是否生效，比如主备架构切换的自动化，软件层面的降级、限流、超时机制等都是故障转移的方案。
可用性演练是演练的一个常见场景，通常是验证冗余资源是否可靠，故障转移是否有效，比如机房供电、网络故障发生后，对于同城或异地机房启用是否有效，切换时效性是否满足要求；主机发生故障时，备机是否实时完成自动化切换并接管业务；系统会不会因为全部主机放在一个虚拟化主机的单点风险；应用性能故障发生时，软件层面设计的降级、限流、超时机制是否生效等。
随着企业平台化战略或中台战略的推进，企业内IAAS、PAAS，以及云原生应用架构的落地，可用性演练将随着技术平台高可用复杂性的提升而越来越复杂。
3）例行关机维护
例行关机维护是运维团队的一个常规演练工作内容之一。一方面，系统软件在运行一段时间后会产生一些临时文件，或一些内存碎片无法释放等问题。另一方面，随着系统变更越来越频繁，有些配置、程序修改后的问题可能会在重启后才能生效，主动的重启能提前发现这种风险。
关机维护可以归纳为上面提到可用性演练的一部分。在这里单独抽出一点，是因为关机维护可能做得更有计划性，比如年初制定全年的关机维护演练计划，针对不同的操作硬件、操作系统、业务系统分类制定不同频率的关机维护计划，如在实施前已临时实施关机维护则进行调整，在具体的实施当天通常排出一个例行关机的窗口，在非业务时断进行,这个窗口集中安排多个团队的关机维护工作，这样有助于提高工作效率。
4）针对项目的演练
针对项目的演练通常是某个重要变更需要上线，或为了在测试环境模拟验证生产环境的真实的性能，运维会与开发、测试团队进行联合的演练工作。有些企业会建立准生产环境，也有些企业复用备机、灾备、测试，或找个业务空档期用生产环境做演练。这类针对项目的演练，通常是因为测试与生产环境不一致，或为了增强项目上线信心进行的演练工作。
5）桌面演练
桌面演练指参加演练的人员根据应急操作手册、应急协调流程等文档，借助多媒体会议等手段，对事先假定的演练情景进行交互式讨论、推演应急决策、现场处理的过程，从而发现应急预案、沟通协调等方面存在的问题。关于桌面演练，既可以考虑提前预知的方式开展演练，也可以考虑临时通知演练参与人介入演练。前者适合针对方案、沟通流程的完善，后者适合验证参与人是否理解并掌握应急过程的实施。
还有其它一些安全、消防等演练场景，今天先写到这里。
4、从工具层面看应急演练
在上周混沌工程中，我梳理了混沌工程中几大模块/功能：
- 实施计划管理（流水线、工作流、模板）
- 自动化执行（自动化操作脚本与编排、故障注入）
- 故障观察（关键指标管理、可视化、线上协同）
- 事后环境恢复（自动化、数据报告、跟踪任务）
应急演练的功能可以考虑与上面混沌工程的工具整合在一起，增加以下功能：
- 预案管理：预案场景、技术应对措施、业务应对措施、应急组织架构；
- 架构管理：从基础设施、IAAS、PAAS、SAAS层的高可用架构的可视化、高可用描述等；
ok，今天先写到这里。
