数据全丢了🤦‍♀️

丢人，真的太丢人了。

这个博客本来么一直都是托管在 vultr 的，原因也很简单，2.5刀一个月够便宜，面板还贼好用，备份快照都是点一下鼠标的事。

直到回国之后新开了个虚拟机搭梯子，用完之后自然是要删掉省点钱的对吧

淦，手抖点错了。

不过不要紧，我们还有备份对吧，

• daily backup 不知道什么时候被关了，霍日
• 最近一份快照是2018年五月的，还不带数据库（那时候数据库在aws托管）
• s3 里完全没有任何数据库备份
• 自己写的备份脚本很久以前就停止工作了

这就真的很尴尬了，和 gitlab 那时候事件非常类似，都是你以为你有很完备的备份策略，数据绝对是安全的，但事实上你的备份数据是假的，出了事没一个能派上用场。

这当然是一个悲伤的故事，要不是 Google 有缓存，从高中开始写的博客真的全没了。很幸运目前恢复了大部分的文章和18年五月之前的图片，不过别的基本都丢了。

说这个的故事在于警示所有人：

• 你的备份策略真的有用吗？
• 你有做过灾害演练吗？
• 你的应用是否真的便携、抽象且解耦？

第三个问题看似不相干，但我认为这是非常容易被忽视的一点。一个服务如果耦合度非常高，缺了任何一个零散部件就不能工作，这样一来设计一套完整的数据安全策略就很困难了，因为很难面面俱到，而人总是会有过失的。

为了解决这个问题，我做了如下改变：

• 把所有的服务都容器化。所有的服务配置都在一个文件里，一行 docker-compose up 就可以拉起服务，包括应用本身，数据库和外层的 load balancer（以及相关的配置文件）
• 所有 persistent storage 统一中心化管理，默认所有其他的数据都是易失的并且有意定期扔掉。这样的好处很明显，把问题暴露在早期永远比后期丢数据了要好，备份脚本只需要打包一个文件夹就打包了整个服务。

这样做的好处当然是非常明显的。现在这个服务跑在 Scaleway 一台 ARM 架构的 Debian 服务器上（故意的），但如果需要可以只需要一行命令就可以无缝部署在另一台 x86、 Power 架构的服务器甚至是自己家的群晖 NAS 上，所有我需要做的只是从对象存储上拉一个文件，因为 Docker 把这些底层的差异都抹平了。

在恢复数据的时候，我也顺便看了看以前写过的文章，好多都是在讲如何部署、如何编译、如何在xx系统上安装xx，提供xx服务。

这当然是没问题的，如果业务敏感，连寄存器的 bit 都要扣，就不要说动态链接库了。可这真的是大多数业务会遇到的吗？

我在工作中经常会遇到这种事情：xx 服务依赖于xx库，但xx库在xx系统中不被支持。而系统和底层库的升级成本实在是太高，大多是公司统一部署的，稍有不慎就会遇到依赖地狱。试想使用容器之后：各个解耦后的服务运行在自己的容器里，通过socket通信，这对安全性的提升是肉眼可见的。一些使用了较旧依赖的容器也可以被重点关照，而不必影响到其他容器。至于性能的损失则实在是无关紧要，因为解决的问题比这点损失大多了。

大公司技术实力很强，有完善的代码管理、CI、build system，有专门的 DevOps 团队来推动技术升级，这自然不是问题。可是小公司就难受了，内部难有统一的技术栈，各个团队都是自己搞一套，混乱。

这几年越发感到，软件工程领域，大多数情况下沟通成本比技术债要大很多，优秀的管理水平很重要，但老被轻视。

人生苦短，go get a life 吧。