• 事件概覽

1月31日晚上，GitLab通過(guò)Twitter發(fā)文承認(rèn)生產(chǎn)環(huán)境數(shù)據(jù)因?yàn)閁NIX運(yùn)維的誤操作，已經(jīng)被徹底刪除，大致的事情經(jīng)過(guò)是一名系統(tǒng)管理員在荷蘭工作到深夜，在他發(fā)現(xiàn)GitLab的備用數(shù)據(jù)庫(kù)db2無(wú)法寫(xiě)入后，為了能讓數(shù)據(jù)庫(kù)復(fù)制可以繼續(xù)，疲憊不堪的他經(jīng)過(guò)分析后決定清除db2.cluster.gitlab.com中的備用數(shù)據(jù)庫(kù)db2，不幸的是他選錯(cuò)了數(shù)據(jù)庫(kù)的服務(wù)器，他把生產(chǎn)服務(wù)器db1.cluster.gitlab.com中的db1數(shù)據(jù)庫(kù)目錄刪除了，這是一個(gè)含有300GB活動(dòng)生產(chǎn)數(shù)據(jù)的目錄，其中大部分?jǐn)?shù)據(jù)已丟失。GitLab隨后在Blog中補(bǔ)充說(shuō)明已挽回大部分?jǐn)?shù)據(jù)，并在YouTube上開(kāi)啟直播，將恢復(fù)工作全部公開(kāi)。

• 事件引發(fā)的思考

此事一出，在整個(gè)IT界掀起了軒然大波，騫云科技(www.cloudchef.io)認(rèn)為，在關(guān)心事態(tài)進(jìn)展的同時(shí)，我們更應(yīng)該思考出現(xiàn)這類問(wèn)題的原因以及今后如何防范、處理。

首先，我們可以了解到，在這一過(guò)程中，GitLab的系統(tǒng)管理員出現(xiàn)了以下失誤：

1. 在錯(cuò)誤的機(jī)器上執(zhí)行刪除操作， rm -rf，應(yīng)該在備用Postgres所在的機(jī)器上進(jìn)行刪除操作

2. 在文件系統(tǒng)中直接刪除數(shù)據(jù)庫(kù)文件目錄，應(yīng)該是執(zhí)行數(shù)據(jù)庫(kù)的操作清空數(shù)據(jù)庫(kù)

3. 備份缺乏驗(yàn)證的錯(cuò)誤，GitLab部署的5套備份/復(fù)制方法中，沒(méi)有一套在可靠運(yùn)行或當(dāng)初設(shè)置正確

假如Gitlab用了自動(dòng)化的手段來(lái)管理他的數(shù)據(jù)庫(kù)，而不是在生產(chǎn)線上敲鍵盤(pán)這樣的人肉運(yùn)維，結(jié)果又會(huì)如何呢?一個(gè)公司運(yùn)維能力的強(qiáng)弱和線上環(huán)境敲命令是有關(guān)的，你越是喜歡上線敲命令你的運(yùn)維能力就越弱，越是通過(guò)自動(dòng)化來(lái)處理問(wèn)題，你的運(yùn)維能力就越強(qiáng)。真正良性的運(yùn)維能力是——人管代碼，代碼管機(jī)器，而不是人管機(jī)器。

• 使用CMP來(lái)管理數(shù)據(jù)庫(kù)

在傳統(tǒng)的運(yùn)維中，系統(tǒng)管理員一般會(huì)用終端窗口遠(yuǎn)程登錄管理的機(jī)器，然后運(yùn)行各種腳本進(jìn)行運(yùn)維操作，這種管理依賴于系統(tǒng)管理員本身去區(qū)分什么時(shí)候應(yīng)該在哪臺(tái)機(jī)器的應(yīng)用上進(jìn)行操作，當(dāng)管理到多個(gè)機(jī)器，系統(tǒng)管理員需要在多個(gè)終端下切換。對(duì)于系統(tǒng)管理員，為了不出錯(cuò)，他要做到的事情很多，例如：

1. 必須時(shí)刻牢記哪臺(tái)機(jī)器上部署了哪個(gè)應(yīng)用，是生產(chǎn)環(huán)境的應(yīng)用還是備份環(huán)境的

2. 必須清楚的知道，當(dāng)前應(yīng)用處于什么狀態(tài)，能進(jìn)行什么操作

3. 必須清楚的知道各個(gè)應(yīng)用之間的關(guān)系，當(dāng)要在一個(gè)應(yīng)用上運(yùn)行腳步時(shí)，對(duì)別的應(yīng)用會(huì)造成的影響

在這個(gè)過(guò)程中，任何一步都不可以出錯(cuò)，單單依靠人力很難保證。

針對(duì)企業(yè)IT基礎(chǔ)架構(gòu)管理與運(yùn)維中出現(xiàn)的問(wèn)題，Gartner提出CMP(Cloud Management Platform，云管理平臺(tái))的解決方案，并指出了CMP的發(fā)展歷程：

