DevOps-职业手册-全-

DevOps 职业手册（全）

原文：annas-archive.org/md5/0aad6a88152c489fe7798439bba3953f

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

导航任何职业都不容易，而导航一个涵盖多种职业经验的领域，甚至可能感觉几乎不可能。本书将帮助你在 DevOps 领域中找到方向，并帮助你为这一职业生涯做好准备。书籍的下半部分专注于面试过程中的每个阶段技巧，提升你成为顶尖候选人的几率。

本书适合谁

本书适合任何想深入了解 DevOps、追求 DevOps 职业生涯或在 DevOps 领域提升自己职业的人。

本书内容涵盖

第一章，职业发展路径，探索了 DevOps 的历史与文化，并介绍了 DevOps 领域中的各种职业路径。

第二章，DevOps 从业者的必备技能，讲述了所有 DevOps 从业者所需的技能，不论其职业水平如何。

第三章，进阶 DevOps 从业者的专业技能，涵盖了 DevOps 领域内进阶职业所需的技能。

第四章，重新打造自我品牌，提供了更新个人社交形象和简历的建议。

第五章，建立人脉网络，讲述如何让正确的人注意到你的技能，这对于获得工作机会至关重要，并提供了建立包括合适人物的网络的技巧和建议。

第六章，导师指导，聚焦于导师关系的价值以及如何与导师建立联系。

第七章，与招聘人员合作，分析了大多数职位是如何通过内部和外部招聘人员的组合来填补的，并给出了如何与两者合作的建议和技巧。

第八章，准备面试，提供了确保你为面试做好充分准备的建议。

第九章，面试步骤解析，逐步介绍了在典型和非典型面试过程中每个阶段的注意事项。

第十章，DevOps 职业生涯：技巧与窍门，提供了作者 25 年集体知识的倾诉，分享他们在面试过程中遇到的有效与无效的做法。

第十一章，与 DevOps 从业者的面试，回顾了不同职业阶段的 DevOps 从业者的坦诚面试。

如何最大化利用本书

本书假设你具备技术背景。然而，成功使用本书的唯一要求是你有强烈的学习愿望。

下载彩色图片

我们还提供了一个包含本书中使用的屏幕截图和图表的彩色图像的 PDF 文件。你可以在这里下载它：static.packt-cdn.com/downloads/9781803230948_ColorImages.pdf。

使用的约定

本书中使用了许多文本约定。

文本中的代码：指示文本中的代码词汇、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟网址、用户输入和 Twitter 用户名。例如："–it 命令以交互式终端运行容器。"

粗体：表示新术语、重要词语或屏幕上可见的字词。例如，菜单或对话框中的字词显示为粗体。例如："导航回到 GitLab，转到您刚刚推送的项目，然后单击 Settings | Pages 查看您网站发布的 URL。"

提示或重要说明

会出现在这里。

联系我们

我们始终欢迎读者的反馈意见。

一般反馈：如果你对本书的任何方面有疑问，请通过电子邮件联系我们，邮件地址是 customercare@packtpub.com，并在主题中提到书名。

勘误表：尽管我们已尽最大努力确保内容准确性，但错误不可避免。如果你在本书中发现错误，请向我们报告。请访问 www.packtpub.com/support/errata 并填写表格。

盗版：如果你在互联网上发现我们作品的任何形式的非法副本，请向我们提供位置地址或网站名。请通过电子邮件联系我们，邮件地址是 copyright@packt.com，并附上链接。

如果你有意成为作者：如果你在某个领域有专业知识，并且对撰写或贡献书籍感兴趣，请访问 authors.packtpub.com。

分享您的想法

读完《DevOps 职业手册》后，请分享您的想法！请单击此处直接转到亚马逊书评页面，并分享您的反馈。

您的评论对我们和技术社区至关重要，将帮助我们确保我们提供的内容质量卓越。

第一部分：DevOps 职业

在本节中，你将学习成为一名成功的 DevOps 从业者所需要的条件，以及不同层级所需的各种职业路径和能力。

本节包括以下章节：

• 第一章，职业路径

• 第二章，DevOps 从业者的核心技能

• 第三章，高级 DevOps 从业者的专业技能

第一章：职业路径

DevOps 的职业路径从来不是线性的，没有单一的进入点，随时可能分岔。DevOps 职业根植于精益（Lean）、敏捷（Agile）和极限编程（XP），因此它既是技术上的匹配，也是候选人与雇主之间文化上的契合。在这一章中，你将学习 DevOps 的历史，这将有助于你未来与招聘人员和招聘团队的讨论。你还将了解不同的技能档案，这将帮助你确定职业发展的方向。

本章将涵盖以下主题：

• 为什么你应该追求 DevOps 职业

• DevOps 历史概述

• DevOps 文化

• DevOps 职业路径

阅读超过 200 页关于你不确定是否想从事的职业的资料似乎有些傻；时间是有限的资源。在本节中，我们将讨论为什么你应该追求 DevOps 职业，特别是为什么应该选择 DevOps 而不是其他 IT 相关的职业。

收入潜力

DevOps 一直被评为收入最高的职业之一，年薪中位数为 100,000 美元。入门级的 DevOps 工程师年薪大致在 75,000 美元到 145,000 美元之间。随着你职业发展的推进，收入也会逐渐增加。看看下面的图表：

图 1.1 – DevOps 薪资

你应该考虑 DevOps 职业生涯的另一个原因是，它不断发展变化，永远不会让你感到无聊，这也为你提供了许多学习新技能的机会。

持续学习的机会

作为 DevOps 工程师，你的一部分工作就是与行业中最新的工具、技术和趋势保持同步。DevOps 工程师是被支付来学习的！这也是我作为 DevOps 工程师角色中最喜欢的一部分。作为一名 DevOps 工程师，你将在避免无聊的同时，为你的职业生涯做好未来准备。

对公司影响

作为一名 DevOps 工程师，你将交付公司每个部门都能使用并感受到的功能。没有其他技术职位能够像这个岗位一样，对业务产生如此深远的影响。

灵活性

作为一名 DevOps 工程师，你将拥有在任何地方、任何时间工作的灵活性。远程工作已经在技术行业中逐渐被接受；而 DevOps 团队早在这一趋势成为流行之前就已经开始了这种方式。包括 Slack 和 Jira 在内的协作工具使得异步工作成为可能。这意味着你不必和团队的其他成员在相同的工作时间内工作——至少不是一直如此。

那么，为什么你应该追求 DevOps 职业呢？

作为一名 DevOps 工程师，你将获得丰厚的薪酬，不断学习并运用前沿技术解决影响整个业务的问题，同时还能享有灵活的工作地点和时间选择。

DevOps 历史概述

你正在阅读一本关于 DevOps 的书，这意味着你大概对 DevOps 有所了解；如果没有，也无需担心——这部分内容会在书中涵盖。即便是在 DevOps 社区内部，DevOps 的历史也是较为未知的。首先，我们将回顾 DevOps 之前的一些关键元素，它们为 DevOps 的诞生打下了基础，并创造了 DevOps 成长所需的环境。

精益制造

精益制造是一种主要旨在减少生产系统内的周期时间以及供应商和客户响应时间的生产方式。

精益这个术语是由John Krafcik在 1988 年提出的，并由James Womack和Daniel Jones在 1996 年进行了定义。精益制造已成为一套公认的最佳制造实践。通常被称为丰田生产方式，精益制造旨在实现生产车间的过程优化。持续改进是精益制造的口号，实践者不断评估以下方法的改进：

• 保持最低库存。

• 最小化订单排队。

• 最大化制造过程的效率。

敏捷

在 2000 年代初期，传统的瀑布方法正在演变并被敏捷方法取代，这要求进行一个以团队赋能为核心的大规模文化转变。敏捷基于 4 个核心价值观和 12 个原则。一些原则在 DevOps 发展过程中被采纳（kissflow.com/project/agile/values-and-principles-of-agile-manifesto/）。

极限编程

XP旨在提高软件质量和对变化客户需求的响应能力。如果你觉得这听起来很像敏捷，你是对的；它是一种敏捷软件开发方法。XP 与其他敏捷框架的最大区别在于，它特别强调代码和开发（en.wikipedia.org/wiki/Extreme_programming）。

XP 对 DevOps 的主要贡献是持续集成（CI）。CI 是Grady Brooch于 2001 年提出的一个术语，并很快以 Brooch 方法发布。

DevOps

DevOps 的确切起源将永远是一个争论的话题；普遍接受的看法是，DevOps 运动始于 2007 年至 2008 年之间。这一时期的事件汇聚成了一场完美的风暴，促使了 DevOps 运动的诞生。软件行业中的功能失调，尤其是 IT 运维与软件开发社区之间的矛盾，成为了点燃这一运动的火花，但正是精益、敏捷和 XP 的先驱们为 DevOps 运动提供了最初的动力。

在没有 DevOps 的世界里，开发人员和 IT 运维属于不同的企业层级，且 IT 运维和开发的关键绩效指标（KPI）是不同步的，且对彼此产生负面影响。这些条件导致了团队之间的壁垒，造成了沟通障碍，最终导致了部署失败、错过截止日期和客户的不满。

2008 年，软件工程师 Andrew Shafer 尝试在加拿大的一个敏捷会议上组织一个名为 敏捷基础设施 的聚会。敏捷实践者 Patrick Debois 是唯一参加的人。两人进行了长时间的对话，这段对话如今被认为是点燃了一个火花，最终发展成了名为 DevOps 的运动。Andrew 和 Patrick 在那年晚些时候组建了一个讨论小组，供其他人发布他们如何解决开发与运维之间鸿沟的想法。2009 年，第一次 DevOpsDays 在比利时举行，这一事件让 DevOps 成为一个永载史册的流行词汇。DevOps 运动随后在全球各地的本地聚会中继续发展。大约在 2010 年，专注于 DevOps 的开源软件开始流行起来；Jenkins CI 服务器软件和 Chef 基础设施配置软件是其中的几个先驱。

专业提示

了解你所申请的职位背后的历史，会让你显得更为认真，且对话也会更加自然。深入了解，阅读一些书籍，如《DevOps 手册》和《凤凰项目》。这些书籍只会进一步增加你成功的机会。

以下图表展示了 DevOps 历史中的关键日期时间线：

图 1.2 – DevOps 历史时间线

现在我们已经了解了 DevOps 的历史，让我们在下一节中了解 DevOps 文化。

DevOps 文化

DevOps 是一套结合软件开发和 IT 运维的实践。它旨在缩短系统开发生命周期，并提供高质量的软件持续交付。DevOps 与敏捷软件开发是互补的；DevOps 的几个方面源自于敏捷方法论（en.wikipedia.org/wiki/DevOps）。深入理解这个定义，我们会发现 DevOps 是一种多面向的实践。DevOps 有七个指导原则，它们共同构成了 DevOps 文化。DevOps 文化旨在减少周期时间，应用增量变化，并创建更精简的开发流程。

以下图表展示了 DevOps 七个原则的图示：

图 1.3 – DevOps 文化 – 原则

现在我们将更深入地探讨 DevOps 的七个原则。

以客户为中心

经常进行测试，频繁获取最终用户的反馈，并快速失败。客户与最终用户之间的反馈循环应尽可能短。团队所采取的所有行动应当集中在最终用户的体验上。这也正是shift-left（左移）这一说法的由来，意味着越早测试功能中的错误，问题就能越快解决，并且下游依赖的风险会减少。

两家初创公司竞标为一家大型保险公司开发健身追踪器的故事

需求：一种可穿戴设备，用于追踪用户的健身情况。

验收标准：一款像手表一样的可穿戴设备，能够追踪多种运动。

X 公司采用测试驱动开发，并且每周进行演示，收集反馈。在一次演示中，他们展示了一个设备并描述了追踪跑步和骑行的计划。随后他们得知，许多客户是游泳爱好者。团队根据反馈调整了优先级，将重点从跑步和骑行转向游泳。客户对这一调整印象深刻。

Y 公司认为不需要演示，因为他们过去的应用程序表现相对良好。团队将重点放在跑步和骑行的追踪能力上。在验收时，他们收到了客户的反馈，要求这款手表必须具备游泳追踪功能。开发团队未能在规定的时间内满足需求，客户对此感到失望。

结果：X 公司获得了合同，之后发展成为一家价值十亿美元的公司。Y 公司未能获得合同，并且因媒体报道不佳，导致又一次初创公司失败。

培养协作精神

开发团队与 IT 运维团队之间的协作是 DevOps 的最基本要求。消除部门壁垒能够确保全公司范围内的协作与统一，从而专注于客户需求。

协作文化在采用自上而下的方法时最为有效；高层领导的支持应当在任何重大文化转型之前就安排好。另一种更慢的方式是组织内的草根倡议。只需要一群志同道合的人，提供一个平台来分享意见，就能掀起一场变革。然而，这种方法的问题是，长期的过度工作可能会导致倦怠感，尤其是当你不断为改变努力却始终未见成效时。相反，可以从你能掌控的事情做起，例如从你的团队开始。

罗伯特·魏德纳（Robert Weidner）是 Optum 的高级总监，世界上仅有 26 位认证的企业教练之一，同时也是我的导师和前经理。在罗伯特的领导下，我们的团队有权选择我们所工作的微团队。我们还被鼓励帮助任何需要我们支持的其他微团队。在对团队进行绩效排名，并将其适应于奖金的正态曲线时，我们在一次外出活动中对每位团队成员进行评审，所有团队成员在场并在热座上接受反馈。那时是令人害怕的，但它奏效了，因为团队彼此信任。

端到端所有权

特性团队通过为团队提供产品的垂直切片（即特性）来确保端到端的责任。这个特性，特性 1：按钮 X，有两个用户故事：一个用于开发，一个用于测试。特性的完成定义还要求特性成功部署。这可以在图 1.4中看到。最后需要注意的一点是，按钮 X的持续支持也仍由该团队负责。我们公司已经开始称其为你建造它，你拥有它（YBYO）。这一概念的背后逻辑是，建造某个功能的团队将是对该功能最了解的团队，尤其是在出现生产问题时。

图 1.4 – 以特性为中心的团队（端到端所有权）

在传统的开发方法中，如瀑布模型，团队通常在活动层面被拆分和创建，这也被称为工作中的水平切片。特性（Feature）的所有权在不同的团队之间划分。在以下示例中，三个团队必须与特性进行交互，才能将其交付给最终用户，而另一个团队则负责持续的支持。这是一个问题，因为操作支持团队通常不了解开发团队最近做出的更改，从而导致长时间的停机和故障：

图 1.5 – 瀑布式团队

现在，我们将讨论持续改进。

持续改进

持续改进继承自精益方法。整个团队应当受到鼓励，更重要的是，应该有权利在不怕失败的情况下做出改变。团队将失败视为改进有缺陷流程的机会。这也被称为continous_improvement.sh，以确保你的团队能够不断地进行改进：

图 1.6 – 持续改进脚本

上述脚本是一个简单的脚本，定义了如果持续改进流程是一个 shell 脚本，它的操作流程会是什么样子。

自动化一切

在为本书进行研究时，我注意到两种常见的说法：自动化一切和自动化（几乎）一切。进一步的研究揭示了不应自动化的流程类型，包括没有回报的事项和需要高度设计或视觉检查的事项，如下所示（dzone.com/articles/what-to-automate-and-what-not-to-automate）：

• 无投资回报的自动化

• 设计

• 应用程序的最终质量检查

流程应该尽可能减少人工干预。原因很简单：人类容易出错，而机器（计算机）擅长执行高频次、可重复的任务。

接下来，我们将讨论持续学习，这是一个对希望进入 DevOps 领域的人以及那些希望在不断变化的技术领域保持竞争力的人的重要 DevOps 原则。

持续学习

技术正以前所未有的速度发展；最著名的例子就是摩尔定律。摩尔定律是一个观察结果，即密集集成电路（IC）中的晶体管数量大约每 2 年翻一番（en.wikipedia.org/wiki/Moore%27s_law）。到 2017 年，微处理器中可容纳的晶体管数量已经超过 100 亿，而在 1971 年这一数字不到 1 万（ourworldindata.org/technological-progress）。成为一个持续学习者是一个能让你被聘用的个人特质。

提示：如果你希望在 DevOps 中取得成功，必须是一个持续学习者

使用新技术创建一个公共项目是向潜在招聘经理展示这一点的好方法。另一种方式是确保留下你最近阅读的文章的数字足迹，无论是在 LinkedIn 上的帖子，还是在 Twitter 上的推文。

一个突出的例子是一个高级 DevOps 工程师职位的面试，最终剩下两位候选人。两位候选人在组织中都有一定的任期，超出了职位要求，面试表现良好，并且都拥有高等学位。最终获得录用的候选人在面试过程中通过细微的方式表现出对知识的渴望。该候选人选择将焦点放在一个侧项目上，而不是他们的学位，该项目的目的是教候选人 Golang。数据科学的理论通过该应用得到了展示，而且很酷。最令我印象深刻的是，候选人有学习新事物的强烈愿望，这也是他们继续脱颖而出的原因。

总结来说，开发与运维的结合以及七个 DevOps 原则的共同应用，形成了 DevOps 文化。DevOps 是精益、敏捷和 XP 的完全独特衍生物，旨在缩短开发与最终用户之间的反馈循环。

请看下面的 DevOps 文化图示，其中将其划分为不同的实践和原则：

图 1.7 – DevOps 文化图表

总结来说，DevOps 文化包含七项指导原则，如 图 1.7 所示。在接下来的部分中，将讨论 DevOps 工程师的不同职业路径。

DevOps 职业路径

DevOps 领域内容庞杂，即使对于经验丰富的从业者来说，也具有挑战性。DevOps 包含八个核心实践，并遵循七项基本原则。不足为奇的是，DevOps 领域有着众多的职业路径，而通才是最常见的 DevOps 角色。

DevOps 通才可以类比为瑞士军刀，它被设计用来处理尽可能多的任务。它可以切绳子、开罐、剪电线，必要时，瑞士军刀甚至能片鱼。DevOps 通才可以创建部署管道，编写基础设施即代码脚本，并且如果需要，还能在 Amazon Web Services (AWS) 中管理 Elastic Kubernetes Service (EKS) 集群。

DevOps 专家可以类比为一把鱼片刀，它专为最有效地片鱼而设计。刀刃的形状、刀材和人机工程学都经过精细调校，以完成唯一的任务——片鱼。例如，一个 DevOps 云专家将自己的职业生涯集中在云基础设施、云架构和云安全领域，并且管理 AWS 中的 EKS 集群已经是他们的“呼吸”般的技能。他们很可能会比非云专家找到更具成本效益的方式来完成这项工作。

DevOps 专精的通才可以类比为一把带有弯刀的日常携带（EDC）小刀。这把刀的设计与瑞士军刀相似，但刀刃的形状使其在切割鱼肉方面与专门的鱼片刀相当。一个在 AWS 环境中工作了 10 年的 DevOps 专精通才，能够完成大多数 DevOps 任务，尤其擅长涉及 AWS 服务的任务。

通才、专家和专精通才的常见技能轮廓形状可以在以下图表中看到：

图 1.8 – 技能轮廓

你的技能组合的特点在确定如何自我定位时非常有用。首先从一个梳子开始。每个齿（技能）的长度（深度）相似。梳子的形状是典型的通才。第二个常见的形状是T形。T形有一条完整长度（深度）的线（技能）。T形是专才的典型形状。E形轮廓，有时被称为不对称的梳子，具有长度（深度）不同的齿（技能）。通常，有一个或多个技能的深度显著大于其他技能。E形是专精通才的典型形状。

一位导师曾告诉我，E 型的技能档案才是衡量个人技能的唯一真正标准。这个梳子形状存在缺陷，因为它假设所有技能的深度是相同的，这显然不可能。T 型则缺乏细节；它展示了个人擅长的某一项技能，但没有考虑到个人其他的技能。

专业提示

对于本章内容，不要过多关注示例中列出的技能要求，因为这些将在下一章详细讨论。请集中精力理解技能档案与不同类型 DevOps 工程师特定需求之间的关系。

以下图表展示了与 E 型档案匹配的常见技能档案：

图 1.9 – 技能档案（适配 E 型档案)

在接下来的章节中，我们将查看 DevOps 通才、专精 DevOps 通才以及几种 DevOps 专业领域的技能档案。我们将首先看看 DevOps 通才的技能档案。

DevOps 通才

谷歌的 Ben Fried 曾表示，通才，而非专家，将推动互联网的扩展（devops.com/specialists-vs-generalists-enterprise-devops/）。这句话最早出现在 2011 年，但直到今天，在某种程度上依然适用。通才理解整个软件开发生命周期（SDLC）。通才在多个领域和技能方面具有广泛的知识，但对任何单一领域的理解较为浅显。这在小型公司、初创公司或产品和工具数量有限的垂直整合型公司中很常见。几乎不需要工作交接，这减少了疏漏或遗忘的风险。

以下是 DevOps 通才的示例技能档案。请注意其相对平坦的形状：

图 1.10 – DevOps 通才技能档案

DevOps 通才通常是最先感受到公司扩展或引入新软件时的困境，尤其是在小公司或 DevOps 部门较小的组织中。当引入一款新工具时，DevOps 工程师需要在实施之前了解该工具。接下来，需要为新工具配置一个环境，这个环境通常与现有工具使用的环境不同，或至少有一些独特的差异。最后，工具被实施。在这一点上，新工具和现有工具都需要 DevOps 工程师进行支持。用图形表示的梳子形状来描述通才有一个固有的缺陷：它假设通才对任何领域都没有深入的理解。

DevOps 专精通才

如果你长时间在同一行业或同类型的项目中工作，你最终会变成一个专业化的通才。专业化通才也被称为“全能大师”。在前面的例子中，DevOps 工程师具备所有所需技能，但在编程和开发代码领域有更深入的理解和知识。这是软件工程师转型为 DevOps 角色的典型情况。如果你喜欢某些技能，或者总是被指派需要这些技能的任务，这也可能是你随着时间推移演化的技能概述。无论你的技能概述如何演变，了解自己在某些领域有更深入的理解，无论在找工作时还是要求晋升时，都会带来好处。

下图展示了一位具备多领域知识、并对构建和部署领域有更深入理解的 DevOps 工程师的技能概述：

图 1.11 – DevOps 专业化通才技能概述

了解自己的技能概述对于团队经理在进行产能规划时，以及工程师在选择申请的职位时非常有帮助，这也是你可能感兴趣的内容。在下一章中，我们将深入探讨如何创建自己的技能概述。

专家在某一领域有非常深刻的理解。这并不意味着他们不能做其他事情；然而，通常让专家跨领域工作效率较低。专家在大型组织中较为常见，这些组织通过支持的工具来定义专家。如果我们将其应用到之前的例子中，DevOps 工程团队 A 会专注于工具 A。当公司引入新工具时，会组建一个新团队，招聘具备正确技能的人才，或者通过提升现有员工的技能来加入该团队。那些在某个 DevOps 领域拥有深厚知识的专家，将是本书接下来重点关注的对象。

DevOps 安全专家

一名专注于安全的 DevOps 工程师被称为处于 DevSecOps 这一细分领域。DevOps 安全专家对渗透测试、云安全、混沌工程和持续验证等领域有深入理解，如下例所示的技能概述：

图 1.12 – DevOps 安全专家技能概述

现在，我们将讨论 DevOps 云专家。

DevOps 云专家

其中一个增长最快的领域是云工程，而云工程师也是收入最高的职业之一。你可能会问，云专家、云工程师和 DevOps 云专家有什么区别？诚实的回答是，没什么区别。职位名称没有意义，而且通常在不同公司之间、甚至在大型组织内部的不同部门之间有所不同。DevOps 云专家具备传统的 DevOps 技能，但在云工具、架构、最佳实践和整个云环境的管理方面有非常深入的知识，有时甚至涉及多云环境。

云的广泛应用使得对云的深入理解成为许多入门级职位通常也要求具备的技能。

图 1.13 – DevOps 云工程师专家技能档案

本节讨论了 DevOps 通才和 DevOps 专家的技能档案。

小结

在本章中，你了解了 DevOps 的历史和目标。DevOps 起源于 2008 年左右，当时一位开发者和一位敏捷专家在一次会议上碰面，决定要找到一种更好的软件开发方式。DevOps 的目标是打破开发与 IT 运维团队之间的壁垒，缩短开发者与客户之间的反馈循环。DevOps 是精益、敏捷和 XP 方法论的结合。

你还了解了 DevOps 领域中众多职业发展的路径。DevOps 职业路径的定义依据所需的知识深度。我们讨论了三种技能档案：DevOps 通才、DevOps 专注型通才和 DevOps 专家。DevOps 专家比通才拥有更深的知识。

在下一章中，我们将讨论作为 DevOps 通才所需的具体技能。

第二章：DevOps 实践者的必备技能

对于那些想要获得首个 DevOps 职位的人来说，最常听到的问题是，什么是重要的技能？ 对于一个 DevOps 通才来说，重要技能的列表相当冗长，这也是大多数寻求第一份 DevOps 工作的人所期望的角色。本章面向那些寻求第一份 DevOps 工作的人。已经有 DevOps 职业生涯的人可以跳过本章，或将其作为复习材料。

本章将涵盖以下主要内容：

• 脚本编写、编码与编程

• 源代码管理

• 基础设施管理

• CI/CD 概念

• 软技能

• 云原生框架

• 初学者 DevOps 认证

脚本编写、编码与编程

一些 DevOps 工程师非常擅长编程。然而，你不必成为一个优秀的程序员。要成为一名出色的 DevOps 工程师，调试代码、通过脚本实现自动化以及在仅有文本的终端中工作也是重要的技能。本节将涵盖以下内容：

• 浏览命令行

• 脚本编写

• 修改遗留代码与编写新代码

浏览命令行

命令行导航可能是任何想要在 DevOps 领域找到工作的人的最基本技能。命令行是一个通用术语，指的是基于文本的界面。大多数 Linux 发行版默认提供的命令行外壳是 Bash。虽然掌握基本的命令行使用知识对获得 DevOps 工程师职位至关重要，但精通命令行能帮助你在其他申请者中脱颖而出。没有哪种方法能够在不将终端作为日常常规工具的情况下精通它。许多写得很好的、内容丰富的博客、文章和备忘单都覆盖了命令语法。本节的重点将是如何通过技巧来快速提高使用命令行的舒适度。

所有导航操作都可以通过命令行完成，且通常更为迅速。即使你不确定当前所在的位置，pwd 命令也会输出你在终端中的当前路径。如果你想查看当前目录中的文件和文件夹，可以使用 ls 命令。要进入特定的文件夹，使用 cd 命令。如果你想在文本文件中查找特定的字符串，可以使用 grep 命令。默认情况下，grep 是区分大小写的，但像大多数命令一样，可以使用标志来改变其行为；例如，grep -i 会使搜索不区分大小写。如果有多个结果，你可以使用 sort 将结果按字母顺序或反向顺序排序。

图 2.1 显示了 Bash 终端窗口，已执行一些基本命令并显示了输出：

图 2.1 – Bash 终端与基本命令

正如你在前面的 Bash 终端中看到的，终端显示了独特的颜色，当前目录前有一个箭头，并且git文件夹中显示了当前检出的分支。你可以配置外观，也可以在.bashrc文件中设置别名和自定义函数。

专业提示：多玩玩，享受其中的乐趣

学习终端应该是有趣的，我们将在下一部分深入探讨。到那时，先在谷歌上查找命令，创造属于自己的命令，发挥创意！终端的强大之处在于它的灵活性；终端可以根据你的需求进行定制，而大多数这种定制都是通过.bashrc文件完成的。

.bashrc文件是设置别名、函数以及自定义终端外观和感觉的核心区域。.bashrc文件是一个在终端加载时运行的 Shell 脚本。如果你使用的是 Bash，你会有一个.bashrc文件，如果你使用的是zsh，则会有一个.zshrc文件。在.bashrc文件中，可以执行以下操作：

• 加载模块：

  module load <module>
  

• 修改环境变量：

  export PATH=$PATH:<path/to/dir>
  

• 激活 Python 环境：

  source <path/to/env>/bin/activate
  

• 设置别名：

别名是命令、命令组或脚本的别名，可以添加到.bashrc文件中。别名通常用于将常用命令缩短。最佳实践是将别名添加到一个名为.bash_aliases的单独文件中，然后将.bash_aliases加载到.bashrc文件中：

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

如果你的别名列表很短，你可以直接将它们添加到.bashrc文件中：

alias l="ls -l"
alias la="ls -la

别名也可以用来调用函数：

alias dd=dockerdown()
dockerdown(){
  sudo docker rm -f $(sudo docker ps -a -q)
  sudo docker ps
  sudo docker rmi -f $(sudo docker images -q)
  sudo docker images
}

另一项所有 DevOps 工程师都应该掌握的有用技能是，在终端中使用文本编辑器。

文本编辑器是命令行工具，可以直接在终端窗口中编辑文件。常见的有 vim、emacs 和 nano。大多数 Linux 发行版默认安装了 vim。在以下示例中，我们将向你展示如何编辑你的.bashrc文件。要在vi中打开文件，输入 vi </path/to/file>。在以下示例中，命令是 sudo vi .zshrc，它以 sudo 权限打开.zshrc文件：

](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/dop-crr-hb/img/Figure_2.02_B18117.jpg)

图 2.2 – 启动了 vi 编辑器的 Bash 终端

此时，文件已以只读模式打开。要进入编辑模式，输入 I。修改后，按 esc 再输入 w 保存文件，并按 q 关闭编辑器。

文本编辑器功能强大，但需要一定时间来掌握。如果你需要关于vi命令的信息，可以在各种在线论坛找到很棒的资源。我特别喜欢的一个是 ryanstutorials.net/linuxtutorial/cheatsheetvi.php。

脚本编写

脚本是 DevOps 工程师必须能够创建和维护的东西。获得 DevOps 工作的秘诀在于能够解决脚本问题，这意味着需要不断练习。目前 DevOps 工程师使用的脚本语言有多种，每种语言都有其最适合的工作类型，没有一种比另一种更好。

专业提示：在学习新语言时，谷歌是你最好的朋友

如果你在某个问题上遇到困难，很可能别人也曾遇到过这个问题，并且已经解决并写下了相关内容。不要做更辛苦的工作，而要做更聪明、更高效的工作。

