阿里云、滴滴服务故障简单复盘

前言

临近年末，各大厂运维的日子似乎没那么好过。先有阿里云两次故障，后接着滴滴服务故障。影响都不小。估计这两个公司的运维团队算是完成“降本增效（笑）”了。
解释一下这个名词：
1、增效是指运维团队年终奖和绩效肯定没了，公司成本降低；
2、增笑是指给广大吃瓜群众带来了笑料😆😆😆。

玩笑归玩笑，言归正传。

运维故障如何预防

我问了一下chatgpt3.5, (对不起各位股东，，经济形势不好，穷，只能用免费版)，以下答案仅供参考。

1. 定期进行系统和设备的检查和维护，包括硬件和软件的更新和优化。

2. 实施监控系统，及时发现并解决潜在的故障。

3. 建立完善的备份和恢复机制，确保数据和系统可以及时恢复。

4. 加强安全措施，保护系统免受恶意攻击和病毒感染。

5. 建立良好的变更管理流程，确保系统升级和改动的稳定性和可靠性。

6. 培训和提升运维人员的技能和意识，提高他们对系统和设备的管理和维护能力。

7. 定期进行容量规划和性能优化，确保系统资源的合理分配和利用。

我对这三次故障的简单复盘

从最近的几次故障，各大群里议论纷纷，我的理解如下，仅供参考：
一、生产变更流程管理不完善，变更时间选取不合理。

1.1 阿里云的第一起案例来自周末，符合属于正常变更时间范畴，但是从响应来看，相对比较滞后。考虑到刚双十一结束，这个时间点是大家都比较累的状态，并且是周末，不应该安排重要变更。
1.2 滴滴变更是工作日晚上10点，也是属于滴滴业务高峰期。这变更时间明显有问题。
重大变更在业务低峰期进行，且有合理回退方案。 这应该是运维的共识吧。

二、重要变更复核机制不完善
这三起故障从目前公开的或者流传的原因来看，都是简单的问题导致大面积的服务不可用。这个说明了变更复核机制是有问题的。我个人觉得好的运维状态应该是有规范制度，并且这些规范制最大化以用工具实现，减少人为操作。不能工具化的低频操作也应该提前出方案,多方复核。变更时最好双人互相复复核，只按照方案执行，不临时更改方案。当然这个只是理想化的场景，现实的情况总是一地鸡毛，家家都有难念的经。

三、对生产环境缺乏敬畏
我觉得不管什么时候，对生产环境还是要抱有极大的敬畏之心，尽量不要疲劳驾驶。（现实情况可能真的人手不够，天天人肉运维，疲劳驾驶是常态。毕竟运维这种平时不起眼的脏活累活又不能刷kpi，对吧，哈哈，你懂得）

MySQL数据库故障预案以及常用工具

最后给大家扯一扯MySQL数据库的一些预案。
1、做好备份恢复 物理备份+binlog

物理备份恢复：xtrabackup、mybackup、克隆插件 

binlog备份：mysqlbinlog、my2sql

逻辑备份：mysqldump、mysqldumper、mysql shell utils

2、做好高可用 重要系统做延迟从库

3、做好sql上线审核
工具：goinception、archery、bytebase等工具，最好有dml回滚。

4、定期做备份恢复演练、应急切换演练 精力足够的团队可将这些功能做成自定化工具。按照一定的调度策略定期演练。

其他具体工具也可参考我之前的文章 mysql生态工具简单汇总。