1月31日晚上，GitLab通过Twitter发文承认生产环境数据因为UNIX运维的误操作，已经被彻底删除，大致的事情经过是一名系统管理员在荷兰工作到深夜，在他发现GitLab的备用数据库db2无法写入后，为了能让数据库复制可以继续，疲惫不堪的他经过分析后决定清除db2.cluster.gitlab.com中的备用数据库db2，不幸的是他选错了数据库的服务器，他把生产服务器db1.cluster.gitlab.com中的db1数据库目录删除了，这是一个含有300GB活动生产数据的目录，其中大部分数据已丢失。GitLab随后在Blog中补充说明已挽回大部分数据，并在YouTube上开启直播，将恢复工作全部公开。
事件引发的思考此事一出，在整个IT界掀起了轩然大波，骞云科技(www.cloudchef.io)认为，在关心事态进展的同时，我们更应该思考出现这类问题的原因以及今后如何防范、处理。
首先，我们可以了解到，在这一过程中，GitLab的系统管理员出现了以下失误：
1. 在错误的机器上执行删除操作， rm -rf，应该在备用Postgres所在的机器上进行删除操作
2. 在文件系统中直接删除数据库文件目录，应该是执行数据库的操作清空数据库
3. 备份缺乏验证的错误，GitLab部署的5套备份/复制方法中，没有一套在可靠运行或当初设置正确
假如Gitlab用了自动化的手段来管理他的数据库，而不是在生产线上敲键盘这样的人肉运维，结果又会如何呢?一个公司运维能力的强弱和线上环境敲命令是有关的，你越是喜欢上线敲命令你的运维能力就越弱，越是通过自动化来处理问题，你的运维能力就越强。真正良性的运维能力是——人管代码，代码管机器，而不是人管机器。
使用CMP来管理数据库在传统的运维中，系统管理员一般会用终端窗口远程登录管理的机器，然后运行各种脚本进行运维操作，这种管理依赖于系统管理员本身去区分什么时候应该在哪台机器的应用上进行操作，当管理到多个机器，系统管理员需要在多个终端下切换。对于系统管理员，为了不出错，他要做到的事情很多，例如：
1. 必须时刻牢记哪台机器上部署了哪个应用，是生产环境的应用还是备份环境的
2. 必须清楚的知道，当前应用处于什么状态，能进行什么操作
3. 必须清楚的知道各个应用之间的关系，当要在一个应用上运行脚步时，对别的应用会造成的影响
在这个过程中，任何一步都不可以出错，单单依靠人力很难保证。
针对企业IT基础架构管理与运维中出现的问题，Gartner提出CMP(Cloud Management Platform，云管理平台)的解决方案，并指出了CMP的发展历程：
作为以应用为核心的第三代CMP的代表，骞云科技(www.cloudchef.io)在SmartCMP中引入了组件与蓝图的概念，组件是对一个可部署的应用的抽象与建模，组件有自己的生命周期，从创建、配置、启动、停止到销毁，在它生命周期的每个阶段，都可以有对应的操作(也就是可执行的脚本文件)和它绑定关联，这些操作都是预定义好的，在投入生产环境前就已经进行过验证。以定义PostgreSQL数据库组件为例，可以定义它在创建、配置、启动、更新参数、清空以及备份等阶段的操作。
下面的图例给出了在SmartCMP中PostgreSQL的组件定义：
通过这一定义，即使是非专业的数据库管理员，也可以执行这些预定义的简单明了的操作。
在实际的生产环境中，部署在一台机器上的单一组件是不够的，例如PostgreSQL，一般需要提供复制(Replication)或者集群(Cluster)的功能，GitLab就使用到了PostgreSQL的复制功能，也随之产生了这次的运维问题。对应的，CMP中的蓝图对这些功能可以进行抽象的描述，同时，CMP的编排引擎会依据蓝图中的抽象进行部署和组件操作的执行。
以PostgreSQL复制功能为例，如下图所示，PostgreSQL被部署在了DatabaseServer这个虚拟机中，同时在ReplicationDatabaseServer虚拟机中部署了备用PostgreSQL，绿色的虚线标示出了它们之间的依赖关系。当PostgreSQL按照蓝图被实际部署后，各个组件遵从蓝图中预定义的关系，用户可以选中某一个组件，得到该组件可执行的操作列表，然后执行某一个操作。
回到Gitlab运维中出现的问题，Gitlab的系统管理员在使用CMP后，如果发现db2.cluster.gitlab.com中的备用数据库db2无法写入，在蓝图中选择备用PostgreSQL，进行数据库清空操作，SmartCMP在进行这种破坏性的操作前，会自动先给db2所在的虚拟机db2.cluster.gitlab.com创建一个快照，然后再进行相应的操作。如出现Gitlab公开的描述中所说的清空后备份数据库db2仍然不能写入，我们可以在操作列表中选择删除db2后再安装，这样就会生成一个全新的备用数据库，当然，在删除和安装前，SmartCMP都会自动创建虚拟机快照以防止意外发生。
试想一下，如果Gitlab的系统管理员在CMP中仍然犯错选择了对生产数据库进行清空或者重装操作，那么在他发现问题后可以立即从快照中恢复原有的数据。
显而易见，CMP模块化了运维管理，将具体的操作和组件进行了绑定，尽可能的降低了各个组件之间的耦合，简化了运维的难度。
随着自动化运维和开发运维一体化的快速普及，企业唯有借助以应用为核心的云管理平台，实现从部署到管理(包括监控、报警、备份、恢复等环节)的完整生命周期管理，才能真正地提高工作效率与操作的合规性，避免Gitlab类似事件的发生。
本文作者：佚名
来源：51CTO