Python

Python 在基础设施自动化和配置中被广泛使用，并且已成为 DevOps 中的全能脚本语言。它被许多人青睐，因为它容易入门。然而，随着你熟练度的提高，Python 会变得更加复杂。以下是最基本的 Python 脚本（helloworld.py）：

图 2.3 – hello_world.py

Bash

Bash 是 Unix/Linux 环境中最常用的脚本语言，并且有一个强大的社区提供支持。它被用于全球 Linux 服务器的自动化。以下是最基本的 shell 脚本（helloworld.sh）：

图 2.4 – hello_world.sh

JavaScript

JavaScript 用作 DevOps 脚本语言，用于创建以网络为中心的应用程序。它是一种轻量级的 DevOps 脚本语言。JavaScript 提供了许多优势，包括更少的服务器交互、更高的互动性、对访客的即时反馈以及更丰富的界面。以下是最基本的 JavaScript 脚本（helloworld.js）：

图 2.5 – hello_world.sh

Go

Go 于 2009 年推出，并且自问世以来大大改变了 DevOps 的格局。Go 是基于 C 构建的，旨在便于人类阅读并且具有可扩展性。以下是最基本的 Go 脚本：

图 2.6 – hello_world.go

专业提示：专注于一次学习一种语言

如果你尝试同时学习多种编程语言，那么你注定会让自己失望。除非有特殊情况需要你学习新语言，否则先精通一种语言再转向下一种。

在学习新语言时，你可以选择大量的书籍和在线资源。一个很好的练习方法是从 GitHub 上 fork 一个项目并进行修改。这是你可以给自己带来的一些最有用的经验。如果你想挑战自己，可以尝试一些专门为用户准备技术面试的在线网站，这也是提升编码技能的一个好方法。这里有几个受欢迎的推荐：

LeetCode: leetcode.com/

AlgoExpert: www.algoexpert.io/

还有一些网站围绕你可能在面试中遇到的问题类型建立。编码挑战网站也能大大提高你成功的机会。

现在我们已经涵盖了各种脚本语言，接下来需要讨论的是何时修改现有代码以及何时编写新代码。

在本节中，你了解了如何在基于文本的 shell（如 Bash）中导航，以及如何使用文本编辑器修改现有文件和创建新文件。我们还介绍了 DevOps 工程师使用的各种脚本语言及其最佳使用场景。

在下一节中，我们将讨论版本控制和源代码管理。

源代码管理

git。

Git

令人吃惊的是，87% 的开发人员使用 git 作为他们的版本控制工具。Git 是一种分布式版本控制软件，最初由 Linus Torvalds 设计，用于管理 Linux 内核。git 与 svn 的区别在于，使用 git 时，完整的代码历史会存储在每个独立节点上，而使用 svn 时，则是存储在单一的源服务器上。在学习 git 时，需要考虑以下几个方面：

• git 可用版本。

  开始使用 Git

  Windows: gitforwindows.org/

  macOS: git-scm.com/download/mac

  Linux: git-scm.com/download/linux

• 第二：有多种分支策略。建议你花时间学习并练习使用不同策略管理自己的项目。一些常见的策略定义如下：

图 2.7 – 基本的 git 工作流

基本的 git 工作流只有一个分支，即主分支或 Master 分支。开发人员直接向该分支提交代码，所有部署，无论是哪个环境，都是从该分支进行的。除非你需要快速设置或正在进行私人项目，否则不建议使用这种工作流。

以下图示为 git 特性分支工作流的图形表示：

图 2.8 – Git 特性分支工作流

每当多人在相同代码库上工作时，git 特性分支工作流就变得必不可少。特性 A 和特性 B 都可以独立创建，而无需担心会影响到其他人的合并操作。

图 2.9 – 带有 Develop 分支的 Git 特性分支工作流

带有 Develop 分支的 git 特性工作流是最流行的分支策略之一。Master 分支始终保持在一个可以部署到生产环境的状态，开发人员可以独立进行特性开发，而无需担心其他开发人员的合并冲突。

• git命令有很多，几乎不可能记住所有。我们提供了两种方法来帮助你在刚开始时更有信心。

将常用的git命令作为别名添加到你的.bash_profile文件中。以下是可以添加到.bashrc文件中的代码片段，它将与git相关的三个命令合并成一个gp别名：

图 2.10 – Git 函数示例（.bashrc）

前面的gp别名有两个参数：$1=file，或待暂存文件的路径，$2=commit message。以下输出显示了执行gp别名时的结果。我们来分解一下：

• shell_favorites是由git跟踪的本地工作目录。

• git stage命令将README.md文件移动到本地暂存区。

• git commit –m命令将README.md文件提交到本地仓库，并附上提交信息，在我们的示例中提交信息是test100721。

• git push命令将本地仓库中的更改推送到git所跟踪的远程仓库。

在下图中，你可以看到执行gp别名时的输出结果：

图 2.11 – git push 终端输出

相当不错，不是吗？添加git别名并不会让你成为更好的开发人员，但它确实能简化你的生活。

我给初学者的成功秘诀之一是随时手边有一份常用的git命令清单——一个git备忘单。我最喜欢的是 GitHub 教育组提供的：education.github.com/git-cheat-sheet-education.pdf。

SCM

流行的 SCM 工具包括 GitHub、GitLab 和 Bitbucket。

GitHub: www.github.com

GitLab: about.gitlab.com/

Bitbucket: bitbucket.org/

每种 SCM 工具都有独特的功能，帮助改善开发人员的体验，并且设计上都非常用户友好且易于使用。这些解决方案之所以容易使用，是因为每个工具都为用户开发了丰富的 UI。你可以通过在它们的网站上注册，免费使用这些工具！无论你选择哪个 SCM 工具，版本控制仍然是git。

在下表中，我们将比较 2021 年最流行的三种 SCM 工具：

表 2.1 – SCM 比较

到头来，只要你在学习，就没有什么选择是错误的。

在本节中，你了解了git、常见的git模式和常用的git命令。我们还讨论了源代码管理软件的可选项。

在接下来的部分，你将学习作为一名 DevOps 工程师所需的基础设施工具和技巧。

基础设施管理

高德纳（Gartner）这样定义 IT 基础设施：

IT 基础设施是由硬件、软件、设施和服务组件组成的系统，支持业务系统和 IT 启用的过程交付。

基础设施管理可以分为三个关键阶段：容量规划、基础设施配置 和 部署，如以下图所示：

图 2.12 – 基础设施管理阶段

基础设施管理的第一阶段是容量规划，接下来将对此进行详细讲解。

容量规划

容量规划是基础设施管理的第一步，随后是配置和部署。为了准确规划资源，收集准确的数据是至关重要的。容量规划中使用的工具包括 Splunk、ELK（Elasticsearch, Logstash, Kibana）栈和 New Relic。根据生产环境中的需求，持续的容量规划是必要的，以便根据需求自动扩展或缩减资源。

自动扩展资源具有两个好处：节省成本和提高性能。当资源被缩减时，它将不再被使用，从而不会产生费用。当资源被扩展时，额外的资源会在性能下降之前被添加进来。

基础设施配置

在成功收集和分析了容量数据后，我们可以进入基础设施配置阶段。配置包括根据容量规划得出的容量数据，创建、分配和删除基础设施资源。基础设施资源包括服务器、容器、存储、网络、IP 和负载均衡器，这些都可以在 AWS、Azure、GCP 等云服务提供商或本地部署的环境中创建和管理。

DevOps 工程师需要了解如何根据公司架构在云环境和本地环境中管理基础设施资源。在接下来的示例中，您将看到用于通过 CloudFormation、Terraform 和 Ansible 创建 AWS EC2 实例的模板代码。

如果组织在 AWS 上管理资源，则可以使用 AWS CloudFormation 来自动化基础设施资源的创建/分配/删除。以下是用于配置 EC2 实例的 CloudFormation 模板示例：

图 2.13 – CloudFormation 示例

要了解更多关于 CloudFormation 的信息，请访问 docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html。如果您的组织在多个云服务中管理资源，可以使用 AWS、Azure、GCP 和 Terraform 等提供商来自动化基础设施资源的创建/分配/删除。以下是可以用来提供 EC2 实例的 Terraform 文件：

图 2.14 – Terraform 示例

Ansible 还可以用于提供分布在各种环境中的资源，包括本地和云端。以下示例将在传入的变量 MY_KEY、EC2_TYPE、IMAGE、GROUP、COUNT 和 VPC_SUBNET 下创建一个 EC2 实例：

图 2.15 – Ansible 示例

现在，我们将讨论部署。

部署

在基础设施已配置完毕后，进入部署阶段。部署涉及在服务器或容器上安装、配置、发布和管理软件服务，这些服务器或容器用于承载生产工作负载。部署是在自动化配置基础设施资源时创建或分配的服务器或容器内部进行的过程。DevOps 工程师可以使用像 Chef、Ansible 和 Salt 这样的自动化工具来自动化软件服务的部署。

CI/CD 概念

持续集成（CI）和持续交付（CD）是与 DevOps 同义的。这是因为在第一章《职业路径》中讨论的每一项实践——计划、编码、构建、测试、发布、部署和运维——都包含在无限的 CI/CD 循环中，如图 2.16所示：

图 2.16 – 无限 CI/CD 循环

让我们首先探讨持续集成（CI）以及与之相关的实践和工具。

持续集成

持续集成是将多个开发人员的代码更改定期且频繁地合并到单一分支的过程。为了有效地做到这一点，您需要某种形式的自动化工具来构建您的代码并执行一系列测试。CI 服务器帮助通过 CI 流水线有效地集成您的代码。

在开发人员进行更改后，代码更改会通过 git 提交到源代码管理系统。CI 服务器具有内置的监听器（钩子），当代码被提交时，它会触发构建。流水线创建一个新的构建，并对构建执行一系列测试。这些测试包括静态代码分析、动态代码分析、秘密检测、漏洞扫描以及功能测试和集成测试。下图展示了 CI 服务器如何与开发生命周期的多个方面进行交互：

图 2.17 – CI 管道

持续集成服务器包括 Jenkins、Travis CI、CircleCI 和 GitLab。

这些工具提供了相似的功能，唯一的区别在于用户界面和编写管道所需的语言。

Jenkins

我们将讨论的第一个 CI 软件是最广泛使用的 Jenkins。由于 Jenkins 是开源的，它拥有一个庞大的社区和许多功能，这也是它免费使用的原因。Jenkins 的一些缺点包括维护开销以及复杂的管道设计。Jenkins 管道使用 Groovy，这是 Java 的一种衍生语言。以下是 Jenkins CI 使用的控制器-代理架构：

图 2.18 – Jenkins 架构

GitLab

GitLab 是一个 SCM 和 CI 工具。GitLab CI 自 2014 年推出以来虽然较新，但自发布以来其用户群增长迅速。GitLab CI 使用 runner 概念，这意味着每个作业都在自己的基于容器的执行器中运行。它提供了广泛的安全工具。如果你在本地运行 GitLab，它可能会很难管理。你可以在下图中看到，有许多服务器需要管理和配置。然而，GitLab 也为希望更快入门的小公司提供了 软件即服务（SaaS）选项。GitLab 基于 YML，使得编写和理解管道变得非常简单。以下架构图是实现 GitLab 在组织内的一种可行方案：

图 2.19 – GitLab 架构

持续交付

持续交付是持续集成的扩展。在构建阶段之后，代码更改会被交付到更高的环境，如阶段环境、测试环境、预生产环境和生产环境。采用持续交付时，必须具备自动化发布过程。下图展示了被识别为 CI 或 CD 任务的 CI 服务器阶段：

图 2.20 – CI/CD 管道

持续集成和持续交付是你随着时间推移而掌握的高级技能。如果你正在寻找入门级 DevOps 工程师岗位，它们可能不会要求你具备 CI/CD 的实际经验。然而，预计你能够讨论它并表现出兴趣，因为这很可能会成为你工作的重要部分。一个开始学习 CI/CD 的好方法是将管道整合到你的代码仓库中。祝你学习愉快！

云原生框架

云原生是一种软件开发方法，利用公共和私有云的能力。DevOps 工程师将在他们选择的任何职业中使用云原生技术，这使得它成为一项非常重要且备受追捧的技能。

云原生计算基金会（CNCF）的云原生定义：

云原生技术使每个人都能在现代环境中使用不可变技术。容器、服务网格、微服务、不可变基础设施和声明式 API 体现了这一方法，并使得独立的应用程序具有容错能力且易于管理。通过自动化，它们使工程师能够在几乎不干扰的情况下频繁更改。

云原生有多个优点，包括更快的开发时间和更快速响应客户的能力。

容器

容器是一种轻量级的、专门构建的应用程序，它已经打包了所有运行时所需的依赖项，因此可以在任何操作系统和任何环境中运行，所需的更改很少。多个容器可以在同一台机器上运行，并作为用户空间中的分段进程运行。容器占用的空间比虚拟机少，可以处理更多的应用程序，并且需要更少的虚拟机和操作系统。以下是比较多个虚拟机与多个容器所需基础设施的图示：

图 2.21 – 容器与虚拟机比较

Docker 练习

在接下来的练习中，我们将通过一个基本的 Docker 示例，这个示例可以在你的计算机上完成。

步骤如下：

1. 按照此教程在你的机器上安装 Docker：docs.docker.com/get-docker/。

2. 创建 Dockerfile：

   touch Dockerfile
   

3. 使用 vi 编辑器向 Dockerfile 添加内容：

图 2.22 – Dockerfile

在将前四行添加到文件后，确保使用 :w 保存文件，然后使用 :q 退出 vi。

以下是 Docker 镜像：

图 2.23 – Docker 镜像

如果你想查看构建过程中究竟发生了什么，可以省略 --quiet 命令。镜像构建并打标签后，你可以看到基础的 alpine 镜像以及 DevOps 书籍镜像可用。

1. 使用交互式终端命令运行你的容器：

图 2.24 – 交互式终端命令

–it 命令以交互式终端方式运行容器，这意味着会为容器打开一个终端会话，允许你与容器进行交互。

1. 停止并删除你机器上的所有容器和镜像：

图 2.25 – Docker 镜像删除

在本章中，你了解了容器以及它们在 DevOps 中所扮演的角色。如果你跟着练习走，你将会创建一个 Dockerfile，创建一个 Docker 镜像，并在你的计算机上运行 Docker 镜像！希望这能激发你继续深入学习 Docker，因为这是一条深不见底的兔子洞！

微服务架构

在查看所需架构之前，我们将介绍其他过时的架构。

单体架构

我们首先介绍单体架构，它共享单一的代码库和数据库。由于没有任何分离，所有内容都必须同时发布/部署，这导致了客户请求和生产上线之间的长时间延迟。我曾在多家公司工作，每一家公司都有单体应用。很有可能你在职业生涯中会遇到这种情况。

面向服务的架构

面向服务的架构 (SOA) 是朝着正确方向迈出的第一步——它通过服务拆分代码，从而减少了将更改部署到生产环境所需的努力和时间。面向服务的架构容易遇到与单体架构类似的问题，例如依赖关系，要求即使是一个服务进行修改，也需要重建整个应用。我曾与多家公司合作，它们的应用都使用了 SOA。

微服务

微服务架构因大型科技巨头如亚马逊、Netflix 和谷歌发布了其成功案例而受到广泛关注。SOA 和微服务的关键区别在于通信协议、存储和规模。首先，微服务使用与语言无关的协议与 UI 进行通信，虽然导致更多的远程调用，但也大大提高了容错性。其次，每个微服务都有自己的存储/数据库，这意味着每个微服务可以为其需求设计合适的数据库，而不是使用整个应用程序共享的数据库。最后，规模和缺乏相互依赖性是微服务与 SOA 之间的真正区别。微服务可以随时部署，而不会影响其他组件。SOA 共享数据库，各个服务之间仍然存在一定的依赖关系，这使得无法单独部署某个服务。大多数公司都在努力实现微服务架构，这也是一个非常关键的技能。

在下图中，您可以看到单体架构、SOA 和微服务架构的对比：

图 2.26 – 架构对比

接下来，我们将讨论软技能对于 DevOps 工程师的重要性。

软技能

软技能被定义为能够使一个人有效且和谐地与他人互动的个人特质。潮流正在发生变化，DevOps 工程师不能再仅仅依赖技术能力来取得成功。以下是 DevOps 工程师最重要的几项软技能。

同理心

在 DevOps 中，同理心是指理解同事和客户观点的能力，或者说是站在他人立场看问题的能力。以冷静的态度与同事沟通，这将有助于创造一个更愉快的工作环境，使新想法得以蓬勃发展。如果你的想法与同事或客户的不同，可以先对他们的观点给予积极反馈，然后再表达你的不同意见。与同事培养同理心确保每个人的想法都能被听到，存在的问题也能够得到解决。与客户培养同理心可以确保所有反馈都被采纳，最终达成令人满意的解决方案。

团队合作

在团队合作中，多个视角能够同时审视代码。协作可以确保每个人都保持一致，最终交付一个连贯的产品。

适应能力

技术不断变化，作为一名 DevOps 工程师，你必须证明自己能够快速转换思路，无论是学习一门新语言还是迅速调整优先级。在面试中，你可以讨论自己如何学习一门新的编程语言，或者如何在解决上一个项目时与不同部门合作。如果你不愿意改变，你在 DevOps 中不会成功。

良好的沟通能力

良好的沟通包括从面对面的交流到 Slack 消息的各种方式。作为一名 DevOps 工程师，你可能需要与完全远程办公的团队成员合作，他们可能处于不同的时区并且来自不同的文化背景。因此，你必须能够在这些情况下有效沟通。记住，人们都很忙，所以选择最有效和高效的沟通方式。

如果没有强大的软技能，找工作将会非常困难。DevOps 是一项团队运动，需要你与不同的人合作，在快速变化的环境中适应。没有戏剧性冲突或自我膨胀的空间；每个人的意见都很重要，你需要尊重这些意见。

初级 DevOps 认证

和其他行业一样，DevOps 的认证数量也在不断增加。证书是展示你知识的好方式，但它们无法替代经验，也不是获得 DevOps 工程师职位的必需条件。DevOps 认证可以帮助你在面试过程中脱颖而出，还能展示你持续学习的欲望。当到达绩效评估时，你可以利用自上次评估以来获得的新认证作为争取更多成绩的筹码。以下是你可以选择的不同证书列表：

AWS 认证

AWS 提供了一些针对 DevOps 工程师的入门级认证，从 AWS 云实践者认证开始，这需要大约 6 个月的 AWS 实操经验。完成 AWS 云实践者考试后，你可以开始为 AWS 助理架构师考试做准备。以下是提供的认证：

• AWS 云实践者 (aws.amazon.com/certification/certified-cloud-practitioner/)

• AWS 助理架构师 (aws.amazon.com/certification/certified-solutions-architect-associate/)

Google Cloud 认证

对于 Google，并没有通用的初级认证，但助理云工程师认证是进入 GCP 的一个良好入门。

助理云工程师 (cloud.google.com/certification/cloud-engineer)

Azure 认证

对于 Azure，存在一个基础认证，涵盖了很多基础内容。还有其他多个认证，但我们将在下一章的 专业能力 部分介绍更多云认证。

基础知识 (docs.microsoft.com/en-us/learn/certifications/exams/az-900)

其他资源

对于初学者内容，Udemy、EdX 和 Coursera 上有许多课程，具体取决于你感兴趣的领域。涵盖 Docker、Terraform 和 Kubernetes 的认证，以及高级云专业认证和职业认证，将在下一章中讲解。

总结

在本章中，你学习了成为初级 DevOps 工程师所需的基本技能。这些技能包括操作仅文本终端如 Bash，使用各种脚本语言进行自动化，以及理解 Git 和源代码管理。你还了解了 Ansible 和 Terraform 等基础设施管理工具的基础知识，并获得了对 CI、CD 和流水线的基本理解。

在下一章中，你将更深入地了解各类 DevOps 专业角色所需的技能。

第三章：高级 DevOps 实践者的专业技能

随着 DevOps 工程师在其职业特定领域的进展，他们可能因其自然能力或技能而脱颖而出，或因对该主题的强烈喜爱而脱颖而出。这导致 DevOps 工程师走上了专业化的职业道路。本章的重点将放在进入不同 DevOps 专业所需的技能上。

中高级内容

本章对于任何对 DevOps 领域感兴趣的人都充满了有用信息；然而，它是为已经实践了至少 1-3 年的 DevOps 工程师而设计的。本章假设个人已经掌握了前一章节列出的知识。

本章将涵盖以下专业 DevOps 能力：

• CI/CD 管道 DevOps 工程师

• 基础设施即代码

• 云和应用现代化

• 容器和容器管理

• 安全性

• 高级 DevOps 认证

• 能力矩阵

CI/CD 管道 DevOps 工程师

一位 CI/CD 管道 DevOps 工程师负责从开发人员的代码自动化到生产环境的端到端过程。由 CI/CD 工程师开发的策略是公司 DevOps 路线图的中心关注点。重新审视前一章节的无限 DevOps 循环，您将想起 DevOps 的所有阶段都包含在 CI/CD 循环中，如下图所示：

图 3.1 – 无限 DevOps 循环

对于 CI/CD DevOps 工程师来说，最受欢迎的技能之一是能够创建、维护和推广共享管道库的能力。

维护共享管道库

CI/CD 管道工程师将维护共享管道库及与 DevOps 生命周期的每个阶段相关的所有标准和实践。

CI 工具管理

根据公司规模的不同，CI 工具管理的责任可能由管道工程师负责；对于本书，我们将在云和应用现代化部分讨论工具管理。

要维护共享管道，DevOps 工程师必须对管道工具和管道架构具有专家级的理解。维护共享管道库还涉及管理和维护一个内部开源项目。当提出将创新想法添加到管道时，DevOps 工程师的角色是确保其正确实施。

定义：内部开源

内部开源是采用开源软件开发最佳实践，并在组织内建立类似开源的文化，用于开发其非开源和/或专有软件。

以下图示是共享管道库如何工作的图形表示：

图 3.2 – 共享管道库

在前面的图表中，涉及的内容很多；首先，我们有一个共享的管道库，其中包含不同的组件模块，这些模块可以被多个产品使用。我们有一位开发人员开发了一些他们认为对公司其他部门有用的新功能，因此他们提交了一个拉取请求，这个请求需要在正式成为库的一部分之前由 CI/CD DevOps 工程师进行审核。最后，你可以看到两个不同的产品在它们自己的管道中使用了共享库的组件。

与管道集成的所有权

一名 DevOps 管道工程师需要对管道各阶段的工具有广泛的了解。以下图表展示了管道不同阶段可用的众多工具：

图 3.3 – CI/CD 工具

上面的图表旨在展示 CI 管道各个阶段可用的众多工具。一个有价值的资源，可以让你查看并研究每个工具的是 digital.ai 的 DevOps 工具周期表（digital.ai/periodic-table-of-devops-tools）。

CI/CD DevOps 工程师负责确保各种工具可以集成到公司的管道中。必须开发与工具 API 连接的模块，然后将解决方案提交安全审查，以确保其符合公司标准。一旦它成为管道的一部分，CI/CD 工程师负责在工具版本和 API 变化时对各种集成进行持续支持。

在本节中，你学到了一名 CI/CD DevOps 工程师必须了解 CI/CD 生命周期的所有阶段，并且要了解每个阶段使用的各种工具。

在下一节中，我们将介绍成为一名成功的 DevOps 基础设施工程师所需的技能。

基础设施即代码

DevOps 基础设施工程师负责配置、管理和维护公司各个应用程序中使用的基础设施。通常被称为 基础设施即代码（IaC） 工程师，IaC 工程师与架构师密切合作，并且需要与多个不同的团队保持良好的关系。在本节中，我们将介绍成为一名成功的 DevOps IaC 工程师所需的技能，以及你需要深入了解这一角色的工具。

网络基础设施设计

DevOps IaC 工程师与架构师密切合作，在某些情况下，还会在许多项目中担任架构师的角色。

网络基础设施设计：定义

网络基础设施设计是一个过程，包括网络综合、拓扑设计和网络实现，旨在确保网络或服务满足运营商和用户的需求。

存储管理

DevOps IaC 工程师需要掌握广泛的存储管理和优化相关知识。存储管理涵盖了卷迁移、过程自动化、灾难恢复、数据复制、自动配置、快照和镜像、存储虚拟化以及压缩等内容。

容器化（Docker 和 Kubernetes）

DevOps 工程师需要熟悉容器；然而，专注于基础设施管理的 DevOps 工程师需要能够处理大型 Docker 和 Kubernetes 集群的编排和管理。像 Terraform 和 Ansible 这样的工具可以帮助完成这项工作。

容器化的主题将在本章的容器与容器管理一节中详细讨论。

网站可靠性工程

网站可靠性工程（SRE）专注于系统的可用性和可靠性，最早由 Google 的 Ben Treynor 于 2003 年提出。SRE 的目标与 DevOps 相同——缩小开发与运维之间的差距。如果你在一家大型组织工作，SRE 和 DevOps 将会是两个独立的职能，因为它们的目标和关注点不同；然而，SRE 和专注于基础设施的 DevOps 工程师所需的技能非常相似。SRE 侧重于保持系统运行和可用，而 DevOps 旨在减少市场推出时间并支持快速变更。在以下的图示中，应该占据大部分时间的内容是 SRE 层级结构的基础：

图 3.4 – SRE 层级结构

上述图示展示了 SRE 基础的主动式监控方法，接着是快速且彻底的事件响应和详细的无责备事后分析。SRE 的核心理念是快速发现和修复问题，并通过变更来避免将来再次出现同样的问题。

在本节中，我们只是浅尝辄止地探讨了这一深奥且有趣的话题。如果你想深入了解 SRE，可以查看 Google 出版的 SRE 书籍：sre.google/sre-book/table-of-contents/。在本章的最后一节，我们将列出与 SRE 相关的多个认证。

在本节中，你了解了成为专注于基础设施的 DevOps 工程师所需的技能。你需要具备网络设计、存储管理、SRE 和容器化的技能。

在下一节中，我们将介绍专注于云计算和应用现代化的 DevOps 工程师所需的技能。

云与应用现代化

在本节中，你将学习云计算和应用现代化，并了解 DevOps 工程师在这一领域中的特殊角色。首先，我们将讲解所需的高级云计算知识，随后介绍云现代化技术。

DevOps 领导者需要调整以适应对更新服务的需求，同时保持、运营并改进现有的应用程序组合。这个新需求来自于现代技术的引入，随着技术的不断发展，这种需求也在不断增加。有许多应用程序现代化方法（包括重新托管、重新平台化和替换），它们有不同的目的、效果、价值、成本、风险和影响。

高级云技能

成为一名 DevOps 云工程师，除了深入了解云平台，还必须具备强大的脚本编写技能。你需要理解不同云产品的功能及其协同工作方式。如果你在一个多云环境中工作，以下图示会非常有用：

图 3.5 – 云提供商对比

我对 Amazon 的术语非常熟悉；当我需要在 GCP 工作时，旁边有一个备忘单非常有用。方法论是相同的；不过，不同云提供商之间的术语差异巨大。

DevOps 云工程师还需要具备将应用程序和服务部署到云资源的能力；这也是不同云提供商之间差异很大的一个方面。作为 DevOps 工程师，理解云提供商的 CLI 工具也非常重要。你很少会通过图形用户界面（GUI）与资源进行交互；相反，你会使用 CLI 工具或 API 调用各种云服务。以下链接是关于各个云 CLI 工具的文档：

• GCP: cloud.google.com/sdk

)

• AWS: aws.amazon.com/cli/

)

• Azure: docs.microsoft.com/en-us/cli/azure/install-azure-cli

)

在下一节中，我们将介绍云技术的另一个方面——应用程序现代化。这个话题内容丰富，没有有效的方式可以在没有实践的情况下掌握它；然而，Gardner 提供了一些对那些想要深入了解的人来说很有用的资源。

应用程序现代化

作为一名专注于云技术和应用现代化的 DevOps 工程师，评估现代化需求背后的驱动力至关重要。驱动力可以分为需求方和供给方两方面：

• 供给方：

  • 适应性：缺乏实施新需求的能力

  • 价值：缺乏提供的价值、支持的质量以及所提供的信息

  • 敏捷性：缺乏以可接受的风险水平快速进行变更的能力

• 需求方：

  • 成本：与其提供的价值相比，拥有成本较高。

  • 复杂性：复杂性导致可维护性差，并在变更时增加风险。

  • 风险：安全性、合规性、可支持性或可扩展性风险。

在 DevOps 工程师审查并评估系统、确定问题后，必须识别问题的根本原因。

选择现代化方法

现代化的原因可以分为三大类：功能性、技术性和架构性。一旦确定了原因，DevOps 工程师必须决定最佳的现代化方法。以下是一个图示，展示了不同现代化方法在努力和复杂度上的差异：

图 3.6 – Gartner 的现代化方法在解决根本原因方面的能力

作为一名专注于云和应用现代化的 DevOps 工程师，你需要对不同的现代化方法有深入的理解。Gartner 发布了一篇文章，www.gartner.com/doc/reprints?id=1-25RJ3RG2&ct=210408&st=sb，该文详细介绍了上述每种方法。

在本节中，我们介绍了作为专注于应用现代化和云的 DevOps 工程师所需的技能。专注于云的 DevOps 工程师必须非常熟练地进行云应用的配置和部署。DevOps 工程师需要对云 API 和 CLI 的功能有深刻理解，并理解云服务如何与其他云服务提供商的产品进行比较。此外，专注于云的 DevOps 工程师可能还需要协助应用现代化项目。

在接下来的章节中，我将讨论作为专注于容器的 DevOps 工程师所需的技能。

容器与容器管理

容器管理、编排和维护是所有 DevOps 工程师必须掌握的技能；然而，随着云原生 Kubernetes 和其他云编排工具的出现，这已迅速成为一个专业领域。在本章中，我们将介绍作为专注于容器管理的 DevOps 工程师所需的技能。

成为容器专家所需的素质

能够开创、采用并掌握新的容器方法论是区分通才与容器管理专家的关键技能。

容器管理软件

专注于容器化的 DevOps 工程师必须精通容器管理软件。最广泛使用的容器管理软件包括 Docker 和 Kubernetes。容器管理软件的目的是五个方面：自动化、监控、安全、扩展和部署。我们将首先讨论自动化方面：

