Gitlab 删库引发的思考：你也陷入到“人肉运维”的怪圈中了？

高效运维 · 公众号 · 运维 · 2017-02-03 07:14

正文

大约有 ±4979 提交记录丢失了（陈皓注：估计也可以用git仓库中反向恢复）。

可能有 707 用户丢失了，这个数据来自Kibana的日志。

在1月31日17:20 后的 Webhooks 丢失了。

因为 Gitlab 把整个事件的细节公开了出来，所以，也得到了很多外部的帮助，2nd Quadrant 的 CTO – Simon Riggs 在他的 blog 上也发布文章 Dataloss at Gitlab 给了一些非常不错的建议：

关于 PostgreSQL 9.6 的数据同步 hang 住的问题，可能有一些Bug，正在fix中。
PostgreSQL 有 4GB 的同步滞后是正常的，这不是什么问题。
正常的停止从结点，会让主结点自动释放 WALSender 的链接数，所以，不应该重新配置主结点的 max_wal_senders 参数。但是，停止从结点时，主结点的复数连接数不会很快的被释放，而新启动的从结点又会消耗更多的链接数。他认为，Gitlab 配置的32个链接数太高了，通常来说，2到4个就足够了。
另外，之前 gitlab 配置的 max_connections=8000 太高了，现在降到2000个是合理的。
pg_basebackup 会先在主结点上建一个 checkpoint，然后再开始同步，这个过程大约需要4分钟。
手动的删除数据库目录是非常危险的操作，这个事应该交给程序来做。推荐使用刚 release 的 repmgr。
恢复备份也是非常重要的，所以，也应该用相应的程序来做。推荐使用 barman （其支持S3）。
测试备份和恢复是一个很重要的过程。

看这个样子，估计也有一定的原因是—— Gitlab 的同学对 PostgreSQL 不是很熟悉。

随后，Gitlab 在其网站上也开了一系列的 issues，其 issues 列表在这里 Write post-mortem （这个列表可能还会在不断更新中）

infrastructure#1094 – Update PS1 across all hosts to more clearly differentiate between hosts and environments
infrastructure#1095 – Prometheus monitoring for backups
infrastructure#1096 – Set PostgreSQL’s max_connections to a sane value
infrastructure#1097 – Investigate Point in time recovery & continuous archiving for PostgreSQL
infrastructure#1098 – Hourly LVM snapshots of the production databases
infrastructure#1099 – Azure disk snapshots of production databases
infrastructure#1100 – Move staging to the ARM environment
infrastructure#1101 – Recover production replica(s)
infrastructure#1102 – Automated testing of recovering PostgreSQL database backups
infrastructure#1103 – Improve PostgreSQL replication documentation/runbooks
infrastructure#1104 – Kick out SSH users inactive for N minutes
infrastructure#1105 – Investigate pgbarman for creating PostgreSQL backups

从上面的这个列表中，我们可以看到一些改进措施了。挺好的，不过我觉得还不是很够。

因为类似这样的事，我以前也干过（误删除过数据库，在多个终端窗口中迷失掉了自己所操作的机器……），而且我在 Amazon 里也见过一次，在阿里内至少见过四次以上（在阿里人肉运维的误操作的事故是我见过最多的），但是我无法在这里公开分享。

在这里，我只想从非技术和技术两个方面分享一下我的经验和认识。

一直以来，我都觉得直接到生产线上敲命令是一种非常不好的习惯。我认为，一个公司的运维能力的强弱和你上线上环境敲命令是有关的，你越是喜欢上线敲命令你的运维能力就越弱，越是通过自动化来处理问题，你的运维能力就越强。