作為以應(yīng)用為核心的第三代CMP的代表，騫云科技(www.cloudchef.io)在SmartCMP中引入了組件與藍(lán)圖的概念，組件是對(duì)一個(gè)可部署的應(yīng)用的抽象與建模，組件有自己的生命周期，從創(chuàng)建、配置、啟動(dòng)、停止到銷毀，在它生命周期的每個(gè)階段，都可以有對(duì)應(yīng)的操作(也就是可執(zhí)行的腳本文件)和它綁定關(guān)聯(lián)，這些操作都是預(yù)定義好的，在投入生產(chǎn)環(huán)境前就已經(jīng)進(jìn)行過(guò)驗(yàn)證。以定義PostgreSQL數(shù)據(jù)庫(kù)組件為例，可以定義它在創(chuàng)建、配置、啟動(dòng)、更新參數(shù)、清空以及備份等階段的操作。

下面的圖例給出了在SmartCMP中PostgreSQL的組件定義：

通過(guò)這一定義，即使是非專業(yè)的數(shù)據(jù)庫(kù)管理員，也可以執(zhí)行這些預(yù)定義的簡(jiǎn)單明了的操作。

在實(shí)際的生產(chǎn)環(huán)境中，部署在一臺(tái)機(jī)器上的單一組件是不夠的，例如PostgreSQL，一般需要提供復(fù)制(Replication)或者集群(Cluster)的功能，GitLab就使用到了PostgreSQL的復(fù)制功能，也隨之產(chǎn)生了這次的運(yùn)維問(wèn)題。對(duì)應(yīng)的，CMP中的藍(lán)圖對(duì)這些功能可以進(jìn)行抽象的描述，同時(shí)，CMP的編排引擎會(huì)依據(jù)藍(lán)圖中的抽象進(jìn)行部署和組件操作的執(zhí)行。

以PostgreSQL復(fù)制功能為例，如下圖所示，PostgreSQL被部署在了DatabaseServer這個(gè)虛擬機(jī)中，同時(shí)在ReplicationDatabaseServer虛擬機(jī)中部署了備用PostgreSQL，綠色的虛線標(biāo)示出了它們之間的依賴關(guān)系。當(dāng)PostgreSQL按照藍(lán)圖被實(shí)際部署后，各個(gè)組件遵從藍(lán)圖中預(yù)定義的關(guān)系，用戶可以選中某一個(gè)組件，得到該組件可執(zhí)行的操作列表，然后執(zhí)行某一個(gè)操作。

回到Gitlab運(yùn)維中出現(xiàn)的問(wèn)題，Gitlab的系統(tǒng)管理員在使用CMP后，如果發(fā)現(xiàn)db2.cluster.gitlab.com中的備用數(shù)據(jù)庫(kù)db2無(wú)法寫(xiě)入，在藍(lán)圖中選擇備用PostgreSQL，進(jìn)行數(shù)據(jù)庫(kù)清空操作，SmartCMP在進(jìn)行這種破壞性的操作前，會(huì)自動(dòng)先給db2所在的虛擬機(jī)db2.cluster.gitlab.com創(chuàng)建一個(gè)快照，然后再進(jìn)行相應(yīng)的操作。如出現(xiàn)Gitlab公開(kāi)的描述中所說(shuō)的清空后備份數(shù)據(jù)庫(kù)db2仍然不能寫(xiě)入，我們可以在操作列表中選擇刪除db2后再安裝，這樣就會(huì)生成一個(gè)全新的備用數(shù)據(jù)庫(kù)，當(dāng)然，在刪除和安裝前，SmartCMP都會(huì)自動(dòng)創(chuàng)建虛擬機(jī)快照以防止意外發(fā)生。

試想一下，如果Gitlab的系統(tǒng)管理員在CMP中仍然犯錯(cuò)選擇了對(duì)生產(chǎn)數(shù)據(jù)庫(kù)進(jìn)行清空或者重裝操作，那么在他發(fā)現(xiàn)問(wèn)題后可以立即從快照中恢復(fù)原有的數(shù)據(jù)。

顯而易見(jiàn)，CMP模塊化了運(yùn)維管理，將具體的操作和組件進(jìn)行了綁定，盡可能的降低了各個(gè)組件之間的耦合，簡(jiǎn)化了運(yùn)維的難度。

隨著自動(dòng)化運(yùn)維和開(kāi)發(fā)運(yùn)維一體化的快速普及，企業(yè)唯有借助以應(yīng)用為核心的云管理平臺(tái)，實(shí)現(xiàn)從部署到管理(包括監(jiān)控、報(bào)警、備份、恢復(fù)等環(huán)節(jié))的完整生命周期管理，才能真正地提高工作效率與操作的合規(guī)性，避免Gitlab類似事件的發(fā)生。

更多精彩內(nèi)容歡迎關(guān)注騫云科技微信公眾號(hào)：