应用运维为业务创造更多价值

白凡

分享：封铨贤
编辑：白凡

讲师介绍：在这个专场里面我达不到标准层次了，就只是想向大家分享一下我这么多年做运维经验 体会和思考，首先介绍一下我的题目，我叫封铨贤，来自中国民生银行，大概做运维也有差不多十来年的时间了，当然之前也有在外企的经历。

我今天选的题目叫做应用运维位业务创造更多价值，因为刚刚谈到有一些同学都是来自银行业的提问的同事，我选一个题目，因为我们在银行里面有一个职务叫应用运维，就像里面互联网老师说到的，运维是一个概念，包括咱们今天的专场里面说到技术运营，其实从很多内涵上，很多概念上，从我们具体大家做的事情上可能有80-90%是一样东西，但是从传统行业和金融行业角度运维怎么做，为什么有应用运维做这个事情，这个团队怎么位大家创造价值，这个就是我今天想给大家分享的，今天这个论坛里面，因为是DevOps高峰论坛，我就把应用运维这个词做了翻译叫BizOpS，就高大上了一点，从中文角度来说，开发运营一体化，DevOps他的体系里面可能中间应用运维只是其中一部分，所以还是看应用运维不看BizOpS，毕竟是技术运营的专场，准备PPT的时候，尽量向两位老师靠拢，因为咱们今天的论坛也叫做以标准运营，针对平时应用运维工作做了一些总结，也尽可能希望可以成体系减少我们在应用运维当中的一些体会和思考，也希望把我们工作当中遇到的好的想法分享给大家。

第一个部分基本理念，BizOpS的基本概念，把概念澄清了，要不然不能在相同语境之下，第二块介绍一下做应用运维有哪些关键的原则，这个是需要我们考虑的，第三点我们怎么样实践我们的应用运维的方法论和应用运维的理念呢？最后就是结合我们这些年在工作当中遇到的典型案例分享一下，应用运维怎么做的，总之今天就这个分享事实上是想给大家发出一个我们作为应用运维团队的声音，让大家知道我们有这么一群人做应用运维这个事情。

1. 应用运维的基本理念

大家看到BizOpS这个词的话，第一个感觉和DevOps是不是差不多，或者是不是把DevOps扩展到的业务领域，这里做了一个澄清，应用运维不是DevOps延伸到了业务开发运维一体化，不是延伸，不是BizOpS这是两个词，两个独立的概念，因为既然提出了BizOpS这个词的话，我觉得不管怎么样都要解释一下为什么叫这个词不在这个体系里面提这个，就先列出来最近几年看到了解到行业里面提出的DevOps相关的名词，因为DevOps今天上午分享里面提到DevOps现在有十年时间了。

首先就是业务，首先是把业务拉进来，就叫BizOpS，业务开发运维一体化，或者把BusDevOps加起来，另外一个关注安全的，今天大会也有这样的主题，就是专门讨论开发运维一体化当中安全领域的事情，有一个词安全开发运维一体化，但是这个特别有意思的是我还看到的另外一个词叫做开发安全运维一体化，第三个词叫开发运维安全一体化，这三个词顺序不一样，代表的含义是否一样呢？其实我研究不是很深，但是我个人感觉，这个和我们很多时候领导人的出场顺序，排序是很有关系的，谁先谁后是非常讲究的，把安全放在前面，是不是意味着我们在一个软件工程的实施过程当中，在设计阶段，计划阶段就要把安全纳进来，做好很多安全的考虑，把安全放在中间，开发安全运维一体化，是不是意味着一个软件工程项目的实施过程当中，我们的开发过程当中更强调我们的安全的实施的落地，比如我们的代码的扫描，编码的相关安全规范，这些也是我们需要考虑的，如果把安全这个词放在后面，从我们整个开发运维一体化的过程当中，这个软件工程的生命周期角度来说，是不是更强调的是我们一个应用程序头餐以后，上线以后的安全运营，怎么样在线上避免被攻击，这三个词也许是一个词，也许是三个词，但是代表的含义有可能不一样。

