高效運維--數據庫坐而論道活動

高效運維--數據庫坐而論道活動

 

我我的對這5個答案的簡單整理，詳細內容請關注高效運維的微信公衆號

 

一、如何看待DaaS（數據即服務）？DaaS有哪些要素構成？你認爲目前實踐較好的公司有哪些，爲何？

 

你們對於耳熟能詳的IaaS和PaaS都很是的瞭解和熟悉了，而且對於這2個名詞的定義也不會有太多的分歧，可是對於DaaS有些人可能會解釋爲Data as a Service，也有些人會解釋爲Database as a Service，不過我想小軍要問的確定是Data as a Service。

 

如何看待DaaS，網上一般的解釋以下：「數據即服務是指與數據相關的任何服務都可以發生在一個集中化的位置，如聚合、數據質量管理、數據清洗等，而後再將數據提供給不一樣的系統和用戶，而無須再考慮這些數據來自於那些數據源。」我的認爲DaaS應該相似一個海鮮超市，在這個超市中應該有各類各樣的數據，好比金融、通信、用戶行爲、消費記錄等等。而後用戶會指定要那些數據，就如同將不一樣的海鮮放到購物車中，最終將選定的這些海鮮拿到加工店根據用戶的喜愛將這些海鮮（也就是數據）作成一桌子菜。

 

最終這一桌子菜纔是用戶真正想要的。而一個DaaS平臺要能實現以上這些功能，那麼就須要有以下幾個要素

• 數據採集：一個超市總歸是物品種類越多越好，因此數據種類也是越多越好
• 數據治理和標準化：不是全部數據都是好數據，因此要創建標準化便於准入和存儲
• 數據聚合：這裏會是最大的差別點，就如同一樣的食材給不一樣的大廚作會出來不一樣的味道，因此差別化競爭應該在這裏更多的體現。
• 數據服務展現：最後，展現環節就如同上菜，中國人對吃仍是講究色香味的。

 

最後這個問題，我還真回答不上來，可是我認爲較好的實踐必定會出如今天生擁有數據的那些公司，好比BAT，華爲，京東，美團等等，由於我的認爲整套DaaS最難的地方就是最開始的地方，擁有足夠多足夠多樣的數據才能保持領先優點。

 

 

二、關係型數據庫如何應對雲時代的彈性伸縮挑戰？

 

隨着docker等容器技術的普及，如今前端應用服務能夠很是簡單的就彈起來，可是關係型數據要想彈起來，或者在具體點說MySQL若是想要彈起來就不那麼簡單了。

 

首先咱們能夠看下若是MySQL須要彈性伸縮都須要那些必要要素？

 

• 容量管理系統：咱們須要知道在何時須要伸，何時縮。
• 資源管理系統：咱們須要知道那些資源是可用的。
• 擴容遷移系統：自動完成數據的拷貝遷移和訪問上線。

 

     以及和一些周邊的好比監控、配管、安全審計等系統的聯動。

 

     在這其中，最簡單的就是擴容系統，由於這個徹底是標準化和流程化的，可是也是最難優化的，由於大部分時候遷移所需的時間都是由數據的容量決定，是最難節省下來的。

     其次，就是資源管理系統，只要作好信息採集並配合好資源隔離，那麼在設定必定的規則就能夠完成對資源的管理，以及推薦，也就解決了往哪裏擴的問題。

     最後，最複雜的其實就是容量管理系統，想要準確的計算出在那個時間節點須要擴容或者縮容須要基於時間線的各類分析。最簡單就是環比和同比，複雜的計算方法就各顯神通了。

 

     最最後，我的認爲相對於如今比較成熟的前端的彈性伸縮，數據庫的彈性伸縮的目標不該該放在解決業務瞬時峯值上面，由於相對於前端來講數據庫的擴容所需的時間較長，極可能在擴容完畢以後峯值已通過去了。而數據庫的彈性伸縮更大價值應該在對資源的充分利用上。

 

