为什么你永远不会搞定 DevOps 面试

这篇文章最初于 2015 年 5 月发表在 VentureBeat.com 上。

现在很多公司都在抱怨他们很难招到优秀的人才。有传言称谷歌和苹果等大公司之间有人才收购战和协议，我经常听到谈话中提到这些类型的问题。最近我听 Battery Ventures 的 Adrian Cockcroft 说，他在 Netflix 的时候，大公司经常问他，“Netflix 从哪里招聘到如此优秀的人才？”，他对康卡斯特等人的回答是：“我们聘请了同样的人才。”你雇佣的人，我们刚刚让开他们。”

另一个讨论这种持续抱怨的人是 Andrew Clay Shafer，他是 Pivotal 的高级技术总监，也是 DevOps 世界的知名人物。在 2013 年题为“ 不存在人才短缺 ”的演讲中，他认为我们需要的人才已经摆在我们面前，我们只是在寻找错误的东西。

我想断言我们甚至不知道是否存在人才短缺，因为这个过程完全被打破了——在两个方面：首先，招聘人员不知道他们需要寻找什么。其次，求职者并没有正确地展示自己。

注意：为了在整篇文章中进行演示（尤其是“DevOps 工程师”），我选择使用 DevOps 示例，但我在这里写的内容也适用于“全栈开发人员”或我们误认为的任何标题创建是为了找到我们的“技术经验丰富的开箱即用的任何问题解决者”。另一个注意事项：术语“DevOps 工程师”是一个讽刺和悖论，我反对在职位描述中使用它，因为它会让人产生这样的错觉。诚邀您 在此处 阅读相关内容 。

运营过渡

在过去十年左右的时间里，由于 Web 运维的井喷，运维范式发生了转变。虽然系统管理员过去拥有组织中特定子系统的专业知识，但如今，运维工程师负责生产系统的更广泛子集，有时甚至是整个系统。

只是为了确保我们在同一页面上，我指的是那些管理一个非常大的系统的 4-6 人超级英雄团队——从基础设施和监控管道架构到版本部署、配置管理等等（寻呼机职责在凌晨 3 点，有人吗？）。所以我们现在有五个人的团队来做曾经是几十人的工作。

人力资源涟漪

这种转变引起了涟漪。好吧……用涟漪这个词来描述 LinkedIn 中的 Ops 状态可能太软了。

如果你是一名运维工程师，简历中有 Puppet、Chef、AWS、Linux、Docker，当然还有臭名昭著的“DevOps”，Amazon、Yahoo 和许多其他财富 100 强企业会毫不犹豫地向你扑来。实际上，许多优秀的公司，无论它们是大公司还是小公司，SaaS-y 还是很酷，都在完全清空运营工程师市场。

同时，假设您刚刚离开了一家“优秀的 SaaS 公司”的体面工作，去寻找新的东西，并打开了您的 LinkedIn 帐户来更新您的个人资料。你可以投入任何东西：Nagios、PHP、Shell、AWK、Apache、Hadoop、数千台服务器、Ruby、虚拟化、CFEngine、所有已知的 Linux 发行版、MySQL、NoSQL、YesSQL、WhySQL ……

但这还不够。你没有学位；您从未使用过“云”，也不是“DevOps”（不管那是什么——至少您上次检查时是这样）。

你可能会被拒绝——这是假设你能参加面试。为什么？因为他们正在寻找最好的，creme de la creme。他们正在寻找……*鼓声请*……受人尊敬的“DevOps 工程师”。

我最近参加了在比利时根特举行的 DevOps Days 5 周年纪念活动，与我过去参加过的其他 DevOps Days 会议一样，大部分讨论都是关于 DevOps 到底是什么。工具？文化？自动化？持续交付？合作？一个人？一个团队？经过五年的 DevOps 日，也就是 Patrick Debois 首次创造这个术语已经过去了五年，我们仍在尝试定义它。

以下是“DevOps 工程师”的所有荣耀示例，可通过 Linkedin 上的求职选项找到：

要求
理想的候选人将拥有 4 年学院或大学的理学学士学位，至少 10 年的基础设施开发经验和/或培训，以及：

• 3 年以上 AWS 经验。

• 5-7 年的一般 DevOps/WS/DB/基础架构经验。

