方法论与技术栈双管齐下的运维可用性能力建设（六）

2）实战演练

（1）非交易期的实战切换

非交易期的实战切换和前面“例行可用性演练”中的切换差不多，只是切换后不马上切换回来，需要生产系统在备份模块中运行一段时间，或长期运行。比如，单数据中心内的双机切换、多数据中心或灾备数据中主的切换后的运行。通过这类验证，能更好的发现主备机的高可用，并在实战运行的过程中发现运维日常过程中存在的问题，比如配置未更新、程序未同步等。

（2）破坏性演练

破坏性演练是在交易期对应用某个模块，或关联系统的某个模块，当运行负载规模下降或不可用情况下的实战演练。这类演练在金融企业很少提及，在互联网公司中有提到，比如 ：Netflix为提高可用性能力，解决无法在测试环境完全模拟出真实的线上环境，可用性问题在测试环境测试时没法发现，但是在线上环境却频繁发现微服务并不是完全高可用的问题， Netflix 决定在线上环境进行破坏性测试。采取的破坏性措施包括：关闭特定服务接口，关闭特定缓存服务，关闭特定 DB 服务，增加网络丢包率，增大网络延迟等。

2应急手段

1）最好的应急手段

最好的应急手段是提前消灭潜在的故障， 应该要不断的反思己制定的应急场景是否有优化的空间，不断减少或更新这些场景。

2）做好应急预案

提前制定好故障应急方案是很有必要的，但在日常工作过程中我们的应急方案遇到一些问题：

应急方案缺乏持续维护，缺乏演练，信息不及时、不准确；

应急方案过于追求大而全，导致不利于阅读与使用；

应急方案形式大于实际使用效果，方案针对性不强；

只关注应急方案的内容，但没有关注运维人员对方案的理解；

针对上述常见问题，应急方案需要做到以下几点：

（1）内容精&简

很多人可能会认为故障出现的形式各种各样，所以应急方案需要涉及到方方面面。但实际的故障处理过程中，我们可以发现其实我们的应急措施往往重复使用几个常用的步骤，所以应急方案要有重点，如果一个应急方案可以应对平时故障处理80%的场景，那这个应急手册应该是合格的。

过于追求影响应用系统方方面面的内容，会导致这个方案可读性变差，最终变成一个应付检查的文档。以下是应用系统应急方案应该有的内容：

系统级

能知道当前应用系统在整个交易中的角色，当前系统出现问题或上下游出现问题时，可以知道如何配合上下游分析问题，比如：上下游系统如何通讯，通讯是否有唯一的关键字等。

另外，系统级里还涉及一些基本应急操作，比如扩容、系统及网络参数调整等。

服务级

能知道这个服务影响什么业务，服务涉及的日志、程序、配置文件在哪里，如何检查服务是否正常，如何重启服务，如何调整应用级参数等。

交易级

能知道如何查到某支或某类交易出现了问题，是大面积、局部，还是偶发性问题，能用数据说明交易影响的情况，能定位到交易报错的信息。这里最常用的方法就是数据库查询或工具的使用。

知道最重要的交易如何检查是否正常，重要的定时任务的应急处理方案，比如开业、换日、对账的时间要求及应急措施。

（2）辅助工具的使用

有时候，需要借助一些工具或自动化工具辅助分析并应急，这时需要有辅助工具如何使用的方法。

（3）沟通方案

沟通方案涉及通讯录，包括上下游系统、第三方单位、业务部门等渠道。

上述3点内容如何都完备，相信这个应急手册己可以解决80%的故障恢复工作。

宝企通IT服务作为智能化工单系统龙头，拥有多年优化SLA经验，能够有效提高员工对IT的服务满意度。是一款支持SAAS、本地化部署、源码交付的运维工单系统(SAAS免费试用，企业微信--工作台--添加应用，搜索“IT服务”，排名第一的就是)。目前是全网众多企业选择的工单类产品，支持手机验证码或账号验证，员工自助修改域账号密码，具备智能化派单模式工程师响应快减少员工等待时间。自定义知识库可提升工程师专业技能水平，帮助工程师迅速判断员工问题，极大提升员工报单体验。系统还能够大幅提升职能部门可以服务的用户数，有效降低专业人力成本开支，提高业务执行效率，展现工作成果。产品服务好能为用户免费开发个性化需求，连续多年被魔力象0评为leaders位置，市场占有率爆发式增长