假设你是一家连锁餐厅的运营总监。你不必亲自颠勺，但你必须能回答四个问题：后厨多久能推出一道新菜？客人从点单到上菜要等多久？端上桌的菜里有多少做错了？发现做错后，多久能重做一道合格的端上来？这四个数字，决定了这家餐厅的“交付效能”。在云上造软件的世界里，这套答案叫 DORA 指标——谷歌 DevOps 研究与评估团队从数万家软件组织中提炼出的四把尺子：部署频率、变更前置时间、变更失败率、恢复服务时间。它回答的不只是“代码跑得快不快”，而是：你的团队能不能又快、又稳、又省钱地把价值送到用户手里。这篇文章，我们就用“餐厅后厨”这条主线，把 DORA 指标拆开揉碎，再连上 FinOps 的成本账本，让你从零看懂云服务团队的效能度量。

岗位关联

掌握 DORA 四指标，等于拿到了云服务团队效率的“体检报告”——无论你是 DevOps、SRE 还是 FinOps 分析师，这套语言都是你跟团队、老板、财务对齐“快不快、稳不稳、贵不贵”的通用度量衡。

目录
  1. 可视化演示
  2. 认识 DORA 四指标
  3. 部署频率解析
  4. 变更前置时间
  5. 变更失败率
  6. 恢复服务时间
  7. FinOps 成本联动
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

以部署频率、变更交付周期、变更失败率与恢复时间为指标，量化软件交付速度与稳定性。

本节配有交互动效（进入视口后自动加载，约 3KB）。

四大指标 部署频率 交付周期 失败率 DF+LT+CFR+MTTR 四指标量化交付

认识 DORA 四指标

米其林评星时，评委不会只看一道菜的卖相，而是用出品稳定性、上菜节奏、翻台效率等一整套标准打量后厨。DORA（DevOps Research and Assessment，DevOps 研究与评估团队）干的就是这件事：它不是某一种工具的性能指标，而是谷歌团队调研数万家软件组织后，提炼出的四把“后厨评审尺”。

这四把尺子分别盯着交付链条上的四个关键点：部署频率回答“多久能上新品”，变更前置时间回答“点单到上桌要多久”，变更失败率回答“上错的菜占多少”，恢复服务时间回答“错了多久能重做”。四个数字组合起来，就是一支团队真实的交付画像，缺了任何一个，画面都会失真。

根据四指标的表现，DORA 把团队划分为精英、高、中、低四档。精英团队能做到每天多次部署、前置时间不到一天、失败率低于 15%、恢复在一小时内；低效能团队可能一个月发不了一次版本，失败率却高得吓人。关键在于四指标互相联动：靠加班和堆人拉高单点指标，往往会让其他指标一起恶化。

把这四把尺子贴在后厨门口，你就能一眼看出问题：如果“上错菜率”很高而“上新频率”很低，多半是菜单太复杂、备料不足；如果“上菜慢”的老毛病总治不好，问题往往根本不在这道菜，而在整个后厨节奏。DORA 的价值，就是让你不看表象、直指病灶。

交付效能=⟨DF,LT,CFR,TTR⟩\displaystyle \text{交付效能} = \langle DF,\quad LT,\quad CFR,\quad TTR \rangle
交付效能不是单一分数，而是四把尺子组成的“体检套餐”，必须整体解读。
  1. DF（部署频率）衡量“多久能推出一次新菜品”，即单位时间内成功上线到生产环境的部署次数。
    DFDF
  2. LT（变更前置时间）衡量“从点单到上菜”的总耗时，即代码提交到生产环境生效的时间差。
    LTLT
  3. CFR（变更失败率）衡量“端上桌的菜做错的概率”，即引发故障的部署在所有部署中的占比。
    CFRCFR
  4. TTR（恢复服务时间）衡量“发现做错后多久能重做出来”，即服务从故障到恢复的时长。
    TTRTTR

部署频率解析

