生产事故江湖再现,CTO扬言干掉一条业务线
还记得上次我发表的生产事故么order by 字段到底要不要加索引?[大坑],定位问题知道是索引问题产生的，那么新业务线上的事故为何又再现呢？
一个平静的下午，17:48生产报障群出现报障，本以为是一次小小的数据不一致问题，但接下来的运维故障以每秒1个，到每秒3个，然后以每秒5个bug的速度爆出，上游业务，影响范围全国，相关服务全部挂掉，然后逐步开始在故障群解决。
问题产生时间：17:48
问题报障：省区业务上报
问题产生原因：上游业务在发版日进行发版，因业务需求，需要将原有索引删除，将现有索引添加，涉及主表数据量1182万条，次主表数量1000万条，上报DBA执行时，将现有索引删除时，还未来得及添加索引，此索引为覆盖索引，由于数据量巨大，当删除索引时，在维护索引的同时，还要将整张表的数据重建，那么可以想象在生产上不断增加数据的同时去删掉索引成本多么的巨大
引用片段https://blog.csdn.net/ActionTech/article/details/95343839MySQL 8.0 将DDL用以下五个维度分类讨论：
- Instant：此变更可以"立刻"完成
- In Place：此变更由InnoDB引擎独立完成，不需要使用Redo log等，可以节省开销
- Rebuild Table：此变更会重建聚簇索引，一般情况下，涉及到数据变更时才需要重建聚簇索引
- Permits Concurrent DML：此变更进行时，是否允许其他DML变更同一张表。此特性关系到变更是否会长时间阻塞业务。
- Only Modifies Metadata：此变更是否只变更元信息，不涉及数据变更。
至于redolog和undolog不在此展开细说，原因就是在海量数据表上维护索引成本巨大，造成DDL锁表。
解决方案：由运维紧急通知全国范围业务，将线上服务杀死，此时删除索引秒完成，且重建索引，重新启动服务，由报障时间起到报障解决恢复时间1小时，报障11900条，此次重大bug，CTO扬言再出现此类问题，10分钟不能解决生产问题的，一条业务线全部干掉！！！
复盘：由于开发人员没有预先在pre环境执行此操作，其实是执行了，但因为短时间没有响应，就私自上报到DBA执行此操作了，导致DBA未能准确评估影响范围，只能停掉服务，释放CPU资源，如果线上长时间CPU100%，数据库极有可能Crash掉，且本次执行时间在业务高峰期，造成影响巨大，也没有补救回滚策略，多部门联合调试减少MTTR时间，且提到应具备熔断降级策略，保证部分接口失效，以此报障90%的接口可用，但此部分我有疑问，问题发生在数据库层面，你保证部分接口可用，请求数据库hang死，你如何保证？这根本不是服务的降级熔断的问题所在，只能说你链路调用是A服务可用，但落库都是相连的，调用B服务断掉，保证A服务的意义不是很大，仍有大量数据需要修复。
反思：除了开发人员应引以为戒之外，对生产环境保持敬畏之心，那么bug这个问题，从公司角度是影响全部产品线，导致用户满意度下降，大局观是如此的，影响范围不仅是开发眼中的数据问题，而是一笔笔真实的订单，那么问题不应该反思到合理的产品评估，严格的测试，为保证高效高质量而给与充足的开发时间吗？有些bug为什么要写？为什么测不出来？为什么产品脑子一热就上线？自己不明白业务，就短时间想要个产品出来，到底是整个公司的氛围有问题，还是打官腔的职场作为让人恶心？