• 事件概覽

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類似事件的發生。

更多精彩內容歡迎關注騫云科技微信公眾號：