快餐连锁和新派餐厅的菜单更新节奏完全不同：麦当劳一年换几次限定品，而主打新式的餐厅每月推新菜单。部署频率（Deployment Frequency）就是“菜单更新的节奏”——团队把代码交付到生产环境的次数，是四指标中最直观、最先被看到的一项。

频率的数字本身不含褒贬，关键看发布批量。一次部署塞进去三四十个功能，风险像一锅乱炖，哪个环节出错都难排查；拆成小批量高频发布，每道菜都是小份试做，坏了只浪费一小份。所以 DORA 从不单独提倡“越快越好”，而是把频率和失败率放在一起看，频率越高、失败率还越低，才算真本事。

自动化是高频的底气。流水线把构建、测试、容器镜像、基础设施编排全部自动化，人工审批降到最少，部署变成按一个按钮甚至完全自动触发。CI/CD 工具链就相当于后厨的“标准作业程序”：一旦发布流程做到可重复、可验证、可回退，一天多次部署就不再有心理负担，反而成为一种肌肉记忆。

回到后厨：真正的名厨不是靠蛮力加速，而是把每道菜的流程标准化、备料提前完成，客人一来就能流畅出餐。高频部署的本质，是把“发版”从惊心动魄的大事件，变成喝水一样平常的小动作。

DF=NdeploysTperiod\displaystyle DF = \frac{N_{\text{deploys}}}{T_{\text{period}}}
把一段时间内的部署次数除以周期时长，得到“单位时间能上几次新菜”。
  1. 分子 \(N_{\text{deploys}}\)周期内成功完成的部署次数，只统计真正上线并生效的发布，部署后又回滚的不算成功。
    NdeploysN_{\text{deploys}}
  2. 分母 \(T_{\text{period}}\)观察周期的长度，通常取周或月，团队可根据发布节奏自行约定统一口径。
    TperiodT_{\text{period}}
  3. 整体比值把部署次数除以周期时长，得到“单位时间内的部署次数”，方便跨团队、跨周期横向对比。
    DF=NdeploysTperiod\displaystyle DF = \frac{N_{\text{deploys}}}{T_{\text{period}}}

变更前置时间

客人点完菜，最关心的不是厨师手艺多好，而是“多久能上桌”。变更前置时间（Lead Time for Changes）就是这道菜从下单（代码提交）到上桌（生产生效）的总时长。它不是部署那一刻的耗时，而是整段旅程的长度。

这段旅程通常跨越几个环节：代码评审、持续集成构建、自动化测试、环境准备、部署发布、线上验证。低效团队的这段路可能要走一两周，其中真正“写代码”的时间往往只有几小时——多数时间都堵在排队等评审、等环境、等审批上。就像一道菜等了三十分钟，真正下锅只有三分钟，其余时间全耗在传菜通道里。

缩短前置时间的杠杆不在最后一公里，而在中间的等待区：评审拆小并行、环境按需弹性创建、构建测试交给云上流水线并发执行、权限与合规检查尽量内建到流程里。每个环节缩短一点，整个旅程就从“按周计”缩到“按小时计”。团队常用的做法是统计每次变更各阶段耗时，找出占比最大的等待项，优先优化它。

上菜快不快的秘密，通常不在灶台上，而在切配间和传菜通道。聪明的餐厅盯的是“从下单到上桌”的整体时长，而不是抱怨哪口锅太慢，因为瓶颈往往藏在看不见的等待里——这正是前置时间这个指标最犀利的地方。

LT=Tproduction−Tcommit\displaystyle LT = T_{\text{production}} - T_{\text{commit}}
上菜时长的终点是“菜真正落到客人桌上”，而不是“菜从厨房窗口递出来”。
  1. \(T_{\text{commit}}\)代码提交并合入主干分支的时刻，这是计时的起点，评审前的本地修改不计入。
    TcommitT_{\text{commit}}
  2. \(T_{\text{production}}\)代码在生产环境生效、用户真正能访问到的时刻，部署完成但功能未对用户开启也不算。
    TproductionT_{\text{production}}
  3. 差值两者相减得到一次变更从诞生到上桌的完整耗时，通常用中位数反映团队常态，避免个别极端值误导判断。
    LT=Tproduction−Tcommit\displaystyle LT = T_{\text{production}} - T_{\text{commit}}

