故障报告个人学习总结

故障报告个人学习总结

1、避坑歌

需求紧，工期紧，风险暴露最要紧。
状态服务是根基，组件、配置须盯紧。
项目上线莫马虎，依赖顺序，很要紧！
重大故障，速解决，指定指挥，得抓紧。
工具平时要操练，解决问题，快得很。
同步数据，不可靠，未雨绸缪，很重要。
核心服务，须灾备，BAT服务，亦要备。

2、针对故障处理的基本要求

2.1、要求对常见问题有良好的处理方式和直觉

1、了解常见错误码含义，如：499、504、503、502、500等，及其处理套路；
2、对慢sql查询、cpu飙升、内存溢出类型的告警保持敏感，对nginx日志、业务日志、slb 保持“亲切“，尽最大努力做好告警监控；
3、写代码要保持两个习惯、防御性编程，solr、es等类型的公共服务及组件修改时，需要周知客户端，及捋清依赖关系等；
4、修改接口逻辑，尤其是不确定接口有多少个客户端的情况下，不要轻易修改。宁可新增接口；
5、项目上线前需需要与QA和PM确认。

2.2、业务恢复优先定位原因原则

1、例一：定位到异常机器后，将异常流量摘除，先保证业务可用，再查原因。
2、例二：可回滚的，先回滚。再查原因

2.3 、保持良好编程习惯

1、通过网络连接服务的代码，尤其更要注意，不要吃掉异常，如此，则出现问题时，才能比较容易的快速定位问题原因；
2、对自己负责的项目，分离出核心服务，或者比较出现问题的服务，给自己留一些后门工具，如相关的测试、验证API。线上发生问题时，调用工具API，可快速验证和定位问题原因。

3、故障发生前中后的总结

3.1 故障发生前

故障发生前，以预防为主

短期方案：

1、基础架构升级和项目上线或跑对线上有影响的脚本，需要QA介入。

2、基础架构升级和项目上线或跑对线上有影响的脚本，需要周知各个项目负责人。

3、对线上有状态服务操作前，需要备份相关数据。

4、操作线上服务，要谨慎，避免误操作，尤其UD类型的操作。

5、有条件的，提前做好回滚机制，可以做异常测试，避免解决问题的时间过长。

6、对于项目使用到的状态服务，如redis、memcache等需要做定期梳理，及异常监控。

7、开发过程中升级任何组件库都要对相关联的组件库进行相应的回归和升级测试。

8、在修改App全局配置时，要仔细了解并向别人请教一些关键代码的作用，避免修改关键代码。

9、所有业务客户端开发RD及测试在非测试rom功能时都必须使用release版本进行开发测试。

10、上线checklist:线上环境配置、表结构等要和沙盒保持一致。

11、提测前，充分自测，充分说明那些模块修改过，影响范围。尤其RD对业务流程不熟悉的情况下，更要如此。

中长期方案

1、引入自动化业务测试，基础架构升级和项目上线或跑对线上有影响的脚本，需要执行自动化业务测试。

2、引入业务监控，帮助提前发现业务告警，加快解决问题，以缩短故障影响的时间。

3.2 故障发生中

保证服务可用优先

1、重大故障，指定故障解决指挥人，负责做好中间沟通工作和上下游的指挥工作，指挥人最好是对应的PM和故障负责人。

2、502报错，如果是某台机器问题，及时摘掉故障机的流量。

3、难以定位的复杂问题或频发的同一个小问题，需要问题升级，督促相关责任人给出解决方案并解决。

4、会使用工具，用工具快速定位问题。

3.3 故障解决后

复盘回顾，留下宝贵经验

1、todo列表，跟进处理

2、对故障发现和处理流程详细记录，互相交流故障处理的总结和心得，为更快的解决下一个未知的故障提供经验。