嘉賓介紹

任明，中國卡廠技術委員會專家，信息總中心架構室負責人。高可用、問題、容量性能經理。運維架構師、布道師、企業講師。曾獲人民銀行科技發展一等獎。負責卡廠云平臺與運維平臺的建設。

熱愛純技術，從事過網絡協議開發、省級銀行數據大集中建設、卡廠二代系統建設、卡廠云計算系統建設，對運維技術與管理有十多年的深刻理解與掌握。

專注于數據中心架構、運維架構，云計算、自主開源以及DEVOPS在傳統企業的思考與實踐。

前言

大家好，我是任明。

很高興和大家做這次在線的分享交流。今天我要講的題目包括以下四個部分：

• 運維歷程
• 運維體系
• 運維思想
• 從運維到放棄

希望能對運維的小伙伴有所啟發和收獲。

先放一張圖說明幾個數字： 

 

 

• 交易量1億/日
• 核心系統10年無故障
• 核心系統五個9
• 異地切換100秒
• 10000個節點管理
• 3000交易TPS

運維歷程

階段1：菜鳥呱呱叫(before 2006) 

 

 

階段特點：

• 用啥學啥

需求：協議分析 圖形展現 組網

學習：使用fluke協議分析 tcp經典三卷 Java ccnp

需求：數據移植

學習：sql db2 jdbc infomix ds8000 shark b16

需求：系統部署 系統上線

學習：aix suse hacmp power/lpar shell ds8000 shark catalyst

需求：大小額、信貸系統、卡前置、支票影像

學習：sybase 、MQ 、cics tsm

為了實現一些明確的需求，而針對性的以自學為主的學習。基本什么監控、巡檢、備份、日常操作等均用shell+java編寫完成

• 單兵作戰

由于沒幾個人、且都是新手，因此基本靠自己測試、實驗。

且當時運維學習資源、溝通方式較匱乏。

加班是常態、熬夜是正常。

• 兩聯兩天

金融行業早一批的MA大牛黃埔軍校，現在銀行和很多集成商的專家和領導均出自那里。

• 管理員時代

似乎沒有運維這一說法，系統管理員、網管。也試著弄過許多證書DB2 AIX cate、CCNP、OCP、系統分析師、RHCE等。

階段2：運維在路上(2007-2011) 

 

 

 

 

 

階段特點：

1.專業分工

企業大了、管理分工細化了后，則更專注于偏系統的運維和部分應用運維，雖然可以更精細、系統的了解的系統性知識，但是也會造成全面性的缺失。

2.ITIL

在接觸ITIL之前，一直認為是一個高大上的東西，也深深的學習了一把，考了master的認證。鬼子對方法的總結確實很精細，然而在許多傳統企業落地的時候，確成了對人員的流程管控/記錄工具，而和技術本身關系很弱。

例如：CMDB 交流過許多銀行、保險、證券、航空、制造、物流、電力、煙草等企業，從沒有認為cmdb做的成功的，可見一斑。問題在于大家在做的時候還是為了ITIL而ITIL，并沒有去從實際的需求出發，進行自動化、便捷性的考慮，沒有從運維消費場景出發。

我開始負責公司的問題管理流程(含對生產問題的技術質量控制)、高可用流程(演練、故障模擬、測試方法、應急三板斧)、容量性能管理(容量模型、容量活動)、災備技術方案等。

3.培訓講師

一個偶然的機會，代替朋友去做了一次企業培訓(AIX)，便慢慢開始兼職做IT專業講師，為煙草、電力、銀行等進行一些培訓，主要為power aix db2 cics hacmp等。占用了機會所有業余時間，但是還是有收獲的：

• 準備課件能力(PPT、組織邏輯)
• 演講能力(反應、語言、表達)
• 備課可以讓自己的學習更鞏固
• money
• 了解了許多企業的運維技術及運維方式

4.產品為王

傳統企業的運維大多是靠購買產品的，無論是備份(tsm/nbu)、監控(tivoli/patrol)、測試(loadrunner、qtp)、os、db、middleware等全是購買商業產品，除了一些日常簡單運維用用shell以外。

階段3：山雨欲來云滿樓(after 2011) 

 

 

 

 

 

當我正在感嘆傳統的IT運維陷入平臺期的時候，變化就這么巧然而至了。上面是我當時在12年寫的一個云計算的內部技術宣導材料。

階段特點： 

 

 

1.開源自主

公司開始了開源自主的技術路線，對于一個大公司來說，技術戰略的明確是非常有用的，這樣不會產生由于自下而上的使用開源產品時候帶來的質疑和反對。大膽的去選擇、測試、試點就可以進行推廣了。Bind、haproxy、mysql、jboss、redis、memcached、zabbix、openstack逐步替代了原有的產品為王。 

 

 

這是我們當時依據業界的熱門技術進行的技術雷達分析。

2.云計算

這幾年搞IT的不說自己玩過云計算都不好意思和同行交流了。確實因為云計算和devops、開源等再次指明我在技術道路的前行之路。

十年前交流時說自己是搞AIX的，覺得很高大上，現在必須說自己是玩云/x86的。 

 

 