三、異地多數據中心的數據同步有幾種方式，各有哪些優缺點，哪一類更適合互聯網金融業務？傳統數據庫是否適應和知足了互聯網金融業務的要求，還有哪些改進的地方？

 

     異地多數據中心其實作的最好是銀行，惋惜銀行貌似歷來沒有出來分享過。目前我記得在網絡上有過度享的阿里的異地雙活數據同步基礎設施DRC，另外微博其實也實現了異地機房的雙活。

     對於異地的數據同步有以下幾種：

• 第一種，最簡單的就是直接使用數據庫自身的同步機制，優勢就是比較好部署，可是缺點就是隻能在一地寫入。
• 第二種，就是本身實現數據庫的複製，經過讀取source DB將數據同步到異地的數據庫中，好處就是實現了雙向複製能夠支持多地寫入，可是缺點異地的數據庫會存在必定的時延，畢竟須要先讀取後同步。（阿里的DRC相似這種）
• 第三種，本身實現一個消息中心，異地的寫入都先寫入消息中心，而後由消息中心把數據分發到各個數據中心，在寫入到數據庫中。優勢就是配置比較靈活，由於消息層和數據庫層其實解耦了，缺點就是依然仍是存在延遲，異地的數據庫無法徹底實現同步寫入。（微博的WMB相似這種）

 

     我的認爲第二種方式更適合互聯網金融業務，由於金融類的業務更加註重數據的安全性和一致性，先成功寫入一個數據庫後在同步到異地能夠避免不少問題，好比回滾等。

 

     最後，不得不吐槽一下，異地多數據中心的同步問題跟重要的是網絡問題，微博就曾近悲催的一年被挖斷專線4次+，什麼技術在挖掘機前面都是紙老虎。

 

      

 

四、傳統行業DBA和互聯網DBA的有哪些區別？互聯網DBA是否要投入更多的精力到工具和建設中，若是是，DBA和運維開發職業有什麼區別？從一個DBA成長爲CTO須要提高哪些方面硬實力和軟實力？

 

     對於傳統行業的DBA和互聯網DBA以前區別，我的認爲更多的實際上是由各自的業務形態決定的，即時互聯網行業，金融、社交、遊戲等行業也是區別挺大的。

 

     我的認爲互聯網的DBA應該投入更多的精力到工具的開發和自動化系統的建設中，相對傳統行業來講，互聯網的節奏要快不少，這也就意味着需求多、快、雜，爲了應對這些需求，純靠人力是不可能知足業務高速增加的，因此必定要投入更多的精力。

     而一旦工具文化和自動化系統造成必定的規模，就會進入一個正循環中，即自動化提供效率，工程師有更多的時間去開發新的自動化系統，而後時間進一步釋放，最終會就能夠實現用極少數的人就能夠運維支持海量的服務，並能保證一個較高的服務水平。可是若是沒有造成這個正向的循環，就會陷入沒人開發自動化 —》 用人力堆 —》更加沒人開發 —》 用更多的人 這個惡性循環中，借用@田國的運維2.0的思想，這不是人性的運維，由於沒有幸福感。

     可是關鍵就是造成規模和效益，有時候一些「自動化」系統反而是下降效率的罪魁禍首，就如同有些流程其實並不能讓事情「順」起來同樣。其實最關鍵的就在於分析目前最浪費人力，最機械的勞動是什麼，而後集中解決No.1問題，每次如此，慢慢的就會造成效益了。我的雖然不反對作總體規劃，可是也不建議什麼都設計好了在開工，不少時候等都設計好了的時候需求已經變化了，互聯網公司即時是內部項目頁能夠秉承快速試錯的思路，慢慢的造成本身的體系。

     而如今流行的DevOps，我我的認爲這並非一種職位，而是一種思路，能夠應用到各個領域，和DBA並不衝突，並且我我的一貫認爲，運維的自動化系統必定要一線運維的人蔘與設計和開發，由於做爲需求提出者和使用者最清楚想要解決什麼樣子的問題，並且，在系統出現問題和變化的時候，因爲是直接利益關聯方，不會出現「排期」「優先級」等問題，便於快速的對系統進行修正。

 

     最後一個問題因爲我我的離着CTO還有九九八十一難那麼遠，實在不知道怎麼回答，可是從我我的同一些高level的技術人接觸來講，並不都是技術上的「完人」，更多的感受反而是比較容易溝通，視野很大，方向感很強，因此我的覺得溝通能力，大局觀，情商，堅韌的性格，這些軟實例應該反而更重要一些。至於技術，用技術人常說的一句話來講就是「技術上的問題都不是問題」最後都能解決，由於大部分狀況下，都沒用到須要拼天賦，拼智商的狀況，只要足夠努力就能夠了。

 

