1.故障处理原则
-
以恢复业务优先 -
及时升级
1.1 恢复业务优先
1.2 及时升级
- 有明确业务影响,例如PV,UV,购物车,订单或者支付等业务指标波动。
- 非常重要的业务的严重以上的告警故障,比如北斗核心业务,核心的组件等。
- 处理时效明显超长(时效参考故障处理时效定义)。
- 有高级别领导,监控中心或者客服已经关注到这个故障。
- 很明确超出了自己的能力范围。
注意:任何运维故障,运维的领导必须是第一个知道的人,如果他从别的人或者部门中知道这个故障,那么就很被动,而且是故障处理人失职表现。
2.故障处理方法论
故障处理一般会分为三个阶段,故障前,故障中和故障后,故障前是指故障的定位分析,故障中是指故障处理过程,故障后是指故障总结,故障总结很重要,这个会单独放到一章,故障定位很杂,以后会单独去写,这里主要讲一下故障中的一些运维常用的方法。
2.1故障服务来看运维处理故障方法
- 调整上游权重为零,如果架构上有自检测机制,那么也可以直接停止故障对象的服务,让上游健康探测时效。
-
通过绑定hosts或者配置路由的方式,绕开故障对象。比如智能路由管理域关闭某一条线路。
这里需要注意的是,防止雪崩效应。
以 CDN 管理为例:
我们要求开发提供的预案有:
-
任何时候,核心域,都可以更换到备用域名,并且是分钟级生效。 -
核心域必须有重试机制,当访问一个域名失败时,APP能够直接回源到源站。 -
前端业务重试提供开关功能,可以一键关闭重试机制(主要担心源站会被重试打垮)
-
无状态,这个要占大多数 -
临时有状态,需要整改 -
有状态,少量的
2.2 从故障影响方去看运维故障处理方法
2.2.1.外部用户
-
自己在本地模拟是否可以重现,如果可以重现,那么就不是用户到IDC之间公网问题,是内部系统问题,那么变成内部用户处理。 -
如果自己在本地模拟不能重现,那么多找几个内部用户模拟,防止自己环境问题,同时,让用户进行hosts绑定到其他入口,排除DNS,一些外网链路问题,如果这时用户在绑定hosts后,访问正常,那么恢复业务,同时可以确认大概率是外部问题。
2.2.2 内部用户
2.3 故障处理过程中的组织架构
故障处理一般需要有三拨人同时行动
- 故障处理者,他们的职责就是尽快恢复业务。
- 故障定位者,他们的职责是当故障处理者方法失效或者需要查找问题根因时,解决故障。
- 信息传递者,他们的职责是对故障处理,故障定位传递有效信息,同时对外部传递故障进展信息。
往往运维这三类人不会同时存在,比如在凌晨值班时,只需要故障处理者处理即可,恢复业务后,第二天由故障定位者去找根因及优化措施。
当然,三拨人可以复用。
3.故障总结

- 赞助本站
- 微信扫一扫
-
- 加入Q群
- QQ扫一扫
-
评论