雙態(tài)運(yùn)維模式下的數(shù)據(jù)規(guī)范建設(shè)之路

1、 雙態(tài)運(yùn)維模式下的數(shù)據(jù)規(guī)范建設(shè)之路DBAplus社群 微信號 dbaplus功能介紹 圍繞數(shù)據(jù)庫、大數(shù)據(jù)、PaaS云，頂級大咖、技術(shù)干貨，運(yùn)營幾個月受眾過十萬！成為運(yùn)維圈最專注圍繞“數(shù)據(jù)”的學(xué)習(xí)交流和專業(yè)社群！歡迎投稿，加入探討。近年來，不少金融客戶和我們交流時(shí)都會問到數(shù)據(jù)庫的運(yùn)維體系應(yīng)該怎么去創(chuàng)建，他們知道要建設(shè)規(guī)范體系，但不知道具體有什么方法。對此，我們把這幾年在金融駐場運(yùn)維規(guī)范的建設(shè)做了一些總結(jié)，希望能對大家有所幫助。雙態(tài)運(yùn)維，如何開展什么是雙態(tài)運(yùn)維？對于傳統(tǒng)金融業(yè)來說，就是在保證一貫強(qiáng)調(diào)的安全生產(chǎn)、穩(wěn)定運(yùn)行的基礎(chǔ)下，繼承互聯(lián)網(wǎng)高速迭代的更新速度，保證企業(yè)的信息建設(shè)思路既穩(wěn)又敏。去年曾聽

2、過一個演講談到了雙態(tài)模式下的運(yùn)維演進(jìn)之路，分享者分享了如何去做，提出了運(yùn)維的發(fā)展方向就是以ITIL理念為核心的穩(wěn)態(tài)管理，同時(shí)使用DevOps的方式進(jìn)行敏捷運(yùn)維，實(shí)現(xiàn)敏態(tài)。但是，以金融為代表的傳統(tǒng)行業(yè)都知道，DevOps對于整個IT中心的改動太大，很難完全DevOps。那么，在這種很難打破傳統(tǒng)壁壘的情況下，我們怎么去實(shí)現(xiàn)雙態(tài)運(yùn)維呢？回過頭來看看DevOps的思維：精益，價(jià)值，跨界，敏捷。下面我們就來聊聊如何通過抓住DevOps思維中的精益、價(jià)值、敏捷這三個思維要點(diǎn)，在盡量少的變動下，在保證穩(wěn)態(tài)的同時(shí)實(shí)現(xiàn)這個敏態(tài)。運(yùn)維對象&運(yùn)維人員IT的發(fā)展很快，我們的數(shù)據(jù)庫也跟著這張圖在企業(yè)內(nèi)部飛速膨脹著。20

3、多年前，我們維護(hù)的數(shù)據(jù)庫的數(shù)量僅幾套到10幾套，10多年前，維護(hù)的數(shù)量維持在幾十套。10年前的時(shí)候，數(shù)量開始逐步破百了。2年前，我們的一些金融客戶數(shù)據(jù)庫的數(shù)量破千了，到現(xiàn)在這些破千的企業(yè)，所有種類數(shù)據(jù)庫的數(shù)量基本維持在1500套上下。互聯(lián)網(wǎng)里有個說法，數(shù)量在幾十套的時(shí)候，人肉運(yùn)維對于企業(yè)來說，是最節(jié)省成本的方法，但當(dāng)數(shù)以千計(jì)的運(yùn)維對象存在時(shí)，我們需要更高效的方法去運(yùn)維。這年頭其實(shí)關(guān)于運(yùn)維提出了很多方法論，高效運(yùn)維、白盒運(yùn)維、精益運(yùn)維等，說到底，需要靠我們的運(yùn)維人員去執(zhí)行。對于傳統(tǒng)金融來說，運(yùn)維人員的心理就愈加重要了。這里以一個DBA團(tuán)隊(duì)中工作了兩年左右的中堅(jiān)力量小明進(jìn)行舉例。在一次偶然的機(jī)會下

