BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

高效运维最佳实践(02):员工的四大误区及解决之道

| 作者 萧田国 关注 2 他的粉丝 发布于 2015年3月4日. 估计阅读时间: 19 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

专栏介绍

“高效运维最佳实践”是InfoQ在2015年推出的精品专栏,由触控科技运维总监萧田国撰写,InfoQ总编辑崔康策划。

前言

本专栏的第一篇文章获得诸多同行赞许,也被多位技术大佬转发、点赞,确属始料未及。兴奋之余,诚惶诚恐,思来想去,唯有继续码字,方能聊表谢意。也预祝大家在羊年里幸福快乐,心情愉悦。

春节刚过,广大运维朋友又面临着新的工作压力。让大家苦恼的是,我能力这么好,为什么不幸福?怎么能让工作不那么累心,怎么能多些成就感?甚至,还有机会幸福吗?

通常,幸福感很大程度来自于外部的认同(以及基于此的自我认同),例如外部门、领导或同事的赞赏。应该只有极少数的人,能在不被外部认同的情况下,还能自我陶醉(那该是何等强大的内心啊)。

导致技术人员不幸福的原因不胜枚举,本文主要针对个人自我管理上容易出现的四大问题,分析其根源,并试图给出些许改进建议。因篇幅有限,至于技术、流程规范等方面的问题,以后单开专题深入分析。

PS: 文末有彩蛋哦(但…不建议直接翻页到最后,谢谢!)

本文略长,主要目录结构如下:
1. 过于追求技术进步
2. 分不清轻重缓急
    2.1 给事情正确地分类
    2.2 要事第一的关键所在
    2.3 做事原则、排序原则
    2.4 怎么更好地接单?
    2.5 勇于说不,合理拒绝
3. 不善表达
4. 爱抱怨
    4.1 抱怨及其本质
    4.2 积极主动的精髓
    4.3 通力合作

好吧,我们开始。

1. 过于追求技术进步及改进建议

技术人员有时会过于追求个人技术进步,有意无意的混淆个人成长和公司要求之间的差别。这样的结果,往往会降低客户满意度,即需求方对我们工作的不认同。这种不认同,又会以各种形式表现出来,并反作用到我们自己身上。

例如,新来一个业务需求,经分析,嗯,有两种方案:1)采用新技术,大概1周完成。可用上自己关注了很久的某新开源软件,看上去一举两得:个人技术有机会进步了,而且是服务于公司的项目;2)采用老套路,3天完成。但没啥技术含量,一堆shell脚本拼凑,对个人而言是重复劳动,而且实现起来很不优雅。

我们会选择哪个方案?实际中往往采用新技术的居多。技术人员(特别是技术能力强的同学),难免对个人能力有所自负,潜意识认为,自己很棒,任何问题基本上都能解决。于是自信满满地和需求部门拍胸脯,然后结果就是……(你懂的,又延期了呗。)

新技术可能导致时间不可控,开源产品可能bug不断,中途遇到问题就麻烦了:社区不完善(发帖半天没人回),网上搜索不到管用的解决方案。反之,老套路时间可控,甚至闭着眼睛都能交活。有差不多现成的脚本,东改改西改改,出了问题也好解决,如果业务实在催得紧,多买几灌某牛加加班,保证按期交付。

其实,需求部门根本不在乎我们用什么技术来实现(而且他们也没必要在乎)。对他们而言,运维是个黑盒子,他们知道的输出结果只有两种:搞定了,没搞定。需求部门最无奈的是,技术人员没搞定,然后拿一堆听不懂的技术分析反复解说,而且自己还得在旁边赔笑脸、假装略懂。

正确的作法是怎样?

首先,主观上,需要遏制自己的那股技术冲动;其次,提前预估到各种风险,觉得难度有些大,就选用老办法。先按时交付业务需求,然后可以利用空闲时间,搞搞新技术的实现。

这样一来,皆大欢喜。虽然没业务压力的情况下,新技术的完成时间会延长很多。但不管怎样,这时,事情的性质转变了——由公司需求变成了个人问题。

2. 分不清轻重缓急及改进建议

运维人员其实有相当多的时间,都在用于处理日常业务需求。或者说,一天到晚都在处理故障的情况,并不多见。所以,同比例的,外界对我们的认可程度,较大程度上取决于我们日常工作的交付能力。

分不清轻重缓急是个普遍存在的问题,例如:1)新员工,刚参加工作几年,每个业务人员都说自己的需求重要紧急,可时间就那么多,又想好好表现,于是手忙脚乱;2)老员工,多个需求、问题一涌而来,这时也难免手忙脚乱。