• AWS 的大部分（如果不是全部）组件的实践经验：EC2、Beanstalk、ELB、Route53、S3、Cloudfront、SNS、SWF、SQS、RDS、DynamoDB、ElastiCache、IAM、CloudFormation。

• 熟悉 SOA 原则和实践。

• 体验阅读、分析和吸收 AWS 白皮书、架构文档和技术简介。

• 服务推出加上完整的多周期 SDLC 体验，使用 Chef、Puppet、CloudFormation 等。

• 接触 AWS 辅助工具和实践（例如，Chaos Monkey、Asgard 等）。

• 亲身体验监控工具、入侵检测机制以及漏洞评估工具和实践。

• 一般脚本魔法。

• 自我激励的团队合作者，表现出主动性和灵活性。

• 强大的组织能力，能够处理多项任务并确定其优先级。

额外的首选技能
除上述要求外，首选候选人将具有：

• 熟悉 iTunes/App Store 基础知识

• SQL 和 NoSQL 经验

• 熟悉 JDBC 和各种类型的 SQL/NoSQL

• 具有设计访问控制、用户身份验证和服务安全性解决方案的总体经验

• 较强的口头和书面沟通能力

作为一名招聘人员，您必须翻阅无数的简历才能找到符合职位描述的人选。

通过浏览无数的纸质和在线简历；从许多不同的环境中听说过 DevOps；通过查看数百个职位描述，我得出结论，我们没有正确搜索。我相信这个超载的术语（连同 Fullstack Developer 和其他一些行业的最爱）正在创造一个恶性循环，招聘人员和求职者都会错失很多机会。

我想指出几个常见的错误，并提出一些可能的解决方案。

错误 1：招聘人员正在发布不存在的专业人员的职位描述

“我们想要最好的，”你说。自然，每个人都这样做。由于“DevOps”已成为一个广泛使用的术语，我们倾向于认为它概括了 CI、CD、CM、架构、自动化、云和任何其他技术经验，因此我们正在寻找可以担任此角色的人选。谁不会？任何组织都宁愿找到一个无所不知的人并付钱给他，而不是五个无所不知的人。

现代形式的运营工程师是一种新职业。自需要 24/7 正常运行时间的云和按需系统以来，它一直在获得动力。它需要具备设计、构建、监控、分析和维护完整、复杂、潜在大规模和高可用性生产环境的能力。你能在短短 3-4 年的实践中成为所有这些方面的专家吗？

那些幸运的人，他们知道得如此之多，以至于他们以某种方式设法与该定义非常吻合，他们可能已经被采用了。更重要的是，我敢说你可能无法与谷歌/亚马逊的雇佣条件相提并论，或者无法让他们满意地为一家正在改变世界的公司工作。

“但我们愿意等到找到完美的人选。”

嘘。其他人也是如此。

“我们正在寻找拥有主要大学学位的候选人。”

你希望人们在大学里学习成为解决现实世界问题的优秀工程师吗？有没有可以学习如何监控系统的机构？关于学术机构落后于实际技术的说法很多。这些课程几乎不可能跟上市场的速度。我推荐阅读 Ken Robinson 的 Out of Our Minds，他在其中详细讨论了这个差距。他专注于大学如何不再提供雇主所寻求的真正价值。

我就个人而言，学习成为一名电气工程师。工程师大多教授数学、物理、电学、化学、电子学和其他学科。据我所知，他们没有被教导如何做他们的工作。他们获得了理论知识和实践，其中一些知识可能会在未来应用或为他们服务。但在这个新职业中，我们甚至没有。没有学校。字面上地。

由于很多原因，候选人需要至少 X 年经验的普遍要求是有缺陷的。我们真的可以断言拥有四年经验的人比拥有两年经验的人更好吗？就不能有人在他们所做的事情上真的很糟糕五年，而另一个人却在两年内表现出色吗？我们应该根据数量还是根据质量来判断？

错误 2：招聘人员在面试中提出错误的问题

考虑到这些新角色的广泛性，您是否应该期望人们记住如何在 Junos 中配置 GRE 隧道，或者记住 Kerberos 需要哪个端口，或者记住如何在 DNS 服务器之间移动区域文件？

错误 3：求职者在简历中展示了错误的技能

