什么是GPT-4？完整指南
首先我們來看一下數據庫和DevOps的關系，或者說它們是如何建立聯系的？
可以從如下這幾方面切入：
這些維度，包括怎么樣去做監控、怎么樣去保證我們的數據安全，在這些方面去考慮、去深入、去設計我們的數據庫有什么樣的工具，或者是有怎樣的平臺來支撐我們達到這方面的目的。
我們今天也會圍繞這些方面展開討論。
上圖為國外一家專業公司的調查結果，我們可以看出一些問題：
這是前四個原因。
我們如果說，大家認識到這些問題，我們也知道朝哪些方向去做，那么我們怎么樣能把數據庫集成到DevOps流水線上呢？我們會面臨哪些問題呢？這值得我們去研究。
怎樣同步應用數據庫的變化？怎樣能夠把應用和數據庫的發布，以及發布方式的不同拉平到一致？應用和發布的方式，以及所用到的工具都是不一樣的，我們怎么樣才能把它們集中起來？
這是我們可能遇到的挑戰。
假設我們要在一家公司做這些事情，我們可能會遇到哪些困難險阻呢？
首先，我們要打破目前的流程，比如說我們以前銀行發布數據庫的方式，首先需要開發提交腳本到代碼庫，再提交發布請求到工單系統，版本審批通過后，還需要運維去下載腳本或通過郵件接收腳本去手工通過客戶端或工具來執行發布，這是我們以前的方式。
現在全線上化方式后，我們怎么樣去適應變化呢？這樣一個演變，跟以前的方式是有區別的，我們怎樣保持一個平滑的過渡？這都是要考慮的一個問題。包括我們講到的缺乏開發和運維之間協調的一致，或者說一致性的認知，這些都是阻礙的因素。
那既然有這樣的目的、這樣的阻礙因素，那是誰說了算呢？怎樣在公司踐行你的數據庫DevOps理念呢？
這里面其實是需要公司技術管理層牽頭，至上而下一起去推動落實，才有可能實現。當然，我們的開發人員、DBA、架構師也要參與進來。
現在快速地進入到第二部分，就是面向開發，我們需要做到什么事情？
這一部分主要講解的是面向開發提供了涵蓋數據庫開發設計、代碼審核、部署測試、生產發布的一條龍生產流水線。
剛剛也提過過，以前的開發流程，就是開發人員要將應用程序打包，并按順序匯總、整理數據庫發布腳本，DBA拿到數據庫發布腳本后檢查、備份、執行，以完成數據庫發版；部署人員拿到應用部署包，備份、替換，已完成應用程序發版；引入DevOps后發布流程為開發人員將應用程序、DB代碼在CI工具中完成打包；部署人員拿到部署任務后，直接在發布系統中完成DB發版以及應用包部署。
這是簡化了發布的流程，而且全線上化。在有這套流程以前，我們的腳本是通過郵件，或者通過簽報，一些共享的平臺去完成腳本的傳遞的，那么有了這個流程之后，我們全部是在線上工具之間進行對接的。
這套流水線的設計思想是這樣的：首先會有一個建模工具，建模工具會生成我們的數據模型，生成數據模型后會轉化成數據庫的DDL、DML的語言，然后經過審核之后會上傳到代碼庫，然后發布平臺會讀取代碼庫的發布請求，然后發布請求會傳遞給我們執行發布的數據庫發布工具，我們給它起了個名字叫DBgo，那么它就會在測試環境執行發布任務，測試環境測試完成后會經過我們的集成測試平臺進行測試、驗證，然后會進行移交，到生產環境的發布環節，然后最終是發布到生產環境。
其實這個流水線流程是非常直觀明了的，思路也是比較簡單的。
數據建模工具（1）
那現在我們一個一個環節往下看。
我們的建模工具的目標是解決這些問題的，就是從建模開始講，缺少統一的工具支持、建模與數據標準脫節、數據模型無法共享，公司的數據標準無法落地，這都是我們目前這個建模工具所要解決的問題。
那么我們的目標實現了什么呢？就是我們通過這個東西實現了快速建模，比如邏輯模型、物理模型，可視化建模，可以快速地編輯我們的表、字段等等，并且可以跟你的數據標準落地。因為現在很多大型公司都流行數據治理，那你的數據標準庫、詞根庫拉通，可以實現數據標準智能發現以及數據標準引用，提升建模質量。還有一個是模型共享，也就是說很多標準化模型都是可以跨團隊、跨系統共享，一個大公司可能它的很多業務的模塊都有可能是可以復用的，那你的底層模型肯定是可以共享的，那只有我們存在這樣平臺，才可能達到這樣的目的。最后一個就是設計驅動開發，很多時候我們這個程序開發跟數據庫開發就比較的粗獷，就直接開蓋，沒有設計，直接就編寫程序編寫表，我需要什么樣的數據存儲，我就去建什么樣的表，就沒有在最開始的時候把整套模型給設計出來。因此，我們可以通過這個建模工具把我們的數據庫開發規范給落地。
數據建模工具（2）
下面大概闡釋跟建模工具相關的一些細節。
大概的過程是這樣的：新建模型、設計表、設計字段、設計索引、模型發布、生成DDL，大概是這幾個過程。這里面可能會有一些不一樣的場景，就不一一敘述了。在不同的場景下怎么樣去進行數據庫建模，步驟都是類似的，按照我們上圖右邊的“步驟列表”都可以做。
數據建模工具（3）
我們的建模工具支持數據庫的逆向，就是我已有的數據庫可以通過建模工具連過去，然后生成模型，把已有的數據庫模型生成出來，這叫逆向工程。跟大家演示一下（如下圖），這就是我們已有的數據庫，經過一系列的步驟，最后生成表的模型展示。
數據建模工具（4）
那模型除了可以逆向工程生成模型之外，也可以去導入。由于我們很多的傳統工程都是基于EXCEL去建模的，可以把EXCEL導入進來，這樣也可以生成我們的模型。（如下圖）
4.DB發布流程總覽
下面就進入到我們的發布階段。就是我們的模型建完之后，我們數據庫的腳本是怎么發布的？剛才我們提到，我們的腳本會傳到一個平臺上，這個平臺會調用我們的工具去做發布，那我們DBA所涉及到的工具就在這個環節起到作用了。我們會對腳本文件、SQL文件進行解析，就是語法、語義規范、性能、空間進行檢查，這里面可能會分為兩部分，就是叫做靜態檢查和動態檢查。
所謂的靜態檢查，指的是比如說你的DDL寫得合不合規范，比如說你的create table有沒有帶comments、有沒有加主鍵索引，再比如oracle新建索引有沒有按照規范設置initrans大小等，工具先解析出DDL/DML的語法，然后根據預定義的規則做出是否符合規范的檢查判斷，這就是靜態檢查。
而動態檢查就是，工具會連到數據庫里面去檢查：例如你將要創建的對象跟已有的對象命名是否沖突，如果已經存在，我就沒必要在執行的時候再告訴你，這叫動態檢查。如果通過的話就會進入到測試環節至應用環節，如果執行通過的話就會進入到生產執行環節，如果不通過的話就會將本次提交的腳本打回去。
數據庫發布工具DBgo（1）
上圖是我們數據庫發布的背景說明，就是為什么有這樣一個東西，就是去規避人工執行的錯誤；然后環境混亂就是，我們可能有多套測試環境，可能會連錯，甚至生產環境也會連錯這種情況；如果版本發錯回退的話，沒有工具支持的話時間也會很長；有了這個工具后我們可以把整個發布過程記錄下來，事后去追溯或者達到一個審計的目的都可以做得到。
數據庫發布工具DBgo（2）
數據庫發布工具DBgo（3）
我們的發布工具從剛開始設計的時候是從易到難的，因為剛開始想做一個大而全的東西是比較困難的，比如說我們剛開始是只發DDL不發DML，當然我們現在是做到了可以發DML。有一些同學可能會覺得我們比如說發布完一個代碼后，比如一個對象，失敗后是否可以自動回滾。那我們目前也是這樣，比如我可以做備份，但是我們不做自動回滾的，可以幫你生產回本語句，但我不會幫你做執行，這些都是為了控制這個工具的風險。然后還有一個原則是只做新增，不做刪改。比如說我制作增加字段，我不做drop字段，類似這樣的理念，也是為了規避一些風險。所以我們分了幾期，逐漸達到這樣的目的。
數據庫發布工具DBgo（4）
在文件命名里面，我們對于整個發布腳本文件的命名有一些約定，比如說有序號、有發布的用戶屬主，有發布的類型，比如你是做什么，有執行人的賬號，通過這種格式化的配置文件名，我可以得到很多有用的信息。比如說我可以根據序號去編排發布的順序，比如哪個先執行哪個后執行，就是根據序號來的。
熟悉oracle的小伙伴都知道，我還要指定每個腳本執行的用戶schema（模式）從哪里來，就是從這里來。另外，通過這個腳本的開發人員名稱知道是誰提交的，我們還可以做到精準的審計。
DDL/DML我們盡量不要放在一個文件里，因為我們發布的原子的粒度，我們定義為一個SQL文件，這個SQL文件你可以寫多條語句，但是我們的最佳實踐是把DDL/DM分開，因為我們是一個SQL作為一個事務。比如說對于我的發布工具來講，你的這個SQL文件里的語句要么全部執行成功，要么全部執行失敗，這樣一個設計理念，才能保證你的發布過程每一個步驟都是自包含的，不會產生一些關聯的影響。
事務提交。我們這里也講到，你的SQL文件里面不能發commit,是我們的工具幫你做commit。
這就是一些細節設計中我們自己考慮的一些點。
數據庫發布工具DBgo（5）
我們這個工具其實它的原理也比較簡單。我們是用了開源的組件。首先解析SQL類型，然后把SQL拆分出來，拆分成不同的小的模塊，然后組成利于理解的開發程序JSON串，然后根據我們剛才講的靜態規則去做一些檢查，然后把檢查的結果反饋出來。動態檢查其實也一樣，就是連到數據庫里面，根據你查到的信息，把數據庫里面的信息跟你解析出來的信息和JSON串做一個解析和對比，然后返回檢查結果。其實原理很簡單，我相信大家去設計這樣的一個發布工具，應該也是同樣的思想。
數據庫發布工具DBgo（6）
這是一個過程，大家看看就可以了。就是說真正執行的時候，做一個pre_check看看是否需要備份，然后按照順序去執行，執行完之后要么成功、要么失敗、要么回滾，然后最后做一個check，就是去確定你的這個語句是否執行成功了。
數據庫發布工具DBgo（7）
上圖就是我們的規則的展示，供大家參考。比如說我的靜態規則，剛才講到比如說我會判斷你這個表的字段字數是否會超過50個字段，如果超過50個字段，我們就認為這是個寬表，我們會有提示。當然，這些規則有些是強制的，有些是建議的，會做一定的區分。
SQL代碼審核流程
剛才講的是DDL/DLM的發布，那我們在程序里面SQL代碼要怎么審核呢，我們也有一個審核流程。以上是我們整個的審核流程。就是說我們在開發階段的代碼會提交到我們叫做SQM的平臺，在SQL質量管理系統里面去進行審核優化，如果審核通過就會進入到審核記錄，然后去進行測試和生產發布；如果審核不通過，就會返回到開發處理，開發處理的時候會做一個判斷和分析，那我只要修改為SQM建議的這種寫法，或者是它覺得它的寫法就是最優的，它就可以提交DBA審批，當然這是線上的。
這里面在生產環境和測試環境分別有一個控制點，控制什么呢，我會在測試環境和生產環境去掃描有問題的語句，然后跟審核記錄做比對，比如說我真的在數據庫里面抓到了有問題的語句，但是你又沒有審核記錄，那么我們就會變成違規記錄。意思是你的程序沒有經過審核就提交發布了，然后又產生了問題。
所以這個流程看似簡單，實際上它穿插了很多東西，而且它涉及到的人員和角色也比較多，而且我們底層依賴的系統也比較多，比如說你首先得有一個開發過程管理系統，它才能把我們的審核違規單和開發的缺陷版本關聯起來，那我們生產上也必須要有一個監控系統，它才能去發現這些問題，而且這個監控的語句能夠跟我們這個SQM系統審核的語句建立關聯，它才能做成這樣的一個閉環。相當于說我們通過這個平臺，對我們的SQL代碼質量從開發、測試到生產完成一個閉環。
SQL審核規則舉例
這是我們的一個審核規則，比如說就是一些常見的SQL語句上可能會存在的一些問題。
SQL審核工具：支持多種格式的SQL導入
這是一個大致的界面演示，就是你可以把自己要審核的語句，包括.SQL文件格式、excel文件格式，甚至可以直接把MyBatis和xml格式直接導進去，也就是說它可以支持多種格式文件的導入。
SQL審核工具：隱患SQL監控
導入之后會有一些報告反饋給你，包括你執行這個計劃，缺少VR條件等等一些內容，然后你就可以看到導出SQL的詳情報告。
剛才是我們第二章節，是我們面向開發，無論是數據建模、版本發布，包括SQL審核等一系列的面向開發，或是面向應用程序等跟數據庫相關的涉及到上線的一個流程達到的工具。銀行也不是全部東西都自己做，有些模塊是外購的，像我們的建模工具、還有SQM審核工具，也都是我們外購的。但我認為這個是合理的。因為銀行不是靠IT去盈利的，IT在銀行的使命是維持系統的穩定，我們把專業公司在做的東西拿過來，比如建模工具、SQM質量審核工具拿過來之后，融入到我們現有的開發測試管理流程里面，而且能夠跟我們現有的系統做一個對接，完成整個流程的閉環，我認為這就是我們在銀行做數據庫管理所帶來的價值，不是所有的東西都要自己開發建設，這是我個人的理解。
下面我們進入到面向運維，在這一方面，我們打造融合不同DB類型的一站式數據庫自動化運維平臺。
上圖是我們DB整個自動化運維的生態圈，可以看到我們有監控報警、配置信息管理、容量管理、數據庫自動化交付、發布工具、日常運維工具、數據庫查詢發布工具、數據庫切換工具等等，組成了我們DBA自動化運維生態圈，下面我們可以再簡單了解一下。
上圖是我們圍繞數據庫系統打造的一個自動化系統的概覽圖，圍繞我們的數據庫的配置信息，匯總到我們整個系統中心的CMDB里面，我們的數據庫相當于我們被管理的目標，在這個目標上我們會做一些數據采集，我們的數據采集一共有兩種，一種是基于數據開源的Prometheus，它負責的是我們所有OS層面的指標采集，以及我們開源數據庫的指標采集。我們自己研發的這個產品叫做EasyDB/xall它主要面向的是Oracle，面向Oracle數據庫各種指標的采集和展示。采集了數據之后，我們就會有一個監控告警的系統，基于我們采集到的數據，經過我們的程序的判斷，我們有各種告警的指標，然后每個指標有不同的閥值，不同的閥值有不同的報警級別，我們大概分了三個告警級別：
幾個不同的級別，不同的告警級別告警發送的方式也不太一樣，有的會發郵件，比較重要的會發短信；然后我們內部也有這種即時通訊的手機端的系統，叫作快樂平安，就像我們微信一樣，更加關鍵的會自動外呼電話，外呼發到給我們的值班人員，這是告警。
有了告警之后，我們就要去分析定位了，助力我們分析定位的有，基于Grafana去把我們所有數據庫的指標，比如你的TPS、QPS、會話數、等待事件、鎖堵塞信息等等這些指標都展示出來，然后把OS層面的CPO、memory、IO、網卡流量等等這些指標都展示出來，這樣你就能迅速定位出來你的問題瓶頸在哪里，是不是有一些熱塊競爭、有一些慢查詢，是不是有一些業務量的并發、高并發突然涌入進來，或者是主機CPU隊列等待，存儲度有沒有慢，都會通過我們的這個可視化提供的監控信息能夠實時的定位分析。
定位分析之后要去處理解決，比如我們常見的幾板斧，比如你要重啟數據庫、切換數據庫、殺會話、去優化綁定執行計劃等等，就需要一個運維工具，通過工具定位處理解決，實現了一些剛剛講的那些常規動作。這種思路看似簡單，其實是把我們運維經常要做的幾件事情串起來了。基于這個我們還做了AIops的一些探索，后面簡單介紹一下。
1.配置信息、監控報警
如上就是我們DBA的監控大屏，大家可以看得到，我們的DBA類型，基本上我們常見的數據庫類型這里都包含了，大概有十種，像Oracle、MySQL、MongoDB、Redis、PG、DB2、Sqlserver等都涵蓋，然后大屏上的每一行DB都是一個實例，這些實例我們都會監控它的狀態，我們有幾個關鍵的指標燈，比如說數據庫是否連通，主從是否同步，數據庫的連接數是否超過最大連接數、有沒有產生數據庫的擁堵、數據使用率等等。
這個就是我們一個集中的、而且可以cover所有數據庫類型的監控告警平臺。那我們的DBA平時只需要看這個監控就可以了，我們的值班人員只要有亮紅燈的就通知處理，沒有被處理掉的話這個燈就會一直亮著。
除了這個監控告警之外，我們也做了一些巡檢，因為大家知道監控告警是一條一條的，當這條過去之后有些會遺漏，比如你的短信報警、郵件報警，如果你沒看到的話就會錯過，那我們就做了第二層的監控，叫巡檢，各種指標的巡檢報表，比如表空間使用率、FRA使用率、ASM使用率、CPU使用率、費用分析表等等。這個巡檢就是我們的第二層防線，就是我們根據指標、根據實例、根據每個指標的監控告警之外我還有一個巡檢和預測，做第二套保障，確保不會有潛在問題或風險被遺漏，影響生產。
這里展示了我們基于這個平臺去處理一次生產實際問題的過程。發現有一個數據庫CPU告警了，我們通過點擊這個數據庫的IP右鍵，這里有幾個菜單，OS可視化、DB可視化、TOPSQL可視化。
這里就是OS可視化，然后這里我們發現這個數據庫的CPU使用率確實很高。
然后這里是DB可視化，我們可以看到常見的幾個DB指標趨勢圖，比如同一CPU沖高的時間點，這里的會話數也會有一個突增，或者我的數據庫的等待事件里也會有一個突增等。
返回到大屏上，我們通過點擊大屏上的某個紅燈，比如數據庫堵塞這個燈，我們就會進入到這個詳情頁面上：
這個頁面就會展現出來當前哪些SQL在堵塞（wait）。例如這個enq:TX contention就是Oracle的行鎖。
也就是說首先我們被通知到了有報警，然后通過查詢分析資源和DB的相關監控圖表，我們就定位到了問題出在哪里。我們知道這個是行鎖，那么下一步的做法就是要殺掉這個行鎖，也就是要處理報警了。那我這個環節也不需要人工登錄到數據庫里面，我可以知道這條語句的執行計劃，通過點擊這個SQL ID可以知道這個語句的執行計劃。
我們可以知道這個語句過往按照時間排序的一個執行的次數，一個執行時間的變化等等。
我們進入到數據庫里面去殺會話，以前先要登錄數據庫。在銀行登錄數據庫還要經過幾道堡壘機，這個過程很漫長，那么現在就不用做這個工作，可以直接通過監控平臺的鏈接直接跳轉到一個運維操作工具上，我們可以看得到這個SQL ID有兩個執行計劃，一個plan value 是311，另一個plan value是163，這兩個執行計劃我們可以看得到，一個走的是日期的索引，一個指的是number的索引。當然啦，它還有一些輔助的性能指標判斷，就是那個執行時間、buffergets等，這里沒有貼出來。這兩個執行計劃有一個是最優的，那我們可能要綁定這個執行計劃，我們可以用工具一鍵直接生成oracle的profile，迅速地去綁定。當然也有可能不是執行計劃的問題，就是短時間的并發會話擁堵產生的問題，我可能要臨時去殺一些會話，那我們也可以提供批量去殺會話的功能。
這個oracle、MySQL都支持。
2.自動化運維
這個就是剛剛講的運維工具的展示。用戶管理、批量授權、會話處理、參數調整、表空間擴容等，oracle、MySQL、MongoDB都支持。
這是我們的主從切換工具，就是我們可以在這上面去執行我們數據庫的批量切換、主動切換，因為會有些場景用到這樣的工具。大家可能會問，我們的數據庫切換不應該自動的嗎？比如Oracle RAC、MySQL MHA都是自動切換的，為什么還需要這種切換工具呢？那如果你想要批量切換的時候就需要了，舉兩個場景，比如你一個物理機上面好多個實例，物理機要做主動維護；或者你是要多做容災切換，同城容災、遠程容災、異地切換，你可能一切切幾十個、上百個，你可能就需要工具。我們現在已經做到Oracle、MySQL可以在這個平臺上批量切換。
3.自愈-AIops
那就再進入到AIOps，當然我們的DBA他并不希望每天都在處理報警，那我們能不能探索出一條道路就是，如果出現一些簡單的問題，我們運用一些人工智能的運維思想去自動地解決這些問題，這是我們的背景。這個就是主要的過程，是我們在AIOps在數據庫上面一些簡單的探索。如果大家學過一些AI的算法的話，比如說傅里葉、決策樹、KNN、近鄰算法這些，有了基本算法的基礎理論后，實現AIops的方法論其實是一樣的（起碼在常規的系統運維場景），就是首先你要形成你的知識庫，就是你要把你的場景提煉出來，然后形成這種常見的決策表，然后根據決策表來建立模型并提供樣本讓機器學習，不斷訓練，去優化你的模型，然后根據你的決策樹生成你的解決方案，再對告警對象進行干預，實現告警消除。大概是這樣一個過程。
這個是我們以空間為例所探討的一個AIOps的場景，就是這個歸檔區報警了，這個是FRA區，然后是Oracle的，我們的場景有幾個，我們的判斷條件有幾個，比如說報警了，這個使用率是在什么水位，是否還有磁盤空間，日志有沒有備份等等。
舉個例子，比如說當前已經報警了，然后還有剩余空間，備份沒有成功，那我們的策略是什么？就是加大FRA區。換句話說，就是FRA區報警了，磁盤還有空間，你的歸檔日志還沒有完成備份，沒有備份就不能清理，那你的策略就是加大FRA區。
那還有一個就是，報警了沒有剩余空間，但是我備份成功了，而且我監控到有大量的數據更新，那我的策略就變了，變成了調一次歸檔日志的備份，備份后的日志直接清理掉，這就是我另外的一種策略，其實策略就是一樣。假如你是一個DBA ，面對這樣的問題，你需要判斷哪些因素，判斷完之后你的動作是什么，這些東西需要整理起來。
這個東西就是決策樹的一種算法，有了這種算法之后，你去把它寫成程序，然后調用接口去把它執行就完事了。
、
這個就是我們自愈的簡單的統計，而觸發量，就是觸發了多少次，觸發自愈的一個統計。它確實在我們的生產線上已經上線了，減少了很多DBA在這個環節上的一個工作。
4.一站式查詢DB
最后就是一站式查詢的DB。就是有十幾個數據庫，數千名開發人員，他們也有訪問DB的請求，但是我們銀行的訪問是非常受控的，他們有一個物理的房間，要進去，然后再登Teminal、再授權、再去查，但很多時候這個效率是比較低的，而且操作間空間比較有限，所以在這個背景上，我們提供了一個基于外部頁面的查詢的一個工具。
這個就是我剛剛講的一些問題。就是這個流程非常繁瑣，開發人員想要去直接去查數據庫里面的東西，因為涉及到一些敏感性意義，涉及到一些安全的審計，要有好多個步驟，大家可以看到藍色的步驟大概有七八個，這樣我們才能得到他需要的數據。
我們的需求非常簡單，就是我可能簡單地去查，又能夠在安全可控的基礎上。
現在我們已經可以做到這種白色底色的數據庫的查詢。
這個步驟很簡單，第一步選擇數據庫，閱讀說明、執行語句，然后查看查詢結果，這里面還可以查看它的表結構，索引信息。這里的功能雖然做起來簡單，但是我們其實做了一些事情。
首先我們會在背后解析你跑的SQL語句，如果發現你不符合我們的要求，或者你有一些查詢隱患，比如說你沒有輸入VR條件，我們都會提醒你甚至拒絕執行。
還有一個就是剛剛講的性能上的，還有就是第二點安全上面，我們這套系統會對接安全平臺，某些數據庫、某些表、某些字段含有敏感信息，那么我們的程序會自動把這些敏感信息過濾掉。
第三，哪些人、什么時間、查了什么表，我們后臺都有審計。這個審計會對接到安全平臺，就是說它會對員工的行為做控制等等。實際上，我們也通過這個達到了我們對數據庫的一些規范或者運維安全的一些目的。
這個是我們的調用量。這個我們目前這個開發運維使用最多的一個工具，每天可以大概看得到有一萬三千次的訪問。
最后就是我們的一個宣言：就是運維不做背鍋俠。
所有的這些你光靠口頭是不能實現的，我們的宗旨就是能夠做到工具自動化的就絕不讓它手動去做。工具要有防災機制，我們曾經有一些工具設計得不夠完美，當然這個是需要一點點去迭代完善的。可能也會產生一些問題，甚至產生一些生產事件，所以我們的工具一定要有防災。比如說，你的工具要去重啟，要去重啟一個數據庫實例的時候，你是不是首先要看這個數據庫是不是有連接。你不能不管三七二十一就上去重啟了，一定要看這個數據庫有沒有連接，有沒有活動連接。如果有活動連接，說明這個數據庫還在提供服務，就不能隨便重啟，這又是簡單的防災機制。
開發其實是運維的友軍。
踐行DevOps不是一句口號，我們運維需要更多、更密切地跟開發并肩戰斗，才能夠達到這個目標。像前面講到的數據庫的建模、開發、設計、發布的一套平臺，我們是跟開發團隊架構團隊密切合作才能做出來這樣的東西。
本文章轉載微信公眾號@dbaplus社群