仅仅手忙脚乱还好说,如果因此导致人为事故,业务中断,系统不稳定,大客户流失,重要内部客户不满意,影响公司决策支持,那么就更加麻烦了,而且会严重损害自己的自信心和信誉值。

那么,如何避免此类事情发生呢?可以从以下几个方面改进。

2.1 给事情正确地分类

当手头要处理的工作超过5个,就需要分类了。按照时间紧迫性和重要程度的不同,可分为紧急、不紧急,重要、不重要。手头的各种工作,可以自己搞个白板,按四个象限,分颜色贴上便利贴。

这个图相信不少人都了解过。现在大家可以闭目几分钟,回忆下,想想过去的一周,自己完成的事情,都可以放入哪几个象限,相信结果定会让你大吃一惊。

往往不重要、紧急的事情,占用了我们大量的时间,每个业务人员,都看上去火急火燎,甚至愿意站在办公位旁等结果。另外,不重要、不紧急的事情,有时也会占用我们大量时间。

那么,问题来了,我们允许大量时间被自己低效地消耗掉,对自己有什么好处?好处是:逃避现实(有时也用于逃避重要不紧急事情),寻求一个心理安慰——你看,我也好忙的(备注:这些文字可能会刺痛某些同学,但这类情况还比较普遍,权当共勉!)。

2.2 要事第一的关键所在

要事第一的关键所在,是将更多时间和注意力,放在重要、不紧急的事情上,而不是重要、紧急的事情(这意味着我们能实现卓越、还是止步于优秀)。我们建议至少留出20%的时间,来做重要不紧急的事情。这符合2/8原则,而且,往往也能产生80%的效能。

这样的好处是:可以减少重要紧急、不重要紧急的事情。例如,给某大型游戏导入用户的banner广告出现重大Bug,该广告虽由投放系统动态生成,但需运维同学紧急更新相应CSS文件才能在线上环境生效,这属于重要紧急范畴;正常情况下,这属于举手之劳的小操作,但运维人员在地铁上,不能稳定连入服务器。多悲催?!如果之前持续投入时间,利用Jenkins等实现了Web更新,那就可放权给需求部门自己更新,运维人员甚至不用参与。

纠结之处在于,因为事情重要但不紧急,所以容易被一拖再拖。如果各种痛心疾首后,还是仍然经常忘记重要、不紧急的事情,怎么办?收藏本文章,时不时的阅读一下,如此甚好。

2.3 做事原则、排序原则

各种原则很多,说多了大家也都容易忘掉,这里仅列举3个简洁实用的。

2.3.1 一次只做一件事

技术工作的特性,决定了得有整段时间(一般至少15~30分钟),才能沉下心来、分析解决问题,才有效率。一般来说,一次只做一件事。我们看下最高指导(新华网发布于2015年1月13日)。

有些时候,甚至可以戴上耳机,关掉QQ,忽略非重要邮件。不要把自己搞得有三头六臂似的,貌似很忙,实则瞎忙。

2.3.2 故障是第一位的

故障是最重要紧急的,也应该优先处理。这个貌似很简单的事实,有时都会被忽略。这发生在:

  1. 该类故障,并未明确规定第一责任人,大家相互扯皮;
  2. 故障第一责任人,沉浸在其他问题的解决中;
  3. 故障第一责任人,心急火燎地在想办法,其他人主观感觉和自己没关系,没主动跟进、群策群力去反向推动和解决。

例如公司官网无法访问,这个情况可能是DNS有问题、Nginix挂掉了,PHP出问题了,MySQL出故障了,网络堵塞了。各种情况都可能有,除非有智能监控,故障自愈系统,或者责任人有丰富的处理经验,否则运维部门所有工种,都应该主动去排查自己负责的部分是否有异常,并协助相关同学分析解决。

2.3.3 部门内部工作靠后

如果手头有多个重要紧急的业务需求,应及时向上级请示,将部门内部工作排序靠后,先做部门外的业务需求。

部门内部工作,一般由运维负责人提出,如迁移Zabbix数据库、PHP性能调优、新技术测试等。这类事情,实际上,交付日期是可协商的,往往并非重要紧急。

但也正因为是自己领导的需求,所以,往往被同学们分配更多的时间和更高的优先级,以博得领导赞赏——毕竟,给外部门做得再多,考核自己的,主要还是上级。

这是潜意识指导下的、一种合乎理性的行为,我们不能简单的否定。所以,这方面需要运维负责人的配合:需要主动、周期性的告知部门同学这个观点,并且鼓励这种插队行为(当然,前提是和上级沟通了)。

