互联网时代运维价值的重塑当今的互联网行业发展可谓风生水起，从传统的ICP纯内容生产到移动互联O2O连接线上与线下，再到成为国家发展战略的互联网+深度拥抱各行各业，整个互联网浪潮下催生出来的众多业务形态、无数产品和创新的技术都在影响和改变着这个世界。

而支撑起这整个互联网基础系统稳定运转的人是谁？如当前一款游戏产品PCU达百万，一个web站点pv量上千万，一个app的月活跃帐户达数亿，这些业务繁荣昌盛的背后有哪些工作要做？我掐指一算，大概涉及到数据中心、网络、服务器等基础架构的规划、建设、运营及服务管理，涉及业务架构评估、部署方案优化、运行环境设计、容量与成本管理、可用性与连续性管理、故障恢复与维护等诸多方面，以上工作都需要运维这个特殊的职业群体来承担。

运维作为业务发展的后腰团队，一直致力于如何更快更好更省地支撑线上业务，既然是做业务支撑，得随着业务的发展而发展，运维整体水平也往往与业务发展状况和体量正相关，如国内BAT这些巨头互联网企业，其运维在标准化建设、规范化实施、资源规划和运维效率质量等方面均已成体系，并基本能代表业界最NB水平。

在一些中型互联网企业，运维团队和支撑体系可能正处于建设和发展阶段，业务发展稳中有进，此时运维侧关注的是如何提升效率、保障质量并控制成本以及自动化建设，当然最关键的是运维管理思路的转变，工作界面切分、业务解耦、降低人员依赖度等等。

在小微互联网企业内部可能问题并没有这么复杂，甚至DO都不需要分离。

但本人认为无论在哪种业务场景下，在如今互联网行业如何猖獗、用户如此海量的背景下，运维的价值需要输出到产业链的上游中去，创造更多的空间。

那么问题来了，运维往往是企业内部的屌丝团队(不挣钱花钱又最多，起的比鸡早睡的比鸡晚，甚至颜值普遍偏低)，如何输出更多价值，以本人有限的经验来看，得练内功，即通过提升运维整体水平来输出更多价值，简单归结为以下三方面Chapter 1 运维支撑架构的进化面对业务全面发展，用户量膨胀，线上服务不断增多，从运维整体支撑架构上，该如何转变思路并扩展支撑能力?本人以为下述几点措施可重点考虑。

1. 界面切分这块主要考虑的是运维人员组织结构的问题，当前的互联网运维涉及的专业技术学科非常广泛，从大的方向来讲有两类，一是基础架构运维：这其中包括了IDC、网络、服务器以及这几块纵向切分为规划、建设、运营和ITSM。

这一类总结起来至少是三横四纵，十二个专业领域，当然如果是再深度细分，如IDC这一块又涉及基建、电力能源、制冷、暖通等等更多技术领域，总之这一大类不少于少林七十二绝技。

第二类是业务运维，这一块是贴近业务侧，涉及的内容如下业务运维人员接触的是OS之上的各种应用系统，需要运维人员快速理解业务逻辑架构、前后端部署架构并深入业务逻辑细节，偏向于开发层面，涉及到的基础IT技能包括：系统架构与原理、TCP/IP 协议栈、dns/dhcp等各种网络服务、lvs/apache/redis/zeromq等各种开源组件、puppet/fabric/ansible/salt等各种管理工具、数据库、脚本编程、HA高可用、硬软件性能评估等等太极108式。

世间可有万中无一的奇才既精通少林72绝技又习得武当太极108式？曾经我想说我就是这种人，结果被一巴掌拍倒在地。

但事实证明是有的，不是某个人而是团队。

如此多的细分工作需要分配到组织架构的各个团队中去。

当业务不多，体量较小的时候可能几个人就可以搞定，一人多职纵向支撑也不会有太大问题，但业务剧增，体量巨大时，对基础架构容量与健壮性、资源交付效率、维护与实施的质量等各方面都有着更高的要求，具体体现在专业深度和中长期规划能力上。

