（作者注：gitlab 也是如此，多级备份没有一个正常工作）
你会发现当无法预料的灾难发生时，他们虽然有详尽的 DRP，但 Murphy's law 不幸应验。很可能，他们从来没有遇到类似的事故，所以也从未试验过他们的 DRP，至少，没有把他们所有三个流程都测试一遍（看起来他们有三级备份，很难得了）。
由于对第一个方案的失败的准备不足，而对第二个方案的时间复杂度估计不足，使得整个服务的恢复过程竟然超过了 48 小时（现在还没完成）。gliffy 的 Eric（Head of Engineer）说 "data transfer is taking longer than expected"，可见第二种方案中，他们的备份和生产环境在不同的物理位置，如果是使用 aws，这就好比生产环境在俄勒冈，备份在弗吉尼亚。假设他们使用了 direct connect，理论上可以达到最大 10Gbps 的传输速度，也就是每秒 1.2GB（当然，工程师需要写代码保证并发处理网络读写，使其达到带宽的上限）。在这样的前提下，1PB 的数据需要大概 243 个小时进行传输，而从 gliffy 的日志看，他们花费在数据传输上所花的时间大概 12 - 24 小时，所以，大致猜测 gliffy 要传输的数据在 50 - 100 TB。
注意，在网络上传输的数据很可能是压缩过的数据，所以，实际的数据量可以要比这个大一倍到几倍。
对于 gliffy 这样的工具而言，48 小时还不足以致命，但在线交易，游戏这样的平台，可能就是灾难性的。如果好好地测试 DRP，了解各个方案的不足并且进而想办法加快处理的速度，就不会这么被动。
以上都是纸上谈兵，事后诸葛。
不过你想想看，如果一个程序员经历了这样的磨难，还能挺过来，她的内心该要有多么强大？Randy Paursch 说：
experience is what you get when you didn't get what you wanted.
当然，最最最重要的，就是杜绝类似的事件发生：
首先，automation, automation, automation! 任何 devOps 操作都要自动化，避免手工操作。以上例子中都是手工操作惹的祸，如果将其脚本化，辅以合适的 review，可以把人为错误的发生概率降到最低。（对于 gitlab，sysadmin 再疲惫，也不太可能出错，因为脚本不会出错）
其次，设置合适的权限（least privilege）。在服务器上，代码部署有代码部署的用户，备份有备份的用户，系统维护有系统维护的用户；在 aws 上，用 iam 设置每种角色，每个用户。用户的权限严格定义，只赋予刚刚够用的权限，对于删除操作，权限一定要慎重。比如说 aws 的 RDS，在 console 里不允许删除 db group，同时 db 的用户不允许删库（只有超级用户才可以）；对于 unix 的特权用户，不要对 sudo 设置免密码，或者仅仅对特定的命令允许免密码，如 apt-get，等等。合适的权限可以避免意外的事情发生。（对于 gitlab，即便脚本出 bug 了，权限系统也会阻止 rm -rf 的执行）
最后，重要的操作一定要预先触发备份 —— 比如删库，通过脚本，使得这样的操作先进行一次完整备份，然后才真正删除。这样，万一误操作还有挽回的余地。（对于 gitlab，即便权限系统被绕过，在执行包含有 rm -rf 的脚本前，也会先备份，在备份期间，清醒过来的 sysadmin 还可以撤销这个操作，即便没撤销，还有一份最新的磁盘映像可以恢复）
希望大家从 gitlab 和 gliffy 的错误中有所收获！
发表评论