4、，小明見到了自己曾經(jīng)的大學(xué)同學(xué)小剛，對方目前正在一家互聯(lián)網(wǎng)里做著DBA，同樣的工作，讓兩個人對于近況展開了討論，酒足飯飽，小明回憶著飯桌上的種種話題，不禁對未來感到了迷茫。小明一直認(rèn)為自己的薪水不高，每年漲幅也很低，小剛說自己從不擔(dān)心薪酬，每年漲薪都不會被遺忘，而且數(shù)量不低，當(dāng)然如果公司沒倒閉的話。小明覺得現(xiàn)在的通宵太多，常規(guī)情況下每周至少兩個，感覺太累。小剛說，通宵不算啥，補(bǔ)貼豐富。同樣的活，干了兩年的小明認(rèn)可領(lǐng)導(dǎo)說的“穩(wěn)定壓倒一切”思想，覺得目前的環(huán)境下已經(jīng)沒有新技術(shù)的挑戰(zhàn)了，感覺著把IT從一個技術(shù)活，變成了體力活。而小剛在吹噓自己的技術(shù)博客中，又加了什麼新架構(gòu)技術(shù)的使用。晚上回家精疲力盡

5、的小明，一直在想，自己之后的路在何方。睜眼仿佛看到了白天領(lǐng)導(dǎo)提的，兩年滿三年就可以升級了。閉眼卻又想起了同學(xué)在旁邊吹噓，別看現(xiàn)在我是一線民工，等我這兩年積累好了，我就是某創(chuàng)業(yè)公司首席技術(shù)官。酬薪，強(qiáng)度，內(nèi)容，前景，這四個我們大部分在社會上拼搏了四五年內(nèi)的人最關(guān)注的，也是最決定人才去留的四個點(diǎn)，而這批人也往往是團(tuán)隊(duì)中的中堅(jiān)力量，在傳統(tǒng)和互聯(lián)網(wǎng)的博弈下，這兩年傳統(tǒng)金融的員工流向各種互聯(lián)網(wǎng)金融非常多。在運(yùn)維對象數(shù)量劇增的當(dāng)下，我們的人員替換永遠(yuǎn)比人員養(yǎng)成的速度要快。做運(yùn)維久了，有時(shí)候挺感嘆，如果現(xiàn)在的團(tuán)隊(duì)里面，誰誰誰還在打造一只全明星團(tuán)隊(duì)多好。對于我們運(yùn)維的對象數(shù)據(jù)庫來說，我們配置了容災(zāi)，但是運(yùn)維人

6、員的容災(zāi)缺青黃不接，人員替換永遠(yuǎn)快于人才養(yǎng)成。那么，在庫那么多、人員流失又那么重的當(dāng)下，我們怎么去把握精益，價(jià)值，敏捷這三個點(diǎn)呢？從運(yùn)維到運(yùn)營有一句俗話說得好，思路決定高度，去年運(yùn)維圈里提出了個概念從運(yùn)維到運(yùn)營。其實(shí)說的就是關(guān)注點(diǎn)前移，將運(yùn)維對象從庫提升為人，化被動為主動等。但是對于DBA來說，IT運(yùn)營的終極目標(biāo)：簡單來說就是不僅活著，更要活得好。那么做運(yùn)維的，如何實(shí)現(xiàn)運(yùn)營到運(yùn)維的轉(zhuǎn)變？反過來逆推一下，我們作為企業(yè)的員工，要想活得好，企業(yè)要做得好，在這個信息化時(shí)代，就務(wù)必要跟上時(shí)代的腳步，企業(yè)IT就必須要加速變化。而對于金融IT來說，無論怎么快，安全生產(chǎn)、穩(wěn)定運(yùn)行是第一要素。這是前面說的雙態(tài)運(yùn)

7、維的理念，但它靠什么來落地？清晰明確的流程，簡潔明了的步驟，不怕斷檔的團(tuán)隊(duì)，三者融合，確保了在將價(jià)值導(dǎo)向的同時(shí)確保工作的精益，并且實(shí)現(xiàn)我們的敏捷運(yùn)維，而這一切的基礎(chǔ)，在于規(guī)范。這張圖，從下往上，其實(shí)就是借著規(guī)范，通過一個個里程碑，而從運(yùn)維走向運(yùn)營的道路。規(guī)范建設(shè)指南做規(guī)范，相信也是讓很多朋友頭疼的一件事。規(guī)范這玩意，由無數(shù)大大小小的文檔組成，牽扯面之廣，往往讓我們一些剛起步的企業(yè)不知道從哪個方向入手。而且傳統(tǒng)企業(yè)IT系統(tǒng)越建越多，多而雜，各種各樣的技術(shù)規(guī)范都可能有，非常亂，這樣造成IT運(yùn)維支持比較困難。差不多6、7年前，在運(yùn)維規(guī)范不成體系時(shí)，我們需要去裝一個庫，因?yàn)檎也坏桨惭b文檔，所以去網(wǎng)上下

