企业官网建设流程全解析

• 文档/教程

90DaysOfDevOps 第三天（2022 路线图）以应用为核心视角，把 DevOps 生命周期拆解为「开发 → 测试 → 集成 → 部署 → 监控」五个阶段，并强调这是一个周而复始的闭环。本文将完整继承该文档的核心脉络，并结合当前仓库中真实存在的 CI/CD 流水线、容器化配置、Kubernetes 编排清单与 Elastic Stack 监控栈等源码佐证，帮助你理解：一个应用从需求诞生、编码提交、自动测试、部署上线，到持续监控与成本治理的完整旅程，以及 DevOps 工程师在这条链路上应当扮演的角色。

DevOps 生命周期：以应用为核心的持续循环

在接下来数周的学习中，「持续开发（Continuous Development）、持续测试（Continuous Testing）、持续部署（Continuous Deployment）、持续监控（Continuous Monitoring）」这些词汇会被反复提及。如果你正朝着 DevOps 工程师岗位发展，可重复性（repeatability）将是你必须习惯的工作常态——同一个流程会被一次次执行；而每次循环后的持续改进（constant enhancement），则是让这份工作始终保持有趣、有挑战性的关键。

本次课程的核心，是站在**应用（Application）**的角度，从零开始追踪它从启动到结束、再回到起点的高层视图：

开发(Development) → 测试(Testing) → 集成(Integration/CI) → 部署(Deployment) → 监控(Monitoring) ↑ ↓ └──────────────── 反馈与改进闭环 ←──────┘

下面逐一深入每个阶段，并结合仓库中的真实文件佐证其落地方式。

阶段一：开发（Development）——需求、编码与版本控制

以一个全新应用为起点：初始阶段一切尚未创建。作为开发者，你首先需要与客户或终端用户讨论需求（requirements），形成应用的计划与需求清单，然后据此从零编写应用。

本阶段的工具需求极简：只需要选择你习惯的 IDE（集成开发环境）以及希望用来编写应用的编程语言。仓库本身就是一个多语言混合示例——例如 2022/Days/Go 目录下存放着 Go 语言的学习代码，而 CI/CD 示例则涉及 Java/Maven 与 shell 脚本，这说明应用可以用任何语言编写，语言选择取决于业务场景与团队技术栈。

从源码结构看，可以得出两个对 DevOps 工程师至关重要的结论：

1. DevOps 工程师通常不是需求方案或业务代码的作者——那是熟练的开发者的工作。但 DevOps 工程师最好具备阅读部分代码的能力，这样才能为应用做出最优的基础设施决策（例如：这段代码是 CPU 密集还是 IO 密集？需要怎样的内存与存储规格？）。
2. 代码必须纳入版本控制系统（Version Control System）维护，这正是后续课程将重点展开的Git。一个项目几乎不可能只有一名开发者，最佳实践要求使用**代码仓库（code repository）**来存储与协作——可以是私有或公开、自托管或云端托管，业界常见的是 GitHub、GitLab 这类平台。这些内容也会在后续Git专题中详细覆盖。

阶段二：测试（Testing）——用容器压低测试环境的成本

进入这一阶段时，我们已拥有需求清单，应用也正在开发中。此时需要确保代码在所有可用环境（尤其是所选编程语言相关的运行时环境）中都经过测试。

这一阶段的核心价值有两层：

• QA 负责测试与缺陷发现。如今越来越普遍的做法是用容器（container）模拟测试环境——相比搭建物理或云基础设施，容器可以整体降低测试环境的成本开销。
• 测试自动化是必然趋势。这一阶段大概率会作为下一环节「持续集成（Continuous Integration）」的一部分被自动化。

原文特别点明了一个对比：让数十、数百乃至数千名 QA 工程师手工测试，与把测试自动化相比，差距不言而喻。测试自动化能把工程师从「反复测试 bug」中解放出来，让他们专注于栈内其他更有价值的开发工作，从而比采用瀑布方法论（waterfall methodology）的传统软件发布更快地交付更多功能——传统瀑布式发布恰恰最容易卡在 bug 测试环节。

仓库中的 Dockerfile 是容器化环境的一个直观示例：它基于ubuntu:18.04官方镜像构建，安装 nginx 与 curl，并通过groupadd/useradd创建非 root 的basicuser用户，最后用USER basicuser切换运行身份。这段配置体现了测试/运行环境容器化的两个要点：镜像可复现（同一 Dockerfile 永远构建出相同基线环境）与最小权限运行（不推荐以 root 运行应用进程），这正是容器能低成本、安全地替代物理/云测试基础设施的原因。