变更失败率

再好的餐厅也免不了上错菜。变更失败率（Change Failure Rate）就是那本“退菜登记簿”：一段时间内所有部署中，有多少引发了生产故障、需要紧急修复或回滚。它衡量的是“上桌的菜里，不达标的占多少”，直接关系客人（用户）的体验。

失败率与部署频率不是此消彼长的敌人。恰恰相反，DORA 调研揭示：精英团队的部署频率是低效团队的几十倍，失败率却只有其零头。秘密在于小批量发布——每次改动小、影响面窄、好排查，出了问题快速回退，失败带来的连带损失也小。大爆炸式发布反而因为一次牵动太多，出问题的概率和代价都成倍上升。

压降失败率靠的是“质量内建”：自动化测试成为发布门禁，代码评审聚焦业务逻辑而非格式，灰度发布让新版本先在 5% 流量上试跑，监控告警在用户感知前捕捉异常。质量不是上线前的“质检环节”，而是揉进每道工序的面团里。常见的诱因包括：缺乏测试覆盖、配置错误、依赖变更未验证、以及匆忙上线的人为失误。

“少上错菜”和“多上菜”不是二选一。优秀的后厨靠标准化菜谱和试菜机制，让每道菜无论多忙碌都保持稳定出品；优秀的工程团队靠小步快跑和自动化护栏，让发布变得更加频繁却更加可靠。

CFR=NfailedNtotal×100%\displaystyle CFR = \frac{N_{\text{failed}}}{N_{\text{total}}} \times 100\%
失败部署占全部部署的百分比，精英团队通常能控制在 15% 以内。
  1. 分子 \(N_{\text{failed}}\)统计周期内导致生产环境故障、需要热修复或回滚的部署次数。
    NfailedN_{\text{failed}}
  2. 分母 \(N_{\text{total}}\)同一周期内所有部署的总次数，无论成功与否都计入。
    NtotalN_{\text{total}}
  3. 乘以 100%把失败次数占比换算成百分比，方便对照 DORA 效能等级的阈值（精英通常低于 15%）。
    CFR=NfailedNtotal×100%\displaystyle CFR = \frac{N_{\text{failed}}}{N_{\text{total}}} \times 100\%

恢复服务时间

真正考验餐厅功力的时刻，是客人当场退菜：是让客人干等半小时，还是三分钟内重做一份并送上甜品赔礼？恢复服务时间（Time to Restore Service）就是“从退菜到补救完成”的时长——服务出故障后，团队把系统拉回可用状态要多久。

DORA 如此看重 TTR，是因为故障不可避免，能控制的只有响应速度。恢复时长的下限取决于架构：如果你能一键回滚到上一个稳定版本，或者流量秒切到蓝绿环境中的健康一侧，那大多数故障的恢复时间可以压缩到分钟级；如果只能一行行改代码热修复，恢复时长就完全不可控了。

支撑 TTR 的还有三根支柱：可观测性（日志、指标、链路追踪三位一体，让故障定位从“大海捞针”变成“按图索骥”）、故障预案与定期演练（混沌工程把“没演练过的应急流程”变成“肌肉记忆”）、以及明确的值班指挥体系（谁决策、谁执行、谁通报，避免事故现场七嘴八舌）。

餐厅为防止退菜危机，会提前备好半成品和标准补救流程；工程团队则用可回滚架构和反复演练，让“出事了怎么办”成为本能反应。恢复时间不只是应急指标，更是平时架构设计与组织准备的照妖镜。

TTR=Trestored−Tdegraded\displaystyle TTR = T_{\text{restored}} - T_{\text{degraded}}
从“服务开始降级”到“服务恢复可用”的时钟跨度，是事故损失的直接度量。
  1. \(T_{\text{degraded}}\)服务开始出现故障或降级的时刻，通常由监控告警的时间戳确定。
    TdegradedT_{\text{degraded}}
  2. \(T_{\text{restored}}\)服务恢复至正常水位、用户可以正常使用的时刻。
    TrestoredT_{\text{restored}}
  3. 差值两者相减得到“从坏到好”的恢复时长，它直接决定一次事故造成的可用性损失和成本损失。
    TTR=Trestored−Tdegraded\displaystyle TTR = T_{\text{restored}} - T_{\text{degraded}}