8、了份。對于初創(chuàng)企業(yè)來說，有問題問百度，解決了就行。但對于大型金融業(yè)來說，這里面有著很大的隱患。我這邊結(jié)合這幾年的運(yùn)維經(jīng)驗(yàn)，梳理了一下我們規(guī)范建設(shè)的思路。規(guī)范有兩個重要的特性：工作手冊的總綱，團(tuán)隊(duì)傳承媒介。將這兩個特性深挖展開就是我認(rèn)為規(guī)范建設(shè)的思路：工作流和信息流。工作流建設(shè)方向指引首先說說工作流。建設(shè)的時(shí)候，我們從設(shè)置流程大類、流程子類、技術(shù)分類、SOP手冊這四個緯度逐步細(xì)化進(jìn)行建設(shè)。流程大類包含五個緯度：變更操作、告警處理、值班巡檢、性能優(yōu)化、應(yīng)急預(yù)案。其中前三項(xiàng)各個企業(yè)都是按照流程的不同，內(nèi)容肯定也不一樣。第四項(xiàng)性能優(yōu)化就比較偏技術(shù)層了，屬于一種可以拿出來交流的通用性流程。第五項(xiàng)應(yīng)急預(yù)案

9、，在最開始的時(shí)候是幾乎沒有的，但無數(shù)血淚的教訓(xùn)告訴我們設(shè)立應(yīng)急預(yù)案的重要性，于是也加了上去。各自的流程子類如圖：變更操作：安裝部署、遷移升級、用戶權(quán)限維護(hù)、數(shù)據(jù)歸檔、數(shù)據(jù)對象維護(hù)等告警處理：性能告警（異常等待，高效耗語句，鎖阻塞）、實(shí)例告警、同步告警、空間告警、配置告警（基于安裝規(guī)范的，參數(shù)沒有按照規(guī)范配置）等值班巡檢：值班流程、巡檢流程、投產(chǎn)流程性能優(yōu)化：參數(shù)調(diào)整、語句改寫、非改寫優(yōu)化、應(yīng)急預(yù)案：硬件損壞、軟件損壞、關(guān)聯(lián)系統(tǒng)損壞（nbu）關(guān)聯(lián)系統(tǒng)：類似數(shù)據(jù)庫的備份，監(jiān)控系統(tǒng)壞了該怎么辦接著就是根據(jù)各項(xiàng)子類，在根據(jù)相關(guān)的技術(shù)進(jìn)行細(xì)分，比如說像遷移升級：Oracle XTTS升級、Oracle

10、DG切換遷移或者其它數(shù)據(jù)庫Informix hdr切換遷移、Informix RSS切換遷移等，根據(jù)使用的技術(shù)不同，以及數(shù)據(jù)庫類型不同再進(jìn)行的細(xì)分。最后再落地到sop標(biāo)準(zhǔn)流程執(zhí)行手冊。SOP里肯定包含了基本上所有的執(zhí)行步驟、腳本，寫SOP的這個過程，其實(shí)也是一步步將規(guī)范腳本化的過程。工作流建設(shè)的突破點(diǎn)這邊列舉了三個最主要的問題：操作復(fù)雜：我們的某些變更操作，涉及步驟動輒十幾二十多步，相當(dāng)繁瑣復(fù)雜，而且又需要多個數(shù)據(jù)庫間進(jìn)行交互，更加加劇了我們的復(fù)雜度；不通用：花大精力寫出來的變更方案，每次同類型的變更，要做很多修改，不通用；校對困難：我們是直接在金融生產(chǎn)庫上做操作的，重大變更的話，有些企業(yè)還會

11、把每個具體的步驟一頁一頁打印出來，嚴(yán)謹(jǐn)性不用去說。所以做運(yùn)維時(shí)，對于這類改動的方案校對審核得非常仔細(xì)，當(dāng)然這也和我們公司的一條紅線有關(guān)，所有上生產(chǎn)的方案，一定要審核通過才執(zhí)行。所以這種情況下，經(jīng)常有大量的方案堆積在評審人這邊。這個時(shí)間是非常痛苦的，窮則思變。我們就想了一個辦法，一個字拆，針對不同場景的復(fù)雜步驟，將它分割成一個個原子步驟。當(dāng)然不是所有類別都可以這么做的，但是我們發(fā)現(xiàn)其實(shí)大概90%的操作都是能拆的。舉一個Oracle DG切換的案例。常規(guī)的DG切換，肯定不是這樣切的，有switchover的步驟，但是這個操作我們是不做的，它里面存在著未知，我們不敢做。在常規(guī)DG切換中，switch