• 容器自动化：容器编排的自动化涵盖并提升了监控、安全、扩展和部署的水平。

• 监控：容器需要监控，例如活跃度探针，这些探针与监控仪表盘和警报关联，能够帮助及早发现和修复问题。有多种工具可用于监控，包括 Prometheus、Dynatrace 和 Datadog。

• 安全：容器安全是 DevOps 工程师最关心的问题，因为如果容器被攻破，整个应用都暴露在外。为了确保你的容器生态系统安全，首先要确保所使用的基础镜像是安全的。确保容器镜像来自受信任的源并且已签名，运行时操作系统层是最新的，并确保你有更新镜像的修补策略。接下来，确保你的镜像存储在安全的位置，并实施基于策略的身份验证，以减少人为错误引入容器的机会。集成安全测试和扫描并自动化部署过程是减少风险的另一种方式。像 Twistlock 这样的工具可以帮助实现这一目标。扫描容器可以让容器被重建并重新部署，而不是尝试修补正在运行的容器。

• 扩展：容器的设计是不可变的，这意味着代码在部署后不能更改。容器的一个好处是，通过适当的配置和监控，扩展某个组件的实例数目变得十分简单。困难的部分是确定在何时进行扩展的界限。

本部分描述了成为专注于容器的 DevOps 工程师所需的条件。在本部分的结尾，我将分享一些我在学习 Kubernetes 时使用的动手教程：

• Kubernetes 硬核实践: github.com/kelseyhightower/kubernetes-the-hard-way

)

• Kubernetes 培训课程: www.udemy.com/course/certified-kubernetes-application-developer/

在接下来的部分中，我们将讨论在 DevSecOps 领域取得成功所需的条件，换句话说，就是专注于安全的 DevOps 工程师所需的技能。

安全

专注于安全的 DevOps 工程师通常被称为 DevSecOps 工程师。DevSecOps 工程师对 CI/CD 过程也有深刻的理解。

安全是每个人的责任

安全是每个人的工作。任何与交付软件相关的人都在确保应用安全方面扮演着角色。

DevOps 安全工程师的工作是确保安全从项目开始时就被融入和包含。

专注于安全的 DevOps 工程师的职责分为两个方面：CI/CD 过程和环境与数据。我们首先来看 CI/CD 过程安全以及实施它所需的技能。

CI/CD 过程安全

让我们回顾一下之前讨论的流水线；以下图表中已添加数字，以便与以下安全项对应：

• 容器扫描 (1): 容器扫描应添加到将新容器引入注册表的过程中。像 Twistlock 这样的工具被广泛使用。最受欢迎的容器扫描工具是 Twistlock；然而，也有许多其他工具，它们可以在这里查看：techbeacon.com/security/17-open-source-container-security-tools。

• 安全测试 (2): 这包括在构建过程中运行安全静态分析测试（SAST）工具，以及在将任何预构建的容器镜像拉入构建流水线时扫描已知的安全漏洞。在以下示例中，这些库是合规性模块的一部分。关于 SAST 工具，市面上有许多工具，包括开源和付费工具。

• 安全验收测试 (3): 这种类型的测试被称为动态应用安全测试（DAST）。其目的是在应用程序运行时动态地测试安全漏洞。该类别的综合工具列表可以在此找到：owasp.org/www-community/Vulnerability_Scanning_Tools。

• 补丁和安全更新 (4): 补丁和安全更新应该有一个流水线，以便它们可以自动运行并按计划进行。可用的工具差异很大。根据我的经验，最好的补丁工具有时只是一个在流水线中执行的简单脚本。做你自己的研究，形成你自己的观点。

• 配置管理 (5): 其目的是确保所有基础设施遵循公司安全和合规政策。通常，这在基础设施配置或应用配置更改后运行。

图 3.7 – CI/CD 安全

将安全性集成到 CI/CD 流水线中是棘手的，因为它需要领域知识、特定工具的知识以及对行业安全最佳实践的理解。一篇帮助我更好理解合规性流水线的文章可以在以下链接找到：itrevolution.com/book/devops-automated-governance-reference-architecture/。在下一部分，我们将讨论 DevSecOps 工程师需要关注的领域，以确保环境和数据的安全。

环境和数据安全

各种环境及其相关数据是公司最宝贵且最脆弱的资产，如果没有得到正确保护。确保最佳实践以自动化和可扩展的方式实施是 DevOps 工程师的职责。以下是一些概念，将有助于进一步研究该主题：

• 最小信任与零信任原则：过程和应用程序被授予其正常运行所需的最小访问权限。听起来简单，但实际上这是一个庞大的工程，因为每个账户都需要进行审计，以确保它具有正确的访问权限。最小权限原则是零信任模型的核心部分；然而，零信任模型更为全面，并且要求更加严格。此外，零信任的实施和维护更为复杂，因为需要更多的访问策略。以下图表展示了零信任的三个原则：明确验证、使用最小权限访问和假设已被攻破：

图 3.8 – 零信任原则

• 隔离原则：隔离原则适用于在微服务架构中运行的容器。隔离原则包括多个组件，如状态隔离、空间隔离、时间隔离和故障隔离。

• 数据加密：具有集成功能的容器编排平台有助于减少未经授权访问的可能性。

• 安全 API 网关：安全的 API 增加了授权和路由的可视性。通过减少暴露的 API，组织可以减小攻击面。

高级 DevOps 认证

随着你作为 DevOps 工程师的进展，能够获得的认证数量也会增加。虽然专门的 DevOps 角色通常不要求拥有认证，但认证能迅速展示你的技能和专业知识，并且体现你对行业的承诺。

AWS 认证

AWS 提供了多个高级认证，具体取决于你的职业发展方向。大多数高级 AWS 认证要求至少拥有 AWS 云实践者认证。以下是所提供的认证列表：

• AWS 认证解决方案 架构师 – 专业 (aws.amazon.com/certification/certified-solutions-architect-professional/)

• AWS 认证 DevOps 工程师 – 专业 (aws.amazon.com/certification/certified-devops-engineer-professional/)

• AWS 认证 安全 – 专业 (aws.amazon.com/certification/certified-devops-engineer-professional/)

Google Cloud 认证

Google 提供了多个与 DevOps 相关的高级认证，具体取决于你感兴趣的专业领域。以下是所提供的认证列表：

• 专业云 架构师 (cloud.google.com/certification/cloud-architect)

• 专业云 DevOps 工程师 (cloud.google.com/certification/cloud-devops-engineer)

• 专业云安全 工程师 (cloud.google.com/certification/cloud-security-engineer)

• 专业云网络 工程师 (cloud.google.com/certification/cloud-network-engineer)

Azure 认证

Azure 提供众多高级认证，包括 DevOps 和安全技术的认证路径。DevOps 认证路径为 AZ-900、AZ-104，然后是 AZ-400。架构师的路径为 AZ-90、AZ-300，然后是 AZ-304。安全认证的路径为 AZ-900 后跟 AZ-500。以下是所提供的认证列表：

• Microsoft Azure 管理员 (docs.microsoft.com/en-us/learn/certifications/exams/az-104)

• Microsoft Azure 架构技术 (docs.microsoft.com/en-us/learn/certifications/exams/az-303)

• 设计与实施 Microsoft DevOps 解决方案 (docs.microsoft.com/en-us/learn/certifications/exams/az-400)

• Microsoft Azure 架构设计 (docs.microsoft.com/en-us/learn/certifications/exams/az-304)

• Microsoft Azure 安全技术 (docs.microsoft.com/en-us/learn/certifications/exams/az-500)

Kubernetes 认证

Kubernetes 是最大的开源项目之一，也是雇主在招聘 DevOps 工程师时所看重的顶级技能之一。以下是所提供的认证：

• 认证 Kubernetes 管理员 (CKA) (www.cncf.io/certification/cka/)

在下图中，您可以看到三大云服务提供商的认证路径——AWS、Azure 和 GCP：

图 3.9 – 云认证路径

在接下来的章节中，我们将讨论 DevOps 工程师的技能矩阵。

能力矩阵

能力矩阵是一个可视化的图表或图形，展示了公司内各个职位所需的技能和教育背景。在我们深入了解能力矩阵定义之前，有几点需要先理解。

首先，并不是所有组织都使用能力矩阵来招聘和晋升员工，其次，使用能力矩阵的每个组织会有不同的要求。

决定在能力部分进行讨论的原因是，每个公司都有不同的能力标准，并且这些能力与不同的级别相对应。这意味着，在 X 公司的一名高级 DevOps 工程师可能与谷歌的 DevOps 工程师相对应。这在我职业生涯初期曾让我感到焦虑和沮丧。我希望这一部分能为您提供足够的清晰度，帮助您理解级别、能力和薪酬之间的关系。

本章的目的是向您介绍能力矩阵的概念，并为您提供另一种工具，用于在技能提升的过程中跟踪您的进展。我们将从解析能力矩阵开始。

矩阵解析

能力矩阵分为三个主要部分：技能、级别和能力。

图 3.10 – 能力矩阵

首先，我们将讨论技能部分。

技能

技能部分通常位于图表的垂直（y）轴上。技能可以根据公司需要的具体程度进行细分或概括。图表上表示的技能将特定于您所在的部门，因此，如果您的部门存在能力矩阵，最好保持更新并跟进。接下来，我们将讨论矩阵的水平轴。

级别

该级别位于图表的水平（x）轴上。不同公司之间的级别有所不同。我目前在一家组织工作，所有个人贡献者都被映射到不同的助理级别。如果你在谷歌工作，你的角色会被映射到 L1 到 L11，其中 L3 是工程师，L11 是资深谷歌专家。没有能力映射的级别不过是一个没有意义的术语。不幸的是，级别并不是通用的，如果你决定在当前组织之外的公司追求职业生涯，你需要调查当前技能在其他地方的映射情况。如果你有兴趣了解不同公司级别的更多信息，一个有价值的资源是 levels.fyi：www.levels.fyi/。接下来，我们将讨论能力。

能力

能力被定义为成功完成某项任务的能力。能力位于图表中水平和技能的交叉点。每个级别对于每项技能都有不同的成功标准，这意味着成功是相对于您所处的级别而言的。越来越多的公司在每个级别内采用能力带。这样做的目的是提供入门级能力、期望的能力，有时还会有更高级别的能力：

• 入门能力是指在给定级别上，某项技能被考虑为角色的最低能力。如果你在所有领域都处于最低范围，你找到工作的机会并不大。然而，如果只有少数几个领域处于最低范围，这些可以成为你在面试时谈论的内容，展示你正在努力改进的方面。

• 期望的能力是指该级别中约 50%个体的能力，或者更简单地说，就是招聘团队希望找到的能力水平。招聘经理的理想情况是找到一个在各方面都具备期望能力的候选人。

• 高级能力是指在当前级别和下一个级别之间出现大量重叠的点。如果你在多个技能领域处于高级能力区间，你就准备好晋升到下一个级别。

下图显示了不同级别之间存在能力重叠。这一特点旨在允许不同级别之间的灵活流动：

图 3.11 – 能力矩阵级别

你的薪资范围受你的级别限制，但在同一级别内，技能能力决定你在该范围内的位置。以下部分将详细讨论这一点。

与级别和能力相关的薪酬

薪酬受公司内各级别薪资区间的限制。不同级别的薪资区间会重叠；这意味着，一位高级助理可能会获得比首席助理更高的基本薪资。下图很好地展示了这一点：

图 3.12 – 薪酬 – 级别图

为了在每个级别内实现薪酬的标准化，经理们通常会被要求在每个薪资区间内确定一个特定的百分位。这在查看带有薪资范围的职位发布时非常有用。

摘要

在本章中，你了解了 DevOps 专家角色所需的技能，包括 CI/CD 管道专家、基础设施专家、云计算与应用现代化专家、容器专家以及安全专家。本章的主要收获是，DevOps 专业技能需要通过实践和投入来磨练。我们还讨论了能力矩阵及其如何与不同薪资等级相对应。

在下一章中，我们将讨论如何在网上重塑自己。

第四章：第二节：申请过程

从更新你的简历和在线资料，到在提交简历后发送跟进邮件，本书的这一部分将帮助你应对申请 DevOps 职位的各个方面。

本节包括以下章节：

• 第四章**, 重新塑造自我

• 第五章**, 构建你的社交网络

• 第六章**, 导师制度

• 第七章**, 与招聘人员合作

第四章: 重塑自我

你不断学习、成长，成为更好的自己。那些经常见到你的人知道你是谁，了解你拥有哪些技能；然而，对于世界上其他的人来说，你是通过你的社交档案来定义的。在本章中，我们将指导你如何确保你的社交档案、简历和个人网页与你现在的状态以及你想要达成的目标相匹配。我们将从更新你的社交档案开始，然后处理其他在线站点，如 GitLab 和 GitHub，最后确保你的简历与社交档案一致。

本章将涵盖以下主要内容：

• 改进你的 LinkedIn 个人资料的方法

• 更新简历以匹配你所追求的职业

• 更新或创建个人网页

• 利用 Twitter 和其他社交档案

改进你的 LinkedIn 个人资料的方法

你的社交档案被所有人看到，招聘人员也在不断查看它们。一个更新且维护良好的LinkedIn个人资料是招聘人员和招聘经理最容易注意到的方式。在这一部分，我们将介绍所有必要的更改，确保你的 LinkedIn 个人资料最好地代表你自己，并能被更多人看到。

更新你的头衔

你的头衔在 LinkedIn 上非常显眼，默认情况下，它显示的是你的职位和工作地点。发挥创意，利用它展示你的顶级技能，宣传你的求职信息，或者使用独特的标语，确保你的个人资料在人群中脱颖而出。

如果你是一个有经验的 DevOps 工程师，正在寻找职业转型，可以尝试以下头衔：

DevOps | 云计算 | 容器 | 开放远程机会

如果你不是在寻找新职业，但想要让自己脱颖而出，可以尝试以下头衔：

经验丰富的云工程师 | AWS | GCP | AZURE

以下是两个虚构的个人，一个左侧是平淡无奇的头衔，右侧则是大胆清新的头衔：

图 4.1 – LinkedIn 头衔更新

你的头衔最多可以包含 220 个字符，应该描述你擅长的领域以及人们为什么应该对你感兴趣。包含像DevOps、云计算和AWS这样的关键词，会增加你在 LinkedIn 上被搜索到的次数。

在下一部分，我们将讨论为什么推荐很重要以及如何请求推荐。

推荐意见

LinkedIn 可以请求与你曾共事的同事和经理进行推荐，并在你的个人资料上展示这些推荐。这使得访问你个人资料的人，在面试之前就能看到与你共事过的人的推荐意见。以下是请求推荐时的一些提示：

• 推荐应来自与你关系良好的人，最好是在 LinkedIn 上请求推荐之前，你能够请对方提前推荐你。

• 推荐应该来自你尊敬的人，以及在你所在行业中受人尊敬的工作。

• 如果你是一个资深的 DevOps 专业人士，推荐应该来自你曾指导过的人、其他资深的 DevOps 同行，或者是与你有紧密合作关系的主管或副总裁。

• 不要向很长时间没有联系过的人或与你关系不好的人请求推荐。

• 来自你亲近教授的推荐非常有影响力。

• 不要请求另一位初级 DevOps 工程师或也在寻找第一份工作的人的推荐。相反，向你的导师（如果有的话）请求推荐。关于导师的重要性，将在第六章《导师制》中讨论。

如果你收到一条推荐并且对其外观不满意，可以要求修改。确保提供具体的反馈和请求更改的理由。写得不好的推荐可能弊大于利。以下是一个写得不好的推荐示例：

](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/dop-crr-hb/img/Figure_4.2_B18117.jpg)

图 4.2 – 一条不完整且模糊的推荐

前面推荐的问题在于语法差且缺乏细节；约翰擅长哪些任务，为什么？如果我看到这个推荐，我会感到很疑惑；它来自一位非常有信誉的人，但缺乏任何有意义的细节。以下是经过更好语法修正和更多细节补充后的同一条推荐：

](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/dop-crr-hb/img/Figure_4.3_B18117.jpg)

图 4.3 – 一条写得好的推荐

总结这一部分，推荐很重要，并且当它来自一位受人尊敬的个人且写得好的时候，可以帮助你找到工作。在接下来的部分中，我们将讨论你应该在 LinkedIn 个人资料中包括但可能未包括的部分。

额外的部分

在 LinkedIn 中有些个人资料部分，可能是你没有时间更新，或者根本不知道有这些内容。LinkedIn 不像简历那样有单页限制；如果你有可能增加求职机会的信息，应该把它们包括在内。

精选内容

精选内容部分位于页面的顶部，允许你添加已发布的文章、参与的项目以及个人网站。这应该是能够公开分享的职业成就的亮点。精选内容部分的一个优点是，它可以轻松地与成就部分的内容结合，我们接下来将讨论这个部分。

成就

成就往往容易被忽视。成就部分可以用来添加出版物、专利、课程、项目、荣誉和奖项、考试成绩、组织和事业。成就部分的信息可以作为精选内容添加，并显示在你页面的顶部。

经验

经验部分通常由个人在 LinkedIn 上直接更新；然而，描述每项经验的细节往往不足，尤其是当你在一个职位上待了很长时间时。一个好的规则是，每次完成一个项目或计划时更新你的经验部分。如果你正在寻找 DevOps 工程师的第一份工作，尝试突出你过去职位中与 DevOps 工程师相关的经验。

个人资料照片

更新你的个人资料照片并不是找到工作或被认出的必要条件；然而，这样做并不会有坏处。拍摄你家庭照片或宠物照片的人可以为你拍一张头像，用于个人资料上。拥有个人资料照片的档案在搜索算法中的排名较高，因此会有更多的招聘人员和招聘经理看到你的个人资料。

在下一节中，我们将讨论技能认证的力量以及技能考试。

技能认证

技能认证可以由你添加，并由你的任何一位一度联系人验证。验证你技能的个人越多，别人搜索该技能时，你被找到的可能性就越大。如果你正在寻找 DevOps 工程师的工作，获得 AWS、Python 和 DevOps 等技能的认证可以帮助你被注意到。为了进一步增加基于某一技能被找到的可能性，你可以参加技能评估。

LinkedIn 技能评估是针对特定技能的专业考试；通过后，你会在个人资料上获得一个徽章，告诉大家你已经通过了技能评估。这一认证再次提高了你在搜索算法中的排名，增加了被招聘人员注意到的机会。最后，我们将讨论与同行业内其他专业人士互动的内容。

分享、点赞和评论

与其他 DevOps 专业人士互动已经被证明是我在 LinkedIn 上建立联系和关系的最强有力手段。在 第五章，建立你的网络，我们将讨论帮助你在 LinkedIn 上建立关系的策略。每次你分享、点赞或评论内容时，你被注意到或出现在潜在雇主的动态中的可能性都会增加。

在这一部分中，我们讨论了帮助增加在 LinkedIn 上被注意到可能性的策略；在本章的下一部分，我们将讨论确保你的简历准备好呈现给招聘经理的策略。

更新你的简历以匹配你追求的职业

即使你并不积极寻找工作，保持一份更新的简历也是一种良好的做法，因为完美的机会可能随时出现。在这一部分，我们将讨论一些提升简历的技巧，这些技巧将带来更多的回调，甚至可能是面试机会。

无论你的技能有多强，经验有多少，你的简历应该控制在一页纸内。如果埃隆·马斯克能将自己的经验压缩到一页纸上（novoresume.com/career-blog/elon-musk-one-page-resume），你也能做到。简历的目的是让招聘人员和招聘经理在不到一分钟的时间内快速了解候选人。有些公司在流程中加入了计算机化的层面，会扫描你的简历中的关键词，并在将其传递给人工审核之前验证是否符合要求。接下来，我们来看一下简历的六个部分应该包括什么，首先是联系方式。

联系方式

联系方式至少应包括你的名字（与在线个人资料上显示的相同）、电子邮件地址和电话号码。建议包括你的位置和个人资料信息，特别是如果你刚刚更新了这些信息。你不鼓励在简历中包含照片，因为招聘人员认为这可能会给选择过程带来偏见。接下来是至关重要的信息：你的目标。

目标

这一部分描述了你能提供什么以及你希望获得什么类型的职位。目标应该简洁明了，不超过一两句话。根据你的个人喜好，你可以写一个通用的目标，例如以下内容：

拥有 20 年经验的 DevOps 领导者，专注于云原生安全和 Kubernetes，寻求加入一家有强大工程文化的快节奏公司。

上述目标中的一个要点是过度使用关键词，强调你在寻找的职位中带来的技能。与此相对的方式是一个针对具体职位的目标，例如以下示例：

拥有 20 年经验的 DevOps 领导者，专注于 CICD、安全和 Kubernetes，寻求加入 XYZ 公司担任 DevOps 工程师主管职位。

后一种方法是更好的选择，因为它允许你挑选关键词并将其包含进去，同时通过使用具体的职位名称和公司名称让其更加个性化。另一方面，你可能希望尽可能多地申请职位；在这种情况下，你应始终准备一份更新过的简历，里面包含一个通用的目标可以使用。关于目标的一个关键点是，它应包含你希望被注意到的关键词，无论是自动检查器还是人类审核。 在前面的例子中，我们使用了几个关键词，包括工作经验。接下来，我们将讨论简历中最大的一部分：你的工作经验。

经验

经历应按时间倒序排列，最新的职位排在最上面。每个职位应包含五个关键信息：职位、雇主、开始日期、结束日期以及成就。所有信息应尽可能准确。始终假设你的信息会被验证；即使是诚实的错误也可能导致失去工作机会。成就应具体并包含量化数据。

与应用团队合作，显著提高面向客户的应用程序可用性

上述示例是一个友好的开场白；然而，它会让招聘人员或招聘经理感到困惑，因为缺乏清晰性，并让读者不清楚具体做了什么。一个写得不清楚的成就可能会让你的简历被放入拒绝堆，尤其是在申请竞争激烈的职位时。改进后的写法如下：

在 AWS 中为应用程序 x 实现了地理冗余和自动故障切换，导致应用程序的可用性从 98.7%提高到 99.9%。

上述示例清晰地阐明了所取得的成就，并提供了具体细节。此类细节能将你的简历从拒绝堆中移到面试堆中。

对于新晋 DevOps 工程师来说，一个常见的挑战是缺乏经验。别担心，你只需要记录那些为你担任 DevOps 工程师角色做好准备的经历。如果你当前的职位是软件工程师，确保专注于与你 DevOps 职位相关的成就，强调相关的工具和原则。以下这样的经历描述会比较合适：

软件工程师 | XYZ 公司 | 2020 年 5 月 - 至今

将端到端测试框架 Test Café集成到 Jenkins CI 流水线中，从而减少团队在本地测试所花费的时间，减少了 30%。

使用 AWS 服务开发 API，目前每月处理超过 20,000 个请求。

将我的 Test Café方法贡献给 Jenkins 全球流水线库内源项目，以便其他团队可以利用它。

我的建议是：简历中的经历不必是付费工作。如果你是一个开源项目的主要贡献者，可以将其包含在经历部分，尤其是在职业生涯的早期。这样会引起注意，并帮助你获得面试机会。一个常见的误解是，未付费的经历和志愿工作只应在面试时提到。

接下来，我们将介绍技能与认证部分。

技能与认证

你的技能和认证应该与 LinkedIn 资料上的内容一致；你空间有限，所以要选择最相关的技能和认证来列出。在图 4.4中，使用条形图表示了我的能力。有一件事常常引起疑问，那就是当你的简历上列出一些顶级技能，但这些技能与经验故事不匹配时。比如，如果你在简历中列出 AWS 是你的顶级技能，但你之前的工作成就并没有体现这一点，这对招聘人员和招聘经理来说是一个红旗。如果你在 AWS 方面的经验来自你做的一个大型副项目，那么你需要在简历中列出该项目。

教育背景

在研究这个话题时，我真的开始感到自己变老了。四年制学位曾经是进入软件工程/IT 相关职位的要求。随着职业生涯的发展，学位的重要性逐渐降低，直到它成为一个不再被提及的话题，除非你打算转向需要硕士学位的领导岗位。现在，对于很多人来说，刚开始时学位就不是话题，因为他们是自学成才，或者参加过编程训练营并通过实习获得了实际经验。这是朝着正确方向迈出的步伐。作为一名招聘经理，我更关心的是你是否具备持续学习的心态，而不是你是否拥有四年制学位。

你所拥有的任何教育背景都应该列在你的简历中；某些职位有最低教育要求，如果在简历中找不到相关学历，你将自动被淘汰。在第五章《建立你的网络》中，我们将讨论如何通过与正确的人建立网络，绕过这一要求。

到目前为止，我们已经覆盖了简历中需要的各个部分。以下是一个示例，形象展示了各个部分：

![图 4.4 – 简历示例]

](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/dop-crr-hb/img/Figure_4.4_B18117.jpg)

图 4.4 – 简历示例

以下是两个可以帮助你创建漂亮单页简历的网站：

• Novorésumé: novoresume.com/

)

• Resume.io: resume.io/

)

在下一节中，我们将讨论个人网页的重要性以及如何创建一个。

更新或创建你的个人网页

你的个人网页应该是简历和 LinkedIn 资料的延伸，一个可以展示你热衷的话题和你感兴趣项目的地方。这个网页应该能够让你讨论并分享个人兴趣和爱好，以便在潜在雇主面前展现出更具人情味的一面。如果你已经有了个人网页，你可以跳过接下来关于如何使用 GitLab Pages 创建网页的部分。

GitLab Pages 教程

创建一个静态网页已经变得非常简单，既不需要花费金钱，也不需要耗费太多时间。GitHub 和 GitLab 都提供免费的静态网站托管。在这一部分，我们将介绍如何使用 GitLab Pages 创建网站。

前提条件：你需要在 GitLab 注册一个免费账户。

1. 我们要做的第一件事是安装hexo，一个基于 Node 的网页框架：

   npm install -g hexo
   

2. 接下来，登录 GitLab（gitlab.com/）并导航至gitlab.com/natejswenson/dcr-demo。将dcr-demo fork 到你的工作区。

克隆你从 GitLab fork 的仓库到本地机器，cd（更改目录）到项目文件夹，并运行以下命令：

npm install 
hexo server

1. 打开浏览器，导航至localhost:4000查看当前网站。

2. 对网站进行个性化修改，做到属于你自己的风格，然后将其推送回 GitLab：

   git stage . 
   git commit -m "my commit"
   git push
   

返回 GitLab，找到你刚刚推送的项目，点击设置 | 页面，查看你网站发布的 URL。

如果你跟着步骤走，你已经在本地机器上安装了所需的模块，使用 Hexo 框架进行开发，将仓库 fork 到你的个人空间，将仓库克隆到本地机器，进行修改，并将修改推送回 GitLab，你的网站已经发布。做得好。在本节的下一部分，你将获得在个人网页上应该包含的最基本信息。

个人网页上应该包含的部分

开发一直很容易；而创作内容则是一个挑战。以下是我认为在个人网页上有效的部分。

联系方式

联系部分应该包括你的电子邮件、LinkedIn、GitLab、GitHub，以及你希望访问你网站的个人能够了解的任何其他专业资料。

介绍

向潜在雇主介绍你自己，既从职业角度，也从个人角度。这是你展示工作中的自己和工作之外的自己的机会，同时表达你对 DevOps 领域的热情。

博客

这一部分是可选的；如果你喜欢写作，可以包括这一部分，因为你的写作对潜在雇主可能会有兴趣。如果你不是写作者，不要为了在网页上放上博客就开始写作。我曾做过这件事，对我和我的读者来说都不愉快；我并不热衷于我写的内容，因此那不是我最好的作品。在这种情况下，我的时间更应该花在开发一些 Alexa 技能上，并将其添加到我的网站上。

项目

这是另一个机会，让潜在雇主了解你的兴趣，以及你在工作之外花时间做的事情。以下是一些示例：

• GitHub 项目

• GitLab 项目

• 智能设备技能

• 自定义家庭自动化

• 学校项目（特别是毕业设计）

• 演讲活动

• 你所做的演讲

简历

你的简历应该以可视化的形式展示或从你的网站上以 PDF 格式下载。这能减少你和感兴趣的方之间的来回沟通。

总结来说，你的个人网站是你 LinkedIn 资料的延伸，但它允许你加入个人品牌。

利用 Twitter 和其他社交资料

无论你是技术社交影响者，还是希望在大学期间获得实习机会的学生，拥有跨多个平台的社交存在都是有益的。在前面的章节中，我们介绍了如何设置 LinkedIn 页面，以吸引招聘者的注意，以及如何开始你自己的网页。在本节中，我们将进一步讨论如何通过在 Twitter 上发布或在 Medium 上撰写文章来补充你的 LinkedIn 和个人网页。

图 4.5 – 社交资料

我们将从讨论 Twitter 入手，以及如何利用它来作为一名 DevOps 工程师找到工作。

Twitter

技术专业人士在 Twitter 上的使用可以分为两类：获取信息和分享信息。

用于获取信息的 Twitter

如果你想保持在技术最前沿的动态，Twitter 是一个绝佳的选择。你可以关注 Gene Kim 或 Martin Fowler 等个人，如下图所示：

图 4.6 – Gene Kim 和 Martin Fowler 在 Twitter 上

在 Twitter 上，你也可以关注新闻机构和公司，比如 Stack Overflow 或 ZDNet，如下图所示：

图 4.7 – Stack Overflow 和 ZDNet 在 Twitter 上

Twitter 的另一个用途是与你的粉丝分享信息。

用于分享信息的 Twitter

如果你是 Twitter 的粉丝并喜欢使用它，你可能想尝试增加你的粉丝。一个有效的方法是分享原创内容或转发他人发布的内容。

如果你在 Twitter 上成为一个受欢迎且广受关注的账户，你更有可能被招聘者和雇主注意到。

Twitter 的发文长度限制为不超过 280 个字符。如果你需要一个能容纳更多信息的平台，你可能会考虑使用 Medium。

Medium

根据 medium.com/，Medium 是一个开放平台，读者可以找到动态思维，专家和未被发现的声音可以在任何主题上分享他们的文章。Medium 是一个开始作为作家职业生涯的好地方，因为任何人都可以为其写作。