另外一个就是关注测试，关注测试的话，很简单，大家都知道，就是把QA加起来开发测试运维一体化，我们在软件工程当中测试也是必不可少一个团队。

对于这些这些名词，所以为什么提出来应用运维叫BizOpS概念呢？这里面对比一下DevOps，我说的这句话非常也争议的，我相信很多人包括很多专家觉得这句话部队，就是DevOps关注实施态，DevOps是一个闭环，怎么可以说他关注实施态，这个东西是相对的，从DevOps的官方教材里面摘出来了DevOps几个基本的要素，价值流强调DevOps价值流动，这个事实上就是一个软件工程实施过程当中最关注的东西，还有一个部署流水线，参加很多DevOps的材料，部署流水线是一个很重要的概念，这个其实也是关注的是实施工程，而不是上线之后运行的东西，怎么样提高效率，怎么样快速的投产，版本控制，版本控制也是我个人理解是在过程当中也是关注于怎么样投产，怎么样在软件生命周期开发过程当中怎么样控制质量，怎么样去控制我们的代码，还有自动化的配置管理，这一点实施态和运行态都涵盖着都有的东西，整体来讲，我个人的观点DevOps更关注实施态，关注内容更多一些，另外DevOps强调效率，大家说了很多DevOps，和敏捷绑在一起，很多时候前些年大家谈敏捷，这些年大家谈DevOps，所以有一个词叫持续集成，持续部署，持续交付这几个持续强调我们能够提高软件的效率，这个效率体现在哪几个方面呢？

一个方面参加很多活动分享的时候，有些专家也会说这个企业实施了落地的DevOps，弄了一个DevOps的平台，之后我的变更或者是说我发布的数量猛增，看到一个数字花了很漂亮的曲线图，一年发布几十次，去年一年发布了几百次，预计明年发布几十万次，另外用了DevOps实践落地之后，类似于用了敏捷方法论，原来可能一个项目的周期可能是半年，一年，我们用了DevOps整个方法论之后，两周就一个快速迭代，这个都是强调效果，今天分享这个话题就是说我们可能效率很重要，也很拥抱DevOps，觉得DevOps非常好，但是我们做运维的同学，大家知道，我们可能在运维这个角度来说，我们可能更关注的是另外一个东西，就是运行态的东西，这里给出一个应用运维的概念，也不能说定义，其实我觉得他的内涵和技术专场的主题很类似，今天我们在这里有这么一个部门，我也希望可以对做事情的一群人做一个树立和总结，我先把前面看到的DevOps展开了，把根据看到的那个展开之后可以看到，分位8个阶段，计划，编码，发布，部署，运维，监控，DevOps我们说是一个闭环，但是展开的话是一个应用程序的生命周期，但是都是做运维的，很多人属于数据中心，我们可能不是按照生命周期来的，我们是按照技术展的分成来的，包括机房，网络，服务器，操作系统，中间件，数据库，一个数据中心，不管是金融行业还是互联网行业有这样的运维专家团队，我可以说是网络运维，数据库的运维，DBA，我们这边是做应用的运维，那么这很直观的可以看到，应用运维就是应用程序的运维，就叫应用运维，但是为什么有这么一个结合，大家可以看到如果从开发团队角度，我一个项目组从前面计划，编码，构建，测试，发布，一直到部署，其实我大部分的时间没有和数据中心打交道的，从另外一个角度来说，我数据中心的计算资源只有当我数据投产之后才能用到，尤其现在这几年我们说云，都说虚拟化，现在云化之后包括容器技术，这些新的技术出来之后，数据库往下，中间件其实都可能是透明了，对于很多项目组透明了，对他们来说这个东西可能都只是计算资源，可以增加要多少内存，可以在线调配的，所以现在谈运维分成了两个，一个是技术的运维，一个是团队的运维。

