关于我们

高效运维最佳实践七字诀,不再憋屈的运维!(1) - 51CTO.COM

做运维的那么多,快乐的能有几个? 我们那么努力,为什么总感觉过得那么憋屈、苦闷?做的事情那么多,为什么业务部门、直接领导和公司貌似都那么不领情?怎么做才能自己更加开心些? 高效运维最佳实践七字诀,不再憋屈的运维! 本专栏的主线实际是一个运维人员的十年成长史,从菜鸟到运维总监。但不是基础技术教学,也不会在运维技术的某一方面过深涉及。更多的是应用技巧、实践经验及案例剖析。专栏中的系列文章,包含作者在运维各个细分领域的技术和个人成才的心得体会。因此也可以成为广大运维朋友的工具书,伴随大家从初级运维成长为高级技术型运维管理人才。 技术专栏就非得那么中规中矩么?咱这个专栏试图以更轻松活泼的文字,徐徐道来,就当是个老朋友,轻松愉快中,希望能给大家带来收获和启发。 前段时间有位IT大佬在网络上发声,我这么有钱,为什么不幸福?诚然,有钱是幸福的最重要条件之一,但有钱就一定幸福么?真的是充分必要条件?当然更悲催的是运维行当,技术好是被认可(幸福)的最重要条件,但技术再好,外部门不说咱们“坏话”,已经是很不错的了。 1. 什么是高效运维 我们收集了一些来自外部门对运维的印(tou)象(su),如下图所示。其中,大家看是否也多少有自己的影子? 高效运维最佳实践七字诀 往往看自己都很美,但从外部门来看,槽点多到乃至无力吐槽。首先,做事情不专业,人为事故多(更多是低级的人为事故);很多时候,都是我们业务部门告诉运维,运维才知道发生故障了,而且故障解决时间过长;做个调试,老超出调试时间,超时也不说,是不是完成了也不知会一声;部门内老玩踢皮球的游戏,做个需求,老让我挨个找人;申请个服务器,老费劲了,扔我一个申请表,当自己是衙门呢?或者扔我一个技术文档,我哪看得懂? 专业、热情、方便、快,这是为根治上述各种疑难杂症,经多年自我治疗并综合各方经验,得出的高效运维七字诀。我们用一个简单的公式来表示高效和专业的关系。专业是高效的基石,否则无从谈起高效与否,而技术是专业的基石。但这恰恰也是运维技术人员的误区所在,误以为,技术比较强,就足够了,并因此而忽视其他重要方面。 实际上,对外部门而言,运维是个黑盒子,是一个输入输出的关系:外部门提出需求,运维给出结果:完成、或未完成。本质上而言,外部门不关心(也无法关心)我们采用什么技术来实现的,只关心是否如期完成。 合理的流程规范,就像血液,能让部门稳定而高效的运转,大家都觉得开心,这也是专业与否的重要组成部分。但如果希望做到高效运维,良好的客户界面、合适的方法技巧,也非常有必要。这就像网站的UI,给人感觉舒服了,后面很多事情也能轻松愉快、顺理成章地进行。 2. 为什么难以做到高效运维 做不到高效运维,公司和业务部门不满意,上级领导不满意,自己也不满意。原因很多,我们从管理者和员工角度分别来讲。 ● 糟糕的分工及连环反应 发生在中小公司的糟糕情况,往往从不明确的分工,开始悲剧之旅。有些游戏创业公司,刚开始时运维人员也就2、3个,基本每人都得会运维的各个工种,游戏运维、网站运维(Nginx/PHP等)、数据库运维(MySQL等)、系统运维(Linux/Windows等)、服务器上架、故障报修、甚至做网线。 公司业务扩大很多后,如果运维组织结构不随之而变,分工不明确,就会发现大家都在疲于奔命,什么都会的结果就是什么都不精。在运维技术如此庞杂的今天,就是把人活活的架在火上烤。这样引发的是多米诺骨牌效应:分工不明确 —> 职责不清楚 —> 考核不量化—> 流程不合理—> 缺规范 、少文档。 ● 做vs说的困境 一般运维技术人员都不善于沟通(至少表面上,虽然大家都普遍有火热的心,呵呵)。在微信、QQ大行其道的今天,这个问题变得更严重,而不是减轻。这也和工作性质有关,想想,一天到晚和服务器说话的时间,比和人说话时间都多。 另外,从人脑结构来看,做和说两难全,也是合理的。控制计算、推理能力的是左脑,而表现力等由右脑控制。如果强行要求会做还会说,说不定会导致紊乱、崩溃甚至“脑裂”呢,呵呵(当然,这个问题也是有解决方法的)。 更严重的是,很多同学没意识到自己的沟通表达是有问题的,说句话能把人呛死,也不知道如何有效表达。这样就谈不上热情了。 ● 资源错配 管理者和员工都可能存在资源错配的问题。对管理者而言,包括人员错配和时间错配,员工主要是时间错配。 管理者如果把错误的人安排在错误的岗位,那么注定是个错误。例如,某位同学喜欢钻研技术,不喜表达,非得让他作为和外部门的接口人,那自然费力不讨好,大家都不开心。 管理者的时间错配包括三种情况。 1)沉迷解决技术问题。这一般发生在刚从技术岗位提拔为管理者的时候,忘记自己是管理者了。解决复杂技术问题,能带来愉悦感,否则就是挫折感。于是遇到技术问题时,非得死磕到底,然后一周过去了,而部门其他同学却放羊一周。 2)一心扑在管理上。这又是一个极端了,忘记自己的技术身份。把自己变成一个项目经理,整天只关心时间节点,不关注技术人员的小情怀,不协助他们解决具体的技术问题。 3)沉迷单个业务模块。这是另一个特例。一般发生在内部提拔时。例如某位同学,之前是DBA组的负责人,提拔为运维部经理后,还是习惯于抓其擅长的数据库工作,这也是不应该的,否则就没必要提拔了嘛。 员工的资源错配主要体现在时间安排上。事情多了,分不清轻重缓急,没有一个合理的排序原则、指导思想;混淆技术进步和工作要求(有时过分追求技术进步),简单的问题复杂化,降低客户满意度。

分享


相关内容