DevOps 组织中的工程师需要什么样的技能？让我们来看看。调查 DevOps 职位 发布，您需要非常熟悉在非生产环境中从未使用过的数十种技术。阅读 devops.com 上的文章，您需要能够写出 1,500 个单词而无需真正说出任何内容。参加 DevOpsDays 会议 或 DevOps 聚会 ，你需要有一种微妙的同理心。这么多事情，你应该关注什么？
在这篇文章中，我将讨论我认为对工程师最重要的前三项 DevOps 技能，排名不分先后。
代码
当 DevOps 首次成为#TrendingTopic 时，对此存在一些争议，但我认为我们现在已经解决了这个问题：如果您是 DevOps 组织中的工程师，您需要能够以代码形式交付解决方案。无论您是开发人员、运维人员、QA、DBA、安全人员、数据分析人员等，都没有关系——用代码对我们的系统进行建模所带来的稳定性远远超过引入的任何复杂性。
请注意，我说的是“以代码形式交付解决方案”，而不仅仅是“编写代码”。满足“完成的定义”是团队嘴上说说但通常不会实际执行的概念之一。另请参阅：事后分析、持续集成、数据驱动的决策制定。一段代码完成的定义不是“推送到 Github”，而是“为客户提供价值”。客户包括内部利益相关者。
教你编码的网站往往忽略了这一点。你为继续下一课而制作的工件是一个类或函数，它通过了他们编写的测试。人们参加了“学习 Ruby”课程，当没有人愿意雇用他们为生产系统编写 Chef 食谱时，他们感到气馁。需要明确的是，我并不是说您不能在线学习编码。请注意，作为一名工程师，编写代码只是您对组织价值的一部分。我将在以后的帖子中对此进行更多介绍。
共情
当我们谈论 DevOps 中的同理心时，我们实际上是在谈论 基于经验的同理心 。不知情的同理心可能是毁灭性的。当工程师升级问题时，您经常会看到这种情况。一个例子：
Harry（开发人员）对他从 Kate（操作人员）那里收到的代码审查感到不满。他的代码运行良好，他认为凯特只是在迂腐。因此，Harry 就冲突问题来找 Wes（开发经理）。 Wes 查看了它并发送了一封电子邮件说，从现在开始，操作代码审查将只在完整发布之前完成。 Ops 正在减慢开发过程。
持续交付销毁。
如果您对自己说“这永远不会发生”，它就会一直发生。它现在正在您附近的一家公司发生。这是局部同理心。韦斯当然有很多同理心，但 仅限于他的团队 。他对 ops 领域的了解不够好，无法做出正确的决定。这是可以理解的。但是他并没有花时间去听对方（ops）。这是疏忽，是局部同理心的结果。
这就是为什么 CAMS 不是 CAM。分享信息，通常只意味着倾听，是培养基于经验的同理心的关键做法。如果你在一个不重视他们的组织中，磨练你积极倾听的技巧并用脚投票。
沟通
hard_engineering_problems = [
'naming things',
'cache invalidation'
]
hard_engineering_problems.append('communicating effectively')
聪明人无法避免过度自信。工程师是聪明人。但是我们计划我们的谈话吗？不，不是真的。如果我需要某人的东西，我会去和他们谈谈。很明显我需要什么以及为什么需要它。他们会很密集，不给我我需要的东西。
hard_engineering_problems = [
'naming things',
'cache invalidation'
]
hard_engineering_problems.append('communicating effectively')
听起来有点熟？是的。
规划你的沟通是工程师的一项重要技能。无论您是要进行冲刺计划、与您的经理一对一，还是向其他团队的人寻求帮助，准备都是关键。这对于迁移到 DevOps 时经常出现的困难对话尤为重要。
至少，在开始谈话之前，你应该知道你想从谈话中得到什么。这些是你的目标。记下来。这对于您需要回答的问题特别有用。很容易走岔路，会议结束时你的问题得不到解答。考虑一下您准备做出的让步，并将它们也写下来。把你的笔记带到会议上。使用笔和纸，笔记本电脑会分散注意力。
事情是这样的：如果你不这样做，你就会让自己处于不利地位。很可能您在进行对话时对方准备不足。如果他们的目标与您的目标相冲突，您就很难获得所需的东西。有效的沟通是关于准备。准备胜于聪明。
谢谢阅读！我希望这可以帮到你。
本月晚些时候，我将发表一篇关于有效沟通主题的客座文章，作者是 Howard Perlstein ，他是一位拥有 20 多年帮助组织改善沟通和拥抱变革经验的朋友。