在 Medium 上找到成功的关键是增加你文章的浏览量。这可以通过在其他社交网站上交叉发布你的 Medium 文章来实现，比如 LinkedIn 和 Twitter。

图 4.8 – 使用 Medium 和其他社交网站

在前面的图示中，你刚刚在 Medium 上写了一篇文章并发布，但一直未能吸引到足够的人点击并阅读你的文章。于是，你决定将 Medium 文章分享到你的 LinkedIn 和 Twitter 个人资料上。这一举措为你的 Medium 文章带来了额外的点击量。你还开始收到招聘人员和其他人的消息，祝贺你写的文章。

还有许多其他社交媒体网站，可以进一步帮助你扩大在线影响力，这将增加你与可能帮助你找到工作的人的联系机会。

总结

本章中，我们涵盖了确保你向潜在雇主展示最佳自我的所有必要改动。我们讨论了拥有完整且专业书写的 LinkedIn 个人资料的重要性，并提供了提高被潜在雇主注意到的建议。接下来，我们讲解了如何更新简历，以便使重要信息能快速被自动化系统和人类看到。然后，我们讨论了拥有个人网页的重要性，介绍了如何在 GitLab 上创建 Hexo 网页的教程，并详细讲解了个人网页应包含的各个部分。最后，我们探讨了其他社交网站，这些虽然不是必须的，但可以增加被招聘人员注意到的机会。

在下一章中，我们将讨论人脉建设的重要性，以及如何在 LinkedIn 和会议中进行有效的人脉拓展。

第五章：建立你的网络

我的当前工作非常棒。我喜欢我所做的工作，每天都在学习，而且有一个很棒的经理；这真是一个三重威胁的职位。你可能会认为我必须非常努力地工作才能获得这份工作。从某种程度上来说，我确实做到了，但不是你可能想象的那种方式。我并没有为面试做大量准备，因为大多数面试是在我甚至不知道自己正在被面试的情况下发生的。这是因为我和招聘经理在 LinkedIn 上建立了关系。几个月来，我们一直在讨论他所在组织中的不同工作机会，同时他也在了解我的技能和职业目标。

本章将讨论如何建立关系，以帮助你的职业朝着正确的方向发展。那句名言 “不是你知道什么，而是你认识谁” 部分是对的。如果我要重新表述这句话，以使它完全正确，我会说 “被对的人注意到你的技能是成功的关键”。本章将涵盖以下主题：

• 正确使用 LinkedIn

• 建立持久的联系，无论在线还是离线

• 质量重于数量

• 社交网络 – 交谈开场白

我们将首先讨论如何使用 LinkedIn 引起招聘人员和 DevOps 工程师招聘人员的注意，然后讨论如何在 LinkedIn 上以及在聚会和其他社交活动中与那些注意到你的人建立持久的关系。之后，我将解释为什么拥有少数可以建立关系的联系，比拥有大量联系要更好。最后，我将通过给内向的读者（像我一样）提供一些交谈开场白来结束本节。

正确使用 LinkedIn

LinkedIn 起初是一个专业社交网络平台；现在它已经发展成了领先的求职网站之一。以下图表展示了一些关于 LinkedIn 的关键统计数据，足以让你感到兴奋：

图 5.1 – LinkedIn 信息图（2021 年）

这些是一些巨大的数字。本节将指导你如何正确利用它们。在 LinkedIn 上建立良好声誉的第一步就是引起注意。

引起注意

在 LinkedIn 上获得关注似乎几乎不可能，尤其是随着用户数量接近 10 亿。最简单的一种方式是将你的安全设置更改为开放网络者。在你开放了个人资料后，接下来就是开始关注并与其他 DevOps 专业人士互动。如果你缺乏 DevOps 相关的联系，一种轻松的方式确保你开始看到关于 #DevOps、#AWS、#DevOpsJobs、#CI 或其他任何话题的帖子，就是关注特定的标签。这不仅会显示你的一度联系人的帖子，还会显示二度和三度联系人的帖子。我们将在接下来的部分中使用以下图表：

图 5.2 – LinkedIn 连接

假设你有两个朋友，A 和 B；这两位是你的第一度连接，或者说是你直接连接的人。在我们的例子中，每个第一度连接有两个连接，而每个二度连接也有两个连接。

这相当于你在扩展网络中的 14 个连接。随着连接数量的增加，这些数字呈指数级增长；假设你有 50 个一度连接，而每个一度连接又有 50 个连接，每个二度连接有 50 个连接，那么从一度到三度的总连接数将达到惊人的 1,277,550。

获得多个连接认可的一种方式是发布关于你正在学习的内容。连接们开始评论并点赞它，最终会被一位招聘人员看到，而这位招聘人员正在寻找具有 Kubernetes 经验的 DevOps 工程师，如下图所示：

](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/dop-crr-hb/img/Figure_5.03.jpg)

图 5.3 – 一条 LinkedIn 帖子引发第三度私信

这听起来可能不太可能，但它一次又一次地发生在我身上。招聘人员通过私信联系你后，你可以将他们添加为连接。此时，你可以提起第四章中讲到的前一个课程，重新打造自己，确保你的 LinkedIn 个人资料是整洁的；你不希望招聘人员看到你不完整或杂乱的资料。

在 LinkedIn 上获得认可的另一种有效方式是评论和/或点赞他人的帖子。在以下示例中，B1，一位二度连接，发布了关于在你所在地区举办聚会的帖子。你的一个连接已经点赞了该帖子。该帖子出现在你的动态中，因此你也点赞了它，并发表评论。在这个时刻，跟进发送一条个性化的连接邀请，表达你对这个聚会的兴趣：

](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/dop-crr-hb/img/Figure_5.04.jpg)

图 5.4 – 将二度连接添加到你的网络

总结这一部分，获得 LinkedIn 上关注的最佳方式是与连接互动，即使他们与你并没有直接连接。在接下来的部分，我们将讨论如何建立持久的连接。

建立持久的连接，线上和线下

你可能会幸运地在与某人一次互动后就获得一份工作。这种情况没有发生在我身上；在关系的回报上，它总是一个长期的过程。曾有一次，一位招聘人员联系我询问一个工作机会。当时，我并没有考虑换工作。我们在 LinkedIn 上保持联系，每年见面吃几次午餐。三年后，一位朋友和前同事因为部门重组失去了工作。我把他的简历发给了那位招聘人员；两周内，他开始了一份薪资不错的合同工作，这份工作能让他在寻找更长期职位的过程中维持生计。

在本节中，我们将讨论如何在虚拟环境和面对面环境中建立持久的联系。我们将从如何在网上或虚拟环境中建立联系开始讨论。

在虚拟环境中建立联系

在 DevOps 圈子里，远程工作和虚拟关系建设早在 Covid-19 颠覆我们世界之前就已经开始了。像GitLab、Atlassian和PagerDuty这样的公司都很支持远程工作，团队成员之间有着极好的关系。我已经远程工作了 5 年，且相信那些用于确保团队成员之间建立牢固纽带的做法，也可以应用于任何类型的职业关系。

以下是通过个人化、帮助性和一致性建立关系的场景视觉设置：

](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/dop-crr-hb/img/Figure_5.05.jpg)

图 5.5 – 在 LinkedIn 中设定场景

在个人环境中建立联系

有一条界限是你绝不能跨越的，但人们喜欢听你谈论你的宠物和工作之外的活动。举个例子。假设 Josh 发布了自己完成马拉松的帖子。Rachelle 点赞了它，结果它出现在了你的动态中。你也喜欢跑步，于是你决定给 Josh 私信：“恭喜你完成马拉松，真了不起！我也是跑步的忠实粉丝。”给 Josh 发消息让你们在个人层面上建立了联系，而不是工作上的联系，这有助于建立更强的关系。

帮助你的连接

帮助你的连接是我名单上最重要的建议。在你给 Josh 发了私信后，他查看了你的个人资料，注意到你们都是做 DevOps 的，所以他把你加进了他的网络。他后来发布了一条关于他在进行一个侧面家庭自动化项目时遇到的Raspberry Pi问题的帖子。你恰好有类似的设置，于是决定分享你在设置中使用的 GitHub 链接。几周后，你发布了一条关于你在使用 AWS 时遇到的问题，并向你的网络求助。Josh 看到了你的帖子并评论了它，还通过私信给你提供了一些他以前使用过的解决方案。他的建议效果很好；你问他是否愿意参加视频通话，详细解释一些问题。

持续地与连接保持互动

到现在为止，你和 Josh 已经建立了不错的关系。为了保持这种关系，你需要与他保持互动。设定一个周期，定期互相联系，看看彼此的进展。

在本节结束时，我将推荐几个虚拟聚会，帮助你发现与自己兴趣相同的专业人士；首先是All Day DevOps（ADO）www.alldaydevops.com/。如果你搜索线上 DevOps 会议或虚拟 DevOps 聚会，你会惊讶于它们的数量。我鼓励你参加几个，找出哪些对你最有帮助。

在现实生活中

Covid-19 将一个新词引入了职场，在现实生活中（IRL），这是一个巧妙的术语，用来描述与同事、潜在同事面对面见面的情况。无论你是内向型还是外向型，处理现实生活中的职场关系都是复杂的，这也是我们将在本节讨论的内容。现实生活活动的最大好处是能够与那些你想建立更好联系的人进行一对一的交流。

接下来，我们将讨论一些在虚拟关系中很重要，但在处理现实生活中的情况时更为显著的属性。

真实地展现你自己

我从导师那里得到的最好建议，想要分享给我的读者的是保持真实。我的导师指的是我与他人互动的方式。有些人喜欢更亲密的一对一交谈，而另一些人则在大型群体对话中更为舒适。把自己置身于可以展现真实自我的情境中。

如果你试图强迫自己进入一个必须表现得不自然或不舒服的情境，谈话将不会顺利进行。你试图建立关系的人会意识到你不是在做真实的自己，并且会对继续与你交往持谨慎态度。

积极地与网络互动

如果你在长时间专注于某个特定话题的学习，可以自愿参加即将举行的活动。这将带来多重好处。首先，它可以确保每个参加活动的人都知道你是谁，这对于正在寻求职业变化的人来说非常有帮助。它还可以让你在 LinkedIn 简介中添加讲师身份，这也是一个非常好的方式让自己被注意到。最后，如果你处于职业生涯的早期阶段，这是一个很好的机会来练习演讲，这是对你未来职业生涯有用的技能。

另一种参与的方式是，在讲座后直接与讲者进行互动讨论。不要与之争论。那样不会建立关系；但可以提问并表现出兴趣。这将让你引起注意。

对自己设定高标准的职业要求

这个是常识，但令人惊讶的是，很多人都忘记了这个简单的规则。活动后总会有一个欢乐时光。很容易忘记你参加活动是为了帮助自己发展职业，而是觉得自己是在和朋友们玩乐。记住两条简单规则：保持对话的专业性，避免过度饮酒。第一次印象不好是很难挽回的。

总结来说，要在面对面的活动中取得成功，带着真实的自我参加活动，无论你是观众还是讲者，都要全身心投入，最后保持专业。

重要的是在本节结束时列出六个个人属性，这些属性将帮助你在建立关系时更成功，这些属性在以下图形中得到了可视化展示：

图 5.6 – 建立关系所需的属性

重申前面图形中展示的内容，你必须努力做到：乐于助人、一致性、参与感、真实性、专业性和个人化。

在下一节中，我们将讨论连接的质量重于连接的数量。

质量重于数量

两个人在 LinkedIn 上同时发布关于同一话题的帖子。连接 A 有 1 万个连接，而连接 B 有 800 个连接。一天后，连接 A 的帖子只有两个点赞，没有评论，而 B 的帖子却有 14 个点赞和 22 条评论。

图 5.7 – 注重质量

当我第一次遇到这样的情况时，我感到很困惑；是连接 A 做错了什么，还是连接 B 做错了？让我来分解一下。

连接 A 专注于扩大他们的网络，几乎不关心自己网络中添加了谁。连接的数量是一个虚荣指标；乍一看，它看起来很不错，但如果你深入看，它是没有意义的。

一个更有用的衡量标准是你的连接与你互动的频率。按照这个标准，连接 B 显然做对了什么，但到底是什么呢？

好吧，如果你一直在阅读这一章，连接 B 已经做到了我们谈论的所有事情。他们有意识地努力保持与他人的联系，帮助别人，并与他人建立个人关系。最重要的是，连接 B 始终保持真实的自我，无论是在网上还是在现实生活中。以下是你可以问自己的问题，以判断是否应该将某个连接添加到你的个人资料中。如果你对一个或多个问题的回答是肯定的，那就添加他们；如果不是，就不要添加。这个问题确保每个连接都是你认识的人、你感兴趣的人，或者能够帮助你的人：

• 我认识这个人吗？

• 我是否被这个人的业务、职业道路或专业前景吸引？

• 我是否有这个人能够填补的直接需求？

本节的要点是本章中描述的行为的汇总：与其拥有许多仅仅是数字的联系，不如与少数拥有稳固关系的人建立联系。简单来说，就是质量优先于数量。在本章的最后一节，我们将讨论你可以在社交活动中使用的对话开场白。

社交和对话开场白

会有一些读这本书的人，像我一样，在社交场合上并不擅长寒暄。也会有一些人，宁愿跳过寒暄，直接进入更深刻、更有意义的讨论。在这一部分，你将学到一些有用的技巧，来帮助主持社交活动，如何启动对话以及当你卡壳或觉得该换个话题时的应对策略。我们先从一种可以用来主持没有议程会议的技巧——Lean Coffee开始。

Lean Coffee

Lean Coffee 是一种组织会议/活动的方式，允许参与者投票选择他们想讨论的话题。我在我主持的读书俱乐部讨论中也使用过这种方法，它能使议程过于紧张的会议更加高效。

以下是一个图示，展示了主持 Lean Coffee 会议所需的基本物品。它也是我最自豪的作品之一，因为我并不是一位艺术家：

图 5.8 – Lean Coffee 必需品

举办 Lean Coffee 活动的最低要求包括便利贴、马克笔、智能手机或其他计时设备、桌子、椅子，最重要的是，参与者。接下来，我们将讨论如何主持 Lean Coffee。我们将从一个视觉示意图开始，接着详细描述每个阶段：

图 5.9 – Lean Coffee “如何做”的视觉展示

现在，让我们谈谈如何主持 Lean Coffee。

选择一个主题

主题可以是任何内容，比如 DevOps、安全性，或 DevOps 中的敏捷。它们都是适合 Lean Coffee 的好主题。其目的是鼓励参与者围绕共同的主题添加讨论内容。

添加话题

参与者将他们希望讨论的与主题相关的话题写在便利贴上，用尽可能简短的词汇描述。若主题是 DevOps，话题可以包括 CICD 工具、DevOps 文化和 Docker。

点票

参与者可以在他们想讨论的话题上投票。我发现，用马克笔在便利贴上画点比较有效。如果你想更正式一些，可以用白板。

请鼓掌。

话题按照从最多投票到最少投票的顺序进行排序。投票最多的话题首先讨论。

讨论

设置计时器，定一个时间 – 通常 3 到 7 分钟足够，开始讨论第一个话题。

竖起大拇指/竖下大拇指

遵循 Lean Coffee 的民主性质，当某个话题的时间结束时，如果大多数人希望继续讨论，可以延长时间；否则，就进入下一个话题。

你可以发挥创造力，将相同的概念应用到虚拟会议中，使用分组讨论室和白板功能。在会议结束时，是否决定将笔记发布到 Lean Coffee 讨论中，由你和你的团队决定。过去，我曾使用 GitHub 页面来跟踪 Lean Coffee 的结果以及即将到来的日期。

接下来，我想讨论闪电演讲，这种形式在虚拟活动和线下活动中都非常有效。

闪电演讲

闪电演讲是简短的演讲，通常时长为 3 到 5 分钟，多个演讲会接连进行。我非常喜欢听闪电演讲，特别是在有其他人的场合。闪电演讲将高度技术化的话题介绍给观众，激发他们的兴趣，令他们渴望更多，从而带来精彩的演讲后讨论，观众和演讲者之间展开深入的交流。

每一次我参加的闪电演讲都会引发一些我之前不知道自己感兴趣的讨论，和一些我原本不会遇到的人进行交流。你可以在你的 DevOps 或工程小组内部启动一个定期的闪电演讲系列。当我在Optum工作时，我们在 DevOps 社区的办公时间电话会议开始时就加入了闪电演讲环节。它让参与者在电话会议一开始就投入进来，也促成了精彩的讨论。

对话的开场白

你没有建立优质的联系，因为你在社交活动中没有与人交谈，而你之所以在社交活动中没有与人交谈，是因为你不知道该聊什么。我们每个人都经历过，或者至少我经历过比我愿意承认的更多次。在之前的小节中，我们讨论了旨在激发对话的闪电演讲和 Lean Coffee 活动。不幸的是，大多数社交活动只是简单的茶点和人群聚集在一起。以下是一些帮助我在有效建立社交网络方面逐渐成熟的经验：

](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/dop-crr-hb/img/Figure_5.10.jpg)

图 5.10 – 改善你对话的方式

我们首先讨论准备的重要性。

准备好

如果你要去参加 Docker 聚会，我会先疯狂观看几部关于 Docker 的视频，并阅读一些近期的文章，确保你能够与参加活动的人进行有效的对话。

变得更加个人化

提出能够帮助你获得更多信息以继续对话的问题。例如，一个不太好的开场问题是，嗨，你怎么样？ 这个问题无法为你设定下一个问题的方向，并且很容易导致对话变得短暂。一个更好的对话会是，嗨，我看到你在名牌上写着你在亚马逊工作。你在那里做什么工作，为什么对容器感兴趣呢？ 这是一个很好的问题。首先，它不能用一个单词来回答；其次，你从中得到的回答将帮助你设定下一个问题；最后，这个问题让人觉得你对了解他们非常感兴趣。假设这个人是一个专注于 AWS ECS（弹性容器存储）的团队经理，并且对 Docker 感兴趣，以确保他们能够紧跟容器领域的最新动态。然后，这个人将问题反问你，这就引出了下一个话题。

明确表达你的意图

如果你参加这个活动只是为了建立人脉或与可能帮助你找到工作的个人建立联系，那就直言不讳地说出来。坦率和直白是许多人钦佩的特质，然而很少有人具备。这里的重点是要诚实。

知道何时以及如何结束对话

如果对话进行得很顺利，比如在你陈述了自己的意图之后，这个人似乎对了解你更多感兴趣，那么你应该根据对方的需要与他们花费时间交流。不要为了转到下一个人而退出对话。你已经打下了基础，现在是时候在这个基础上继续深入。相反，如果这个人对目前没有招聘需求，并不打算为了招聘某人而进行交流，那么你应该感谢对方的时间，告别时告诉他们保持通过 LinkedIn 联系。之后，务必跟进并通过 LinkedIn 加对方为好友，附上一条感谢他们对话的留言；你永远不知道他们什么时候会需要一个候选人。

摘要

在本章中，我们讨论了几种虚拟和现实生活中建立人脉的方式。我们首先讨论了在 LinkedIn 上建立关系的最佳策略。包括了如何增加你被他人注意到的可能性。在本节中，你还学习了如何利用你的第二度和第三度人脉来建立关系。我们讨论了六个可以提高成功对话可能性的特质，这些特质适用于虚拟和现实生活中的对话。它们包括：乐于助人、真诚、个人化、一致性、积极参与和专业性。我们发现，与那些你有互动的连接相比，拥有大量没有个人关系的连接更为不值一提。接下来，我们讨论了可以帮助促进更好对话的活动，例如闪电演讲和精益咖啡。最后，我们介绍了四种方法，这些方法可以大幅提高你在社交活动中进行有意义对话和建立关系的能力。这些方法包括：做好准备、表现出关心、明确表达你的意图，以及知道何时结束对话。

在下一章，我们将讨论导师关系：为什么它很重要，以及如何找到一位导师。

第六章：导师关系

在DevOps领域，拥有一位导师将使你更快地到达职业目标；它让你能够获得来自曾经走过你这条路的人的知识。在本章中，你将获得找到导师的动力，以及根据个人偏好寻找导师的资源。

在本章中，将涵盖以下主题：

• 导师的重要性

• 导师与学员的关系动态

• 选择合适的导师

• 导师作为参考

导师的重要性

在这一部分中，我们将讨论导师关系能带来的好处。本节将分为四个部分：帮助设定可实现的目标、职业指导、动力和职业建议，如下图所示：

图 6.1 – 导师关系的好处

我们将首先讨论导师如何帮助你设定、规划并达成你的目标。

帮助设定可实现的目标

导师将提供如何实现目标的指导。导师将帮助你确保你的目标是可实现的，并通过设定里程碑来实现。以下是一个真实的故事，讲述了我的导师如何引导我走上一条与我的目标无关的道路，但最终这条道路正是我成功所需要的。

真实经历：从 DevOps 工程师到技术敏捷教练

自从在联合健康集团开始从事 DevOps 职业以来，领导一个 DevOps 团队一直是我的目标。我的导师帮助我揭示了如果我的目标要变为现实，需要解决的短板。向他人展示和表达想法一直是我的一大难题；此外，我也非常胆怯，且不擅长表达意见，直到和导师进行了坦诚的目标设定讨论，我才意识到这些都是我的不足之处。

克服我短板的解决方案是从幕后技术人员转变为教练角色。技术教练的角色是帮助敏捷团队学习并适应 CICD（持续集成与持续交付）最佳实践；换句话说，需要大量的演示和发表我的意见。

我的转型过程的第一部分包括沉浸在敏捷的世界中，并与我的导师进行一对一的辅导会议。我协助的第一个团队没有使用 CI 服务器，代码没有迁移到 GitHub，也没有自动化测试或回归测试。这些都是我熟悉的事情；然而，我的角色并不是做这些工作，而是指导和引导团队走向正确的方向。那段时间非常糟糕；然而，在第一个冲刺的过程中，我开始变得越来越舒适，无论是对自己还是对团队。慢慢地，这变得相当有趣，我的导师和主管也告诉我，我做得相当不错。

我作为技术导师的历程持续了两年，之后才转型为 DevOps 卓越中心 (COE)的负责人。直到后来，我才实现了成为 DevOps 团队的人员经理的目标。如果没有导师的指导，我可能无法培养出领导团队所需的技能，也不会发现我对辅导和培训的热情，而这最终成为了我决定进一步追求的方向。

通常，导师会提供一些你自己不太可能意识到的见解。在做出任何可能改变职业生涯的目标或决定之前，我建议你与导师进行讨论，听取他们的意见。如果你还没有找到导师，继续阅读本章，了解如何找到导师。接下来，我们将讨论辅导和培训的重要性，这是导师提供的另一项有用技能。

激励你帮助自己实现目标

设定目标后，由于所需的努力，朝着目标努力可能会迅速变得不那么吸引人。在这种情况下，导师会介入并重申为什么这个目标值得付出努力。只有在你和导师之间建立了允许开放沟通的关系时，这才有可能发生，也就是说，建立了一种你能舒适地讨论疑问的关系。

你的导师是你为实现目标而努力的啦啦队员。为了确保你走在正确的道路上，定期安排辅导会议，讨论你的进展，并致力于解锁和提升你的技能。

职业辅导

培训是导师将知识转移给学员的过程，而辅导则是导师用来增强学员某一特定技能的方式。在与你的导师进行辅导时，你有责任将对话和讨论引导到你希望的方向。这意味着要对导师保持开放态度；如果你在某个特定概念或方法上遇到困难，要让导师知道。

在接受指导时，有一些事项需要牢记，以避免生气或感到沮丧：

• 辅导与培训不同；导师不会向你解释具体的概念或方法。相反，他们会推动你朝着他们认为有助于你更好理解某个概念的方向前进。

• 辅导会议是关于你，学员的。询问导师在特定情况下会怎么做，问题将会反过来问到你自己。记住，这关乎你如何变得更好，而不是导师知道什么或认为什么。

• 如果你从一次辅导会议中带走更多的问题而不是答案，那么这就是一次成功！带着你的问题，转化为你自己的答案。

在下一节中，我们将讨论当你需要一个值得信赖的人的意见时，导师如何为你提供帮助。

有用的建议

导师随时都能为你提供建议。无论是关于你正在进行的项目，还是关于职业发展的常规问题，导师都会在你职业生涯中为你提供帮助。导师的建议是在一个不太正式的环境中进行的培训。当你在做一个项目时，如果出现问题，导师可能是你第一个联系的人。

专业小贴士：导师的建议是持续的培训

每次与你导师的讨论，都会向你传授导师的一小部分知识。当你寻求具体的建议时，就像是打开了一门来自你最信任出版者的迷你培训课程。如果你有机会得到这种建议，一定要充分利用。

在这一部分中，我们讨论了拥有导师的重要性。要解锁所描述的潜在好处，你必须与导师建立基于信任和尊重的强大关系。你越早感到舒适向导师寻求建议，你就越能早日解锁导师-学员关系的潜力。

在接下来的部分中，我们将讨论导师与学员之间的关系动态以及该关系的不同阶段。

导师-学员关系动态

你可以选择你的导师；然而，你的导师也必须选择你作为他们的学员，这正是这段关系独特且强大的原因。导师和学员之间有一组核心技能是共享的，如下图所示：

图 6.2 – 导师技能模型

积极倾听、建立信任和设定目标；这三者都可以追溯到尊重。导师必须尊重学员，同样，学员也必须尊重导师。导师-学员关系有三个阶段。

在第一阶段，你开始向你仰慕的人寻求建议。此时，关系的具体形式尚未确定，你也正式没有导师。在这一阶段，你实际上是在测试某个你认为可能成为好导师的人。这一阶段的一个好比喻是约会；你会和一个你觉得可能适合自己的人约会，然后再询问对方是否愿意开始更为严肃的关系。

第二阶段是你定义关系（DTR）的时候。在第二阶段，你正式向某人请求成为你的导师，并且他们已同意你的请求。此时，你们很可能已经安排了 1 对 1 的会议和定期的沟通。

在这一阶段，你需要注意不要变得自满，因为这段关系尚在初期阶段，脆弱且易受影响。你希望导师-学员关系能够持续成长和成熟。以下是我个人职业生涯中的另一个例子，我曾犯过一个错误，让我的导师-学员关系在第二阶段停滞不前。

实际经历：什么不是导师关系

在我的职业生涯初期，我有几位导师，我曾正式请求他们成为我的导师。从这些导师那里，我得到了职业建议，并在我请求时得到了他们的指导。这些关系显得强迫且尴尬，导致很少有 1 对 1 的会议，也没有教练辅导会议。我曾以为这就是导师-学员关系应该有的样子。

前面的例子中的问题源于对导师-学员关系如何运作缺乏了解。导师-学员关系的目标更像是友谊，这就是第三阶段。

导师-学员关系的第三阶段是导师和学员之间建立深厚关系的阶段。正是在这一阶段，信任促进了有效的辅导和 1 对 1 的指导会议的发生。根据你与导师关系的深度，导师可能会开始视你为自己的得意门生。

以下图表是导师关系三个阶段的图形表示：

图 6.3 – 导师关系的阶段

在这一部分，我们讨论了导师-学员关系的三个阶段以及在每个阶段你应该期待什么。你了解到，只有在你们完全信任和尊重彼此时，你才能获得导师关系的全部好处。

在接下来的部分中，我们将讨论如何选择导师以及在做出决定时需要考虑的众多因素。

选择正确的导师

寻找导师是一项挑战，但选择正确的导师更具挑战性。一位成功的导师会理解你的目标，是你尊重和仰望的人，理解你当前的状况和能力，并看到你身上的潜力。我们将这一部分分为两部分：选择导师的标准和请求某人成为你的导师。

寻找导师时需要提出的问题

让我们直观地看看我发现的，作为寻找一个好导师的标准：

图 6.4 – 帮助你判断是否选择正确导师的问题

这个人是否能促进我短期和长期目标的实现？ 在我们接近找到这个问题的答案时，我们会提出另一个问题，集中在你的目标上，我的短期和长期目标是什么？ 如果你没有将这个记录在某个地方，别担心，我们现在就来讨论。

活动：写下你的目标

拿一张纸，将页面分成四个象限。然后，为每个象限标上 3 个月、6 个月、1 年和 5 年。

接下来，拿一些便签纸并开始写下你的目标。将便签纸放入四个象限中的一个。

完成这些之后，你可以在 Google 文档或任何其他类型的文件中创建最终版本。

如果你感到舒适，我建议你将这个信息与您的职业网络或网络的子集分享。我们稍后会回到这个话题。

现在你已经有了你的目标，看看你一年的目标和五年的目标。在开始寻找潜在候选人时，问问自己，这个人具备哪些技能和专长，能够帮助你培养实现目标所需的技能。

这个人了解我的当前目标和能力吗？ 这个问题是为了评估某人是否了解你的当前情况。如果你有一个曾经与你合作过、无论是虚拟还是面对面互动过的导师，那么他/她会更有效。并不是说你应该排除任何没有过互动的人。

专业小贴士

如果你与某个个体没有任何之前的互动，但仍决定他们是一个适合做你导师的人，你必须坦诚地告知彼此了解过程中的额外时间投入。这是建立富有成效的导师-学员关系所必须的。

如果你在 LinkedIn 上发布你的目标，关注你的人应该了解你的目标。在接下来的章节中，我们将介绍另一种向导师展示目标的方式。

这个人是我尊敬和仰慕的对象吗？ 这个问题包含了两个部分；如果你希望与导师建立强大的关系，这两个部分都至关重要。你应该把不符合这些标准的人从你的名单中剔除掉。与一个你不尊敬或者不仰慕的人，是不可能建立导师-学员关系的。

使用下面的维恩图来判断某人是否应该被视为潜在导师：

图 6.5 – 用于判断某人是否是潜在导师候选人的维恩图

在接下来的部分中，我们将讨论如何正式向已经确定是合适人选的个体提出成为你导师的请求。

向某人请求成为你的导师

如果你很幸运，向你的导师提问将是你们现有关系的自然发展。如果你与这个人密切合作，并且已经有定期的职业相关讨论，向他们请求成为你的导师应该是件容易的事。这个候选人就位于前面维恩图的中心，如图 7.5所示。

专业小贴士

内部赞助人和导师是有区别的。内部赞助人是你当前组织中的某个人，他将帮助你在内部职场晋升。与赞助人的互动通常会在你离开他们所在的组织后结束。而导师则是不会给你工作或帮你找工作的那个人；然而，他们将在你的职业生涯中长期扮演重要角色。

