| 编辑推荐: |
| 本文来源网络，本文介绍了作者总结的应用运维是什么，运维整体的原则以及运维团队能力要求等相关内容。 |
|
由于自己一直是做应用运维的，所以今天主要是和大家讲应用运维相关的，我个人总结了一些体系和方法论，希望能对你们有帮助。
第一部分：我讲应用运维是什么；
第二部分：我讲应用运维需要什么样的团队；
第三部分：给个案例讲讲运维能做什么？
第一部分：应用运维是什么
其实很多时候非运维的人员不知道运维是什么，他们都理解你们是网管、提供服务器的，处理故障的，其实这些都不是。
恰好Blues提议我去产品经理社区讲讲运维，那么我要把运维和他们讲清楚，我就不断在想运维是什么?
对于我来说，运维就是技术运营，和产品运营差不多。
对于用户的需求，一方面有实际的产品实现服务交付，另一个方面需要技术去支撑产品，无论是客户端还是服务端、无论是网络还是服务器，涉及的技术很多，因此我觉得对于运维来说，如何把你维护的技术栈运营好是非常重要的。而把产品和技术拉到同一个点上的就是用户价值。那什么是用户价值呢？
我把客户的价值是获取服务需要一定的成本之上，所获得的服务能力。这个里面有产品提供的功能能力（产品指标）、获取的可用性（运维指标）、体验（产品+运维指标）和成本（产品+运维指标）。
其实这个思路确定之后，会影响我们后续很多应用的方法论以及团队之间合作的感觉。
我们运维和产品、技术等等都是服务于用户，最终的价值点都是用户的，这样把我们的合作点都拉到了相同的对象上来了。
接下来我讲我整个应用运维的方法论。我把它理解成几部分，
第一：运维整体的原则；
我很多时候都看这个，一定是价值导向。前面讲了用户的价值导向，我们技术运营的好，就是让用户使用我们的产品很爽。
涉及这么多的技术栈靠人肉一定是没法运营好的，这个时候必须要平台支撑，我把平台分成两部分，一部分是自动化平台（实现价值交付），一部分是数据化平台（实现价值衡量）。
服务透明，分成两部分，一部分是离线服务，一部分是在线服务。离线服务比如说运维服务器资源提供，运维扩容能力，甚至是ITIL的服务等等，这些服务能力一定要对研发和业务部门透明。千万别设置很多的表格来让研发或者产品理解。
在线服务的透明，我其实讲得更多的是服务公共化能力，打造公共化的服务平台。原生memcache、mysql都是组件，而不是服务。而需要在此基础上让他们具备可运维性，一个重要衡量基准就是透明性。
最后一定要数据来驱动，别动不动跑到研发那边说，你这个不好那个不好，拿一些数据出来，告诉他们那个地方不好，包括我们自己哪儿不好，其实这个和服务部分也有些关联。我们的数据驱动可以驱动我们内部的服务优化，另外一个就是驱动线上的服务优化了。
用户价值已经说了，接下来说说平台。
在很多运维人的眼里，ITIL就是运维的平台，而我说不是，我很多观点都在讲去ITIL化，去ITIL到底要去什么呢。
一个是去流程化的意识，一个是去服务化的意识。
在一个故障发生的时候，不要埋怨人做错了什么，我是不是可以通过流程或者加入什么审核机制来规避掉，那是传统的做法，不建议。建议找技术驱动优化的方法，待会儿后面有个案例会说这个观点。
去服务化，是因为现在的运维服务范畴已经大大的发生了变化，这个服务的边界已经拓展了很多。最低级的如果你还按照服务某个研发或者业务的方式去做运维的，最后运维是没有出路的。高级一点，我把ITIL里面涉及到的一一几个流程做成产品，封装服务，其实你会发现很多服务在互联网化下已经发生变化了。
因此我自己把运维平台做了一个总结，我觉得可以适用大部分团队。
（注意这个图中写了“此服务非彼服务”，这个服务是将的一种动态能力，而ITIL服务讲的是一种静态能力。）
里面你可以理解有几个部分，基础架构及服务（IAAS及私有IT设施），配置及服务（CMDB）、架构及服务（公共服务能力那块）、数据及服务、监控及服务、持续集成服务、适当的考虑一下ITIL那块服务能力的封装，比如说事件。问题管理就不需要了，做了这么多家，从来没有去实现问题管理，发现也没什么问题。
架构及服务，我后面在运维路径里面再讲一下。数据及服务，我把技术数据的本质理解成指标和事件数据，运维应该有能力去采集这些数据，然后分析、在此基础上进行告警。甚至我觉得监控是数据服务上一个场景，因为对于很多用户来说，监控的维度非常复杂，其实想传统的nagios和zabbix完全不能满足这种柔性。
刚刚讲了整体的原则。接下来我把应用运维三部曲，做应用运维都是在这个路径上去走。
第一步做标准化，第二步做公共服务化，第三步做服务去状态化。
这个我之前写过一篇文章，里面详细介绍了每部分的内容，这个地方再简单的和大家过一下。
一定不要忽略标准化的价值，当你从底向上把运维标准化做好了，你以后的运维成本会大大的降低，比如说自动化，甚至是服务发现等等。我之前把标准化分成：服务器的、OS的、机房部署的、应用环境的等等。
这个里面发挥一下想象力，能标准化就标准化，小到一个进程的属主和路径，达到机房甚至是架构选型。特别是架构选型这块，一定不要被开发牵着走，特别是有些研发说性能很高，我希望你们给到的回复是，我多给你几台服务器。
还有一个标准化很重要的是协议，在YY有一个标准化的YY协议，目前我负责的业务这边都采用http协议，在统一协议之上做一些运维能力封装特别简单，比如说监控、数据采集等等。
服务化，我刚才说mc、mysql都是组件化能力，不是服务化能力，真正服务化的平台一定是运维友好的，一定是对前端应用是无状态感知的，比如说mysql扩容和迁移等等，都可以做到对APP无感知，这才是服务化能力。
无状态，等我们所有基础设施都标准化了，这个时候，我们就要去无状态化了，去识别架构中的单点问题，挖掘出来优化他。这个里面有方法论可以遵循，早期腾讯有个海量服务运营之道，大家可以网上找找。
我这次有个项目优化也遵循了这个原则，收到很好的效果。
应用运维也有了路径，接下来就是怎么落地了，那么我会在不同的阶段，制定不同的方向，比如说我现在的团队来说，我的方向如下：
就是做数据化运维、自动化运维和精细化运维。
紧扣当前阶段的目标，识别当前团队的矛盾点，设定具体的KPI方向，持续以周为单位进行跟踪。
都会有明确的要求，每周滚动。这个群里面很多我的同事。这个地方的建议，一定不要把扩容变更能力、服务器提供能力作为指标放到你的KPI中。做得不透明和不好是我们的耻辱，做得好是应该的。所以很多时候我说运维是要带着耻辱感去工作，每天我做重复的事情，点按钮，敲命令就该想想什么地方要改进了。
第一部分什么是应用运维我讲完了，什么是应用运维--》整体的指导原则--》应用运维的实现路径--->运维的工作方向---》最后到运维的KPI持续滚动。
这是运维团队能力要求，里面有三个部分，业务运维即应用运维、运维研发、运维技术研究。
我希望大家日常的运维工作，在业务运维这块越少越好，而运维研发和技术研究越多越好。
还有一个非常重要的东西，运维工作是什么驱动的，这个代表着不同类型的三种团队。
问题驱动，救火队员，你天天在救火，有没有感觉每天半夜要起来苦逼，如果是这样的话，一定要去把问题找出来，这个阶段都有，按照我说的三部走一定可以解决。
事务和需求驱动，我觉得就是一个保姆角色，做内部服务的提供者，研发找我要服务器，我给服务器，找我部署，我去部署，找我做什么我就干什么。
最后一个是价值、优化、用户驱动的运维团队，我们需要走出来，把自己的能力放大一下，运维能做的事情很多呢，三部曲里面那么多东西可以做，还有自动化平台建设，还有数据化平台建设。
个人能力模型，其实这个是腾讯的职级通道体系里面给的，他分成了10个维度对应用运维提出了要求，其实我觉得写得不是很好，忽略了运维研发能力要求和运维规划能力要求。
特别是T3、T4职级，我觉得一定是从运维研发能力走过来的，只有你做过自动化，你才能对运维的东西进行抽象，其实这个和测试一样，长期做功能测试，你最后都失去了对测试美好愿景的想象，运维也是如此的。
技术能力希望大家再全栈一点，很多应用运维一个薄弱的环节就是对数据能力的了解。其实我有时候还建议大家去看看Oracle数据库呢，这个能力非常重要。恰恰我觉得应用运维做到最后如果能不了解业务就最好了，做到业务无差异化运维。
其实运维开始非常苦逼，是吧！但是你把这个事情当成一个挑战来看和对自己的一个不断完美的要求，你会觉得运维是有很多美感的，这个美感我在之前一篇文章里面讲过了。在此就不复述了。
（图还是要给，强化一下大家对美感的认识）
这一部分我讲了团队能力要求，驱动模型，个人能力要求和运维美感，不全是苦逼。
最后一部分我讲一下一个故障看运维的价值。
说一下家丑，去年12月13号，我们一个核心业务，因为交换机故障，导致我们服务终端45分钟，100%服务不可用，耻辱。
这个故障暴漏了很多问题，我们有冷备中心用不起来，复盘的时候发现很多架构问题。
问题真的很多很多，这个地方有个经验，问题是运维最好的老师，特别是线上故障，如果一个故障产生的时候，运维一定要挑头把这个故障进行复盘（腾讯运维的经验），最后你能识别出很多需要改进的地方。
好吧，问题已经发生了，我们要解决它，领导说了，别跟我说那么多没用的，简单指标，5分钟发现故障、三分钟解决。怎么解决啊，几乎是不可能的任务，不过领导说的，咱们硬着头皮也要挑战一下。不过UC有一个很棒的地方，团队合作特别好，一群优秀的人。我们就成立了一个专项组：把产品、测试、运维、研发、还有项目管理都卷进来了。
13号出的故障，14号我们复盘了，15号了，我们就成立项目组了。
简单而极致的要求是我们平时需要不断告诉自己的，最怕的心里状态是这个故障跟我没关系，头都不挑，其次一种怕，就是说技术能力不足，会不会被研发挑战。
不要怕呢，我们都是为用户服务的。
其实从这个节奏来说，UC的响应速度非常快。
我在项目一开始，也确定了一些原则，其中总结起来最核心的就是”技术驱动优化“，而不是流程优化。
这个里面分成了六个方向：服务降级、双中心、统一调度、过载保护、业务分离、立体化监控。
为什么需要这些简单的原则？这个有利于项目一致的理解。其实刚刚头条新闻也发生了500错误，从服务影响时间来看，30分钟左右，我猜是后台数据库压力过大导致，在这些原则里面都能找到解决方案，比如说过载保护，服务分离等等。
这些原则和方向许多都是运维参与的，比如说双中心就涉及到运维参与方案的讨论，给出数据双中心的方案、立体化监控也是80%是运维来做的，统一调度，我们借助了天雷调度（httpdns）。
然后在这六个方向上我们就制定了具体的改进措施，最终完成了刚才说的5+3目标。
这个故障其实可以看到运维很多东西可以做的，首先运维一定牵头，第二运维一定要提出自己的要求，第三运维跟进参与整个改进方案的实施，第四，运维要最后给出最终的结果报告，我们做了这么多到底怎么样。
自己希望的一个愿景吧，没有操作就是好的运维，最后应用运维没有运维就是好的运维。
其实许多时候不要让大家感受到我们运维，我们运维就是成功了，运维的SAAS化一定是未来的趋势。
自己也倡导了一些运维理念：
接下来是问答环节：
1、目前自动化运维这块有什么好的学习建议吗？
王：我对自动化有分层化的理解，我建议应用运维第一个把持续集成作为重点，其次是把配置管理作为方向（比如说puppet、saltstack）等等。
持续集成带来的收益非常大，可以把运维从日常繁琐、低价值的任务中释放出来，并且是跨越了研发、测试和运维三个团队，这个里面解放了几个团队的生产力，收益很大。
但我建议你们持续集成一定以标准化为前提，否则做起来很累。
2、问题类似：技术驱动，那些技术？
王：这个技术驱动，其实是一些技术的方法论，基于这个方法论，当然你也需要很多的技术储备，无论是存储的、还是应用的，还是协议的，还是程序研发的，甚至是测试的，都需要了解了，全栈。
3、请问，很多企业把运维细化到分片分区管理，你说的运维理念又很难实施了。
王：这个应该是传统企业来的吧，这个变革力就看大家的要求了。我的预见是总有一天用户会逼着你做出改变，这种外力比内力推动力更强。
4、具体的学习路线
王：如饥似渴的学习和运维相关的一切知识，ITIL、网络的、操作系统、应用组件的.....没有好的学习路线来遵循，把你岗位上做到机制，把周边知识都吸收进来，比如说你从网络上去看应用运维
5、学习建议
王：我的建议不要浮于表面做运维，当你遇到一个不懂的问题时候，你要深究到底，然后顺着他就可以打开知识体系了，举两个简单的例子，top命令看到的那些CPU占用的指标，user、sys、idle、io....我以前面试就经常问这个，可惜很多人都不知道。
如果你能说出来原理，就说明你把知识地图打开了。其次我们经常定位问题用的strace，但你真正的去了解strace原理的时候，里面有很多操作系统的知识涉及到，当年因为strace，我还把操作系统的书重新看了一遍。不放过任何一个细节，总结和思考自己目前正在做的。我觉得其他的东西都好解决了。
6、请教：运维人如何做绩效考核？东西很难量化，主观意识太强？
王：去掉主观的东西，识别自己需要优化的地方，平时记录下来，然后要求组员也记录下来，到每个Q制定规划的时候，大家一起提。
备注：
ITIL：信息技术基础架构库
|
