AI 基础
什么是 DevOps？开发与运维详解
将 Unite.AI 添加到您在 Google 上的首选来源
DevOps是一种社会技术方法，将软件开发和运维整合到同一个反馈系统中。团队通过共享所有权、版本控制、自动化、可观测性以及小规模可逆的变更来提升交付速度和服务可靠性。
DevOps 本身不是职位名称，也不是一套工具。持续集成服务器无法修复那种奖励开发者快速交付却让运维人员对所有故障负责的激励机制。
关键要点
- 小批量和快速反馈降低了变更的成本和风险。
- 持续交付确保软件始终可发布；持续部署在通过预定义门槛后自动发布变更。
- 可观测性和事故学习将生产行为与规划和工程相连接。
- 有用的指标在吞吐量与稳定性之间取得平衡，而不是仅仅追求部署频率的最大化。
共享所有权与工作流
跨职能团队从设计到运维全程拥有服务。工作可视化，变更经过审查，依赖被降低，使功能能够在系统中流动而无需长队或交接。
目标是实现可持续的价值流动，而非持续的紧迫感。限制在制工作，自动化重复检查，并使变更足够小，以便理解和逆转。
版本控制、CI 与自动化测试
应用代码、基础设施定义、配置和策略应可审查且可复现。持续集成频繁合并小的变更，并运行自动化构建、测试和安全检查。
绿色流水线仅能证明其所包含的检查。单元测试、集成测试、契约测试、安全测试和性能测试覆盖不同风险。类似生产环境的测试环境以及受控的测试数据可以降低意外，但不应假装预发布环境与真实环境完全一致。
持续交付与安全部署
持续交付通过自动化流水线生成可发布的制品。金丝雀、蓝绿发布和功能标记等部署策略在观察遥测的同时限制曝光范围。自动回滚需要可靠的信号，并且不应破坏诊断所需的证据。
基础设施即代码使环境可审查，但状态、凭证和供应商行为仍需受控。通过威胁建模、依赖控制、制品来源追溯和最小权限，尽早整合网络安全。
运维、观察与学习
指标、日志、追踪和用户信号展示服务是否达成目标。对需要采取行动的症状进行告警，定义服务级别目标，并在故障发生前准备好事故响应角色。
无责学习审视技术和组织层面的因素，同时不剥夺责任。后续工作应提升检测、缓解、沟通和系统设计，将 DevOps 与 ITOps 以及站点可靠性工程相连接。
衡量成果与管理权衡
DORA 研究通常使用部署频率、变更交付周期、变更失败率和服务恢复时间等指标，并将可靠性与交付并列考虑。指标应揭示约束，而非成为团队可以操纵的目标。
成功的实践能够提升客户成果、安全性和恢复能力，同时降低重复性工作。受监管的系统可能需要明确的审批和证据；DevOps 可以对这些控制进行自动化和记录，而不是绕过它们。
DevOps 原则与交付流
DevOps 将软件开发与运维围绕快速、可靠的交付和共享所有权进行对齐。它融合了文化、产品思维、自动化、度量和持续学习；单纯的团队、工具或职位并不等同于 DevOps。绘制从创意到实际变更的价值流，包括审批、排队、环境、部署和恢复。降低交接次数和批次规模，使工作可视化，并为产品团队提供来自生产环境的反馈，同时在风险需要时保留独立监督。
持续集成频繁合并小的变更并运行自动化构建和测试。持续交付保持制品可发布；持续部署在通过门槛后自动发布。基础设施即代码、配置管理、不可变制品以及环境一致性提升了可复现性。制品应只进行一次版本化并进行提升，而不是在每个环境重新构建。功能标记将部署与曝光分离，但需要负责人和退役机制。数据库变更必须保持向后兼容，并经过回滚或前滚的测试。
可靠性、可观测性与事故学习
可观测性将日志、指标、追踪、性能分析、部署和所有权与系统行为问题关联起来。根据用户体验定义服务级别指标和目标，然后使用错误预算在可靠性工作和变更之间取得平衡。自动化应包括超时、带抖动的重试、幂等性、健康检查、容量限制以及优雅降级。通过演练日和恢复演练来测试故障，而不仅仅是顺畅路径的流水线。
事故响应需要值班角色、严重程度、沟通、应急手册、授权以及无责审查。事后回顾重建导致事故的技术和组织因素，并跟踪纠正工作。平均恢复时间可以提升，但如果复发率仍高，则需要衡量检测、失败变更、恢复、重复工作和重复原因。避免使用指标对个人进行排名；它们描述的是一个社会技术系统。
安全性与度量
通过最小权限的 CI 身份、隔离构建、依赖控制、SBOM、签名、来源追溯、密钥管理以及带有受控例外的策略门来保障软件供应链安全。将交付周期、部署频率、变更失败率、恢复、可靠性、安全风险和开发者体验等指标一起度量。仅在增加故障的情况下优化部署次数并不算进步。DevOps 成功的标志是团队能够进行小规模、安全、可观测的变更并快速学习——而不将运维负担或风险转嫁给用户。
实战示例：安全的服务部署
团队通过审查后的代码以及自动化的单元、集成、安全和契约测试合并一个小的 API 变更。隔离构建生成一个带有 SBOM 和来源信息的签名制品。该制品被提升到预发布环境，随后金丝雀实例接收有限的生产流量。仪表盘比较错误率、延迟、饱和度和业务结果与旧版本的差异，同时功能标记独立于部署控制曝光程度。
如果错误预算或安全阈值被超出，自动化会停止 rollout 并回滚或禁用该功能。数据库变更保持向后兼容，直至旧代码退役。事故通道将日志、追踪、所有者和变更关联起来。稳定运行后，团队移除功能标记和过时的模式。指标涵盖交付周期、失败变更、恢复、可靠性和用户结果。流水线在保持证据和人为授权的前提下，使安全路径快速实现。
实施证据与运营准备
生产决策需要的不仅是一次成功演示。需明确预期用户、运行环境、输入、输出、依赖、所有者以及每个关键故障的后果。在调优前建立可复现的基线和版本化的评估集。测试常规案例、边界条件、格式错误或缺失的输入、分布漂移、依赖中断、误用以及最可能被忽视的群体或环境。将任务质量与校准或不确定性、延迟、吞吐量、资源成本、可访问性、隐私和安全一起度量。记录每一次转化和阈值，以便独立审查者能够复现结果，并将证据与诱人的原型区分开来。
在上线前，分配发布、例外、变更、回滚和退役的权限。采用分阶段 rollout，保留安全回退，并通过有意注入的故障验证监控。运营遥测应揭示输入质量、输出行为、模型或规则版本、依赖健康、人为覆盖以及已确认的结果，而不收集不必要的敏感数据。定义告警阈值和响应负责人，然后在部署后审查真实世界的证据，而不是假设离线性能会持续。每当数据源、用户、模型、供应商、策略、硬件或目标发生变化时都需重新评估。维护中的系统还需要有文档化的恢复、事故学习、删除与保留流程，以及明确的停用或替换时点。
常见问题
DevOps 与敏捷软件开发是同一回事吗？
不是。它们在反馈和小幅增量上有重叠，但 DevOps 将所有权和自动化延伸至部署和生产运维阶段。
DevOps 是否意味着每个开发者都必须随时待命？
不是。团队需要明确的服务所有权和生产反馈，但人员配置、轮值和升级流程应保持可持续并符合服务需求。
主要参考文献
