作者介紹
孫志俊，新炬網絡資深數據庫工程師，超過5年數據庫運維經驗，服務于銀行、保險、電信、醫療等行業，擅長數據庫遷移升級、性能優化。
本文根據〖6月18日金融行業運維實踐沙龍〗孫志俊老師的現場演講內容整理而成。點擊文末【閱讀原文】還能下載PPT哦~
大家好，我是來自新炬網絡的孫志俊，今天給大家分享的主題是《金融業數據庫規范運維》。近年來，不少金融客戶和我們交流時都會問到數據庫的運維體系應該怎么去創建，他們知道要建設規范體系，但不知道具體有什么方法。對此，我把這幾年在金融駐場運維規范的建設做了一些總結，正好借著這次線下沙龍的機會拿出來分享一下，希望能對大家有所幫助。
1雙態運維，如何開展
什么是雙態運維？對于傳統金融業來說，就是在保證一貫強調的安全生產、穩定運行的基礎下，繼承互聯網高速迭代的更新速度，保證企業的信息建設思路既穩又敏。
去年曾聽過一個演講談到了雙態模式下的運維演進之路，分享者分享了如何去做，提出了運維的發展方向就是以ITIL理念為核心的穩態管理，同時使用的方式進行敏捷運維，實現敏態。
但是，以金融為代表的傳統行業都知道，對于整個IT中心的改動太大，很難完全。那么，在這種很難打破傳統壁壘的情況下，我們怎么去實現雙態運維呢？
回過頭來看看的思維：精益，價值，跨界，敏捷。下面我們就來聊聊如何通過抓住思維中的精益、價值、敏捷這三個思維要點，在盡量少的變動下，在保證穩態的同時實現這個敏態。
2運維對象&運維人員
IT的發展很快，我們的數據庫也跟著這張圖在企業內部飛速膨脹著。20多年前，我們維護的數據庫的數量僅幾套到10幾套，10多年前，維護的數量維持在幾十套。10年前的時候，數量開始逐步破百了。2年前，我們的一些金融客戶數據庫的數量破千了，到現在這些破千的企業，所有種類數據庫的數量基本維持在1500套上下。
互聯網里有個說法，數量在幾十套的時候，人肉運維對于企業來說，是最節省成本的方法，但當數以千計的運維對象存在時，我們需要更高效的方法去運維。這年頭其實關于運維提出了很多方法論，高效運維、白盒運維、精益運維等，說到底，需要靠我們的運維人員去執行。對于傳統金融來說，運維人員的心理就愈加重要了。這里以一個DBA團隊中工作了兩年左右的中堅力量小明進行舉例。
在一次偶然的機會下，小明見到了自己曾經的大學同學小剛，對方目前正在一家互聯網里做著DBA，同樣的工作，讓兩個人對于近況展開了討論，酒足飯飽，小明回憶著飯桌上的種種話題，不禁對未來感到了迷茫。
小明一直認為自己的薪水不高，每年漲幅也很低，小剛說自己從不擔心薪酬，每年漲薪都不會被遺忘，而且數量不低，當然如果公司沒倒閉的話。
小明覺得現在的通宵太多，常規情況下每周至少兩個，感覺太累。小剛說，通宵不算啥，補貼豐富。
同樣的活，干了兩年的小明認可領導說的“穩定壓倒一切”思想，覺得目前的環境下已經沒有新技術的挑戰了，感覺著把IT從一個技術活，變成了體力活。而小剛在吹噓自己的技術博客中，又加了什麼新架構技術的使用。
晚上回家精疲力盡的小明，一直在想，自己之后的路在何方。睜眼仿佛看到了白天領導提的，兩年滿三年就可以升級了。閉眼卻又想起了同學在旁邊吹噓，別看現在我是一線民工，等我這兩年積累好了，我就是某創業公司首席技術官。
酬薪，強度，內容，前景，這四個我們大部分在社會上拼搏了四五年內的人最關注的，也是最決定人才去留的四個點，而這批人也往往是團隊中的中堅力量，在傳統和互聯網的博弈下，這兩年傳統金融的員工流向各種互聯網金融非常多。
在運維對象數量劇增的當下，我們的人員替換永遠比人員養成的速度要快。做運維久了，有時候挺感嘆，如果現在的團隊里面，誰誰誰還在打造一只全明星團隊多好。對于我們運維的對象數據庫來說，我們配置了容災，但是運維人員的容災缺青黃不接，人員替換永遠快于人才養成。那么，在庫那么多、人員流失又那么重的當下，我們怎么去把握精益，價值，敏捷這三個點呢？
3從運維到運營
有一句俗話說得好，思路決定高度，去年運維圈里提出了個概念——從運維到運營。其實說的就是關注點前移，將運維對象從庫提升為人，化被動為主動等。但是對于DBA來說，IT運營的終極目標：簡單來說就是不僅活著，更要活得好。
那么做運維的，如何實現運營到運維的轉變？反過來逆推一下，我們作為企業的員工，要想活得好，企業要做得好，在這個信息化時代，就務必要跟上時代的腳步，企業IT就必須要加速變化。而對于金融IT來說，無論怎么快，安全生產、穩定運行是第一要素。
這是前面說的雙態運維的理念，但它靠什么來落地？清晰明確的流程，簡潔明了的步驟，不怕斷檔的團隊，三者融合，確保了在將價值導向的同時確保工作的精益，并且實現我們的敏捷運維，而這一切的基礎，在于規范。這張圖，從下往上，其實就是借著規范，通過一個個里程碑，而從運維走向運營的道路。
4規范建設指南
做規范，相信也是讓很多朋友頭疼的一件事。規范這玩意，由無數大大小小的文檔組成，牽扯面之廣，往往讓我們一些剛起步的企業不知道從哪個方向入手。而且傳統企業IT系統越建越多，多而雜，各種各樣的技術規范都可能有，非常亂，這樣造成IT運維支持比較困難。
差不多6、7年前，在運維規范不成體系時，我們需要去裝一個庫，因為找不到安裝文檔數據庫可用性設計，所以去網上下了份。對于初創企業來說，有問題問百度，解決了就行。但對于大型金融業來說，這里面有著很大的隱患。
我這邊結合這幾年的運維經驗，梳理了一下我們規范建設的思路。規范有兩個重要的特性：工作手冊的總綱，團隊傳承媒介。將這兩個特性深挖展開就是我認為規范建設的思路：工作流和信息流。
5工作流建設方向指引
首先說說工作流。建設的時候，我們從設置流程大類、流程子類、技術分類、SOP手冊這四個緯度逐步細化進行建設。流程大類包含五個緯度：變更操作、告警處理、值班巡檢、性能優化、應急預案。
其中前三項各個企業都是按照流程的不同，內容肯定也不一樣。第四項性能優化就比較偏技術層了，屬于一種可以拿出來交流的通用性流程。第五項應急預案，在最開始的時候是幾乎沒有的，但無數血淚的教訓告訴我們設立應急預案的重要性，于是也加了上去。
各自的流程子類如圖：
接著就是根據各項子類，在根據相關的技術進行細分，比如說像遷移升級： XTTS升級、 DG切換遷移或者其它數據庫 hdr切換遷移、 RSS切換遷移等，根據使用的技術不同，以及數據庫類型不同再進行的細分。最后再落地到sop標準流程執行手冊。SOP里肯定包含了基本上所有的執行步驟、腳本，寫SOP的這個過程，其實也是一步步將規范腳本化的過程。
6工作流建設的突破點
這邊列舉了三個最主要的問題：
這個時間是非常痛苦的，窮則思變。我們就想了一個辦法，一個字——拆，針對不同場景的復雜步驟，將它分割成一個個原子步驟。當然不是所有類別都可以這么做的，但是我們發現其實大概90%的操作都是能拆的。
舉一個 DG切換的案例。常規的DG切換，肯定不是這樣切的，有的步驟，但是這個操作我們是不做的，它里面存在著未知，我們不敢做。在常規DG切換中，這個操作有無法把控的風險，主庫切換為備庫無法切換回去，怎么辦？我們把切換的步驟變為，從主庫這邊直接將在線redo和控制文件通通拷貝到備庫進行啟動的方式。
這樣一個操作，我們切分成了13個原子型操作。這其中，對于物理文件的備份，都是可以復用的；減少標準操作的復雜性，讓每個原子標準都可以被復用，是我們做原子化標準的目的；將同一個變更中不相關的操作進行分離是我們的分割標準。
剛開始，我們是針對變更操作入手開始進行原子化標準建設，后面逐漸發現，分割出來的原子化標準很多。我們擁有了一個原子庫，這個和我們的函數庫其實類似。原子庫中的規范呢，在根據不同的技術和平臺進行分類。再然后我們發現這些原子化標準，慢慢的，可以輻射到其它流程大類里面的操作。
就像PDCA戴明環一樣，不斷地推動工作流的建設，整個標準原子化操作成為了整個工作流建設的突破點。差不多一年多的時間，我們60%的SOP可以在原子標準的基礎上結合而成。
7信息的歸檔
工作流基本上就講到這里了，下面來談談信息流規范的建設。
什么是信息流？字面意思，我要把我知道的告訴你，這個過程就是信息流。信息流建設可以分為三塊，信息的歸檔記錄、信息的溝通，信息的升級。
企業的信息庫一般由事件庫、告警庫、變更庫組成，企業基本都有自己的內部管理平臺，這些平臺的覆蓋面很廣泛，基本上所有的重要事件都會通過平臺中的事件、變更、告警保留下來，以供追溯。
但對于可用性事件，我們拿故障來說，它可能是由1個告警而被發現，幾個事件被其他部門察覺，再借由幾個變更進行解決的。
對于傳統的ITSM來說，信息存放太碎。很明顯，這些信息的傳遞溝通，并不是需要我們這些團隊中的老員工，靠記憶來硬剛，也不是在各種碎片信息中去拼接，而是需要靠著曾經完整的記錄來追溯的。
所以這邊我給出了兩條魚，目前為止我們認為需要額外記錄的信息庫：包括可用性事件庫和Bug庫。兩根魚骨頭，表示了需要記錄的點。我們做DBA的，其實無所謂甲方還是乙方，都是做運維服務的，企業本身其實就是一個很好的案例來源，我們是需要從歷史教訓中學習前進的，總不能一個問題一年前發生過，換了一波人，又踩一次坑。
8信息的溝通
在你的企業內部，溝通方式有哪些？微信？釘釘？企業內部通信工具？郵件？手機？
這么多的聯系方式，卻還是帶來一個問題，部門同事間的歷史信息不對等。我們發現一個部門里某個同事他不知道某件事，很大的概率在于，他的確是不知道這件事，而不是他忘了這件事。于是我們針對任何團隊里任一位同事都分配了為期四周的一個工作計劃，每周一個任務。
第一周，熟悉環境，他需要知道哪些庫是重要的，哪些平臺是給他工作的，誰是他的領導，哪些是禁止項等。
第二周，安裝部署，我們企業有很多的庫，很多種類的技術，但是變更也好，告警也好，他們都離不開一點，我們一開始安裝部署的標準項，第二周的任務是安裝部署，去熟悉這些標準項。
第三周，基礎技術，我們每個人進來可能是高技能的，也可能是低技能的，但是不重要，第三周就是讓你掌握有哪些基礎技術是你在80%的工作里面需要用到的。
我這邊截取了，目前我們團隊在MySQL方面做的一個新人入職前四周的一個學習計劃，通過我們的學習概要，內容細分，學習文檔，來讓這個新人員入職流程切實可行，而不僅僅只是一個高高在上的規范。
第四周，流程實戰，跟隨我們的老員工，把重要的流程走一遍。通常我們大型企業對于新員工都是有一個考核制度才能上生產進行操作，那第四周終極目標考核。
大家可以看到，這套規范其實對于一個老DBA來說，僅僅是加速對工作的上手速度，但是對于一個新人來說，短短兩個月，他就可以讓一個初出茅廬的新人，成為一個知其然不知其所以然的偽中級DBA。
9信息的升級
做運維時間久了，都說運維是個把腦袋別在他人褲腰帶上的活。我們遇到的問題往往不取決于自己，那么在這種某一天肯定會發生的意外情況下，該怎么去做好信息的升級？
我們這邊制定了三條紅線，其中一條就是關于問題的升級，根據我們服務的客戶不同的情況，這條紅線的落地也是不同的。我們在做金融運維時，把運維團隊分成了三個層次，值班崗、專家崗、遠端專家。通過分工，設立一二三線崗位，先把人力資源有效利用，避免高級人才在做一些繁重的體力活。那在不同的場景下，我們各崗位人員的職責是不同的。
這里我把運維問題分為了四個方面：常規事件處理（像清理以下表空間，刪下歸檔之類的）、異常問題處理（包含一些技術難度較高的工作，比如SQL性能低下，存儲過程某類語句問題緩慢等）、應急預案實施（當某些不可抗拒的事情發生后，我們是沒有回退方案的，這個時候就是應急預案的啟動了）、重大故障救援（這個是指某些第一次發生的，沒有應急預案的事件）。
而我們的本地專家和遠端專家呢，則以救援方案的制定為中心開展工作這是我們整個信息的升級機制，使各個崗位在不同情況下各司其職，而不是一擁而上去解決。
10規范的迭代完善
前面說了很多，我們的規范怎么去做，從工作流和信息流方面。那么寫過文檔的同學肯定知道，我們一般文檔都會從v1-v2-v3-v4慢慢迭代跟進。
運維規范同樣需要迭代去更新，簡單來說就是一點——利用好當前已有的東西，在體系大綱明確的基礎上去查缺補漏，這里梳理了六個方面：
但是有兩個注意點，這兩個注意點是曾經很長一段時間里，我們的痛：
做好版本控制
不要只增不減
不然的話，文檔的邏輯亂了的同時，我們的規范也就漸漸臃腫到無法看了。
另外，永遠要記住我們的SOP精髓：
工作手冊
傳承媒介
精簡而復用
11規范的階段總結
我們的服務團隊在為金融業服務時，這些運維規范建設，也經歷了不同的階段周期：
第一階段是地基階段，叫規范標準化：坦白來說，確定每個SOP規范的標準流程、標準操作、標準溝通。
第二個階段，規范腳本化：我們的目標是標準操作腳本化。但是在這個階段，我們遇到了兩個問題：簡單操作，因為環境往往不一致，導致了腳本化后不能復用；復雜操作數據庫可用性設計，又會導致我們的人力時間成本投入過高。所以對于這個階段，我們只有一個建議：不建議整體腳本化。千萬不要把一整件事，放在一個腳本里面去做。
也正是因為預計到了這些問題，我們經歷了第三個階段：規范原子化。通過拆拆拆的方式，將操作分解，操作腳本原子化，同時建立標準原子庫，便于后期操作的調用。
12規范原子化的平臺落地
到這步為止，其實我們都在做規范，雖然經歷了很多階段，用了很多方法，但是說白了，依然停留在文檔階段，穩是做到了，但是敏還差得很遠。很自然的，開始追求這些工作的平臺化落地。
這個是我們自己開發的自動化運維平臺對于運維規范的一些功能，當我們把大部分規范腳本原子化后，我們發現自動化成了一件很簡單的事，所需要去做的就是可以支持各類腳本的集中化管理、工作流程的編排、原子腳本的調用、以及去觀察每個腳本的執行結果。
比起之前很痛苦的分人，針對每個長流程來寫腳本，我們工作長流程的自動化實現就這么自然簡單地實現了。當然我們的這個自動化運維平臺里還有很多其它功能，包括自動化巡檢、自動化安裝部署等等，有興趣的歡迎在本文微信評論區留言咨詢。
13規范的迭代完善
隨著規范的平臺化落地后， DBA在整個規范建設階段里面其實也有著不同的感知，這里的ABCD分別對應了規范的四個階段：
在確保工作質量的同時，提升了工作的效率，還加速了人員的養成。
14自動化的極致——智能化運維
前幾年大家都在說自動化，那么自動化運維的極致是什么？這里截取了一段關于智能化運維的解釋：一個因應突發事件而彈性自伸縮、自愈、自適應的軟件系統，“自己運維自己”的“無人值守”運維。
這三個自是智能化運維的切入點，而我們目前也是從其中一點入手：從監控告警入手，先做自愈。左邊是我們傳統的告警處理、右邊是我們目前正要做到的。通過告警觸發我們的腳本調用，以達到自愈。
傳統的告警處理，主要靠7*24小時人工值守進行告警處理，一旦運維人員錯過了告警，本來有很簡單有效的運維操作沒有被執行，就可能導致系統故障。通過固化常見的故障處理方式，在收到告警時自動調用相關腳本處理告警，可以快速的消除系統隱患，降低業務風險。
當然這一點目前已經可以做到了，但是我們還沒有去做最后一步，僅僅是在告警的同時，生成可以去解決的腳本，還是需要人為的點擊去執行。原因在于追求穩妥，不過不管怎么說，這已經比當年一個個告警手動去做穩妥很多了。
15從運維走向運營
從運維走向運營是需要一個過程的，我們仍在這條路上，目前的成績：
將工作流，信息流實現了標準化；
將標準原子化推動了問題前進；
通過自動化實現了穩態和敏態；
通過智能化自愈將被動式運維轉化為主動式運營。
希望通過今天的分享，能讓一些boss級的企業呢，在回顧過去自動化創建的艱苦歷程時，會心一笑，也希望咱一些初創型的金融企業呢，知道原來規范可以這么建設與落地。
End.