本文由 dbaplus 社羣授權轉載。
如果你要我用一個字來形容初次接觸災備建設的感受，那就是：悶。不像在搞定高併發大流量優化後，帶給你的酣暢淋漓的感覺；做災備時的感受，猶如今天會場外天氣一般，讓人喘不過氣。但它不僅是運維最後一道防線，又是災難發生時的救命稻草，讓你不得不硬着頭皮去完成它。
我還清晰記得，領導給我災備建設任務時，第一個反應是：爲什麼是我？但在做了四年的災備建設後，突然感到災備建設是一件很有趣的事。
上週參加其他大會，陸金所分享他們的一鍵機房切換，4分03秒就完成機房主備切換。他們怎麼做到的？除開技術原因，他們在災備建設這件事情上進行了大量資源的投入，不管是人的資源還是機器的資源。
一、中小型企業如何進行災備建設
那麼中小型企業在極其有限的資源下該如何進行災備建設，怎麼讓災備建設能在可用性和成本之間求得一個平衡，是我接下來演講的主要內容。
先做個背景介紹，好買財富是專門做基金銷售的，並不是做P2P，因爲很多人聽到財富兩個字自然會往那個方向想。既然我們是跟基金相關，那我們受證監會的相關監管，兩地三中心就肯定逃不走，所以公司就會有這方面的訴求：把災備建好，並且保證災備是可用的。
在四年前，老闆讓我重建災備機房時，我最初的想法是：很簡單嘛，照着主機房原樣拷貝一份，應該很快就能把災備建設完成。然而，花了近一年的時間，才把第一個交易核心系統的災備建起來。
下圖是現實做災備建設過程中遇到的種種挑戰：RTO/PRO，數據同步、負載、切換模式、網絡互聯和第三方外聯等等。舉個例子：金融企業的第三方外聯，當前你的支付接入50家銀行，在災備建設時，這50家銀行需要再接入一遍，突然有家銀行告訴你：我同時只支持一個key，這意味着當災難發生的時候，要麼這家銀行就被我放棄掉，要麼人跑到主機房拔下key，再馬上打車到災備機房插上去才能用。
通過這個例子我發現，災備建設過程中是在梳理整個運維的核心點、痛點、難點，當你把這些理完，整個運維的水準也悄然提升。
下面是一個業務連續性管理的6R模型，爲什麼要提到這個模型？讓我們回到最初的目標，你會發現災備建設只是實現這個目標其中一環：業務連續性。
大家可以從圖中看到，災備建設基本處於第三或者第四個環節，每一個環節時間要求不同，我這邊摘錄了一本書上寫的時間供大家參考。
整個災備建設過程不斷前行中，隨着持續不斷的災備演練，恢復時間會在自動化工具的協助下不斷逼近極限，但是自動化的建設又是一個長期且需要大量投入的事情。
所以我們災備建設的思考邏輯是：在恢復時間和投入資源之間尋找一個平衡點。那誰是砝碼呢？RTO和RPO，當你期望多久能恢復，容忍多少數據損失，大體就能知道你的災備建設投入多少的資源。
二、運維自動化的作用
接下來就是今天的正題，從災備建設痛點着手，講清楚運維自動化的作用。
痛點一：原樣拷貝
第一個痛點，如果說主節點基建狀況就像圖中小昆蟲運送的東西一樣，那你在災備建設過程中，只是多幾個同樣的東西而已，並且災備機房越多，這狀況被複制的就越多，但人的資源不會相應增加，結果到最後把所有的運維小夥伴，甚至研發同學一起拖死，所以在災備建設過程中要以本地資源建設爲優先。
對於中小金融企業來說，本地應急資源建設也是災備的一環，你可以先做應用高可用、數據庫高可用、網絡冗餘、硬件冗餘等本地應急資源建設，這樣只要不是發生機房級別的災難，就能很快恢復正常運作。
那麼我們的經歷是怎麼樣的？我們分了三步走：
① 多虛擬化池
在2016年年底的時候已基本實現除數據庫外，其餘服務均虛擬化。但我們發現只有一個私有化虛擬池，這個池一但出狀況就會造成大面積問題，是一個巨大的隱患，所以我們把一個虛擬化池拆成多個虛擬化池。
② 去軟件單點
對於現代的互聯網化應用來說，軟件單點問題基本已不存在。但是要考慮到金融行業中不少軟件是第三方開發，在開發過程中並未考慮高可用，那就需要你自己怎麼把外購的軟件也做成具備一定程度的高可用。
③ 互聯網入口多點接入
隨着整個災備建設推進，從原本單一機房線路接入，到現在三個不同機房的接入點，這三個接入點都是對外提供服務的，只要其中任何一個點出問題了，其他兩個點馬上就能頂上來提供對外服務。
痛點二：災備機房的可用性
第二個痛點，災備機房的可用性。一般我們在做主機房的時候會做的特別棒，但是回過頭來看看災備機房，我們會看到猶如還未學會走路的嬰兒般弱小的災備系統。當災難突然發生的時候，我們才發現災備機房根本就沒法正常對外提供服務。爲什麼？原因有很多種：你的主要精力沒在這兒，你的軟件未同步更新，甚至你的數據有可能也大幅落後。
怎麼辦呢？我們提出來的想法是：應用雙活。對於大公司，他們會選擇用戶體驗更加好的業務雙活。但對中小企業來說，沒有資源去實現業務雙活，那我們該怎麼辦？
可以先做應用雙活，把所有對於數據庫的讀寫均回到主機房，可能部分中間件的訪問也會回到主機房，而應用會在兩個機房同時承擔流量，只是備流量會比較小一些。
這是我們現在的做法，這張圖是借用自趙成老師的《進化》。
整體的結構如圖所示，真實的流量在生產環境，我們通過劫持辦公室DNS解析，將辦公室流量引至災備環境，應用更新會現在在災備環境當中進行，業務驗證通過之後再正式上產線。
這樣的好處是，比仿真更進一步，在仿真驗不出的業務性的流程，比如完整的走一次下單、撤單的流程，因爲中間涉及支付，往往在仿真環境中是驗不到的。我們現在的災備環境，其實就是生產，只是這個不對外開。當然因爲數據就是產線的真實數據，需要有預案來應對在驗證過程中萬一產生髒數據後的情況。
痛點三：度量
第三個痛點是制度流程上的：度量。不知道大家有多少人蔘與過災備演練，想想演練過程中的RTO和RPO是如何填寫的：很多銀行在做災備演練時，每人發一張紙，大家手填演練過程記錄，最後再把所有人紙收上去進行統計。
所以往往在做的過程中會遇到這些問題：比方說有些人隨便填一個數據，或者在演練過程中發生錯誤但不填寫。對於老闆來說沒有這些數據，不知道演練是否成功，爲了保證數據完備性，就要將演練數據填寫寫進KPI裏面。在KPI的壓力下，大家更容易選擇：老闆讓你填，我就填一個，KPI就到手了。
爲什麼產生這樣的情況？一是數據的生產者不會關心這些數據的價值在哪兒，演練成功與否跟我沒有太多關係，反而會比較關心不填寫所給帶來的收益或者懲罰，這就造成他有動機去隱瞞一些事實。
度量的意義大家很清楚，PDCA環也都耳熟能詳，就是想看一下現狀怎麼樣，我與目標的GAP有多大，原理很簡單，但落地卻有重重困難。
我們也在做度量，循序漸進：第一個，原來手工填寫改成探針式，由程序收集；第二個從KPI變成了OKR，爲什麼要OKR？先來看一個例子，這是今年我們運維定的一個OKR：應用雙活的方式重建災備環境，並完成災備提升。這是一個O，而O下面的KR可以不斷被調整的。有些人可能會問，你用了OKR，你怎麼考覈他？
我舉一個可能不那麼貼切的例子，假設你有一個女兒，你女兒已經6歲了，你天天“996”沒有時間跟她進行交流，你給自己定一個目標：我要在一個月裏面提升我跟女兒之間的親密程度。如果是KPI該怎麼寫？內容大體會是每天我跟女兒交流不少於半小時，每週跟她談一次心，每兩週帶她去玩一次。最後考評時，就看上述任務做沒做到位。
那換成OKR呢，會怎麼寫？KR的內容跟KPI相同，但不一樣的地方是每週你會覆盤一下KR完成情況，並判斷對O產生影響，比如你發現每天陪半小時沒什麼效果，一覆盤發現原來你雖然陪伴了，但是一直拿着手機。
通過覆盤，你就會把這個KR換成對O有幫助的其他KR。通過這種方式來提升整個度量的質量，能達到一個更好的效果。
痛點四：一年幹一次，一次幹一年
第四個痛點，災備往往是一年幹一次，一次幹一年。我在好買四年幹了三次災備建設，在整個災備建設過程中採用敏捷的方式，不斷交付價值，持續改進。採用這種方式，老闆能不斷看到階段成果，而且做事情的小夥伴的信心也會持續提高。
這個是我們的經歷，基本我們每年都有一定產出：
在2015年把交易核心部分進行重建，這時候伴隨着運維的工具我們做了哪些？第一個製品庫，第二個發佈工具。因爲我們覺得災備更新要有保障，不能靠人工操作，那就讓程序幫你。
到了2017、2018年的年初我們做了一次主備機房切換，這時候我們有很多準備工作要做，所以我們先做了一個事，配置版本化，保證兩邊推送的配置模版一致。第二個我們將部署動作做了工具化，使得災備應用搭建速度非常快。
這是2019年正在做的，災備機房要正式承擔一部分產線流量，所以我們做了兩個事，第一個資源數據的閉環，第二個發佈流水化。原來發布流程靠人驅動，現在由系統來指導你一步一步往下，保障你不會遺漏災備變更。CMDB是數據閉環的重要組成部分，原來由人保障的數據正確性，現在更多的是依賴流程來保障：機器從你申請開始，一直到你完成回收，都會在這個閉環中進行流轉。
最後是我們正在做的，當時運維內部提出了兩個要求：第一個配置模板化，第二個產線變更零SSH。相信大多數運維的同學喜歡通過SSH直接在產線做變更操作，在做完主機房變更之後，他很可能忘了災備機房也需要做同樣的變更操作。這就造成災備機房跑着跑着跟主機房越差越遠、做演練花一個月提前準備的主要原因。
三、思考與嘗試
不可變基礎設施的概念正好契合這兩個要求，而容器化將這個概念很好地落地：所有的變更都會通過鏡像進行變更，然後推送到各個環境，這樣就能保證整個環境的一致性。
目前我們在測試環境有一個研發團隊所有的測試環境都已經跑在容器環境中，我們用了這五個工具：Kubernetes、Docker、Harbor、Wayne、Jenkins，組成的工具鏈來支撐測試環境。
那效果如何？工具本身效率很好，但是使用者的體驗很差。爲什麼？因爲容器化後，改變了他們直接登錄測試環境機器操作的習慣，所有的變更均通過重新制作鏡像的方式進行，比如：配置沒有接到配置中心那隻能使用configmap或重打鏡像的方式，而我們對configmap進行了封裝，對操作人員來說，我只想改一行配置就要把前面的流程重新走一遍，即便執行是自動化的。
最後我們在思考災備建設未來使用容器的方式來替代虛擬機。
① 更快速的環境重建
一是因爲容器化能更快的把環境重建起來。比方說現在老闆跟你，我們要把機房從一個雲遷到另外一個雲，如果在容器化技術支撐的情況下，你的遷移速度就更加迅速一些；
② 更高效的資源使用
二是更高效的資源使用，運維往往就是一家企業的成本中心，災備建設爲什麼很多的公司不做？很多的金融公司不得不做？那是因爲對於資源的佔用非常的大，性價比不高，而今年基金信息技術管理辦法裏面更是要求災備機房的算力跟主機房是對等的，換句話主機房花了5000萬建成，災備機房基本需要再花5000萬，這對中小金融公司來說是個不小的負擔。通過容器化技術，外加依託雲的情況下，這個資源的使用會更有效，成本更低。
③ 更標準的環境管理
三是更標準的環境管理，所有的變更你不得不通過鏡像變更去完成，這樣會讓你的變更有跡可尋，同時容器使用起來非常方便，不用在意應用程序的環境是如何被初始化的，只要把鏡像運行起來就好了。
Q&A
Q1：剛纔您提到災備機房的請求，在災備機房可以連接到主機房，如果數據庫是單中心怎麼是災備呢？
A1：數據庫在災備機房以只讀的方式存在，通過常規的手段進行災備，比如主從，DG等，正常情況下不使用。
Q2：主備流量是通過DNS做的？
A2：我們只劫持辦公流量，外部流量主備線路的流量按比例分發，由我們前面用CDN供應商完成。
Q3：備機房到主機房有網絡帶寬的，專線可能會有擁堵。
A3：在主機房、備機房請求基本上是閉環的，只有一些要寫數據庫的操作纔回到主機房，如果不是大型的互聯網企業不會遇到這種問題，你的帶寬絕對夠。如果像我們這種金融企業流量一直比較平穩，當然我們也很希望金融突然有一次熱賣，那個時候帶寬不是問題，你要1G就給1G，10個G就給10個G。其實我們會從成本考慮，這根線路會盡量避免讀的操作，你可以通過監控會發現其實寫的量不是這麼大。
Q4：你剛纔說在災備環境下測試，如果把災備環境破壞了怎麼辦？
A4：流程上還是會先上仿真，但是它比面對最終外部用戶的生產事故好一些，因爲僅僅影響的是公司內部的用戶，很多補救措施實施起來也方便很多，壓力沒有那麼的大。
作者介紹：
岑崟，某fintech公司運維主管，負責應用運維，對DevOps抱有極大熱情。曾任好買財富系統運維部副總監，負責應用運維及DevOps運維平臺研發和運營，任職期間推動運維團隊從傳統的運維向DevOps轉變，帶領運維從只關注產線到服務“全環境”，深刻體會DevOps落地實踐中給運維帶來的笑與淚，品嚐行爲轉變到思想轉變的酸甜苦辣。
原文鏈接：