14年的蜕变：从菜鸟到卡厂运维总架构师
2016-04-28 15:26:00   来源：来源：DBAplus社群   评论：0 点击：

51CTO网+ 首届中国APP创新评选大赛>>

嘉宾介绍

任明，中国卡厂技术委员会专家，信息总中心架构室负责人。高可用、问题、容量性能经理。运维架构师、布道师、企业讲师。曾获人民银行科技发展一等奖。负责卡厂云平台与运维平台的建设。

热爱纯技术，从事过网络协议开发、省级银行数据大集中建设、卡厂二代系统建设、卡厂云计算系统建设，对运维技术与管理有十多年的深刻理解与掌握。

专注于数据中心架构、运维架构，云计算、自主开源以及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还做云干什么，有点悖论的感觉，除非量非常大，自主化需求频繁。

【编辑推荐】