此时可梳理当前运维工作涉及的所有块面按专业进行横向切分，定义各团队的工作界面，以高效的方式横向支撑公司各业务。

典型的组织方式：首先整体上切分为基础架构团队和业务运维团队，基础架构团队负责资源的规划与提供、硬件环境的管理维护工作，最终向上交付的是可用的OS。

业务运维团队负责OS之上的业务相关应用运行环境的设计、应用部署结构的优化和实施、线上应用的管理与维护等。

界面清晰职责明确是可执行落地的前提，不要出现应用维护人员还需要去装机器、配置网络路由器、做存储分区，搞机房的同事还需要去管理应用进程状态、部署配置业务应用等情况。

基础架构团队再细分下去典型的又可分为IDC团队、网络团队、SA团队、监控与安全等，根据实际情况而定了；业务运维团队内部可按业务类型或上游研发团队来细分，具体可视人员规模业务体量技术类型等情况去定了。

总之运维工作界面的切分目的是为合理组织人员，优化分配工作，明确职能和提升专业深度，粒度和维度视企业环境可灵活配置。

2. 流程整合流程化是为了保证工作的质量。

定义工作界面后，各职能团队完成的是某个节点，团队通过内部流程来实施作业任务，团队间通过外部流程有序串联，完成某个具体业务逻辑的工作。

对于流程的整合本人认为做到内部闭环和外部闭环是关键，内部闭环指某个职能团队内部在实施具体任务过程中的闭环，如IDC团队在服务器资源供应中整个流程链条一般是：单服务器采购这一块涉及到的东西又很多，供应商管理、资源评估与规划、成本管理等。

生产这一块可理解为把金属物体变成对业务可用的OS资源，服务器从出厂到上架到灌OS再到软环境的标准初始化等等，这一块在海量业务需求下对产能、资源供应效率的要求很高，传统的手动安装方式当然满足不了，于是IDC的同学要考虑批量快速生产的方案如kickstart，本人接触最高产能的部署系统是每小时部署5000台物理服务器OS，当然随着虚拟化云技术的应用，彻底改变了传统的基础架构资源生产和配置方式。

调配这一块也是需要IDC同学去考虑的重点，如何管理业务需求，如何分配服务器资源，如何管理信息，服务器资源的调度等，站在更高的层面来说这一块就是如何灵活调度资源来满足业务需求，且能合理利用与控制成本，以下措施可以一试：维护这块是基本工作，其中涉及的处理流程、技术细节与硬件设备本身关系很大，本人接触到的dell/hp/ibm/Lenovo/华赛等各厂商的在用主流型号服务器达100多款，日常维护这块的工作量很大，作为IDC的同学当然也要从思路、平台等方面去优化，比如建立带外网络集中维护和管理、基于日志的自动分析和报障、事件与问题管理等等。

资源回收与资源分配是同等重要的环节，宗旨是能做到有需求时放、无需求时收，这块要考虑的是如何对资源利用状态的监管，如何快速回收，弹性伸缩。

以上只是大概说了服务器资源管理这条链的内部闭环流程。

实际上在职能团队内部，类似的业务支撑流程很多很多。

这些流程内部往往需要运维人员去考虑管理思路、实施技术、综合解决方案等多方面。

外部闭环体现在多团队之间的工作协作上了，拿一个例子来说：某游戏产品需求在国内搭建一个大区，这个就需要运维多个团队来协作了，简化的流程如下：业务运维团队进行环境的设计，依据网络覆盖质量数据和用户分布数据，选址服务端该放到哪个地区、哪个运营商。

依据性能测试数据和用户量预估数据来确定需要多少机器资源和带宽资源；资源需求提交给基础架构团队。

IDC资源团队根据提交的需求进行资源的匹配，或调度或采购或其他方式来保障资源的按时到位。

SA团队进行资源的生产，可能是利用工具平台完成指定OS的部署，深度加工并配置，最后进行标准的初始化操作，交付给业务运维团队。

