前言：自從上一次公眾號更新“網際網路運維新時代”文章後已經快一個月了，其中文中也提到新一代運維必須迎合’DevOps’，而’DevOps’在企業內部的成功實施也會取決於三個要素：理念＋自動化工具＋人。前兩者比較好理解，無非就是想法與工具實踐，而整個環節中最重要的應該是人，在這個過程中，究竟需要怎樣的人以及如何實施，才能最終將DevOps理念所倡導的文化實施到自動化工具中，所以人(Opser)才是運維開發一體化成功的決定性因素。而人其實是三個要素中最難搞明白的，不像理念和自動化工具，認真讀幾本相關的書就可以大概懂產品要如何做，最終做成怎樣。在人這個環節，我們需要考慮更多，包括業務架構設計，IT基礎架構設計，流程管控，風險管控，個人目標以及時間管理等等。這個過程中的確是很耗費腦細胞的，我不得不承認，去思考一個工程或者想辦法優化工程體系遠遠比單純碼程式碼要複雜和難的多。
(另外，以後我會把程式碼相關的實踐釋出在簡書或者開源中國部落格上，而公眾號上會分享更多理論以及想法之類的東西)

工作中的思考

其實我個人挺懶的，雖然在JDJR這兩年不論是在技術還是思路上我都學到很多東西，而且在別人說到相關的東西也立馬能夠心領神會(原諒前面有點誇張)，but，我仍然不能夠將自己熟悉的技術理論以及一些運維理念流程之類的東西很自然的結合到一個整體。我總結了下，原因是太懶，沒有將平時的所學所感所悟進行系統性梳理和結合。然而，任何事物，如果我們只是單純的去執行，不去思考深層次的東西或者站在工程學角度去系統思考的話，那麼最終我們也將會遇到瓶頸，而作為一個運維人來說，我覺得這點尤其重要。So,即使比coding難很多，我還是打算好好梳理下。

1.業務機房遷移

來PE(應用運維)團隊接觸的第一個大專案可以算是大規模業務專案機房遷移了。背景大概是由於網路架構改造，當時所有金融的線上業務都需要平滑遷移到另外一個機房。(沒辦法，趕上了移動網際網路的大浪潮，業務發展也是節節升高，考慮到未來的發展，網路架構調整實在是一個明智的規劃)。業務機房遷移其實說起來很好理解，簡單點說就是將業務遷移到另外一個機房的應用伺服器上去，然而操作起來並不是那麼簡單的，至於多複雜，很多辛酸淚就不說了，反正整個遷移從專案開始到最終結束大概經歷了一年半的時間，當然這些不是重點，重點是在這整個遷移過程中我學到了哪些，作為一個運維人(Opser)應該如何去支援並幫助應用業務專案實現價值。

• 熟悉運維架構 
  這點其實是很重要的，因為你需要掌握公司體系內部的整個運維架構是怎樣的，用的基礎工具以及流程是怎樣的(從域名解析到vip到後端的軟負載甚至到一些基礎軟體設施)，這樣才能站在運維的角度去幫助業務研發進行上線部署以及後期運營。當然至於運維架構本身是否合理可靠，可以暫時不去考慮，放給更加專業的人去考量。
• 熟悉業務架構 
  在整個業務遷移初期其實挺蛋疼的，因為對業務架構不是很熟悉，不清楚每個業務系統的底層依賴以及周圍系統的呼叫依賴(可能因為人員流動，相應的研發也不一定特別清楚)，還有部分奇怪的專案會寫死ip去呼叫，或者去寫死hosts。這些都給當時的遷移造成很大的麻煩。後期，摸清套路後大家就都沒有那麼難受了。所以作為PE(應用運維)來說，熟悉業務架構會非常的重要，這樣可以結合底層運維架構以及業務架構對業務進行建議改造。說實話，整個遷移完成後對金融大部分的業務架構都比較熟悉，這也為後期的維護提供了很多的便利。
• 引導業務研發按照標準化流程走 
  遷移的另外一個好處就是可以重新梳理並統一部署標準化，在歷史的應用部署中往往會有目錄標準不統一，或者隨意修改系統檔案之類的變更，遷移的過程也是梳理並統一標準化的過程。
• 瞭解業務會使用到相關技術 
  畢竟我們這個工種也是技術序列，掌握運維相關技術架構是很重要的，但是適當瞭解並熟悉業務的相關技術也是必要的，比如說JVM調優，Tomcat配置優化等等，這樣才能做到業務研發與運維之間的正向反饋，互惠互利，並最終快速實現業務價值

