互联网时代运维价值

互联网时代运维价值

最近跟朋友聊起工作，我说干运维的，他略显诧异的说这行业感觉有点low啊，好多专科技校、蓝翔电脑培训出来的孩子都搞这个。嗯，这朋友倒是蛮心直口快的，只好无奈一笑，不以为意。后来一想，这也许就是当前运维从业人员面临的一个尴尬境地，给人的职业形象就是呆板和猥琐，要么是目光呆滞地蹲机房拆机器，要么是焦头烂额的处理各类业务故障，价值点不易被外界看到和认同。

当今的互联网行业发展可谓风生水起，从传统的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层面的操作问题，但需要管理应用层面的东西及需要与应用的研发人员确认相应的接口，对于开源组件而言一般不会有什么问题。因此如果是从零开始做自动化，个人认为CMDB、管控平台、业务管理工具这三部分是地基。在此基础之上，可以针对运维各类场景和业务逻辑去做相应的垂直功能系统，再上一层，可以使用流程引擎之类的组件来实现业务运维流程的纵向整合，最终实现运维场景化一键式作业。

运维自动化的宗旨是把运维人员的专业经验和技术知识转化为工具，让工具去做事情，让人去享受生活。

4.   标准交付

运维在工作切分和实施流程化之后，时常会出现沟通障碍、信息不同步不对称、权责划分不清的情况，导致的结果可能是酿成各种悲剧惨剧、相互推诿、甚至多年兄弟基情破裂，本人认为这种情况的根源应该是团队与团队之间没有交付标准，对应的流程的上下游没有入口规范和出口规范，这没什么好说的，解放方案就是针对业务流程中各个节点制定好交付标准，这也是衡量团队工作质量的重要指标。线上应用出了状况，排除外界因素外，定是内部实施中某个环节没有达标，标准可能是这样的：

运维涉及的工作纷繁复杂，没有交付标准很难确保万无一失，各团队、各流程节点均按标准交付，实际出状况的概率会降到最低，且团队之间的协助沟通也会顺畅得多。

Chapter 2  运维团队价值的提升

如前面所述，运维团队往往处于整个业务发展的幕后环节，在价值体现方面也较难让台前的观众们看到，但运维团队自我意识要清醒，在整个业务发展中贡献的价值是不可或缺的，且要不断提升自身价值，本人以为下述几方面对运维团队价值提升有很大帮忙。

1.   从操作到优化

从运维工作中的某个点来说，运维所做的工作最终都映射到某个操作上去，如对硬件设备进行的操作、对OS环境进行的修改、对程序文件的各种配置与更新、对数据的管理操作、对系统平台的各种维护等等。这种工作特性往往会让很多运维团队陷入埋头苦干，重复劳动、思维僵化的境地，尤其是在管理风格较封闭的团队里，一切的流程和实施方案均已被定死，没有全员参与感，下面的执行团队根本不知道中心整体规划是什么，整体目标是什么，也不会去为团队整体的发展做考虑，只能机械的完成上级交待的操作任务。

记得看过一部叫《雪国列车》的科幻电影，在一列号称永动机供能的高逼格列车上，某个小零件坏了且维修空间狭小，于是把一定尺寸的小孩抓过去当成没有生命的金属工具使用，小孩被训练得僵化服从，并始终重复一个动作在一堆机械中完成某个特定的操作，从而维持整辆列车的继续前行。看后不禁毛骨悚然，我们运维人员也该思考一下，当前你是否也处于这种状态？当然运维操作是基本工作职责，但运维团队该思考的是如何从这些操作任务中提取共性、去重、优化操作流程从而自动化去完成，大的平台系统暂且不考虑，小的工作上的优化无处不在。

比如在服务器资源初始化环节，业务运维针对提交过来的服务器进行业务相关初始化配置工作，各团队运维人员针对不同业务各自进行这项操作，繁琐费时，还不一定保证质量，此时去梳理各业务初始化需求，发现绝大部分是共性的，将这些共性的东西提取出来，再随便做个初始化工具，将工具集成在OS部署环境中，这样OS生成出来后就自动完成各业务相关的初始化工作了，最终交付给业务团队的是标准的统一的OS环境，大家都省时省力且质量还高。再举一个例子，各业务需求CDN资源，且各自上传到各自对应的site，线下的域名站点信息、权限目录信息等各业务团队分别管理，在信息沟通和管理上较费事，如做一个优化，将前端做成统一平台，后端让系统去自动完成差异化分发，再加上覆盖率、下载率、带宽等数据的统计分析等等则是较完善的一个CDN管理平台了。类似的可优化方面太多太多，运维人员需要去思考如何优化，而不仅仅是完成操作任务，当发现一切细节都赏心悦目的时候，团队的价值自然就提升了。