12、over這個操作有無法把控的風(fēng)險(xiǎn)，主庫切換為備庫無法切換回去，怎么辦？我們把切換的步驟變?yōu)?，從主庫這邊直接將在線redo和控制文件通通拷貝到備庫進(jìn)行啟動的方式。這樣一個操作，我們切分成了13個原子型操作。這其中，對于物理文件的備份，都是可以復(fù)用的；減少標(biāo)準(zhǔn)操作的復(fù)雜性，讓每個原子標(biāo)準(zhǔn)都可以被復(fù)用，是我們做原子化標(biāo)準(zhǔn)的目的；將同一個變更中不相關(guān)的操作進(jìn)行分離是我們的分割標(biāo)準(zhǔn)。剛開始，我們是針對變更操作入手開始進(jìn)行原子化標(biāo)準(zhǔn)建設(shè)，后面逐漸發(fā)現(xiàn)，分割出來的原子化標(biāo)準(zhǔn)很多。我們擁有了一個原子庫，這個和我們的函數(shù)庫其實(shí)類似。原子庫中的規(guī)范呢，在根據(jù)不同的技術(shù)和平臺進(jìn)行分類。再然后我們發(fā)現(xiàn)這些原子化標(biāo)準(zhǔn)，

13、慢慢的，可以輻射到其它流程大類里面的操作。就像PDCA戴明環(huán)一樣，不斷地推動工作流的建設(shè)，整個標(biāo)準(zhǔn)原子化操作成為了整個工作流建設(shè)的突破點(diǎn)。差不多一年多的時(shí)間，我們60%的SOP可以在原子標(biāo)準(zhǔn)的基礎(chǔ)上結(jié)合而成。信息的歸檔工作流基本上就講到這里了，下面來談?wù)勑畔⒘饕?guī)范的建設(shè)。什么是信息流？字面意思，我要把我知道的告訴你，這個過程就是信息流。信息流建設(shè)可以分為三塊，信息的歸檔記錄、信息的溝通，信息的升級。企業(yè)的信息庫一般由事件庫、告警庫、變更庫組成，企業(yè)基本都有自己的內(nèi)部管理平臺，這些平臺的覆蓋面很廣泛，基本上所有的重要事件都會通過平臺中的事件、變更、告警保留下來，以供追溯。但對于可用性事件，我們拿

14、故障來說，它可能是由1個告警而被發(fā)現(xiàn)，幾個事件被其他部門察覺，再借由幾個變更進(jìn)行解決的。對于傳統(tǒng)的ITSM來說，信息存放太碎。很明顯，這些信息的傳遞溝通，并不是需要我們這些團(tuán)隊(duì)中的老員工，靠記憶來硬剛，也不是在各種碎片信息中去拼接，而是需要靠著曾經(jīng)完整的記錄來追溯的。所以這邊我給出了兩條魚，目前為止我們認(rèn)為需要額外記錄的信息庫：包括可用性事件庫和Bug庫。兩根魚骨頭，表示了需要記錄的點(diǎn)。我們做DBA的，其實(shí)無所謂甲方還是乙方，都是做運(yùn)維服務(wù)的，企業(yè)本身其實(shí)就是一個很好的案例來源，我們是需要從歷史教訓(xùn)中學(xué)習(xí)前進(jìn)的，總不能一個問題一年前發(fā)生過，換了一波人，又踩一次坑。信息的溝通在你的企業(yè)內(nèi)部，溝通

15、方式有哪些？微信？釘釘？企業(yè)內(nèi)部通信工具？郵件？手機(jī)？這么多的聯(lián)系方式，卻還是帶來一個問題，部門同事間的歷史信息不對等。我們發(fā)現(xiàn)一個部門里某個同事他不知道某件事，很大的概率在于，他的確是不知道這件事，而不是他忘了這件事。于是我們針對任何團(tuán)隊(duì)里任一位同事都分配了為期四周的一個工作計(jì)劃，每周一個任務(wù)。第一周，熟悉環(huán)境，他需要知道哪些庫是重要的，哪些平臺是給他工作的，誰是他的領(lǐng)導(dǎo)，哪些是禁止項(xiàng)等。第二周，安裝部署，我們企業(yè)有很多的庫，很多種類的技術(shù)，但是變更也好，告警也好，他們都離不開一點(diǎn)，我們一開始安裝部署的標(biāo)準(zhǔn)項(xiàng)，第二周的任務(wù)是安裝部署，去熟悉這些標(biāo)準(zhǔn)項(xiàng)。第三周，基礎(chǔ)技術(shù)，我們每個人進(jìn)來可能是高

