运维是时候走出服务区，迈向产品化了，可以说运维产品化是真正的未来运维姿势！
在很早以前，记得给YY的产品经理讲什么是运维，当时给运维提炼出一个成熟度模型，囿于当时的认识，用技术模型来做了总结，简单总结如下：
1、单机
把SSH作为主要的运维能力送达通道，机器的服务器数量很少，基本运维靠手。日常的运维工作内容也就是修改配置文件、机器上架、网络变更、应用发布等等。运维看似无所不能，无所不包。这个时候运维把配置管理工具（chef、puppet、salt）应用到现网会兴奋不已，认为这代表着一种自动化。此时运维的自我驱动力和业务驱动力都非常的弱，确保需求完成即可，完全是一个问题性、事务性团队。
2、批量、自动化
随着服务器规模越来越大，“靠手”的模式逐渐不能应对那么多的事务需求，此时需要运维引入贴合业务的自动化封装。配置管理工具显然不能满足更上层的业务变更的需求，特别是国内研发自由发挥的情况下。大部分公司会以以标准化为前奏，持续部署为主线强力推动自动化工作，释放运维人力。但这个自动化只是构筑在运维环境标准化之上，基于整个业务的自动化链条依然还没有打通。应该说当前阶段很好的满足了业务需求，还远远不够，特别是运维在数据和架构的理解上。其次运维还是和业务耦合，没法做到业务无关，业务的碎片依然带来大量的运维人力成本消耗。
3、集群化、无状态
本阶段以消除业务碎片和业务架构去状态化为核心特点，变成集群式Cluster运维。在上一个阶段，发现运维自动化的能力是受限制的，此时要做到全业务的自动化发现很多服务都带着状态，需要自动化工具带着对业务的理解，成本相当的高昂，举个简单的例子，配置文件依然是记录了服务的访问关系，权限策略等等。为了更好的驱动运维自动化能力，此时把业务架构去状态化和消除业务碎片作为核心的目标。为什么要消除业务碎片化呢？我仔细分析业务碎片是当前阶段运维成本的主要消耗，运维团队是跟随业务走，到运维团队内部，运维也是也是划分业务的。但我们可以设想一种运维形态，那就是在运维人的眼里，我看不到业务差别，只看到线上服务的区别？那是否可以带来运维成本的大大降低？所以我们提服务的集群化，把业务共性服务抽象出来，建立服务集群。最后就是无状态业务逻辑服务配合各种不同的服务集群提供业务服务能力。是否有点类似于PAAS平台？
4、云运维
从运维职责上有基础设施运维、应用运维、数据存储运维等等，IAAS是一种基础设施、架构运维能力的产品化封装。依附在IAAS云上的运维能力交付的确可以让很多公司摆脱对运维的依赖，运维能力已经透明，都包含在产品之中。
现在回头去看，觉得这样的划分非常简单，从以上的技术阶段去划分运维，首先无法和非运维人员沟通清楚，术语本身就无法理解；其次很容易落入到技术特性识别之中，而忽略了其业务价值。而我最近所做的思考努力，是把它转换成类似CMMI的成熟度模型(待深度细化)，初步的识别如下：
1、运维职能化
运行 维护是运维的最直观理解。在非运维人的眼中看到了很多运维职能，如网络管理、服务器管理、服务变更者等等。在运维的自我认识中，保姆、救火者是其代名词，岗位角色决定的，运维自己面对的还是一个个独立的运维事务。
技术人员在提一个业务需求的时候，还需要和多个运维职能角色打交道，找DNS管理员申请域名，找服务器运维给服务器，找业务运维去部署应用等等。
2、运维服务化
在上一个阶段的运维职能逐渐消失在一个一个的运维服务之中，并且这种运维服务接口特别简单，此时典型指导思想就是ITIL，以前以资源描述运维服务的特征转换成业务角度描述服务的特征。运维用一个类似运维服务目录的东西对外提供服务，技术团队和运维团队的交互接口也非常简单，只需要给出运维服务接口的业务输入即可。比如说新业务上线，输入你的业务指标、业务能力模型即可，后面的资源评估都可以由运维后台完成，服务的输出从技术上看到的是一个个的服务名标识，无需关注服务的物理表述，比如说分配的RDS存储资源的物理位置，你看到的就是一个服务名。
运维服务化还是把运维定位成一个服务者，同时作为服务者，运维的服务对象就是是公司的研发和业务。这就回到我之前所说的D/0分离的弊端，直接的后果是运维的成就感不强，变成了一个保姆的角色。运维服务还把运维团队放在技术支持的职位上，很难让运维团队走出来。
3、运维价值化
个人是价值化运维的倡导者，把运维对内的服务输出变成对外的价值体现。那什么是运维价值？之前说质量、成本、效率、安全等等，我觉得这个价值可以作为运维KPI没有任何问题，但作为跨团队（产/研/测/运维）价值则有问题。真正的运维价值应该可以上升到一种共识，这种共识可以协调产品、研发、测试和运维朝着共同目标（质量、成本、安全）前进，这也是DevOps所倡导的。在之前的一次分享会上介绍了DevOps的价值是：
不提倡一种共享价值和做事原则，其实运维的工作很难开展开来，有了这些统一的做事准则和对用户价值的关注，各团队都找到共同的落脚点。持续优化是PDCA似的运维工作的持续改进；共享责任，是一种责任共享文化，很多团队都把合作挂在嘴边，到最后我就是不合作，把责任绑定在一起，最后能催生合作，是一种更本质的表达；杜绝浪费，不合作、等待都是一种浪费，浪费就带来了成本；关注用户，是以用户的价值拉动整个内部价值链条的滚动，这个用户的价值不单纯是一个简单的质量描述，也可能是一种业务需求，关键是能够实现快速交付（这个和持续交付是吻合在一起的）。
4、运维产品化
运维价值化的最终落地需要产品化的体现，一种可视化的封装。运维职能阶段的小组边界被自动化平台不断的打破，运维服务所需要的流程，已经隐藏在自动化平台之中，最终用户的价值驱动和优化，通过数据平台DevOps指标来体现，改进之后通过持续交付到用户手中。
基于自动化和数据化两条平台主线，可以构建完整的运维产品体系。对于自动化的维度来说，分层去看待运维自动化平台的需求。对于不同的层次，对应的解决方案不同。比如说基础设施服务层，它的产品形态是IAAS；对于架构层，运维产品化的体现是组件服务化平台；对于应用层是持续部署的自动化解决方案。这些产品虽然所处层次不同，但无耦合性。
对于数据产品来说，显得会繁杂一下，清晰的识别数据价值非常不容易。这个更需要运维能识别出数据的业务价值，才能把运维技术特征的平台转换成业务平台。这个地方有一个很清晰的指导思路，就是把运维当做技术运营来看待（和产品运营类似），可以提供更多的产品建设思路。后续我单独开篇文章去讲【运维和技术运营的关系】。
运维的产品化，真的会诞生一个行业，一个生态。每个重大思想推出之后，必然会伴随一次产品化的过程。回顾我个人所熟知的IT领域，也遵循着此规律，粗略看看。
早期管理领域的MRP和ERP管理思想，诞生了几家伟大的公司和产品，比如说SAP、Peoplesoft、国内用友、金蝶等等。对于ERP来说，由于涉及那么多模块（财务、物料、销售、仓库等等），没有专业公司的支持，落地更是难上加难，这也便催生了一个ERP咨询行业。
在商业智能领域，早期诞生了BusinessObject、Microstrategy、Brio、SAS等公司，这些产品当年在银行、电信领域是非常的热。
再看看大热的数据可视化领域，Qlikview、Tableau、Tibco Software等等，不过在这个领域依然有很多老牌公司，Oracle、Sap等等。
最后看看早期的ITIL，产生了N家ITSM的公司和软件，如BMC、Tivoli、HP等等，更伴随了一个IT服务咨询的行业。
我没有理由怀疑！这次DevOps思想也不例外，必然会带来产品化的全面爆发！。我所说的运维产品化又带着很多特有的属性，比如：
1、运维人的优势会凸显
做过运维的人构建的产品会有更有优势，运维是场景强驱动的行业，这个经验优势不可比拟，因此让运维更有优势提炼一个有共性的产品出来。当前我们能看到的是，持续部署方面可以抽象成一个标准模式，而运维不仅仅是持续部署，只能说持续部署解决了应用运维里面核心问题。其他的产品化需求，需要参照不同运维角色、不同行业、不同规模、不同业务等因素去综合考虑运维产品的设计。
但运维人又有着明显的劣势，普遍产品化能力不强。
2、核心需求出发的
当前的运维产品化一定是从运维的核心需求出发的，比如说基础设施服务、基础架构、持续部署等等。不同的层面有不同的服务提供商，比如说IAAS领域、PAAS等等；在持续部署领域，你可以看到有基于docker提供的服务商出现。没人会去做一个单独的配置管理平台，非核心运维需求。
3、云 形式存在的
云 能力很容易让人觉得是公有云形式存在，其实不是。云 形式是一种公有云、私有云任意部署及运行的模式。一方面随着公有云用户越来越多，运维的产品需要提供类似公有云的交付能力，和IAAS云平台整合交付，面向用户的全服务能力。另一方面，也不能忽略私有云IT的情况，这个产品必须能快速导入到私有IT环境。这个IAAS云的策略是类似的！
4、垂直与整合
运维的产品首先是垂直的，在不同的层次和不同的方向都会有相应的产品出现，如APM、持续集成、CMDB、移动化运维能力、监控等等。横向整合不同的运维产品优势，提供面向用户的运维服务一站式平台。
不得不说IAAS云或者私有云平台有着入口级的整合优势，当一个运维产品可以以云 形式运行的情况下，可以很容易跟随IAAS在公有、私有云环境中部署和运行。
运维产品化是运维人能力的一次自我检验，一方面检验我们是否走出对小组、公司、行业的运维认识，同时在检验着是否真的做出了“面向用户”的运维。最后提醒，我们再也别提运维是做服务的！