刚才提到了DevOps关注实施态，我们做DevOps关注点不是完全匹配的，我们更关注的应该是运行态的东西，我列入了应用运维关注的三个点，或者三个部分，第一部分上线交付的过程，这个部分里面，应用运维团队和开发团队打交道承接应用程序的上线，第二部分业务运行的过程，这个过程当中，主要和数据中心的很多专业团队打交道，当然我们在云化之后可能对应用运维团队来说基本上透明了，我们和下面的同事基本上也是透明了，第三部分叫做优化反馈的过程，需要和业务部门打交道，现在感觉很多企业里面有很多人做到了A，做到A不是一个真正的运维团队，可能是开发团队里面负责上线支持的那一部分人员，也有人做到了A+B，其实是技术运维团队负责承接系统的投产和技术运维这样的应用运维团队和下面的技术展我们数据中心其他的专业话的运维专家团队没有区别，我们更关注的是C，就是怎么样从技术运维，应用运维角度和业务部门打交道，遇到各式各样问题，需要油画的地方和业务部门反馈，我们觉得只有做到A+B+C才是一个完整的应用运维.

刚才的ABC三块做一个展开，应用运维应该有6个环节的事情要做，这6个环节也是分三个部分，前两个环节，是上线准入的环节和变更实施的环节，上线准入位什么有一个准入的过程，就是我们说什么，就是一个项目组选择的平台，选择的技术，比如说选择的中间件的版本，数据库的版本是否符合我们数据中心生产运行的要求，这个不都是需要评估的，他上的业务，他上的业务是不是和线上的业务相匹配，这些也是需要评估的，包括安全性，容量性很多，上线就需要一个准入，还有另外配套的实施，投产这个过程，第二个环节就是上线之后我们会持续的迭代，持续的开发，投产，我们需要有一个变更的过程，这个叫变更评估委员会，我们可能有一个周期，任何上内容需要经过评审，觉得不影响生产安全稳定运行，有变更的必要，上线的必要才允许去做，第三个环节叫做运维工具体系的建设，和业务连续性的设计和理念，这两块就是刚才说的B的内容，业务运行过程当中的内容，分成两个部分，一个部分就是我们要建很多的工具，这也是现在几年大家推动DevOps落地的一个重要的方向，很多人甚至问，做DevOps做很多运维工具，但是不管怎么样，我们工具是必要的，工具不是万能的，但是没有工具是万万不能的，这里的供给包括了，我们的监控的工具，自动化的工具，还有现在流行的智能运维的工具很多，还有业务连续性的设计和演练，这点对于很多互联网的应用，还有金融行业的应用非常重要，就是我们的高可用怎么保证，这个高可用包括的服务器的应用同城的高可用，包括现在做的同城的双活，异地的多活。

另外两个环节就是和业务相关的，就是结合刚才的三个点，业务上我们要做两个事情，一个是系统和流程的应用分析的建议，我们总汇发现他很多并不是那么完美的地方，这些不完美的地方往往由我们应用运维人员发现的，我们发现之后怎么样把这些问题，需要优化的点反馈给业务部门，换句话说叫技术运营，往往来自于客户，或者来自于前台，各种业务部门有很多业务的问题，之后经过业务部门的梳理排查之后发现和技术相关的难题，我们需要用技术手段给他做分析和解决，这里面可能需要澄清，做应用运维的人并且不直接面对客户，但是很多客户的问题最终流转到我们这里，所以这个也是服务请求的问题处理也是我们很重要的内容。

