前言
事故经过
1、接口超时事故
1）、现象
2021年12月某周一上午，负责管理网络的同事(俗称网管)一大早巡检过程中发现有一个服务挂掉了，他当时没在意，直接重启就好了，但到了10点左右，忽然三四个服务：挂号服务、门诊服务、检查报告服务等一起挂掉了，而且重启十几分钟后又会挂掉，瞬间公司就炸锅了，网管、开发人员、技术主管集体冒汗，在紧急处理过程中，还不断有院方电话打给主管、总经理直到大老板，领导就站在我们背后着急的等待我们处理，我想很多人应该有画面了。
2）、原因
大概到中午都没解决，因为没有日志平台的情况下，定位问题是一件不容易的事情，后来在中午休息时间技术主管和我们终于发现了门诊服务中调用某软his接口出现超时，而周一上午的流量又很大，平常偶尔超时也没问题没人在意，这次一个小小的接口超时竟然直接把服务全部堵塞，调用该接口的挂号和门诊服务全部挂掉，而和门诊服务有一点耦合的检查报告服务也在疯狂的超时等待又超时又等待中挂掉了。
最终，紧急联系院方找厂商服务团队查找该接口问题，同时我们临时把几个服务全部重启，总算在所有人惶惶不安的努力下3点之前恢复了正常。
3）、总结及处理
事后，老板大发雷霆，并召开批斗大会点出了团队没有危机处理预案等等种种问题，据说是被院方碉堡了。我们怀着谦虚忐忑的心情在小本上疯狂做笔记(做样子)，算是挺过去了，唯独主管比较难受，要亲自写好几个事故报告给甲方，懂的都懂。
接口超时时间之后发现设置为60秒，真特么离谱啊，之前竟没一个人关注(包括我)，没问题的情况下自然万事大吉，但凡出了问题，60秒的超时时间这是人干的事么，有什么接口若需要60秒，那本身就是一枚定时炸弹，必须一开始就拆掉。
很多公司的项目其实都存在这个问题，碍于调用第三方接口难以预估超时时间，所以就设置的比较长，可实际上，这会给项目带来莫大的隐患，处理方式很简单：
2、锁表事故
1）、现象
这个事故和前面的相比算是小事故了，但依然令人心惊胆战，毕竟快过年了，谁也不想出问题。墨菲定律讲过，越是你害怕的事情越是会到来，果不其然，年前大概就是前一两周的样子，某天下午一家三甲医院的挂号服务未响应，在前端的效果就是，你打开了小程序，点击了挂号服务，然后某个功能一直加载中，最后页面未响应或假死。
2）、原因
锁表，因为负责维护该医院的同事，在下午四点中的时候给挂号表新增了一个可以为空的字段，而挂号表是百万数据的大表，直接执行SQL新增字段还附带部分条件，直接导致整个表都锁掉了，前端发来的请求就一直无法对该表执行其他操作，最终未响应及假死。
既然锁了就要解，操作很简单，但集成同事刚好一时联系不上，开发人员又不熟悉内网环境，前后花了一个小时时间才解锁恢复正常，在一堆病患使用过程中，一个小时时间内都无法挂号，这背后的凶残你可想而知。
3）、总结及处理
给该表迅速解锁，有条件的话最好让本公司专业DBA或集成同事来操作，他们更熟悉数据库服务及项目部署，操作更安全，如果公司没有这样的同事，只能百度一下咯。
MySQL解锁方式：
# 1. 查看当前数据库锁表的情况
SELECT * FROM information_schema.INNODB_TRX;
# 2. 杀掉查询结果中锁表的trx_mysql_thread_id
kill trx_mysql_thread_id
Oracle解锁方式：
# 查看被锁的表ct
select b.owner, b.object_name, a.session_id, a.locked_mode
from v$locked_object a, dba_objects b where b.OBJECT_ID = a.OBJECT_ID
# 查看连接的进程
select sid, serial#, username, osuser from v$session;
# 杀掉进程 sid, serial#
alter system kill session '678,983';
总结
本人文章从来都是纯手打，且都来自实际工作中的经验及分享，如果觉得有一滴滴帮助，就点个赞和收藏吧！(o…o)~