2.   从实施到规划

规划工作讲究的是长远计划，早做打算未雨绸缪。在我们的运维工作中，业务需求是不断变化的，满足有计划性的通用型的需求远比满足零散的个性化的需求要容易得多，运维规划能力体现在以下两个方面：

• 整体把握长远打算：拿游戏运维工作来说，最新的运营计划时间节点是什么，当前业务工作重点有哪些，问题和风险以及相应的解决方案是什么，未来一个月、一个Q、甚至未来半年的工作重点是什么，实施计划是否已做好，要非常清楚自己该做什么，而不要让别人来提醒你该做什么。
• 化零为整：业务侧的需求经常给人的感受就是，突发性的、零零碎碎的、个性化的，有时运维人员白天盯16个小时都没需求找你，到你睡觉的那几个小时偏偏就有需求找来了，事情很小可能最终就只是上机器敲个命令而已，但业务说很急很急，这种情景相信每个运维都遇到过不少。那么从运维角度如何去规划这些零散的琐碎的需求，完成的同时让工作变得轻松。这个是需要与需求方协商一起来解决的，需求入口的规范性、SLA和达标率的明确制定、通过系统平台自助实施的方案等等可以较好的解决此类问题，最后你会发现其实最终那些不可控的非常紧急的突发需求其实并没有那么多，计划性的常规需求是占绝大部分的。

这些导致你工作不爽的问题，运维自己不去考虑没人会替你考虑，抱怨是没有用的，要从多次实施的经验中去总结并合理规划你的工作。

3.   从粗放型到精细化

精细化这块要做起来，得有度量手段和数据的采集，运维的工作实现线上化后数据的获取是便捷的，在此基础上再做容量、成本、业务可用性、工作量、工作质量、达标率等各项指标方面的分析也较为容易，依据这些数据来量化工作、优化流程和实施细节，精细化的关键是一切基于数据。有些运维团队可能觉得我支撑的业务量不大，人员也不多，没有精力去做精细化方面的工作，粗放型的模式实施下来也并没有太大问题，如应用服务器配置经常是根据运维经验或类对其他应用直接拍板、系统承载能力和用户量预估没有实际数据支撑、应用部署结构没有标准模型、运维工作评估没法量化等等。个人理解，精细化的思路是恰到好处、精确匹配。

如在进行业务资源调配时，考虑业务逻辑模型和各模块性能数据，差异化的资源分配策略能做到恰到好处的资源利用，而不是一把抓使用同一规格的资源配置的粗放方式。

再比如对服务器资源利用率的控制可以非常精细化，某业务部署了很多服务器，我们从成本管理的角度去看，使用的这些服务器资源与其业务量、用户量匹配吗？实际的负载达到多少了？有多少比例的机器是长期处于低功耗状态？通过什怎样的部署优化措施可以减少成本？但我们把这些数据监控起来后，经常发现这样的情况：某业务共部署了1000台机器，有50的机器长期处于低负载状态(比如cpu峰值长期低于5%、内存峰值长期低于20%，io峰值长期低于10%等等)，但业务运维还在扩展机器资源，说性能达不到要求，为什么？再深入分析发现30%用于接入模块的机器是高磁盘IO，低cpu配置，40%用于中间逻辑模块的机器是高cpu、低内存、高IO配置，30%用于存储模块的机器是低磁盘IO、低内存、低cpu的配置，一句话部署结构未精细化、资源配置没有数据支撑。当然你也可以粗放的每个模块全部配置高CPU、高内存、高IO的机器资源，也不会对业务运行有什么影响，但这样真的好吗？

以上只是运维工作中的很小的可以精细化的例子，类似的非常多，从宏观角度看如运维人力的分配、时间的分配、各类标准模型、各种实施流程的完善等等都值得运维去深挖。

4.   从CASE-BY-CASE到统一解决方案

