阿里云
阿里云多端小程序中小企业获客首选
发表主题 回复主题
  • 17010阅读
  • 0回复

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

发帖
62
云币
250
— 本帖被 柚子 从 内部文章调用 移动到本区(2015-03-11) —
`^ieT#(O  
oj,HJH+  
本文转载自InfoQ
原文地址:http://www.infoq.com/cn/articles/effective-ops-part-02
Jcwh|w9D8  
@Og\SZhn  
<Um1h:^   
,wwU` U  
高效运维最佳实践(02)
员工的四大误区及解决之道
LG/=+[\{E  
?6gDbE%  
N>&{Wl'y\  
作者 萧田国 发布于 2015年3月3日 专栏介绍 “高效运维最佳实践”是InfoQ在2015年推出的精品专栏,由触控科技运维总监萧田国撰写,InfoQ总编辑崔康策划。 "?2  
Bo](n*i  
H{ n>KZ]\  
前言 X_-Hrp!h  
nvO%  
        本专栏的第一篇文章获得诸多同行赞许,也被多位技术大佬转发、点赞,确属始料未及。兴奋之余,诚惶诚恐,思来想去,唯有继续码字,方能聊表谢意。也预祝大家在羊年里幸福快乐,心情愉悦。 B|]t\(~$ [  
TnvHO_P,  
        春节刚过,广大运维朋友又面临着新的工作压力。让大家苦恼的是,我能力这么好,为什么不幸福?怎么能让工作不那么累心,怎么能多些成就感?甚至,还有机会幸福吗? ^D ]7pe  
Jf %!I  
通常,幸福感很大程度来于外部的认同(以及基于此的自我认同),例如外部门、领导或同事的赞赏。应该只有极少数的人,能在不被外部认同的情况下,还能自我陶醉(那该是何等强大的内心啊)。 n}AR/3}  
       导致技术人员不幸福的原因不胜枚举,本文主要针对个人自我管理上容易出现的四大问题,分析其根源,并试图给出些许改进建议。因篇幅有限,至于技术、流程规范等方面的问题,以后单开专题深入分析。 xWenKY,  
本文略长,主要目录结构如下: bl:a&<F  
        1. 过于追求技术进步 b:}wR*Adc  
        2. 分不清轻重缓急 OEy:#9<'  
            2.1 给事情正确地分类 K,lK\^y  
            2.2 要事第一的关键所在 )*^OPVt  
            2.3 做事原则、排序原则 K]H"qG.K  
            2.4 怎么更好地接单? ohQz%?r  
            2.5 勇于说不,合理拒绝 ~# hE&nq  
        3. 不善表达 KV^:sxU  
        4. 爱抱怨 ;3.T* ?|o  
            4.1 抱怨及其本质 P\*2c*,W;  
            4.2 积极主动的精髓 {L-{Y<fke  
            4.3 通力合作 0] :*v?  
=#POMK".6  
Q ^1#xBd  
好吧,我们开始。 GM9]>"#o\  
(?*mh?  
 |(J ?#?  
1. 过于追求技术进步及改进建议 &geOFe}R  
n7`.<*:  
J#Ne:Aj_  
        技术人员有时会过于追求个人技术进步,有意无意的混淆个人成长和公司要求之间的差别。这样的结果,往往会降低客户满意度,即需求方对我们工作的不认同。这种不认同,又会以各种形式表现出来,并反作用到我们自己身上。 Q?Bj q>  
       例如,新来一个业务需求,经分析,嗯,有两种方案:1)采用新技术,大概1周完成。可用上自己关注了很久的某新开源软件,看上去一举两得:个人技术有机会进步了,而且是服务于公司的项目;2)采用老套路,3天完成。但没啥技术含量,一堆shell脚本拼凑,对个人而言是重复劳动,而且实现起来很不优雅。 W{$+mow7S  
我们会选择哪个方案?实际中往往采用新技术的居多。技术人员(特别是技术能力强的同学),难免对个人能力有所自负,潜意识认为,自己很棒,任何问题基本上都能解决。于是自信满满地和需求部门拍胸脯,然后结果就是……(你懂的,又延期了呗。) #RLch  
       新技术可能导致时间不可控,开源产品可能bug不断,中途遇到问题就麻烦了:社区不完善(发帖半天没人回),网上搜索不到管用的解决方案。反之,老套路时间可控,甚至闭着眼睛都能交活。有差不多现成的脚本,东改改西改改,出了问题也好解决,如果业务实在催得紧,多买几灌某牛加加班,保证按期交付。 )'K!)?&d  
其实,需求部门根本不在乎我们用什么技术来实现(而且他们也没必要在乎)。对他们而言,运维是个黑盒子,他们知道的输出结果只有两种:搞定了,没搞定。需求部门最无奈的是,技术人员没搞定,然后拿一堆听不懂的技术分析反复解说,而且自己还得在旁边赔笑脸、假装略懂。 WoClTb>F  
正确的作法是怎样? T,xVQ4J?  
       首先,主观上,需要遏制自己的那股技术冲动;其次,提前预估到各种风险,觉得难度有些大,就选用老办法。先按时交付业务需求,然后可以利用空闲时间,搞搞新技术的实现。 VxPTh\O*[  
       这样一来,皆大欢喜。虽然没业务压力的情况下,新技术的完成时间会延长很多。但不管怎样,这时,事情的性质转变了——由公司需求变成了个人问题。 8,H#t@+MT  
^;bGP.!p  
; K)?:  
2. 分不清轻重缓急及改进建议 m|#(gX|F  
O w($\,  
x%:> Ol  
       运维人员其实有相当多的时间,都在用于处理日常业务需求。或者说,一天到晚都在处理故障的情况,并不多见。所以,同比例的,外界对我们的认可程度,较大程度上取决于我们日常工作的交付能力。 x w?9W4<  
       分不清轻重缓急是个普遍存在的问题,例如:1)新员工,刚参加工作几年,每个业务人员都说自己的需求重要紧急,可时间就那么多,又想好好表现,于是手忙脚乱;2)老员工,多个需求、问题一涌而来,这时也难免手忙脚乱。 P :7l#/x_  
       仅仅手忙脚乱还好说,如果因此导致人为事故,业务中断,系统不稳定,大客户流失,重要内部客户不满意,影响公司决策支持,那么就更加麻烦了,而且会严重损害自己的自信心和信誉值。 w=P <4 bdT  
       那么,如何避免此类事情发生?可以从以下几个方面改进。 6Ymo%OT  
2.1 给事情正确地分类 kGBl)0pr`x  
       当手头要处理的工作超过5个,就需要分类了。按照时间紧迫性和重要程度的不同,可分为紧急、不紧急,重要、不重要。手头的各种工作,可以自己搞个白板,按四个象限,分颜色贴上便利贴。 d'g{K]=tF  
@h7GTA \  
 7 zP  
       这个图相信不少人都了解过。现在大家可以闭目几分钟,回忆下,想想过去的一周,自己完成的事情,都可以放入哪几个象限,相信结果定会让你大吃一惊。 ,rl <ye*&  
往往不重要、紧急的事情,占用了我们大量的时间,每个业务人员,都看上去火急火燎,甚至愿意站在办公位旁等结果。另外,不重要、不紧急的事情,有时也会占用我们大量时间。 d@>k\6%j  
       那么,问题来了,我们允许大量时间被自己低效地消耗掉,对自己有什么好处?好处是:逃避现实(有时也用于逃避重要不紧急事情),寻求一个心理安慰——你看,我也好忙的(备注:这些文字可能会刺痛某些同学,但这类情况还比较普遍,权当共勉!)。 vS*0CR\  
2.2 要事第一的关键所在 ["#A-S  
       要事第一的关键所在,是将更多时间和注意力,放在重要、不紧急的事情上,而不是重要、紧急的事情(这意味着我们能实现卓越、还是止步于优秀)。我们建议至少留出20%的时间,来做重要不紧急的事情。这符合2/8原则,而且,往往也能产生80%的效能。 o7 -h'b-  
       这样的好处是:可以减少重要紧急、不重要紧急的事情。例如,给某大型游戏导入用户的banner广告出现重大Bug,该广告虽由投放系统动态生成,但需运维同学紧急更新相应CSS文件才能在线上环境生效,这属于重要紧急范畴;正常情况下,这属于举手之劳的小操作,但运维人员在地铁上,不能稳定连入服务器。多悲催?!如果之前持续投入时间,利用Jenkins等实现了Web更新,那就可放权给需求部门自己更新,运维人员甚至不用参与。 }~\].I6  
       纠结之处在于,因为事情重要但不紧急,所以容易被一拖再拖。如果各种痛心疾首后,还是仍然经常忘记重要、不紧急的事情,怎么办?收藏本文章,时不时的阅读一下,如此甚好。 1Sc~Vb|>  