通常，拥有导师和赞助人两者都是有益的。赞助人会为你提供与当前雇主相关的建议和职业机会，而导师则会给你更全面的建议，这些建议不会偏向于某个特定雇主。两者的意见都很重要，尤其是当导师的建议与你赞助人提供的工作机会一致时！

大多数人可能不会那么幸运，你需要更加努力，走出自己的舒适区，才能找到一个优秀的导师。以下是一些你可能会遇到的情境：

情境 1：潜在的导师是你在上一家公司曾一起工作过的人，并且你们保持着 LinkedIn 上的联系。这个人位于维恩图的中心位置或A 区域。

在这种情况下，你可以给他们发一封电子邮件。这里是一个示例：

主题：指导关系

你好 [插入姓名],

在我们一起工作时，我在 [公司] 学到了很多，并且作为一名工程师得到了成长。我已经附上了我的职业目标，并且觉得在你作为我的导师的帮助下，我们可以进一步完善我的目标，并制定一个计划来帮助我实现它们。如果你愿意做我的导师，我很乐意安排一次初步的电话会议来讨论。

此致，

[你的名字]

情境 2：潜在的导师是你在一次会议上认识的，并且之后通过 LinkedIn 与之互动的个人。这个人位于维恩图的A 区域。

在这种情况下，你可以给他们发一条 LinkedIn 消息。以下是一个示例：

主题：指导关系

你好 [插入姓名],

自从在 [会议或活动] 上听你讲解 [主题] 后，我一直在 LinkedIn 上关注你，并且尊重你对 DevOps 的理解。现在，我的职业发展已经到了需要一位导师来帮助我实现目标的阶段。我相信在你的支持和指导下，我可以在职业上得到成长，并且实现我的目标。如果你愿意成为我的导师，我希望能找到时间与你讨论。初步看来，我们可能需要讨论时间的安排。

此致，

[你的名字]

情境 3：潜在的导师是你从未见过面，但一直在 LinkedIn 上关注的人。这个人位于维恩图的A 区域；由于你从未与此人见面或互动，得到积极回应的可能性不高。

在这种情况下，最好以更个人化的方式去了解对方。一个人更有可能接受与你有个人关系的人的导师邀请。

在这一部分，我们讨论了你需要提出的问题，以便找到一个合适的潜在导师。此外，你还了解了请求某人做导师的潜在方式。在接下来的部分中，我们将讨论何时适合请求导师成为你的推荐人。

其他与导师建立联系的方式

找到一位导师并不总是一件直截了当或容易的任务。你可能在你的组织内甚至你的人际网络中都很难找到一个导师。这比你想象的更常见，并且有一个完整的业务是围绕着连接个人与导师以帮助他们成功而建立的。如果你有兴趣在找到导师方面获得额外支持，请查看下面列出的网站：

MentorCruise

MentorCruise (mentorcruise.com/) 旨在连接技术专业人士：导师和学员。服务价格为每次 150-250 美元。提供的服务包括问答、面试准备和简历审阅。

GrowthMentor

GrowthMentor (www.growthmentor.com/) 每月基础订阅费用为 50 美元。你可以使用该网站根据你的需求查询导师数据库。

Pelion

Pelion (pelion.app/) 专注于软件工程专业人士，包括 DevOps。起价为 300 美元。

导师作为参考

你有一个导师，并开始申请新的角色，但是否适合将你的导师作为参考呢？答案不明确，正如本节中的大多数内容一样，应基于你的最佳判断。有几个问题可以帮助你做出决定。

以下是一张决策图，将帮助你简化决策过程：

图 6.6 – "我是否应该将导师作为参考?"的决策树

在本节的接下来的部分中，我们将涵盖每一个四个问题，从最基本的问题开始：你是否已经问过你的导师是否可以用他们作为参考？

你是否已经问过你的导师是否可以作为你的参考？

如果你没有询问过某人是否是你的导师或其他人，那么只有在你问过他们并且他们同意后，你才能将其用作参考。未经允许将某人用作参考是不专业的，可能会损害或破坏你与导师的关系。导师会对你坦诚和诚实。如果他们觉得你还没有准备好承担特定的角色，如果他们被要求为你推荐工作，他们将处于困境之中。如果你询问他们，这可能会导致一次很棒的讨论机会，让你从导师的见解中成长。虽然他们可能会拒绝的机会存在，但很大可能他们会乐意成为你的参考。

当一位导师同意担任你的导师后，你需要问第二个问题：你以前和你的导师合作过吗？

你是否与导师合作过？

如果你与你的导师合作过，他们将了解你的技能。此外，他们同意为特定角色担任参考的事实表明他们对你具备所需的信心！

专家建议

如果你请求你的导师为广泛的求职而不是某一具体职位提供推荐，你可以询问导师有关具体职位的情况。这样，他们会了解该职位的要求，并且可以开启一些关于如何更好地准备即将到来的面试的有益对话。

如果你没有与导师一起工作过，你必须再问自己一些问题，以判断是否应该使用他们作为推荐人。你需要问的第一个问题是，导师是否曾见过你运用过你的技能。

你的导师是否曾见过你运用过你的技能？他们是否对你所需的职位技能有信心？

看到你的技能和能力对于裁判给出准确的评价是很重要的，他们需要在推荐信中准确地描述你的技能、能力和个人品质。他们可能参加过你进行的配对编程练习，或者曾经在你参加的会议上听过你的演讲。如果推荐人没有亲眼见过你的技能，我个人建议不要使用他们作为推荐人；你应该根据自己的最佳判断做决定。如果不确定，可以和你的导师进行讨论。

接下来，你需要问自己一个问题：我的导师是否对我所需的职位技能有信心？如果你请求导师为某一具体职位提供推荐，并且他们同意了，那么可以认为他们对你在该职位上的能力有信心，可以将他们作为推荐人。另一方面，如果你请求导师作为一般性推荐人，而非针对某一特定职位，那么你就需要评估他们对你在该职位上的能力的信心。最佳的做法是与导师讨论该职位，并获取他们的反馈。

在这一部分，我们介绍了决定是否应将导师作为推荐人时需要问的关键问题。确定是否使用导师作为推荐人的最有效、最可靠的方法是讨论你申请的具体职位。

总结

本章介绍了关于导师制的几个话题，包括导师制的重要性、导师与学员之间的关系动态、如何找到导师以及如何将导师作为推荐人。在导师制的重要性一节中，我们讨论了设定可实现目标、职业指导、激励以及职业建议方面的帮助和指导。

在导师-学员关系动态一节中，你了解到导师-学员关系分为三个阶段。第一阶段是你还没有正式邀请某人做你的导师，第二阶段是你正式定义关系并开始进行 1:1 的正式会谈，在第三阶段，由于相互间的信任和尊重关系的增加，你们的关系得到了发展。正是在第三阶段，你们才能开始进行更加富有成效和成果的讨论。

接下来，我们讨论了如何找到并选择一个导师。在这一部分，我们讨论了三个问题，你应该问自己这些问题来判断某人是否能成为一个好导师。这三个问题包括这个人是否能促进我短期和长期目标的实现？、这个人是否了解我的当前目标和能力？以及这个人是否是我尊敬并仰慕的人？

最后，我们讨论了是否应该将导师作为推荐人；这一部分的关键要点是，你可以随时与导师进行讨论。然而，如果时间不允许，可以参考一个决策图表来帮助你做出选择。

在下一章，我们将讨论如何与招聘人员合作以提高获得一份令人惊叹的 DevOps 工作的机会。

第七章：与招聘人员合作

招聘过程的导航是一门艺术，直到你经历了几次之后，它才会变得不再神秘。理解这一点非常重要，尤其是当你准备参加第一次面试时。如果一开始所有信息都无法理解，不要灰心；有些信息在你亲身经历之前是不会明白的。本章将重点讨论与招聘人员的关系及如何在面试过程的不同阶段与各种类型的招聘人员进行互动。我们将在第八章《面试准备》中深入探讨面试过程的复杂性。

在没有招聘人员的帮助下，很难找到工作。在本章中，你将学习如何与招聘人员建立持久的关系，并利用这些关系找到工作。

本章将涵盖以下主题：

• 招聘人员的不同类型

• 如何找到招聘人员以及招聘人员如何找到你

• 如何展示自我

• 如何谈判

• 跟进，但什么时候跟进？

招聘人员的不同类型

招聘人员有几种类型。虽然我们不会提供全面的回顾，但我们会尝试涵盖在我们的职业生涯中遇到的最常见的情况。

以下图表概述了你在找工作时可能遇到的三种类型的招聘人员：

](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/dop-crr-hb/img/Figure_7.1.jpg)

图 7.1 – 招聘人员概述

首先，让我们深入探讨第一方招聘人员。

第一方招聘人员

这是直接为公司工作的招聘人员，试图填补职位空缺。他们可能通过社交网络联系你，最著名的是 LinkedIn，或者通过其他招聘网站。如果你直接在公司网站上申请职位，那么这个人可能就是你进行第一次电话沟通的对象。有些公司甚至将这分为不同的子角色，一个负责提供候选人线索，另一个负责实际筛选。不管你是否符合他们的要求，你都将进入面试环节并与团队接触。

他们通常是你谈论薪资要求、询问薪酬、奖金以及其他可能感兴趣的领域的人。反过来，他们会试图看看你与职位描述的匹配度如何。

虽然这不是一场技术面试，但不要太放松！有时候，招聘人员或人力资源人员不仅仅筛选技能，还会筛选文化契合度。这意味着他们可能会关注几个方面，包括你有多礼貌、你对公司了解多少，以及如果是视频面试的话，你的整洁度和个人形象。

确保您将这些通话视为面试的一部分，但不要害怕提问，并确保这是值得您花时间的角色。您不希望成为那些完成六轮面试过程后才意识到可以通过正确的问题预见到一些缺点的人之一。

招聘机构

招聘机构分为两种类型之一 - 独立公司或由最终客户保留的公司。独立公司可能会找到您的档案并将其提交给几个不同的工作岗位。如果一家公司被保留，它正在寻找与公司配置文件特别匹配的人才，但如果他们足够大，他们可能有多个可行的候选公司。

代理机构往往会根据您的薪水或收入的百分比（或固定金额）在一定期限内获得奖金。

一般来说，您挣得越多，他们做得越好，除非在角色（角色）上存在很多竞争的情况下，代理商试图互相削弱。试着判断这种情况是否存在，以便您知道如何适当地进行谈判。

自由职业者招聘人员

自由职业者招聘人员通常会通过 LinkedIn 或未经请求的电子邮件联系您。他们会传递他们的职位需求，并尽快与您通话。大多数情况下，他们不是最终客户，可能会将您推荐给一个代理机构或多个招聘人员，最终再与公司交谈。虽然他们可能了解您不知道的角色，但他们通常不在保留名单上，这些角色是自由可用的。是否比直接申请更好，还有待商榷，这取决于招聘人员是否已与招聘经理建立了关系。

根据我的经验，自由职业者招聘人员在合同工作中表现最佳，您可以指定您的费率，然后招聘人员可以确定他们是否能够按照该金额进行工作。

他们要求通过电子邮件发送的协议来代表您的权利，尽管有时这更正式地通过签署的 PDF 文件进行，希望确认您同意提交的费率或工资以书面形式提出。

招聘人员在面试过程中的角色

到目前为止，我们已经讨论了三种类型的招聘人员。在本节中，我们将探讨这三种类型的招聘人员可能参与面试过程中的各个阶段。如下表所示，这些阶段将在第八章，准备面试中详细描述：

图 7.2 - 招聘人员在面试过程中的角色

人才发现——也就是主动在社交平台上寻找合适的候选人——通常不是第一方招聘人员参与的事情；他们通常会在社交平台上发布空缺职位，等候候选人通过人才管理系统申请后才会联系他们。招聘公司被雇佣的原因在于他们能够主动去寻找人才；他们所找到的候选人中有相当大一部分来自社交平台或他们建立的过去关系。自由职业招聘人员的唯一收入来源就是找到人才并将这些人才推荐给公司。他们被认为是最优秀的猎头，因为他们有非凡的能力，在别人忽视的地方找到人才。之所以能够成为自由职业招聘人员，是因为他们在特定的招聘市场和雇主中积累了良好的声誉。

初步面试通常由第一方人力资源（HR）招聘人员负责。唯一的例外是公司已经委托某个机构处理这部分面试过程，或者是某些直接雇佣或合同职位。

第一轮面试通常是通过第一方招聘人员安排的，通常会与招聘经理进行。这个规则的例外是某些合同职位，经理与个人自由职业招聘人员或招聘公司有很好的关系，并信任他们来处理这一步骤。

技术面试可以由内部第一方流程或通过招聘机构进行。虽然自由职业招聘人员通常不会进行此步骤，但也有一些例外情况。在后续面试环节，通常会安排与你将来会合作的团队成员或公司其他部门的人员，且由第一方招聘人员协调安排。

如何找到招聘人员，以及他们如何找到你

从总体上来说，如果你保持活跃的社交形象，并且有一份更新的简历，招聘人员总会首先找到你。虽然有很多招聘网站，但一些招聘人员会购买整个候选人数据库，因此，一旦你在某个招聘网站上，哪怕你不再找工作，仍然可能收到邮件。

在 LinkedIn 上，吸引最优秀的招聘人员是一件简单的事。确保你的个人资料和简历大致相同，并且具有类似的总结和关键词。确保这些关键词与您的经验匹配，并且与搜索术语以及你感兴趣的职位中最常用的关键词相符。

你也可以直接联系招聘人员——无论是第一方还是第三方——询问他们发布的职位。虽然我不建议你的 LinkedIn 仅仅充斥着招聘人员，但我认为将你的三分之一联系人与求职或职业发展相关是正常的。这正是 LinkedIn 的主要用途。

小贴士

招聘人员也会进行搜索，当他们搜索Terraform时，确保你的个人资料和简历上有相关技能会有所帮助。不要添加你并不具备的技能，因为你可能会被要求或者甚至被测试这些技能。然而，还是建议扫描不同的职位招聘信息，看看哪些关键词出现频率高，并以此为指导，学习或进一步发展相关技能。

最后，确保你的个人资料是公开的，并且标明你愿意接受工作或愿意进行交流，这会告诉招聘人员可以联系你。与招聘人员建立良好的关系可以为你在职业生涯中带来多个机会。在 LinkedIn 上拥有一个出色的个人资料，可以让你保持丰富的联系人资源，并确保你不会错过任何有助于职业发展的机会！

如何展示自己

我简要讨论了展示自己的一些方面，以及如何让自己对招聘人员更具吸引力。让我再强调一下我认为最关键的内容。

展示自己的第一步是增强你的 LinkedIn 个人资料。我们在第五章《建立你的网络》中已经详细讨论过这一点，但我想说，拥有一个专业的页面，其中包括高质量的照片和内容是非常关键的。什么样的内容算是高质量的？其中一部分是写作，另一部分是内容本身。通常来说，我建议你的个人资料和简历应该保持一致或非常相关。我是根据我的 LinkedIn 个人资料来创建简历的，每当有更新时，我首先在个人资料上更新，然后再导出简历。

找人校对你的职位总结，并确保内容足够具有描述性，能够吸引招聘人员的注意，这对你很有帮助。在技术领域，你必须描述每个职位所用到的技术技能。不要泛泛而谈，而要具体明确。一个小技巧是，强调结果时，尽量加入数字和百分比。

在简历中突出最重要的（并且具有市场竞争力的）技能，对于读者和搜索引擎来说都至关重要，因为搜索引擎会寻找这些技能，从而返回最佳匹配结果。

一旦你觉得自己的个人资料在所有提到的领域都显得专业、描述性强且全面时，就该明确表示自己正在寻找新职位了。LinkedIn 提供了不同的工具来实现这一目标，包括定制徽章，表明你正在寻找工作。对于更加注重隐私的人，你可以设置仅招聘人员能够看到你对新机会持开放态度。这一信号会告诉招聘人员联系你。有了一个足够出色的个人资料，你应该会收到源源不断的消息和联系请求。我建议不要将每个招聘人员都加进你的网络，因为你希望保持与自己领域内的人以及能提升你领域知识或其他职业方面的人建立联系。你可以根据自己的需求来决定这些比例，但要知道，申请职位并不一定需要与招聘人员建立联系。如果有某个你曾愉快共事的人，或者有特别好的职位信息的人，那就值得与他们建立联系。

那么，当你开始收到消息时，接下来该怎么办？许多介绍信息会提供职位描述的简短版本。有些会包含你所需的所有信息来判断自己是否感兴趣，而其他的则只会包含希望联系或者进行简短电话交流的意图。我的建议是在接听电话之前，先做一些简单的探询，并明确你的要求。否则，你会花费很多时间与别人分享自己的信息，最后却发现这个职位并不适合你。

我至少会要求获取职位描述和薪资范围（年薪或时薪）。有些人可能不会提供，但根据我的经验，大多数人会提供，尤其是当你明确表示不想浪费他们的时间时。我们将在如何谈判部分更详细地讨论这一点，但你需要传达自己正在寻找的和不想要的东西，只与那些与你需求更匹配的机会约定时间或进行通话。

你还可以做的另一件事是提高自己的社交意识并建立个人品牌。我们在第五章《建立你的网络》中详细讨论了这一点，获得并展示认证、撰写文章、在你的动态中转发其他文章，甚至撰写书籍（像这本书一样！）都能增加你的知名度和品牌，这样会让你对招聘人员和潜在雇主更具吸引力。

最后，我想说的是，你可以主动联系和与招聘人员及招聘经理进行信息交流。LinkedIn 提供了一个专业版本，允许你向网络外的人发送信息，并可以用来查询他们的数据库。到那时，它就有点像销售中的冷拨电话了。我更倾向于打造一个出色的个人资料，让招聘人员主动来联系我。

如何谈判

谈判的方式取决于你在求职的哪个阶段。当你与招聘人员打交道时，你主要是在确定你的薪资和期望的工资。你可能还想确定其他方面，比如奖金、股票限制性股票单位（RSUs）或期权，比如带薪休假（PTO），以及你是否希望远程工作或在办公室工作。越来越多的人（尤其是在科技行业）希望至少部分时间能够灵活远程工作，因为他们只要有电脑和网络连接就能完成工作。雇主的期望各不相同，因此重要的是与联系人确认他们的期望是什么。

那么，什么是 RSU 呢？根据 investopedia.com，RSU 指的是以公司股票形式发放给员工的一种薪酬形式。它们的特别之处在于有一个归属时间表，通常你会在一定时间后获得一部分权益——比如每年 25%。然而，RSU 也可以与绩效指标挂钩，而不仅仅是工作年限。

如果你不知道自己应该要求多少薪资怎么办？你可以询问一些职位的薪资范围，并以此为基准。并不是每个人都会提供这个信息，但有些会，这样你就能开始了。你可以提高你的薪资要求，直到遇到反对，或者你可以保持灵活，要求一个范围。一般来说，你要求的下限是用来确保这是一个你感到舒适的数字。如果得到更多，那就太好了，但一定要从一开始就要求你所需要的。

不起作用的事情

我曾犯的一些错误是把现金看得比职位头衔更重要，把现金或头衔看得比公司文化或契合度更重要，或者在薪资较低的情况下进入工作，并想着自己能逐步升职。当然，这种情况有可能发生，但我们应该关注更现实的情形。

专业提示

找出在类似职位上有相同经验的人赚多少钱，然后要求这个薪资。

虽然你的内心可能会阻止你要求比目前薪资高得多，但考虑一下你是否薪资偏低，或者你是否曾在一个地方市场工作，现在因为远程工作的机会而可以进入全球市场。如果你不问，就永远不会知道。他们能说的最糟糕的就是“不行”。

根据我的经验，希望不是一种策略。要么你尽早争取你想要的，虽然可能得不到完全符合的，但至少尽可能接近，要么你最好继续寻找。

我记得当我在寻找领导职位时，看到了一个看起来很有吸引力的 DevOps 主管职位。它是与一家知名公司合作的，所以这个职位具有一定的声望，而且从我与招聘人员的初步交流来看，薪酬似乎符合我预期的范围。我没有问足够的问题，而职位描述中有更多的细节，我本可以利用这些细节提问，确保这个职位适合我。

比如，我本可以问一下这个职位下属有多少人。我希望能领导多个团队，因为我有多年领导 5 到 10 人团队的经验，认为自己已经准备好承担更多责任。我注意到在许多大公司的高级职位中，管理经理是一个要求。我曾经领导过高级员工，但从未领导过经理，所以这是我在下一个职位中希望能够尝试的事情。

我没有提问，而在与招聘经理面谈时，他们提到这个职位主要是面向技术领导者，且只有两个直接下属。对于一个主管来说，这可不算是一个大团队！有些公司将主管视为某种职能角色（你领导一个小组，所以你是主管），而有些公司则把它当作一种职级（从高级经理晋升为主管！）。然而，有些公司则根据薪酬来划分角色，从功能上看，它可能与其他公司相同薪资的职位有很大不同。

让我失误的是其他的原因。经理在寻找一个在某一项技术上有深厚经验的人。我有一些经验，但这不是我的专长，而招聘经理明确表示这是他的优先考虑事项。我直言不讳（我通常这样做），说我的经验是与一个竞争产品相关，但我相信自己能够很快弥补这个差距。他提到他自己也经历过相同的过程，并且花了很长时间才赶上，所以他认为我也会花很长时间。这简直是胡说八道，但我并不打算改变他的想法。团队的缺失使这个职位变得不具吸引力，面试结束时我觉得自己浪费了大家的时间。首先要多读、多问问题！

图 7.3 – 谈判中不应做的事

接下来，我们将讨论一些在谈判中有效的方法。

有效的谈判方法

谈判时最重要的事情是做好调研。向其他招聘人员、朋友、同事，甚至社交媒体上的人请教。确定一个合理的基准，并尽早沟通。你不想浪费时间去考虑那些你根本不会接受的机会。

了解除了薪酬以外的其他奖励。它可能会影响你对工作的满意度，一些公司做事的方式可能不同。良好的企业文化是无法用金钱衡量的，因此在整个面试过程中，你要尽量感知这个工作是否适合你。问问自己，五年后你是否能看到自己仍然在那里。面试官是否是你愿意与之共事的人？你无法从和招聘人员的简短通话中推断出这些，但你当然可以向他们询问公司文化，并建立一些基本的标准。

我从个人经验中发现的一件事是，当你在同一家公司工作多年时，薪资调整的速度要慢得多。你可能会获得 2-5%的加薪，但换工作可能会让你获得 15-20%的涨幅。做一些市场调研可以让你根据当前的市场状况来确定薪资，而不仅仅是基于你的职业经历。

需要记住的一件事是，薪资过去通常会根据你所居住的地点进行调整。远程工作和竞争在一定程度上减轻了这种情况，但仍然有一些公司会因为你住在低生活成本的地区而对你进行惩罚。高工资同时享受低生活成本的现象叫做套利，这在科技行业中是你可以利用的机会。

远程工作是降低成本的另一个重要因素。你可以在家吃饭，节省油费、停车费和汽车维护费，同时还可以利用薪资套利。我总是把远程工作或远程福利（比如每周有 20%的时间可以在家工作）作为谈判的一部分。它对我的生活质量有着显著的改善，我把它看作和询问福利或企业文化一样重要。相反，你不希望在面试了几周后才发现，这份看似完美的工作需要你每天往返 45 分钟，或者要求你搬迁！

现在，搬迁本身没有问题，尤其是在职业生涯的早期。从家乡搬到科技职位丰富的地方可能是有利的，公司也可以帮助你支付搬迁费用。不幸的是，套利是双向的，你可能会得到加薪，但生活成本的提高使你失去了获得的任何收益。如果你搬到一个生活成本更高的城市，甚至可能会变得负担更重！在科技圈里，这是一种危险的现象，因为像旧金山、西雅图、纽约和洛杉矶这样的城市拥有很多工作机会，但它们也是美国最昂贵的城市！即使像奥斯汀这样的地方现在也比以前贵得多，所以在比较城市时，你要特别关注住房成本（比其他指标更重要）。

最佳建议是尝试使你的薪水标准化，并根据每个城市进行调整，使用网站或计算器。这样，你可以要求加薪，并根据生活成本差异做出相应的调整，明确知道自己需要要求多少。如同往常一样，数据是王道，你可以随时用确凿的数字和研究来支持你的主张。招聘人员肯定会说，他们会根据经验支付相应的薪水，但他们可能是参考全国数据，而不是考虑到特定地区的调整数据。

如果你查看一份列出最高生活成本的清单，你会发现，例如，圣何塞位于前 10 名最昂贵的城市之中，因此即使他们支付高薪，你的生活方式可能也低于例如住在北卡罗来纳州罗利的水平。这类数据在美国劳动统计局网站上是可以找到的。

除了基本工资外，你可能还想在薪酬的其他方面进行谈判，例如奖金和股权/股票，这些通常可以作为期权进行奖励。在这里，你有权选择以较早的价格购买股票，或者选择 RSU（受限股票单位），即有多年度归属计划的股票奖励。通常你会获得一个年度份额，而这些股票需要 4 年才能完全归属，因此每年你都在同时赚取和归属更多的股票。这在大科技公司中很常见（例如Meta、Apple、Amazon、Netflix和Google），当你在职业阶梯上爬得更高，成为高级领导时，股权成分有时会比薪水更重要！这取决于你在职业生涯中的位置以及所在的公司。

专家提示

有时候，公司会说奖金是某个百分比，但并没有解释奖金可能取决于其他因素，例如你的表现、公司表现或其他因素。它也可能是有条件的，不一定会发放！有些公司倾向于根据表现级别来发放奖金，如果你的表现得分是 4 分（满分 5 分），你可能会获得 80%的奖金。最后，一些公司会在 1 年后支付一部分奖金，剩余部分则在下一年支付，激励你继续留在公司。

历史表明，如果你在一家成功的公司工作，拥有股票奖励，并在公司成长的过程中留下来，你可能会随着公司股票每年增长赚很多钱！不过，你必须注意，并不是每家公司都像 Netflix 或 Amazon 那样快速增长，有些公司可能会崩溃并倒闭。

当你与初创公司合作并将股权作为薪酬的一部分时，应该把它当作一种奖金，而不是薪酬的核心组成部分。毕竟，可能要经过数年，公司才会成功退出，而你可能永远无法从那份股权激励中看到任何价值。从这个角度看，成熟的上市公司在提供股票奖励时拥有更多的杠杆。

Figure 7.4 – 谈判时需要做的事

在本节中，我们学习了在与招聘人员合作时如何进行谈判。我们讨论了哪些方法有效，以及哪些方法需要避免。

在接下来的部分，我们将讨论申请职位后，如何以及何时进行跟进。

跟进，但何时跟进？

求职过程中最令人焦虑的阶段就是在提交简历后，等待电话、电子邮件、短信或烟雾信号的回应。本节将分为两部分：

• 等待游戏

• 与招聘人员跟进的礼仪

让我们先从等待游戏开始。

等待游戏

提交简历后，立刻想要得到反馈是很常见的；我自己也有过许多次这样的经历，深知不知道接下来会发生什么的那种压抑感。保持耐心——通常的规则是在跟进前至少等待两周。许多因素会影响招聘团队处理你申请的时间：

图 7.5 – 未收到招聘人员回应的时间延迟原因

职位发布的时长会影响你在申请职位后应当期待何时得到回应。职位发布的时间越长，你通常会更快收到回应。虽然职位发布的时间本身并不能完全反映预期回应的时间，但当结合职位的申请人数时，你可以做出比较准确的预估。

职位申请者的数量是一个多维度的衡量标准；在本节中，我们仅考虑它如何影响招聘人员的回应时间。职位的申请者越多，你的等待时间通常会越长。如果一个职位已经发布很长时间并且申请者众多，你的等待时间可能会非常长，甚至也可能会很短。有可能该职位已开设很长时间是因为没有找到合适的候选人。

填补职位的紧迫性是你可以利用的优势。你可能会很快得到招聘人员的回复，而且面试过程也会加速。然而，你必须询问为何这个职位急需填补。从我的经验来看，作为面试官和候选人，过于急于填补职位对任何一方都没有好处。加速面试过程可能是公司文化有问题或规划不当的结果，可能导致双方无法充分了解是否能建立有益的关系。另一方面，如果你不尝试，你永远也不会知道。

归根结底，等待并不有趣，但了解影响等待时间的因素可以让这个过程变得更加可承受。

在接下来的部分，我们将讨论与第一方招聘人员合作时，最佳的跟进实践。

与招聘人员跟进的礼仪

自从你申请了一个职位，几周过去了，但仍然没有收到任何回应；在你发送情绪化的邮件——或者更糟的是打电话之前——请花一点时间，尝试遵循一些最佳实践。你可以参考下图：

图 7.6 – 跟进招聘人员的礼仪

电子邮件是跟进招聘人员时唯一可以接受的方式。除非事先获得许可，否则不宜打电话。电子邮件还提供了你的通讯记录的数字化证据。有些公司，尤其是那些收到大量申请的公司，会要求申请者不要进行跟进；你应该遵守公司的政策。

展示兴趣而避免显得急切，在撰写邮件时重申你对该职位的真诚兴趣，并列举职位描述中的具体例子；如以下截图所示：

图 7.7 – 邮件示例

尊重个人边界就像是保持专业一样简单。招聘人员并不是在寻找朋友——他们在寻找顶尖人才。首先，我建议不要将招聘人员添加到任何非专业社交媒体平台，如 Facebook。第一方招聘人员专门为公司工作，而不是为你工作，这意味着他们对你没有任何义务，不需要回应或跟进，不管你多么渴望获得回应。例如，如果你多次跟进了，但他们没有回复，那么他们对你并不感兴趣，是时候继续前进了。

请记住，保持一座桥梁畅通并且保持良好状态，比因为不专业而烧掉这座桥更为重要。情况会发生变化，将来这座桥可能会为你带来最理想的工作！

总结

在本章中，你学习了与招聘人员打交道的基本规则。你还了解了如何以及何时跟进，并且阅读了我们一些在求职和与招聘人员、招聘经理以及代理机构协商时的经验。

