再比如对服务器资源利用率的控制可以非常精细化,某业务部署了很多服务器,我们从成本管理的角度去看,使用的这些服务器资源与其业务量、用户量匹配吗?实际的负载达到多少了?有多少比例的机器是长期处于低功耗状态?通过什怎样的部署优化措施可以减少成本?但我们把这些数据监控起来后,经常发现这样的情况：某业务共部署了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.?? 优化意识

（编辑：ASP站长网）