InfoQ Geekathon 大模型技术应用创新大赛 了解详情
写点什么

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

  • 2015-03-03
  • 本文字数:6285 字

    阅读完需:约 21 分钟

专栏介绍

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

活动推荐:

2023年9月3-5日,「QCon全球软件开发大会·北京站」 将在北京•富力万丽酒店举办。此次大会以「启航·AIGC软件工程变革」为主题,策划了大前端融合提效、大模型应用落地、面向 AI 的存储、AIGC 浪潮下的研发效能提升、LLMOps、异构算力、微服务架构治理、业务安全技术、构建未来软件的编程语言、FinOps 等近30个精彩专题。咨询购票可联系票务经理 18514549229(微信同手机号)。

2015-03-03 08:288750

评论

发布
暂无评论
发现更多内容

什么叫做信息安全?包含哪些内容?与网络安全有什么区别?

行云管家

网络安全 信息安全 数据安全

第五届 Polkadot Hackathon 创业大赛全程回顾,获胜项目揭秘!

One Block Community

区块链 科技

如何将 DevSecOps 引入企业?

SEAL安全

DevOps DevSecOps DevSecOps和敏捷

购买小间距LED显示屏的三个建议

Dylan

LED显示屏

《2022年中国银行业RPA供应商实力矩阵分析》研究报告正式启动

易观分析

银行用户

不要再说微服务可以解决一切问题了!

博文视点Broadview

NFT 交易市场主要使用 ETH 本位进行交易的局面是如何形成的?

NFT Research

区块链 NFT

【Python技能树共建】python urllib 模块

梦想橡皮擦

Python 7月月更

基于OpenHarmony的智能金属探测器

OpenHarmony开发者

OpenHarmony

spark调优(一):从hql转向代码

怀瑾握瑜的嘉与嘉

spark 7月月更

Spring Cloud源码分析之Eureka篇第二章:注册中心启动类上的注解EnableEurekaServer

程序员欣宸

Java spring SpringCloud 7月月更

【云资源】云资源安全管理用什么软件好?为什么?

行云管家

云计算 安全管理 云资源

程序员内卷和保持行业竞争力

沃德

程序员 7月月更

《信息系统项目管理师》备考笔记---信息化知识

IT蜗壳-Tango

软考 7月月更 信息系统项目管理师

OpenHarmony应用开发之Navigation组件详解

坚果

HarmonyOS OpenHarmony 7月月更

手把手带你入门Apache伪静态的配置

迷彩

Apache SEO伪静态 7月月更

7 大主题、9 位技术大咖!龙蜥大讲堂7月硬核直播预告抢先看,今天见

OpenAnolis小助手

云原生 技术干货 龙蜥大讲堂 7 月预告 精美周边

百问百答第45期:应用性能探针监测原理-node JS 探针

博睿数据

自动化 博睿数据 性能检测 百问百答 智能运维AIOps

ACID事务理论

源字节1号

软件开发

C++|TCP客户端中发送文件

中国好公民st

c++ TCP通信 7月月更

居家办公那些事|社区征文

CrazyGeek1996

居家办公 社区征文 7月月更

IPv6与IPv4的区别 网信办等三部推进IPv6规模部署

郑州埃文科技

ipv6 ipv4 IP地址

分类TAB商品流多目标排序模型的演进

得物技术

算法 得物

龙蜥社区第九次运营委员会会议顺利召开

OpenAnolis小助手

阿里云 开源 龙蜥社区 运营委员会 运营代表

超高效!Swagger-Yapi的秘密

百度Geek说

后端 swagger

leetcode 10. Regular Expression Matching 正则表达式匹配 (困难)

okokabcd

LeetCode 动态规划 数据结构与算法

TDengine 社区问题双周精选 | 第三期

TDengine

数据库 tdengine 时序数据库

谈谈对Flink框架中容错机制及状态的一致性的理解

百思不得小赵

flink 容错机制 状态 7月月更

如何让全彩LED显示屏更加节能环保

Dylan

LED LED显示屏

激动人心!2022开放原子全球开源峰会报名火热开启!

kk-OSC

开源 开发原子全球开源峰会 开源峰会

大疆车载从多家数据库中选定 TDengine 存储海量数据

TDengine

数据库 tdengine 物联网 时序数据库

  • 扫码添加小助手
    领取最新资料包
高效运维最佳实践(02):员工的四大误区及解决之道_QCon_萧田国_InfoQ精选文章