拥有一个专业的个人资料，展示你的经验并仔细突出所有技能是至关重要的。你的在线资料是你的名片，因此拥有正确的技能和经验可以让你从网络拓展和特定机会的角度获得你想要的联系。

你可以主动进行求职，并且可以让自己根据在线资料接收到每日的职位信息。养成快速分类每个职位并将其放入正确类别的习惯。合同职位和固定薪水的职位在职责和薪酬上可能差异巨大，因此在开始面试之前，你必须确保自己清楚需要了解的所有信息！

做好研究，提出相关问题，并阅读职位描述，确保你知道自己在签约什么。互联网让申请工作比以往任何时候都更加容易，但盲目申请可能会在之后浪费你更多时间。了解他们的薪资范围，分享你的期望，并确认它们是否一致。询问福利、企业文化、远程工作以及其他形式的补偿，如奖金、股权或股票。

注意生活成本的差异，并意识到在旧金山的一美元不如在博伊西的一美元值钱。向公司询问他们的搬迁套餐、薪资调整以及远程工作的可能性。为了新工作而搬迁可能是一个很好的职业决策，但你当然不希望以牺牲生活质量为代价。

至于招聘人员，直率、直接，尽量不要浪费他们和你自己的时间。如果某个机会看起来是个糟糕的工作，不要仅仅为了面试而去面试。当然，面试练习很有价值，但最好是在你真正感兴趣的工作上进行。

与你喜欢合作的招聘人员建立联系，并在面试过程中与遇到的人建立网络关系，包括招聘经理。有些人可能会因为他们仍在面试过程中而不接受你的请求，但你可以在事后联系他们，并说明你希望无论如何都能建立联系。

在下一章中，我们将开始讨论如何为面试做准备。

第三部分：面试过程

你成功了！你获得了面试机会！到目前为止，你已经在网上展示了自己的形象。在本书的这一部分，我们将详细介绍如何清晰地向招聘团队展示你的才华。

本节包括以下章节：

• 第八章**，准备面试

• 第九章，逐步面试

第八章：为面试做好准备

你已经和招聘人员谈过，了解了职位描述和薪酬水平，并安排了面试。这可能是一个令人畏惧的过程，因此我们将在接下来的几页中详细分解，讨论涉及的所有步骤、最佳准备实践和其他行业技巧。在下一章中，我们将更深入探讨，甚至会谈到一些非常规的面试案例。

本章将涵盖以下主题：

• 面试过程的各个阶段

• 最佳准备方法

• 预期面试内容

• 行业技巧

面试过程的各个阶段

通常，在初步电话沟通之后，你的第一个面试对象是招聘经理。当然，这个顺序可能因公司而异，但我认为这是最常见的起点。在我们的领域，你可以期待一个技术筛选环节，可能由个人进行，也可能由小组进行。对于领导或管理职位，可能由同事或甚至你的下属进行面试。根据公司不同，这可能会导致与你未来领导的一对一电话沟通，可能是你的未来老板，甚至是他们的老板！他们在这里关注的是文化适配性、沟通能力和一般的兼容性。我们稍后会详细讨论。在一些公司，面试环节可能更多。我见过以设计为重点的面试、编程挑战、情境问题、行为问题，甚至是创新思维。我会在第九章《一步步面试》中详细讨论这些内容。

我还想提到的是，一些技术职位会有编程测试，可能是离线的，也可能是实时的，面试官会在你编程时观察并提问。有些公司可能还会要求你参加行为测试或认知测试。我将在非常规面试的详细介绍中讲解这些内容。编程测试对于软件工程师来说可能很常见，但对于 DevOps 专业人员则较少。我认为三轮面试可能是最常见的设置。如果你在大型公司面试，比如《财富》100 强公司，面试过程可能需要四轮或五轮。

图 8.1 – 面试阶段

然而，在许多公司，通常是三轮面试，简短而直接。准备你的第一轮面试并不困难，但这是许多候选人往往留下未完成的地方，所以让我们从这里开始。

第一轮面试

虽然你可能首先与招聘人员和人力资源部门的人员交谈，但我们认为第一轮面试是与团队成员进行的。通常，这个人是招聘经理。面试时间通常为 30 分钟到 1 小时，面试中招聘经理会告诉你关于公司、团队、他们的需求，然后询问你的经验。确保你做了功课，了解一些关于公司的信息。

如果你已经阅读了职位描述，你应该大致了解他们在寻找什么，以及你的经验如何与他们的需求匹配。谈论你的工作经验时，你应该突出你的技能和任何你认为与申请职位相关的内容。

你应该首先概述一下自己的职业生涯，花 5 分钟介绍自己是谁，以及你一直在做什么。如果你能阐明你的经历和这个职位的匹配程度，那就更好了。

面试官一定会问你一个问题，特别是如果你不是刚毕业的大学生，那就是为什么你想在他们公司工作，或者为什么你想换工作。通常，你可以说你想要更高的薪水，但这并不能说服你的未来雇主你不会因为更高的报酬而离开他们。最好将你对新角色的渴望与职业发展以及你申请的公司直接联系起来。这是一个展示你对与他们合作充满热情和兴趣的绝佳机会。

我注意到招聘经理在这个阶段通常会试图了解你如何融入团队。例如，如果你是一个经理，他们可能会问你关于领导风格的问题。他们也可能会问你情境性问题，比如你告诉他们一个你处理某个问题的经历。他们也可能会问你怎么看待自己的优点、缺点和职业前景，比如你如何看待自己 5 年后的发展。

根据面试官的不同，你可能会回答这些问题中的一些或大多数。特别是亚马逊，非常重视这种类型的面试问题。

专业建议：第一轮准备

一般来说，最好提前准备一些关于你如何处理常见情境的故事。例如，讲讲你曾经与一个利益相关者有分歧，并且你是如何解决这个问题的。面试官希望知道你能应对分歧和冲突，并且有足够的韧性在现代职场中生存下去，所以准备几则展示你如何应对并克服困境和类似情况的故事。保持一个电子表格或文档，并进行练习，这样这些就会变成你的第二天性。

一旦他们告诉你关于自己和团队的情况，并且你已经介绍了自己的背景，回答了他们可能提出的所有问题，他们肯定会问你是否有任何问题。这是一个展示你做过功课的好时机，可以问一些关于公司、未来计划以及你如何为他们的工作做出贡献的问题。

你还可以问一些重要问题，包括公司的下一步计划，以及是否存在任何挑战让你难以胜任这个职位，或者更好的是，他们认为成功完成这个职位需要具备哪些能力。

技术面试

这一轮面试的形式可能会有所不同，具体取决于面试的地点。它可能是一个编程测试，在这种测试中，面试官会给你一个问题，并观察你如何解决，可能会在你解决问题的过程中提供提示，并要求你在一定时间内完成解决方案。在此期间，面试官可能会询问与你工作相关的问题。它也可能是一个小组面试，由三位同行或专家组成，他们会问你技术性问题，以了解你的知识深度，涉及多个领域。这是最重要的一轮，因为你将主要因你的知识被聘用，而不是因为你做过什么，这也是你展示自己知识的机会。如果需要，不要害怕提问，或者在不确定时说我不知道。这比胡乱说话要好，因为这样做可能会让自己陷入困境。你可以随时说这不是我的专长领域，然后引导面试官问你另一个问题。没有人知道所有的事情，因此非常容易被那些试图让你出难题的人难倒。你要展示的是深思熟虑的答案，并表明你能够以智能且富有创意的方式思考解决方案。

专业建议：技术面试

技术面试是面试过程中的最具压力的一部分，且设计上就是如此。利用这一点，保持冷静，给自己一些时间来处理面试官所提的问题。如果你对某个概念或语言不熟悉，可以请求另一个问题。

通常，在科技巨头（如 Google、Meta、Amazon、Microsoft 等）公司，你会遇到一项困难的技术评估，考察你在计算机科学领域的知识，包括数据结构、批判性思维、对象以及大 O 表示法。对于与云相关的工作，你可能会被问到与云服务相关的具体问题，类似于认证考试中的问题。建议你向招聘人员询问接下来会面临什么样的面试，并询问是否有任何准备建议。当面临编程挑战时，通常会使用一个允许你使用多种编程语言的平台，因此你可以选择你最熟悉的编程语言。我总是使用 Python，因为它简单易用，但如果你更习惯使用 Java，也完全可以选择它。关键是至少精通一种编程语言。对于这些类型的面试，最好进行大量的练习，如前所述。以下网址，leetcode.com/，以及Cracking the Coding Interview（由 Gayle Laakmann McDowell 编写的书籍）都是非常好的资源。

除非另有说明，否则你还需要熟悉 Linux，这意味着你需要掌握 Bash 和 shell 命令及脚本。根据不同的职位和公司，你可能还需要谈论架构或特定的系统。

最后，可能还会有带回家的作业和家庭作业。这些任务可以是架构图、设计文档、编码挑战，甚至是实际部署在云端的服务，他们会连接并验证这些服务。如果是带回家的任务，时间对你有利，所以不要惊慌；只需预留一天时间专心完成即可。

图 8.2 – 技术面试类型

我们将在未来章节中详细讨论面试流程的例外情况，但现在让我们来讨论跟进环节。

跟进环节

根据公司和职位的不同，可能会有一个或多个后续面试环节。例如，可能会有一个专门的架构或设计面试，专家会提出一个情景，并想看到你如何解决问题。如果你是领导者，可能会遇到来自其他团队的领导，甚至是你老板的老板。与其他团队面试并不罕见，特别是在有明显重叠的情况下，如与 QA、测试和 DevOps 等团队。如果你是个体贡献者，你可能会遇到一位同行工程师、一位更资深的工程师，或一位与你所在团队密切合作的其他团队的工程师。DevOps 非常注重协作，因此你会遇到来自你自己团队以外的人，展示你是客户服务导向且具有团队精神是非常重要的。

如果你处于领导层职位，你可以预期会有一个面试小组来评估你的技术知识，还有另一个面试小组评估你的领导力和协作能力。这些面试通常由组织中的其他领导进行，通常是同行或处于相似级别的人。

通常你还会与招聘经理的上级见面，因为你是他们团队的一部分。这将不是技术面试，而是文化契合度、领导风格和理想特质的综合考察。如果你是领导者，准备好深入讨论你的领导风格，并提供具体的例子。如果你是个体贡献者，可能会被问到与成长相关的问题，你需要分享职业规划，以便他们了解你的规划与他们的需求是否一致。常见的问题是“你如何看待自己五年后的发展”，因此，心中有一个大致的规划是有利的。

你应该在最后一轮面试后一周内收到决定，但如果他们面试了很多候选人，这个时间可能会有所波动。始终与招聘人员跟进，了解下一步的流程，但也要给他们一些时间，因为即使是整合来自多个面试的所有反馈也需要时间。

最佳准备方式

在面试前，最好的准备方式是研究公司、你的招聘经理和这个职位。职位描述文件将提供很多关于他们理想候选人的信息。如果你缺少一个在那里突出的技能，可以试着加强这方面的知识。如果有一些你是专家的领域，确保你突出这一点。

专业提示：技术面试准备

对于技术面试，最好准备好让你的简历受到挑战。简历中的每一项都可能被问及，所以不要误导他人！

询问负责安排你面试的人或 HR 联系人，每轮面试都应该预期会发生什么，尤其是技术面试。如果你仅仅问一下，你可以从以前的面试中得到样本问题或有用的反馈。

如果工作描述中有许多陌生的项目，可以在面试前几天快速参加一些课程。这将帮助你在技术方面蓬勃发展。像 Udemy、Pluralsight 甚至 YouTube 等网站上有很多关于技术主题的教程。另一个方面，如果适用于你的面试，是编程挑战。编程挑战可能非常令人紧张，因为在写代码时会受到面试官的监视。为此练习的方法是使用 LeetCode 等网站。这些网站还提供编程挑战的最佳解决方案。一个好主意是经常这样做，即使你没有在面试，也要经常这样做，以便在这类案例场景中感到自在。

通常来说，你应该了解你申请的角色所期望的内容，同时也要了解自己的优势和劣势。如果编程不是你的强项，并且未来会有编程挑战，请花些时间学习算法和常见的编程挑战。面试中有很多面试和准备材料，你只是受限于吸收这些材料的时间。

专业提示：面试练习

提高任何技能的最佳方法是通过练习和重复。面试也是如此。即使你目前不积极寻找工作，你也应该申请职位并参加面试过程。每次这样做，你都会对面试过程有更多的了解；利用你得到的反馈，并将其应用到你的准备仪式中。

你可能已经有了一份你愿意为之离开目前雇主的公司的简短名单。但你要知道！如果你从不申请，你就不会得到工作的机会。也许你还没有申请是因为你觉得自己不够资格，或者听说面试过程很难。让这成为你振作的动力，去尝试吧。尤其是如果是像 Netflix、Google、Amazon 或 Facebook 这样的公司，第一次很可能会失败。

正如我之前提到的，熟能生巧，而在这种情况下，失败只会让你变得更好，谁知道呢，也许你第一次尝试就能得到梦寐以求的工作。

除了进行研究和技术准备外，你还应该回答一些常见的情境问题，比如“如果发生了什么你会怎么做？”或者“你有没有做过某事？”如果你在网上搜索面试问题，你可以找到一些常见问题，然后将这些问题的答案写下来。排练这些答案不仅能确保你的回答有力且具有说服力，还能确保你表达得简洁明了且富有吸引力。你不想在顺利通过技术关卡后，因为表达不清楚自己如何克服挑战或者如何在组织内协作而摔倒。和其他一切一样，熟能生巧。

预期的内容

如果一切顺利，完成整个面试流程后，你可能会在最短的 1 周内收到反馈。如果他们有很多候选人需要面试，这个时间可能会更长。如果表现不佳，面试流程可能会提前结束，你可能会收到一封自动化的邮件，感谢你参加面试，但他们将继续与其他候选人进行沟通。不要灰心。我估计，至少需要提交 50 份申请，进行 5-10 次面试，才能拿到一个可能你真的想要的工作的 offer。很少有人只申请一个职位就获得面试机会并顺利拿到 offer。高薪的技术岗位竞争激烈，所以要有耐心，并尽可能为自己争取更多有利条件。

图 8.3 – 提交的申请与最终面试

通常，在每一轮面试后，你都有机会提问，因此可以随时询问下一阶段的内容，收集一些早期的情报。如果你需要更多时间准备，不要急于面试！告知你的招聘人员并在需要时重新安排面试时间。

如果你收到拒绝信，别气馁。虽然向刚刚拒绝你的公司询问拒绝原因是件好事，但往往他们不会详细说明，可能是因为没有时间逐一回复每个候选人，或者出于避免某种法律责任的考虑。无论如何，你可以期待收到一封自动化的拒信，内容是他们将继续与其他候选人沟通。

即使没有收到直接反馈，现在也是你自己分析情况的时机，弄清楚哪里出了问题，哪里做得好，自己可以做得更好的地方在哪里。

有时，即使你认为自己在所有面试中表现出色，依然可能没能获得工作，因为可能有一个更合适的候选人。有时候，候选人更合适的原因可能很多，包括要求较低薪酬的候选人，或者有推荐人介绍的候选人，或者有更合适的地理位置的候选人。原因可能五花八门，但如果你养成在每次失败的面试后分析自己表现的习惯，你可以放心，你会逐渐变得更好。根据我的经验，你总能学到更多，但更重要的是，你可以更好地沟通。

持续面试周期

接下来，我将介绍持续面试周期的概念，该周期由三个阶段组成：申请与准备、面试和反馈。

](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/dop-crr-hb/img/Figure_8.4.jpg)

图 8.4 – 持续面试周期

我们将从面试周期中的申请与准备阶段开始讨论。

申请与准备阶段

在这个周期阶段，你正在申请职位并准备即将到来的面试。如果你已经收到了之前面试的反馈，请确保将这些反馈纳入你的准备工作中，确保你的面试技巧不断发展和改进。

面试阶段

面试阶段包括公司面试流程中的所有面试。此阶段持续到你收到反馈，无论是正面还是负面反馈。

反馈阶段

这是你必须处理从雇主那里得到的反馈的阶段。如果你被提供了工作机会，你必须决定是否接受这个 offer，拒绝它，或者提出反要约。如果你没有得到工作机会，雇主可能会给你反馈说明原因；如果没有反馈，你应该回顾整个面试过程。

在下一节，我们将讨论行业技巧。

行业技巧

从你投入的时间中获得最佳结果的方法是，确保你为每一场面试都投入了必要的准备时间。如果你有很多面试安排，并且还在工作中，这可能会很困难，但请记住，你可能会因为一些原因被淘汰，但你不会知道，直到你已经花费了时间和精力。得知自己因为一个小问题没有进入团队，可能会让你感到很沮丧，尤其是在花了几周时间面试之后。不要面试那些你不真正感兴趣的职位，或者那些你认为不值得额外准备的职位。为自己着想，做好准备，让自己处于有利的位置。

在接下来的部分，我们将讨论我在面试过程中发现有效的策略以及我认为无效或对成功有害的做法。首先，看看以下图示：

](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/dop-crr-hb/img/Figure_8.5.jpg)

图 8.5 – 不要那样做，应该这样做

在本章的下一个部分，我们将讨论候选人在面试过程中常犯的错误。

常见错误

以下是我在面试过程中使用过并证明有效的做法清单。这不是一个完整的清单，我鼓励读者去了解其他人的见解，从而为面试提供最佳成功机会：

• 没有完全理解问题：

  • 这种情况在所有类型的面试中都非常常见，不仅仅是技术面试。面试者常常会听到几个关键词，开始在脑海中想出解决方案，结果错过了问题的其余部分，最后完全答错。始终等到完全理解问题后再进入解决方案阶段。

    专业小贴士：做笔记

    确保不遗漏任何内容的最佳方法是做笔记。如果面试是面对面的，可以使用便签和笔，如果是虚拟面试，可以使用电脑上的便签应用。这将展示你对面试的兴趣，同时在回答之前让你充分理解问题，并在回答前有机会提问。

• 没有处理边界情况：

  • 在编程问题或挑战中，面试者很多时候不会在代码中编写任何边界/角落情况的处理代码。记住，你的解决方案将通过预生成的测试用例进行测试，如果你没有编写代码来处理边界/角落情况，它肯定会失败。

    专业小贴士：练习 TDD

    在本书的第一章，第一章，职业路径一节中，我们讨论了 DevOps 如何融入许多极限编程实践，包括测试驱动开发（TDD），这种方法要求程序编写测试用例，直到正确的代码实现之前，这些测试用例都会失败。如果时间允许（例如家庭作业），可以使用 TDD 实践来确保不会漏掉边界情况，同时展示你对极限编程实践的理解。

• 对语言不熟悉：

  • 面试者通常会在面试中选择用 Python 写代码，因为它类似于伪代码。如果你选择这样做是完全可以的，但请确保足够熟悉你选择的语言，以便知道如何进行基本的字符串操作、算术运算，并且能够舒适地创建数据结构。如果你对所选语言不熟悉，这会让面试官认为你不熟悉编写代码，或者你不常写代码。

    专业小贴士：注册每日编程问题

    注册每天接收编程挑战问题的邮件，网址：www.dailycodingproblem.com/。第二天，你将收到该问题的解决方案。我曾使用过这个方法，它帮助我准备了编码面试，同时也让我在配对编程和集体编程中更加自信。

• 保持安静：

  • 当面试者在思考时，通常会保持安静。这正是面试官所不期望的。通常，面试官只是想看看你如何思考以及你解决问题的方法。保持安静可能会导致面试官对你的假设产生误解。相反，你应该大声说出自己的思考过程，确保面试官能够参与到你的思考中。

    专业小贴士：不要假装自己了解不熟悉的内容！

    很多接受面试的人在被问到自己不懂或完全不熟悉的内容时会感到慌乱。在技术领域，新技术每天都在被实施，所以你不可能知道所有的内容，这是很正常的。通常情况下，直接说“我不熟悉这个，但它听起来非常有趣，我很想了解”比试图编造答案要好。记住，面试官很可能是该技术的专家，他们一眼就能看出你是否在吹牛。

有效的方法

谈判时最重要的事情是做好研究：

• 关于公司、职位、所需技能、招聘经理以及新闻等方面的研究。甚至对面试流程本身的研究，都能为你提供准备所需的优势。研究、研究、再研究，只有这样你才能获得其他候选人没有的优势。

  专业小贴士：找到内部消息源

  获取公司信息的最佳途径是与该公司的员工交谈。LinkedIn 让你能够轻松找到在特定公司工作且在你网络中的联系人。

• 一旦你进入了求职的密集阶段，你可能会同时接受多家公司的面试：

  • 至少保持一份电子表格，记录招聘人员和招聘经理的基本信息，以及你可能随时需要的任何资料。追踪面试过程中的进展，以及早期谈论过的薪酬水平也是很有用的。

    专业小贴士：保持一致性

    如果你对一个问题给出两个面试官不同的答案，你看起来会显得不够有条理和不专业。最常见的情况发生在薪酬方面。招聘人员在初次面试时几乎肯定会问你期望的薪资水平，而你必须记住这个数字，并且在后续过程中不要提高它。

• 应用在连续面试周期部分讨论的原则：

  • 通过定期面试、接受面试反馈并将其应用到下次准备中，你可以始终保持新鲜感和面试的舒适感。

• 对你不知道的内容要保持舒适感：

  • 你不需要知道所有的事情，这完全是可以接受并且是预期中的。在面试时要诚实地告诉面试官你的优势与不足。

    专业建议：对你不知道的内容保持舒适感，但要保持开放的态度并愿意学习新知识。

    到目前为止，本书已经明确表达了我对那些优先考虑持续学习与自我提升的人的高度重视。相信我，我并不是唯一一个在招聘时看重这种心态的人。在某些情况下，一个没有先前知识、具有新鲜视角的人正是团队所需要的。

总结

在这一章中，你对面试过程有了很多洞察，并且了解了如何为其中常见的不同阶段做好准备。

我们还讨论了面试的不同阶段以及你可以期待的内容，将个人贡献者与领导角色的细节区分开来。

我们讨论了在每次面试循环中你可以期待什么，并且如何从每一轮面试中最大化收益，即使你最终没有拿到 offer。

最后，我们介绍了一些在面试环境中有效的技巧与方法，以及哪些是行不通的。

我们还详细讨论了各种面试类型，但我们将在接下来的章节中更详细地讲解这一部分。在下一章，我们将讨论典型和非典型的面试，以及如何在这两种面试中顺利应对并取得成功。

第九章：一步步解读面试

在上一章中，我们谈到了面试过程，但没有过多细节。本章将继续讨论这个话题，深入探讨不同的步骤、你可能会接触到的不同人员，以及如何为每个阶段做好最佳准备。为此，我将通过具体示例和额外细节来讲解典型面试与非典型面试。从编码挑战、设计题、情境题和智商测试到其他所有类型的面试，我将尽力覆盖一切内容，并给你一些建议，帮助你变得无懈可击，无论遇到哪种类型的面试。

在本章中，我们将讨论以下主题：

• 典型的面试流程

• 非典型的面试流程

典型的面试流程

下图将面试过程分为三个阶段——初始面试、技术评估和后续面试：

![图 9.1 – 面试阶段回顾]

](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/dop-crr-hb/img/Figure_9.1.jpg)

图 9.1 – 面试阶段回顾

我们将在接下来的部分中更详细地讨论这些内容。简而言之，每一轮面试对于面试的结果都是同等重要的，因此在每一轮面试中都要全力以赴。

第一轮面试

第一轮是你与招聘经理或从事类似职能的人员交流的阶段。你会提前与招聘人员或人力资源部门进行电话联系，但就本次概述而言，这些只是第一轮面试前的准备工作。

什么是第一轮面试？

第一轮面试被认为是你与招聘经理或评估你资格和适合度的人员的面试。这是在人力资源筛选电话成功后进行的面试。

对于第一轮面试，你必须专注于对公司进行调研，查看面试官的 LinkedIn 个人资料（他们将是你的直接上司）寻找线索，并确保你多次阅读职位描述。

除了背景信息外，你还应该专注于传达你的软技能，主要是清晰简洁地讲述你的经验，并思考你之前的经验如何能为潜在雇主带来帮助。

在这一轮面试中，他们通常会详细讨论当前的挑战，因此在面试过程中可以随时提出临时问题，最后留出一些问题，因为他们会期待你提问。你可以利用这个提问环节来结合你之前的经验，并解释你如何解决类似的挑战。这有助于给他们留下你知道如何解决他们面临的挑战的印象，这也是结束面试的一个绝佳方式。

如果你正在面试一个领导职位（即使你不是），你也应该询问你将与之共事的团队情况。

除非面试官明确提到，否则不要谈论薪资、福利或类似内容。

下图列出了第一轮面试的一些注意事项：

图 9.2 – 第一轮面试的注意事项

确保你提出足够多的问题！这是展示你做了足够研究、已经准备好开始工作并且对工作充满热情的最佳时机。对许多公司来说，你对这个职位的兴趣有时比你的技术资格更重要。如果你在面试过程中看起来或听起来无聊，可能会错失机会！

技术面试

这是面试中最关键的部分，因为目标是确定你技术知识的深度和广度；在与招聘经理的面试和这一阶段之间，你能做的准备有限。最好不要误表示你的技能，以免被问到你没有经验或不熟练的领域。如果你遇到自己不了解的内容，解释自己过去没有从事过这个领域的工作，但你对此感兴趣。如果你突然说出一些没有准备的内容，可能会对你试图建立的信任关系造成无法挽回的伤害。

不同的公司将采用不同的方式来评估你的技术能力，从最常见的场景——一位或多位面试官向你提问技术问题，到更复杂的情况——公司可能会提前给你一个设计、编码或架构的挑战，让你完成后再当面讨论。简单的技术筛选通常由一个小组或多个独立面试官组成，你可以期待他们深入探索你的技术知识。记住，你简历上的任何内容都可能成为提问的对象。

有一次，我需要在云端架构一个系统，并提供我所做的所有工作证明，实际上这等于授予了我所托管的基础设施的访问权限。后来，我被问到了相关问题。

还有一次，我被要求做一个带回家完成的问题，要求我使用一个我明确表示没有经验的工具。这类问题的目的是考察你学习新事物的能力——在大多数情况下，你将被评估解决方案的创造力，而非工具的理解。

我也多次面临编程挑战，问题的范围从一般的编程能力测试（例如，你如何实现这个XYZ?）到更具体的问题。这些问题的形式各异，从荣誉制的解决方案——你只有一两天时间提交测试，无法知道你是否通过搜索引擎找到答案，到更为复杂的第三方监考测试——真正的人会在你编程时观察你。一些公司可能希望你在现场编程，并在你工作时提问。

更具挑战性的编程测试通常是针对软件工程师的，但 DevOps 工程师通常也需要具备一定的编程能力。关键是至少要精通一门语言，能够实现常见的算法和数据结构。

提示

DevOps 工程师需要成为优秀的软件工程师和程序员；我所认识的一些最熟练的编码人员，恰好是我的 DevOps 同行。

其他类型的技术测试可能更具领域特定性，比如编写 Terraform 模块或 Shell 脚本来自动化任务。不管是什么测试，确保在开始前尽可能收集相关信息，并预期在后续的讨论中详细探讨你的解决方案。

设计面试或挑战有些不同。它专注于创建一个新的应用程序或服务，并构建相应的基础设施和服务。可能需要你在数据库、安全性等方面做出决策，甚至涉及一些传统上更侧重于应用程序开发的领域。一些公司会考察你对整个应用程序堆栈的理解程度。拥有一定的高层次理解是非常重要的，尤其是在云计算领域。你应该知道如何划分和保护网络，以及如何防止互联网访问你的后端和数据库。你应该知道如何进行身份验证、创建安全组，并且对网络有很好的理解。不同的角色将有不同的侧重点。有些公司会更关注容器化，可能会深入探讨 Kubernetes。有些公司则可能涉及无服务器架构。获得一些认证有助于确保你对可能未曾在职业生涯中使用过的服务有广泛的理解。同时，它们也帮助你在面试竞争者中脱颖而出。

即使是在技术面试中，结束时提问也很重要。我喜欢问技术面试官他们有多享受自己的工作，或者他们看到的挑战是什么。这可能与第一轮面试时的答案不同。

额外的面试轮次

你应该与招聘人员密切合作，准确了解每一轮面试的内容。若有疑问，最保险的方法是通过 LinkedIn 查看面试官的背景，了解他们的工作领域。根据我的经验，如果面试官来自与你不同的领域，比如质量保证（QA）和测试，那么通常这类面试更多的是考察文化或团队契合度，可能会有一些情境性的问题。如果面试官来自与你相同的领域，他们可能会更关注你的具体经验，并了解你是否能够解决他们面临的挑战。

即使你在技术面试中表现优异，也不要放松警惕！你仍然可能因为缺乏足够的热情，或在最后一轮面试中表现不够强势而未能通过。记住，即便你做得非常好，其他候选人也可能表现更出色，所以始终要全力以赴，直到最后一轮面试结束。

如果可能，等一段时间再请求反馈。如果没有得到工作机会，也要请求反馈。有时，他们不会给你更多的具体理由，只会给你一个泛泛的拒绝，但有时你会得到一些有价值的信息，指出你面试过程中的一个关键问题，比如过于亲力亲为或不够亲力亲为，或者是你的热情与他们的预期不符。我曾有一个人告诉我，我表现得不够有情感，这让他们感到不舒服。

除了正式反馈之外，试着分析你的表现并给自己一些反馈。你的回答是否尽可能流畅或简洁？你是否有任何知识空白？

下图展示了不同类型的技术面试：

图 9.3 – 技术面试类型

在下一部分，我们将讨论面试过程中的 offer 阶段。

Offer 阶段

恭喜你——你通过了面试，克服了所有障碍，公司的招聘人员或人力资源部门已经联系你，表示希望给你提供 offer！通常，他们会先给出口头 offer，如果你口头接受，他们会发出书面 offer，通常会附带一个有效期——大约 48 小时到一周。

现在，如果你同时在多个公司进行面试，可能正处于收到多个 offer 的过程中，并且有可能进行进一步的谈判。小心不要过度表演，因为如果公司认为你只是利用他们来获得更好的待遇或改善现有工作状况，它们可能会撤回 offer。关键是你应该小心行事，因为这份工作还不是你的，所以要把这当作面试的最后阶段来看待。

