来源 | 云头条

欧洲中部时间10月17日晚上10点45分左右，Keepthescore的创始人兼程序员在几杯红酒下肚后，无意中删除了生产数据库。超过300.00个记分牌及相关数据顿时人间蒸发。

值得庆幸的是，该公司使用的是DigitalOcean提供的一款托管数据库，这意味着DigitalOcean每天自动执行一次备份。经历了5分钟的紧张和恐慌后，Keepthescore工作人员将网站置于维护模式，竭力恢复备份。欧洲中部时间晚上11点15左右即灾难发生后30分钟，恢复了正常，但是7个小时的记分牌数据永远消失了。

确切地说，2020年10月17日15点47分至23点21分之间创建的任何记分牌或添加的任何分数统统丢失了。

到底发生了什么？

有人忍不住会将这场灾难归咎于几杯红酒。然而，擦除数据库的函数却是在清醒的时候编写的。一个函数删除了本地数据库，并从头开始创建所有必需的表。今天晚上，就在深夜编写一些代码之际，该函数连接到生产数据库，并清除了该数据库。

为什么？目前仍在努力搞明白原因。

以下是造成灾难的代码：

def database_model_create():    """Only works on localhost to prevent catastrophe"""    database = config.DevelopmentConfig.DB_DATABASE    user = config.DevelopmentConfig.DB_USERNAME    password = config.DevelopmentConfig.DB_PASSWORD    port = config.DevelopmentConfig.DB_PORT    local_db = PostgresqlDatabase(database=database, user=user, password=password, host='localhost', port=port)    local_db.drop_tables([Game, Player, Round, Score, Order])    local_db.create_tables([Game, Player, Round, Score, Order])    print('Initialized the local database.')

请注意，host被硬编码成了localhost。这意味着它永远无法连接到除开发者机器之外的任何机器上。另外：当然，Keepthescore为开发和生产环境使用不同的密码和用户。眼下他们太累了，还没有搞清是怎么回事。

学到了什么教训？为什么这种情况不会再次发生？

Keepthescore已明白，拥有删除数据库的函数实在太危险了，不能到处乱用。问题是，您永远无法真正适当地测试安全机制，因为进行测试将意味着对生产数据库下手。

Keepthescore已明白，拥有便于快速恢复的备份绝对必要。他们感谢DigitalOcean，使这项工作可靠又简单。

幸好，没人因这场灾难而丢掉饭碗。创始人不会解雇开发人员，因为他们是同一个人。

此外，这个Web应用程序只是一个附带项目而已，不是运行电厂的那种软件。

颇具讽刺意味的是，就在几天前，他们还刚发布了一条推文，内容正是有关删除生产数据库的可笑的文化基因：

往期推荐

前瞻：在 Java 16 中会带来哪些新特性？

高可用 Prometheus 的常见问题

Fastjson < 1.2.68版本反序列化漏洞分析篇

音效摸鱼还不够爽？试试IDE里打几盘魂斗罗？

一个让你敲代码的同时，找回童年乐趣的 IntelliJ 插件

扫一扫，关注我

一起学习，一起进步

每周赠书，福利不断

﹀

﹀

﹀

深度内容

推荐加入

最近热门内容回顾   #技术人系列