2.分散式k/v儲存系統運維

基本上業務遷移專案快完結的時候就開始接手公司內部的分散式鍵/值儲存系統(主要是當時待遷移的業務屬於非標應用，研發部門遷移成本比較大，況且當時我們已經把遷移需要的準備工作都已完成，如果繼續將大部分精力投入該專案，時間成本以及精力成本將會很大)。公司上一代分散式鍵/值儲存系統是基於redis2.8使用一致性hash演算法構建的k/v儲存系統，在維護期間深入學習了redis相關的知識，包括各種使用場景的使用方式，troubleshooting，甚至底層系統的相關核心調優等工作(很遺憾的是redis的原始碼沒有看太多)。好的架構總是不斷演進而來的，redis3.0以前的版本是不支援叢集模式的，但是業界總是能搞出一些工具系統去支撐業務的高吞吐、高併發請求，實現分散式儲存，比如由Twtter開源的Twemproxy,豌豆莢開源Codis,搜狐視訊開源的CacheCloud。當然啦，使用外部代理的方式總會有些許問題，比如通過代理後的效能問題，資料一致性的問題等等(感覺自己說了一句廢話，因為沒有完美的解決方案，總會有些許問題的)，So,redis3+之後的版本增加了叢集模式(相當於在儲存層面多了一層slot用來進行資料管理，使用Raft協議來保持一致性)，而公司內部正好有大神在做基於redis3+ 的分散式彈性k/v儲存。由於老系統在金融業務使用過程中的種種弊端，最終通過綜合對比決定將目前業務在使用的redis叢集遷移到內部大神們構建的基於redis 3+的分散式彈性k/v儲存系統R2M上。(其實當時個人考慮最多的是運維成本，畢竟之前那種代理方式運維工具太不友好了，而redis cluster中內部集成了運維管理工具，再加上當時對比redis代理叢集模式和cluster叢集模式的效能測試並沒有發現什麼差異，就向領導申請將業務使用的redis遷移新叢集平臺上，主要是想在精神上有滿滿的支援)。緊接著就是持續了大半年的redis遷移，redis遷移不像業務應用遷移那樣，畢竟是用來存資料用的，秒級的失誤也是可能導致業務可用率下降的，當時遷移也是經常在半夜裡進行，不過後來隨著工具的完善以及經驗的豐富，遷移進度和遷移時間也都很隨意了(遷移這件事肯定不能隨意)，只要研發確定好時間隨時可以遷移，截至去年618(全職維護分散式k/v儲存R2M的最後一個月)，整個R2M平臺已經將大部分老系統的業務遷移過來，並承載了金融大部分的業務系統。在維護整個分散式k/v儲存系統期間其實也是我成長最快的階段，因為從開始的業務應用專案的維護到基礎平臺專案的維護過程中需要轉變和學習的東西還是蠻多的，個人總結大概以下幾點：

• 熟悉底層的基礎架構技術
  做基礎架構平臺的運維一定得對底層技術細節有一個深入的瞭解，雖然我們有專業的redis研究和平臺開發人員，但是作為開發和運維的紐帶角色－PE，我們必須對相關的技術細節有深入的瞭解，否則也不能為業務開發提供最快最高效的業務支援。
• 善於溝通 
  可能作為IT人大部分都是不善於溝通的，但是運維這個角色必須要學會與不同的人溝通(原諒我其實有些許的溝通障礙，不過在慢慢嘗試)，因為這樣你才能說服業務方去按照你的架構你的計劃去實施，從而實現讓運維和研發在某一個點上達成一致。
• 熟悉業務
  還是業務，如果說在在前期遷移業務應用的時候需要熟悉業務架構的話，那這個時候應該就是要熟悉業務細節了。業務研發在開發初期並不會考慮太多使用上的細節，然而我們需要考慮到整個系統的可用性，可靠性以及吞吐率等。比如在初期，總會有不明真相的業務研發在使用redis的時候會使用keys命令而導致redis堵塞，進而造成業務系統的高延遲，又或者存放一些本可以丟棄的資料，一直佔用物理資源。這些問題後期我們都會和業務去進行深入談判，並給出相應的解決方案，使之對業務系統進行改造。

3.Docker在業務場景中的使用