业务运维团队分发并部署应用，当然其中设计到的部署方案、实施技术、性能评估等每个环节均需要细致考量。

监控团队部署监控环境，完成对OS层面、业务层面各项指标的实时监控展现。

安全团队需要规范OS层面、软件应用层面的安全基线，并实时监测线上应用的安全状况。

流程的整合，需要看每个企业内部运维的职能团队、工作界面划分以及承载的业务逻辑，尤其对于全业务运维的团队，流程的制定很重要。

一个好的流程，既要合理又要尽量简单，较大的运维团队要明确的一点是：保障一切正常运转的是规范的流程，而不是个人。

3. 自动化实施老话题了，对于业务量稍微上来、网络与服务器规模稍大一些的企业，都已经意识到这点的重要性。

运维不做自动化，生活不会幸福。

关键是怎么做，如何整体规划并大方向布局，见过很多运维自动化的实施方案，涉及运维工作中的各类场景。

自动化实现方面大概有三个层次：一是脚本阶段，依靠运维自行编写shell、bat、perl等各种脚本去完成自动任务执行，批量处理，功能封装的好的话，用起来也挺省心省力。

这种方式在管理规模较小的环境时没太多问题，但对于成千上万机器规模，或处理逻辑较复杂的情况时，显得鸡肋了。

二是依托ITIL理论建立起来的适应运维各种业务逻辑的自动化系统和工具，这也许是当前绝大多数互联网企业采用的方式。

整个基础架构和业务运维这块盘子，从IT管理的角度来做运维，并结合实际状况寻找最佳实践，如做信息管理我们需要CMDB，CMDB主要用来管理线上线下信息的对称性和准确性，在此基础上给其他各类业务系统提供一致的数据输入；做事件管理我们需要事件管理系统；还有需求管理这块，给内部和外部提供统一的需求入口；还可能有作业平台，帮忙业务运维团队自动化完成相关运维任务，此外安全、监控等等众多的垂直型功能系统。

这些自动化的系统确实能很好的帮忙运维去掉重复单调的工作、减轻日常工作负担，并能量化工作和为优化质量指标提供数据支撑。

但多数企业在实施这些自动化系统中，往往是缺什么补什么，整个自动化的实现分散在多个独立的系统中，且可能没有接口，数据不能互通，需要运维人员人工对接多个系统来完成某个运维场景的自动化实施。

如一个发布任务，可能需要先到需求系统打开电子流，根据里面的信息去仓库系统拉取版本，然后去分发系统分发版本，去监控系统屏蔽告警，然后去发布系统做相应的操作等等。

这类垂直功能的相互独立的自动化系统确实能帮助运维人员解决很大一部分问题，在效率上有很大提升，使得运维的工作基本全部实现线上化。

但这够吗？可以想象拥有百万机器，数万款线上应用的规模，这种方式还有待优化。

三是智能化的整合平台，这类运维自动化的平台目前接触到的只有腾讯蓝鲸了，它是一个横向的PAAS平台，为游戏运维领域提供了整套统一的解决方案，基于平台，运维可以自由定制需要的工具，可按各种运维场景实现一键式作业，前端几乎可适应任何业务，后端支持的自动化操作几乎涵盖所有，运维人员需要做的不是运维，而是任务设计。

自动化的建设水平在行业内差异化还是明显的，如果处于运维自动化刚起步的阶段，那么本人的建议是：从整体上规划，基于ESB思想尽量让平台与业务逻辑解耦。

如上所示，我们先抛开基础架构侧的自动化不论，对于业务运维而言，整个工作面无非就是对业务运营环境的各种操作、配置，已经对业务应用程序的管理，简单来说就是OS层和应用层，要做自动化实施首先得有准确对称的数据，然后需要一个统一的管控平台，能并发的控制和操作远程大量主机，这解决了OS层面的操作问题，但需要管理应用层面的东西及需要与应用的研发人员确认相应的接口，对于开源组件而言一般不会有什么问题。