CTO DevOps 手册：简单原则和示例
作为公司首席技术官，务必把 DevOps 部分做好。
本手册旨在帮助您清晰了解 DevOps：
- 了解什么是 DevOps（用简单的话来说）
- 了解DevOps能实现什么（以简单目标为例）
- 获取简明的“何时做什么”DevOps 指南
我在文章末尾添加了一个额外内容。
这是一个可供参考的生产环境部署示例。
本文的目标读者是谁？
您可能是一位希望以正确方式开始使用 DevOps 的创始人。
你可能是一家拥有 1000 名员工的公司的首席技术官，希望获得一些简单的原则。
或者，也许你是一名软件工程师，你想了解你公司的 DevOps 方法是否有效。
如果你正在寻找一本简单的 DevOps 操作手册，那就是它了。
了解预期结果
贵公司需要具备的两项能力
- 向顾客提供产品
- 构建和改进产品
构建、改进和维护软件所需的能力
- 进行实验并测试更改
DevOps 的含义很简单
开发人员和运维人员共同承担构建和改进系统的责任。
实际操作中：
- 开发人员负责“运营”。
- DevOps工程师的职责是使系统能够“运行”，并且他们自己也要完成一些操作。
运营= 提供、监控、保护、配置、部署、扩展。
选择一种平衡：推动者、执行者或自动化者
DevOps角色最终将需要在以下两方面之间取得平衡：
- 赋能者：提供实现 DevOps 目标所需的工具和知识
- 执行者：执行实现 DevOps 目标的任务
- 自动化程序：自动执行任何重复性操作
了解应该启用、执行或自动化哪些操作。
- 提供基础设施
- 确保系统安全
- 部署工作负载
- 监控系统
- 从问题中恢复过来
- 放大或缩小
- 跟踪和测试变更
- 自动化流程
选择合适的工具
- 具备状态管理功能 = 节省自动化状态感知流程（例如 Terraform）的时间
- 拥有庞大的社区和完善的文档 = 节省处理常见问题（例如 Kubernetes）的时间
- 具有多种接口类型：API、CLI、UI = 节省与现有系统（例如 Vault）集成的时间
您也可以点击此处阅读有关选择工具的信息。
设定有意义的目标
遵循DevOps目标将使您朝着正确的方向前进：
- 一键式环境：让端到端测试变得轻松快捷
- 原子提交：确保经过测试的更改在生产环境中也能正常工作。
- 将共享部分和特定环境部分分开：随着公司规模的扩大，可以进行端到端测试。
如果您想了解更多有用的 DevOps 目标，欢迎在此预约免费咨询。
赋能因素：选择工具与知识的平衡
开发者要么拥有完成某件事所需的知识，要么拥有完成某件事所需的工具。
- 更依赖知识：如果你希望开发人员为 DevOps 工作做出贡献。
- 更依赖工具：如果你想将操作对开发人员进行抽象化。
如果两者之间的平衡并非有意为之，那就是偶然的。
行动者：做事要有充分的理由
- 这是一次性任务吗？
- 它能教会你开发者是如何工作的吗？
- 你是否直接对任务结果负责？
如果您对以上问题的回答为“否”，请启用或自动执行该操作。
多做练习 = 学习系统的使用案例
做得太多 = 无法规模化，过度依赖知识
自动化者：要有充分的理由进行自动化。
- 以前发生过吗？
- 这种事有可能再次发生吗？
- 自动化操作会比手动操作更省时间吗？
- 自动化操作能让你了解公司一项重要的流程吗？
如果您对 4 个问题中的 2 个回答“是”，请将其自动化！
自动化程度越高，对操作系统的专业知识依赖就越少。
自动化程度过高会导致系统感知能力下降。
PS：您还可以允许开发人员自动执行此操作。
创建可用的 DevOps 容量
公司的DevOps需求会有高峰期。
一个月需要 2 名 DevOps 工程师，下个月只需要一半。
在大型项目和小型任务之间切换是很常见的。
这一点尤其适用于新公司。
打破“DevOps 任务必须由 DevOps 工程师完成”的假设。
DevOps 能力分为 3 种类型。
- 非灵活岗位：团队中的一名全职 DevOps 工程师
- 半灵活型：能够为DevOps目标做出贡献的关键开发人员
- 完全灵活：一家灵活的DevOps服务公司或自由职业者
您可以点击此处阅读更多关于计算公司所需 DevOps 容量的信息。
何时关注什么：常见困境
适用场景：你独自工作，且系统很简单
重点：简化开发——将应用 Docker 化，创建提交后运行测试的流水线
何时需要：您需要能够快速创建新环境（用于开发或为客户服务）
重点：实现“一键式环境”：使用 IaC（例如 Terraform）+ 部署工具（取决于平台）。
何时需要进行端到端测试：您希望对每一项代码修改进行测试，但代码修改数量众多。
重点：将“一键式环境”拆分为包含共享资源的“基础”环境和包含特定环境资源的“环境”环境。
何时需要：您希望统一和标准化工作负载的部署、监控、扩展、配置和安全方式
重点：实现类似 Kubernetes 的编排器
何时：当您的系统有很多活动部件，并且您希望确保经过测试的更改能够奏效时。
重点：实施 GitOps 并考虑使用单体仓库（越早越好）
何时：您希望 DevOps 工作由开发团队完成
重点：使用“真正的”IaC工具（Pulumi Typescript/Python），完整的“操作方法”（见上文）文档
切勿：在没有充分理由的情况下，投入大量时间研究新技术。
总是：
- 将你的代码放在 Git 中
- 监控基本要素：CPU、内存、磁盘、网络、应用日志、云费用
- 高可用性架构师
- 部署前进行测试
额外内容：CTO 接近生产环境时的示例设置
2 个 AWS 账户
- 一个用于开发和搭建
- 另一个用于生产
Github 中的 Monorepo
- 用于本地开发的 Docker-Compose
2 个基础设施即代码项目：'base' 和 'apps'
- 基础资源 = 共享资源（例如，VPC、RDS、ECS 集群、EKS 集群）
- apps = 特定于环境的资源（例如，Lambda 函数、ECS 服务、Kubernetes 命名空间）
- 每个环境一个配置文件
GitHub Actions 工作流：开发工作流
- 结账分支并本地开发+测试变更
- 创建拉取请求：将拉取请求的“apps”环境部署到“开发”环境“base”上
- 合并到主分支时：将“主”分支上的“apps”环境部署到“开发”环境“base”上。
- 手动：从“主”分支部署到“测试”/“生产”环境“基础”分支
设置说明
- 避免在条件资源部署的代码中提及环境名称。
- 使用每个环境的配置文件来声明是否应该创建资源。
- 可以使用 Terraform、Terragrunt、Pulumi、CDK 和其他 IaC 工具来实现。
- 为了实现高可用性，生产环境中的每个工作负载应该有两个实例。
如果您想在您的初创公司中看到这种设置，请点击此处预约通话👈🏼
PS：我会不定期更新此页面，所以您可能想再次访问。
另一个福利：面向普通人的DevOps词典
| 学期 | 定义 | 工具 |
|---|---|---|
| 环境 | 整个系统的运行实例 | |
| CI（持续集成） | 通过确定单一数据源（主分支/主分支），使开发人员能够协作。 | Jenkins、GitHub Actions、GitLab CI |
| CD（持续交付） | 创建一个可用于生产环境的制品（已测试、已标记） | JFrog Artifactory、Nexus、AWS ECR |
| CD（持续部署） | 所有可用的交付物（工件）都会自动部署。 | ArgoCD、Jenkins、AWS CodeDeploy |
| 监测/可观测性 | 从应用程序和基础架构中收集指标/跟踪/日志，对其进行分析和显示，并设置警报。 | Prometheus、Jaeger、Elasticsearch、Fluentd、OpenTelemetry |
| 基础设施 | 工作负载运行所依赖的资源、数据存储所依赖的资源以及网络流量所经过的资源。 | 服务器、数据库、网络路由器和交换机 |
| 云基础设施 | 与上述相同，但特指在云端。 | AWS EC2、AWS RDS、GCP Compute Engine、Azure 虚拟机 |
| 云 | 计算和数据服务由远程地点提供，供您构建系统。 | AWS、Azure、GCP |
| 容器化与虚拟化 | 利用内核和操作系统特性创建虚拟机或隔离进程（又称运行容器）的技术 | Docker、vSphere、KVM |
| 秘密管理 | 存储和检索敏感配置信息（例如，令牌、密码） | Hashicorp Vault、AWS Secrets Manager、SealedSecrets |
| 配置管理 | 通常指为工作负载准备服务器（例如，创建目录和文件，启动进程） | Ansible、Chef、Puppet |
| 版本控制 | 以版本控制的方式（Git）保存代码 | GitHub、GitLab |
| GitOps | 构建该系统与 Git 中描述的方法相同。 | Flux、ArgoCD、Jenkins |
| 单体仓库 | 公司的所有代码都存放在一个 Git 仓库中。 | NX，Turborepo |
| 聚雷波 | 不同组件使用多个 Git 仓库 | |
| 基础设施即代码 (IaC) | 使用幂等代码和状态管理创建云基础设施 | Terraform、Pulumi、CDK、Crossplane |
| 部署 | 执行、运行或安装这些工件 | ArgoCD、Jenkins、AWS CodeDeploy、脚本（Bash、Python 等） |
| 编曲家 | 将工作负载动态分配给节点池 | Kubernetes、Nomad、AWS ECS |
| 身份验证与授权 | 确保每个人、每项工作或每项资源只能访问必要的内容（其他工作和资源）。 | AWS IAM、OpenID、OpenVPN、Twingate、Istio |
| 服务发现 | 利用 DNS 暴露可用工作负载 | Consul、CoreDNS |
获取更多实用建议
我会在“MeteorOps Newsletter”上分享一些实用的小技巧。
你可以在这里订阅👈🏼