刚才主持人说有书，提一个问题，大家感兴趣的话可以回答一下，这个问题很简单，但是感兴趣的可以举手。是否需要组建专业的应用运维团队？
提问：首先我说一下，我是做应用运维，所以我认为有必要组建专门的应用运维团队，我在做对应用运维理解的话，或者从整个公司价值来讲的话，最多能体现一个是稳定性，还有就是如何提高应用效率，业务部门的企业如果有专门运维团队的话，更多提到整个流水线一样，从我的开发，我的测试，最后的部署，通过我的运维工具做一个穿针引线，做到很多平台的效率上的提升，包括您刚才PPT里讲的，我在业务上，对我的业务系统的监控，业余系统一旦出现了什么样的一些问题，我通过一些业务指标，反过来对我的开发和业务运营也一个反馈，进行一个相应的比重，包括应用运维这个团队，传统意义上属于运维团队，包括效率团队也是可以的，是我的问题。

封铨贤：方便透露一下您是哪个单位的吗？
提问：还有一个专门线下的问题请教您，就是最近遇到一个很大的问题。
封铨贤：我们可以线下交流，我自己并没有给出答案，因为什么呢？也许有人觉得不需要，也许有人觉得需要，但是从我的经验来说，可能不同的行业不一样，那么金融行业可能很多公司我们可以把应用运维这个团队放在数据中心，这个是可能比较趋势容易理解地，但是也有一些公司把应用运维放到开发中心的一个上线，支持的团队里面把他做的很大，那种可能就觉得开发成绩谁负责，但是互联网的行业提到了，互联网行业运用反对分为两个部分，一个是业务运营，一个是技术运营，技术运营涵盖了我们应用运维的工作，所以这是不同行业不同的主题架构，不同企业可能对这种归属并不是那么统一，但是那个问题是开放性的，我自己给出了我自己的一些理解，就是应用运维可以解决很多问题，第一点这个问题叫做理想很丰富，现实很骨感，很多时候打拍脑袋拍不出好需求了，他离一线比较远，这种情况下，他提出一个新业务没有那么合理，那么这个时候，业务人员主动联系到我们的业务运维团队收集一些运行数据进行一些沟通，他提出来的需求更好一些。
第二点叫管生不管养，管杀不管埋，现在可能很多企业相信大家有这种感觉，IT系统越来越多，只看到系统不断的上线，从而没有看到系统不断的下线，如果我们业务部门没有业务部门控制这个事情，从IT部门角度谁去控制这个系统，我觉得这个时候其实应用运维这个团队应该站出来，去梳理这些系统做一个梳理。
第三个IT关注于技术，但是技术是要服务于业务的，从这个角度来讲，应用运维的适合，应用运维不仅仅关注于技术，因为我做的是应用系统的运维，应用的运维，更关注与业务，所以应用运维就是技术和业务的结合点，最后一个就是一个玩笑话，“好男人是调教出来的，好系统是运维出来的”我觉得我已经被调教了好多点，但是还没有被调教成好男人，但是作为一个运维的男人，我和我同事们努力调教出更多好系统，通过不断优化线上系统去把这个系统做好.

这个感觉有一个离子叫做系统上线可能对开发团队来说他就完成他的任务了，但是对于运维来说，长征路上的第一步，才对运维来说才是刚刚开始，这个就是这种感觉，刚刚开始就像另外一个比喻就像我们小孩儿刚刚出生一样，我们做运维可能就比较服务行业的小孩儿，要慢慢的去管理他的吃喝拉撒，慢慢陪伴他的成长，就是系统的感觉，之后给出一个例子就实际案例里面，应用运维应该是放在一个生产运营里面，他当中和开发部门测试部门有交付。

2. BizOps的关键原则

第二部分介绍一下我们做应用运维过程当中的总结出来的原则，这个叫做不是所有的Ops叫BizOpS，首先第一个原则运维从立项开始，交付从需求开始，这个挺好理解的，我们两个质量控制点，比如第一个控制点就是开发到测试的点，就相当于我开发东西完了进入测试阶段，另一个我测试也完成了要投产了，如果我们测试人员和我们的运维人员只关注这两个点的话，往往开发程序质量不会很高，我们平时实际例子就是这样，可能一个项目要上线，过来找我们的CAB，就是上线评审，发现很多问题，觉得项目开发过程当中没有考虑到，这个时候就会有一个妥协和谈判过程，这个东西没有办法做到，但是现在业务那边要求时间特别紧，这是一个重点项目，必须某个点上上线，这个时候叫待定上线，承诺上线之后多久之内根据要求做相应的改造和优化，这个是不好的，也会带来很多的DevOps角度来说叫技术栈，让运维对从讨论开始参与进来，这个是横轴是软件工程的生命周期，纵轴就是百分之百参与度，一开始参与进来，包括测试团队也可以参与进来，最后到两个控制点的时候就会发现之前不知道的问题，或者考虑不到的问题就解决一大半了，这个就是这个设计，我们的原则叫做运维从立项开始。