在谈判时，你应该专注于表现出对这个角色非常热情。此外，在待遇上，尽量保持灵活性，因为他们在某些方面可能比其他方面更有弹性。谨慎地不要过早告诉你其他的机会已经收到了 offer，因为这可能适得其反。不要提及公司名称，也不要透露过多的具体情况。如果你收到了两个或更多的 offer，那么可以开始认真谈判，但前提是你愿意放弃你正在争取的机会。

有时候，人们会将 offer 拿回他们的工作公司并要求加薪。这可能是一个短期内通过外部 offer 获得加薪的好方法，但也可能会产生负面反馈，并且根据就业市场的情况，他们可能会在未来寻求某种保障，以防止这种情况再次发生。具体情况具体分析。如果你已经好几年没有加薪，并且收到了 offer，那就两边都要进行谈判。只是要尽量管理好你的选择，确保在做决定后，你与两家公司都能保持良好的关系。

非典型面试流程

虽然大多数面试通常遵循一定的模式，但偶尔你会遇到一些不同寻常的情况，值得特别关注。在本节中，我们将介绍预筛选测试、创新设计以及一些典型问题，比如著名的Tell me a time when格式问题。

测试

首先，让我们从预筛选测试开始。一些公司希望了解你的个性类型，并要求你提前参加一个个性测试。这个测试可能仅仅是让你评估五个与你相关的词汇的一页内容，也可能是一个包含 15 个以上问题的长篇考试。

有时，这会与认知测试配对进行，类似于传统的智商测试，不过在这些测试中用于测试的时间远远少于传统智商测试。我参加过Criteria 认知能力测试（CCAT）好几次，这个测试有 50 个问题，时间限制为 15 分钟。只有一次，我答完了所有 50 道题，而且做这件事时有相当多的猜测。问题的内容包括数学、逻辑问题，以及空间和语言类问题，如类比或反义词。这项测试需要你集中精力，因此尽量不要在疲劳或容易分心时进行这类测试。

我甚至听说一些私募股权公司要求他们投资的每一家公司员工都参加这些测试！对于这类测试，你能做的准备工作不多，但你可以通过确保你有 15 分钟的专注时间，并且在脑力处于最佳状态时进行测试来为自己增加一些优势。由于猜测不会受到惩罚，你应该始终在最后一分钟内猜测所有剩余的问题。

如果你没有这类测试的经验，可以尝试找到一份模拟测试：

图 9.4 – CCAT 问题示例 – 1

前面的截图展示了来自www.criteriacorp.com/的一个口头问题示例。以下截图展示了来自www.criteriacorp.com/的一个数学问题示例：

图 9.5 – CCAT 问题示例 – 2

除了个性和认知测试外，还有编程和设计测试，我们之前已经讨论过这些内容。对于传统的编程测试，leetcode.com/是一个合适的起点，www.hackerrank.com/也是一个不错的选择。对于书籍，推荐《Cracking the Coding Interview》这本书，作者是Gayle Laakmann McDowell，其中包含了很多针对公司的特定技巧。

创新设计

对于设计来说，这会稍微复杂一些，但有一些很好的书籍深入讲解了系统设计，不仅能帮助你应对线下测试，还能在与面试官现场解答设计问题时提供帮助。对于与云相关的设计，可以参考云服务提供商提供的参考架构。如果你研究几种样本，你将能掌握很多场景的共性，更快速地想到解决方案。我建议你熟悉至少一种图表工具，并在被迫现场设计之前，尝试在该工具中设计一个示范性的三层应用。

你可能会遇到一个非传统性的问题，比如著名的纽约有多少个井盖之类的问题。我曾被问到，如果我被缩小并放进搅拌机里，我会怎么办。我还曾被要求从零开始设计一个地图应用的流程，在一个基础设施落后的欠发达国家。公司也可能要求你设计他们的某项服务，改进它，或创造一些新的东西。很多大型科技公司可能会以这种方式筛选你，无论你的具体技术角色是什么，所以如果你说自己是DevOps，也不意味着就能避开这个环节。

以下图中包含了一些非传统性问题：

图 9.6 – 极其困难的面试问题

幸好，最疯狂的脑筋急转弯式问题已经基本上消失，不再被用来严肃地筛选候选人。像往常一样，问问你的招聘人员应该期待什么，如果公司够大，互联网肯定会有关于他们可能抛给你哪些问题或设计问题的额外信息。在这类面试中，最重要的是你能清晰、逻辑地表达自己的思考，并且在制定解决方案时考虑到例外和边缘情况。

讲讲你曾经遇到过的一个情境

我最喜欢的云服务提供商之一以提问情境性问题而闻名，这些问题都以讲讲你曾经遇到过的一个情境的口号开始。这类问题会询问你在职业生涯中的经历，如何克服困难，以及如何处理各种职业情况。关键是你需要用 STAR 格式来回答 —— 情境、任务、行动和结果 —— 如下图所示：

图 9.7 – STAR 技巧

发生了什么，你做了什么，结果是什么？在这里，你应该少强调公司或团队，而更关注你的贡献。理想的候选人是那个敢于挑战当前规范、突破现状，以获得最佳结果的人——无论是对自己、团队还是客户。

这里的挑战之一是，你自己的经历可能并不像你想象的那样有趣或英雄化，或者你可能没有一套随时可以使用的故事。这可能让人很烦恼，但解决方案很简单。创建一个文档，开始整理你的故事，用 STAR 格式回答样本问题。你不希望在同一面试环节中重复讲述相同的故事，因此，确保如果有类似问题，你能快速切换到不同的故事。

告诉我一次你需要与难以合作的人一起工作时的经历？

ST: 我曾与一位难以合作的队友共事。

A: 我花了额外的时间了解这个人，我们的关系得到了改善。

R: 现在这个人非常适合合作。

现在，这个故事可能显得有些单调，但我剥离了那些部分来展示核心机制。

那么，如何让你的故事更好呢？你可以添加数据和数字。为你的故事增加量化的感觉会使其更加令人记忆深刻和印象深刻（尤其是与那些没有具体数据可分享的其他候选人相比）。

通常，R 部分应该是积极的，但并不总是完全积极的。如果它展示了你超越了自我，即使是负面结果，也可以被看作是一个积极的回答，就像下面这个例子所示：

告诉我一次你需要与难以合作的人一起工作时的经历？

ST: 作为一名在 ABC 公司工作的初级开发者，我的小组成员尽其所能与我制造麻烦。他们故意试图让我们之间产生隔阂，甚至试图疏远我和其他队员的关系。

A: 我是团队中新加入的成员，而与我发生冲突的那个人已经在团队工作了 4 年半。我邀请他一起吃午餐，希望我们能更好地了解对方。此外，我明确表示，我并不是要接管他们的团队，而只是根据需要提供帮助。

R: 2.5 年后，我和那个麻烦制造者已经是同事，我们之间建立了强大的工作关系。我们彼此尊重，但也非常具有竞争性，因为我们总是在努力推动对方向前进。说实话，如果没有我们现在的关系，我也不会被晋升为和他在同一团队的高级工程师。他是推荐我申请这个职位的几个人之一。

注意，这类问题可以应用于技术和非技术场景。你职位越高，问题越偏向领导力，但你应该准备好将任何答案以 STAR 格式呈现。

避免的错误

在回答问题时，避免使用我们或我们团队。相反，专注于你自己做了什么。即使是团队合作，也要强调你为解决方案提供了什么。

我看到的另一个常见错误是，候选人用简单的“是/否”回答问题，而不是利用这个机会加入一些关于自己的相关信息。根据你所面试的职位，如果面试官直接要求你提供更具体的例子，你可能还有机会挽回局面。

总结一下，找到一份情境面试问题的清单，并开始回答这些问题，将你的问题和答案保存在云端文档中。然后，优化你的答案，使其更加简洁有力，便于分享。

总结

在本章中，我们更详细地讲解了传统面试和非典型面试的流程。

我们讲解了面试过程中的传统阶段，重点讨论了技术评估阶段，讨论了各种类型的测试和筛选方式，以及如何准备。

我们还讨论了非传统的面试场景，如认知测试、性格测试、情境演练和设计问题，包括富有创意的脑筋急转弯等。我们强调了提前练习测试并写出最常见情境问题的答案，并随时保存。实践出真知，面试也不例外！

在下一章中，我们将讨论申请和面试过程中的一些技巧和窍门。

第四部分：技巧、窍门与访谈

作者们在 DevOps 领域积累了 25 年的共同经验，这些经验构成了我们书籍的最后一部分。它正如书名所言——为 DevOps 专业人士提供的技巧、窍门和访谈。

本节包含以下章节：

• 第十章**，DevOps 职业生涯：技巧与窍门

• 第十一章**，与 DevOps 从业者的访谈

第十章：DevOps 职业：技巧与窍门

在前面的三章中，我们定义了 DevOps，讨论了你可以走的不同路径，并制定了一个你可以在申请过程中遵循的基础计划，以及每个面试阶段的注意事项。本章将重点讨论申请和面试过程。

本章将涵盖以下主要内容：

• 转行进入 DevOps 职业的建议

• 面试过程中要避免的技巧与窍门

• 面试过程中可以采用的技巧与窍门

转行进入 DevOps 职业的建议

本节内容围绕我的 DevOps 之旅展开。我将通过讲述我的故事来铺垫基础，接着分享从中提取的技巧。

个人 DevOps 之旅

2005 年，我决定去明尼苏达大学攻读机械工程专业。在大学时，我需要修一门 C++计算机科学课程。这门课是大学里唯一的一门软件相关课程；然而，这门课让我激发了继续探索编程以及编程能做什么的兴趣。这种兴趣促使我购买了一个微控制器板，类似于现在大家所说的 Arduino。我最终创建了一个托管在 Web 服务器上的网页，进而将宿舍房间与计算机连接，进行远程监控。

我在大学最后一年选修了一门专注于自动化和机器人技术的实验课，这激发了我对自动化的兴趣。我的课程教授也激发了我对自动化的兴趣。在实验课上，我们需要制造一个没有人工干预的产品——我们选择了一个木制的玩具板。我们被分成三人小组，每个小组负责使用一台 Fanuc 六轴机器人以及一个制造环节。我所在的小组负责包装环节。当玩具板制造完成后，它需要被放入盒子中、贴上标签并发货。我对整个过程产生了浓厚的兴趣，最终我在实验室花费了更多时间在自己的环节上，并且帮助其他环节与我们的小组进行对接。教授成为了我第一个学术导师，也是我最终决定毕业后选择那份工作的原因。

我大学毕业后的第一份工作是做制造工程师，这份工作我并不喜欢，但我选择了它，因为我能在工业环境中接触到自动化技术。我从自动化部门的资深同事那里吸收了尽可能多的知识；其中有一位同事告诉我，如果你仅仅花很少的时间在某件事情上，是不可能迅速掌握它的。他建议我买一个二手微控制器，自己动手玩一玩。我照做了，最终搭建了一个家庭实验室，逐渐发展成家庭自动化任务，最终变成了一个完全自动化的家。

我的制造工程师生涯结束后，我开始了作为自动化工程师的职业生涯，在北达科他州西部的石油和天然气行业工作。在担任自动化工程师期间，我接触到了监控控制与数据采集（SCADA）系统。参与 SCADA 系统的工程师们正在使用 Java 开发软件，并且使用 Maven、Subversion 和 Eclipse 工具。我开始在空闲时间研究软件开发，学习新的编程语言和工具。等到我对编程有了一定的信心后，我开始申请同一家公司内的软件工程师职位。最终，我拿到了我的第一个软件工程师职位。

软件工程非常有趣——总是有新东西可以学习，总是有挑战需要解决。我很快就能掌握新的编程语言，并希望能接触到更为多样化的代码库。另一个让我感到困惑的问题是如何平衡工作和生活，或者说，是工作和生活的不平衡。我住在明尼苏达州，但需要经常通勤到北达科他州西部。我认识几位在联合健康保险公司工作的人，他们一直鼓励我申请工作。我申请了大约六个我认为自己比较适合的软件工程师职位。

我还申请了一个技术敏捷教练的职位，这个职位的描述听起来很吸引人，但我觉得自己并不完全符合要求。我没有使用敏捷开发的经验，也没有做过教练或接触过 DevOps 的经验。最后，我还是拿到了这个职位！作为一名技术教练，我的工作是与团队合作，帮助他们进一步推进 DevOps 实践。直到第一天的到来，"不知所措"都不足以形容我当时的心情。在每个清醒的小时里，我都在学习 DevOps 和技术实践，但随着我了解到这个领域的复杂性，我变得越来越沮丧。第一天，我的经理坐下来对我说：

"我知道你没有 DevOps 或敏捷开发的经验，曾有比你更合适的候选人，但你之所以被选中，是因为你渴望学习、渴望进步。"

这位个人最终成为了我认为的第一位导师。在这位导师的指导下，我不仅提升了自己的技术能力，还提高了软技能。这个人帮助我变得更加自信，并鼓励我参加演讲俱乐部 Toastmasters 来提升我的公共演讲技巧。当我离开他们的团队时，是为了迎接一个新的挑战——也就是建立并领导属于我自己的 DevOps 团队。

前面的故事是一座信息宝库；你们中的一些人可能错过了一些要点，我们来逐一解析。

保持正轨，但要追随你的兴趣

在大学时，我的学位课程并没有让我有机会修更多的软件课程，因此我决定在自己的时间里跟进这方面的知识，且不影响我完成学位的时间。这并不是总能做到的；有时候，你需要全力以赴。除非我对某件事情非常确定，否则我通常会在做决策时有所保留——也就是说，我会继续平行进行已经有效的工作，同时尝试新的想法/流程。一个显著的例子如下：

图 10.1 – 合理利用你的时间

在上述例子中，这位个体的工作是软件分析师，但他们希望转向一个薪水更高的软件工程职位。他们听说了软件训练营，并考虑辞掉工作去参加为期六个月的训练营。我强烈不建议这样做；首先，你毕业后并不保证能找到工作。你可能经历过训练营，但出来后却找不到工作。第二个原因是，如果没有可靠的工作机会，你离职后将背负数万美元的债务。我建议你留在当前工作岗位，利用公司提供的学费报销机会。用这些资金来参加编程课程、获得认证，甚至追求在线学位。此外，即使你的公司不提供学费报销，你也可以通过自学和研究来提升自己。想想你花在看 Netflix 和玩视频游戏上的时间；将这些时间的一部分用来学习新知识，这些知识将帮助你找到下一个工作。我尊重那些自学成才的候选人，也与许多持有相似观点的领导者交谈过。

生活忙碌；优先考虑并专注于对你重要的事情

在大学时，我非常忙，老实说，忙得有些过头。我在滑雪巡逻队做志愿者，修了 16 个学分，做兼职，还想有点社交生活。直到在机器人实验室，我才意识到，如果我想交出一份自豪的演示，我需要重新优先安排我的时间。在其他实验室，只要能得到好成绩，我交出的东西就算不是最好的也无妨。但我对机器人实验室非常感兴趣，决定想从中获得最大收获，以便将来能在职业生涯中加以应用。我把实验室放在首位，牺牲了加入滑雪巡逻队的机会。另一个例子可以在以下图示中看到：

图 10.2 – 重新优先安排你的时间

如你所见，一天的时间是有限的；你还应该尽量保证充足的睡眠，并需要投入时间工作，以便能继续保持良好的表现。这些都占用了你的时间，剩下的自由时间由你掌控，你可以决定如何利用这段时间。我建议你坐下来，确定哪些方面可以被剪掉或缩减，从而腾出时间去做你希望优先安排的事情。

机会往往伪装在一个骗人的外表下。

在本节开始的例子中，我谈到过我曾经担任制造工程师的职位，因为我知道我将有机会与自动化与控制系统部门合作；未曾提及的是，我花了很多时间通过实习了解公司，才发现了这个机会。这在我的职业生涯中发生过好几次；有些情况下，我提前做了研究并做出了正确的决策；而有时，我错过了一个极好的机会。举个例子，看看下面的图示：

](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/dop-crr-hb/img/Figure_10.3.jpg)

图 10.3 – 超越表面看到的东西

上述例子是为了举例说明而做的极端案例，但事先做足研究、再决定重大事件的逻辑依然适用。

有时候，做内部职业转换比同时更换工作和公司要容易。

当你为一家公司工作时，很可能你与管理层建立了良好的关系。如果你决定追求另一条职业路径，通常建议你先与当前雇主沟通。在这个例子中，另一条职业路径指的是远离你当前从事的工作类型。我们用一个例子来展示这个转变：一名软件工程师转行做 DevOps 工程师。

](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/dop-crr-hb/img/Figure_10.4.jpg)

图 10.4 – 内部与外部职位变动比较

我在这里并不是想说——申请外部工作不是一个好的选择。申请外部工作过去曾多次对我有效。有时候，申请内部职位会显示出更快且更有利的结果，如前面的图示所示。

转向新职业路径需要新的技能——这些技能你可能已经具备，但除非有人亲自了解你，否则这些技能不会显现出来。这也是内部转岗有时更容易的原因之一。另一个原因是，内部职业转换可以分阶段进行，或者作为一个计划的一部分，如果你与领导层讨论过这些变动。最后，内部推荐对于申请职位来说是宝贵的。如果你能申请一个职位，并且有几个人可以推荐你，得到该职位的机会将呈指数增长。

申请你感兴趣的职位，即使你没有满足所有要求。

申请你真正想要的工作，而不是你完全符合要求的工作。这通常是无效的，但我和我的许多同行通过这种方式找到了工作。使用自动筛选机制的公司如果你没有满足所有要求，会将你筛掉；绕过这个问题的一种方法是，在简历中不仅写出你在工作中使用相关软件的时间，还要包括你在个人项目中使用这些软件的时间。作为一名招聘经理，我是不会因为你缺少两年使用某种语言或工具的经验就忽视你的。

为工作设置年限经验要求的问题在于，这只有在每个人都按相同的速度学习时才有效。然而，大多数招聘经理都清楚这一点并非如此。

面试过程中需要避免的事项

在上一节中，我讲述了我的成功经历以及这些成功如何帮助我进入 DevOps 领域。现在，我想用几页纸回忆一下我的失败经历，或者更准确地说，是我尝试找工作时的失败。首先，我们将回到 2008 年。

申请职位时，避免提供不准确或具有误导性的信息

错误信息让我失去了一份工作。

在大学的三年级时，我开始寻找实习机会。我申请了一份要求申请者正在攻读计算机科学学位的工作；而我当时正在攻读工业工程学位。当问卷中问到是否目前就读计算机科学专业时，我回答了“是”。一周后，我接到了招聘人员的电话，我们开始讨论这份工作；这次讨论非常简短，最后我收到了一份技术能力测试的链接。我在测试中的表现应该还不错，因为我顺利进入了下一轮面试，那是现场面试。公司为我支付了机票费用，并为我安排了酒店住宿。我需要带着成绩单到现场，我在第一次会议中与面试官一同查看了它。接着，面试官问了我一句，我以为你是计算机科学专业的学生？ 不用多说，这次面试以我的自尊心受挫而结束。如果我遵循申请工作时的黄金法则——始终提供准确的信息，这场碰面本来是可以避免的。如果我当时直言不讳，我或许仍然能获得这份工作，但因为我在最初的申请中没有诚实以对，我最终被列入了“拒绝名单”。

应始终遵循的一条规则是，申请工作时要诚实，包括在你的社交资料上。在我的案例中，我是故意提供了虚假信息，但无意间提供错误信息的后果可能一样。在回顾时，有一个词能描述我所做的：自私。我选择了将自己的需求置于公司要求之上。这样一来，公司浪费了时间和金钱面试我，安排了我的机票和酒店，这是一种严重的背叛。当他们发现我故意提供虚假信息时，信任完全破裂。如果我诚实一些，或许我会有机会。避免在不了解职位要求的情况下参加面试。

你甚至看过职位描述吗？

一位候选人通过了我团队 DevOps 职位的招聘筛选，并迅速进入了面对面的技术面试。每当我问他一个问题时，他都回答说自己用 Python 解决过类似的问题。面试结束时，我给了这位候选人以下反馈：

尽管你在使用 Python 方面似乎非常有经验，但我们更倾向于寻找一位在 Golang 上有更多实际经验的人；你愿意分享一下你使用 Golang 的经验吗？

候选人如实回答，除了进行一些轻微的代码修改外，没有使用过 Golang 的经验。不幸的是，候选人没有得到这份工作，如果他们完全阅读了职位描述：高级 DevOps 工程师 – Golang 经验，本可以节省时间。

在前面的例子中，如果候选人能花更多时间研究职位和要求，而不是立刻投入准备，他本可以避免尴尬的对话。显然，这个人是一个优秀的工程师，但在给定的团队中，能够在 Golang 上指导他人是职位描述中提到的一个要求。如果职位描述不清晰，或者你对某些事情不确定，完全可以向招聘人员询问。

有四个方面是你必须在面试前做好准备的：

• 文化：了解公司的文化将帮助你通过招聘人员的初步筛选。如果你能展示如何加强公司文化，这可能会成为你获得这份工作的决定性因素。

• 技术需求：这是必须的。如果你无法展示出你对团队所需支持领域的扎实理解，你将无法获得这份工作。

• 行业：如果你正在申请金融行业的工作，至少应该了解一下该行业。在最理想的情况下，你已经在该行业工作。

• 二级职责：这些是你将与之合作的团队，他们需要额外的知识，超出了你直接工作所需的内容。

在接下来的部分，我们将讨论与招聘人员沟通不畅可能带来的职业毁灭性后果。

避免在申请职位后忽视招聘人员的回复

未回复。

在石油和天然气行业工作时，我与招聘人员进行了初次面试，随后我去了为期一周的工作旅行，之后又度过了一个星期的假期。

在我旅行和度假期间，我忽略了检查邮件，错过了招聘人员的两次电话。当我最终回归现实时，我联系了招聘人员，得知我不再被考虑这个职位。说实话，我差点忘记了这事，但这也给我上了一课，希望我能传授给你：

申请工作时，始终制定沟通策略。

在我的例子中，我本可以设置一个自动回复，说明我在旅行回来之前无法回复邮件。这样，招聘人员更有可能给我更多的时间来回复。更好的做法是，提前告知招聘人员你即将到来的工作和个人计划，以避免任何混淆。面试后，如果你决定不再对某个职位感兴趣，要做出礼貌的回应，并告知招聘人员你不再感兴趣，这样可以为未来可能出现的机会保留关系。在申请工作时，遵循LinkedIn、电子邮件和电话（LEP）协议非常重要，具体如下图所示：

Figure 10.5 – LinkedIn、电子邮件和电话跟进协议

上面的图表展示了与招聘人员初次接触后，能够提高成功机会的做法。接下来，我们将讨论跨平台一致性信息的重要性。

避免社交档案与简历之间信息不一致

在 LinkedIn 上，你会遇到一些个人资料上夸大职位头衔、看起来无所不能、并且能说六种语言的人的资料：

Figure 10.6 – LinkedIn 与现实

上面的例子是一个夸张的版本，展示了你可能会遇到的情况，但它也应该鼓励你，并告诉你要保持积极心态——大多数人的情况并不像他们社交资料上所写的那样光鲜。夸大自己在 LinkedIn 和其他社交平台上的形象，可能会对你产生不利影响，尤其是在你申请工作的时候。

夸大的信息能让你引起注意，但一旦完整的故事被揭示，你的声誉将会受到影响。

到目前为止，我们已经讨论了你应该避免做的一些事情，以提高面试后获得积极结果的机会。接下来，我们将讨论你在面试过程中应该做的一些事情，以提高获得工作的机会。

面试过程中的注意事项

在我参与的许多面试中，无论是作为面试官还是面试者，我遇到了一些出乎意料的积极因素，对整个过程产生了意想不到的积极影响。在本节中，我将介绍其中的几项。

讨论你的副项目

并非所有的副项目在你面试 DevOps 职位时都有分量；比如你的岩石收藏在面试中几乎没有任何意义，但如果你用 Raspberry Pi 创建一个能够区分不同类型岩石的 AI，那就很酷，应该提及。在讨论时，你可以根据情况和判断来决定你的项目是否具有意义。

你对智能家居感兴趣？我也是！

我曾参加过一个技术主管职位的面试，并顺利通过了初步面试和技术面试。在一次最后的跟进面试中，我被告知现在只剩我和另一个候选人了。那次谈话比之前的讨论更加轻松，招聘经理告诉我他一直在升级自己小屋的互联网连接，以便能够支持更复杂的智能家居。

我抓住这个机会开始讨论我正在进行的智能家居项目。我不认为这是我获得工作机会的决定性因素，但它也没有削弱我的机会。

我能够讨论无线拓扑结构和 C 编程语言等话题，因为我提到了我的智能家居副项目，这些本来可能会被忽略，因为它们不是我的简历中的内容，也不是我在专业工作中从事的事情。如果你正在寻找 DevOps 领域的第一份工作且缺乏实际经验，讨论你的副项目变得尤为重要。讨论副项目会让面试官看到你对 DevOps 感兴趣并渴望学习新知识。

充分准备，准备讨论工具替代方案

DevOps 工具来来去去——这就是现实。如果你有使用 GitHub 的经验，而公司使用的是 GitLab，不必担心！准备好讨论这两者的相似之处和不同之处；向面试官展示你做了功课，了解了这个工具。下表展示了在面试过程中可以互换使用的工具：

图 10.7 – 工具替代

有时公司对候选人有硬性工具要求，但更多时候，如果你使用过类似的工具，相关知识会被视为可转移的。云服务提供商有着多样化的工具集合，并且在某些情况下要求广泛的知识和认证，这也是为什么这些技能集可能不被视为可转移的原因。

如果公司愿意为您面试与 Azure 相关的职位，而您只有 AWS 的工作经验，请确保准备好讨论这两个供应商之间工具的关系。在这种情况下，一个有用的资源是下图，首次讨论见于第三章，高级 DevOps 实践者的专业技能：

图 10.8 – 云等效性

这个想法几乎可以应用于任何工具或流程；另一个适用的例子是，当工作要求具有 GitHub 经验时，使用 GitLab 的经验也同样适用。这两者在仓库功能上都提供了类似的功能；只需准备好讨论 GitLab 还具有 GitHub Actions 所不具备的内置 CI/CD 功能。

总结

在本章中，我们涵盖了所有必要的变更，以确保您向潜在雇主展示最佳自我。我们讨论了拥有完整和专业撰写的 LinkedIn 个人资料的重要性，并提出了如何提高被潜在雇主注意的建议。接下来，我们介绍了如何更新您的简历，以便自动化系统和人类能够快速看到关键信息。然后，我们介绍了拥有个人网页的重要性，并演示了如何在 GitLab 上创建 Hexo 网页的教程，以及您的武器库网页应包含的部分。最后，我们介绍了其他社交网站，虽然不是必需的，但可以增加您被招聘人员注意的可能性。

在下一章中，我们将讨论网络建设的重要性，以及如何在 LinkedIn 和会议上进行网络建设。

第十一章：与 DevOps 从业者的访谈

如果你从头到尾都跟随了本书的内容，抱歉，老实说，我希望你从中收获了很多有价值的信息。本章的总结是基于我与实际同事以及我采访过的人的对话。

本章将涵盖以下主题：

• 与资深 DevOps 经理的访谈

• 与资深 DevOps 工程师的访谈

• 与 DevOps 架构师顾问的访谈

• 与一位热衷于神经多样性和包容性的技术高管的访谈

通过阅读不同经验层次的人的观点，你可以形成更全面的了解，知道在寻找下一个 DevOps 职位或尝试获得第一个 DevOps 工程师角色时应该期待什么。

与资深 DevOps 经理的访谈

我采访的第一个人恰好也是这本书的合著者，约翰·奈特。约翰最初怀着成为游戏设计师的美好愿景开始他的职业生涯。20 年后，他成了一个杰出的工程领导者：

](https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/dop-crr-hb/img/Figure_11.1.jpg)

图 11.1 – 约翰·奈特的个人简介

记者：嗨，约翰，谢谢你同意今天下午与我见面，讨论你作为 DevOps 领导者的职业生涯！

约翰·奈特：没问题。

记者：首先，请告诉我们一些关于你自己的事。

约翰·奈特：我是约翰·奈特，我是一名具有 16 年 DevOps 经验的工程经理，拥有 9 年云计算经验和 5 年团队领导经验。我曾为 8 家财富 500 强公司工作并提供咨询服务，并获得了三大公共云提供商的多项认证。在我的空闲时间，我收集硕士学位。

记者：听起来是个成功的职业生涯！在继续之前，能否谈一下你提到的收集硕士学位的说法？

约翰·奈特：我目前拥有三项硕士学位，并正在攻读第四个学位。我抱怨自己没有太多时间，但我从不允许自己不在学校里；我是一个知识怪。

记者：有意思；我们稍后再回来谈这个问题，但现在能不能告诉我们你是如何进入 DevOps 领域的？

约翰·奈特：我曾是一个游戏开发者，或者说是尝试成为游戏开发者。我曾参与过两个独立的 MMO 开发，后来被从游戏开发领域招募了出去。结果发现，部署和修补游戏所需的技能，恰好也是部署和修补软件所需的技能。这就是我进入这个领域的原因。那时，首席架构师太忙，无法亲自进行部署！16 年过去了，我依然感谢他。

记者：16 年，哇。你在这个领域遇到的最大变化是什么？你是如何确保自己保持相关性的？

约翰·奈特：我 10 年前使用的技术大多数现在已经不再相关。你必须跟上技术的进步，并从专家和创新者那里获取知识，做到持续改进。成为一个持续学习者是非常重要的。

记者：你谈到过自己是一个硕士学位的“收藏者”，并且如何持续学习帮助了你；我开始看到一些模式了。你能否展开讲讲持续学习在 DevOps 领域的重要性，以及它如何影响了你的职业生涯？

约翰·奈特：我 15 年前使用的技术，甚至 10 年前使用的一些技术，大多数已经过时。对于一个新来的人来说，完全不需要调查过去 15 年的领域发展，过去 5 年就足够让他胜任，甚至在一些领域更少。持续学习让你能够不断提升自己的技能，即使别无他法，它也能帮助你保持创新，尤其是当你学习自己专业领域之外的知识时。真正的飞跃来自于将原本毫无关联的领域结合在一起。现在很难做到这一点，因为信息量巨大，无法了解或学习所有内容。所以，持续学习让你能够逐步掌握知识，并使其变得更加容易。就影响力而言，我拥有比其他类似候选人更广泛的背景，这使我在竞争中占有优势。任何你能通过获得更多知识、证书等方式使自己与众不同的做法，都会在长期中对你有帮助。知识是复利增长的。