回顧三年半前的這個文，看來也并沒有猜錯。

3.Devops

開發和運維各進一步，解決原有的部門墻和責任問題，通過平臺、機制優化、技能強化共同為應用、業務、市場的快速變化負責。我們也根據這樣的變化衍生了“托管”、“聯合運營”的開發運維模式。 

 

 

這是我們今年的校園招聘JD，已經明顯的偏devops技能了。

4.傳統+互聯網 

 

 

 

 

隨著互聯網企業對傳統企業的業務“彎道超車”，卡廠也大量增加了許多面向持卡人及商戶的2b 2c的應用。銀聯錢包、互聯網在線、營銷活動等業務直接帶來更多的無法用以往的經驗進行處理的問題。

因此各種學習、交流、測試、問題處理又開始成了工作的重心。

同時由于卡廠這條路在傳統金融行業走的比較徹底(開源自主)，已經采用了大量的開源軟件在增量應用中

運維體系

1.運維技術框架

運維的道法術 

 

 

 

道：基礎的扎實學習很有用，在實際學習的使用，tcpip、算法、數據庫原理、操作系統原理等都是在實際使用時候才覺得很有用的東西。

術：基本的操作、命令、配置。

法：將測試、監控、容量、高可用、容災、安全、備份、自動化進行提煉、規范，進而平臺化，提升運維級別。

2.運維可用性 

運維的可用性從高可用、安全指標、性能容量指標、監控四個技術維度以及演練、應急三板斧兩個管理維度進行衡量。

高可用指標 

 

 

 

 

 

我們可以看到，通過對環境、網絡、存儲、服務器、數據庫、中間件、應用、安全、數據、災備全層面的可用性指標梳理，解決每一個可能發生風險的技術單點。

容量性能指標 

 

 

 

 

 

監控 

 

 

安全 

 

 

演練 

 

 

 

 

 

 

通過演練的全盤規劃，可以看見我們幾乎每天都有多個實戰演練在進行。

應急三板斧 

 

 

確保值班人員能明確、快速的進行故障的處理。

3.運維平臺 

 

 

 

 

 

 

 

 

運維理解

1.懂業務

必須要懂業務，否則你連應用發布干什么你都不知道、除了問題你只會打電話、語句慢了你不知道影響什么、營銷來了不知所措、你只能原地踏步

2.不停抽象

不斷去總結、抽象自己的工作和思考方式，“為什么要這么做”、“能不能做的更好”、“別人再怎么做”、“能不能推廣到別的地方”、“能不能更快、更好”……

3.不增值就自動化掉

OS安裝、was安裝、應用安裝、重建、自恢復，等所有不增值的重復勞動盡量想辦法自動化。

換個維度解決問題比死磕有效一百倍!

4.聽說讀寫

沒有聲音再好的戲也出不來。

學技術重要，然而隨著年齡、經驗、圈子的變化，聽說讀寫也非常重要。

經常總結自己的經驗、經常學習新的東西、測試并寫出來。

經常與人交流，交換大家的技術和想法。

“從運維到放棄”

每一件事都一樣，精力時間的分配決定了前行的遠度。 

 

 

Q&A

Q1：請問你們開始上docker了嗎?

A1：還在試點，主要是前端的jboss apache haproxy 以及mysql用來替代cgroup。

Q2： 請問這個圖是什么意思? 

 

 

A2：這是每個月實戰演練的次數。

Q3：你們有沒有打算把自己的安全整合成安全云模式?你對這塊怎么看?有什么架構設計?

A3：安全這塊還是以產品為主，如ips、堡壘機、防病毒等。現在在增加的是host ips，類似于云盾的模塊，但是并沒有計劃在入口做一個安全云集群。

Q4：見過很多高大上的架構，可卻不知道怎么去實現。請問什么樣的方式有助于更好地去實現?

A4：其實這個問題問應用架構師更好，但是一般通用回答如下：一是大系統小做，確定層級、框架、數據同步，還可用接口等關鍵方案后，逐步分析拆解、設計。二是根據業務特點，如后臺、前臺、2b、2c開確定技術需求。最終你會發現同樣技術需求的應用系統在設計完成后是一致的。

Q5：請問對于搞IT的軟件開發的，35歲以后有合適的出路嗎?做云計算的項目，停留在開發的層面，不知道后面的路怎么走合適。

A5：主要看你個人的發展了，你喜歡不喜歡開發。如果是則加強聽說讀寫和總結，經常與自己的上平下同事交流，與外部同行甚至跨行交流。如果不是那就轉產品、業務、市場、開發轉這些很有特效的。國內確實環境不好，尤其互聯網時代之后，前兩天去武大南大招聘，男孩子都是只愿意做開發的。因此后浪太多了，所以前浪們只好利用優勢和經驗，去慢慢布道后浪。

Q6：有把Oracle真做成云的嗎?

A6：云計算的開發很熱門，我們現在就很需要云計算開發和運維開發，專注做下去非常搶手的。不過oracle db2還做云干什么，有點悖論的感覺，除非量非常大，自主化需求頻繁。