去年618結束之後，分散式k/v儲存系統R2M基本上已經可以平穩支撐各個業務系統，當然R2M平臺未來還是需要不斷改進的，包括業務支援，事實證明這大半年搞R2M那幫大神和當時我交接運維的那些同事都是相當牛逼的，我離開之後就去搞docker了，而他們在精細化運營的道路上一直探索著，並且穩定度過11.11和各個大促。
我開始搞docker是一個很機緣巧合的過程，618過後正值有個業務系統想嘗試使用docker的特性進行構建業務系統，雖然當時docker也炒的比較火，但是對於我們內部來說還是比較未知，比較新的一個東西。之後我便接下來這個專案去研究docker相關的技術，不可不說的是docker用於生產環境還是蠻複雜的，因為裡面需要考慮到很多相關的東西，包括底層作業系統，網路，docker的儲存驅動選型，資料卷儲存，容器的編排排程以及生命週期管理，監控以及日誌等等。另外一個要說的是，docker真的有多的優勢，在使用docker的同時一定要想清楚要解決什麼問題，結合業務場景去選擇docker的某一種技術選型，以業務支撐的角度去做docker選型而不是以docker技術本身去做技術選型。幸而那個業務比較簡單規模也比較小，基本上兩個月就上線了(雖然後期也不斷出現一些問題，但總是會有辦法去解決改造的)，後期就是正常的業務升級以及維護了。由於該專案比較特殊，當時無法使用我們生產的部署系統進行快速的變更管理，初期靠人工進行維護變更。然而後期在不斷的學習中引入的各種自動化工具進行變更管理。在負責整個業務專案中，相當於是從底層作業系統，到最上層的應用我都全部接手了一遍，說實話從底層完整的支撐一個業務系統讓我學到並且思考了更多的東西。

• 專案需求梳理 
  向上需要梳理業務系統的需求，調研相關的技術細節；向下需要梳理底層技術細節包括操縱系統版本，基礎網路配置需求，儲存相關需求等
• 部署規劃 
  部署生產環境就一定要標準化先行，這樣才能為之後的流程化，自動化做好鋪墊，包括應用程式碼放置目錄，基礎軟體包放置路徑，日誌以及資料目錄等
• 變更管理 
  專案初期使用人工進行多例項部署變更，但這種方式是很容易造成標準化缺失問題，後來嘗試在專案環境使用Ansible進行統一的變更管理，即使未來需要擴充套件docker的基本環境，也依然可以在很快時間內進行統一的配置變更管理
• 監控和報警 
  俗話說的好：無監控不線上，由於使用的是應用容器化，在監控方面，還是很受挑戰的，當時調研了很久，最終選擇了Telegraf+Influxdb+Grafana這一套進行基礎監控(遺憾的是效能監控目前還沒有找到合適方案)，報警由於也是比較特殊的點，臨時寫了小程式在伺服器上進行日誌分析，然後報警到郵箱。但其實在監控和報警這塊是可以做很多事的，業務場景比較單一，當前的解決方案還是可以滿足目前的需求的。
• 日誌 
  日誌也是docker容器使用中需要解決的一個問題，該專案中暫時沒有進行日誌相關的處理(心寒啊，沒有來得及去研究)。docker容器的日誌方案一些官方的建議是可以使用log-dirver將容器的標準輸出資料流直接傳送到遠端，然後進行日誌儲存以及分析。官方其實是支援很多中日誌驅動的：json-file,syslog,journald,gelf,fluentd,splunk等。雖然沒有在業務中嘗試這樣使用，但是在內部的docker映象倉庫harbor的使用過程中各個元件容器使用了syslog將其他容器的日誌進行統一的收集和處理，所以後期日誌這塊會去嘗試幾種解決方案

4.Docker相關的技術研究

現在，我依然負責部分的業務運維，上面那個docker專案我也依然在維護支援，但是目前更多的是研究docker相關的技術，也有其他團隊在一起努力做這件事，最終實現基於docker的CI/CD整個流程、基於docker的標準化應用支援(包括編排排程)、企業內部的多功能映象倉庫(App Store)。關於目前docker相關的一些感悟和思考，實在是太多了，也許等過一段時間再總結起來收穫會更多，因為整個過程中需要考慮和關注的點更多，我還在繼續前行，繼續努力探索，期待未來分享的那天。

文章來源微信公眾號：有逼格的Opser