技术面试问题分为两类：工具特定问题和概念相关技术问题。
工具特定问题如：“请谈谈Terraform的生命周期。它解决了什么问题，如何工作？”
而概念相关技术问题可能是：“你能描述一下你实现的CI/CD流水线吗？你是如何确保它可靠且可扩展的？”
本文将分享我在过去一年DevOps面试中遇到的10个概念相关技术问题。
回答面试问题时，讨论你面临的挑战以及如何克服它。挑战可以是任何事情：紧张的截止日期、项目中人力资源不足、缺乏知识和经验等。挑战越难，越好。
你也可以使用STAR格式 来回答问题。
STAR格式代表情境、任务、行动和结果。
- 情境：发生了什么？
- 任务：事故发生时你的角色是什么？
- 行动：你采取了哪些步骤来解决事故？
- 结果：你的行动提高了公司绩效并节省了公司资金。
以下是我在过去一年DevOps面试中遇到的10个常见问题。这些问题针对有2-3年经验的候选人。
1. CI/CD流水线
- 问题: 你能描述一下你实现的CI/CD流水线吗？关键步骤是什么，你是如何确保它可靠且可扩展的？
- 如何回答:
正如我在之前的文章中所写，描述你过去实现的CI/CD流水线的最佳方式如下：
- 绘制CI/CD流水线的图示。
- 为流水线创建良好的文档。
- 记住你记录的内容。
- 在面试中展示图示并讨论流水线。
- 解释为什么选择特定工具，有哪些替代方案，以及为什么拒绝它们。
不仅要回答问题，还要与招聘经理讨论。将面试视为对话，双方都会感觉像是在一起工作。
_如果你正在面试你的第一个DevOps职位，显然你没有经验。在这种情况下，你应该创建自己的CI/CD项目并在面试中使用。
<strong>2. 配置管理工具</strong>
- 问题: 你使用过哪些配置管理工具（如Ansible、Puppet、Chef），它们如何帮助管理基础设施？
- 如何回答:
我建议学习Ansible、Puppet和Chef之间的区别，并将它们作为回答的一部分。
例如：
“在我之前的工作中，我使用Ansible，但也考虑过使用Salt Stack或Puppet。我为每个工具做了概念验证，并向我的团队和管理层展示了结果。最终，我选择了Ansible，因为它有很好的文档，非常容易学习，不需要特殊服务器或代理，只需要ssh连接。
Ansible在我们的软件开发周期中发挥了关键作用。例如，我们有一个环境即服务平台（XXXXX），每个开发人员都可以使用该平台构建应用环境。在工具背后，我们使用Ansible playbook来构建和配置这些环境的服务器。”
3. 版本控制和Git
- 问题: 你如何为DevOps项目设计分支策略，如何确保你的基础设施代码与应用代码保持同步？
- 如何回答: 你可以讨论确保基础设施变更与应用变更耦合的方法，减少不匹配或配置漂移的风险。你还可以谈论早期测试，以最小化在开发周期后期发现基础设施相关问题的可能性。
例如：
“在我之前的DevOps项目中，我遵循GitFlow分支策略来设计分支。我们使用_feature_分支进行所有新工作，_develop_分支用于集成和测试，_main_分支用于稳定发布。
我们开始每个新功能或任务，无论是与基础设施（如Terraform脚本或Ansible playbook）还是应用代码相关，都会从develop分支克隆一个单独的分支。这允许隔离开发而不中断主要开发流程。
为了保持基础设施代码与应用代码同步，我们将它们都存储在同一个仓库中，使用monorepo结构。这确保了我们版本化任何必要的基础设施调整，并与它们支持的代码一起，应用和基础设施变更都存在于每个feature分支中。
当然，如果你之前为基础设施代码维护了单独的仓库，也可以提及。这里没有正确答案；每种方法都有其优缺点。
在合并回_develop_之前，所有变更都经过拉取请求和代码审查。我们还安装了SonarQube，在早期阶段测试我们的代码。通过早期发现问题，我们确保在进入生产环境之前在staging环境中正确测试基础设施变更。
一旦测试和审查通过，feature分支将合并到_develop_中，进一步进行集成测试。当一切稳定后，我们将develop合并到main进行发布。”
4. 监控和日志
- 问题: 你使用过哪些监控和日志工具来维护基础设施和应用？它们如何帮助你识别和解决问题？
- 如何回答: 监控和日志在确保软件应用和系统的性能、安全性和可靠性方面起着至关重要的作用。在面试中，你应该展示你对此的重视并理解其重要性。
例如：
“我使用过多个监控和日志工具，包括Prometheus、Grafana、OpenSearch和AWS CloudWatch。
对于监控，我使用Prometheus收集指标，使用Grafana进行可视化。对于日志，我使用OpenSearch集中日志并分析模式。我们设置了仪表板和警报，以确保在问题升级前捕获潜在问题。根据影响和紧急程度，我们按团队分发警报，并发送电子邮件和短信。
一个例子是我在管理一个托管通知服务应用的Kubernetes集群时。我们使用Prometheus和Grafana进行监控，并为资源使用（如CPU、内存和磁盘I/O）创建了警报。
一天晚上，我收到了一个关于Kubernetes集群中某个节点内存使用异常高的警报。在调查过程中，我发现我们的一个后端服务存在内存泄漏问题，导致其内存消耗不断增加且未正确释放。
由于警报，我能够在情况变得关键之前介入。我暂时通过隔离节点释放内存，防止更多pod调度到该节点，然后重启服务。之后，我们进行了彻底调查，识别了服务代码中的内存泄漏，并应用了修复。”
5. 基础设施即代码（IaC）
- 问题: 你使用过哪些基础设施即代码工具？你能解释一下你如何组织和结构化你的IaC项目吗？
- 如何回答: 管理基础设施即代码（如Terraform、CloudFormation）可能会很混乱，尤其是在基础设施增长且需要处理大量文件时。回答这个问题时，你需要展示你知道如何处理大量文件和代码，并了解从第一天起组织一切的重要性。此外，你还需要展示你知道如何处理敏感数据（如密码、密钥等）。
例如：
“在我使用Terraform的经验中，管理秘密和敏感信息是确保安全和防止潜在漏洞的关键方面。我使用AWS Secrets Manager来存储和管理秘密和敏感数据。Terraform配置为在运行时检索这些秘密。
对于Kubernetes部署，我使用HashiCorp Vault来安全存储秘密，并在需要时注入到pod中。
在CI/CD管道中，Jenkins和GitHub Actions将秘密作为环境变量传递，因此Terraform可以在不将它们存储在代码库中的情况下使用它们。
我采取的另一种方法是使用基于角色的访问控制（RBAC），仅将秘密访问权限限制给需要它的实体。这意味着只有负责部署的特定角色才能从Secrets Manager检索秘密。
对于Terraform状态和variables.tf文件，我们使用加密的S3桶进行服务器端加密，并严格控制访问。”
6. 容器和编排
- 问题: 你对Docker和Kubernetes有什么经验？你会如何使用这些工具部署微服务应用？
- 如何回答: 回答这个问题时，你需要展示在设置高可用性Kubernetes集群方面的经验。你需要展示对Kubernetes/Docker安全方面、自动扩展和网络的理解。
例如：
“我有使用Docker进行应用容器化和使用Kubernetes进行编排的经验。在Kubernetes集群中扩展和确保高可用性需要结合适当的配置、自动化和监控。
对于扩展，我主要使用Kubernetes中的Horizontal Pod Autoscaler（HPA）。HPA根据观察到的CPU或内存使用情况或自定义指标（如请求速率）自动调整部署中的pod数量。为了确保在Kubernetes集群中运行的服务的高可用性，我专注于以下策略：
- 副本和负载均衡：我使用Deployments运行每个pod的多个副本。通过拥有关键服务的多个副本，系统能够更有效地处理故障。此外，Kubernetes Service提供了负载均衡，确保传入请求均匀分布在健康副本之间。
- 多区域部署：为了确保可用性，我将Kubernetes集群部署在多个可用区中。通过在不同区域中分散工作节点，我们减少了如果一个区域出现问题而导致停机的风险。
- 就绪和存活探针：我配置了就绪和存活探针，以确保只有健康的容器接收流量。存活探针确保Kubernetes自动重启无响应的容器，而就绪探针确定pod是否准备好处理请求。
- 使用Ingress进行流量管理：为了管理这些扩展服务的传入流量，我使用了Ingress Controller。Ingress允许我定义路由规则，将外部流量定向到适当的服务，同时提供TLS终止等功能以确保通信安全。
通过结合Horizontal Pod Autoscaling、就绪/存活探针、节点亲和性和Ingress进行流量路由，我能够提供一个弹性且高可用的系统，该系统根据用户需求自动扩展，并最大限度地减少潜在停机时间。”
7. DevOps中的安全
- 问题: 你如何将安全实践集成到DevOps生命周期中？
- 如何回答: 回答这个问题时，你需要展示你理解DevOps中安全的重要性，并实施了SonarQube等安全工具在CI/CD管道的早期阶段。
例如：
“我遵循左移安全的概念，这意味着在软件开发生命周期的早期集成安全措施。例如：
- 代码分析：我在开发阶段使用SonarQube和Trivy扫描代码和Docker镜像中的漏洞。这些工具集成到CI/CD管道中，确保在非常早期阶段捕获不安全的代码。
- 依赖扫描：我使用Snyk扫描第三方库中的已知漏洞。这有助于防止由过时或不安全的依赖项引起的漏洞。
- 秘密管理：敏感数据（如API密钥、数据库密码或SSH密钥）安全存储在AWS Secrets Manager和GitHub secrets中。这防止了秘密被硬编码或在仓库中意外暴露。
- 自动化安全测试：我将ZAP by Checkmarx添加到CI/CD管道中。它对运行中的应用进行模拟攻击，以识别漏洞（如SQL注入或跨站脚本），在部署到生产环境之前。
- IaC扫描：我使用Terraform Validator扫描我的IaC脚本，以确保符合安全最佳实践。这有助于在部署前识别配置错误，如开放的安全组或公开暴露的S3桶。”
8. 云平台
- 问题: 你使用过哪些云平台（如AWS、GCP、Azure）？
- 如何回答: 对我来说，我选择AWS作为我首选的云平台。我几乎不接其他云提供商的项目。我决定专注于AWS，掌握它，并避免与其他云提供商合作。
这就是为什么我只面试与AWS相关的工作。因此，我对这个问题的回答将集中在我对特定平台的专长上。然而，如果你有多个云平台的经验，请提及。你还应该提到你在每个云提供商上使用的具体服务。
例如：
“我有多个云平台的实际经验：AWS、Google Cloud Platform和Microsoft Azure。每个平台都有其优势，我利用对它们的熟悉度根据项目的具体需求选择合适的服务。
- AWS：AWS是我使用最广泛的平台。我使用过核心服务，如EC2用于计算，S3用于存储，RDS用于托管数据库，Lambda用于无服务器函数。我还使用过EKS用于容器编排，CloudFormation用于基础设施即代码，IAM用于访问管理。AWS的灵活性和广泛的服务使其成为大多数项目的首选。
- GCP：我有使用Google Kubernetes Engine进行容器编排和BigQuery进行数据分析的经验。GCP在数据处理和机器学习方面有出色的服务，我倾向于在有大量数据分析或机器学习需求时使用它，因为AI Platform和BigQuery能够轻松处理大数据集。
- Azure：我还使用过Azure，使用过Azure虚拟机、Azure Kubernetes Service和Azure DevOps等服务。Azure与Active Directory的集成使其成为已经大量投资于微软生态系统的组织的理想选择，并且由于Azure Arc等服务，它是混合云解决方案的绝佳选择。”
9. 自动化和脚本
- 问题: 你如何在日常DevOps任务中使用自动化？
- 如何回答: 你需要展示你尽可能多地自动化，不仅限于DevOps相关任务，还包括其他团队的任务。你可以提到你发起的与开发团队的每周会议，询问他们的痛点并提出自动化工作方法。
例如：
“自动化是我作为DevOps工程师工作的核心方面，我每天使用它来简化重复任务，减少手动干预并提高效率。我的经验涉及使用Ansible、Jenkins和Python脚本来自动化从基础设施配置到CI/CD管道的广泛活动。
- 基础设施配置：我使用Terraform来自动化基础设施部署。而不是手动创建虚拟机、数据库和网络配置，我编写可重用的Terraform模块，以代码定义基础设施，使其一致且版本控制。
- 配置管理：使用Ansible，我自动化服务器的配置。我安装必要的软件包，建立配置，并确保所有服务器的一致性。使用Ansible，我可以将相同的配置应用于数百台服务器，确保一致性并消除人为错误的可能性。
- CI/CD管道：我使用Jenkins和GitHub Actions来自动化构建、测试和部署过程。每次代码变更都会触发一个管道，运行单元测试、集成测试和安全扫描，然后在所有测试通过后将应用部署到staging或生产环境。
- 自动化监控和警报：我使用自动化来设置监控工具，如Prometheus和Grafana。例如，我创建了脚本，在部署新服务时自动将其添加到监控仪表板。这确保没有服务被遗漏监控，并且警报自动配置。”
10. 事件管理和故障排除
- 问题: 你能描述一次生产环境宕机的事件，并且你是响应团队的一员吗？你是如何进行故障排除的，你在解决问题中扮演了什么角色？
- 如何回答: 显然，答案应采用STAR格式（情境、任务、行动和结果）。
例如：
“事件发生在高流量期间，我们的主要应用突然出现延迟峰值，最终导致完全宕机。该应用托管在Kubernetes集群上，用户无法连接到我们的服务，这对业务产生了重大影响。
作为事件响应团队的一员，我的职责是识别根本原因，缓解问题并使系统重新上线。以下是我如何进行故障排除的：
我们通过PagerDuty收到警报，指示多个服务处于降级状态，并记录了大量500错误。我登录Grafana以识别受影响的服务，并检查系统指标，如CPU、内存和网络使用情况。Kubernetes仪表板显示多个pod处于崩溃循环中，我们注意到某些节点上的资源限制。我使用OpenSearch深入查看崩溃服务的日志。我发现OutOfMemory错误，表明我们的pod消耗的内存超过了分配的内存。
我还分析了依赖关系，发现我们的一个后端微服务有一个未优化的数据库查询，产生了大量负载，导致其他服务出现级联故障。该微服务在多个副本中运行，每个副本独立尝试处理突然的流量激增，最终耗尽了可用内存。
为了暂时缓解问题，我扩展了受影响的部署，添加更多pod来处理增加的负载。我还增加了崩溃pod的内存限制。我们调整了入口规则，使用速率限制暂时限制部分流量，以减少后端的压力，同时我们解决根本原因。
我启动了回滚到之前稳定版本的微服务，该微服务导致了问题。这稳定了整个系统并停止了崩溃循环。
系统重新上线后，我们与开发团队合作，识别未优化查询的根本原因。我们使用数据库查询分析工具发现缺少索引，这导致在负载下进行全表扫描。
我们添加了所需的数据库索引，并优化了查询，显著提高了其性能。我们还更新了Horizontal Pod Autoscaler（HPA）设置，以确保pod在未来的流量激增中更积极地扩展。
事件解决后，我们进行了无责备的事后分析，以了解发生了什么、为什么会发生以及我们如何改进。我们识别了监控中的差距，并改进了我们的警报系统，以包括内存使用增加的早期预警信号。
我在此次事件中的角色是专注于基础设施稳定性和资源管理的DevOps工程师。我的职责包括：
- 分析日志和指标以确定宕机的根本原因。
- 扩展服务并分配更多资源以缓解即时危机。
- 回滚有问题的服务以恢复稳定性。
- 与开发人员合作实施长期修复。
- 记录事件响应过程并建议改进我们的监控和警报实践。”
这些问题不仅旨在评估候选人的技术知识，还评估他们的问题解决方法、处理复杂情况的能力以及他们在DevOps环境中持续改进的思维方式。希望对你有所帮助！
