互联网时代运维价值的重塑

互联网时代运维价值的重塑

当今的互联网行业发展可谓风生水起，从传统的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的同学当然也要从思路、平台等方面去优化，比如建立带外网络集中维护和管理、基于日志的自动分析和报障、事件与问题管理等等。资源回收与资源分配是同等重要的环节，宗旨是能做到有需求时放、无需求时收，这块要考虑的是如何对资源利用状态的监管，如何快速回收，弹性伸缩。以上只是大概说了服务器资源管理这条链的内部闭环流程。实际上在职能团队内部，类似的业务支撑流程很多很多。这些流程内部往往需要运维人员去考虑管理思路、实施技术、综合解决方案等多方面。外部闭环体现在多团队之间的工作协作上了，拿一个例子来说：某游戏产品需求在国