记者：在你的职业生涯中，有没有遇到过挫折或意外的变故？

约翰·奈特：至于挫折或意外的变故，它总是发生在一个动态变化的环境中。曾几何时，我大多在 Windows 系统中工作，突然间，我转向了 Linux 世界。在某一时刻，容器技术被引入了，还有基础设施即代码。你必须适应，否则就会停滞不前。游泳或沉没。

记者：哇，刚才那段话中有很多有价值的信息。接下来，我想谈谈你是如何、何时以及为什么决定转型为领导者，而不是继续走个人贡献者的道路。

约翰·奈特：转型为领导者可能很困难，因为每个人都希望看到经验，但必须有那个第一次机会，尽管你没有经验，而给予你机会需要信任。在我看来，我有几个原因想尝试。首先，我认为这是一个合乎逻辑的职业发展方向，能够为我的职业生涯带来更多的机会。其次，我受到好的和坏的经理们的启发，想要运用我学到的经验，做出不同的改变，在我认为能做得更好的地方做到最好。

在我的团队中，我也鼓励每个成员关注学习、培训和提升自己的专业水平，并且你可以看到我们从开始合作到一年后的显著进步。

我还有很多需要改进的地方，但我觉得在这些领域的提升不仅有利于我的工作，也有助于我生活和事业的其他方面，所以这是一种双赢的局面。

至于如何过渡，我当时选择从事咨询工作，以便在不需要永久加入公司员工的情况下与高知名度的公司合作。这使我能够从外部视角看待他们的业务，并加强了我的人际交往能力，因为他们是客户，而我现在是面向客户的。

做了几年之后，我加入了一家小公司，管理他们的 DevOps 团队和相关工作。我发现作为一名顾问，除了技术知识外，最重要的技能是影响他人。当你没有权威时，必须依靠外交手段、魅力和谈判技巧来获得你想要的东西。在成为经理之前学习这种技能，能够帮助你成为更好的领导者。

记者：影响他人——我也认为这在我作为更资深的个人贡献者时很重要。还有哪些技能是可以转移的，又有哪些技能是完全不同的？

约翰·奈特：导师的能力在于帮助他人提升，使周围的人变得更好。一位经验丰富的工程师是初级工程师的催化剂，可以帮助他们更快地达到目标。在管理方面，能够合理地优先排序工作并分析相互竞争的优先级是关键能力，但几乎每个人都能从这一领域的优势中受益。领导力与管理不同。领导力在于拥有责任，并为结果负责。即便是初级员工也应该努力成为领导者。

在管理中，你必须进行大量的谈判；你需要运用外交手段避免那种“赢得了战斗却输掉了战争”的局面。管理多团队之间的人员预期是非常重要的。作为一名个人贡献者，你往往更专注于你所在的团队。

记者：您对正在寻找导师的初级工程师有什么建议？

约翰·奈特：我认为我们应该始终尝试模仿身边积极的榜样。这样，我们能够进步，并受到那些在某些方面拥有我们所缺少的能力或卓越表现的人的影响。与团队中资深成员建立良好关系，也为潜在的导师机会打开了大门。

你还可以请求你的直接上级在你的职业发展中发挥更积极的作用。导师无处不在。

记者：我们许多人都有一个问题，想问您关于招聘的过程；能否先跟我们说几次候选人在面试过程中没有交付的例子？

约翰·奈特：通常在面试筛选时，我会看经验、文化适配性和团队契合度，以及一些软性的人际交往技能。我希望找那些能与他人合作顺畅的人。有些人过于关注薪资，夸大自己的技能，或表现出缺乏热情。

有一次，我有两个候选人，我给两人都抛了一个挑战；一个是临时的问卷要求他们填写。一个第二天就回来了，并且态度积极。另一个则因为这个突如其来的障碍感到沮丧。第一个人得到了这个职位。

我的招聘运气不错，我仍然在不断更新我的面试流程。

记者：John，你能否为我们深入介绍一下你过去使用过的其他技术评估方法？另外，你认为哪些方法能为你提供最有价值的候选人洞察，并且你在审查技术挑战时关注的是什么？

John Knight：评估技术专长有很多方法。通常，我专注于经验。你用你声称掌握的技术解决了什么问题？我通常假设他们告诉我的信息是准确的，然后只是寻找经验。这让我能够同时评估多个维度。有时，你还能了解一个人的性格特征，比如他们是否善于合作，还是像孤狼一样独立工作等等。

传统的技术能力评估标准很有用，但通常我把这些留给其他面试官。编程熟练度、系统经验、云技术专长——这些都是很容易测试的基础知识领域。我不想知道你能否定义某个概念。你可以查阅任何定义。我想知道你能独立创造些什么，以及你知识和技能的边界在哪里。我特别寻找能补充我现有团队的能力，所以拥有多种技能总是很棒的。

记者：谢谢 John，只有几个问题了。回顾你的职业生涯，有没有什么特别的事情你希望自己能做得不同或避免的？

John Knight：我根据薪酬需求而不是基于我真正想做的事情或是否对公司的工作感兴趣来换了岗位。我会建议避免这样做，尽管我理解财务因素在每个决策中都起着关键作用。有时，我希望自己能勇敢地选择一份薪水较低的工作，在我热衷的公司或产品中工作。无论如何，我的选择为我带来了良好的职业生涯和结果，所以我非常幸运。

我可以做得不同的其他事情包括在接受工作之前更多地考虑文化契合度。我曾在几个工作环境恶劣的地方工作过，虽然没有任何一个问题或面试是万无一失的，但作为候选人，你也应该对公司进行尽职调查，确保他们的做法与你的信念一致。

记者：最后一个问题，John——我读过你一些关于 AI 和未来技术的作品；你认为 AI 会在未来影响 DevOps 领域吗？个人应该如何为 DevOps 的未来做好准备？

John Knight：不完全是人工智能，而是人工智能辅助自动化和机器学习。有两个交集。一个涉及使用 DevOps 将 AI 或 ML 部署到生产环境中。这被称为将 AI/ML 落地或 AI/MLOps。

另一个交集是使用 AI 代理自动响应事件，或使用 ML 对将要发生的事情进行预测，或者提供推荐。这个领域充满了创新的机会。我认为自动修复服务的代理，比如站点可靠性工程师（SRE）代理，如果现在还没有存在的话，应该很快就会出现；智能测试自动化，智能资源分配，AI/ML 在威胁防范、检测、修复等方面的应用。

为了做好准备，你必须开阔视野并不断学习。云服务商很擅长教你如何使用他们的服务，但你必须理解底层的知识，才能最大化地利用它们。幸运的是，我们生活在一个学习资源丰富的时代，我们可以在线上参加世界顶尖大学的课程，可以在瞬间以最低的成本获得任何信息。说实话，如果你能接入互联网，就没有什么是你不能开始学习的。这是一个令人惊叹的时代。

记者：确实如此，John。感谢你抽出时间与我分享你的见解，我期待再次与您交流。

与一位资深 DevOps 工程师的访谈

我采访的第二位个人是Veeral Patel。Veeral 是我有机会聘请为 DevOps 工程师的第一份工作的个人：

图 11.2 – Veeral Patel 的简历

记者：下午好，Veeral，感谢你同意坐下来和我讨论你成为 DevOps 工程师的历程。

Veeral Patel：谢谢，Nate，没问题！

记者：在我们开始之前，你能分享一下你的背景信息吗？

Veeral Patel：当然！我在教育方面的背景是软件工程和数据科学。在实际工作中，我在科技行业工作了 4 年。在技术经验方面，我做过 React 和 C# 的全栈开发，使用 Python 进行脚本编写，并在 Jenkins、GitLab 和 Azure DevOps 上做过 DevOps 自动化工作。

记者：你是何时发现自己对技术产生热情的？是什么决定性的时刻让你知道自己想编写代码？

Veeral Patel：我知道我想编写代码是在大学时选修计算机科学入门课程时，那是我唯一会定期参加的课程，即使它是大一的早上 8 点课。

记者：哈哈，所以你知道这是你的志向，所以才值得投入精力；我喜欢这个！在大学期间，你有做过实习吗？如果有的话，是哪些实习？能详细谈谈你的职责和学到的东西吗？此外，你的实习是否对你之后所选的课程或学习内容产生了影响？

Veeral Patel：我做过——我曾在Medicon Health做过实习！在那时，我从事软件测试工作，我们做的是集成测试，我使用了一款叫Applitools的工具。那时我学会了如何从网页浏览器中找到元素，并编写脚本来点击这些元素并进行数据验证。这次实习并没有影响我所选的课程，因为我选修了完成学位所需的必要课程，以便尽快毕业。

记者：你觉得你的实习对你毕业后找工作有影响吗？此外，毕业后你第一份工作是什么？你在本科毕业后直接去攻读了第二学位吗？

Veeral Patel：大学毕业后找工作并不困难。在毕业前，我就收到了几个工作邀请，因此我选择了提供更高薪水的公司。我毕业后等了一年才去攻读第二学位，这样我的雇主可以为我支付一部分学费。

记者：听起来是个聪明的财务决策！你会给即将找工作的软件工程专业学生三条建议吗？

Veeral Patel：首先，我鼓励学生们继续学习现代技术——科技世界变化太快，你需要在工作日抽出时间来学习。

第二，如果你不会为了那份工作而去做，即使它的薪水只有一半，那说明你对这份工作并没有那么热情。没有激情，很难在科技行业取得成功；这里竞争激烈，每个人都很聪明。

最后，如果你不开心，就不要害怕辞掉工作——外面的机会太多了，不必被困住。

记者：这真是一个非常有价值的建议，如果大家能遵循这个建议，肯定都会受益。我想换个话题，讨论一下你是如何从软件工程转到云 DevOps 工程的。

Veeral Patel：我从软件工程转到 DevOps，因为我喜欢能拥有某些管道、项目或计划的控制权。作为一名软件工程师，我曾是一个团队的一员，负责维护或创建应用程序；我只不过是一个大齿轮而已。而在 DevOps 中，我能负责某些项目并全权掌控它们。而且，我能接触到很多创新的技术。例如，在 DevOps 中，我能涉及到 AWS、Terraform、Ansible 等技术。而在软件工程中，我可能会被困在 Java 上工作多年。

记者：我们应该把这个做成海报——进入 DevOps，这样你就不会被困在做 Java 多年了。这听起来像是我进入 DevOps 的原因——我想从事酷炫的技术工作。当你第一次面试我团队的 DevOps 职位时，你对学习和吸收知识的渴望是你超越其他具备相似技能的候选人的原因；你能告诉我在你的职业生涯中，这一特质在哪些方面带来了回报吗？

Veeral Patel：这种学习能力和渴望吸收知识的态度在学校里也取得了回报；我一直认为正规教育非常重要，我认为我有几个学位的原因就是因为我渴望学习。我能够讨论各种技术，因为我至少花时间研究过它们，所以面试变得容易得多，而且我从不担心自己会在不太了解的任务上担任志愿者。

记者：Veeral，你能描述一下你希望聘用的完美团队成员吗？他们应该具备什么样的品质？

Veeral Patel：完美的团队成员是一个喜欢分享想法且不介意接受新挑战的人。我总是喜欢听听其他人的观点，仅仅这样就能激发思维的流动。具备技术能力当然很重要，但学习的意愿同样重要。

记者：你还拥有数据科学的高级学位。这个知识如何补充你传统的 DevOps 技能？你有具体的例子吗？

Veeral Patel：拥有数据科学学位让我对管道和数据流动的可能性产生了许多想法。我常常思考某些数据或管道在分析中会有什么价值，或者当前不可轻易获得的数据可以用来做什么。当我在医疗行业工作时，我常常思考有多少未开发的数据仅仅是进入数据库后，显示在用户界面上，并没有进行任何实际的分析。

记者：感谢你的时间，Veeral——我期待着再次和你交谈。

DevOps 架构师顾问访谈

有些人对你产生影响。Chris Timberlake就是对我有影响的人之一。从我第一次参加与他一起的会议时，我就能感觉到他是一个我能从他身上吸收知识的人。这在我们共同为 GitLab 实施项目的过程中得到了验证：

图 11.3 – Chris Timberlake 的个人简介

记者：感谢你，Chris，愿意和我讨论你的 DevOps 之旅。在开始之前，你能介绍一下自己以及那些经历如何带领你走到今天这个位置的吗？

克里斯·廷布雷克：谢谢你邀请我，内特！我很小的时候就开始接触计算机——在我不到 10 岁的时候。我从做 GeoCities 网站和为 Yahoo Messenger 开发启动工具开始，随后转向基于 Half-Life Source 引擎的电子游戏编程。这些经历是我接触编程的起点。从那时起，我就一直沉迷于此。我曾短暂地转行去从事执法工作。后来，我回到了编程领域，并通过一系列事件在 Red Hat 参与了大规模的数字化转型项目。现在，我在 GitLab 担任专业服务架构师，帮助推动数字化转型。

记者：等等——你是技术专家，同时也是执法人员？真了不起！你认为自己是一个 DevOps 工程师吗？你能解释一下你如何区分 DevOps 工程师和软件工程师，还是说它们是一样的？

克里斯·廷布雷克：我确实认为自己是一个 DevOps 工程师，但我也认为自己是一个不错的软件工程师和系统管理员。我可以在不同的角色之间灵活切换。以前，在 2015 年，我会说 DevOps 工程师只不过是拥有系统管理员能力的软件工程师。然而，随着云市场的发展，DevOps 领域已经有了显著的成长和变化。今天，我认为 DevOps 工程师是一个独立的角色。现在，DevOps 工程师是负责自动化和交付流程的大部分管道工作。

记者：克里斯，你在工程和 DevOps 领域看到了许多不同的面向。你能解释一下作为顾问在 DevOps 领域工作和直接为公司工作之间最大的区别吗？

克里斯·廷布雷克：最重要的一点是你的角色。作为一名顾问，你必须拥有完全不同的思维方式和不同的责任。作为顾问，你应该是该领域的领导者，一位教育者，别人向你请教问题并寻求解决困境的帮助。你还必须协调旅行、费用、待命，并且在不同的环境中工作——有时甚至没有必要的工具。作为顾问，你的任何角色都会更具挑战性。例如，作为员工，你不必太担心确保自己在下午 6 点赶到亚特兰大，搭上前往达拉斯的航班，晚上 10 点转机，再赶到旧金山参加早上 8 点的会议。

作为员工，你关心的事情要少得多。我认为作为 DevOps 顾问是两种截然不同角色的结合。一方面，你是为 DevOps 工程做出贡献的个人；另一方面，你是一个出差的领导者或老师，负责向他人传授相关知识。

记者：谢谢你，克里斯。接着问一下，你认为咨询角色适合那些想要开始从事 DevOps 工作的人，还是说这个角色只适合专家？

Chris Timberlake：这两种情况都适用。更多的是关于决心以及在压力下保持冷静的能力，而不是单纯的知识。当我开始我的咨询生涯时，我当然不是所有领域的专家。即使到今天，我仍然会被问到我并不擅长的事情。但面对不确定性时，我确保自己能去为别人找到答案。我确保自己在处理当前问题时不断学习，同时保持清晰的思维。成为一名顾问让我学到的其中一件事是，除非我能可靠、准确并且适当地为某个问题提出正反两方面的论点，否则我就不能真正理解一个解决方案或话题。做顾问是一份压力巨大的工作，肯定不是每个人都适合。它更多是关于你如何工作，如何应对角色带来的压力，甚至是如何享受这份工作的。

记者：谢谢你，Chris，我觉得我们的读者在规划自己的 DevOps 职业生涯时会发现这些特别有用。我想换个话题，谈谈开源。你曾经工作过的至少两家公司被认为是开源软件的先驱——GitLab 和 Red Hat。许多人还认为它们是 DevOps 领域的主导者。你能分享一下你对开源与 DevOps 之间关系的看法吗？

Chris Timberlake：我的意思是，软件的未来显然是开源的。这不是秘密。从历史上看，许多 DevOps 工具和模式都来源于开源项目。人们会自发地组织起来一起做一个项目，然后，啪——你就有了一个被许多人甚至企业使用的新产品。有些人可能觉得开源是有益的，因为它让一些可能无法参与软件开发的人也能够参与其中。

开源的真正力量在于透明性、协作性，最重要的是，开源还允许公开的冲突发生。这些都是打造伟大事物的关键。Red Hat 不仅仅是一家基于开源的公司；它将这些价值观融入到他们的工作和运营方式中。他们让员工保持自我，并且在很多方面对员工保持透明。Red Hat 能够成为迄今为止最大的一笔被收购的科技公司，价值达到 340 亿美元。GitLab 也将这些价值观深深铭记——不仅仅是在软件方面，而是在其运作方式上。这导致了该公司今年实现了巨大的 IPO（首次公开募股）。

开源倡导者提倡和鼓励的那些相同价值观推动了这两家公司走向了巅峰，我相信这些价值观将巩固 DevOps 成为未来所有软件和 IT 公司的必需品。这是因为 DevOps 也鼓励并实践着这些相同的价值观。

记者：我完全同意！现在，回到你刚才提到的 DevOps 价值观，你觉得对于 DevOps 专业人士以及那些希望进入这一领域的人来说，最受需求和最受欢迎的软技能是什么？

Chris Timberlake：我认为无论你处于什么职位，你都应该有成为领导者的愿望。当然，这并不意味着你必须成为经理或领导任何事务。但拥有类似领导者的特质会帮助你在职业目标上取得成功。有效的沟通技巧是必不可少的。清晰的信息传达和开放的沟通非常重要，不能被过度强调。自信也是一个重要的特质。

即使你必须“装作自己已经做到了”。我看到许多了不起的工程师因为冒充综合症而绊倒自己。我们都在这里尝试构建伟大的东西，我们都会遇到问题，也都会失败。最后，我认为接受失败、愿意冒着失败的风险，然后克服失败是非常重要的。每个具有强大软技能的工程师都有一段失败的故事。

我？我在一个下午为我所在的公司损失了 400 万美元的收入。能够从这些失败中进行反思和学习，防止它们再次发生，并在失败后构建更好的东西是非常重要的。因为每个人在任何职业中都会失败，重要的是你在失败后做了什么。

记者：如果你能谈谈你如何损失了 400 万美元的故事，我很感兴趣。发生了什么事情？你是如何解决这个问题的？此外，在这件事发生时，你的雇主是否有任何反应？他们的回应是什么？

Chris Timberlake：不幸的是，我不能谈论。我有隐私方面的顾虑。我要说的是发生了什么：我曾负责将一些软件发布到购物车系统中。它导致购物车功能出现了问题，虽然没有完全崩溃，但功能有所降低。因此，我们阻止了许多顾客完成结账，但又没有足够严重到触发自动警报和监控。

至于后果，绝对有。我必须写一份详细的文档，解释一切是如何发生的，并通过 5 个为什么方法进行深入剖析。然后，我还必须向公司的股东写一份声明，说明发生了什么，并向他们保证这种情况不会再发生。我要说的是，JavaScript 确实很酷，直到有一个小小的语法错误导致大问题。

记者：我明白了。我知道在工作之外，你的爱好也涉及许多与软件相关的工作。你能谈谈这些吗？你在工作之外的努力是否有助于你在工作中的成功？

Chris Timberlake：绝对是！我不会说我的外部工作成功对我的职业生涯有所帮助，但我的失败却有帮助！我做过大量的移动、游戏和桌面开发，这其实是在说我曾深入研究过构建工具链和第三方库中出现的问题。这也意味着我有机会接触到许多我正常工作中无法接触到的技术。

一个很好的例子是当苹果关闭了移动应用程序的编译功能，阻止任何应用能够动态编译代码。这导致了很多 MongoDB 库的崩溃：能够解决这个问题是一项艰巨的任务，但我从中学到了很多。我将这些经验运用到我日常的工作中。

然后，还有一些更有趣的“兔子洞”项目，比如在周末将 Quake 2 从 C 语言转为 C++ 编译器。这让我了解了部分 C 和 C++ 编译器的内部工作原理。并不是所有我的项目都涉及软件。我还是一个狂热的汽车爱好者。能够诊断和解决汽车或发动机中奇怪的电气问题，帮助我在工作中解决问题。这些经验也转化为软件方面的技巧。

记者：我不会再耽误你太久了，但我还有几个问题想问你。你对那些想进入 DevOps 领域的人有什么建议吗？

Chris Timberlake：我想说，如果你想进入 DevOps 领域，你应该花很多时间在副项目上，并积累大量知识。你的工作不会暴露给你所有需要学习的内容；你必须对这个领域充满热情。开发一个移动应用，做一个视频游戏，然后进行自动化。

记者：最后一个问题——技术变化如此之快。你能描绘一下 20 年后 DevOps 的发展前景吗？

Chris Timberlake：未来，我认为我们会看到两件事。首先，我们将看到 DevOps 公司之间的整合，因为为了争夺销售和市场份额，竞争将加剧。我们已经在疫情期间见证了巨大的整合。

与此同时，我们还会看到很多新公司诞生，某些人会提出新流程或新想法，然后尝试并从中建立公司。这与 GitLab 和许多新兴科技 IPO 的起步方式类似。这些变化是短期的；5 到 10 年内的事。我无法预测 20 年后的情形。一切变化如此之快，20 年后我们可能会拥有可穿戴的 VR 或《星际迷航》全息影像。或者，这些技术可能会像飞行汽车一样，始终遥不可及。

无论如何，我们将看到软件和 DevOps 领域中更多的透明度、合作和冲突。无论如何，我们都会变得更好。

记者：感谢你抽出时间，Chris，我期待下次我们讨论 DevOps 的所有话题。

采访一位热衷于神经多样性和包容性的科技高管

我采访的下一个人是 Magnus Hedemark：

图 11.4 – Magnus Hedemark 的个人简介

记者：嗨，Magnus，感谢你同意接受我的采访，讨论一下 DevOps。你能介绍一下自己吗？以及你在 IT 和 DevOps 领域的职业发展经历？

Magnus Hedemark：我进入 IT 的路径非常不寻常，这本身就是一个很长的故事。但我认为，在我的整个职业旅程中，有一件事始终对我有帮助，那就是尽量向前看，看看我如何能够在已知需求到来之前发挥作用。我喜欢弄明白事情是如何运作的，所以我没有从开发人员这边开始，而是进入了运维领域。我总是有能力搞清楚如何自动化那些庞大、复杂的任务，这样我就可以专注于更智能的工作。在我早期的职业生涯中，这在我的领域并不常见，和现在不一样。但在行业中有几个重大拐点，行业本身发生了变化，我的职业生涯也因此发生了变化：

• 行业开始转向敏捷开发。我在 IBM 的一个运维团队工作，那里一些来自巴西的优秀工程师每天围绕他们的工作聚集，并以一种在企业驱动的敏捷项目中很难见到的方式社交化地围绕工作。这让我非常着迷，也让我意识到自己在职业发展中缺少了什么。

• 曾有一位 CTO 把我拉到一旁，挑战我考虑走上领导岗位。我当时并没有完全认同这个想法，但他承诺会花时间与我一起了解什么是优秀的领导力，而这一点在我身上是缺失的。现在，我尝试成为那个对其他有领导潜力的人给予帮助的人。但我认为，当我年轻时，信息就是力量，工作安全意味着没有继任者。如今，信息渴望自由，优秀的领导者会不断培养潜在的继任者。

事实证明，我比起工程工作更喜欢领导（尽管我仍然在不断地构建东西以娱乐自己）。我从一个喜欢独自编程的天才混蛋转变为一个我希望更多人能认为是具有同理心并支持他人的领导者，重视协作。这一过程既是个人成长，也是职业发展的过程。

现在，我领导着超过 300 人的团队，管理着广泛的技术运营产品组合。

记者：哇，谢谢你，Magnus——这是个非常棒的回答！我想我不应该感到惊讶，因为我在 LinkedIn 上一直在关注你，想问一下以下问题：

• 对于那些希望在 DevOps 方向上提升职业生涯的年轻 IT 专业人士，你有什么建议？

• 其次，你对那些考虑转向管理岗位的资深 IT 专业人士有什么建议？

Magnus Hedemark：对于刚起步的人，我认为没有一个训练营能充分准备你。一直以来，我在这个领域合作过的那些最优秀的人，那些收入丰厚且需求量大的，都有几个明显的特点：

• 他们是非常好奇的人，总是学习新的技能来丰富个人生活，然后将这些技能应用到工作中。即使在高级领导岗位上，我每年也会将大约 10%的年终奖金投入到提升自己的技能。这可能是购买书籍或请教练。今年，我将这些资金用于支持一些 HomeLab 的升级，以便更深入地学习 Kubernetes。如果你刚开始接触 DevOps，一些基础的书籍可以说是这段旅程的起点……如果你还没有读过这些书，你就错过了很多你周围人正在理解的东西：

  • 凤凰项目

  • 持续交付

  • 敏捷宣言（它的阅读时间比这个回答还要短），但比这更重要的是，它背后的12 个原则

• 他们是非常有同理心的人。我之前提到过天才混蛋的范式，现在这种范式几乎没有立足之地。学会做一个好的倾听者，学会保持好奇而不是愤怒，都是非常重要的。有些人在这方面天赋异禀，而另一些人，比如我，则需要更加努力。不过，DevOps 不仅仅是酷炫的技术技能，它同样关乎文化影响。我认为学习Westrum 模型是我会特别提到的第一件事，它能帮助你确保培养一个高协作性的工程文化。我还认为，保持对技术领域中弱势群体文化敏感性的意识也很重要。同志支持指南是一个很好的起点。只要保持警觉和敏感——当我们确保包括不同背景和不同思维方式的人时，这些优势就会显现出来。但作为一种尊重，我们也需要投资去理解如何将他们纳入其中。

对于那些从个人贡献角色考虑转入管理层的人来说……我该从哪里开始呢？我想，如果你在之前提到的好奇心和同理心方面做得不好，我建议你考虑一下：这个领域已经有太多人缺乏这些关键特质，也许这条道路不适合你。理解从个人贡献者到管理者的转变并不是晋升；更像是一个横向的转变，进入完全不同的职业轨道。例如，仅仅为了让你了解我所在的公司，目前能够向高级经理汇报的最高级别的个人贡献者是高级员工软件工程师。尽管两者之间存在监管关系，但他们的薪资等级是相同的。当某人从高级员工软件工程师转变为高级经理（这并不罕见）时，最初会感到一些失望，因为他们并没有获得更高的薪资。即便你在管理层逐步晋升，你也可能会遇到技术高超的个人贡献者赚得比你多。我现在想告诉你，并且记住这一点，当这种情况不可避免地发生时——接受现实。在从个人贡献者转变为经理的过程中，薪资增长通常不会发生（在同一个组织内），但当你从经理晋升为总监（即管理多个经理）时，薪水才会显著增加。但问题是——你可以继续待在个人贡献者的角色，仍然通过晋升为首席软件工程师来获得更高的薪水。而且，你的汇报关系也会发生变化，因为现在你超过了你的高级经理，你将直接向他们的总监汇报。

所以，我觉得这一切归根结底都回到了这个问题。

如果你正在考虑转行，仔细思考一下你的动机是什么。并且思考你对这条道路的承诺程度。不要试图抱着“我还是会一半时间写代码”的心态。现实检查：你将不再写太多代码。如果你确实写代码，你实际上是在把其他工程师置于一个非常尴尬的境地，他们必须告诉老板他们的代码很差。就此放下，放下你自己，承诺成为一个出色的领导者。如果你只是想成为“带徽章的工程师”，这可能不是你正确的职业选择。

对我来说，我的动机是释放潜在的能量（在我自己、在他人、在团队、在业务线、他们的产品、他们的客户以及他们所处的社区中）。

记者：你手下有超过 300 人，这意味着你见过各种面试，既有好的也有不好的。如果不介意的话，读者们肯定会对哪些候选人脱颖而出，哪些又不合适感兴趣。

Magnus Hedemark：我想很多经验丰富的面试官会在我说的这句话上点头认同——大多数时候，你在前 5 到 10 分钟就能知道这个人是否是合适的人选或者完全不行。但我还是喜欢花更多时间，因为有时候，一个大满贯的候选人，随着你了解得更深入，可能会变成一个硬性的“否”答（但我不认为我见过面试走向反方向的情况）。再次强调，我认为在面试过程中要表现出大量的同理心和理解，毕竟这个世界上有很多种方式可以表现“正常”，而不仅仅是那些我们认同的人（亲和偏见）。因此，以下是我与人交谈时常常考虑的几个关键点：

• 他们是否客观上具备提升团队水平的硬技能？

• 他们可能会是团队的文化补充吗？（我不会面试文化契合度；那样你就会得到一个单一文化的团队。）

• 我会问一些问题，帮助面试者暴露是否存在违反不容忍混蛋原则的高风险，这对我来说非常重要，因为我负责培养优秀的团队文化。你不能让任何一个有毒的人进入你的团队，如果发现了他们，就不能让他们留下。

记者：感谢你，Magnus，感谢你的时间。我很享受我们的对话，我相信读者们也会一样。

概要

本章总结了与四位 DevOps 专业人士的访谈，他们的经验水平各不相同。我们有机会与 John Knight 交谈，他分享了招聘实践的见解，以及在招聘 DevOps 工程师时他看重哪些技能。DevOps 领导者还分享了一个人如何从个人贡献者角色转向管理者的经验。最后，John 为 DevOps 的未来做出了预测。

接下来，我们有机会与高级 DevOps 工程师 Veeral Patel 交谈，他分享了自己是如何进入 DevOps 行业的，并为正在找工作的学生提供了有用的建议。

Chris 分享了开源与 DevOps 之间的关系。Chris 采访中的主要收获是，DevOps 真正是一种思维方式，如果你想成功，就不能害怕失败。

最后，我们有幸与 Magnus 进行对话，他是一位在 DevOps 领域有着丰富经验的技术高管，并且为那些希望进入 DevOps 领域或转向领导岗位的个人提供了许多深刻的见解和知识。