Balinder Walia
为什么初创公司从第一天起就需要 DevOps
在快节奏的技术初创公司世界中，快速、可靠且重复地交付软件的能力是决定成功或失败的竞争优势。 DevOps 是开发和运营实践的结合，可实现快速、可靠的软件交付，这并不是大型企业的奢侈品。这是初创公司从一开始就应该建立的基本能力。
许多初创公司都错误地将基础设施和部署视为需要稍后解决的问题，而只专注于早期阶段的功能开发。这种方法产生的技术债务会迅速复合。手动部署会引入人为错误，并随着团队的成长而成为瓶颈。缺乏自动化测试意味着错误会更频繁地出现在生产环境中。缺乏监控意味着问题是由客户而不是工程团队发现的。当初创公司达到产品与市场的契合度并需要扩大规模时，这些问题可能会造成严重后果。
好消息是现代 DevOps 工具极大地降低了进入门槛。小型工程团队可以使用开源工具和云服务，在几天而不是几个月内建立强大的 DevOps 基础，无需重新架构即可从原型扩展到生产。
CI/CD 流水线设置
持续集成和持续部署 (CI/CD) 是 DevOps 自动化的基石。精心设计的 CI/CD 管道会在每次推送更改时自动构建、测试和部署代码，为开发人员提供快速反馈并确保主分支始终处于可部署状态。
GitHub Actions
对于使用 GitHub 进行源代码控制的初创公司，GitHub Actions 提供了功能强大且易于访问的 CI/CD 平台，无需管理额外的基础设施。工作流程在存储库中定义为 YAML 文件，使管道配置可以与代码一起进行版本控制和审查。
使用 GitHub Actions 的典型启动 CI/CD 工作流程包括：对每个拉取请求运行 linter 和静态分析、执行单元和集成测试套件、构建容器映像并将其推送到注册表、在合并到主分支时自动部署到暂存环境，以及通过手动审批门升级到生产。 GitHub Actions 为公共存储库提供慷慨的免费分钟数，为私有存储库提供合理的定价，这对于初创公司来说具有成本效益。
GitLab CI/CD
GitLab CI/CD 提供完全集成的 DevOps 平台，其中源代码控制、CI/CD、容器注册表和监控共存于单个应用程序中。对于喜欢一体化解决方案的初创公司来说，GitLab 减少了需要管理的工具数量，并为整个软件交付生命周期提供了统一的界面。
GitLab CI/CD 管道在.gitlab-ci.yml文件中定义，并支持高级功能，包括用于并行执行的有向无环图 (DAG) 管道、用于微服务架构的多项目管道以及内置安全扫描阶段。 GitLab 还提供慷慨的免费套餐，其中包括共享跑步者每月 400 CI/CD 分钟。
针对初创公司的管道最佳实践
无论您选择哪种 CI/CD 平台，几种最佳实践都将最大限度地提高管道的价值：
- 保持管道快速：目标是从推送到部署的时间在 10 分钟内。使用缓存、并行测试执行和增量构建来缩短管道持续时间
- 快速失败：首先运行最快的检查（linting、单元测试），以便开发人员获得有关明显问题的快速反馈
- 使管道具有确定性：使用固定依赖版本和固定基础映像来确保构建可重现
- 将管道配置视为代码：以与应用程序代码更改相同的严格性审查管道更改
使用 Docker 和 Kubernetes 进行容器化
Docker：一致的开发和部署
Docker 容器将您的应用程序及其所有依赖项打包到一个便携式、可复制的单元中。这消除了软件在开发人员的机器上运行但在生产中失败的经典问题。对于初创公司来说，Docker 提供了几个关键优势：
- 环境一致性：开发、试运行和生产环境相同，减少特定于环境的错误
- 载入速度：新团队成员可以使用单个
docker-compose up命令运行整个应用程序堆栈 - 微服务支持：每个服务都可以独立构建、测试和部署
- 资源效率：容器共享主机操作系统内核，消耗的开销远低于虚拟机
在为生产编写 Docker 文件时，请遵循包括多阶段构建在内的最佳实践为了最大限度地减少映像大小，以非根用户身份运行以确保安全，使用特定的基础映像标签而不是最新的标签，并实施运行状况检查，以便您的编排器可以用来管理容器生命周期。
Kubernetes：大规模编排
Kubernetes 已成为容器编排的事实上的标准。虽然它增加了复杂性，但对于接近规模的初创公司来说，好处是巨大的。 Kubernetes 提供基于资源利用率或自定义指标的自动扩展、通过容器重新启动和重新安排进行自我修复、零停机滚动部署、服务发现和负载平衡以及用作基础设施文档的声明性配置。
对于尚未准备好应对 Kubernetes 的全部复杂性的初创公司，AWS ECS、Google Cloud Run 或 Azure 容器应用程序等托管服务可提供容器编排，同时显着减少运营开销。随着您的需求增长，这些服务可以作为采用 Kubernetes 的垫脚石。
当您准备好使用 Kubernetes 时，Amazon EKS、Google GKE 和 Azure AKS 等托管产品将负责处理控制平面，让您的团队能够专注于部署和管理工作负载，而不是维护 Kubernetes 基础设施。
基础设施即代码与 Terraform
基础设施即代码 (IaC) 是通过机器可读的配置文件而不是手动流程来管理和配置基础设施的实践。 HashiCorp 的 Terraform 是采用最广泛的 IaC 工具，通过其提供商生态系统支持所有主要云提供商和数百种第三方服务。
对于初创公司来说，Terraform 提供了几种基本功能：
- 再现性：您的整个基础设施可以通过代码重新创建，从而实现灾难恢复和环境克隆
- 版本控制：在 Git 中跟踪基础设施变更，提供审核跟踪并启用基础设施修改的代码审查
- 协作：团队成员可以通过拉取请求提出基础设施变更，计划输出准确显示应用
- 之前将发生的变化 多云灵活性：Terraform 的提供商该模型允许您通过一致的工作流程跨多个云提供商和服务管理资源
首先对最关键的基础设施进行编码：网络、计算实例、数据库和 DNS。使用 Terraform 模块封装可重用模式，并针对不同环境维护单独的状态文件，以减少影响范围。远程状态后端（S3、GCS、Terraform Cloud）支持团队协作和状态锁定，以防止并发修改。
监控和可观测性
您无法管理无法测量的内容。可观察性，即从外部输出了解系统内部状态的能力，对于维护可靠的服务和在出现问题时快速响应至关重要。
可观测性的三大支柱
指标是随时间推移收集的数值测量值。 Prometheus 是标准的开源指标平台，使用基于拉动的模型从应用程序和基础设施中获取指标。它提供了强大的查询语言 (PromQL) 用于分析和警报，并与 Kubernetes 原生集成以进行服务发现。
日志是离散事件的带时间戳的记录。集中式日志记录解决方案（ELK 堆栈、Loki 或 CloudWatch Logs 等云原生服务）聚合来自所有服务的日志，从而实现搜索、关联和分析。 JSON 格式的结构化日志记录使日志可被机器解析并支持更复杂的分析。
跟踪在遍历分布式系统中的多个服务时遵循请求。 Jaeger 或 Zipkin 等分布式跟踪工具实现了 OpenTelemetry 标准，有助于识别微服务架构中的延迟瓶颈和故障点。
Grafana：统一仪表板
Grafana 提供统一的可视化层，可以在可定制的仪表板中显示来自 Prometheus、Loki、Jaeger 和数十个其他数据源的数据。对于初创公司来说，Grafana 仪表板有多种用途：工程团队的实时运营监控、面向客户的服务的 SLA 跟踪、成本优化的资源利用率分析以及利益相关者的业务指标可见性。
从涵盖四个黄金信号的仪表板开始：延迟（请求需要多长时间）、流量（您正在服务的请求数量）、错误（失败请求的比率）和饱和度（您的资源有多满）。这些指标提供了服务运行状况的全面视图，是有效警报的基础。
成本优化策略
初创公司在财务限制下运营，这使得成本优化成为一个关键问题。 DevOps 实践既可以增加也可以降低基础设施成本，具体取决于实施方式：
- 适当大小的资源：使用监控数据来识别过度配置的实例和数据库，然后调整大小以匹配实际利用率
- 利用现货和抢占式实例：对于容错工作负载，例如CI/CD 运行程序和批处理、现货实例可节省 60% 到 90% 的成本
- 实施自动扩展：在高峰使用期间扩展资源，在安静期间缩减资源，而不是永久配置峰值容量
- 战略性地使用预留实例：对于稳定、可预测的工作负载，预留实例或节省计划可提供比按需定价大幅折扣
- 优化容器映像：较小的映像可降低存储成本、加快部署速度并降低网络传输费用
- 清理未使用的资源：实施自动化流程以识别和删除孤立卷、未使用的负载均衡器和空闲实例
GitOps：基础设施即 Git 工作流程
GitOps 通过使用 Git 作为应用程序和基础设施配置的单一事实来源，扩展了基础设施即代码的原则。 ArgoCD 和 Flux 等工具不断协调 Git 中声明的所需状态与 Kubernetes 集群的实际状态，并在存储库更新时自动应用更改。
对于初创公司，GitOps 提供了一种可审核（每次更改都是 Git 提交）、可逆（回滚是 Git 恢复）和可访问（开发人员通过熟悉的拉取请求工作流程进行部署，而不是学习集群管理工具）的部署模型。 GitOps 还自然支持多环境升级，其中更改通过分支合并或基于目录的配置从开发流向登台再到生产。
DevSecOps：管道中的安全性
安全性必须集成到您的 DevOps 管道中，而不是事后才应用。 DevSecOps 实践在整个软件交付生命周期中嵌入安全检查：
- 依赖项扫描：Dependabot、Snyk 或 Trivy 等工具可自动识别应用程序和容器映像中易受攻击的依赖项
- 静态应用程序安全测试 (SAST)：在 CI 期间分析源代码中的安全漏洞使用 SonarQube、Semgrep 或 CodeQL 等工具进行管道
- 秘密检测：使用 git-secrets、truffleHog 或 GitHub 秘密扫描等工具防止将 API 密钥、密码和证书提交到存储库
- 容器映像扫描：扫描在推送到注册表或部署到集群之前，先检查已知漏洞的 Docker 映像
- 基础设施策略实施：使用开放策略代理 (OPA) 或 Kyverno 在 Kubernetes 资源上实施安全策略，防止部署不安全的配置
要避免的常见陷阱
在许多初创公司的 DevOps 之旅中，我们观察到几个反复出现的错误：
- 早期过度设计：如果您的应用程序在单个服务器上运行，请不要在第一天实施 Kubernetes。从简单开始，随着真正需求的出现而增加复杂性
- 忽略文档：DevOps 自动化只有在团队成员了解如何使用时才有价值。记录您的管道、运行手册和架构决策
- 忽视本地开发：在开发人员与不一致的本地环境作斗争时投资生产基础设施会降低生产力。 Docker 编写和开发脚本值得同等关注
- 警报疲劳：过多的嘈杂警报会让团队忽视它们。从少量高信号警报开始，仔细扩展
- 跳过事后分析：当事件发生时，无过失的事后分析是提高可靠性的最有效方法。 记录发生的情况、原因以及哪些更改可以防止再次发生
- 将基础设施视为其他人的问题：在小型团队中，每个开发人员都应该了解部署管道并能够响应生产问题
分步实施指南
对于开始 DevOps 之旅的初创公司，我们建议以下内容分阶段方法：
第 1 阶段：基础（第 1-2 周）
- 使用分支保护规则和所需的代码审查设置版本控制
- 创建一个基本 CI 管道，对每个拉取请求运行 linting 和测试
- 使用 Docker 容器化您的应用程序并为其创建 docker-compose 文件本地开发
- 设置一个镜像生产的暂存环境
第 2 阶段：自动化（第 3-4 周）
- 在合并到主分支时实现持续部署到暂存
- 通过手动审批门添加生产部署
- 使用 Terraform 整理基础设施，从最关键的资源开始
- 使用 Prometheus 和 Grafana 设置基本监控，涵盖四个黄金信号
第 3 阶段：成熟（第 5-8 周）
- 将安全扫描添加到 CI 管道（依赖项扫描、SAST、容器扫描）
- 实施集中日志记录并针对关键错误设置基于日志的警报
- 根据流量模式为您的应用配置自动扩展
- 为常见操作过程和事件响应创建操作手册
第 4 阶段：优化（正在进行）
- 采用 GitOps 进行声明式、可审计的部署
- 实施成本监控和优化实践
- 为微服务调试添加分布式跟踪
- 定期进行架构审查并随着团队和产品的发展更新您的 DevOps 实践
Workstation 如何支持启动DevOps
在 Workstation，我们帮助技术初创公司构建可随着其发展而扩展的 DevOps 功能：
- DevOps 评估：我们评估您当前的开发和部署实践，并创建改进的优先路线图
- 管道设计和实施：我们根据您的技术堆栈和部署目标设计和构建 CI/CD 管道
- Kubernetes 和容器策略：从初始容器化到生产 Kubernetes 集群，我们指导您的容器采用之旅
- 基础设施即代码：我们使用 Terraform 对您的基础设施进行编码，使可复制、版本控制的云环境
- 监控和可观察性：我们实施 Prometheus、Grafana 和日志记录解决方案，使您的团队能够了解系统运行状况和性能
- DevSecOps 集成：我们通过自动扫描、策略执行和漏洞管理将安全性嵌入到您的管道中
- 培训和支持：我们提高您的工程团队的技能，以拥有并扩展我们共同建立的 DevOps 实践
无论您是构建第一个部署管道的种子前初创公司还是迁移到 Kubernetes 的扩展公司，Workstation 都可以加速您的 DevOps 成熟度并帮助您充满信心地交付。 通过info@workstation.co.uk 联系我们以开始对话。