第二个非功能性需且决定了应用系统的生命力，在DevOps的整个理论和体系里面，非常功能性需求也很重要，DevOps方法论里面这个词叫运维需求，非功能需求叫Non-functional Requirments，包括哪些呢？可维护性，可靠性，可交付性，可扩展性，可用性，这个高度类似于生命层一样，做的好，系统生命性越高，很多系统发现我们的开发对不愿意改造他，愿意用有一个更新的平台架构重新做一个就是非功能需求没有做好，具体的话哪些是非功能性需求列出来了，这些其实都是一个系统应该上线前考虑的事情，批处理很重要，还有容量的控制，其实这个互联网更关心一些负载均衡，服务有没有降级，这里对于整个的DevOps非常的重要。

第三个应用运维要有串联整个运维技术栈的能力，我必须有具备和网络同事沟通的能力，操作系统可能也要稍微了解一点，主流的操作系统基本的东西我也要懂一下，甚至必须要会操作，中间件也要懂一些，数据库，我们的表结构，我们的数据库的设计，还有很多关键的东西，讨论更多一些，之后应用，这是我们做应用运维必须关心的接口，业务流程，你必须比业务人员更懂，所以这里给出一句话，我们不是全栈工程师的人，但是我们有全栈工程师的心。

第四个原则做了一个总结，系统有界，业务无边，我们可能一个企业里面有几百号系统，我们每个人负责一个系统运维，我们看到一个交易可能只是一个冰山的一角，只看到的上面，在前端一个渠道做了一笔交易，在冰山上面可能流进了十几个系统，他可能跑了好几个机房，跑了很多的系统，这种情况下，如果我们只关心，我系统本身跑的有没有问题，那么当我从业务的思想来说，这笔交易出问题的时候，很难定位，所以我们做应用运维，我们很显然不像开发团队，这个功能推上线就可以了做应用运维的话从端到端负责到底，这个时候应用运维维护的是业务，不仅仅是系统，这个时候特别难，特别需要注意的点，就是我们要超出系统的边界，做业务。

3. BizOps的应用实践

第三部分就是介绍一下应用运维的实践，首先就是DevOps只关注实施态，但是我这边可以纠正一下，在实施态的环境下，应用运维用到DevOps上这是因为DevOps的这个实施可以提高效率和加速质量，技术上持续交付，业务上按需而动，应用运维其实是开发运维和业务三大部门的连接点，这个叫System Owner叫应用运维人员，DevOps里面提到了打破部门墙，很显然应用运维就是打破部门墙的关键点，如果应用运维做得好这个部门墙自然不会存在，这是我个人简单的理解。

运营形态的话这里面提到，实践当中运行过程当中，要借鉴很多成熟的理论，就是ITIL，ITSM等，三大支柱，第一个是知识管理体系，我们平时工作里面积累各种知识和稳当，这当中最重要的就是我们运维很多时候做着做着发现可能某个系统离不开某个人，这个是很不好的事情，所以我们支柱管理和传递很重要，就是要人和事这个节藕不要绑到一起。

另外一个就是IT服务流程，刚才两位老师提到的技术运营标准里面列了很多，第三个就是工具与平台，自动化的工具，监控的工具，可视化的工具，平台的工具，包括云化了，各种PaaS的平台，也都是制成我们应用运维做得更好的支柱。