FinOps 成本联动

运营总监月底要对账：这个月光食材、水电、人工花了多少钱，真正卖出去并让客人满意的菜又有多少？FinOps（云成本优化与治理实践）就是云时代的“后厨财务对账”，它不只看账单总额，更看每道有效交付的菜花了多少成本。

把 DORA 指标接进成本账本，会产生奇妙的化学反应：失败的部署不仅浪费了构建、测试、发布资源，还可能让故障期间的流量和口碑双受损；冗长的前置时间意味着环境与人力都在空转等待。传统的云账单按资源类型分摊，根本回答不了“是哪个团队的低效交付在烧钱”——就像一张只写“燃气费、水费”的账单，看不出是哪个灶台最费火。

FinOps 的成熟做法是：按团队或服务维度拆分云账单，把成本归属到具体的交付单元；再除以有效交付次数（剔除失败部署），得到“单位有效交付成本”。这个数字同时驱动成本与效能的改进——降低失败率既是稳定性工程，也是直接而可量化的省钱手段。成本可视化看板把四指标与账单放在同一张图上，让工程师能直观看到自己的发布行为如何影响账单曲线。

账本不会骗人。当你把食材成本除以真正卖出去的菜而不是做菜次数，就会发现：那些频繁返工、反复试错的后厨，看似忙忙碌碌，实则每一道成功的菜都背上了几道失败菜的成本。DORA 与 FinOps 的联姻，就是让效率与成本在同一张报表上对话。

UC=CcloudDF×T×(1−CFR)\displaystyle UC = \frac{C_{\text{cloud}}}{DF \times T \times (1 - CFR)}
每“一次有效交付”的云成本：分子是总账单，分母是剔除了失败的有效部署次数。
  1. 分子 \(C_{\text{cloud}}\)统计周期内整个云资源账单总成本，包含计算、存储、网络和 CI/CD 流水线等一切云上开销。
    CcloudC_{\text{cloud}}
  2. 中间量 \(DF \times T\)部署频率乘上周期长度，还原出该周期内的总部署次数。
    DF×TDF \times T
  3. 成功比例 \(1 - CFR\)用 1 减去变更失败率，得到“有效交付”的占比，把失败部署从价值账本中剔除。
    1−CFR1 - CFR
  4. 整体比值总成本除以有效交付次数，得到“每次有效上菜的食材成本”，数值越低说明钱花得越值。
    UC=CcloudDF×T×(1−CFR)\displaystyle UC = \frac{C_{\text{cloud}}}{DF \times T \times (1 - CFR)}

AI 应用场景

云服务厂商的发布效能看板

阶段：开发运维一体化（CI/CD 可观测性）

解决的问题：传统看板只展示构建时长、测试通过率等孤岛数据，无法回答“我们到底能不能快速安全地交付”。DORA 四指标把交付抽象成四条可对比的效能尺子，帮助团队定位瓶颈：比如部署频率很低但失败率很高，说明发布流程过于集中、批次太大。

具体案例：某云上 SaaS 服务商每月发版 2 次却事故频发。引入 DORA 看板后，团队发现自己前置时间 70% 耗在人工代码评审与手工环境准备上，于是把环境预置自动化、评审拆小，部署频率从每周 0.5 次提升到每天 3 次，失败率从 25% 降到 8%。

FinOps 成本归因与效能联动

阶段：云成本治理（成本归属与优化）

解决的问题：传统云账单只按资源类型分摊，无法回答“是哪个团队的哪次低效发布在浪费钱”。用 DORA 指标做“成本分母”，把失败部署、冗长等待环境的成本显式归因到交付行为上。