让我们看看 John Doe 的简历：自我激励的 DevOps 工程师，在系统工程、开发和运营方面拥有超过 3.7 年的 IT 经验。希望从事免费/开源软件的工作。

职业总结：

1. 在多种 Linux 版本上拥有 3 年 DevOps 和系统工程经验
2. 在虚拟化和云管理方面拥有 2 年的丰富经验。
3. 2 年敏捷开发方法的工作经验。
4. 具有领导团队进行技术操作的能力。
5. 具有使用 Python、Ruby、C 和 Shell 脚本编写自动化脚本的经验。
6. 具有 LDAP 管理和与其他应用程序集成的经验。
7. 在 Web 应用程序 (LAMP) 配置和管理方面拥有丰富的经验。
8. 了解 BREW 和 Android 等移动平台。
9. 证明有能力就各种技术举办会议和举办研讨会。

技术技能总结

1. 系统管理：GNU/Linux（Debian、Ubuntu、Arch、CentOS、Redhat 和 Zentyal）
2. 虚拟化和云服务：LXC、KVM、OpenVZ、AWS、Droplets 和 CPanel。
3. 配置/构建和发布：Ansible、Make、Projspace、Go（学习）、Chef（学习）
4. 编程语言：Python、Ruby（学习）、Shell Scripting、C、C++和Java
5. 数据库和目录服务：OpenLDAP、Mysql、MariaDB
6. 版本控制系统：GIT、Bazaar、Subversion、GitLab
7. 网络工具/服务：Nagios、ntop、SSH、DHCP、DNS、FTP、Rsync、Squid、Iptables
8. 网络工具/技术：Apache、Nginx、Drupal、Mediawiki、Redmine、Piwik、PhpBB

即使我们假设 John Doe 以某种方式设法在如此短的时间内获得了上述所有方面的一些不错的经验，我们仍然不知道他是否可以将正确的工具应用于任意问题。我们根本不知道他能不能解决问题。我们不知道他是否甚至可以确定存在问题。

如果 John 的简历不是“在 Nagios、Statsd、Graphite、Logstash、Elasticsearch、Kibana、collectd 方面的经验”，而是说“喜欢研究和实施具有挑战性的架构问题的监控解决方案”，这不是更有用吗？

如果不是“四年的 Ruby、Python、AWK、Shell、Batch、VBS、C、C++、C#、Java、Javascript、JRuby、Jython 和其他一切编程经验”，它不是更有用吗？说，“非常了解 Ruby，但热衷于按需学习新语言。这是我一直在做的一个项目：<LINK>”？

误区四：求职者面试时说错话

假设您正在接受面试，面试官说：“这是一个系统。请描述从应用程序服务器向数据库发送请求的最安全管道，以及实现该解决方案所需的最合适的工具类型。”还请提供您的研究过程和您在此过程中使用的资源的逐步文档。”

您认为您管理的服务器数量或使用的 IaaS 的多样性是否能够很好地洞察解决此问题的能力？

问题不在于工具和经验是职位描述或简历的一部分。而是他们似乎优先于潜力和成就。经验重要吗？是的，但是在刚刚出现的环境中，您能指望找到多少有经验的人呢？

寻找激情，不要要求它

我建议招聘人员冒险到野外，真正找到那些足够关心自己的热情人士。您可以通过他们在 Stack Exchange 等网站上的数字足迹，或者通过他们积极参与社区这一事实来认识他们——从参加聚会、DevOps 日或 VelocityConfs 到参与积极的在线邮件讨论列表或开放空间。听。你可能只是找到你要找的东西。

我同意安德鲁和阿德里安的观点。我不认为我们缺少人才，我们只是在以错误的方式寻找人才。我们需要记住，我们实际上并不是在寻找对一堆系统有多年经验的人；我们正在寻找能够解决您问题的人。

“DevOps”这个词本身不是问题。我并不是在鼓吹反对在职位描述或简历中使用此类术语。我认为过度使用该术语是招聘人员试图找到解决复杂问题的简单方法的征兆；求职者试图根据错误的优势和能力将自己定位为理想的候选人，从而导致这个问题。

在我们摆脱有才华的 Ops 人员，让他们可以建造大教堂并成长之前，我们必须调整阻止他们尝试的障碍。