（02）员工的四大误区及解决之道

> 原文出处：http://www.infoq.com/cn/articles/effective-ops-part-02 > 作者：萧田国 ## 前言 本专栏的第一篇文章获得诸多同行赞许，也被多位技术大佬转发、点赞，确属始料未及。兴奋之余，诚惶诚恐，思来想去，唯有继续码字，方能聊表谢意。也预祝大家在羊年里幸福快乐，心情愉悦。 春节刚过，广大运维朋友又面临着新的工作压力。让大家苦恼的是，我能力这么好，为什么不幸福？怎么能让工作不那么累心，怎么能多些成就感？甚至，还有机会幸福吗？ 通常，幸福感很大程度来自于外部的认同（以及基于此的自我认同），例如外部门、领导或同事的赞赏。应该只有极少数的人，能在不被外部认同的情况下，还能自我陶醉（那该是何等强大的内心啊）。 导致技术人员不幸福的原因不胜枚举，本文主要针对个人自我管理上容易出现的四大问题，分析其根源，并试图给出些许改进建议。因篇幅有限，至于技术、流程规范等方面的问题，以后单开专题深入分析。 PS： 文末有彩蛋哦（但…不建议直接翻页到最后，谢谢！） 本文略长，主要目录结构如下： [TOC=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）：七字诀，不再憋屈的运维”](http://www.infoq.com/cn/articles/effective-ops-part-01)中已有重点表述，大家可以参阅一下。本文再次提及，只是因为这个问题，情况普遍、杀伤力大，而且容易改善，效果显著。 喜欢钻研技术，并能寻找到乐趣和认同感，这是运维人员的普遍情况。有些同学和别人讨论技术问题，也能头头是道，在QQ/微信上也话多、幽默。只是一遇到当面交流，就分分钟变成了“沉默的羔羊”。 如果需求方也是个不善表达的同学，相互多少有些“宿怨”，在日常沟通中再夹杂着情绪，那可能就更加不好。有例为证。  这种情况并非少见，是求虐、求投诉么？多说几个字，用些客气的字句、来些语气助词，真的那么难？必须得惜字如金么？又不是从身上割肉，不用舍不得…… 改善客户界面，首先从意识层面反省，是否存在客户界面不友好的问题。解决方法包括，尽量当面沟通，真诚道歉。 ## 4\. 爱抱怨及改进建议 我们是公司的一份子，小公司问题很多，大公司更有各种通病。在一家公司呆个一年半载后，往往发现不如当初期望的那么美好，心情不畅，再加上还得面对生活的各种压力，难免各种坏情绪纷至沓来。 其中，抱怨是我们最常见的情绪之一，甚至是一种背景式的存在。观察下我们脑海里不时冒出的自言自语，十有八九是抱怨。牢骚太多防断肠，抱怨可能会集结成怨恨、甚至怨气，严重损害自己身体。 ### 4.1 抱怨及其本质 抱怨隐含的意思是：我是对的，并将自己放在一个幻想中的道德优越感上。抱怨是一种低调的攻击，常被用于自我保护，捍卫自我。抱怨的，都是过去的事情，会白白的消耗自己的能量。（话语可能有些刺耳，请大家尽量看完下面的文字。） 建议轻度抱怨，勿沉迷，别走心。如果把抱怨当做朋友间的一个话题，也无伤大雅，当然，希望在这些时候，你知道自己是在抱怨（观察到抱怨的过程，很有意义，但也很难，不信你试试）。 事情不会因为我们抱怨，就变少。反而因我们抱怨，可能变得更加繁杂。 抱怨越多的人，往往是被抱怨越多的。其结果往往是，消极被动。所以好消息是，积极主动，专治抱怨。 另外，我正在策划一个情绪管理的专题“我的战争”，里面有对抱怨、焦虑、恐惧等常见情绪的更多剖析，敬请期待。 ### 4.2 积极主动的真正含义 美国管理学大师史蒂芬·柯维在资深畅销书《高效能人士的七个习惯》中，给积极主动下的定义很有意思：当我们的行为，将影响圈扩大（借此蚕食关注圈——萧田国注），则被称为积极主动，否则就是消极被动。 所谓影响圈，就是那些我们能掌控（直接控制）的事情；而只能间接控制、或无法掌控的事情，都属于关注圈。  那么，我们能掌控的事情，都有哪些？思来想去，其实也就是自己的行为。如果我们管理着一个团队，可以指挥同学们做这个、做那个，这属于间接控制的事情。天气，则属于无法控制。 我们往往将注意力放在关注圈，这是导致抱怨、并且被抱怨的重要原因。 举个例子，业务推广因为网站不堪重负而失败，老板开骂。这时： > 网站运营说，我早就告诉运维负责网站的哥们了，他就是不给我好好搞； > > 网站运维说，我早就告诉系统组的同事了，他就是不及时给机器； > > 系统运维说，我早就告诉采购部门了，他们一直没给我机器； > > 采购部门说，我早就告诉供应商了，他们说缺1TB的硬盘，没法发货。 大家都对，但也都不对。例如，对网站运维而言，没法把控系统运维的服务器交付日期，但自己能做的事情，真的到此为止了么？这个情况，你是否及时向自己的上级和业务部门汇报？是否真的没办法，从自己负责的业务中，临时调拨下？ 对系统运维而言，是否真的不能从别的业务借用几台服务器先扛着？对采购部门而言，是否真的不能从服务器供应商借几台服务器先用着？ > 【问】我周遭的环境这么糟糕，我都苦不堪言了，你还让我积极主动，你不是在往我伤口上撒盐吗？ > > 【答】真的抱歉啊，朋友们。大家都是苦水里泡大的，个中滋味，我感同身受。只是，除了改变自己，我们真的不能再做什么了啊。权当良药苦口了呗？一起共勉之。 ### 4.3 通力合作 如果出现重大故障，不要先假设自己负责的部分（如数据库）是没问题的，并带着主观倾向去分析问题，这样在言语表达上可能让人反感，而且也往往不正确。  另外，也不要觉得自己负责的这部分没问题，于是对发生的重大故障，就再也不管不问、隔岸观火。应该主动和大家一起分析讨论，群策群力，解决问题。如果下次你负责的这部分出现了严重故障，其他人都漠然坐上观，你是否也会寒心？ 还是那句话，大家是一条线上的蚱蜢。重大故障出现了、长时间未解决，公司和外部门会说，你运维部不行、不专业。这时候，即使能独善其身，又有什么用？ ## 彩蛋 实在搞不懂轻重缓急，怎么办？这个好办，问上级呗，千万别自己憋着。领导是干什么的？不就是帮属下分忧解难的么，呵呵。甚至，偷偷地说，如果有个需求，实在完成不了了，也不要老是自己去和外部门解释，可以请领导出面。自己领导和需求方领导聊一聊，可能大事变小事哦。 下一篇文章，我们谈技术，主题暂定“高效运维最佳实践（03）：Redis集群技术及Codis实战”，敬请期待。