• 文档/教程

本篇是 90DaysOfDevOps 90 天学习之旅的第 2 站，承接 Day 1 的引言，聚焦回答一个核心问题：DevOps 工程师到底做什么？文章从"应用的两大半边（开发与运维）"出发，梳理 DevOps 工程师在配置、服务器、操作系统、网络、容器化等维度上的职责边界，并给出"通才而非专才"的能力定位，最后将责任落到"如何持续、自动化、可测试地把新版本交付给终端用户"这一终极命题上。读完你将建立起对 DevOps 工程师职责的完整心智模型，为后续 88 天深入各技术主题打下基础。

预备知识：Day 1 的结论

在 Day 1 中我们已经确立了几个关键前提：DevOps不是一件可以购买的工具，不是软件 SKU，也不是一个可下载的开源仓库；它是一种把软件交付做得更聪明的实践与文化。DevOps 通过打破开发（Developers）、运维（Operations）与测试（QA）之间的部门孤岛，将"从产品构思到交付给终端用户"的时间大幅压缩，并且开发、测试、部署这些环节都落到 DevOps 团队身上。而要让这一切高效运转，自动化是不可或缺的杠杆。

Day 2 正是在此基础上更进一步：既然 DevOps 团队要扛起开发、测试、部署的职责，那么这些职责具体长什么样？答案要先从"一个应用被创建出来之后发生了什么"说起。

一个应用的两大半边：Development 与 Operations

在 Day 2 原文 中作者明确指出：创建一个应用包含两个主要部分——

• Development（开发）：软件开发者编写应用代码并对其进行测试；
• Operations（运维）：应用被部署到服务器上，并持续维护运行。

传统模式下这两者往往是割裂的：开发团队只管交付代码，运维团队只管把代码跑起来，两者之间充满交接摩擦与信息损耗。DevOps 工程师的使命，就是成为这两者之间的桥梁，让"开发"与"运维"不再是两个互相扔墙的部门，而是一条连贯、可重复、不断迭代的流水线。

一切从应用开始：以应用为中心的 DevOps

原文强调了一个贯穿整个 90 天课程的核心观点：DevOps 世界里一切皆围绕应用展开。你会在后续所有主题中反复看到这一点——无论讲 Linux、网络、容器、Kubernetes 还是 CI/CD，最终服务的都是"让应用稳定、高效、持续地跑起来"。

开发者创建应用的方式千差万别：可能使用完全不同的技术栈、不同的编程语言、不同的构建工具与代码仓库。作为 DevOps 工程师，你通常不会亲自编写应用代码，但理解"开发者如何工作、用了哪些系统/工具/流程"是成功的关键——这份理解让你能做出更合理的基础设施决策，正如 Day 3 所言："能够读懂部分代码，将帮助你为应用做出最好的基础设施决策"。

在高层次上，你需要至少掌握三件事：

1. 应用如何配置：应用是如何被配置去连接它所需的各种服务或数据服务的（例如数据库、消息队列、缓存等）；
2. 应用如何测试：这套配置与依赖关系应该或可以被怎样测试；
3. 应用部署到哪里：应用将被部署到什么样的环境并如何被终端用户访问。

应用跑在哪里：服务器、操作系统与网络

应用需要一个运行场所。原文把这里"刻意保持简单"：先假设它是一台服务器——不管它在哪里，它就是一台服务器。这台服务器随后被客户或终端用户访问。但作为 DevOps 工程师，你需要考虑更细的一层：

• 服务器运行在哪里：本地自建（on-premises）、公有云，还是 Serverless？原文明确提到 Serverless 是越来越多企业选择的方向，但本 90 天课程不覆盖 Serverless；
• 谁创建并配置这些服务器：创建、配置服务器并让它准备好承载应用，很可能就是 DevOps 工程师的职责；
• 操作系统：服务器运行的是操作系统，一般以Linux为主。仓库为此安排了整整一周的 Linux 基础（参见 2022.md 进度表中的 Linux 章节）；
• 网络：应用通常还需要与网络环境中的其他服务通信，因此 DNS、DHCP、负载均衡等网络知识必不可少——仓库也为此安排了 Networking 专题周（从 OSI 七层模型、网络协议到 Python 网络自动化）。

需要再次强调边界：你不必成为网络或基础设施专家，你需要的只是能把系统拉起来并让它们彼此通信的基础知识——这和你"不需要成为开发者，但要有编程语言基础认知"是一个道理。

Jack of all trades, Master of none：通才定位

这是 Day 2 原文 中非常核心的一段论述：DevOps 工程师的角色定位是**"万事通，无一精"**。你不必是网络专家、基础设施专家或资深开发者，但要具备各领域的基础认知。同时：

• 如果你以某一领域的专才身份进入 DevOps，那会是一个很好的起点，便于向其他领域扩展；
• 你大概率不会接管这些服务器或应用的日常运维管理——那是运维日常的活，DevOps 的职责更偏向"建立让一切自动运行的方式"。

另外，虽然通篇在讲服务器，但现实是：你的应用很可能被开发成以容器（Containers）方式运行。容器大多仍然运行在服务器之上，但你需要同时理解虚拟化（Virtualisation）、云基础设施即服务（IaaS）以及容器化（Containerisation）。本 90 天课程的内容重心更偏向容器，后续会专门安排 Containers 专题周（Docker、镜像、Compose、网络与安全）以及 Kubernetes 专题周（集群搭建、应用部署、Ingress 等）。

高层概览：把功能持续交付给终端用户

把两侧放在一起，就得到 Day 2 的高层概览：

• 一侧：开发者持续为应用创造新功能、新特性（以及修复 Bug）；
• 另一侧：某种环境、基础设施或服务器被配置和管理起来，用于运行应用并与其所需的所有服务通信。

那么最大的问题来了：如何把这些特性和 Bug 修复送进产品，并让终端用户可用？如何发布新应用版本？

这正是 DevOps 工程师的核心任务之一。而关键不在于"把这件事做成一次"，而是要持续地、自动化地、高效地做——并且必须包含测试。围绕这个主题，Day 2 之后的几天会逐步展开：

• Day 3：DevOps 生命周期（以应用为中心）——Development → Testing → Integration → Deployment → Monitoring 的完整闭环；
• Day 5：Plan > Code > Build > Testing > Release > Deploy > Operate > Monitor——逐步拆解每个环节，并引出 Continuous Integration / Continuous Delivery / Continuous Deployment（CI/CD）三者的关系；
• 仓库还专门为 CI/CD 准备了 Jenkins 流水线示例，其中用podTemplate定义了一个同时包含Maven（构建）与Kaniko（构建并推送容器镜像）的 Pod，依次执行Clone Repository、Build Image、Test Image、Build Hello World App等阶段——这正是"持续构建、持续测试、持续交付"在真实配置中的缩影，也印证了 Day 2 所说的"自动化 + 测试 + 部署"正是 DevOps 工程师日常要打交道的对象。

小结与下一步

Day 2 的收获可以浓缩为一张职责清单：

正如 Day 2 原文 所建议：如果你是带着 Day 1 的资源铺垫进入这一天的，那么到这里你应该已经能够判断——DevOps 工程师这条路是否适合自己。接下来的 Day 3 将带你以应用为中心，把上面这条流水线展开成完整的 DevOps 生命周期。

• 文档/教程