Reboot运维开发千人群（365534424）即将爆满，欢迎加入
我一直在强调一个事实，就是随着大规模集群和云计算的普及，运维人员一定是最先被挑战的。最先被技术的发展，特别是运维自动化技术的发展所逼迫要选择的。选择很简单，要么淘汰，要么转型和升级。这个话我其实在我参加的很多技术交流、公开的大会上，都在讲。正好看到一个文章。先转后评。
云计算技术，IAAS和PAAS，正好是现在主流运维在做的事情。IAAS和PAAS的普及，将会带来运维工作的集中化。云公司把这些事情都做了。而云公司，则出现大规模集群或者超大规模集群，必然也会采用运维自动化技术。所以，低端运维被淘汰，运维被迫要向运维开发进阶。
其实这个时候谈运维危机有点像在当下讨论股市危机一样，因此写这篇文章时，内心很纠结，特别是这个互联网运维才产生没多少年（10年）的行业，怎么你就来谈危机了？没办法，都因技术发展太快。
首先带大家看一组数据，国外著名企业级公有云管理市场领导者rightscale每年都会发布一份云计算市场报告，rightscale应该是云管理里面的鼻祖，2013年他们平台管理的服务器达到580万台，因此他的数据报告还是有一定的权威性，从这个报告中可以让我们看到一些趋势。
一、云的使用情况
云的使用度已经达到93%的水平，而在具体的云使用策略上，可以看到未来多云（82%）和混合云（55%）是未来的趋势。
其实这两组数据给我们展现都是云的趋势越来越明显，用户的接受度越来越高。而云计算到底对运维有着什么样的颠覆力？
2、个人也对对国内的公有云使用情况做了一次调研，用户的使用水平也是相当的高（游戏领域），达到76.19%。因为样本量不大，应该会更高。
3、Rightscale报告中，也对DevOps的使用情况做了统计。用户应用DevOps的理念或者工具很广泛，达到66%的水平，相比去年有一定的增长，并且在IT更复杂、敏捷性要求更高的大企业中，DevOps的应用比例更高。在DevOps工具的使用上主要是puppet、salt、chef、docker几类。调查报告中用了“DevOps rises，Docker soars”来总结DevOps和Docker。
4、为了进一步去验证DevOps理念的应用情况，我把PuppetLabs的DevOps的报告又找出来了，总结了DevOps的核心理念及实践。报告反复强调自动化、强调DevOps文化价值、强调数据驱动等等，这些对运维又有着什么样的影响呢？
二、危机在哪儿？
1、云计算平台对运维的影响
我们都知道云计算平台有IAAS平台、PAAS平台、SAAS平台之分，不同的部分对运维的角色都有着不同程度的影响。
IAAS把基础架构做成一个服务，资源即需即得，这也正式创业公司都愿意使用公有云平台的一个原因。按照传统的模式，创业公司自己需要联系机房、购买服务器、电信机房放置调试服务器/网络等等一堆基础设施的工程，影响项目周期不说，还需要一定的专业技能，而IAAS把创业公司都从这些需求中解放出来。再进入到IAAS内部几大部分，软件定义计算、软件定义存储、软件定义网络，进一步降低对运维人的依赖，确保一个大资源池的整体服务能力。让软件代替人，是IAAS层基本思想，都知道对于一个海量的服务架构，同时要面向不同的业务形态，IAAS只能依赖这样的软件定义能力，靠人是跟不上的。刚刚paypal分享他们迁移到openstack经验，其中一个数据很有意思，以前paypal对服务器故障的容忍度是1%，而迁移云平台之后容忍度是3%到5%。要知道这个比率提高意味着什么，对运维的实时事务处理要求进一步降低，也就是对人的需求减少了。结论：不需要那么多基础运维人员了。
PAAS部分，进一步对服务进行抽象，变成一个公共的服务架构，研发程序只需要遵从一定的开发和配置约束，最后服务的运行、发布等都由PAAS平台统一接管，进一步释放对运维的依赖，且此时根本就没有IAAS层维护成本；结论：不需要那么多应用运维人员了。
最后到SAAS部分，这块目前在国外非常活跃，国外从运维领域的监控、自动化部署、数据分析、资源管理等领域都有多家公司在提供服务。之前依赖运维从无到有的构建，现在也不需要了。在传统的模式下，运维都是自己搭建监控平台，自己构建部署系统。当前情况下，对于小的企业来说，可以直接使用云平台自带的服务，足够应付。对于更大规模的企业环境来说，你可以选择其他云服务，只要你许可他们的agent安装在你的服务器上，采集数据/部署都可以完成。再回过头看看IAAS云中提供的RDS服务（类似SAAS服务），里面把一切对Mysql的管理都封装成webUI；对于系统中慢查询，在给出报告的同时，还能给出相应的优化建议，备份、迁移管理都一应俱全。不过幸运的是，国内目前这块的产品还不多。结论：不需要那么多应用运维人员和DBA了。
随着在云计算不同层次的云服务水平的不断提升，对传统的运维模式（流程性、功能性、技能型）逐渐形成颠覆力。可能还是会有很多人有疑问？从公有云获取到服务器资源之后，总还需要做一些一些人去做系统管理的工作吧？不需要，你是否想过未来假设有人基于puppet或者salt封装一个appstore的模式供用户使用，里面所有的SA管理方案都可以通过下载的方式应用到自己的OS环境；PAAS现在很难应用起来，部署工作总还需要运维吧？我认为即使PAAS应用不起来，通过其他的持续部署方案和更上的自动化编排方案都可以解决自动化的问题，因为本质上就是发布文件和执行命令；应用需要经常变更、扩容、故障定位总需要运维吧？我也不这么看，你所会的技能很多都隐藏在数据之中，通过容量数据可以驱动应用变更和扩容，并且容器docker的出现可以让这个工作变得更简单，关于故障定位，很多时候都是依赖一些故障定位技巧，而这些技巧都是可以通过数据来做root cause分析的，只需要把资深的一些运维人经验提炼成产品。
因此我更愿意相信在不久的将来会有一个完整的运维产品存在（类似ERP），该运维产品能够解决自动化运维的问题，能够把一切技术数据收集起来，按照运维人的经验来提炼数据的价值，应用到各个运维场景中去，比如说容量、故障定位、扩容、变更等等。
2、DevOps对运维的影响
在前面给了一些关于DevOps的数据，首先可以看出DevOps的理念已经开始逐渐被更多的企业所接受，其次DevOps关注的焦点也和过去的流程ITIL有着本质的区别，他就是需要通过自动化不断的降低浪费、驱动敏捷、打破团队边界等等。在前不久，我参加了今年puppetlabs的一个在线调查，里面可以看到国外已经有专门的DevOps部门存在，且有专门的DevOps工程师。我是如何看DevOps？就是把后端的Ops服务不断的推到前面Dev，让前面的Dev具备Ops能力，这就是DevOps。当然背后是靠平台和工具支持的，流程肯定是不行，这是传统运维急需要改变的地方。把这种对人的依赖和运维的经验都转换到平台中。在早期，所有的发布变更都依赖运维来完成，后来我们搭建发布平台，可以让测试来做发布，再往后发布平台和自动化测试平台进一步对接，这个发布工作再进一步交付给研发，运维从过去的执行者变成了审核者，自动化驱动一切，质量、敏捷驱动一切。
再去到数据化运维部分。由于研发、运维都是技术人员，所以大家很容易对技术数据达成一致的认识，甚至有时是研发会更敏感，因为他更了解自己的服务该如何衡量。过去我们都有错误的认知，把数据当着运维团队的核心资产且保密，只有运维团队使用，而其他的团队只能关注到一些运维给到的结果，其实这是违背DevOps原则的。而我的建议是，运维提供采集一切数据的能力，把上层的分析和展现能力开放给所有技术人员，运维人员只是数据使用的一个角色，可以按照自己的价值维度和场景抽象几个数据产品出来，比如说监控、容量、质量、可用性等等。研发人员也是数据使用的一个角色，它可以按照自己对服务的理解，去任意的加工数据，这个有点回归到以前BI的那套思路了。
因此运维最终要变成经验平台的建设者，而非简单的事务执行者。
3、开源技术对运维的影响
现在还有什么开源解决不了的呢？请直接搜索【开源的DevOps开发工具箱】
而我想说，在运维的每个部分都有相应的开源解决方案存在，难道我们还说对运维的依赖很重么？在任何一个运维开源技术面前，运维能表现出比研发更强的把握能力么？说实话，开源技术把之前运维的技能墙打破了，都可以获取技术的能力。不过这个地方有运维的一个存在价值，也就是国外DevOps部门的存在价值，我的思考是DevOps部门提供的是运维平台统一规划和建设能力，否则对于一个企业来说，技术和目标的协调无法完成。开源技术降低了获取门槛，但也提高了被滥用的可能，而运维部门可以避免这种滥用。
一方面我们要注意到当下的云端技术变化趋势以及对运维的影响，另一方面要清楚的知道单纯的流程性/功能性/技能型运维，已不是时下需要，危机正在悄悄走进你。当前运维的存在空间，还有部分是因为开发不懂什么是运维，他们连puppet都不知道。当有一天运维也像开发、测试一样变成云端服务，运维就不需要依赖某个运维人和某个运维团队了。因此请尽快拥抱自动化运维、数据化运维，并往运维产品化、规划方向提升，一起做好运维转型准备吧。