要想做好运维就一定要跳出运维这个框框，从全局的角度来看运维，要考虑如何打造和体现出整个技术架构的运维能力，而不是运维的运维能力。这一点是根本，一定要注意。如果我们仍然片面地从运维的角度看运维，片面地从运维的角度规划运维，是无法走出运维低价值的困局的。
从价值呈现的角度看运维
- 运维基础平台体系建设
这块主要包括标准化体系以及 CMDB、应用配置管理、DNS 域名管理、资源管理等偏向运维自身体系的建设。这一部分是运维的基础和核心。
- 分布式中间件的服务化建设
在整个技术架构体系中，分布式中间件基础服务这一块起到了支撑作用。这一部分的标准化和服务化非常关键，特别是基于开源产品的二次开发或自研的中间件产品，更需要有对应的标准化和服务化建设。
- 持续交付体系建设
持续交付体系是拉通运维和业务开发的关键纽带，是提升整个研发团队效率的关键部分。这个部分是整个软件或应用的生命周期的管理体系，包括从应用创建、研发阶段的持续集成，上线阶段的持续部署发布，再到线上运行阶段的各类资源服务扩容缩容等。
- 稳定性体系建设
软件系统线上的稳定性保障，包括如何快速发现线上问题、如何快速定位问题、如何快速从故障中恢复业务、如何有效评估系统容量等等。这里面还会有一些运作机制的建设，比如如何对故障应急响应、如何对故障进行有效管理、如何对故障复盘、如何加强日常演练等等。同样，这个环节的事情也要依赖前两个基础体系的建设。
- 技术运营体系建设
技术运营体系也是偏运作机制方面的建设，最主要的事情就是确保我们制定的标准、指标、规则和流程能够有效落地。这里面有些可以通过技术平台来实现，有些就需要管理流程，有些还需要执行人的沟通协作这些软技能。
最终通过这样一个规划，把团队以虚拟形式重新规划了不同职责，分别负责基础平台体系、分布式中间件服务化体系、持续交付体系和稳定性体系，基本就是上述的前四件事情。
对于最后一个技术运营体系，这一点作为共性要求提出。团队每个成员都要具备技术运营意识。具体来说，就是要能够有制定输出标准的意识和能力，能够有规范流程制定的能力，同时能够将标准和流程固化到工具平台中，最后能够确保承载了标准和规范的平台落地，也就是平台必须可用，确实能给运维团队或开发团队带来效率和稳定性方面的提升。这些对个人的要求还是比较高的，要有一定的规划、设计和落地能力，能具备一整套能力的人还是少数，目前这块还是靠团队协作来执行。
从团队需求和运维价值呈现层面成立的虚拟组织，从实际的人员管理以及技能维度来划分的话，基本会分为如下几个岗位：
- 基础运维，包括 IDC 运维、硬件运维、系统运维以及网络运维；
- 应用运维，主要是业务和基础服务层面的稳定性保障和容量规划等工作；
- 数据运维，包括数据库、缓存以及大数据的运维；
- 运维开发，主要是提供效率和稳定性层面的工具开发。
这个实体的组织架构，相当于是从技能层面的垂直划分。基础运维更擅长硬件和操作系统层面的运维；应用运维可能更擅长业务稳定性保障、疑难问题攻关以及技术运营等；数据运维就不用多说了，DBA 本身就是专业性极高的一个岗位；运维开发则是支持上述几个岗位日常运维需求的，是否能将人力投入转换成工具平台支持，就看这个团队的能力。
实体组织架构，相当于一个人的骨骼框架，但是价值呈现层面的虚拟组织，就更像是一个人的灵魂，体现着这个人的精神面貌和独特价值。