配置引起事故复盘

记一次线上事故的复盘：一个配置引发的血案。

一天晚上的业务高峰期，app 出现了超时（数据加载不出来的情况）。

联想到前一天有发版的工作，一：功能上并没有太大的调整，此次发版内容更多的是新增的功能，用户使用量也较少，基本可以排除因功能导致的问题；二：是否中间件出现问题，因数据的交互，有 80%是和 redis 交互，从慢日志查询中未发现有异常情况；三：隐约有人说过用于负载的服务，昨天发版关闭掉了一台。

通过 netstat -an |grep 'ESTABLISHED' |grep -i 'port' |wc -l,可查看连接数的情况。

从上面的命令查看到当台服务已经到了瓶颈，然后立即从配置中查看，确实只有一台对外在运行着的。

处理方法：立即启动另外一个服务，修改配置后，验证。业务已正常运行。

和昨晚参与发版的人员核对，昨晚关闭掉一台负载的原因。说是因为启动两台时，出现新加的功能，调用新的服务会出现报错的情况。因未找到原因，和运维沟通后，最后决定只起一台服务。

听完说明后，第一个联想到的就是配置的 ip 和端口是否正常? 一看配置，ip 是本地 IP，问题已定位。修改本地 IP 为域名，功能正常。

此次事故，有多个环节可避免掉事故的发生。结果各个环节上都出现了疏漏，导致了此次事故的发生。

一、上生产环境的 IP 配置，统一采用域名的方式。这个是约定，因开发人员不清楚线上域名的情况，未能执行好。

二、运维是部署线上环境的第一人，各服务运行在那台对应的机子上，是最为清楚的一个人，对配置的检查，需要把好最后一道岗。因习惯，未对新增的配置进行审查。

三、对于此次问题的处理，在一定程度上也是可行的方案。但是缺少了数据的支持，未做好测试、评估的工作。在用此方案处理后，未及时反馈给相关人员。

四、对线上运行环境有一定了解的技术（开发）人员未在场。

对于以上问题，解决的方法有很多种。但方法是对于特定问题，而提出的解决方案，是针对特定的场景和特定的人的，对于场景和人的依赖性比较大。有没有什么其他方式可以采用呢？

将方法上升到流程规范，让它具有一定的普适性，有具体的步骤或标准，让每个人都可以执行。减少对人的依赖。

例如：

一、上面的问题，规范上加上明确的说明（可增加上线检查清单），生产环境只能采用域名的方式。开发人员或运维人员，其中一人都可以排除此问题。

二、对线上环境的调整，需要根据数据（业务高峰期的访问量等指标）进行评估、验证，才能进行调整。调整后需要通知（反馈）给相关人员。

流程规范，是可以提高团队效率的，避免一些问题的。 从个体来看，因为流程规范的存在，可能存在效率降低的情况，但从团队的角度来看，好的流程规范是可以提高效率的。

上面的问题，通过制定规范去避免，执行得当，是可以提高效率避免问题的。多一步的检查，却少了线上问题的出现，也减少了其他人员排查定位的时间，可谓一举多得。