具体案例：某电商公司大促前发现 CI 集群成本翻倍，核算后发现 60% 的构建来自失败重试与重复流水线。通过提升变更前置时间的可见性、实施“失败即停”的流水线策略，构建成本下降 45%，同时发布速度不降反升。

SRE 故障恢复体系

阶段：稳定性治理（可靠性工程）

解决的问题：故障恢复靠“大牛救火”，响应时间完全不可控。DORA 的恢复服务时间指标推动建立可回滚、可切换的基础设施与演练机制，让恢复不再是个人英雄主义。

具体案例：某金融云平台规定所有生产发布必须支持一键回滚，并每月执行一次混沌演练。半年后平均恢复时长从 90 分钟降到 15 分钟，达到精英效能水平，年度可用性从 99.9% 提升到 99.99%。

Python 演示

python63 行
import jsonfrom datetime import datetime # 模拟一个星期的部署记录# 字段含义：部署时间, 代码提交时间, 是否失败, 恢复耗时(分钟), 本次部署云成本(元)deploy_log = [    ("2025-03-01T10:00:00", "2025-03-01T01:30:00", False, 0, 320),    ("2025-03-01T18:20:00", "2025-03-01T15:00:00", True, 42, 680),    ("2025-03-02T09:10:00", "2025-03-01T22:40:00", False, 0, 410),    ("2025-03-02T16:45:00", "2025-03-02T12:10:00", False, 0, 355),    ("2025-03-03T11:30:00", "2025-03-03T06:20:00", True, 28, 720),    ("2025-03-03T20:05:00", "2025-03-03T17:30:00", False, 0, 390),    ("2025-03-04T10:40:00", "2025-03-04T08:15:00", False, 0, 305),    ("2025-03-04T19:55:00", "2025-03-04T16:50:00", False, 0, 380),]  def compute_dora(records, period_days=4):    """计算 DORA 四项核心指标"""    total = len(records)    failed = [r for r in records if r[2]]    # 部署频率：周期内部署次数换算为每周部署次数    df_per_week = total / period_days * 7    # 变更前置时间：每次部署从提交到上线的平均耗时(小时)    lead_times = [        (datetime.fromisoformat(r[0]) - datetime.fromisoformat(r[1])).total_seconds() / 3600.0        for r in records    ]    avg_lead = sum(lead_times) / total    # 变更失败率：失败部署占全部部署的比例    cfr = len(failed) / total * 100.0    # 恢复服务时间：失败部署的平均恢复时长(分钟)    ttr = sum(r[3] for r in failed) / max(len(failed), 1)    return {        "deploy_frequency_per_week": round(df_per_week, 2),        "lead_time_hours": round(avg_lead, 2),        "change_failure_rate_pct": round(cfr, 2),        "time_to_restore_min": round(ttr, 2),    }  def unit_cost(records, cloud_budget):    """FinOps 视角：每次有效交付的云成本"""    total = len(records)    failed = sum(1 for r in records if r[2])    effective = total - failed    return {        "cloud_budget": cloud_budget,        "effective_deliveries": effective,        "cost_per_effective_delivery": round(cloud_budget / effective, 2),        "wasted_by_failures": round(cloud_budget * failed / total, 2),    }  if __name__ == "__main__":    dora = compute_dora(deploy_log)    print("== DORA 四指标 ==")    for key, value in dora.items():        print(f"{key}: {value}")    cost = unit_cost(deploy_log, cloud_budget=8600)    print("== FinOps 成本联动 ==")    for key, value in cost.items():        print(f"{key}: {value}")
目的：用一条真实风格的部署流水日志，算出 DORA 四指标，再联动云账单算出每次有效交付的成本与失败浪费。
  1. failed = [r for r in records if r[2]]筛出所有失败部署记录，后面计算失败率和恢复时长都要用到。
  2. df_per_week = total / period_days * 7把 4 天的部署次数换算成“每周部署频率”，方便与行业基准对比。
  3. cfr = len(failed) / total * 100.0失败的部署个数除以总部署次数，得出变更失败率。
  4. ttr = sum(r[3] for r in failed) / max(len(failed), 1)把失败部署的恢复耗时求平均，max 防止除零。
  5. cost_per_effective_delivery": round(cloud_budget / effective, 2)云账单除以有效交付次数，算“每次有效上菜的食材成本”。
  6. wasted_by_failures"用失败率估算这笔周期里因失败部署浪费的预算金额。