阶段三：集成（Integration / CI）——生命周期的心脏

集成（Integration）在 DevOps 生命周期中处于核心枢纽地位：它要求开发者更频繁地提交源代码变更——可以按天、也可以按周。每次提交，应用都能自动进入自动化测试阶段，从而在进入下一阶段之前尽早发现潜在问题或 bug。

这就是「持续集成（Continuous Integration）」的核心机制：提交频率越高，问题暴露越早，修复成本越低。

仓库中的 Jenkinsfile 是 CI 阶段落地形态的完整示例，其流水线清晰复现了「提交 → 构建 → 测试 → 产物」的链条：

1. Clone Repository 阶段：git url: 'https://github.com/MichaelCade/Jenkins-HelloWorld.git'拉取源码，对应「频繁提交」的源头；
2. Build Image 阶段：在maven:3.8.1-jdk-8容器内执行构建，并以echo "Tests passed"作为自动化测试占位——即每次提交后自动跑一遍测试；
3. Test Image / Build Hello World App 阶段：在gcr.io/kaniko-project/executor:debug容器内调用/kaniko/executor --context \pwd` --destination michaelcade1/helloworld:1.0`，用 kaniko 在 Kubernetes Pod 中直接构建并推送应用镜像。

这份流水线的技术细节值得注意：podTemplate声明了一个包含 maven 与 kaniko 两个容器的 Pod，maven 负责编译测试、kaniko 负责镜像构建，且通过kaniko-secret（挂载到/kaniko/.docker的 docker 凭据 secret）实现免认证推送。它印证了 CI 阶段的典型形态：每次代码变更自动触发构建与测试，问题在进入部署环节前就被拦截。

此外，原文还给了一个务实的提醒：如果你的企业不开发应用，而是从软件厂商购买现成的（off-the-shelf）软件，也不必担心——很多公司都这么做。此时前三个阶段主要由软件厂商负责，但你仍然应该采纳第四阶段（部署），因为它能让现成软件的部署更快、更高效。而且，掌握这套知识的价值不只在于今天：今天你或许在买现成软件，明天、以后、乃至下一份工作呢？

阶段四：部署（Deployment）——配置管理、IaC 与容器编排的用武之地

应用已经构建完成、并且针对终端用户需求完成了测试，接下来就要部署到生产服务器供终端用户使用。原文明确指出：这是整个生命周期中极其有趣、也是剩余 86 天课程将不断深潜的领域。

为什么部署如此复杂？因为不同的应用需要不同的硬件与配置。正是这一需求，催生了 DevOps 生命周期中两个关键支柱：

• 应用配置管理（Application Configuration Management）：保证应用在各环境（开发/测试/生产）中的配置可声明、可追溯、可重放；
• 基础设施即代码（Infrastructure as Code, IaC）：用代码来描述、版本化并自动编排基础设施，替代手工配置服务器。仓库中 2022/Days/IaC 目录下的 Terraform 文件（.tf、.tfvars）正是这一主题的实操样本，后续课程会展开详解。

在部署形态上，应用可能被容器化（containerised），也可能直接运行在虚拟机（VM）上；当容器规模变大，就需要引入Kubernetes这样的平台来编排（orchestrating）容器，确保终端用户始终获得你期望的状态（desired state）。

仓库中的 nginx-stateless-demo.yaml 是 Kubernetes 声明式部署的完整示例，只用一份 YAML 就描述了三个对象：

• Namespacenginx：将应用资源隔离在独立命名空间内；
• Deploymentnginx-deployment：声明replicas: 1、镜像nginx、容器端口containerPort: 80——这体现「期望状态」：Kubernetes 负责让实际运行副本数始终向声明值收敛；
• Servicenginx-service：通过selector关联到带app: nginx标签的 Pod，暴露 TCP80端口供访问。

这一示例直观展示了原文所述「Kubernetes 编排容器并维护期望状态」的实现原理：开发者只需声明目标状态（几个副本、什么镜像、暴露哪个端口），集群的控制器会持续调和（reconcile）实际状态与声明状态。

阶段五：监控（Monitoring）——性能、可靠性、成本与反馈闭环

到这里，应用运行速度已经很快了：我们持续为应用加入新特性与功能，测试确保「没有偷偷混入的捣乱 bug（gremlins）」；应用运行在能持续维持所需配置与性能的环境中。但这一切还不够——我们必须确认终端用户真正获得了他们需要的体验。

本阶段的核心任务包括：