五、在雲數據庫運維中，每每是數據庫研發團隊主導了性能優化和特性開發，DBA的傳統職能被削弱，DBA將來的方向該如何選擇？如何體現專業深度？

 

     如今的雲愈來愈接地氣，因爲雲平臺的不斷完善，確實DBA的一些平常工做已經被machina取代了，從某個角度來講，這確實意味着DBA的傳統生存空間在縮小。可是，達爾文的物競天擇，適者生存的理論在任什麼時候代任何場景下都是適用的，既然如今雲是一個沒法改變的大趨勢，那麼就只能順勢而爲，任何妄圖螳臂當車，改變歷史車輪前進的行爲都不會有一個好的結果。因此咱們須要作的事情就是尋找新的生存立足點，從新定義DBA的解釋。

     對於DBA的將來方向，傳統的運維DBA的地位確定會被各類RDS弱化，因此發展方向無非有三種：

 

• 往前，貼近業務
• 日後，貼近源碼
• 轉身，變成雲DBA

 

     分開說一下，轉身比較好理解，RDS在萬能也是須要有人開發和維護的，而這就是機會，只不過雲DBA須要掌握更多的開發技巧以及面對很是多元化的問題（畢竟是面向整個社會提供服務了，不僅是自家的業務），這種改變對於DBA來講相對少一些，也容易一些，可是這依託於公司，若是你不是雲公司的DBA，那。。。我不是要忽悠你跳槽。

     日後，貼近源碼，大部分公司都是使用開源的數據庫，開源軟件的好處就是你們均可以用社區很活躍，缺點就是太過於重視通用性，並不見得契合各家本身的業務場景，這時候就須要系統開發類的DBA了，針對實際的場景和問題去對應的進行源碼修改。只不過這種改變，對於DBA的技術能力，尤爲是編程能力要求很高，且若是沒有一個好的環境和導師，比較難入門，成功的概率相對小一些。

     最後就是往前貼近業務，這也是我我的認爲大部分DBA比較好的一個轉變，目前據我我的瞭解大部分DBA每每都是在業務的後期纔會接到需求，而且這些需求都是較爲明確的，好比用什麼軟件，建幾個表，每一個表什麼結構。而我我的認爲目前數據庫領域算是百花爭鳴，這種各類的數據庫層出不從，每種數據庫都會有各自擅長的領域，並非全部業務都放在MySQL就慢，也並非全部業務都堆在Redis上就能快的，確定有最適合業務場景的存儲選型方案，而這就是DBA的機遇。相對於開發人員來講，咱們DBA應該更加了解各個存儲方案的優缺點和適用場景，更應該在項目之初就參與到項目的設計中，去掌控存儲選型的發言權，從cache到db，給出較優的架構設計方案，甚至是庫表結構的設計。

     而向業務層靠近我認爲也是體現DBA專業深度的一個方面，並非必定要show一下數據庫的源碼或者path，我的認爲只有設計一套存儲方案，保障高可用，高性能，可擴展，低成本，業務意外的突增以後，咱們還能將服務水平維持在一個較高的水位，且不用咱們投入太多的精力，這才能體現咱們的專業性。

     最後，在說一下研發團隊占主導地位這個事情，雖然如今社會已經不是像武俠小說中那樣，誰拳頭大就聽誰的。可是在技術這個圈子裏面，依然仍是誰能解決問題，誰就會更加的有影響力，從這個角度說，研發團隊占主導地位是一個沒法規避的現象，畢竟不少問題只能經過path等方法解決，可是我的認爲沒有必要去想着解決這個問題，條條大路通羅馬，若是是做爲運維團隊，應該和研發團隊有機的組成一個總體，互相利用對方的優點解決問題，畢竟是焦不離孟孟不離焦的事情，缺了誰都玩不下去。