您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  要资料 文章 文库 Lib 视频 Code iProcess 课程 认证 咨询 工具 讲座吧   成长之路  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
 
     
   
 订阅
  捐助
高效运维最佳实践(02):员工的四大误区及解决之道
 
作者:萧田国 来源:InfoQ 发布于 2015-5-26
来自于要资料   1096 次浏览     评价:      
 

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 故障是第一位的

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

该类故障,并未明确规定第一责任人,大家相互扯皮;

故障第一责任人,沉浸在其他问题的解决中;

故障第一责任人,心急火燎地在想办法,其他人主观感觉和自己没关系,没主动跟进、群策群力去反向推动和解决。

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

2.3.3 部门内部工作靠后

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

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

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

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

2.4 怎么更好地接单?

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

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

2.5 勇于说不,合理拒绝

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

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

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

3. 不善表达及改进建议

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

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

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

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

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

4. 爱抱怨及改进建议

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

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

4.1 抱怨及其本质

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

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

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

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

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

4.2 积极主动的真正含义

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

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

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

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

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

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

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

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

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

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

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

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

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

4.3 通力合作

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

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

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

彩蛋

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

   
 订阅
  捐助
相关文章

DevOps转型融入到企业文化
DevOps 能力模型、演进及案例剖析
基于 DevOps 理念的私有 PaaS 平台实践
微软开发团队的DevOps实践启示
相关文档

DevOps驱动应用运维变革与创新
运维管理规划
如何实现企业应用部署自动化
运维自动化实践之路
相关课程

自动化运维工具(基于DevOps)
互联网运维与DevOps
MySQL性能优化及运维培训
IT系统运维管理
 

itil五大流程图
ITIL流程管理六步走
使用ITIL V3作SOA治理的基石
IT服务管理的实践与总结
借鉴ITIL架构理念提升信息化
ITIL流程总结
更多...   


基于ITIL的IT服务管理
ITIL认证
ITSM/ITIL基础
IT规划管理
IT外包管理
IT成本管理

中国移动通信 网络规划与管理
某航空公司 IT规划与企业架构
某金融公司 IT服务管理(ITIL V3)
中国联通集团 IT前沿知识概述
中海油 企业IT架构设计
更多...   
 
 
 

 
 
 
 
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号