1. 持续监控应用性能（Application Performance）：只有持续观测性能指标，开发者才能对后续版本的功能增强做出更明智的决策，更好地服务终端用户；
2. 收集反馈闭环（feedback wheel）：捕捉「已实现的功能」与「终端用户希望如何改进」之间的差距；
3. 可靠性（Reliability）是关键词：归根结底，我们希望应用在需要时随时可用。这自然延伸到其他应被持续监控的领域——可观测性（observability）、安全（security）与数据管理（data management），其反馈可以持续用于增强、更新与发布应用。

仓库中 2022/Days/Monitoring/Elastic Stack 目录提供了一套完整、可直接运行的 ELK/Elastic Stack 监控栈，正是本阶段技术的落地样板，几个关键配置文件足以说明可观测性的组成部分：

• docker-compose.yaml：以setup一次性服务初始化 Elasticsearch 内部用户，再编排elasticsearch（数据存储，暴露9200/9300）、kibana（可视化）等服务的启动顺序与网络；
• elasticsearch/config/elasticsearch.yml：声明集群名docker-cluster、监听地址0.0.0.0，并开启 X-Pack 安全（xpack.security.enabled: true）——说明监控数据的存储层同样需要身份与访问控制；
• kibana/config/kibana.yml：配置 Kibana 服务名、监听地址与 Elasticsearch 地址http://elasticsearch:9200，并通过kibana_system用户凭据认证；
• logstash/pipeline/logstash.conf：定义日志采集管道——input同时监听 Beats（5044端口）与 TCP（5000端口），output写入 Elasticsearch（elasticsearch:9200）；
• extensions/metricbeat/config/metricbeat.yml：通过 docker 模块以 10 秒周期采集容器cpu、memory、diskio、network等指标，正是「持续监控应用性能」的指标来源。

这套配置表明，可观测性的实现路径是：metricbeat/filebeat 采集指标与日志 → logstash 过滤与转发 → Elasticsearch 存储索引 → Kibana 可视化与告警，形成完整的「采集—传输—存储—展示」链路。

FinOps：成本也是需要持续监控的指标

社区成员（尤其是 @_ediri）提出了一个常被忽视但同样重要的观点：FinOps 团队也应参与这个持续过程。应用和数据总在某个地方运行与存储——当资源需求发生变化时，必须持续监控成本，确保云账单不会因此产生巨大的财务压力。

这给监控阶段的启示是：除了 CPU、内存、延迟等技术指标，云成本（Cloud Cost）同样是一种需要「可观测」的运营指标，成本治理（FinOps）与性能监控应并行运作。

DevOps 不是头衔，而是一种流程与文化

原文在此处专门澄清了一个常见的认知误区：虽然业界存在大量挂着「DevOps Engineer」头衔的岗位，但这并不是给 DevOps 流程定位的理想方式。与社区同行交流后的共识是：

DevOps Engineer 这个头衔不应该是任何人的职业终点。

真正值得推广的是：任何岗位都应该采纳这里所讲的 DevOps 流程与文化。DevOps 应当被应用到许多不同的职位中，例如：

• 云原生工程师 / 架构师（Cloud-Native Engineer/Architect）
• 虚拟化管理员（Virtualisation Admin）
• 云架构师 / 云工程师（Cloud Architect/Engineer）
• 基础设施管理员（Infrastructure Admin）

等等。上文之所以用「DevOps Engineer」作为叙述载体，只是为了突出：上述所有职位（以及更多）都会用到 DevOps 这套流程与范围。对学习者而言，这意味着一份重要的心态转变：不要把「DevOps」当成岗位说明书，而应把它当作一套贯穿职业角色的工程文化与方法论。

资源与下一步

本系列 Readme 文件定位为学习工具，始终欢迎补充资源。原文档给出的建议是：完整观看以下主题的配套视频，并结合正文文字吸收理解——内容包括：

• 持续开发（Continuous Development）：原视频聚焦制造业，但其精益（lean）文化可以很好地与 DevOps 对照学习；
• 持续测试（Continuous Testing）：来自 IBM 的讲解；
• 持续集成（Continuous Integration）：来自 IBM 的讲解；
• 持续监控（Continuous Monitoring）：理解监控环节的完整脉络；
• FinOps Foundation 的 FinOps 入门介绍：了解成本治理这一新兴领域；
• 《凤凰项目》（The Phoenix Project）：一本关于 IT、DevOps 与帮助企业取胜的小说，适合作为延伸阅读（非免费资源）。

如果你已经坚持到这里，应该能够判断这片领域是否是你想去的地方了。下一站，我们将继续深入生命周期的更多细节——第 4 天：版本控制与 Git 专题。

• 文档/教程