上周（2017-04-05），位于纽约的云服务商 Digital Ocean 遭遇了一次长达4小时56分钟的停机事故，事故的原因竟然是：主数据库被删除了（primary database had been deleted）。
我曾经开过一个玩笑说：没有删除过数据库的DBA，职业生涯是不完整的。现在看起来，又有人因此而完整了。
对于我们来说，需要本着科学的态度，学习并且引以为警示，做到防患于未然。
Digital Ocean 公布了整个故障的根本原因（Root Cause）：
The root cause of this incident was a engineer-driven configuration error. A process performing automated testing was misconfigured using production credentials.
故障的根本原因在于工程师的配置错误，一个自动执行的测试流程使用了错误提供的生产环境认证配置。
这个根本原因翻译过来就是：由于配置错误，本应指向测试环境的任务被指向了生产环境，测试任务包含的环境初始化过程删除了主生产数据库。
幸运的是，Digital Ocean 公司实现了 DBA 守则的第一条：有效的备份重于一切。
他们在发现故障后三分钟发现了数据库被删除，随后在7分钟内启动恢复任务，时间线非常清晰：
-
T0.00 - 10:24 EDT - First observation of issues
-
T0.03 - 10:27 EDT - Verified that production database had been deleted on master
-
T0.10 - 10:34 EDT - Began recovery from time-delayed replica
-
T1.29 - 11:53 EDT - Backup of time-delayed replica completed
-
T2.10 - 12:34 EDT - Copy of backup to master completed; recovery commencing
-
T3.07 - 13:31 EDT - Recovery of master completed; copy of backups to replicas ongoing
-
T4.56 - 15:20 EDT - All systems restored
这个故障告诉我们什么呢？我认为规则的重要不断凸现出来。
我在前一段总结了 数据库安全的16条军规，其中的几条正是基于类似的惨痛教训总结而来的，我筛选几条和大家分享：
备份重于一切
我曾经在总结的DBA四大守则的第一条就指出，『备份重于一切』，有了有效的备份，即使遭遇灾难，也可以从容应对，对于重要的生产环境，适当建立备库进行数据保护，查询分担，也会减少生产库的风险；
唯一会让DBA们从梦中惊醒的就是:没有备份! 所以对于数据库运维来说，第一重要的是做好备份!有备方能无患!
限制登录工具
明确限制不同工具的使用场景，明确规定工具的准确来源，或者通过堡垒机等来限制数据库访问。对于工具也可以做出明确规则和限制，如限制仅能通过SQL Developer访问生产，PL/SQL Developer工具仅能访问测试环境，以减少安全风险甚至误操作风险；
测试和生产隔离
互通就意味着同时可以访问，也就可能带来很多意想不到的安全风险，企业应当将测试环境和生产环境部署于不可互通，或者不可同时访问的网络环境中，避免因为错误连接而发生的数据库灾难。 分离部署一方面可以降低误操作的可能性，也可以屏蔽一些无关的访问可能，从而从网络链路上保证数据安全；
密码差异设置
有些测试环境或者非产品环境是利用产品环境恢复得到的，DBA在建立了测试环境后，就没有修改数据库用户的登录密码;经常性的，DBA也习惯在所有环境中设置通用的密码;这些习惯为系统带来了很多风险和不确定性。 我们建议用户在不同环境中采用不同的密码设置，这是因为一方面产品环境和测试环境面对的访问用户不同，密码设置相同则意味着产品环境的安全性完全得不到保障;另一方面，DBA登录到不同的数据库需要使用不同的密码，这进一步减低了DBA在错误的环境下执行命令的可能性。
这样的例子已经屡见不鲜了，近期的就有：
五重备份无一有效，还有哪些 rm -rf 和GitLab类似的忧伤？
如何检查和发现数据库的隐含风险呢？你可以通过云和恩墨的免费智能巡检平台 - Bethune 来进行全面诊断和检查。
Bethune （ https://bethune.enmotech.com ）为你的数据库发现潜在问题，早日消除安全隐患！
祝愿大家的 DBA 生涯都能够平安圆满！
文章转自数据和云公众号，原文链接
