一个配置引发的血案
一个配置引发的血案，记一次线上事故的复盘。
一天晚上的业务高峰期，出现了超时（数据加载不出来的情况）。
联想到前一天有发版的工作，第一功能上并没有太大的调整，此次发版内容更多的是新增的功能，用户使用量也较少，基本可以排除因功能导致的问题；第二是否中间件出现问题，因数据的交互，有80%是和redis交互，从慢日志查询中未发现有异常情况；第三隐约有人说过用于负载的服务，昨天发版关闭掉了一台。
通过netstat -an |grep 'ESTABLISHED' |grep -i 'port' |wc -l,可查看连接数的情况。
从上面的命令查看到当台服务已经到了瓶颈，然后立即从配置中查看，确实只有一台对外在运行着的。
处理方法：立即启动另外一个服务，修改配置后，验证。业务已正常运行。
和昨晚参与发版的人员核对，昨晚关闭掉一台负载的原因。说是因为启动两台时，出现新加的功能，调用新的服务会出现报错的情况。因未找到原因，和运维沟通后，最后决定只起一台服务。
听完说明后，第一个联想到的就是配置的ip和端口是否正常? 一看配置，ip是本地IP，问题已定位。修改本地IP为域名，功能正常。
此次事件，有多个环节可避免掉此事件。结果各个环节上的疏漏，导致了此次事件的发生。
一、上生产环境的IP配置，统一采用域名的方式。这个是约定，因开发人员不清楚线上域名的情况，未能执行好。
二、运维是部署线上环境的第一人，各服务运行在那台对应的机子上，是最为清楚的一个人，对配置的检查，需要把好最后一道岗。因习惯，未对新增的配置进行审查。
三、对于此次问题的处理，在一定程度上也是可行的方案。但是缺少了数据的支持，未做好测试、评估的工作。在用此方案处理后，未及时反馈给相关人员。
四、对线上运行环境有一定了解的技术（开发）人员未在场。
对于以上问题，解决的方法有很多种。但方法是对于特定问题，而提出的解决方案，是针对特定的场景和特定的人的，对于场景和人的依赖性比较大。
有没有什么其他方式可以采用呢？
将方法上升到流程规范，让它具有一定的普适性，有具体的步骤或标准，让每个人都可以执行。减少对人的依赖。
例如：
一、上面的问题，规范上加上明确的说明（可增加上线检查清单），生产环境只能采用域名的方式。开发人员或运维人员，其中一人都可以排除此问题。
二、对线上环境的调整，需要根据数据（业务高峰期的访问量等指标）进行评估、验证，才能进行调整。调整后需要通知（反馈）给相关人员。
流程规范，是可以提高团队效率的。 从个体来看，因为流程规范的存在，可能存在效率降低的情况，但从团队的角度来看，好的流程规范是可以提高效率的。
上面的问题，通过制定的规范去避免，执行得当，是可以提高效率的。多一步的检查，却少了线上问题的出现，也减少了其他人员排查定位的时间，可谓一举多得。
原文地址https://www.cnblogs.com/fishsky/p/10593233.html
