摘要：本文主要分享如何構建反脆弱性的雲數據庫服務體系與實踐，實現分佈式雲數據庫服務的高可用方案，同時採取措施保護分佈式雲數據庫整體服務，實現跨機房分佈式自動切換方案，並在實踐過程中，實施分享 SQL 自動發佈，實現0誤操作，有效保障雲數據庫服務的同時，提高了 DBA 及研發人員的效率，並完成有效數據庫評價，實現完整的反脆弱數據庫服務保障體系。
作者：成思敏
成思敏， 21CN 數據庫架構師/技術專家/DBA 主管，長期從事數據庫工作，任公司 DBA 主管，數據庫架構師，技術專家等。擅長數據庫整體架構的構建，數據庫自動化運維設計，早期介入數據庫服務研究，長期從事在雲計算下的數據庫運行情況難題解決，並長期公司內部 DBA 團隊建設培養，對內數據庫規範培訓。
本文根據成思敏老師在DTCC數據庫大會分享內容整理而成，主要分享構建反脆弱性的雲數據庫服務體系與實踐，實現分佈式雲數據庫服務的高可用方案，同時採取措施保護分佈式雲數據庫整體服務，實現跨機房分佈式自動切換方案，並在實踐過程中，實施分享 SQL 自動發佈，實現0誤操作，有效保障雲數據庫服務的同時，提高了 DBA 及研發人員的效率，並完成有效數據庫評價，實現完整的反脆弱數據庫服務保障體系。
一、雲數據庫服務情況簡介
各位朋友大家下午好，我是來自21CN 的成思敏，也是一名專業崗，這幾年在雲數據庫上面我成長得比較快，我們公司的業務發展也是很快。我所帶來的分享主題是雲數據庫反脆弱運維體系，跟大家分享一下六年來在雲數據庫方面遭遇的挫折和總結的經驗。
那雲數據庫的脆弱性是什麼？我們如何去反脆弱？如何建設強大的數據庫服務體系？
這就是我們今天需要討論的話題。脆弱性在《六西格瑪》這本書上指的是質量問題，質量問題其實牽涉到有十幾種，比如說故障、性能、數據的恢復、數據的備份以及同步、性能調優等。即使是數據庫沒有故障也很穩定的時候，但是cpu基本是在10%以下，那麼也是長期低負載的情況下，它也屬於質量問題，因為它浪費了公司資源；這些都屬於脆弱性的範疇。
當大家解決一些問題的時候，一般是很有成就感的。不知道大家是如何去判斷一個問題的，希望大家在解決問題的時候深挖最根本的原因，因為解決的問題往往是表面問題，比如說殺一個會話，調一調SQL，去優化。我們往往只是觸摸到問題的冰山一角。
1、雲計算與雲數據庫服務情況
現在已經是雲時代了，在2009年的時候我是被亞馬遜的雲計算震驚了，從那個時候我就一直在想如何去建設。對於DB來說，他們說一個DBA可以去維護3000臺數據庫實例的時候，我們該怎麼去做這個事情，怎麼去實現？
雲計算的基礎是整個資源池，能夠提供智能的決策，以前是幫決策者去做決策，但是雲計算能夠提供智能的決策，所以它現在越來越成為企業先進性的標誌。因為雲數據庫是雲計算的核心應用，所以每一個DBA、每一個數據庫工作者包括研發不得不去重視雲數據庫。
到2018年為止，我國的企業上雲率是30.8%，美國企業上雲率是80%。但並不是所有的企業都能夠上雲，包括美國。比如說化工類的配方、財務的核心數據甚至一些國家的軍事機密，這些是不應該上雲的，即使是私有云。走向網絡化的時代，企業一定有自己的命根子，他要保住這些東西。我國企業上雲率為什麼和美國相差這麼多？我個人認為，一個是因為我們的雲計算起步稍微有些晚，另外就是IT行業的人工成本還是稍微低了一點。美國的人工成本是非常高的，可能對專業崗來說沒有上限，在這樣的情況下，美國的上雲成本要稍微低一點，所以美國的上雲率比較高。
2、雲數據庫與傳統數據庫
那對於雲數據庫和傳統數據庫來說，主要是雲數據庫和傳統數據庫來說，因為它放在雲計算上面，所以它的安全性得到了很大的保障。像MySQL的單實例性能是非常弱的，我們也是經歷了六年才發現各種各樣的問題，它比我們想的還要弱。SQL性能拿數據量來說，因為數據性能隨著數據量增多而衰減，所以數據量不能過大。另外，在遷移方面，雲數據庫可以實現秒級的切換，對於傳統的數據庫比如Oracle來說，可能至少需要幾分鐘左右。雲數據庫可以解決IO的問題，通過分佈式事務並可以實現高可用分佈式的架構，能夠解決存儲的問題。 它還可以實現高可用連續性。在服務方面，它可以建立分佈式架構，也可以實現高可用和讀寫分離等多種連續性解決方案。
對Oracle來說，我們就用各種手段去做數據庫調優和保障數據庫性能，但是對於雲數據庫來說，它一個弱不禁風的MySQL雲數據庫，如何去保障整個應用？拿實例來說，有可能1個Oracle實例能夠頂200個MySQL的實例，那你如何去維護200個實例，我們就需要具備掌握綜合使用工具的能力。在六年中,雖然有挫折的地方，但我們確實利用雲計算的智能和全棧的技術能力，極大地提高了數據庫的運維效率，並且我們根據業務需求，即使是一個小小的MySQL，也支撐了非常高的300億行數據規模的數據庫。
3、雲數據庫服務運維體系存在問題特徵
那雲數據庫的問題在哪裡？這是經過六年來我們的總結，問題SQL很多，有時候一個insert語句當時也沒有發生高併發高性能的問題，但它就是一個慢查詢，慢查詢有可能是20分鐘，也有可能是7秒，這個問題是非常的嚴重。還有一個就是SQL不穩定，因為MySQL一個列上面可以建好幾個索引，和Oracle不同。在這種情況下，執行計劃會走偏。
另外一個是監控不準，因為虛擬機等都OK的情況下產品發生了問題，然後客戶就找我們的麻煩，這是很常見的，已經幾乎每天都會發生。然後就是雲數據庫的服務劇增。因為我們要支撐高併發，所以我們就用中間件，不管是分表分庫還是讀寫分離，都會存在不可知的問題。另外就是架構過高，那經過我性能壓測，我們一箇中間件代表一個MySQL的時候，它性能衰減有可能達到60%。
另外就是雲計算的資源池過於集中，有時候我們把各種服務放在一起，數據庫會莫名其妙地發生奇怪的問題。其實是因為業務增多，有可能一個資源池擠不下，所以把相同的應用在不同的機房去部署，也就是跨機房的部署。再就是排查問題比較難，這個問題遇到很多次了，那時候一升級我們就發現了問題，但捕捉不到相關的SQL。但是數據庫看起來是很平靜的，中間件是一會兒有問題一會沒問題的情況，所有的工作人員都對這些無頭案很困惑。
4、我司六年雲數據庫服務歷史
我們公司上雲大概是2013年初，一直以來雲數據庫服務運維的複雜度是不斷增高的，因為數據庫類型、數據庫的架構類型、服務業務類型、雲數據庫的資源中心以及項目數以及更新的需求數目等，其中數據量增加最高，這對DBA增加了維護、管理、技術的要求。因為都是我們自建的雲數據庫服務，我們所面臨的問題非常的大。
5、雲數據庫與雲計算相遇，存在主要問題
雲數據庫屬於PaaS的範疇，它下面是IaaS基礎設施及服務，我們前幾天也遇到一個問題，數據庫無故中斷了十分鐘，以為宕機，我去找雲公司，原雲公司說沒宕機，性能也沒有問題。後來雲公司向我反饋說是雲計算的軟件和宿主機的網卡驅動存在著衝突。
還有一個問題就是LINUX操作系統內核和雲計算內核發生了衝突，這是群死群傷的問題，是幾百臺幾百臺的問題，那我們去如何去解決?我們也發生了整個機房宕機，就像阿里雲一樣的整個機房宕機的問題，還有類似於阿里雲的整個資源池的共享存儲發生了IO的爭奪。另外我們也發生挖礦病毒，還有其他各種各樣的問題。我們面臨整個資源池要廢掉的問題，成百上千的實例要搬到另外的資源池上面去，這是一個非常大的問題。在這種情況下，我們需要產生一個新的保障模式。
二、反脆弱運維體系構建過程
1、數據庫異構上雲遷移過程（2013年開始）
下面我們看一下整個的構建過程。大概在2013年10月份的一個業務中，我們做了一個遷移的操作。那個時候我們一窮二白，只有MySQL和Oracle兩種市場所提供的中間件，市場上提供的大概有阿米巴 、ATLAS，cobar，MyCat是零點幾版本，大家都不敢用。在這種情況下，為了支撐業務我們只能分表分庫，即使完成了以後，我們所有的監控還是一窮二白。像MySQL這樣一個完整的監控，在市場上也是不健全的，因為它的指標和之前有點不一樣。在這種情況下，我們做了全部用腳本化去監控，做了最原始的腳本化。
我們業務要求只能夠在凌晨3點到6點施工。在遷移過程中，市場上的工具是原廠自帶、第三方或SQLserver還有普通的一些遷移方法我們都嘗試過，後來發現這確實是很困難的事情。所以，我們DBA就用了原始的存儲過程，再加上這個DTS 這樣的遷移模式，把業務梯度化分類。最熱的數據在停機三個小時之內完成，但是在遷移的過程中又發現了很多的挫折；我們遷移工具、存儲過程等在測試的時候都是OK的，但遷移的過程出現了問題。在遷移的過程中數據是有問題的、不匹配的，所以對研發做了一個限制和標準。在這種情況下我們完成了這樣一個艱鉅的任務，花了三個月的時間完成了3億多行核心數據的遷移，包括代碼編寫。現在最大的數據有30多億行，一直運行得很完善，而且這個項目已經做了雙節點的正常運行。
總結一下，在使用雲數據庫過程中，我們一定要考慮到雲計算的環境，不要覺得整個資源池是無限的。要注意雲資源池能夠給你分配多少臺主機，它到時候裝不下你的業務怎麼辦？還有我們剛才所說的雲計算那麼多的問題，該如何去保障？另外，目標的數據庫也不要做得太花哨，要做自己能夠運維的數據庫。 比如說MySQL就是非常好的例子，都是大家都會用，也會有保障的模式。
在遷移方案中， 我比較傾向於研發級的遷移，可以一個用戶遷過去，然後發現不行再遷回來。現在已經成熟的一個模式，大概是遷了半年，反反覆覆。雖然說很慢，但它確實保障了高併發的業務連續性要求。在遷移技術當中，我還是建議自研，因為市場上的那些工具都不完整，比如說前段時間我們用了開源工具愚公，用中間件遷移的時候很不好用。我們的研發整整花了一個半月才改造好。另外，在遷移過程中，希望大家把數據的一致性和遷移的效率要做好，我們目前有五六種遷移的能力，基本上都是在去Oracle的路上。現在還有幾十臺核心的業務在做，這個事情是很艱鉅的。
還有另外一個，大家不要覺得DBA就要失業了，只是工作模式發生了變化。像我們團隊來說，曾經是三個人，現在有十幾個，DBA是越來越多了。大家可能以前只是維護級，現在需要研發能力，我們需要不斷創建工具，多做創造性的運維工作，轉換工具模式。
2、雲數據庫服務技術原則
對於雲數據庫我們需要堅持一個原則，我一再強調要保持雲主機的特性、彈性輕巧和資源的集中，大家以前都覺得好像一個Oracle裡邊可以放八個項目，很多個項目去複用，但是雲主機它是很有很輕巧的，4C、2C這樣的都可以，但是要適當的複用。
另外一個就是數據庫建設的原則，不要覺得自己技術很高端，去創造性的直接拿來最成熟的工具去做。當你發生問題的時候也不要害怕，在社區上找你的盟友，然後去解決。
再一個就是可實施性的原則，然後當項目去立項的時候，你做一個不可維護的、大家都不知道的工具，必然會給這個項目帶來很重大的問題。我們需要架構簡單靈活，解決問題非常快速，大概需要這樣的一個思路。儘量不要用分佈式，因為我曾經做過MySQL的分佈式測試，大概系統損失 2/3左右的運算，性能非常弱。那要是再放在雲機上面，我做了一個測試，QPS到2000的時候，事實上我用到一千的時候它就死了。
這個性能我覺得是不可靠的，雖然整個雲資源池給你去壓測的時候是非常大的，但實際上用的時候打了折，只能把性能打折作為業務能力的評估標準。所以大家不要太信整個資源池，因為它有資源爭奪的現象。
我們需要關注性能，DBA經常去調優，經常去背鍋，不管是研發問題還是項目設計問題。那在這種情況下，我們需要從開始就約束研發、約束產品，當項目立項的時候我們要考慮到請求的比例、請求的時間間隔、請求的響應時間、請求的併發情況和系統吞吐量。經常會說性能邊界的問題，如果當這個資源就硬件資源和MySQL的配置都很合理的情況下，那就需要知道軟件的邊界能力，需要去知道系統達到瓶頸的情況，從上端去壓測，不然的話鍋永遠是DBA的。
對於應用性能，我們需要關注同步與異步、併發量、請求的響應時間、返回的數據量、能不能夠要求研發，有請求速度可控的能力，我們殺會話是殺不完的，調優是調不完的，需要從項目設計就開始就去解決併發量等的問題。
關於雲數據庫，剛才說了需要關注資源池和網絡環境、雲主機的能力、數據庫的類型和數據庫的架構以及數據庫節點的能力。一定要配合研發，產品需求要理解清楚。對於數據庫來說，我們必須清楚業務和cpu是優先的，還是MEM優先的，還是存儲優先的，然後再做適當的匹配和雲主機的能力，這樣才能夠為公司提供可靠的數據庫系統，替公司節約成本，提供最佳配置。
3、分佈式數據庫案例
這是我們的一個案例，一個分佈式數據庫的架構。上面是多VIP的模式，下面是一個負載均衡集群，然後下面是分表分佈的中間件，再下面就是MySQL的一個集群，做了一個很普通的主從。因為我們有雙節點，所以這個地方沒有用高可用直接切換的本機的能力。我做了一個數據庫的標準給我們公司，說對於一個MySQL來說，必須是一主一從一異地，在異地必須做這樣的一式三份的能力，這救助了我們整個系統很多次。
大家一定要在MySQL的架構中做一個緩存的集群。我們用的是memcached這樣的一個能力，然後我們還有一個能力用的是Redis。
4、分佈式數據庫問題防範
基於剛才的架構，我們需要建設一個故障樹，我們知道問題，預先做一個問題的埋點，知道問題發生在哪裡，先把問題列出來。不要覺得什麼都是意外，沒有意外的，因為你知道你用了什麼，問題會發生在哪裡，要很明白要做的事情。
在這個時候負責均衡層它一定是有問題的，另外一箇中間件也是有問題的。因為我們曾經遇到過分表分庫的中間件、我們的研發， 甚至謂詞都不寫，何談分片，就是把這個直接上線。那如果說這個發生在1000個實例的情況下，是不是所有的實例都cpu90%以上，這個是有很大風險的。還有集體高併發，另外我們也遭遇過緩存崩塌，緩存崩塌就高併發到SQL，而且SQL集可能是個爛SQL集，只一條SQL可能數據庫就死了。即使就是分表分庫的，但是它很多個分片支撐在上面，遇到高併發你也會死掉。
5、分佈式數據庫雙節問題
在剛才的案例中我們做了一個雙節點，我們曾經做了三節點，但是三節點上線以後制約點很多，然後就撤銷了。雙節點一直在用，但是雙節點發現很多的問題。我記得我們的團隊成員在雙節點體系沒建設好的時候，每天半夜由於複製中斷報警起來三次去處理。在每個節點當中，我們設了一個極星平臺和北斗平臺，北斗是中間件的自動管理化，極星平臺是整個數據庫的自動化管理層，整個的架構大概就是這樣。
基於這個問題，我們重要的思維是來自otter，otter拿過來也是很不好用的。但是它提供了四個很有效的框架，他用了etl及TCP滑動窗口的思路，然後用了ZOOKEEPER協調工具。我們利用了這樣的思維，在每個節點按實例去做高可用。當一箇中斷的時候，就是這個節點死了，然後做一個自愈的自動重啟，基本上完成了95%以上的問題。現在我們DBA是比較幸福的，因為我們整個機制按照這種思路去完成，每個組件都不能有單點，每個機房它都有另外一個地方的組件複製節點。
這個時候我們也要建立一個故障樹，我們最長的專線是近2000公里長。而且我們的機房（雲資源池）非常多，同城的機房（雲資源池）之間就是三毫秒到六毫秒的延遲。但是距離越遠的時候，大概有的時候到80毫秒的延遲。我們要很清楚專線的能力，不但是中斷，普通的延遲都要80毫秒，更別說怎樣去做災備的能力。中間件的問題裡有個ZOOKEEPER，我們ZOOKEEPER裡面的一個DATA數據很關鍵，雖然說ZOOKEEPER裡的數據（本身在內存）， 過一陣子它會以日誌的模式落到落到磁盤上，但事實上它內存裡面總有那麼1000到2000條數據放在裡面（我們需要保證它的完整性）； 所以這個時候我們需要用數據庫來解決，把數據全部寫到數據庫裡面，每個節點異常的時候我們該如何去做？一定要規範研發SQL，既然有雙節點，就要約定不能用的地方。然後這個SQL不能夠分片，不能夠有什麼樣的DDL語句，不能有什麼樣的存儲過程，都要說得明明白白。我們的雙節點經過大概 2014年開始建，到現在有五年的時間，基本上可靠性已經達到行業的標準，所以我們的業務支撐也比較好一點。
6、NOSQL數據庫
MongoDB下面這個組件我就不說了，一般MongoDB有四個組件，我們採集多個VIP與DNS協調，還有另外一個是分片。上面我們用了一個負載均衡層，我們的思維也是每一層都不能有單點。那給大家講了這麼多的問題所在，我們需要從哪個點去保障我們的業務？
7、NOSQL數據庫（MONGODB）
MongoDB也屬於雖然叫集群，它也有分片，所以它也是分佈式的。 那分佈式的數據庫，我們一般的定義是保障整個數據庫正常運行，一個節點不能影響整個數據庫的運行，對吧？但事實上我們所遭遇的是什麼？一個分片有問題的時候，然後他上傳到中間件也沒問題，但是你的應用呢？應用怎麼設計？所以，研發一定要明確一個分片影響的應該就是這個分片上的數據應用，而不能是全局的。因為他發現有問題的時候，他在應用層RESIN或TOMCAT等響應慢時，就發生了堆積顯示數據庫慢，其實不是數據庫集群（是某個分片），但整個應用會存在問題，其實這數據庫是分片數據庫，但應用整個架構看是偽分佈式的，這個問題經常發生。所以在這種情況下，我們一定要去站到更高的角度上看數據庫的設計。我們一直說調優在這種複雜的環境下有很大作用，其實作用沒那麼大。
8、威脅分析
經常有人說數據庫上的故障80%都是DBA誤操作的。事實上不是的，我們經過六年的運維發現，與數據庫相關的所有人員他都脫不了干係。另外就是發現了研發在應用層做一個清理數據庫的定時任務，那這些任務死了，然後又是高併發，數據庫就發生問題，還有運營人員那個SQL不知道怎麼寫的。然後可能是200行，可能是六個以上分頁，又是MYSQL和雲機，下面的事情就開始拋包袱了。
在這種情況下，對於業務層來說， 一個是事務的SQL比較差，一個是應用升級的時候沒告訴DBA做審核，沒有評估完整。然後是突然間數據量增長以後，性能突發的衰減，但是隻有30%，其他的其實都是人為。但是七成中也就只有百分之十幾是DBA做的。所以這個事情大家一定要想清楚，多方面的考慮問題並解決去保障好我們的數據庫，為公司帶來效益。
9、環境分析
平時在維護一個Oracle的時候，大家都死命的去保障一臺，穩定的時候DBA可能會在嗑瓜子。事實上我們現在所遭遇的就是幾十個資源池。 每個資源池有很多個數據庫，現在又遭遇到物聯網（現在及未來更多更多的數據庫（嵌入））。但我們的產品要求不能有故障，故障運行到誰手上，那就是誰的問題。這就要有個思維，所有的數據庫問題都不能影響產品，需要故障無害化處理。至於怎麼去無害化處理，就是高可用、自愈等能力。
10、監控體系構建
監控已經是一個常態，那對於剛才那麼多的資源中心如何去保障雲數據庫監控的有效性和收斂性，我們如何去做？當然肯定要考慮做一個分佈式的監控系統，那大家開始的時候說用ZABBIX等什麼東西，但是我們的監控基本是原創的，它是用OS機是用ZABBIX，因為最初很多的東西監控的數據比較模糊（這幾年才比較具體），比如說磁盤小於10%，但不知道具體是多少。但是當分佈式監控平臺做好了以後就真的高枕無憂了嗎？不是的，因為我們也是遭遇很多問題，剛才那麼多的資源池、那麼多的實例發生問題的時候，我們是沒發現的。在這種情況下，我們就設計了這個是元監控平臺，它來自於谷歌的思維。元監控他的思維是來自什麼？源數據。源數據是數據的數據，剛才我們的嘉賓說他們的元信息系統，那是信息的信息；元監控也一樣，也是監控的監控，是二級監控。
我們的監控會發生什麼問題？第一個分佈式的監控一定會死掉，第二個監控的覆蓋不全，有的主機沒部署上去監控不全。第三個就是要監控升級，監控的版本不一致。出現這三個重大問題的時候，我們需要用元監控平臺去解決。我們現在做了一個初始的，只是發現了問題就報警。我們未來會做這樣的一個平臺，發現了問題，把這個元監控作為一個最高的標準，然後把最新的版本派過去，給它更新上去。另外，如果說如果監控的進程死掉以後可以自愈，然後重啟監控。另外一個就是監控覆蓋不全的時候，把最新的監控遠程安裝上去，這就是元監控的使命。
但即使有這些東西的時候，也有一個問題，數據庫不斷地去重啟，等你發現重啟以後，什麼問題都找不到。針對這點，我們設計了這個DBA快照採集系統，三秒鐘採一次，也是分佈式的。 基於MySQL和Oracle全部做這個，這也是我成就感最高的一點，因為我們用它診斷了很多東西，快速地去發現它的趨勢（並是全業務的，全局的），抓住它的上層信息以及SQL。還有一個點就是雖然快速地抓住了它，但是應用升級升得不乾淨。比如說我們有一個應用有200多臺應用服務器，升級的時候升級了90%，剩下的10%是老系統。所以業務會有問題，數據庫也抓不住。我們通過這個採集系統很快就能診斷出問題。
這個就是我們基於剛才的思維所做的一些系統。這個元監控系統比較初級，它只有告警的功能。對於基本的報警，我們設了五級監控，五個級別，有的三天發一回、一天發一回、一小時發一回、一分鐘發一回等等。但是採集數據都是一分鐘之內，採集系統所有的數據都是寫到數據庫。大家可以把數據庫做各種各樣的一個東西，然後隨時都可以全局去看所有的項目的SQL、所有的項目的現狀是什麼，不需要登錄到數據庫就可以直接去查看分析及診斷，及時發現問題接解決問題。
11、自動化與自助化可視模型
對於DBA來說，安裝操作系統，雲機的話除了模板之外的所有技術都是我們自己做的。在這種情況下，我們從2014年有了思想及準備，2015年開發了一個更新和查詢的自助化平臺。這樣的話，一個DBA可以維護3000臺實例，可以把這些給研發、給運維，只要我們設好規範，就可以更新。另外，自助化的質量平臺，發現問題就用告知的模式給你發郵件或者發短信。另外就是自助化的中間件，我們把整個拓撲放上去，然後做了一鍵切換配置。自動化部署平臺目前也是DBA去幹。當時我們公司的MySQL模板是我建的，建完以後十分鐘可以解壓，稍微配置就可以完成數據庫的配置。但這些還不夠，因為我們所有的監控和採集需要有關聯、需要監控的、需要評估的、需要標準化的，我們去部署驗收的列表經過15個版本。我們有31條規則配置，如果你沒有完成這31個工作，那這個數據庫就不能算是完成了部署。
在這樣的情況下我們做了一個自動化的部署平臺，它可以部署自動完成驗收的報告單，包括擴容縮容也要產生報告，而且可以批量地部署。我們測試過一百臺十分鐘可以完成這樣的部署，這也是快速部署的思維。
DBA是要巡檢的，光監控是不夠的。我們做了一個自動化平臺，只看結果。把核心的一些傳統用告警的模式，實現自助化。出現過MySQL有些業務在程序上死循環，然後發現自增列滿了，表已經滿了，但是磁盤不一定是滿的。所以我們做了一個監控，還有一些權限方面的作為監控的補充。這是一個很完善的自助化模型，那大家可能要謹記，生產灰度都可以做生產的，測試和研發一定要網斷隔離，如果不隔離可能會出現生產的應用掛在測試數據庫上面，測試的應用又掛在生產庫上面，出現了很多的誤操作。
關於剛才所說的自動化更新，我們做了一個工單系統，市場上第一家做這個的是美團，後面比如YEARNING ，ARCHOR等系統，每個公司都是各展神通。在這個情況下，我們改造了開源，利用我們自己的思維，做了一個自動化的東西，給它嵌入了自動化的流程。因為我們DBA不可能每天晚上12點起來去update一條。我們把這個作為自動化的檢測環境，如果那個時候存儲要死了，插入2000萬行、更新多少行數據、產生了多少日誌需要評估的，所有的性能在90%。那個時候再備份，還能不能更新？能不能去執行業務的升級？這都是我們需要檢測的，如果不行就延遲半小時，如果還實在不行，就在規定的時間內告訴研發告訴DB沒更新成功（放棄更新）；
關於質量自動評價平臺，我們做了十個維度的模型，然後把這個問題的過頻，過慢的，Top N的SQL告訴相關的人，比如說研發和DBA，那這個時候我們都能夠有所展示。
12、指令處理流程
除了這個GUI可視化平臺之外，還有一些大量的一些大的東西，這個是比較常規的，那大家需要根據規範制度用一個堡壘機等安全機制，用一個存儲數據的存儲，使用審核工具 以及密碼的存放機制，然後去安全地操作。
13、建設數據庫專用知識庫
大家一直都在優化，但是隻優化沒用，要從整個體系與維度去做。除了技術能力之外，我們要建設技術知識庫，根據每個項目要建病歷，這個是我一直的理想，我們也一直這麼做。我們必須把這個規範和工程手冊、項目文檔集中起來，大家知道DBA是最不忠心的崗位，在這個時候我們必須一進來就去研究這個東西，那DBA必須在這個場景之下去做這樣的一個東西。我們已經建了1500多件自創的文檔，有4000多個工具，包括像腳本、自動化的一些工具。
14、建設能力與質量評級7分制
除了這個知識庫之外，我們必須有一個客觀的質量評價標準，根據這個評級我們要建一個能力的體系，要不斷細化。我希望大家能根據這些客觀評價你到底做的好不好，給公司一個交代，公司需要做一個客觀的評價的依據，我們到底能不能做好甲方的東西，能不能做好市場需要的東西。
15、自動化與監控的關係
自動化的意思是，監控不是隻告訴DBA幹什麼事情的，它是用來做自動化的，是用來自愈的。它最終的是要服務自愈、同步自愈、備份自愈。如果實在不行要數據庫服務自殺才能夠讓應用保持健康，一定要有這樣的一個思維。
16、構建效果
這個是我們的一些成果。我很自豪的說，因為我們的業務能力是這樣，但是我們DBA的能力要大於這個很多，其實我們已經可以和市場接軌了。
三、預見-未來
雲數據庫的未來最終是要智能的，這是一個趨勢。人工智能我們DBA應該要學一下。
數據庫的容器化主要是用於數據庫的實例，也把它作為一個接口來對待，要做一個無服務化。但是一個資源池跑到另外一個資源池的時候，遷移到不同共享資源池的數據遷移時，卻是與其它的遷移方式相同，大家需要有這樣的一個能力。
區塊鏈區塊鏈是一個很好的解決方案，DBA可能要多想一想這個思路。
因為我們的架構是非常高，從每一個節點需要做一個。我想告訴大家的是IBM的自主計算，那本書不厚，但是很有思想，希望大家能夠去學一學IBM的偉大之處在哪裡。思考我們做的到底好不好？應該怎樣做好數據庫？
最後講一下數據庫的發展趨勢，因為5G到來，到互聯網，網絡技術有分佈式和區塊鏈，有TMT的融合與互聯網的融合，人工智能提供智能的數據庫是未來我們努力的方向。最終我們要提供一個智能數據庫，實現智能運維，儘量人不要參與，因為我們的人是很貴的，讓系統參與。最好系統要做到百分之百，雖然說不可能，但是我們要向那個方向去努力。