各位好，本文为事故复盘。
据监控记录，乐乐网站严重崩溃了近7个小时，实际不止，距离乐乐重装系统才完全恢复乐乐所有站点的访问。
此次的故障是距离乐乐网站有记录以来，最为严重，时间最长的非计划性故障。
事件概括
乐乐网站于2024/1/12 19:47:00崩溃，阿里云立即检测到，并且进行自动重启。
乐乐即可察觉到服务器无法提供正常网站服务，并且即可开始初步抢救
经过初步抢救，分析问题：可以ssh登录，但是无法使用类似于yum的命令
乐乐经初步抢救无效，于当日19:52:53提交工单
乐乐于2025年01月12日 20:20发布公告，宣告出现错误
点击可查看当时的公告
乐乐服务器于2025-01-13 00:37:15（次日）经过阿里云工程师深度恢复,宣布没救了（不是
开个玩笑哈，乐乐服务器的部分功能恢复正常，已经可以实现备份以及拷贝数据。
此时，乐乐网站的Nginx服务在线，而httpd（提供blog服务）不在线。
在次日，经过初步恢复后，我们宣布系统可能在编译中出现错乱，决定在备份数据后重装系统。
事故原因
事故主要出现原因：乐乐当日在服务器线上弄环境，还没有备份，可恶至极
呃，其实还是有备份的，只不过因为备份时间比较早，所以没有立即恢复而已。
当时，我正在弄gitea。
大家都知道，很多软件需要安装一堆玩意，gitea也不例外，而且恰巧要求的node.js需要的glibc版本和centos7.9提供的glibc版本不兼容，所以乐乐当时就编译了新版glibc，结果也不知道在安装过程中出现了什么差错，然后编译导致系统错乱。
后面gitea也弄好了，但是这不是今天这篇博文要讲的事情。
事后解决
本次事故其实没有啥好事后解决的，主要就是乐乐在线上弄环境，才导致的崩溃。
此事使我学到了两个教训：不要动系统原本的环境，尤其是那些刚需库。要及时打快照
以后我要尽量不要动系统环境，如果要动，要在做好备份，线下动系统环境。
如何避免以后发生这些不可预期情况？
同上，如果实在不行，优先创建当前快照，并且将快照下载到本地进行排查和数据提取，同时，恢复到最新快照，优先保证网站访问优先。如果乐乐服务器出现物理机崩溃，断电（虽然阿里机房基本上不会有这种问题吧。。。）也可以临时把服务器快照打到树莓派，通过内网穿透，临时恢复乐乐网站的访问。
最后，感谢阿里云工作人员半夜加班帮我解决问题，我以后会减少这种非预期的问题。
其实乐乐网站是一个小站，如果实在崩溃几秒钟也不会有人关心的吧，应该把。。。
2 comments
?文化类评语?
作者的观点新颖且实用，让人在阅读中获得了新的思考和灵感。