每个DBA的运维生涯里，总有那么几句话，一听见就忍不住心头一紧，哪怕身经百战，也会瞬间绷紧神经。
第五期【DBA 坦白局】邀请到九位来自不同行业、有着不同经历的DBA朋友，分享他们工作中最“怕”听到的话语及背后原因，希望以此让行业内外更了解DBA、了解DBA的真实痛点和压力来源。欢迎阅读本文、参与文末互动分享你的故事~
5年以上DBA从业经验，现服务于金融行业
我最怕听到的是这三句话，并且这些都是实际遇到过的情况：
1、数据库又连不上了 ，怎么总是不稳定
2、生产数据出错了/删错了
3、数据库备份都被删了
大多发生在分布式数据库，因为都连接到同一个节点压力比较大，可能会引起某一个节点OOM导致重启，重启过程中 其它设置连接这个节点的就会导致连接报错。但客户常会认为是数据库配置的问题，实际上需要在数据库前加负载均衡来分配前端请求，所以我更担心的其实是责任界定不清。
随着经验的增加，我会从数据量、当前需求、未来需求、峰值需求这些方面和客户沟通，来减少这类突发事件的发生。我觉得经验很重要，见得多了思路就多，解决问题更快，还能做一些预防工作，另外了解数据库原理是必不可少的。
8年DBA从业经验，现服务于互联网行业
我最不想听到的是这三句话，也可以说是三个场景，遇到的还挺多的：
1、需求不明确，创建资源没有原因和配置等，需要反复沟通
2、数据不小心删掉了，帮忙恢复
3、应用查询慢了，看看是不是数据库有啥异常，慢查询，有可能不是数据库造成
“需求不明确” 这类问题其实和公司有关，有的公司运维平台很健全就较少出现；但 “数据误删需恢复”“应用查询慢怀疑数据库问题” 这两类，我觉得每个公司都会存在。我觉得这些问题出现的原因，一是公司内数据库规范推广不彻底，没有强制填写需求字段的工单；二是应用端缺乏数据库相关知识。可以通过使用SQL审核平台、数据库工单平台、建立更精确的监控粒度来尽可能避免。
4年DBA从业经验
我目前在云厂商工作，数据库侧 DBA 话语权比较重，所以数据库运维中没有传统 DBA 怕听到的话，现在最怕听到三句话：
1、当时产品就是这么设计的，现在要改不好排期。
2、现在没人力，问题统一提到下下版本解决。
3、客户没有DBA，咱先加急处理下，后续看着再补费用。
我其实是一线出身，深知客户场景与交付压力。现在除了做 DBA，还要解决一线与研发之间的 “矛盾”——客户看重价值与体验，研发看重可交付与质量，我的解法是将一线交付障碍做归纳整理并进行风险排序，再就是积极响应、高质量服务交付做到7*24小时三线支撑，先快速解决问题再复盘规避。我之所以不爽前面两句话， 是因为我已经把问题量化了、风险排序，研发却搪塞敷衍，让我觉得我就做DBA交付也能获得很好的口碑、也能满足客户需求，有啥必要在7*24小时高压工作环境下还抽时间去做数据整理呢。
10年DBA从业经验，现服务于IT行业
日常运维中最怕听到的三句话是
1、恢复了么
2、快点
3、还没好么
一般都是在故障影响业务时候会遇到，主要是因为客户或负责人不太清楚当前故障的恢复难易程度，只是在催促。我一边会和对方沟通说明故障情况及预计恢复时间，一边并发着继续干。
8年DBA从业经验，服务行业较多
我最怕听到的话只有一个，那就是 “某某系统又出问题了”。
主要是因为有些客户给了建议不听、听了又不做、做了又不会，导致问题重复出现，重复沟通很心累。其实信创背景下，大家都非必要不变更（升级/补丁/系统优化），业务也很少改动，也会增加问题重复的可能。面对这种情况，我只能向客户说明问题利害、提供应急预案；从服务客户的情况来看，极少客户会有这种“不听建议”的共性，大部分客户还是会听从专业建议。
3年DBA从业经验，现服务于政务行业
我最怕听到的是这三句话：
1、研发：我不小心删除了表/数据，帮忙我恢复下
2、研发：业务有条SQL很慢，帮忙加个索引
3、项目经理：这个库已提单扩容/缩容了，怎么SQL还是慢/存储使用率怎么一直报警
详细给大家讲讲是怎么回事，第一个是这样，我们目前生产库大部分都是上了云，但我们只有使用实例的权限。恢复一般是提单让业务审批走流程，兼DBA以来按这个流程很少，倒是前几个月信创迁移时给我敲了下警钟。周六那天，某位研发中午急忙打给我，说他不小心删除了表（生产的）让我赶紧帮忙恢复下（删除了多少也不确定）。到工位一看，好家伙，研发平时拿高权限用图形界面用惯了，说不小打开表滑到删除表……然后那天本来是在迁移其他库的，大半天都走流程，恢复完还得帮他迁移（之前研发说自己迁）。 迁移后账号权限全面收紧，专业的事交给专业的人做。
第二句话，与其说怕，不如反感，我是反感一上来就说加索引的。通常我拿到SQL会结合执行计划，接我理解改写一遍验证下（因为是sqlboy出身，研发写的SQL不算复杂）。
第三句话通常是变更时忘了同步调数据库参数，有次是一个高性能库缩到原来的1/4但shard_buffer没同步调整，导致查询慢。还有一次是某个保留wal日志大小的参数也没改，造成wal日志比本体数据还大几倍的情况，这个不太容易发现（一般来说是业务量变小后才缩容，刚好有段时间那个库的大表多次批量更新，很快就把wal日志推高了）。
11年DBA从业经验，现服务于金融行业
我在数据库运维中最怕听到三句话，且分别来自不同对象：
1、（领导）昨天清算操作晚了，数据库又卡了吗？
2、（开发）我就删了一个数据文件，不应该卡住啊？
3、（系统管理员）数据库是DBA安装的，他们统一管理，我们不知道，去找DBA
怕听到领导那句话，是因为就算不是数据库的问题，也需要跟进排查，且可能要跟进很久；怕听到开发那句话，是因为这意味着数据库可能要宕机，需要紧急处理；怕听到系统管理员那句话，是因为不管什么事都找自己，压力太大，而且很多配置和修改其实是系统管理员他们做的。
10年兼职数据库工作经验
我主要是用友ERP实施顾问，不是专职做数据库的，只是兼顾数据库相关工作。在数据库运维这块最怕听到的两句话是 “数据库挂了”“系统进不去了”，并且遇到次数很多。
我会感到“怕”，主要是因为自己数据库相关能力不足，无法支撑这些系统恢复，而且没有其他人能帮忙，只能靠自己摸索着停机恢复。虽然有过多次处理经验，但因为本身不是专职做数据库的，面对这类问题还是会怕，也担心遇到新的、自己更无法应对的情况。
5年DBA从业经验，目前在银行乙方
日常运维工作中，我最怕听到的话其实已经不多了，其中之一就是银监又下发BUG了，如果命中并且这个bug会影响数据库运行这就需要打补丁了，这代表着加班任务又多了。
目前碰到过两次需要打补丁的，一次是Oracle 19.7上的，最后选择升级到19.13，几十套系统，每个系统停业窗口都不一样，最终耗时一年升级完成。还有一次是19.21上的需要打两个one off，系统也不少也花了一年，总之碰到了就是长久加班。
现在我听到银监下发BUG就开始祈祷，不要命中不要命中，或者最好是个影响不大的BUG。
结语
感谢9位DBA朋友的真诚分享，从金融到政务、从甲方到乙方，大家的“怕”有些是技术难题与技术规范、有些来自于跨岗位沟通与责任压力，但本质上都是对业务稳定的牵挂、对责任的敬畏。他们虽说“怕”听到，每每听到也会想办法去处理，甚至通过推动规范流程、收紧权限、优化沟通方式等等方式来进一步预防这些问题。
或许这些真实的场景和话语能引起许多DBA朋友的共鸣，也能让曾对DBA有误会的人更懂他们的压力。数据库运维从不是DBA一个人的事，只有大家一起配合推进规范、分担压力，才能少一些 “怕听到的话”，多一些业务稳定运行的安心。也愿DBA们在这些合作中，既能积累更多经验，也能让自己的工作少些被动，多些从容。
相关阅读（点击跳转阅读）：
【DBA坦白局】第一期：在小城市和一线城市做DBA，是“躺”还是“卷”？
【DBA坦白局】第二期：13位一线DBA的国产数据库真实运维体验
【DBA坦白局】第三期：作为DBA，你加过最晚的班是到几点？在干什么？
【DBA坦白局】第四期：35岁危机到底是否存在？听听DBA们的真实焦虑与感悟
【🎙️话题互动】你的运维日常里，是否也有 “怕听到的话”？和大家的压力来源又是否一样？欢迎评论区分享给我们~
