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

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

Chapter 2? 运维团队价值的提升

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

1.?? 从操作到优化

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

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

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

2.?? 从实施到规划

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

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

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

3.?? 从粗放型到精细化

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

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

（编辑：ASP站长网）