16、技能的，也可能是低技能的，但是不重要，第三周就是讓你掌握有哪些基礎(chǔ)技術(shù)是你在80%的工作里面需要用到的。我這邊截取了，目前我們團(tuán)隊(duì)在MySQL方面做的一個新人入職前四周的一個學(xué)習(xí)計(jì)劃，通過我們的學(xué)習(xí)概要，內(nèi)容細(xì)分，學(xué)習(xí)文檔，來讓這個新人員入職流程切實(shí)可行，而不僅僅只是一個高高在上的規(guī)范。第四周，流程實(shí)戰(zhàn)，跟隨我們的老員工，把重要的流程走一遍。通常我們大型企業(yè)對于新員工都是有一個考核制度才能上生產(chǎn)進(jìn)行操作，那第四周終極目標(biāo)考核。大家可以看到，這套規(guī)范其實(shí)對于一個老DBA來說，僅僅是加速對工作的上手速度，但是對于一個新人來說，短短兩個月，他就可以讓一個初出茅廬的新人，成為一個知其然不知其所以然的偽

17、中級DBA。信息的升級做運(yùn)維時(shí)間久了，都說運(yùn)維是個把腦袋別在他人褲腰帶上的活。我們遇到的問題往往不取決于自己，那么在這種某一天肯定會發(fā)生的意外情況下，該怎么去做好信息的升級？我們這邊制定了三條紅線，其中一條就是關(guān)于問題的升級，根據(jù)我們服務(wù)的客戶不同的情況，這條紅線的落地也是不同的。我們在做金融運(yùn)維時(shí)，把運(yùn)維團(tuán)隊(duì)分成了三個層次，值班崗、專家崗、遠(yuǎn)端專家。通過分工，設(shè)立一二三線崗位，先把人力資源有效利用，避免高級人才在做一些繁重的體力活。那在不同的場景下，我們各崗位人員的職責(zé)是不同的。這里我把運(yùn)維問題分為了四個方面：常規(guī)事件處理（像清理以下表空間，刪下歸檔之類的）、異常問題處理（包含一些技術(shù)難度較

18、高的工作，比如SQL性能低下，存儲過程某類語句問題緩慢等）、應(yīng)急預(yù)案實(shí)施（當(dāng)某些不可抗拒的事情發(fā)生后，我們是沒有回退方案的，這個時(shí)候就是應(yīng)急預(yù)案的啟動了）、重大故障救援（這個是指某些第一次發(fā)生的，沒有應(yīng)急預(yù)案的事件）。常規(guī)事件處理：值班崗處理并記錄，當(dāng)天結(jié)束時(shí)統(tǒng)計(jì)匯報(bào)；異常問題處理：值班崗依照自己能力，十分鐘無法解決時(shí)，上報(bào)專家崗，由專家崗處理解決并記錄匯總給值班崗，當(dāng)無法解決時(shí)上報(bào)給負(fù)責(zé)人，并協(xié)調(diào)遠(yuǎn)端專家。當(dāng)天值班結(jié)束時(shí)進(jìn)行匯報(bào)；應(yīng)急預(yù)案實(shí)施：值班崗上報(bào)給專家崗和負(fù)責(zé)人，專家崗成員從技術(shù)上判斷是否需要采用應(yīng)急預(yù)案，當(dāng)需要時(shí)，第一時(shí)間通報(bào)數(shù)據(jù)庫組負(fù)責(zé)人，團(tuán)隊(duì)項(xiàng)目經(jīng)理，并由負(fù)責(zé)人決定是否采用應(yīng)急

19、預(yù)案，該預(yù)案通常由一位以上的專家崗成員復(fù)核執(zhí)行。同時(shí)遠(yuǎn)端專家在技術(shù)介入，進(jìn)行后備保障；重大故障救援： 同樣由值班崗進(jìn)行上報(bào)，但是我們的值班崗在這個時(shí)間中，還起到了協(xié)調(diào)人的作用，重要的是對外接口，讓組內(nèi)的專家和遠(yuǎn)端專家團(tuán)能夠安心的以處理問題為主。而我們的本地專家和遠(yuǎn)端專家呢，則以救援方案的制定為中心開展工作這是我們整個信息的升級機(jī)制，使各個崗位在不同情況下各司其職，而不是一擁而上去解決。規(guī)范的迭代完善前面說了很多，我們的規(guī)范怎么去做，從工作流和信息流方面。那么寫過文檔的同學(xué)肯定知道，我們一般文檔都會從v1-v2-v3-v4慢慢迭代跟進(jìn)。運(yùn)維規(guī)范同樣需要迭代去更新，簡單來說就是一點(diǎn)利用好當(dāng)前已有的

