IT 领域有个严重性的问题，它的名字叫“故障”。IT 管理人员时刻需要与“故障”抗争，当企业离不开 IT 的时候，必需为生存寻找隐藏其后的致命弱点，因为各种故障随时都可能正在发生。
IT 运维管理部门的真正价值并不是出现故障之后的处理，而是在故障发生前能够准确判断，排除隐患，并避免故障的发生。以下是来自某运维团队在核心数据库发生第二次严重夯死故障后，出具的一份详尽的故障分析报告：
继 8 月初数据库夯死故障紧急重启后，运维团队过了几天安稳日子，原定的各项调优计划都在张罗之中，月内的维优计划是搭乘月末的系统升级窗口，进行四个数据库节点主机重启。
但是，有时候就是这么点背。明天和意外，你永远不知道哪个会先来。多年以后，DBA 摸着白胡子在小院里晒太阳时，准会想起他带头处理故障的那个遥远的中午。
在预定维优计划升级前一天中午 12 点 25 分，系统前台又无故出现大面积的白屏、卡顿、业务办理失败。
与此同时，运维团队也收到了数据库二节点的 Paging space 使用率告警，饭都没吃完的运维团队，立马往办公室跑。
12 点 30 分，运维团队赶到现场着手排查处理问题，发现二节点 DB 严重夯死，一节点也出现大量的连接等待和超时，此时大家闻到了熟悉的味道——数据库夯死“噩梦重现”。结合第一次故障排查缺失信息的经验教训，DBA 和主机管理员首先对运行态日志、内存信息进行了保存，然后着手实施紧急恢复操作。
12 点 40 分，团队实施夯死紧急预案，对数据库主机进行了“心肺复苏”操作——重启数据库节点。DBA 陆续对三节点、四节点、二节点、一节点进行停止数据库监听、查杀监听连接等操作。
13 点 8 分，因几个节点的监听连接全部断开，会话压力释放。二节点夯死故障缓解，一节点可以登录。运维团队重启了一节点数据库，数据库重启耗时 10 分钟。
13 点 18 分，数据库重启完成，继而对各应用软件、服务进行重启，服务及应用平台重启耗时 30 分钟。
13 点 48 分， 重启完成后，前台业务全部恢复。其中数据库故障至重启历时 60 分钟，业务故障至全部恢复，历时 83 分钟。
故障紧急恢复后，运维团队陷入了极大的焦虑与挫败感。这么严重级别的故障，别说一个月两次，在近几年也是从未发生过的。
为确保系统快速恢复稳定，运维团队在 8 月 22 日 -8 月 28 日进行了 Orale bug 修复、数据库主机重启等紧急优化措施。为确保能尽快追根溯源、排查解决根因，规避故障再次发生。运维团队紧急协调了 Oracle 原厂专家、数据库代维厂商专家、应用集成商的运维专家、以及 IBM 硬件专家全部第二天到场，进行问题定位处理，同时，现场团队 7*24 小时对数据库和前台业务进行监控保障。
经过 48 小时的各方联合会诊，这两次数据库严重夯死故障的原因分析结论如下：
数据库物理主机内存资源不足，可用内存太少，在遭受短时间内连接大幅增长的请求风暴后，主机内存快速耗尽，后续使用交换区内存时，系统 IO 性能急剧下降，数据库队列请求大量长时间积压引发夯死 Bug。
通过分析内存和运行日志，发现二节点上调度的批量业务对内存的短时间大量占用，是导致本次主机内存耗尽，进而引发数据库夯死的直接原因。
批量任务虽然是导致数据库夯死的直接原因，但冰冻三尺非一日之寒。作为压死骆驼的最后一根稻草，不应该承担全部责任。
为进一步排查内存高占用和耗尽的原因，运维团队顺藤摸瓜，从系统架构、业务操作、运维监控等多方面进行了分析。内存大量占用、导致数据库夯死的关键原因包括以下方面：
①分布式路由管理的配置及管理：分布式路由管理的优势在于将 SQL 解析为语法树，支持异构数据透明访问接口，实现水平 / 垂直分库和高并发、支持读数据负载和多级路由、以及连接的弹性伸缩扩容。但本次故障分析时发现，管理器的连接数配置较大，日常业务请求不大的时候，也预占大量连接数。运维开发团队不掌握后台连接和前台业务的对应关系，遇紧急情况时无法针对业务优先级进行选择性的业务连接断开。
②系统部署架构：当前业务部署架构，为同城双中心部署，一节点主要承载省会 / 全网业务，二节点主要承载其他地市业务，三四节点承载外围接口 / 后台批量业务，一二节点负载长时间较高，部署架构是否合理，需进一步研判。
③系统监控告警不足：当前主机内存可用量的监控阈值为交换区内存使用时触发告警，但交换分区内存使用时，数据库性能已受到严重影响。对数据库主机内存使用的关注度、风险预判不足。
④业务逻辑：现网业务在繁忙时触发较高的数据库 GC 事件，调用逻辑还有进一步优化空间；
⑤开发运维不规范：在日常开发和运维中，存在执行很多不合规 SQL、对性能影响较大的后台批量脚本等操作；
⑥数据清理及优化：新系统上线至今，因业务变更频繁，对各类数据的保存时限未分级定义，未进行有效的数据清理，SQL 审核和优化工作重视不足。
通过此次故障，结合系统架构实际情况，我们提出并落地了相关优化措施
①数据清理策略确定及清理，释放数据库压力和空间
②数据库表分析计划变更
③结合数据库主机内存和性能，优化数据库连接数限制；
④分析梳理数据库连接的应用并进化
⑤在批量连接梳理清楚后，进行降级预案制定；
①优化数据库数据清理策略并执行清理，释放数据库压力和空间
②结合数据库主机内存和性能，优化数据库连接数限制；
③分析梳理数据库连接的应用并进行优化
④梳理批量连接后，进行降级预案制定；
①双数据中心的部署架构的优化；
②新老系统的库表同步问题，需应用系统侧同步进行优化；
③核心数据库库存在大量写日志问题，需优化业务连接至运维库或写日志文件
④对利旧系统的核心表梳理并迁移至新系统中，减少新老架构混搭的复杂度
对于 IT 系统来说，业务连续性永远在路上。
我们也看到了业界一些大厂，近年也在基础设施稳定性方面，栽了跟头，就拿 2016-2017 这两年来说：
2016.1.6 汇丰银行网站无法登入 影响：1700 万名个人及商业客户无法访问
2016.1.28 Github 全球服务中断 影响：所有托管开源项目不可用
2016.3.10 亚马逊电商网站中断访问 影响：亚马逊电子商务主网站及云计算服务不可用
2016.3.22 全日航空系统宕机 (oracle rac 故障) 影响：超过 100 个航班取消
2016.8.8 达美航空系统宕机 影响：451 趟航班不能按计划起飞
2016.11.2 ING 银行数据中心宕机 影响：超过一百万用户无法使用 ING 银行服务
2017.1.14 炉石传说系统宕机 影响：40 小时无法访问，数据回档
2017.9.8 某运营商网络设备故障 影响：数十万用户无法正常通话
......
运维永远不能存侥幸心理，只要有漏洞风险、监控不足、运维缺位等情况时。总有一次故障，在等待着你自己撞到枪口上来。
我们的系统架构从存储、主机、网络、服务层、应用层进行了大量的架构升级和演进，基础架构建设了 1:1 的双活数据中心、存储采用了较为先进的虚拟双活技术、服务器采用了最新商用版本的计算虚拟化、数据访问层使用了分布式处理框架、服务和平台层也进一步实现了服务编排和标准化的封装发布、系统也进一步向互联网化体验去转型。
新技术的应用让我们欣喜，因为再不用为差几台服务器而满机房挪腾设备了、不用为一个小的紧急功能变更而停下整个业务系统、也不用为秒杀而忧虑前台业务白屏风险。
但是，我们在追逐技术的革新与演进时，过于依赖架构自身的稳定性，而与架构演进匹配的运维能力体系构建，还做得不到位。当系统架构已经换成了跑车引擎时，我们的运维思路和模式没有及时跟上的话，原本是策马奔腾、百花齐放的美好愿景，可能就会变成马扯着人跑的尴尬景象。
我们望着前方跑的太快的同时，没有注意脚底的鞋子，是不是磨出了洞。我们离架构敏捷、智能运营、极致体验、能力开放还有很长的路要走。
建立在我们业务形态、业务体量下最合适的运维模式（包括组织和分工、运维规范、运维平台和手段），进而解决历史的积弊问题，及时发现并解决各类风险，提升架构的轻捷性稳定性。已经是摆在我们案头，亟待推进探索的课题。
希望，若干年后，我们的运维团队被问到，下一次重大活动将如何保障，能这样有底气的回答：
完全不用刻意保障，业务连续性全天候达到 99.99%。
你能想到的风险，我们都演练规避了。
最后，附赠一张故障分析会上，DBA 挥斥方遒、总结分析的福利照：
Google 如何用 AI 造聊天机器人？Pinterest 如何用机器学习获得两亿活跃用户？10 月 QCon 上海站，还有来自 Uber、Paypal、LinkedIn、Airbnb 等顶尖技术专家前来分享前沿实践经验。QCon 报名即将结束，识别下方二维码或点击【阅读原文】与 100+ 国内外技术大咖零距离，如有问题欢迎联系票务经理 Hanna ，电话：15110019061，微信：qcon-0410。