2.4 怎么更好地接单?

为了更好地接单,窃以为关键点是,对自己狠一点:接到业务需求时,需主动问询时间节点要求。从经验教训来看,事前商量好,总比事后被人催要好(虽然会有些痛苦)。有些业务需求的回答往往是:越快越好(晕)。这时就得帮助他们设定一个时间节点,而且得具体,不能模糊——如下周或元旦后。一旦达成一致,就是一个契约。

如果完不成,请提前预警。客客气气地说几句好话、打个电话,真诚道歉一把。最怕的情况是,设定的交付日期早过了,需求方来问进展,然后呆萌呆萌地说:我忘了,还没开始做……

2.5 勇于说不,合理拒绝

有办法礼貌地拒绝某些需求吗?还真有办法。拒绝别人得有理有据、不卑不亢。例如,在工作量非常饱和的情况下,业务方(甚至自己领导)来加塞,说又有一个非常重要、紧急的需求,需要立刻、马上开始,而且耗时还较长。这时怎么办?

这时可以拿出自己的工时分配表来。就说,您看,这是我最近两周的工作安排,都有这些事情,都是给这些部门做的。如果您的事情确实需要我来完成,您可以和这些事情的需求方谈一谈,看是否能做个调配,或者我们也可以一起去找我的上级,看是否能做个乾坤小挪移,等等。

另外,重要紧急往往是对别人而言,要关注那种每个需求都号称重要紧急、恨不得就给他一个人服务的同学。所以,对需求方,我们也可以甄别下,区别对待。

3. 不善表达及改进建议

不善表达更多是性格使然,关于这部分的原因分析及建议方法,在上一篇“高效运维最佳实践(01):七字诀,不再憋屈的运维”中已有重点表述,大家可以参阅一下。本文再次提及,只是因为这个问题,情况普遍、杀伤力大,而且容易改善,效果显著。

喜欢钻研技术,并能寻找到乐趣和认同感,这是运维人员的普遍情况。有些同学和别人讨论技术问题,也能头头是道,在QQ/微信上也话多、幽默。只是一遇到当面交流,就分分钟变成了“沉默的羔羊”。

如果需求方也是个不善表达的同学,相互多少有些“宿怨”,在日常沟通中再夹杂着情绪,那可能就更加不好。有例为证。

这种情况并非少见,是求虐、求投诉么?多说几个字,用些客气的字句、来些语气助词,真的那么难?必须得惜字如金么?又不是从身上割肉,不用舍不得……

改善客户界面,首先从意识层面反省,是否存在客户界面不友好的问题。解决方法包括,尽量当面沟通,真诚道歉。

4. 爱抱怨及改进建议

我们是公司的一份子,小公司问题很多,大公司更有各种通病。在一家公司呆个一年半载后,往往发现不如当初期望的那么美好,心情不畅,再加上还得面对生活的各种压力,难免各种坏情绪纷至沓来。

其中,抱怨是我们最常见的情绪之一,甚至是一种背景式的存在。观察下我们脑海里不时冒出的自言自语,十有八九是抱怨。牢骚太多防断肠,抱怨可能会集结成怨恨、甚至怨气,严重损害自己身体。

4.1 抱怨及其本质

抱怨隐含的意思是:我是对的,并将自己放在一个幻想中的道德优越感上。抱怨是一种低调的攻击,常被用于自我保护,捍卫自我。抱怨的,都是过去的事情,会白白的消耗自己的能量。(话语可能有些刺耳,请大家尽量看完下面的文字。)

建议轻度抱怨,勿沉迷,别走心。如果把抱怨当做朋友间的一个话题,也无伤大雅,当然,希望在这些时候,你知道自己是在抱怨(观察到抱怨的过程,很有意义,但也很难,不信你试试)。

事情不会因为我们抱怨,就变少。反而因我们抱怨,可能变得更加繁杂。

抱怨越多的人,往往是被抱怨越多的。其结果往往是,消极被动。所以好消息是,积极主动,专治抱怨。

另外,我正在策划一个情绪管理的专题“我的战争”,里面有对抱怨、焦虑、恐惧等常见情绪的更多剖析,敬请期待。

4.2 积极主动的真正含义

美国管理学大师史蒂芬·柯维在资深畅销书《高效能人士的七个习惯》中,给积极主动下的定义很有意思:当我们的行为,将影响圈扩大(借此蚕食关注圈——萧田国注),则被称为积极主动,否则就是消极被动。