运维所支撑的上层应用是多种形态的个性化系统，如游戏业务、web业务、音视频业务、搜索业务等等，逻辑架构、技术特征、部署方案、运行环境需求等不尽相同。涉及的运维场景同样是千变万化、需求各异，如发布、变更、迁移、合并、备份、故障处理等等各方面。在业务量少的情况下，通过case by case 方式运维可以很好的支撑起几块产品的维护工作，针对每款产品组建团队搞一套流程并配备相应的工具即可，但随着业务的发展，想象下几百款到上千上万款线上产品同时运作的情形，case-by-case是下下之策，因为资源是有限的，人员也不可能无限增长，这个时候你可能要去寻找统一解决方案，目标是能屏蔽前端多款业务的差异性，建立统一的流程和平台来完成相同场景的运维任务。这个平台是遵循ESB设计思想的，提取共性解耦前端业务逻辑，实现支撑一百款业务跟支撑一款业务付出几乎同等的运维成本。一个简单的抽象如下：

支撑业务量少时，以上模式没有太大问题，为各业务做定制化保姆式运维响应。当业务量增长到一定程度，明显人员和组织架构不可能成正比无限增长，此时可能需要如下这种横向支撑的模式

当然做到这个程度，有很多前置工作要做，如标准化的建设、自动化的建设与持续整合、运维工作的高度抽象与持续集成、甚至可能需要从研发、测试这些上游流程上去做改变。这是个从小工作坊到工业化流水生产线的过程，革命性的转变非一日之功。

Chapter 3  运维人员的自我修养

运维人员在专业技术上的积累这个是基本功了，凡是IT领域的东西都该去多了解一些，主要是技术应用方法了，对于解决常规的业务需求可以拿来即用，对于需要深入理解的方面还是要系统性的学习，建议是去搞清楚整个来龙去脉、找到根源和理论基础，这块涉及的东西太广泛，就不多说，除此之外的以下方面本人觉得往往对个人的成长起到更大的作用。

1.   改善沟通

稍微有些职场经验的人都知道，很多时候问题的关键不在于资源、路径或者是技术问题，而在于人的问题，你所在的部门领导、你的leader、流程上下游相关的人、业务相关接口人等等，这些在你处理某个事务时有交集的所有人都可能影响到整个事务的成败。既然是人的问题，就需要通过沟通来解决，在运维工作中，我们涉及的业务接口人、流程相关方、细节信息确认方等经常是错综复杂，有时甚至斡旋于多个团队之间太极打的风生水起，还是搞不清楚这事谁负责，到底该找谁解决。关于沟通方面体会最深的有以下几点：

• 一次性原则：说一件事情，用最简短的语言把整个事情描述清楚，且让人没有疑问，不要挤牙膏式的给信息。在团队协作做某项实施时，经常遇到这类沟通：

A：那谁一会帮忙把DB重启下

B：哪个DB？

A：xxx业务的一区的DB

B：一区DB机器有3个实例，是哪个？

A：3310实例啊

B：现在重启吗，还是等你通知？

A：等我通知。。。

这种沟通可简化为：

A：等我这边把前端停掉，你帮忙将xxx业务一区DB机器(192.168.1.1)的3310 实例重启下，等我通知再操作！

B：好的。

简化，表达清楚，简单的事情一次性说清，不留疑问，配合你的人一看就明白要做什么。

• 确定正确理解：这个是双方面的，当你更他人沟通事情时，确保他正确理解了你要表达的，没有任何疑问，有时需要再三确认他真的理解了，举一个例子：本人曾经在电信IDC与动力人员配合做电力割接，由于是两路市电，UPS出来到列头分A/B路接服务器的双电源，所以只要两路电不同时停则服务器不会断电，已经跟动力实施人员沟通好，一会先停A路电，割接完成后恢复A路然后再停B路电，他表示已经懂了，结果在实施的时候他还是将A、B路一起停了，五六双眼睛盯着他，表示无限惋惜…。后来想想，如果当时直接在空开上做个标记，按实施顺序编号给动力实施人员讲解可能就不会出问题了。有时他人的理解跟你想表达的完全不同，确定他理解的是你想表达的很重要，尤其对于运维这种高危职业而言。

• 找对沟通的对象：这个需要运维人员先熟悉整个组织架构和工作界面划分，什么事找什么人，这块内部沟通还好，在外部沟通中往往出现问题，导致非常简单的事情兜了好几圈都没解决，所以找对那个真正负责此事的人来配合你的工作，如你不清楚外部团队的内部分工，就找外部团队接口人。
• 要主动不要被动：运维作为业务支撑团队，我们的工作安排和计划均基于业务侧运营侧的相关计划，这就要求运维侧要主动去跟上游或周边团队沟通，尽早拿到上游信息，尽早着手安排相关工作，凡是赶早不赶晚。运维工作中其实最难把控的就是突发紧急情况、临时需求变更等等，主动沟通可有效减少这类情况发生，并使运维工作变得有序合理。

一个好的运维一定是擅长跟各种技术和业务团队沟通的好手。

2.   优化意识

运维的工作往往很杂、很细、很乱，可能你每天都在处理重复的需求、做着重复的事情，埋头在一堆单调重复的琐事之中无法自拔，基本没有时间去学习新的知识和技能，我相信每个运维都遇到这些情况，每天加班加点、且没有成就感，也输出不了什么价值。如果到了这种状态，我觉得往往是优化工作做的不够。优化，可大可小，从自身出发，可先寻找个人工作中的优化点，一点一滴去做，什么是优化点，简单来说工作中你的痛点就是优化点！很多时候我们需要放下手上的琐事多做总结和思考：

• 为什么天天加班事情还是做不完，如何提升效率？
• 为什么每天做重复的事情，有没有固化的自动的方案？
• 为什么总是在救火的时候出现问题，预案和演练平时有做吗？

小到某个特定的执行细节、大到整个流程体系，甚至要推动多个团队来配合，把这些让你感觉费力的不爽的地方变得通畅，省时省力且质量还能提高，这些应该是最能体现运维能力和价值的地方。

如果运维工作中某个环节让你很不爽，想想问题在哪里，有何可行的优化方案，然后去推动和实施，抱怨解决不了问题，持续优化是很重要的意识，尤其对于运维从业者而言。当然有人可能会说这个问题领导或其他团队不重视，推不动，无法优化，这种情况第一可能是你没有让别人看到优化方案的闪光点和预期收益，只对你方有利却把麻烦抛给了他人，没有制造双赢或多赢的局面，可以再深入下方案，相信对大家都有利的事情都会愿意去做。第二可能是管理上的问题了，公司制度使然，这种情况应该是极少数，就不去挑战了，除非你能把老板优化掉。

3.   规划能力

没有人会一直做运维执行和操作，到最后其实更多的是做运维规划，尤其是在做海量业务支撑时，前期的规划往往在很大程度上决定了后期的建设和维护成本。

• 如何制定服务器资源供给与调度计划？
• 如何规划网络架构以适配多种形态业务的需求？
• 某业务上线各节点阶段性的工作安排是什么？
• 自动化建设的整体规划和实施路径是什么？
• 如何搭建运维团队，规划人力分配？

大量的运维实施经验和积累后，对于运维中的事务，多从规划角度去考虑，往往能做得更好。

4.   学习与分享

这块就不多说了，运维是一门实践性很强的科学，专业众多，保持学习的心态很重要，分享亦是一种美德，更是个人积累和成长的重要方式，每个人都有自己独特的经验和感悟可以分享出去，共同成长。

 

说了这么多，不知能否改变我那位朋友觉得运维很low的印象。总而言之对于运维价值的体现和提升有更多的事情要做，本文只是杯水车薪。最近看《权利的游戏》，整个影片构建了一个宏大且残忍的史诗级魔幻世界，里面有个置身七国纷争之外的特殊群体——守夜人，一个人只要是失去生活目标了、堕落了、不被社会认同了、或者感觉活腻了，你还有一个地方可以去，那就是加入守夜人团队，从此将摆脱一切身份，洗去一切罪孽，断掉一切念想，活在另一个世界为七国守卫绝境长城。

守夜人有非常霸气的誓词，以下献给各位运维同仁：

Night gathers, and now my watch begins. It shall not end until my death. I shall take no wife, hold no lands, father no children. I shall wear no crowns and win no glory. I shall live and die at my post. I am the sword in the darkness. I am the watcher on the walls. I am the fire that burns against the cold, the light that brings the dawn, the horn that wakes the sleepers, the shield that guards the realms of men. I pledge my life and honor to the Night's Watch, for this night and all the nights to come.【长夜将至，我从今开始守望，至死方休。我将不娶妻、不封地、不生子。我将不戴宝冠，不争荣宠。我将尽忠职守，生死於斯。我是黑暗中的利剑，长城上的守卫。我是抵御寒冷的烈焰，破晓时分的光线，唤醒眠者的号角，守护王国的坚盾。我将生命与荣耀献给守夜人，今夜如此，夜夜皆然】。

转：http://www.yunweipai.com/archives/5025.html