你认同这五大运维体系的划分吗？本文会给你一个初步的答案。1、价值体系（价值）我在任何场合都强调运维价值/IT价值和用户价值之间的关系。在精益运维的分享中，我推导出用户价值可以通过IT价值相互转化。这种转换的能力大家是可以直接感受到的，其根源在于IT形态的变化。过去，IT中的“我”是信息。这个IT功能是通过许多线下渠道传达的。该信息系统是称为MIS（ManagementInformationSystem）的内部管理系统。现在IT里面的“我”就是互联网，也就是互联网，而互联网本身就是一个客户渠道，已经把用户和内部IT紧密的结合在一起了。运维的价值是什么？质量、成本、效率、安全！你对这些价值观的理解和践行有多深、多远，你对用户价值的理解就有多深、多远。有人说你一直在提倡以用户为中心的价值传递，好虚伪！说实话，一开始我也觉得很虚，即使你在工作中参与了一些实际的价值创造，你还是觉得很虚。比如我们优化用户页面的体验，这就超出了产品经理的技术理解范围。他们关注的是业务运营措施对用户指标的影响。其实技术也是有影响力的，老外来用数据来证明，比如打开网页的速度。来自以下的统计数据：加载时间超过3秒的页面速度会流失超过57%的用户，57%的用户会在加载前3秒后离开，除非原因是她的电脑或网速。PV将减少11%，用户满意度将减少16%，对话将减少7%。亚马逊加载的每一秒都相当于每年损失16亿美元的销售额。在腾讯的工作经历中，我严格把网页打开速度作为业务质量的核心考核指标，直接对应用户体验。我建议你找一本客户关系管理的书，看看在客户关系管理的每个阶段如何提取客户创造的价值。虚拟可以变成现实！用户价值嵌入IT价值！2.技术体系（technology）技术体系就是Dev技术架构对应的系统。就是与研发建立一致的架构标准和服务平台标准，建立一致的架构可操作性，同时避免架构失控。这个地方的难点在于，很多公司缺少公共架构组，或者有的公司有公共架构组，他不负责实施实施，只谈架构。我提出的方案是：架构团队要承载应用技术架构的面向服务的指标，无论是自上而下的PaaS平台还是自下而上的组件服务。注意，我提到的术语是面向服务的应用技术架构。这就需要架构团队将生成的技术架构能力应用到业务技术架构中。谈论架构是最容易的。那么Dev技术架构体系跟我运维有什么关系呢？它决定了您的维修成本是大还是小，维修质量是高还是低，维修效率是快还是慢！否则，你只盯着运维平台，认为一切都是平台的事情。一旦技术标准到位，业务碎片就会消失！3.平台系统（platform）运维的平台系统，这个我在外面讲了很多。我也从平台的业务目标上展示了它应该是什么样子；我也从平台的功能架构上拆解了（到第三层），讲了运维平台应该是什么样子。但说实话，对于很多人来说，看到三层功能架构容易不知所措是可以理解的。所以我建议的重点是你从cmdb+持续交付入手，在IaaS层增加几个面向服务的组件，比如DNS/F5/操作系统安装等等。整体平台抽象为自动化系统和数据系统。自动化系统以持续交付为核心，数据系统以智能监控和运营分析为核心。平台不是工具！4、标准体系（standard）运维标准非常重要，很难建立一套统一的标准来适应所有企业。越靠近应用端越难统一，但可以抽象统一。在更贴近运维端的基础设施标准制定上，运维可以完全自主可控，比如硬件模型的标准化。但是，在应用的标准化方面，需要技术把控和效果呈现。技术手段的把控不仅是在运维平台上，比如应用的持续交付平台管理，还有在技术体系上，比如能力SDK/组件服务等。技术手段的作用呈现，偏向于数据能力。我们一直在讨论如何规范日志。其实可以建立一些技术标准，将日志分为几类，比如webserver日志/用户端日志/应用端日志/接口级日志等。在定义日志标准的同时，提供了SDK-基于能力。最后，要在平台上看到数据采集和呈现的效果。当数据用于驱动决策/驱动优化时，这是一个闭环。当天在现场也有同学提出了这个问题。关于标准实施的难度，其实有两方面的原因。一是标准的制定有问题，可能是错误的，或者是制定标准时没有考虑业务需求；二是该标准缺乏有效的技术手段进行管控。标准层级决定控制力！5.流程系统（process）我的流程系统不是流程系统。工艺系统是其中的一部分。还有规范和制度的要求，目标和路线图的设定等等。流程体系包括我们为了达到某个目标而设定的执行路径是什么。这个路径有两部分，一个是基于产品的执行路径；另一种是非基于产品的执行路径。在数据运维上，这个体现是显而易见的。在跟大家交流我们的EasyOps产品的过程中，我一直说我们的运维分析平台提供的产品如果不包含运维体系和规范的要求，那是一个无用的功能。另外，标准化的落地推广，如果有平台承载，也需要一个过程。这就是我理解的基于产品的执行路径。不基于产品执行路径，大到你的运维目标设定和分解路线图，比如运维平台系统的搭建；小到你的运维流程，比如事件流程，资源池管理流程等等。这个地方会沉淀一些制度和规范的要求，比如安全规范/事件规范/配置管理规范/发布规范/环境管理规范等等，大家不要怕规范，规范沉淀-《平台实施-》标准改进，这就是目的。运维流程不是运维流程！
