基于Git提交自动生成工作日报：原理、实现与工程实践
2026/8/5 5:15:21
核心原则：谁的域、谁配置、谁开发、谁运维，谁主责；跨域协同问题共同担责，不单纯甩锅，按根因定责，分四大角色：业务开发、数据库 DBA、平台 / 云底座、运维 / 中间件。
一、业务开发侧全责（90% 线上故障源头）
1. SQL 写法问题
- 无索引、隐式转换、全表扫描、笛卡尔积、超大分页、批量未分页
- 长事务、频繁锁表、update/delete 无 where 条件、循环单条插入
- 直接 select *、未限制返回行数、join 过多关联表
2. 代码 & 业务逻辑问题
- 未做限流、重试风暴、并发无锁导致数据错乱
- 事务边界不合理，长事务占用回滚段 / 行锁
- 未做参数校验，传入超大字符串、非法 ID 触发索引失效
- 未捕获数据库异常，失败无限重试打垮库
3. 表结构 / 使用规范违规
- 自建大表无分库分表，单表超千万无拆分
- 字段类型设计不合理（大 text 存短文本、主键无序）
- 随意加字段、删索引、线上 DDL 不加锁规避方案
- 不按规范使用连接池：连接数开太大 / 太小、未释放连接泄漏
4. 上线变更引发故障
- 上线未做 SQL 性能预审核、未灰度、无回滚脚本
- 新接口突增流量，未提前同步 DBA 扩容 / 优化
一句话定责：纯 SQL、代码、业务逻辑、上线变更导致慢查询、锁等待、连接打满、数据错误 →业务开发主责
二、DBA / 数据库团队全责
1. 数据库基础运维缺陷
- 实例资源不足（CPU / 内存 / 磁盘 / IO 打满，未监控预警）
- 磁盘满、日志堆积、备份失效、归档未清理阻塞写入
- 主从同步延迟过大、切换异常、高可用架构故障
2. 配置、参数管理失误
- 数据库内核参数不合理（缓冲池、连接数、锁超时、事务隔离级别）
- 未合理规划分片、分库资源，容量评估失误
- 权限管控漏洞：误删表、给业务高危 DDL 权限
3. 平台与数据库服务故障
- 数据库集群宕机、节点崩溃、底层存储块损坏
- 版本 bug、数据库内核已知缺陷未升级规避
- 监控缺失：慢查询、锁、资源水位无告警，故障发现滞后
4. 协同支撑失职
- 业务提前报备流量扩容需求，DBA 未及时处理引发压垮
- 未提供 SQL 审核、容量评估、压测支撑，未提前预警风险
一句话定责：数据库实例、集群、底层参数、存储、高可用、运维监控故障 →DBA 主责
三、底座 / 云平台 / 中间件团队全责
1. 底层基础设施故障
- 服务器宕机、网络抖动 / 分区、交换机故障、存储 IO 故障
- 云资源调度异常、带宽打满、内网丢包
2. 中间件 / 连接层问题
- 代理中间件（Proxy）bug、连接池代理限流异常、分片路由错误
- 缓存、消息队列故障间接拖垮数据库
3. 平台管控故障
- 平台自动扩容 / 缩容误操作、自动化脚本删数据、运维平台 bug
一句话定责：网络、服务器、存储、数据库代理、云平台底层故障 →底座 / 中间件团队主责
四、共同责任（跨部门协同问题）
- 流量突增（营销活动）：业务未提前报备 + DBA 未建立活动容量预案 → 双方共责
- 性能隐患长期积累：DBA 持续推送 SQL 优化清单，业务长期不整改；DBA 未强制卡点拦截上线 → 双方共责
- 变更沟通缺失：业务上线未同步 DBA，DBA 巡检未覆盖业务变更 → 双方共责
- 应急处置缓慢：故障发生后业务、DBA 排查配合低效，缺少联合预案 → 共责
五、快速判定根因简易流程（排查时直接用）
- 先看报错：
- 锁超时、慢 SQL、连接耗尽、数据不一致 → 优先业务侧
- 磁盘满、主从断连、实例 crash、IO 飙升无慢 SQL → DBA 侧
- 超时、丢包、连接间歇性断开、所有库同时异常 → 网络 / 底座
- 看时间点：
- 故障和业务上线 / 发版完全同步 → 业务主责
- 凌晨自动备份、归档清理时段故障 → DBA 主责
- 看影响范围：
- 仅单个业务库异常 → 业务 + 该库 DBA
- 全集群所有业务库同时故障 → 底座 / DBA 平台
六、补充：不属于任何人的特殊情况
- 第三方不可抗力：机房断电、光纤挖断、运营商故障（外部责任）
- 恶意攻击：爬虫、CC 打垮数据库（安全团队牵头处置）
- 罕见数据库内核未知 bug（厂商 / 自研数据库团队修复，各方协同止损）
七、落地管理建议（避免互相甩锅）
- 建立上线 SQL 强制审核卡点，DBA 提前拦截高危 SQL，提前规避开发问题；
- 数据库设置资源水位自动告警，DBA 兜底基础设施风险；
- 大型活动必须业务 + DBA 联合做容量评估、压测、限流方案；
- 故障复盘只看根因，不看表面现象，配套整改责任人，而非单纯追责。