关于“沟通”、标准、流程及传承 | 浅谈运维团队管理（3）

关于“沟通”、标准、流程及传承 | 浅谈运维团队管理（3）

编辑

高浩淼（整理）

作者介绍

付林目前为好玩一二三 运维团队负责人，6年运维经验，关注开源技术、工具、’人’如何更好的辅助业务运营。

专题简介

本专题是“浅谈运维团队管理”，本次分享主要的着重点是如下大纲的第6部分和第7部分。本次分享行文可能略显啰嗦，可能干货不多，各位手里的砖头请先放一下哈~~

分享的大纲如下：

如何从头开始组建一个运维团队（第1篇，暂未发表）选择及培养合适的人：招聘及培训（第1篇，暂未发表）愿景、目标的设定及共担、共享（第1篇，暂未发表）管理者定位及角色认知（第2篇，已发表）绩效管理（第2篇，已发表）关于“沟通”标准、流程及传承

文内‘暂略’部分将在后续分享”浅谈运维团队管理——跨过两年之痒 “中阐述，内容中“【】”里面的内容为所引用的知识点，有兴趣的可以关注下。

本文的主干为：

6 . 关于‘沟通‘ 目的、话术 对事不对人 多使用开阔性的问题 善于构建环境、维护一个合适的氛围 多听、注重事实，勿轻易下结论 情绪引导、心理干扰 解决问题的承诺7 . 标准、流程及传承 制定规则、标准 构建合适的流程 传承及改变（暂略）

说明：您可打开如下链接，以欣赏本专题的第4部分和第5部分。

管理者定位及角色认知、绩效管理 | 浅谈运维团队管理（2）

关于‘沟通’

兄弟们坚持一下，我们进入第六个环节了：关于‘沟通’。

其实，在前面的部分，我们多次提到了‘沟通’，比如在设定团队目标、做规划、分配任务乃至部属业绩出现问题了、心情不好了……我们都会和他一起聊聊，讨论下问题，但这样是‘沟通’吗？可能不是。

‘沟通’是一个双向、需要有回应的过程，就是：我说你听并提出自己的疑问、想法，然后相互接受对方的意见并达成一致及开始行动。与之相反的例子是‘演讲’：演讲者长篇大论，台下无非就是掌声，无实质性内容反馈。因为它是一个单向的传送过程。

在和部属沟通前，我们需要厘清这一次的目的是什么，我需要解决什么问题或得到什么样的信息，还需要根据沟通对象的性格差异，使用不同的描述方法、肢体语言及选择不同的环境。【MBTI】、【管理者的心理沟通技巧】。

如：有些兄弟可能更喜欢在轻松一点的环境中随意畅聊，有些喜欢在比较正式的环境中讨论工作问题，有些说话比较直白，有些更喜欢了解整个事情的细节等。

在宣布组织决定、决策及触碰到原则性问题的沟通时，宜选择较正式的环境，有压迫性的肢体暗示，座次也以面对面为宜。

其他方面的沟通，尽量选择轻松、开放一点的环境，如休闲区域、咖啡馆等。【商务座次礼仪】

如果是部属主动找我们，立即响应，马上放下手上的事情并保持极大的兴趣‘听’部属的诉求并讨论一个解决办法及给出一个期限，同时，可以视情况做一些激励，如：表达对他的工作的认可。不要吝啬赞美，有时候很简单的一句话，胜过万语。

在沟通过程中，也需要控制自己和沟通对象的情绪，描述问题或现状时，注重事实（仅阐述客观事实，只说看到的），然后发起不掺合任何主观判断的疑问，如：

昨天XX业务在21点10分挂了，XX模块中断运行10分钟，这个是什么原因造成的？我们是怎么解决的，后续的规避方案是什么{聚焦问题点，关注问题解决方案而非过程}……

而在4年前，我会这样问：怎么回事，XX模块挂了10分钟都没有处理好…大家可以评估下，哪种方式更好。

做一个好的‘倾听者’：在接受部属反馈的时候，我们也需要区分是情绪化的表达还是客观事实的描述或主观上判断，在部属未发表完之前，勿打断及做任何判断，并鼓励部属继续‘说’下去…在‘听’完部属反馈的问题后，先记录并告知一个答复的期限，随后，立即着手分析及解决问题，随时周知最新的进度信息。

另外，你会发现，部属除了反馈问题外还是会有部分冤屈或不满需要找个人诉说，很幸运，你被选中了。【倾听的艺术】

