本文主要是介绍方法论与技术栈双管齐下的运维可用性能力建设(六),希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
2)实战演练
(1)非交易期的实战切换
非交易期的实战切换和前面“例行可用性演练”中的切换差不多,只是切换后不马上切换回来,需要生产系统在备份模块中运行一段时间,或长期运行。比如,单数据中心内的双机切换、多数据中心或灾备数据中主的切换后的运行。通过这类验证,能更好的发现主备机的高可用,并在实战运行的过程中发现运维日常过程中存在的问题,比如配置未更新、程序未同步等。
(2)破坏性演练
破坏性演练是在交易期对应用某个模块,或关联系统的某个模块,当运行负载规模下降或不可用情况下的实战演练。这类演练在金融企业很少提及,在互联网公司中有提到,比如 :Netflix为提高可用性能力,解决无法在测试环境完全模拟出真实的线上环境,可用性问题在测试环境测试时没法发现,但是在线上环境却频繁发现微服务并不是完全高可用的问题, Netflix 决定在线上环境进行破坏性测试。采取的破坏性措施包括:关闭特定服务接口,关闭特定缓存服务,关闭特定 DB 服务,增加网络丢包率,增大网络延迟等。
2应急手段
1)最好的应急手段
最好的应急手段是提前消灭潜在的故障, 应该要不断的反思己制定的应急场景是否有优化的空间,不断减少或更新这些场景。
2)做好应急预案
提前制定好故障应急方案是很有必要的,但在日常工作过程中我们的应急方案遇到一些问题:
应急方案缺乏持续维护,缺乏演练,信息不及时、不准确;
应急方案过于追求大而全,导致不利于阅读与使用;
应急方案形式大于实际使用效果,方案针对性不强;
只关注应急方案的内容,但没有关注运维人员对方案的理解;
针对上述常见问题,应急方案需要做到以下几点:
(1)内容精&简
很多人可能会认为故障出现的形式各种各样,所以应急方案需要涉及到方方面面。但实际的故障处理过程中,我们可以发现其实我们的应急措施往往重复使用几个常用的步骤,所以应急方案要有重点,如果一个应急方案可以应对平时故障处理80%的场景,那这个应急手册应该是合格的。
过于追求影响应用系统方方面面的内容,会导致这个方案可读性变差,最终变成一个应付检查的文档。以下是应用系统应急方案应该有的内容:
系统级
能知道当前应用系统在整个交易中的角色,当前系统出现问题或上下游出现问题时,可以知道如何配合上下游分析问题,比如:上下游系统如何通讯,通讯是否有唯一的关键字等。
另外,系统级里还涉及一些基本应急操作,比如扩容、系统及网络参数调整等。
服务级
能知道这个服务影响什么业务,服务涉及的日志、程序、配置文件在哪里,如何检查服务是否正常,如何重启服务,如何调整应用级参数等。
交易级
能知道如何查到某支或某类交易出现了问题,是大面积、局部,还是偶发性问题,能用数据说明交易影响的情况,能定位到交易报错的信息。这里最常用的方法就是数据库查询或工具的使用。
知道最重要的交易如何检查是否正常,重要的定时任务的应急处理方案,比如开业、换日、对账的时间要求及应急措施。
(2)辅助工具的使用
有时候,需要借助一些工具或自动化工具辅助分析并应急,这时需要有辅助工具如何使用的方法。
(3)沟通方案
沟通方案涉及通讯录,包括上下游系统、第三方单位、业务部门等渠道。
上述3点内容如何都完备,相信这个应急手册己可以解决80%的故障恢复工作。
宝企通IT服务作为智能化工单系统龙头,拥有多年优化SLA经验,能够有效提高员工对IT的服务满意度。是一款支持SAAS、本地化部署、源码交付的运维工单系统(SAAS免费试用,企业微信--工作台--添加应用,搜索“IT服务”,排名第一的就是)。目前是全网众多企业选择的工单类产品,支持手机验证码或账号验证,员工自助修改域账号密码,具备智能化派单模式工程师响应快减少员工等待时间。自定义知识库可提升工程师专业技能水平,帮助工程师迅速判断员工问题,极大提升员工报单体验。系统还能够大幅提升职能部门可以服务的用户数,有效降低专业人力成本开支,提高业务执行效率,展现工作成果。产品服务好能为用户免费开发个性化需求,连续多年被魔力象0评为leaders位置,市场占有率爆发式增长
这篇关于方法论与技术栈双管齐下的运维可用性能力建设(六)的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!