高效运维最佳实践（02）：员工的四大误区及解决之道

专栏介绍

“高效运维最佳实践”是 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 ）关注我们，并与我们的编辑和其他读者朋友交流。