2.3 做事原则、排序原则 gx>mKSzy  
       各种原则很多,说多了大家也都容易忘掉,这里仅列举3个简洁实用的。 )S;Xy`vO  
2.3.1 一次只做一件事 Vp-OGX[  
       技术工作的特性,决定了得有整段时间(一般至少15~30分钟),才能沉下心来、分析解决问题,才有效率。一般来说,一次只做一件事。我们看下最高指导(新华网发布于2015年1月13日)。 4Igs\x{i  
# V9hG9%8  
C5lD Hw[CX  
       有些时候,甚至可以戴上耳机,关掉QQ,忽略非重要邮件。不要把自己搞得有三头六臂似的,貌似很忙,实则瞎忙。 %ucmJ-< y#  
2.3.2 故障是第一位的 WCfe!P?g  
       故障是最重要紧急的,也应该优先处理。这个貌似很简单的事实,有时都会被忽略。这发生在:
  1. 该类故障,并未明确规定第一责任人,大家相互扯皮;
  2. 故障第一责任人,沉浸在其他问题的解决中;
  3. 故障第一责任人,心急火燎地在想办法,其他人主观感觉和自己没关系,没主动跟进、群策群力去反向推动和解决。
[Ey%uh 6*  
       例如公司官网无法访问,这个情况可能是DNS有问题、Nginix挂掉了,PHP出问题了,MySQL出故障了,网络堵塞了。各种情况都可能有,除非有智能监控,故障自愈系统,或者责任人有丰富的处理经验,否则运维部门所有工种,都应该主动去排查自己负责的部分是否有异常,并协助相关同学分析解决。 / jL{JF>I  
2.3.3 部门内部工作靠后 j n&9<"W  
       如果手头有多个重要紧急的业务需求,应及时向上级请示,将部门内部工作排序靠后,先做部门外的业务需求。 JpHsQ8<  
部门内部工作,一般由运维负责人提出,如迁移Zabbix数据库、PHP性能调优、新技术测试等。这类事情,实际上,交付日期是可协商的,往往并非重要紧急。 v,.n/@s|X  
但也正因为是自己领导的需求,所以,往往被同学们分配更多的时间和更高的优先级,以博得领导赞赏——毕竟,给外部门做得再多,考核自己的,主要还是上级。 7!yF5 +_d  
这是潜意识指导下的、一种合乎理性的行为,我们不能简单的否定。所以,这方面需要运维负责人的配合:需要主动、周期性的告知部门同学这个观点,并且鼓励这种插队行为(当然,前提是和上级沟通了)。 :~A1Ud4c  
2.4 怎么更好地接单? FLnAN;  
       为了更好地接单,窃以为关键点是,对自己狠一点:接到业务需求时,需主动问询时间节点要求。从经验教训来看,事前商量好,总比事后被人催要好(虽然会有些痛苦)。有些业务需求的回答往往是:越快越好(晕)。这时就得帮助他们设定一个时间节点,而且得具体,不能模糊——如下周或元旦后。一旦达成一致,就是一个契约。 @XG`D>%k  
       如果完不成,请提前预警。客客气气地说几句好话、打个电话,真诚道歉一把。最怕的情况是,设定的交付日期早过了,需求方来问进展,然后呆萌呆萌地说:我忘了,还没开始做…… Ew,wNR`  
2.5 勇于说不,合理拒绝 ! {o+B^^  
       有办法礼貌地拒绝某些需求吗?还真有办法。拒绝别人得有理有据、不卑不亢。例如,在工作量非常饱和的情况下,业务方(甚至自己领导)来加塞,说又有一个非常重要、紧急的需求,需要立刻、马上开始,而且耗时还较长。这时怎么办? ^5@"|m1  
       这时可以拿出自己的工时分配表来。就说,您看,这是我最近两周的工作安排,都有这些事情,都是给这些部门做的。如果您的事情确实需要我来完成,您可以和这些事情的需求方谈一谈,看是否能做个调配,或者我们也可以一起去找我的上级,看是否能做个乾坤小挪移,等等。 ;eEtdoy  
       另外,重要紧急往往是对别人而言,要关注那种每个需求都号称重要紧急、恨不得就给他一个人服务的同学。所以,对需求方,我们也可以甄别下,区别对待。 [t=+$pf(-  
PQ#-.K  
|(w#NE5  
3. 不善表达及改进建议 @U.}Ei  
Qs[EA_  
!J?=nSu  
       不善表达更多是性格使然,关于这部分的原因分析及建议方法,在上一篇“高效运维最佳实践(01):七字诀,不再憋屈的运维 ”中已有重点表述,大家可以参阅一下。本文再次提及,只是因为这个问题,情况普遍、杀伤力大,而且容易改善,效果显著。 -8kW!F  
喜欢钻研技术,并能寻找到乐趣和认同感,这是运维人员的普遍情况。有些同学和别人讨论技术问题,也能头头是道,在QQ/微信上也话多、幽默。只是一遇到当面交流,就分分钟变成了“沉默的羔羊”。 T^H) lC#R  
       如果需求方也是个不善表达的同学,相互多少有些“宿怨”,在日常沟通中再夹杂着情绪,那可能就更加不好。有例为证。 *M!YQ<7G^d  
Hf]}OvT>Z  
J2k'Ke97o  
       这种情况并非少见,是求虐、求投诉么?多说几个字,用些客气的字句、来些语气助词,真的那么难?必须得惜字如金么?又不是从身上割肉,不用舍不得…… " 7g8 d  
       改善客户界面,首先从意识层面反省,是否存在客户界面不友好的问题。解决方法包括,尽量当面沟通,真诚道歉。 BL^Hj  
LUVJ218p  
T`<k4ur  
4. 爱抱怨及改进建议 aeLo;!Jh  
5+"8q#X$  
zyn =Xv@p  
       我们是公司的一份子,小公司问题很多,大公司更有各种通病。在一家公司呆个一年半载后,往往发现不如当初期望的那么美好,心情不畅,再加上还得面对生活的各种压力,难免各种坏情绪纷至沓来。 [goPmVe+  
其中,抱怨是我们最常见的情绪之一,甚至是一种背景式的存在。观察下我们脑海里不时冒出的自言自语,十有八九是抱怨。牢骚太多防断肠,抱怨可能会集结成怨恨、甚至怨气,严重损害自己身体。 \yizIo.Y`  
4.1 抱怨及其本质 LO*a>9LI  
       抱怨隐含的意思是:我是对的,并将自己放在一个幻想中的道德优越感上。抱怨是一种低调的攻击,常被用于自我保护,捍卫自我。抱怨的,都是过去的事情,会白白的消耗自己的能量。(话语可能有些刺耳,请大家尽量看完下面的文字。) T ]nR XW$  
       建议轻度抱怨,勿沉迷,别走心。如果把抱怨当做朋友间的一个话题,也无伤大雅,当然,希望在这些时候,你知道自己是在抱怨(观察到抱怨的过程,很有意义,但也很难,不信你试试)。 U~@B%Msb L  
       事情不会因为我们抱怨,就变少。反而因我们抱怨,可能变得更加繁杂。 \ bmboNe  
       抱怨越多的人,往往是被抱怨越多的。其结果往往是,消极被动。所以好消息是,积极主动,专治抱怨。 Bq =](<>>  
       另外,我正在策划一个情绪管理的专题“我的战争”,里面有对抱怨、焦虑、恐惧等常见情绪的更多剖析,敬请期待。 Z"nuO\zH~  
4.2 积极主动的真正含义 >d[vHyA~!D  
       美国管理学大师史蒂芬·柯维在资深畅销书《高效能人士的七个习惯》中,给积极主动下的定义很有意思:当我们的行为,将影响圈扩大(借此蚕食关注圈——萧田国注),则被称为积极主动,否则就是消极被动。 t7%Bv+Uo  
       所谓影响圈,就是那些我们能掌控(直接控制)的事情;而只能间接控制、或无法掌控的事情,都属于关注圈。 &I_!&m~  
@9 tv N}  
j`M<M[C*4N  
       那么,我们能掌控的事情,都有哪些?思来想去,其实也就是自己的行为。如果我们管理着一个团队,可以指挥同学们做这个、做那个,这属于间接控制的事情。天气,则属于无法控制。 `.Q3s?1F  
       我们往往将注意力放在关注圈,这是导致抱怨、并且被抱怨的重要原因。 cDol o1*  
       举个例子,业务推广因为网站不堪重负而失败,老板开骂。这时: 5W '|qmJ  
        2*E<G|-F  
       大家都对,但也都不对。例如,对网站运维而言,没法把控系统运维的服务器交付日期,但自己能做的事情,真的到此为止了么?这个情况,你是否及时向自己的上级和业务部门汇报?是否真的没办法,从自己负责的业务中,临时调拨下? lFt{:HfX-  
       对系统运维而言,是否真的不能从别的业务借用几台服务器先扛着?对采购部门而言,是否真的不能从服务器供应商借几台服务器先用着? e' ;c8WF3E  
       l),13"?C(  
       【问】我周遭的环境这么糟糕,我都苦不堪言了,你还让我积极主动,你不是在往我伤口上撒盐吗? 62E(=l  
       【答】真的抱歉啊,朋友们。大家都是苦水里泡大的,个中滋味,我感同身受。只是,除了改变自己,我们真的不能再做什么了啊。权当良药苦口了呗?一起共勉之。 Z'M@DY/fdK  
;] o^u.PC  
v^E2!X  
4.3 通力合作 3+PM_c)Y  
       如果出现重大故障,不要先假设自己负责的部分(如数据)是没问题的,并带着主观倾向去分析问题,这样在言语表达上可能让人反感,而且也往往不正确。 *M5C*}dl  
0 1w/,r  
e+aQ$1^t  
       另外,也不要觉得自己负责的这部分没问题,于是对发生的重大故障,就再也不管不问、隔岸观火。应该主动和大家一起分析讨论,群策群力,解决问题。如果下次你负责的这部分出现了严重故障,其他人都漠然坐上观,你是否也会寒心? hzVO.Q*  
       还是那句话,大家是一条线上的蚱蜢。重大故障出现了、长时间未解决,公司和外部门会说,你运维部不行、不专业。这时候,即使能独善其身,又有什么用? -<.NEV  
彩蛋 O/@[VPf  
       实在搞不懂轻重缓急,怎么办?这个好办,问上级呗,千万别自己憋着。领导是干什么的?不就是帮属下分忧解难的么,呵呵。甚至,偷偷地说,如果有个需求,实在完成不了了,也不要老是自己去和外部门解释,可以请领导出面。自己领导和需求方领导聊一聊,可能大事变小事哦。 h"m7r4f  
N=x,96CF  
]c+'SJQ  
sTYl' Ieg  
2Vr'AEIQ  
-^N '18:  
[ 此帖被柚子在2015-04-13 15:18重新编辑 ]
发表主题 回复主题
« 返回列表上一主题下一主题

限100 字节
如果您提交过一次失败了,可以用”恢复数据”来恢复帖子内容
 
验证问题: 12 + 28 = ?
上一个 下一个
      ×
      全新阿里云开发者社区, 去探索开发者的新世界吧!
      一站式的体验,更多的精彩!
      通过下面领域大门,一起探索新的技术世界吧~ (点击图标进入)