前言
大家好，我是任明。
很高兴和大家做这次在线的分享交流。今天我要讲的题目包括以下四个部分：
运维历程
运维体系
运维思想
从运维到放弃
希望能对运维的小伙伴有所启发和收获。
先放一张图说明几个数字：
交易量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还做云干什么，有点悖论的感觉，除非量非常大，自主化需求频繁。
作者介绍 任明
中国卡厂技术委员会专家，信息总中心架构室负责人。高可用、问题、容量性能经理。运维架构师、布道师、企业讲师。曾获人民银行科技发展一等奖。负责卡厂云平台与运维平台的建设。
热爱纯技术，从事过网络协议开发、省级银行数据大集中建设、卡厂二代系统建设、卡厂云计算系统建设，对运维技术与管理有十多年的深刻理解与掌握。
专注于数据中心架构、运维架构，云计算、自主开源以及DEVOPS在传统企业的思考与实践。
本文来自云栖社区合作伙伴"DBAplus"，原文发布时间：2016-04-24