第三个一个词叫业务态，网上搜了一下没有这个标准，这一块强调是双速IT这几年大家提的非常多，但是我觉得其实并不是做双速的IT，我们真正的目标做双数的业务，我IT为什么有两速度，受技术控制的，但是业务有的快有的慢，这是两个完全不一样的东西，我们的IT技术是分慢的和快的，我们的业务也是有慢的和快的，这种情况下，如果我慢的IT技术比我传统的技术和我传统的业务在一块的话还是很和谐的。

就是大象和熊猫，他们在一起彼此很稳，也很值得信赖，但是如果我的IT技术是传统特别老的技术，这个企业要上互联网特别快的技术这个时候就麻烦了，这个老鹰就会和大象说，等你等的花都谢了，但是如果业务部门快过IT技术，就会说你太折腾了，所以我们有豹一样的IT，敏捷的一样的IT支撑我们像老鹰一样的业务，这个才是IT和业务之间达成的和谐，时间关系就不展开了，快速给大家过最后几个典型的案例。

4. BizOps的典型案例

首先给出一个叫做从前到后的一个案例，这个案例就是我不知道有没有企业有这种感受就是多头管理，可能一个业务是也很多个业务部门管理的，但是真正要求上是不应该存在的，但是事实上这种多头关系存在还是有的，出现这种情况的时候我们发现实际上开发阶段发现不了，测试阶段发现不了上线的时候应用运维才发现了，那么往往实际上我们工作当中就会发现，应用运维融合这两个业务部门第一次不相关，一旦做到一起商量，整个业务怎么样设计，业务应该由谁来负责，这个就是应用运维的价值，我们应该怎么做，应用运维前移，就是应用运维刚才提到就是为什么应用运维要前移，不要等到上线才发现这个不适合，不好跑，跑不了，另外业务部门也要后移，我们提需求的时候，要多想一下，我们现在线上的业务是怎么跑的，这个是前到后的案例。

另外一个案例就是前面提到的双速IT，或者双速业务，慢与快的关系，几年前上的产品，那个产品是行业的产品，设计的流程的非常复杂，但是在这个行业里面很受欢迎，这个复杂产品对我们来说是一个稳态，因为他慢，这个时候现在发现互联网的业务上线了，发现签约产品的客户交易非常慢，因为他被这个产品拖累了，这个时候怎么办？叫双速IT，你怎么做双速IT都会带来问题，就是说写了一句话叫快车道和慢车道，高速公路上有变现的时候，这个时候应用运维对站出来，应用运维做得好可以变成双速代替的齿轮，把这两个场景寻找一个解决方案，怎么样通过业务的一些优化设计，把这个这种场景避免掉。

第三个案例，从前到后，从快到慢，我们这个行业这些年也很普遍，每年的双十一，各种大促，其实来自互联网的压力也会传到我们这里，这个时候应该怎么办？往往每一次的压力，网联，互联网的应用，这个时候应用运维首当其冲但是这个并不是应用运维一个团队的事情，所以这个时候应用运维理解一个深入的 研究，对业务部门质量的团队，安全的团队，各个力量优化场景分析我们整个交易链条的瓶颈给出性能的优化方案，这个时候应用运维的价值，可以做这个事情

第四个案例由点到面，有一笔交易超时了，但是这个时候交易是从外面过来的，这个时候不知道他在哪儿超时了，这个交易经过十几个系统，是由很多开发团队开发的，这个时候怎么办？是有没有开发人员来支持你，很多开发人员告诉你是不是我开发的程序慢，所以应用运维有动力做这个事情，做端到端的展示，做端到端的交易分析，通过平台做链路的分析，帮助我们定位到这个问题，这个性能在哪个找对应的开发解决。

最后就是一个总结，未来BizOpS做什么事情，总共4个方面，业务上，流程上，还有未来海量的数据怎么样在平台上做一些事情，还有就是自动化，IT资源管理谢谢大家。