骞云科技：假如GitLab使用CMP管理PostgreSQL

骞云科技：假如GitLab使用CMP管理***

事件概览

事件引发的思考

首先，我们可以了解到，在这一过程中，GitLab的系统管理员出现了以下失误：

1. 在错误的机器上执行删除操作， rm -rf，应该在备用Postgres所在的机器上进行删除操作

2. 在文件系统中直接删除数据库文件目录，应该是执行数据库的操作清空数据库

3. 备份缺乏验证的错误，GitLab部署的5套备份/复制方法中，没有一套在可靠运行或当初设置正确

假如Gitlab用了自动化的手段来管理他的数据库，而不是在生产线上敲键盘这样的人肉运维，结果又会如何呢?一个公司运维能力的强弱和线上环境敲命令是有关的，你越是喜欢上线敲命令你的运维能力就越弱，越是通过自动化来处理问题，你的运维能力就越强。真正良性的运维能力是——人管代码，代码管机器，而不是人管机器。

使用CMP来管理数据库

在传统的运维中，系统管理员一般会用终端窗口远程登录管理的机器，然后运行各种脚本进行运维操作，这种管理依赖于系统管理员本身去区分什么时候应该在哪台机器的应用上进行操作，当管理到多个机器，系统管理员需要在多个终端下切换。对于系统管理员，为了不出错，他要做到的事情很多，例如：

1. 必须时刻牢记哪台机器上部署了哪个应用，是生产环境的应用还是备份环境的

2. 必须清楚的知道，当前应用处于什么状态，能进行什么操作

3. 必须清楚的知道各个应用之间的关系，当要在一个应用上运行脚步时，对别的应用会造成的影响

在这个过程中，任何一步都不可以出错，单单依靠人力很难保证。

针对企业IT基础架构管理与运维中出现的问题，Gartner提出CMP(Cloud Management Platform，云管理平台)的解决方案，并指出了CMP的发展历程：

下面的图例给出了在SmartCMP中***的组件定义：

通过这一定义，即使是非专业的数据库管理员，也可以执行这些预定义的简单明了的操作。

在实际的生产环境中，部署在一台机器上的单一组件是不够的，例如***，一般需要提供复制(Replication)或者集群(Cluster)的功能，GitLab就使用到了***的复制功能，也随之产生了这次的运维问题。对应的，CMP中的蓝图对这些功能可以进行抽象的描述，同时，CMP的编排引擎会依据蓝图中的抽象进行部署和组件操作的执行。

以***复制功能为例，如下图所示，***被部署在了DatabaseServer这个虚拟机中，同时在ReplicationDatabaseServer虚拟机中部署了备用***，绿色的虚线标示出了它们之间的依赖关系。当***按照蓝图被实际部署后，各个组件遵从蓝图中预定义的关系，用户可以选中某一个组件，得到该组件可执行的操作列表，然后执行某一个操作。

试想一下，如果Gitlab的系统管理员在CMP中仍然犯错选择了对生产数据库进行清空或者重装操作，那么在他发现问题后可以立即从快照中恢复原有的数据。

显而易见，CMP模块化了运维管理，将具体的操作和组件进行了绑定，尽可能的降低了各个组件之间的耦合，简化了运维的难度。

随着自动化运维和开发运维一体化的快速普及，企业唯有借助以应用为核心的云管理平台，实现从部署到管理(包括监控、报警、备份、恢复等环节)的完整生命周期管理，才能真正地提高工作效率与操作的合规性，避免Gitlab类似事件的发生。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。