在个人成长意愿和团队分配的工作中，总会有矛盾的地方，就此类问题进行沟通时，多问问部属他们的想法是什么样的，也一起聊聊团队现状和下一步的方向、计划，然后一起努力找到一个平衡点【共识】，有条件的相互承诺，如：

如果你可以独立处理好XX业务，可以由你来负责AA业务。这部分的内容在第3节有所体现（今天未分享）。

标准、流程及传承

对于IT资源的管理方式现在有很多可以借鉴的流程或体系，如ITIL、devops甚至是4大运维体系…在或实施这些流程或体系之前，扪心自问：

组织对我这个团队的期望是什么样的（第一节‘业务分析’）？我现在拥有的资源是什么？我们现在能做什么，最需要做什么，究竟做到哪种程度就是OK的？

这些问题留给大家思考。延伸阅读：IT服务成熟度级别。

运维团队存在的最大的价值是保障业务能稳定运行，不会因技术变革、人员流失、业务变更等造成业务运营出现不稳定状态。

在稳定基础上，我们才可以做运维理论的实践、工具和成本的优化或者新技术的应用。

但考虑到现实环境中‘人’不具把控性，我们要考虑尽量剥离‘人’对业务的影响，为此，我们会去做监控、自动化、服务自助、可视化，会去建立各种流程、规则加以约束等等……

而在这之前，我们需要把运维的基础工作做好，静下心来建立一些基本的业务维护标准及审视现有的团队结构和运维架构是否合理：

以业务维护来分析：

有无服务器硬件、操作系统安装标准；有无各模块版本、编译参数、部署位置、启动参数；资源使用有无统计、分析；备份策略、备份数据检测、数据存储策略；监控策略、对象、报警规则是否有效及正常运行；安全防护机制是否仍然有效。

以团队管理制度、流程、成员结构来分析：

部门架构图是否依然适用？部门及各岗位职责是否清晰、有效、可理解？团队成员的技能是否依然能互补？团队人员的技能、经验、年龄组成结构是否合理？既有的业务维护流程是否依然有效？业务维护及说明文档是否清晰、有效及可具操作性？变更及事件的处理有无及时响应、归类记录、分析？业务、服务器的维护权限、操作规范，信息安全规则是否有效及执行？BCP计划是否有演练、有效？对外提供的服务的接口、标准（如邮件格式）是否统一？

从业务部署来分析：

各模块、业务相互依赖的业务逻辑视图是否需要修订？部署架构图、监控能否反映业务运行的最新状态？业务部署架构是否存在热点、单点及可能的雪崩效应，是否支持扩展及对运维友好？

上面列出的几个片段，希望可以给大家在制定运维规范、流程时做一些参考。构建一个有效的流程可如下原则：

单点的输入、输出；输入、输出有标准、期限可依；子环节的次序、过程符合实际；关键业务点有明确的岗位、责任说明。

现在的时代是最好的、也是最坏的时代，云及基于云的SAAS服务、各种运维理论的百花齐放，已让我们应接不暇或陷入争锋。但，无论如何，技术永远只是工具，运维的立身之处还是先要保障业务稳定运营，任何时候，优先满足业务需求。

多说一句：在由技术转向管理岗位的转型过程中，通常，成长为一名合格的管理者需要6~12个月。成长过程中较常见的问题是转型者会变成‘保姆’、‘老好人’、‘背锅达人’、‘劳模’等等。

这个时候要不断的反思：你的职责、绩效(价值)、关注点及你的位置在哪里并加以改善。而你，也不是一个人在战斗！任何时候要记得的背后还有一帮兄弟……

书籍推荐：

管理类的：《第五项修炼》 《定位》项目管理入门类：《人人都是产品经理》成本类：《精益制造013：成本管理》 这本纯属个人爱好

欢迎加入开放运维联盟

开放运维联盟（OOPSA）成立于2015年10月31日，由资深运维从业人员联合发起，是一个运维行业性、非盈利组织，旨在融合运维行业最佳实践、推动运维行业进步，减低公司运维重复投入，建设运维人员共有的家园，提升运维人员幸福指数。指导单位为工信部电信研究院数据中心联盟（DCA）。

目前会员注册开放中，欢迎广大运维同仁加入，共谋发展。OOPSA 更多介绍及会员报名办法，详见如下链接。

开放运维联盟（OOPSA），诚邀您的加入

如何一起愉快地发展

提示：目前高效运维新群已经建立，欢迎加入。您可添加萧田国个人微信号xiaotianguo8 为好友，进行申请，请备注“申请入群”。