研发技术工作全面复盘与整改自查报告.docxVIP

研发技术工作全面复盘与整改自查报告

第一章问题溯源：把“事故”拆成可复现的实验

1.1事故档案

2024-03-1422:47，杭州滨江园区B3栋，「云脉」SaaS核心库出现18分42秒不可读，导致1847家付费客户数据查询返回502。当晚值班经理为平台研发部李晟，技术负责人为中间件组王可。

1.2复现实验

1.2.1环境克隆

使用k8s1.29.2在隔离命名空间cloudrepro中1:1复刻生产镜像，CPU限值、节点污点、内核参数均通过git-ops仓库tagv3.4.7还原。

1.2.2数据回放

通过binlog2sql工具把03-1422:30-23:00的5.3GBbinlog以1×速度重放，同时用tcpdump抓包，确认在22:46:55出现MySQLerror1030“Goterror127fromstorageengine”。

1.2.3变量收敛

逐条注释掉当晚发布的3个PR，发现PR-4281中新增的ALTERTABLE…ALGORITHM=INPLACE在5.7.43-aurora与xfs4.19组合下触发内核bug（ext4延迟分配打满journal）。

1.3根因判定

①代码层：PR-4281未在预发布环境使用生产同等数据量级验证；②运维层：当晚未冻结DDL窗口；③制度层：变更管理委员会（CCB）缺席，紧急上线通道被滥用。

第二章技术整改：让同一类bug第二次出现成本趋近无穷大

2.1代码侧

2.1.1强制回滚脚本自动生成

在GitLabCIjobbuild-db-migration中新增step：

解析PR内所有.sql文件，调用pt-online-schema-change–dry-run，生成反向rollback.sql，并写入mergerequest评论；

若rollback.sql无法生成（如DROPCOLUMN），MR自动拒绝。

2.1.2影子表灰度

所有在线DDL必须先创建_ghost表，双写持续24h，对比checksum差异0.01%方可切流；

灰度量从1%→10%→50%→100%四阶梯，每阶梯至少6h，由FluxCD自动抬升，人为只能降级。

2.1.3SQL评审红线

新增5条正则禁令：ALGORITHM=INPLACE、LOCK=NONE、DROPPRIMARYKEY、CHANGECOLUMN主键名、ALTERTABLECONVERTTOCHARACTERSET；

命中即触发-1评审，需部门总监手动豁免并留档。

2.2数据侧

2.2.1全量数据校验

使用open-source工具titan0.9.3，每日02:00对47个核心库做行级checksum，结果写入ClickHouse；

差异行0即冻结当日所有DDL，并在30min内发起incidentcall。

2.2.2备份可还原证明

每周六04:00随机抽取1个从库，使用备份镜像重建新实例，通过sysbench600s压测，QPS须达到生产80%以上；

连续4周失败即升级P0，CTO介入。

2.3发布侧

2.3.1发布窗口冻结

统一为周二、周四10:00-11:30，其余时间进入“冻结期”，如需紧急发布，需VP级别+值班经理双人批准；

冻结期内在Slack频道#freeze-log用线程形式登记，未登记发布一律回滚并追责。

2.3.2自动化发布门禁

使用ArgoRollouts，蓝绿发布前自动执行30条e2e（基于Cypress+TestNG），通过率100%即中止；

引入“可观测指标”：P99latency上升5%或errorbudget消耗10%即自动回滚，无需人工确认。

第三章制度再造：把“最佳实践”焊进流程

3.1变更管理委员会（CCB）细则

成员：研发总监、QA总监、SRE负责人、安全负责人、DBA负责人，共5人，缺席人数≥2即决策无效；

例会：每周一15:00，议题提前24h在Jiraboard公开；

表决：普通变更过半数，DDL及架构变更需全票通过；

留档：会议纪要自动同步至Confluence空间，保留3年。

3.2紧急上线通道（Hotfix）

触发条件：P0或P1且影响付费客户100家；

流程：值班经理5min内发起Zoom，CC