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