管理故障和问题

本文是对《架构即未来》第8、9章的总结。
1. 书中的的问题翻译为根源更合适。
2. 故障是指造成服务异常的事件，包括停止服务、服务效率降低等；根源是导致故障的原因；同一个根源可能导致多种不同的故障；
3. 解决故障属于紧急事情，找到根源属于重要事情，在时间管理的四象限法制中，紧急事情优先级要高于重要事情；在实际工作中也基本如此：一旦运维发现线上服务出现问题，首先想做的事情就是尽快恢复服务，尽量减少对线上用户的影响；但是这样做有可能会把故障产生的一些现象给擦除掉，从而给分析故障根源带来更大的困难。
4. 文中提到ITIL中规定了事故管理所需的步骤：
（1）监控和记录事故；
（2）分类和初步支持；
（3）调查和诊断；
（4）解决故障并恢复服务；
（5）关闭事故；
（6）事故所有权、建库、跟踪和通信；
上述步骤的部分条款感觉枯燥且难以执行，书中提出一种简称为DRIER的故障管理过程，它是本身对ITIL的繁琐流程进行的简化，其含义如下：
（1）D(Detect)，由运维同事经过监控或者反馈检测到事故发生；
（2）R（Report），报告事故，将事故记录到禅道之类的bug管理系统中；
（3）I（Investigate），调查事故原因，一般由研发人员、运维等相关人员一起进行；
（4）E（Escalate），升级服务，如果事故无法通过重启迅速解决，则尽快安排修改和升级；
（5）R（Resolve），解决问题，恢复故障；
6. 建立有效的监控和记录体系，是快速识别、分析故障，以及找到故障根源的前提条件；目前我们常用的监控和记录有这样几种：
（1）通过nagios、zabbix等通用的监控系统来监控服务所在主机的情况以及服务进程是否存活。
（2）通过自己开发监控脚本来判断服务的假死情况，这些监控脚本要定期（例如每5分钟）运行，监控到异常时要及时通过合适的途径及时发送出告警；
（3）结合日志系统，在分布式服务设计中，日志收集和分析系统是必不可少的一部分，它是记录故障信息的主要途径；
7. 我们在设计分布式服务时搭建的大数据收集和分析系统就是为了实时收集和记录线上所有服务的日志；关于日志有如下几点建议：
 规范而非统一格式，以便Storm或SparkStreaming进行处理；规范日志格式是指将日志的格式输出按照指定的若干中规范进行，但很难做到全部统一，尤其是在移动互联网后台服务中经常采用分布式服务，每个服务有可能用的语言、框架都不一样，而且这些服务还有可能是采用开源的软件，因此很难做到让这些服务都统一成一样的标准；但是，我们可以在制定团队日志输出规范时，要综合自己常用的开源软件和自研软件的输出特点，规定若干种日志输出规范，让大家在开发过程中尽量向制定的标准靠拢；
 分布式服务中的日志一定要有索引跟踪，否则日志收集起来就混乱了，完全不知道上一条日志和下一条日志对应的是什么？可以在制定团队开发规范时，强制要求自研服务中，每个函数的入口参数的第一个参数必须为日志索引；
 日志索引不易太长（long型即可），并且尽量保持单调有序，因为日志要在各服务、服务的各个函数中进行传递；
 输出日志所在的类名和函数，尽管logback之类的日志输出工具可以输出文件名+行号，但是这个可读性太差，我们期望能通过日志就像读文章一样，无需看代码就能定位到问题，类名+函数名的可读性要优于文件名+行号；
 服务调用入口之处需以info级别打印所有的入口参数；
 服务调用返回之处需以info级别打印调用的返回结果；
 关于性能，日志输出会对程序的性能产生一定有影响，部分对效率要求较高的程序，经常需要关闭日志，但是除非特别确定某段程序不出问题，尽量不要关闭所有的日志，尤其是出入口出的日志输出，对于定位问题非常重要；
8. 故障需要跟踪和管理
一般要通过项目管理软件把故障的生命周期管理起来，当系统变复杂时，故障和bug也会变多，有效的管理是保障项目规范、有序进行的前提。例如可以通过禅道来追踪和管理故障的生命周期。
无论是故障还是bug，如果能定期回顾，对团队将会非常有益，回顾过去走过的问题，能让团队以后尽量减少再次犯同样的错误。
书中建议制定季度事故总结制度，这个是非常好的建议；因为这种回顾性质的会议不能执行太频繁，否则很难长久执行下去。
9 关于危机的一些说明
（1）危机是一种特殊的、紧急的、严重的事故；
（2）事故超过一定阈值就变成了危机，每个公司都可以定义自己的阈值；
（3）与事故相比，危机更紧迫，它要求尽快恢复服务，而不是找到原因；
（4）危机发生时，如果不能有效管理危机中的各部分力量，就尽量少用人，紧急时刻，人越多就越乱，反而不容易解决危机；这里有个度，对危机解决起关键作用的人员要参与，例如相应的研发人员、技术骨干等。
（5）危机处理小组的组成，首先要有一个懂技术的协调人，这个人不一定是技术最牛，但他的协调能力一定要强，另外还需要相关开发人员、技术骨干等；