背景
大数据团队负责很多公司核心服务，包括olap查询、队列、日志搜索、数据传输、存储、计算等等服务，作为公司新闻资讯数据传输和存储及计算的中枢，服务的稳定性直接影响用户口碑和体验，间接影响着公司的营收，线上服务的稳定性是每位同学需要重点关注的事情。当然线上服务发生故障，做技术每位同学几乎都会遇到，也是作为技术RD成长中经常要经历的事。从故障中我们可以吸取到很多教训，变得越来越有经验，把我们的服务做得越来越稳定。但是并不是每一个团队/技术同学在应对故障的处理方式上，都能做到合理和科学地迅速止损，把业务影响和损失降到最小。那我们该如何做呢？才能让我们工作做得更好呢？下面流程图和详细步骤就是我们要具体做得工作。
故障反馈
- 用户部门主动反馈，使用集群服务超时或接口调用报错
- 服务负责部门自行发现，通过系统报警发现大数据服务出现异常
确认故障
不管是收到报警信息，还是业务用户反馈大数据组提供的服务有问题，我们都需要进一步确认验证集群是否正常提供服务，确认的同时通知用户我们正在跟踪处理，让用户放心。收到反馈通过以下指标项迅速判断，发现大数据集群可能遇到的问题
系统监控指标：
- cpu usage
- cpu load
- memory
- I/O 网络与磁盘
- network flow
- swap
- 客户端连接总数量
- mmap数量和usage
- File Description数量和usage
- ......
集群监控指标：
- jvm指标(gc、threads)
- 服务日志(错误日志、抛出异常)
- 上下文逻辑问题
- ......
用户服务指标：
- 收集调用异常或错误信息(接口请求响应时间、接口调用QPS、返回错误内容或code)
- 从错误信息确认边界，是用户使用问题，还是集群服务运行异常
集群可能出现问题，示例如下
中间件层面监控(数据库、缓存、消息队列、存储):
- 对数据库的负载、慢查询、连接数等监控
- 对缓存的连接数、占用内存、吞吐量、响应时间等监控
- 消息队列的生产/消费时间、吞吐量、负载、堆积情况等监控
- 对存储的写入时间、TPS、读取QPS等监控
- ......
故障通知
确认故障后，迅速拉群，把上下游用户及自己项目负责人、部门负责人都加入进来，简要整理下内容，告知用户当前情况及解决预案或方案，不要给用户感觉突然或带来惊讶，让用户有心理准备，留好buffer时间做好应对措施。如果不能及时解决，不要等待或死磕问题，请迅速联系自己的老板寻求支持和帮助(也可以请求能帮助自己的同事加入)。
故障恢复
故障确认后，首要做的就是故障止损和恢复，恢复常用手段如下：
- 服务回滚：如果属于更新的代码BUG导致的问题，一般可通过回滚上一个程序版本来迅速恢复，不过会导致部分新功能不可用
- 重启：部分问题是可以通过重启的手段来临时恢复的，以保障系统的暂时可用，但后续还需有其他方法彻底解决问题
- 限流和降级：这其实是一个临时手段，通过将部分非核心系统进行降级和限制流量处理，来避免核心业务受到影响
- 紧急更新：这个方式会经常被用到，明确定位问题源后，迅速修复代码或组件，然后快速更新上线，比较依赖故障处理人技术和代码逻辑、应急处理能力
写故障casestudy
写casestudy原则：并不是所有故障都需要写casestudy，原则一如果我们服务能快速恢复且对用户部门影响很小，就不用写。原则二由各个服务SLA确定是否编写casestudy
故障发生时间：故障报告时间：故障恢复时间：故障持续时间：故障影响范围：故障等级：PNPN故障处理人：xxx、xxx、xxx故障责任人：xxx故障描述：xxx故障处理过程：xxx故障原因分析：xxx故障总结：xxx后续改进工作：xxx 改进任务列表(任务、执行人、Deadline) |
组织故障review
邀请参与人员：用户代表、集群服务负责人、部门负责人、部门相关同事
- 回顾故障处理全过程： 需要详细的记录下故障发现的时间，什么途径发现的，用了什么样的排查手段，什么样子的处理流程，处理过程中，几点几分做了什么事情，将整个过程都一一的记录下来。
- 分析故障原因： 需要将团队成员聚在一起，进行讨论，分析故障发生的原因，这里的原因不是指表象的原因，需要剖析出问题的根源。
- 故障改进计划： 针对当前故障要做哪些改进措施，应对类似问题，如何预防。给出可实施的方案以及时间计划。同时对故障等级进行认定，以及团队成员责任的追究和备案（但不提倡惩罚）。
注意：review&复盘后，发送邮件给用户部门，P0故障同时抄送CTO
改进措施列表
根据当前存在的问题制定出一套流程不难，难在对流程执行的跟踪和监督。因此每个故障Action都是可执行的，且有明确的执行人和Deadline，跟进故障casestudy中改进工作列表进展情况，及时closed任务。随着故障管理标准化建立和规范化，经过一段时间的积累，会沉淀一些宝贵的故障数据，为系统改进方向提供了参考，也增强了伙伴们的故障意识，避免小伙伴不会犯同类型故障，对线上环境的敬畏之心和对故障的紧急处理意识。
完善服务运维文档
以上工作做完后，就要对运维文档查漏补缺进行完善了。大数据团队每个系统或方向的小组人数多寡有差异，多的有4人，少的可能只有1人负责。人都有打盹或休息/休假的时候，自己不能处理或外出，其他人可以根据运维文档，根据故障常用恢复原则进行紧急处理。
- 管理平台使用文档，能进行服务启动/停止/重启操作
- 服务程序部署、回滚版本操作流程等
- 服务程序部署目录、日志目录
- 常见故障列表及恢复手册