语雀宕机到底给我们什么启示
语雀的 故障报告
先说结论，语雀的宕机完全是公司层面的不作为和员工的不作为两方面所导致的结果
前言
我看了很多人的分析还有这个故障报告，其实都没有讲的特别明白。
那我们仔细来分析一波这个事故的原因到底是什么。
14:07 数据存储运维团队收到监控系统报警，定位到原因是存储在升级中因 新的运维工具 bug 导致节点机器下线；14:15 联系硬件团队尝试将下线机 器重新上线；15:00 确认因存储系统使用的机器类别较老，无法直接操作上 线，立即调整恢复方案为从备份系统中恢复存储数据。
上边是 语雀官方给的发文，其实是有点含糊不清，为什么存储会有问题呢？
我们稍微专业的分析一下，和我们同时会遇到的情况比较一下。
软件开发中我们经常遇到的类似问题
- 阿里云上的云产品，这个月还在售，下个月就不在售了，如果想要解决当前版本的问题，那就必须要升级！
- 这个比较常见，其实维护很多老旧的版本对阿里云的运维来说是一个庞大的负担，相当于一直在做向下兼容的事情。所以，一般都是会有最后的期限必须升级。
- 我们用的一些软件，一般都是有支持期，维护期，不再维护
- 最常见的 JDK 在支持期以后就会进入维护期，最后就不再维护了。很多人都说“你发人你发，我用 JAVA 8” 。哈哈哈
- 还有我们用的开源软件的升级一般不支持大跨度的升级
- 比如，nacos 1.x 升级到 2.x 是有固定的版本的。不能支持从 1.x 直接升级到 最新的 2.x。在最新的 2.x 版本中移除了平滑升级的代码部分。这对我们来说，就是我们在版本出来，稳定之后该升级还是要升级的。
- 一些接口开放平台的升级
- 我们对接微信支付，支付宝支付等第三方平台如果他们进行接口升级的话，他们的老版本，也会在一段时间后进行下线。
真正原因
所以，我们回头再来看，这次的事故，从某种意义上来看，一定是新的存储和旧的存储之间的跨度太大了，导致在存储升级的过程中直接升级失败了。想回滚的时候，旧存储相关的配套运维工具早就已经不在维护了。 瞬间进入了一个开始人工修复的慢性修复过程了。
有人为，为什么他们的旧存储为什么以前不升级呢。
原因：
- 语雀可能不是支付宝的核心盈利产品，所以不会给语雀很高的运维等等资源，导致很多底层资源根本就没有考虑语雀这个产品
- 相关运维和开发呢，也是得过且过，只要代码能跑，为什么要升级存储呢？
- 肯定是突然那天发现，想要用某些底层的功能，突然发现，旧存储不支持相关功能，又必须要用，肯定就直接想升级了。
搞技术的同学到这里估计明白了。那不写代码的同学呢，如何有一个形象的比喻呢？
形象的比喻
本来大街上都是马夫驾马车。 然后汽车时代来临之后，慢慢的越来越多的马夫，开始用汽车去载客了。 可是呢，“语雀”这个马夫呢，没有钱去买汽车，他也不想学习汽车这个技能。 慢慢的大街上，只剩下“语雀”这一个马夫驾着马车了，其他的都开上了汽车。 突然有天，“语雀”发现，很多地方不让骑马了。想要赚钱，只能赶紧搞一个汽车了。他又不想先去学习一下汽车怎么开。前天想换车，第二天就买车上路。 上路就发生车祸了。紧接着就是赶紧抢修了。
那到底有什么启示呢？
保持对新技术的向往，多向时代前沿看齐。不要有点被时代抛弃，万一有一天旧版本的系统支持不了了，那就肯定被时代淘汰了。
“身是菩提树 心如明镜台 时时勤拂拭 勿使惹尘埃” 这首偈语，其实放在我们开发和运维的工作中，很有用。
该升级就要大胆的升级！！！