常见误区

误区我一直以为部署频率就是多多益善，团队每天发布几十次就算效能顶尖了，其他指标低一点也没关系，反正四个指标各管各的。

正解餐厅不能为了“上新率”天天换菜单而让菜品质量崩盘。DORA 四指标是一份“套餐”，必须整体解读。高效团队往往是小批量、高频、低失败率同时成立——因为小批量发布本身就在降低风险。单独追频率会诱发碎补丁式发布，前置时间和失败率同步恶化，得不偿失。

为何常见：部署频率最容易从流水线日志里捞到，数字直观、汇报好看，于是被误当成唯一 KPI。

误区我以为前置时间就是 Jenkins 上构建加跑测试的那几分钟，构建跑完就算交付了，所以总想靠换更强的构建机来提速。

正解前置时间等于从代码提交到生产环境真实生效的整个“旅程”，包含代码评审、环境准备、部署、线上验证。就像“下单到上桌”包含切配、烹制、装盘、传菜全程，而不是只看炒锅那三分钟。很多团队的 CI 只占前置时间的一小部分，真正的瓶颈在排队等待环节。

为何常见：CI 的耗时是流水线里最显眼的一项指标，容易以偏概全，忽略了前后看不见的等待区。

误区我们是五人的小团队，一个月发一次版本，DORA 这套东西是给谷歌、亚马逊那种大厂用的，跟我没关系。

正解DORA 关注的不是团队规模，而是交付风险的暴露速度。再小的团队也会被一次失败部署打垮，甚至因为没有冗余而伤得更重。小团队反而更需要这四把尺子找出瓶颈：一个月发一次也可以算 DORA，先测出基线，再朝着小步快跑逐步优化。

为何常见：教程里的案例多为大型互联网公司，造成“与己无关”的错觉，忽略了方法论本身的通用性。

误区FinOps 不就是省钱吗？我把所有云资源都降配、只留最便宜的方案，账单最低就算成功。

正解FinOps 的目标是让每一块钱都花出价值，而不是追求最低账单。用 DORA 指标把云成本除以有效交付，才能识别真正的浪费：失败发布导致的重复构建、闲置环境、低效等待。便宜但交付不动的方案反而是最大的浪费——就像食材买得再便宜，做不出卖得出去的菜也是白搭。

为何常见：FinOps 的名字里带着“成本”，最直观的成果又是账单下降，很容易被窄化成“省钱运动”。

误区把告警阈值调低、多部署几个监控面板，故障恢复时间自然就快了，所以我把力气都花在堆监控指标上。

正解监控只是“看见”，恢复靠的是“能行动”——可回滚的发布形态、蓝绿切换能力、故障预案和定期演练。就像餐厅装再多摄像头也上不了菜，必须备好备料与标准补救流程，服务员才知道被退菜后怎么在五分钟内重做。没有行动能力的告警，只会让值班同学看着面板干着急。

为何常见：故障发生时最先被注意到的是监控告警，容易把“发现问题”当成“解决问题”。

面试题

Q1. DORA 四把效能尺子中，哪一项衡量“把新版本发布到生产环境的频率”？

单选题 · easy

  • A.部署频率← 正确答案
  • B.变更前置时间
  • C.变更失败率
  • D.恢复服务时间

答案：A。部署频率就是“多久能上一道新菜”，即单位时间内的发布次数；前置时间管“上菜多久”，失败率管“上错的菜”，恢复时间管“退菜后重做多久”。四者各司其职，选 A。

Q2. 变更前置时间从哪里开始计算？

单选题 · easy

  • A.从需求评审会议开始
  • B.从代码提交那一刻开始← 正确答案
  • C.从产品经理写文档开始
  • D.从上线评审通过开始