20、東西，在體系大綱明確的基礎(chǔ)上去查缺補(bǔ)漏，這里梳理了六個方面：我們的工作流程是否發(fā)生了變化；各流程分類是否需要去豐富；部門同事間的信息溝通機(jī)制是否發(fā)生了變化；可用性事件的原因是否因?yàn)橐?guī)范的不合理；是否有新技術(shù)需要引入，從而修改更新我們的規(guī)范；當(dāng)前規(guī)范是否已經(jīng)覆蓋了所有版本和平臺；但是有兩個注意點(diǎn)，這兩個注意點(diǎn)是曾經(jīng)很長一段時(shí)間里，我們的痛：做好版本控制不要只增不減不然的話，文檔的邏輯亂了的同時(shí)，我們的規(guī)范也就漸漸臃腫到無法看了。另外，永遠(yuǎn)要記住我們的SOP精髓：工作手冊傳承媒介精簡而復(fù)用規(guī)范的階段總結(jié)我們的服務(wù)團(tuán)隊(duì)在為金融業(yè)服務(wù)時(shí)，這些運(yùn)維規(guī)范建設(shè)，也經(jīng)歷了不同的階段周期：第一階段是地基階段，叫

21、規(guī)范標(biāo)準(zhǔn)化：坦白來說，確定每個SOP規(guī)范的標(biāo)準(zhǔn)流程、標(biāo)準(zhǔn)操作、標(biāo)準(zhǔn)溝通。第二個階段，規(guī)范腳本化：我們的目標(biāo)是標(biāo)準(zhǔn)操作腳本化。但是在這個階段，我們遇到了兩個問題：簡單操作，因?yàn)榄h(huán)境往往不一致，導(dǎo)致了腳本化后不能復(fù)用；復(fù)雜操作，又會導(dǎo)致我們的人力時(shí)間成本投入過高。所以對于這個階段，我們只有一個建議：不建議整體腳本化。千萬不要把一整件事，放在一個腳本里面去做。也正是因?yàn)轭A(yù)計(jì)到了這些問題，我們經(jīng)歷了第三個階段：規(guī)范原子化。通過拆拆拆的方式，將操作分解，操作腳本原子化，同時(shí)建立標(biāo)準(zhǔn)原子庫，便于后期操作的調(diào)用。規(guī)范原子化的平臺落地到這步為止，其實(shí)我們都在做規(guī)范，雖然經(jīng)歷了很多階段，用了很多方法，但是說白了

22、，依然停留在文檔階段，穩(wěn)是做到了，但是敏還差得很遠(yuǎn)。很自然的，開始追求這些工作的平臺化落地。這個是我們自己開發(fā)的自動化運(yùn)維平臺對于運(yùn)維規(guī)范的一些功能，當(dāng)我們把大部分規(guī)范腳本原子化后，我們發(fā)現(xiàn)自動化成了一件很簡單的事，所需要去做的就是可以支持各類腳本的集中化管理、工作流程的編排、原子腳本的調(diào)用、以及去觀察每個腳本的執(zhí)行結(jié)果。比起之前很痛苦的分人，針對每個長流程來寫腳本，我們工作長流程的自動化實(shí)現(xiàn)就這么自然簡單地實(shí)現(xiàn)了。當(dāng)然我們的這個自動化運(yùn)維平臺里還有很多其它功能，包括自動化巡檢、自動化安裝部署等等，有興趣的歡迎在本文微信評論區(qū)留言咨詢。規(guī)范的迭代完善隨著規(guī)范的平臺化落地后， DBA在整個規(guī)范建設(shè)階段里面其實(shí)也有著不同的感知，這里的ABCD分別對應(yīng)了規(guī)范的四個階段：階段A：早期規(guī)范形成（規(guī)范丟失較嚴(yán)重）常常會有終端用戶來問：為什么這兩個系統(tǒng)的性能參數(shù)不同呢？這個時(shí)期，運(yùn)維人員：我們需要規(guī)范，將參數(shù)標(biāo)準(zhǔn)化。階段B：