最近我花了一个月的时间和企业一对一的去沟通运维，去了解运维，特想和大家分享一下这个信息。以前的方式是我讲，大家听，这次是他们讲，我听，同时在讲讲我的具体理解。超过20家的受访企业大致分布如下：互联网：40%，传统行业：24%，银行：24%，运营商12%。
其实这样的计划看到很多传统企业/银行和运营商都非常关注互联网运维是怎么玩的?我根据最近的访谈情况，提出运维的四力模型，从这个模型里面，我们来看看到底还有什么样的信息。
传统的维护走向运维是有两种作用力产生的：
1.结构力
无论是互联网还是传统企业，都是基于不可靠硬件x86构建起的IT体系(研发/测试和运维)，这就决定了思维上的两种变化，第一种是不可靠性需要应用的技术架构来配合实现高可用(需要Ops进入到Dev过程)；第二种是去中心化/分布式/面向应用/零维护能力的底层系统，更需要运维能力的保证(需要Ops更强的能力提供)，我想这是大家不断找我讲运维主要原因。
可以说在互联网行业，是经历了一个迭代式的发展过程，能力从0到1到N。但在传统行业和银行，这个过程不是迭代渐进式的，之前受去IOE的影响，最近受国产化的影响，也有业务互联网化的影响，传统的高可用硬件架构必须转向不可靠的x86架构。系统工程里面都说，结构决定功能。不可靠的结构带来了不可靠的能力，此时就更需要全面的运维能力来弥补。运维能力是什么?是运维规范/是平台能力/是可视化运维能力/是端到端监控的能力/是技术架构自适应和可运维能力.....很多很多。
实际的企业访谈情况是，x86是一种必然的趋势，互联网企业不消说了，在银行/运营商也是如此哈！
我把这种力理解成一种内力。
2.变革力
这个变革力是业务形态变化带来的，就是业务的互联网化。业务互联网化之后，用户的需求持续反作用于IT交付流程。以前的IT交付流程，几个星期的一个版本显然不能满足市场竞争的要求，逼着企业走到持续迭代和快速试错的机制上。传统企业很多人都在问，互联网能够快速的秘诀是什么?有大系统小做(微服务)，服务公共化，服务向前兼容，灰度发布，持续集成，持续部署，运维规范化等等诸多手段。
或许你认为这种外力带来的是对自动化平台能力的很高要求，其实这只是其中一个方面，还有一个更重要的方面就是用户服务及系统状态的变化监测和修复能力。频繁变更的系统，偶尔会导致系统不稳定，如何保证运维有快速发现/快速定位/快速恢复。这是一个监控系统上的能力要求，传统的监控需要进行改变，但这个监控系统需要业务系统上做一些配合支持才行。
通过实际的访谈发现，互联网的发布频率明显高于传统行业，这是业务对内还是对外的差异，小到几倍，大到几十倍的差距都有，因此该变革力在互联网和传统企业是不同的。
这种变革力对运维的要求也相应的就来了，如何完成快速的服务交付和服务状态稳定保障，这是一个挑战。这个挑战来自于多方面的，第一、有运维平台层面的，比如说运维平台能力不足；第二、有组织设置层面的，烟囱式/竖井式的企业组织结构，能力传导特别弱；第三、有企业文化层面的，是流程驱动文化，还是技术驱动文化，运维能力也不同。
业务互联网化是一种很强的外力。
基于以上内力+外力的相互作用的结果，运维需要新的变化，才能走出运维苦逼，无价值的境地，从而真正给新IT组织形态下传递更多的IT能力。
3.控制力
我把运维组织理解成两种类型，面向科学管理时代的组织职能化，每个单元负责特定的职能(function)。在业务互联网化的今天，通过建立面向产品/业务的跨职能(cross-functional)组织来应对敏捷和快速变化的用户要求。传统企业大部分还是职能化的组织架构，而互联网企业都是面向产品的事业部制。跨职能的组织结构，有很强的能力传导效应。
但从运维的角度来说，我还是把运维归到类似公共服务能力部门，此时运维必须建立一种控制力，这个控制力有组织层面的，也有业务层面的。组织层面的，需要集中的运维控制组织，这有利于能力的服务化封装，从底到上都是如此，比如说网络服务/数据库服务，甚至是上层应用(系统或者叫业务)运维等等。另外一种情况，组织中没有应用运维角色，导致面向业务的运维控制能力进一步减弱，运维沦为资源服务的提供者。
严格禁止运维随着研发走，特别是对于一个多部门或者多产品组织中，每个部门/产品组带一个运维小组。
我的观点对于一个互联网化的业务来说，应用运维+集中式的运维组织结构必须是组织建设的两个重要因素。
企业实际的情况是，我访谈的大部分企业都很难建立真正的控制力，核心是没有建立面向业务的集中式运维组织架构。我给很多互联网企业的建议是，必须走向这样的架构，我给传统企业的建议是，建立面向业务的运维孵化组织，让他们按照新的模式运行，储备新的能力。
4.驱动力
由控制力形成的驱动力，控制力之后，运维逐渐形成对面向业务型的运维理解。此时运维会整体性规划其运维体系，并付诸到后续的阶段性实现计划中。运维的驱动力也来自于多个方面，第一个是平台层面的，第二个是规范层面的，第三个是意识和文化层面的。
平台层面的，运维必须建立标准化的自动化和数据化的平台，来驱动DevOps。规范层面的，运维需要建立自己的运维规范，包含线上服务环境的运维规范，也包含技术架构的规范，还包含自己的运维服务规范等等。一定要注意，运维规范必须要从线下走向线上，从流程走向技术服务等等。意识和文化层面，要不断的和研发强调，运维不是维护，运维不是负责资源管理的，运维可以主动承担更多，这种承担会直接影响IT组织的性能。
很多企业实际的情况是控制力偏弱，导致驱动力很弱。一个好的运维组织是高性能IT组织的保障，高性能IT组织到底有什么好处?在2015年puppetlabs的DevOps报告中有体现：
总结一句话，底层IT基础设施的变化，外加业务形态的变化，都在迫使运维的转型，此时须建立集中式运维组织，从而形成真正的运维驱动力。
个人介绍：王津银，自称老王（非隔壁那种）。05年毕业，研发两年，07年进入腾讯公司接触运维，经历服务器从百到万的运维历程，先后在YY和UC参与不同业务形态的运维，期间带过前端运维、数据存储运维、YY语音、游戏运维、运维研发等多种运维团队，对运维有着全面的理解。极力倡导互联网价值运维理念，即面向用户的价值是由自动化平台交付传递，同时由数据化来提炼和衡量。