答案：B。前置时间 = 生产生效时刻减去代码提交时刻。代码提交是“客人点单”的动作起点，需求评审、写文档都属于备菜之前的事，不算进上菜计时。

Q3. 某团队一个月部署 40 次，其中 6 次部署引发了生产事故，其变更失败率是？

单选题 · mid

  • A.约 6%
  • B.约 15%← 正确答案
  • C.约 20%
  • D.约 34%

答案：B。变更失败率 = 失败部署数 ÷ 总部署数 × 100% = 6 ÷ 40 = 15%，对应精英团队“低于 15%”的参考阈值，选 B。

Q4. 关于部署频率与变更失败率的关系，正确的说法是？

单选题 · mid

  • A.部署频率越高，失败率必然越高
  • B.高频与低失败率可以同时达成← 正确答案
  • C.前置时间与部署频率互相矛盾
  • D.恢复时间只看监控工具好坏

答案：B。DORA 数据显示精英团队部署频率极高而失败率极低，关键在于小批量发布——改动小、影响窄、好排查。高频与低失败不是矛盾，而是同一套小步快跑实践的结果。

Q5. 精英效能团队的变更失败率通常低于？

单选题 · easy

  • A.低于 50%
  • B.低于 45%
  • C.低于 30%
  • D.低于 15%← 正确答案

答案：D。DORA 的效能等级划分中，精英团队的变更失败率阈值是 15%，低效能团队往往超过 30%。记住“精英低于 15%”这个数，就像记住米其林餐厅的退菜率极低一样。

Q6. FinOps 视角下，计算“单位有效交付的云成本”时，分母应该剔除？

单选题 · mid

  • A.全部部署的次数
  • B.剔除失败后的有效部署← 正确答案
  • C.夜间自动发布的次数
  • D.测试环境的部署次数

答案：B。有效交付成本 = 云账单 ÷（总部署 ×（1 − 失败率）），分母必须是“真正端上桌且没被退的菜”。失败部署的钱是白烧的，必须从价值账本中剔除，选 B。

Q7. 缩短恢复服务时间的最有效手段是？

单选题 · hard

  • A.提高监控告警灵敏度
  • B.构建可回滚的发布架构← 正确答案
  • C.增加运维值守的人力
  • D.延长部署前回归测试时间

答案：B。恢复时间的下限由架构决定：一键回滚或蓝绿切换能把恢复压缩到分钟级，而监控、人力、回归测试都只是辅助。就像餐厅被退菜后，最快的补救是后厨备好了半成品，而不是多请几个服务员盯着。

Q8. 以下哪些属于 DORA 四项核心指标？

多选题 · easy

  • A.部署频率← 正确答案
  • B.代码行数总量
  • C.变更失败率← 正确答案
  • D.单元测试覆盖率

答案：AC。DORA 四指标是部署频率、变更前置时间、变更失败率、恢复服务时间。代码行数和测试覆盖率是常用的工程度量，但不属于 DORA 的四个核心指标。

Q9. 下列哪些做法能同时改善部署频率与变更失败率？

多选题 · mid

  • A.小批量高频发布← 正确答案
  • B.自动化质量门禁← 正确答案
  • C.合并为大版本发布
  • D.灰度发布逐步放量← 正确答案

答案：ABD。小批量高频发布让每次改动小而稳，自动化质量门禁把住质量关，灰度发布把风险限制在一小撮流量里。把多个功能合并成大版本反而增大排查难度和失败概率，是错误选项。

Q10. 关于 FinOps 与 DORA 的联动，正确做法包括？

多选题 · hard

  • A.按团队拆分云账单← 正确答案
  • B.只按最低价选方案
  • C.用失败率评估浪费← 正确答案
  • D.闲置资源与交付无关

答案：AC。按团队拆分账单才能把成本归因到交付单元；用失败率估算重复构建和故障损失，正是 DORA 与 FinOps 的结合点。只求最低价会牺牲交付能力，而闲置资源恰恰是 FinOps 重点治理的浪费，与交付效率强相关，故 B、D 错误。