所谓影响圈,就是那些我们能掌控(直接控制)的事情;而只能间接控制、或无法掌控的事情,都属于关注圈。

那么,我们能掌控的事情,都有哪些?思来想去,其实也就是自己的行为。如果我们管理着一个团队,可以指挥同学们做这个、做那个,这属于间接控制的事情。天气,则属于无法控制。

我们往往将注意力放在关注圈,这是导致抱怨、并且被抱怨的重要原因。

举个例子,业务推广因为网站不堪重负而失败,老板开骂。这时:

网站运营说,我早就告诉运维负责网站的哥们了,他就是不给我好好搞;

网站运维说,我早就告诉系统组的同事了,他就是不及时给机器;

系统运维说,我早就告诉采购部门了,他们一直没给我机器;

采购部门说,我早就告诉供应商了,他们说缺1TB的硬盘,没法发货。

大家都对,但也都不对。例如,对网站运维而言,没法把控系统运维的服务器交付日期,但自己能做的事情,真的到此为止了么?这个情况,你是否及时向自己的上级和业务部门汇报?是否真的没办法,从自己负责的业务中,临时调拨下?

对系统运维而言,是否真的不能从别的业务借用几台服务器先扛着?对采购部门而言,是否真的不能从服务器供应商借几台服务器先用着?

【问】我周遭的环境这么糟糕,我都苦不堪言了,你还让我积极主动,你不是在往我伤口上撒盐吗?

【答】真的抱歉啊,朋友们。大家都是苦水里泡大的,个中滋味,我感同身受。只是,除了改变自己,我们真的不能再做什么了啊。权当良药苦口了呗?一起共勉之。

4.3 通力合作

如果出现重大故障,不要先假设自己负责的部分(如数据库)是没问题的,并带着主观倾向去分析问题,这样在言语表达上可能让人反感,而且也往往不正确。

另外,也不要觉得自己负责的这部分没问题,于是对发生的重大故障,就再也不管不问、隔岸观火。应该主动和大家一起分析讨论,群策群力,解决问题。如果下次你负责的这部分出现了严重故障,其他人都漠然坐上观,你是否也会寒心?

还是那句话,大家是一条线上的蚱蜢。重大故障出现了、长时间未解决,公司和外部门会说,你运维部不行、不专业。这时候,即使能独善其身,又有什么用?

彩蛋

实在搞不懂轻重缓急,怎么办?这个好办,问上级呗,千万别自己憋着。领导是干什么的?不就是帮属下分忧解难的么,呵呵。甚至,偷偷地说,如果有个需求,实在完成不了了,也不要老是自己去和外部门解释,可以请领导出面。自己领导和需求方领导聊一聊,可能大事变小事哦。

下一篇文章,我们谈技术,主题暂定“高效运维最佳实践(03):Redis集群技术及Codis实战”,敬请期待。

关于作者

萧田国,男,硕士毕业于北京科技大学,目前为触控科技运维负责人。拥有十多年运维及团队管理经验。先后就职于联想集团(Oracle数据库主管)、搜狐畅游(数据库主管)、智明星通及世纪互联等。从1999年开始,折腾各种数据库如Oracle/MySQL/MS SQL Server/NoSQL等,兼任数据库培训讲师若干年。

曾经的云计算行业从业者,现在喜欢琢磨云计算及评测、云端数据库,及新技术在运维中的应用。主张管理学科和运维体系的融合、人性化运维管理,打造高效、专业运维团队。

近来有时参加一些大小技术会议,做做演讲嘉宾或主持人(有空找我来玩呀)。

对了,我计划在2015年4月23-25日的QCon全球软件开发大会上,就自动化运维话题进行分享哦。

我的微信号xiaotianguo。如需更多了解,请百度“萧田国”。另外,我也有微信公众号了,微信搜索“开心南瓜by萧田国”或扫描头像边的二维码,和我微信互动。公众号里将有我原创的各类技术和非技术文章,以及我喜欢的文章、帖子。一起来吧。


感谢崔康对本文的策划,丁晓昀对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

总结得真心好! by higkoo hk

道出了运维工程师很常见和容易犯的错,值得每位运维工程师多读几遍!

好!!! by 金 玉玮

感同深受,深受启发

为啥必须填标题 by 灰翔的 或蓝银

碉堡,虽然大部分自己都已知道,但是还是有受用的部分。赞~

绝对好文,必须多读几遍 by Alan Zhang

举例很有代表性,给刚入职工作的同学解答了很多困惑,老油条很多提升的思路。哈哈~

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

4 讨论

深度内容

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT