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

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

  专注于数据中心架构、运维架构，云计算、自主开源以及DEVOPS在传统企业的思考与实践。

  为了实现一些明确的需求，而针对性的以自学为主的学习。基本什么监控、巡检、备份、日常操作等均用shell+java编写完成

  金融行业早一批的MA大牛黄埔军校，现在银行和很多集成商的专家和领导均出自那里。

  似乎没有运维这一说法，系统管理员、网管。也试着弄过许多证书DB2 AIX cate、CCNP、OCP、系统分析师、RHCE等。

  企业大了、管理分工细化了后，则更专注于偏系统的运维和部分应用运维，虽能更精细、系统的了解的系统性知识，但是也会造成全面性的缺失。

  在接触ITIL之前，一直认为是一个高大上的东西，也深深的学习了一把，考了master的认证。鬼子对方法的总结确实很精细，然而在许多传统企业落地的时候，确成了对人员的流程管控/记录工具，而和技术本身关系很弱。

  例如：CMDB 交流过许多银行、保险、证券、航空、制造、物流、电力、烟草等企业，从没有认为cmdb做的成功的，可见一斑。问题就在于大家在做的时候还是为了ITIL而ITIL，并没有去从实际的需求出发，进行自动化、便捷性的考虑，没有从运维消费场景出发。

  我开始负责公司的问题管理流程(含对生产问题的技术质量控制)、高可用流程(演练、故障模拟、测试方法、应急三板斧)、容量性能管理(容量模型、容量活动)、灾备技术方案等。

  一个偶然的机会，代替朋友去做了一次企业培训(AIX)，便慢慢开始兼职做IT专业讲师，为烟草、电力、银行等进行一些培训，主要为power aix db2 cics hacmp等。占用了机会所有业余时间，但是还是有收获的：

  当我正在感叹传统的IT运维陷入平台期的时候，变化就这么巧然而至了。上面是我当时在12年写的一个云计算的内部技术宣导材料。

  公司开始了开源自主的技术路线，对于一个大公司来说，技术战略的明确是很有用的，这样不会产生由于自下而上的使用开源产品时候带来的质疑和反对。大胆的去选择、测试、试点就能够直接进行推广了。Bind、haproxy、mysql、jboss、redis、memcached、zabbix、openstack逐步替代了原有的产品为王。

  这几年搞IT的不说自己玩过云计算都不好意思和同行交流了。确实因为云计算和devops、开源等再次指明我在技术道路的前行之路。

  十年前交流时说自己是搞AIX的，觉得很高大上，现在必须说自己是玩云/x86的。

  开发和运维各进一步，解决原有的部门墙和责任问题，通过平台、机制优化、技能强化共同为应用、业务、市场的快速变化负责。我们也根据这样的变化衍生了“托管”、“联合运营”的开发运维模式。

  随着互联网公司对传统企业的业务“弯道超车”，卡厂也大量增加了许多面向持卡人及商户的2b 2c的应用。银联钱包、互联网在线、营销活动等业务直接带来更多的无法用以往的经验做处理的问题。

  同时由于卡厂这条路在传统金融行业走的比较彻底(开源自主)，已经采用了大量的开源软件在增量应用中

  道：基础的扎实学习很有用，在实际学习的使用，tcpip、算法、数据库原理、操作系统原理等都是在实际使用时候才觉得很有用的东西。

  法：将测试、监控、容量、高可用、容灾、安全、备份、自动化进行提炼、规范，进而平台化，提升运维级别。

  运维的可用性从高可用、安全指标、性能容量指标、监控四个技术维度以及演练、应急三板斧两个管理维度进行衡量。

  我们能够正常的看到，通过对环境、网络、存储、服务器、数据库、中间件、应用、安全、数据、灾备全层面的可用性指标梳理，解决每一个有几率发生风险的技术单点。

  必须要懂业务，否则你连应用发布干什么你都不知道、除了问题你只会打电话、语句慢了你不知道影响什么、营销来了不知所措、你只能原地踏步

  不断去总结、抽象自己的工作和思考方式，“为何需要这么做”、“能不能做的更好”、“别人再怎么做”、“能不能推广到别的地方”、“能不能更快、更好”

  OS安装、was安装、应用安装、重建、自恢复，等所有不增值的重复劳动尽量想办法自动化。

  Q3：你们有没有打算把自己的安全整合成安全云模式?你对这块怎么看?有什么架构设计?

  A3：安全这块还是以产品为主，如ips、堡垒机、防病毒等。现在在增加的是host ips，类似于云盾的模块，但是并没有计划在入口做一个安全云集群。

  Q4：见过很多高大上的架构，可却不知道如何去实现。请问什么样的方式有助于更好地去实现?

  A4：其实这样的一个问题问应用架构师更好，但是一般通用回答如下：一是大系统小做，确定层级、框架、数据同步，还可用接口等关键方案后，逐步分析拆解、设计。二是依据业务特点，如后台、前台、2b、2c开确定技术需求。最终你会发现同样技术需求的应用系统在设计完成后是一致的。

  Q5：请问对于搞IT的软件开发的，35岁以后有合适的出路吗?做云计算的项目，停留在开发的层面，不知道后面的路怎么走合适。

  A5：主要看你个人的发展了，你喜欢不喜欢开发。如果是则加强听说读写和总结，经常与自己的上平下同事交流，与外部同行甚至跨行交流。如果不是那就转产品、业务、市场、开发转这些很有特效的。国内确实环境不好，尤其互联网时代之后，前两天去武大南大招聘，男孩子都是只愿意做开发的。因此后浪太多了，所以前浪们只好利用优势和经验，去慢慢布道后浪。

  Q6：有把Oracle线：云计算的开发很热门，我们现在就很需要云计算开发和运维开发，专注做下去非常抢手的。不过oracle db2还做云干什么，有点悖论的感觉，除非量非常大，自主化需求频繁。

  12月21日，由工信部信软司指导、ITSS分会承办的“中国IT服务运营大会”将在北京召开，届时将重磅发布中国IT服务工具图谱2018版IT服务运维工具功能全景图，颁发2018年度IT服务领域重要奖项，更有行业专家的技术分享与深度对话，全面开启从IT运维到IT运营的蜕变。近年来，随着云计算、大数据等热门技术的发展和普及，IT运维在企业中的受重视程度逐年提高...