CNPA 模拟考 A

声明式资源管理和命令式资源管理之间的主要区别是什么？

• 声明式类型使用 YAML，命令式类型使用 JSON。
• 声明式类型描述了期望的状态，系统确定达到该状态的路径，而命令式类型允许人们一一指示达到该状态的过程。
• 声明式类型只能在 Kubernetes 中使用，而命令式类型可以在任何地方使用。
• 声明式形式总是比命令式形式执行得更快。

在声明式管理的工作负载中，有人直接访问集群并更改副本数量。这种情况叫什么？系统应如何处理？

• 这称为漂移，协调循环必须返回到声明的状态并使该事实可观察。
• 这称为修补程序，通常将其保留原样直到下一个版本发布。
• 这称为回滚，并且必须使用集群值更新声明的状态。
• 这称为故障，需要停止控制器以保留更改。

声明性清单必须具有的幂等性的正确含义是什么？

• 即使您多次应用相同的清单，结果状态也与应用一次相同。
• 每次应用清单时都会创建一个新资源。
• 仅按照清单中指定的顺序创建资源。
• 清单一旦应用就不能再次应用。

声明式方法不太适合的最合适任务是什么？

• 将相同的应用程序配置部署到多个环境
• 按命名空间管理资源限制
• 执行顺序和时间很重要的过程性任务，例如一次性数据回填
• 管理 Ingress 路由规则

将平台提供给用户的抽象转化为声明式 API 的最准确的操作优势是什么？

• 这必然减少用户必须填写的字段数量。
• 记录所需的状态，以便可以对同一目标执行审查、审核和恢复。
• 平台团队无需编写自己的控制器
• 不会发生运行时错误

在三种所谓的 DevOps 方法中，哪一种最适合作为平台中实现的“反馈”示例？

• 将部署管道的各个阶段分解为更小的块
• 平台团队每周举行回顾会议
• 长期保留构建工件
• 配置错误是在开发人员提交时通知的，而不是在部署时通知的。

在平台上练习“左移”时常见的错误有哪些？

• 它只是将测试向前推进，并没有为开发人员提供在本地运行相同测试的方法。
• 推进检查，同时保持部署前的检查
• 在测试失败信息中写出修正方法。
• 以代码形式管理检查规则并留下版本

为了无可指责的事后剖析，哪一个最准确？

• 确定责任人但未采取纪律处分
• 通过记录失败来为审计做好准备
• 即使人们做出了合理的判断，也要找出系统中导致事故发生的条件。
• 通过减少停机时间来保护 SLO

什么工作最符合SRE对辛苦的定义？

• 为新功能创建设计文档
• 首先分析故障原因
• 确定下一季度平台的路线图
• 每次发出请求时，人们都会使用相同的过程创建名称空间。

为什么在从开发升级到暂存再到生产时需要传输相同的容器映像摘要？

• 如果针对每个环境进行重建，则在暂存中验证的内容和在操作中显示的内容可能是不同的输出。
• 针对每个环境进行重建会增加注册表存储空间。
• 修复摘要将加快图像池化速度。
• Kubernetes 无法使用标签检索图像

环境平价被打破时的典型症状是什么？

• 构建时间因环境而异，因此很难预测管道将花费多长时间。
• 在登台中通过的更改只会在生产中失败，并且原因跟踪会针对环境差异而不是应用程序。
• 随着镜像的积累与环境数量一样多，注册表存储容量也会迅速增加。
• 开发人员将无法在本地运行像生产这样的容器

为每个拉取请求启动临时预览环境的最大优势是什么？

• 共享暂存环境可以完全消除
• 减少操作环境中的资源使用
• 每个变更都有一个独立的验证点，因此无需等待共享环境。
• 无需编写测试代码

如何按照基础设施不可变的原则进行操作？

• 将补丁应用到正在运行的实例并重启实例
• 使用配置管理工具融合正在运行的服务器的设置
• 连接到故障节点，修复原因，然后继续使用它。
• 创建一个新镜像来替换该实例并丢弃旧实例。

平台应阻止在部署清单中使用映像标签latest的主要原因是什么？

• 无法确定正在运行的代码，没有回滚和事件分析的参考点。
• 注册表自动删除latest标签
• latest始终将映像池策略设置为从不。
• 标记有latest的图像无法签名

内部开发者平台的Integration and Delivery Plane负责什么？

• 为开发人员提供输入请求的界面
• 连接从源到可执行输出的构建、验证和部署路径。
• 提供集群、数据库等物理资源
• 收集并显示指标和日志

在决定自己创建平台功能还是使用现成产品时，最合适的标准是什么？

• 该职能是组织的差异化因素，还是一个在任何地方都以相同方式解决的问题？
• 提供该功能的产品是开源的还是商业的？
• 平台团队中是否有人已经了解该技术？
• 现成产品的年授权费是否比负责人的人工成本便宜？

将租户划分为命名空间的软多租户最准确的限制是什么？

• 每个命名空间都需要一个单独的 API 服务器，从而增加了成本。
• RBAC 不能应用于命名空间内
• 由于它共享节点内核和控制平面，因此无法防止内核级逃逸或集群范围的资源冲突。
• 如果命名空间不同，服务之间的通信是完全不可能的。

当需要打破平台提供的功能的向后兼容性时，采取什么方法最合适？

• 新版本一起提供，并有处置和转移信息的通知期，根据使用情况确定终点。
• 下次部署时立即更换，并在发生故障时单独响应。
• 永久保留旧版本，使新版本可选
• 仅在发行说明中记录更改，不通知用户。

当根据“能力”定义平台的功能列表时，该建议意味着什么？

• 这意味着创建一个包含已安装工具名称的列表。
• 这意味着定义用户获得的结果，例如“保护数据库”，并留下实施工具。
• 这意味着为每项职能指定一名负责人。
• 这意味着根据 Kubernetes 资源的类型来划分功能。

最薄可行平台的概念建议从什么出发点？

• 从最少的必要内容开始，但如果即使一份组织良好的文档有帮助，也可以将其视为一个平台。
• 全部核心功能完成后立即发布
• 首先安装所有最流行的开源工具
• 首先构建开发者门户，然后添加功能。

平台团队决定下一步构建什么的最可靠来源是什么？

• 行业趋势新技术一览
• 管理层要求的功能列表
• 确定我们想要在平台团队中创建的内容的优先级
• 在用户访谈和支持请求记录中反复发现的摩擦点

平台团队实际上已经回到售票窗口的最明显迹象是什么？

• 使用该平台的团队数量正在增长
• 新功能请求正在通过记录的流程接受
• 平台团队的大部分时间都花在处理各个团队的请求上。
• 平台团队实行轮班制。

自助服务和“愿意做任何事情”之间最准确的区别是什么？

• 自助服务必须包括审批流程
• 自助服务是指允许用户在安全的默认设置和护栏内自行完成任务。
• 自助服务仅打开读取访问权限。
• 自助服务意味着允许用户直接连接到集群。

首次引入平台时选择试点团队最合适的标准是什么？

• 组织中最大的团队
• 运行最复杂的遗留系统的团队
• 团队的座位距离平台团队较近
• 一个有明显摩擦、愿意合作、有对其他团队有说服力的成功故事的团队。

当平台的用户群分为新开发人员和经验丰富的团队时，最合适的设计策略是什么？

• 所有设置项均根据技术团队的需要按原样公开。
• 仅公开最少数量的设置项目以适应新开发人员并修复其余部分。
• 立即开始使用安全默认值，但为需要它的团队保留通往较低层的路径。
• 针对两个用户群搭建不同的平台并分别运营

当平台采用被纳入强制监管时，指标会发生什么变化？

• 使用率看起来很高，但这些数字不再解释该平台的有用性。
• 使用率和满意度共同提升
• 利用率仍然较低，因此可以及早发现问题
• 将不再收集使用指标

哪种实践最符合持续集成的定义？

• 引入 CI 工具并配置管道
• 所有开发人员经常将他们的工作整合到共享分支中，并每次都通过自动构建和测试进行验证。
• 一旦功能完成，就会在代码审查后合并。
• 将测试覆盖率保持在一定水平之上

当共享分支的构建被破坏时，出现的最大问题是什么？

• 随着构建服务器重复执行失败的任务，资源使用量会增加。
• 失败的执行被排除在计数之外，从而减少测试覆盖率。
• 之后，提交的验证结果变得不可靠，整个团队开始忽略失败信号。
• 失败构建的中间输出会累积，导致工件存储容量不足。

使构建可重复的要求对平台意味着什么？

• 无论您何时何地从同一提交构建，都会产生相同的输出，因此验证结果可以归因于输出。
• 构建时间始终保持不变
• 这意味着不使用构建缓存。
• 这意味着构建始终在同​​一构建服务器上执行。

持续交付和持续部署有什么区别？

• Canary 用于交付，Blue Green 用于分发。
• 这意味着交付仅在分阶段之前是自动化的，而部署在运行之前都是自动化的。
• 交付是让版本随时可供部署，而分发是在无需人工批准的情况下自动将该版本投入生产。
• 两者含义相同，不同地区叫法不同。

在 GitOps 的原则中，“持续协调”需要什么？

• 声明的状态与实际状态不断进行检查，发现的任何差异都会自动缩小。
• 每次提交时，管道都会运行部署命令
• 分发历史记录在 Git 中
• 所有更改都通过拉取请求

我们想要找出当一个请求经过多个服务时延迟发生在哪里。什么信号最好？

• 按服务划分的 CPU 利用率指标
• 每个服务的应用程序日志
• Kubernetes 事件历史
• 每个请求的分布式跟踪

如果我将用户 ID 或请求 ID 之类的值添加到指标标签中会发生什么？

• 由于重复的指标名称而导致收集失败
• 随着时间序列数量随着值数量的增加而增加，存储和查询成本迅速增加。
• 标签值不会发送到日志
• 公制精度低

当平台采用 OpenTelemetry 作为测量标准时，获得的最大好处是什么？

• 降低观测数据的存储成本
• 无需修改应用程序代码即可收集所有信号
• 通过将测量方法与后端分离，即使更换存储和分析工具，也无需再次测量应用程序。
• 指标、日志和跟踪自动集成到一个屏幕中。

平台默认将可观察性构建到黄金路径中的最佳理由是什么？

• 节省观察工具许可费用
• 这是为了确保开发人员不必学习可观察性概念。
• 这是为了防止发生故障。
• 这是因为，如果每个团队的衡量方式不同，那么跨服务的相关性分析就变得不可能。

对于几乎耗尽错误预算的服务，最合适的操作是什么？

• 通过降低 SLO 目标来恢复预算
• 放慢部署新功能的步伐并优先考虑可靠性改进
• 通过放宽通知阈值来减少警报噪音
• 暂时停止该服务的 SLI 收集。

与单向 TLS 相比，将 mTLS 应用于服务间通信时可以获得哪些额外收益？

• 传输部分加密
• 自动更新证书
• 每个请求路径的访问控制
• 能够使用证书验证呼叫方的身份

如何引入符合零信任原则的网络策略？

• 对每个命名空间都有默认拒绝，并明确仅允许必要的通信。
• 允许所有通信并仅将危险目标列入黑名单
• 仅限制入口，保持出口畅通
• 仅将策略应用于生产命名空间

在考虑采用服务网格时，我们应该最诚实地考虑哪些成本？

• 必须使用特定于网格的 SDK 重写应用程序代码
• 如果使用mesh，则无法再使用网络策略。
• 添加了 Sidecar 和节点级代理作为延迟、资源和操作目标，并且故障情况下的调查范围增加了一层。
• 如果网格对流量进行加密，则无法收集观察数据。

CI阶段和入学阶段采用相同政策的最准确原因是什么？

• 这是为了将策略引擎的负载分配到两个地方。
• 这是因为 CI 提供快速反馈，而准入实际上会阻止绕过 CI 的路径。
• 这是因为CI考试是强制性的，录取结果仅供参考。
• 这是因为当准入 Webhook 失败时，CI 会阻止它。

验证准入政策和修改准入政策有什么区别？

• 验证是在每个命名空间的基础上应用的，并且转换仅在每个集群的基础上应用。
• 验证仅适用于创建请求，转换仅适用于更新请求。
• 验证同步运行，转换异步运行。
• 验证通过或拒绝请求，转换在保存之前修改请求。

向现有集群引入新策略的建议顺序是什么？

• 首先在审计模式下检查违规状态，经过警告阶段，然后提升为阻止。
• 从一开始就采取阻止措施，立即消除违规行为
• 阻止从操作命名空间开始应用，然后扩展到子环境。
• 不应用该政策，仅提供书面指导并向违规团队提供个人指导。

将策略管理为代码的最准确的好处是什么？

• 由于规则是在代码中固定的，因此不会发生违反策略的情况。
• 由于规则驻留在存储库中，因此无需单独的策略引擎即可强制执行它们。
• 策略本身可以进行审查、测试并恢复到版本，因此规则更改遵循与代码更改相同的步骤。
• 审核员无需直接访问集群即可检查合规性。

在设计授予租户团队的角色时，最危险的选择是什么？

• 授予对命名空间内的部署和服务的编辑权限。
• 授予查看 pod 日志的权限
• 授予在命名空间内创建 ConfigMap 的权限。
• 为了方便起见，将集群角色与作为通配符打开的资源和动词绑定。

关于 Kubernetes 机密，以下哪项是正确的？

• 秘密值在存储时会自动加密，因此不需要特殊操作。
• 由于该值仅采用base64编码，因此在存储时必须提供单独的加密和访问权限限制。
• Secrets 不能挂载到 Pod 中，只能作为环境变量传递。
• 秘密会跨命名空间边界自动共享

为什么我建议默认关闭服务帐户令牌的自动安装？

• 这是因为即使不需要访问 API 服务器的 pod 也有令牌，因此一旦发生漏洞，攻击者会立即获取 API 凭据。
• 这是因为令牌挂载会显着增加 Pod 启动时间。
• 这是因为一旦安装了令牌，就不会应用网络策略。
• 这是因为令牌文件增加了容器映像的大小。

SBOM 在软件供应链安全中最准确的作用是什么？

• 签名证明构建结果创建后未被篡改。
• 证明构建是在哪个源和环境上执行的
• 它列出了输出中包含的组件和版本，使您可以在披露新漏洞时立即找到影响范围。
• 检测运行容器中的异常行为并通知侵权尝试

当 CI 管道访问云资源时，建议使用什么替代长期静态访问密钥？

• 加密密钥并将其提交到存储
• 将密钥存储为管道变量，并为每个分支使用不同的值。
• 钥匙每 90 天手动更换一次。
• 使用 Workload Identity 证明您的身份，并接收每次运行的短期凭据。

确定管道中阶段的顺序时应遵循哪些原则？

• 将最重要的测试放在最后并做出最终决定。
• 首先进行快速、高失败率的测试，尽早停止不正确的更改。
• 首先进行慢速测试，以减少后续步骤中的等待
• 通过将步骤合并到一个任务中而不是将它们分开来减少执行时间

管道执行时间增加，因此开发人员不必等待结果。您应该首先考虑采取什么行动？

• 减少执行频率，每天只运行一次管道
• 通过删除缓慢的测试来减少执行时间
• 应用步骤并行性和依赖项缓存，并将长时间运行的检查移至提交后步骤。
• 增加构建服务器并指示开发人员等待

让平台为每个团队提供管道模板的最大好处是什么？

• 每个团队的管道执行时间变得统一
• CI 工具可以经常更改，因为团队无需学习管道语法
• 没有发生与管道相关的故障
• 安全扫描和签名等基本步骤在一个地方更新，而不是为每个团队重新创建。

事件指挥官在事件响应中最准确的角色是什么？

• 不是直接进行技术研究，而是分配角色、组织情况并管理决策点。
• 作为最有经验的工程师，我们直接主导原因分析。
• 撰写和分发客户通知
• 事故结束后确定责任

公共平台带来的风险中，哪些风险最应该体现在事件响应设计中？

• 平台团队有少量待命人员。
• 一个平台组件的故障将阻碍所有团队使用该平台。
• 平台用户没有接受过应对事件的培训；
• 该平台跨越多个云的事实

当操作事件正在进行并且怀疑先前的部署时，正确的优先级是什么？

• 准确查明原因后，分发准确的修复程序。
• 按顺序禁用对用户影响最大的功能。
• 等到下一个常规分发窗口再一起处理。
• 首先，恢复之前的部署以停止影响，然后找出原因。

什么充当 CI 和 CD 边界上的“契约”？

• 描述管道中步骤的定义文件
• 附加到源存储库的发布标签
• 已使用不可变标识符进行验证和修复的工件
• 批准部署的变更管理票证

CI 操作持有集群凭证并直接执行部署（推送模型）有哪些弱点？

• 与协调方法相比，分布反映的速度明显慢一些。
• CI系统总是对多个集群拥有强大的权限，部署后没有人负责维护状态。
• 无法在 CI 工具中创建特定于环境的清单。
• 在推送模型中，没有发布哪个版本以及何时发布的历史记录。

GitOps 的拉取模型有哪些安全优势？

• 允许您减少可以提交到存储库的人数
• 消除集群和存储之间的网络通信需求
• 即使您在清单中以纯文本形式包含机密，存储也会变得更安全。
• 由于集群内的代理会读取存储库，因此无需将集群凭据移交给外部系统。

分离应用程序源存储库和部署清单存储库的最佳理由是什么？

• 这是因为清单存储库可以完全开放访问权限。
• 这是因为 Kubernetes 无法同步具有混合源代码的存储库。
• 这是因为导致部署和代码更改提交的提交不会混合，因此可以单独处理部署历史记录和批准流程。
• 这是因为将清单放在单独的存储库中可以加快同步速度。

如果由于紧急情况手动修改 GitOps 管理的集群中的集群，会发生什么情况？

• 协调循环自动反映对存储库的更改。
• 更改将在下一个协调周期中恢复，因此如果操作未反映在存储库中，操作就会丢失。
• 相关应用程序的同步将永久中断。
• 保留更改并自动锁定存储库

通过为每个环境设置单独的分支来管理环境之间的差异有什么问题？

• 随着分支数量的增加，存储库大小和克隆时间都会增加。
• 部署前无法验证放置在分支上的清单
• 协调工具不跟踪默认分支以外的分支
• 环境之间的合并冲突会重复出现，并且反映在哪个环境中的内容分散在提交图中，因此很难知道。

在 GitOps 环境中从暂存阶段升级到生产环境的最合适的操作是什么？

• 上传反映在生产环境清单中暂存时验证的映像摘要的提交。
• 运行命令以更新生产集群上的映像标签
• 暂时关闭操作环境中的调整，并在部署新版本后重新打开。
• 将资源从暂存命名空间复制到生产命名空间

Kubernetes 控制器“级别触发”运行是什么意思？

• 这意味着控制器根据资源的优先级来处理资源。
• 这意味着将事件存储在队列中，这样您就不会错过任何更改通知。
• 这意味着着眼于当前状态本身，而不是变化事件，并缩小与期望状态的差距。
• 这意味着只有当差异超过一定程度时才会进行调整。

在自定义资源中分离spec和status的角色正确的是？

• spec由控制器使用，status由用户使用。
• spec是用户声明的期望状态，status是控制器记录的观察到的实际状态。
• 两者都是由用户编写的，控制器只读取它们。
• status是用户不可见的内部字段。

当外部 API 调用在协调期间失败时，控制器采取的最合适的操作是什么？

• 将资源标记为错误状态，不做进一步处理
• 立即重复相同的调用，直到失败
• 关闭控制器并在重新启动时从头开始重试。
• 将错误保留在状态中，并使用指数退避重新排队以重试。

为什么 OpenAPI 模式验证紧密集成到平台提供的自定义资源中？

• 这是因为 API 服务器会在存储之前拒绝不正确的值，从而在提交时而不是部署后显示错误。
• 这是因为如果有模式，资源就可以运行而无需编写控制器。
• 这是因为需要架构验证才能在命名空间范围内创建自定义资源。
• 这是因为如果您有架构，则无需编写单独的 RBAC 规则。

平台提供的自定义资源从v1alpha1升级到v1时如何减少对用户的影响？

• 只保留新版本并强制用户重新创建现有对象
• 使用不同的 CRD 名称注册两个版本。
• 在一个 CRD 中提供两个版本，指定保存的版本，然后在必要时使用转换 Webhook 交换两个表达式。
• 禁用调整控制器，直到推出新版本

在设计平台API时，如果将Pod规范的所有字段都原样暴露出来，会出现什么问题？

• API服务器的验证成本变得过高。
• 随着抽象的消失，用户的认知负荷保持不变，平台没有空间改变其内部实现。
• 超出自定义资源的大小限制
• Kubernetes 不允许重复的字段定义

将数据库或存储桶等云资源配置为 Kubernetes 自定义资源有哪些好处？

• 云提供商费率降低
• 基础设施资源无状态漂移
• 基础设施配置比专用工具更快
• 应用程序和基础设施在相同的声明性模型和相同的协调和权限系统中进行管理。

处理作为自定义资源管理的云资源时必须确定什么？

• 是否为每个资源拥有单独的集群
• 删除自定义资源时是否删除或保留实际资源的策略
• 用于资源名称的前缀规则
• 将在一天中的什么时间执行配置。

用一句话最准确地描述运算符模式是什么？

• 这是一种通过将应用程序捆绑到模板中来分发应用程序安装的方法。
• 这是一种将管理权限委托给集群操作者的RBAC设计方法。
• 该方法将特定应用程序的操作知识传输到控制器代码中，并允许协调循环执行备份和故障转移等任务。
• 它是一种联合方法，可在一个控制平面中处理多个集群。

在引入某种中间件时，判断一个包图是否足够，或者是否需要一个算子，最合适的标准是什么？

• 该中间件是在磁盘上存储状态的中间件吗？
• 社区已经创建并提供了算子吗？
• 是否需要安装大量 Kubernetes 资源？
• 即使安装完成后，是否还需要持续进行备份、扩容、版本升级等操作判断？

将渐进式披露应用于屏幕以创建新服务的最佳示例是什么？

• 基本屏幕仅询问名称、团队和语言，资源大小和缩放设置留给高级项目。
• 所有设置项目都集中在一个屏幕上，并提供搜索功能。
• 将设置项目分成几个步骤，依次输入。
• 删除配置项并让平台团队设置值

服务脚手架模板对开发人员体验的最大贡献是什么？

• 通过减少编写的代码量来加快开发速度
• 防止团队使用不同的框架
• 存储库创建时间缩短
• 存储库、管道、观察和所有者信息从一开始就作为标准连接。

防止软件目录中的信息过时的最有效方法是什么？

• 要求团队每季度更新一次目录
• 将目录元数据放置在服务存储库中，以便可以与代码一起更改和审查。
• 将目录编辑权限限制给平台团队。
• 显示目录中的最后修改日期，以帮助您识别较旧的项目

为什么服务目录不仅要在屏幕上提供，还要以 API 的形式提供？

• 这是因为API的响应速度比屏幕的响应速度快。
• 这是因为存储目录数据的成本降低了。
• 这是因为管道、策略检查和 oncall 工具可以自动查询和使用所有者和依赖项信息。
• 这是因为需要 API 来授予对目录的访问权限。

如何才能防止您的开发者门户成为链接的集合？

• 较低层的功能必须以可执行的方式链接起来，以便门户网站能够真正完成工作。
• 门户设计和搜索功能有待完善。
• 所有内部工具的链接都必须毫无例外地注册。
• 门户访问必须指定为公司的标准起始页。

仅通过门户访问来衡量开发人员体验有哪些局限性？

• 访问计数难以收集且准确性较低。
• 访问次数因团队规模而异，因此比较困难。
• 访问次数引发隐私问题
• 人们因为找不到某样东西而反复回来的情况和他们使用得很好的情况是相同的。

将基于人工智能的助手附加到平台时，最重要的设计原则是什么？

• 使尽可能多的操作任务能够自动运行，无需人工批准
• 确保您创建的任何清单或操作都通过现有策略检查和审批流程，确保自动化不会绕过护栏。
• 通过减少检查步骤消除延迟，确保模型输出可靠
• 通过提供对运营数据的广泛访问来提高响应质量

为什么我们要衡量新加入的开发人员将其第一次提交部署到生产环境需要多长时间？

• 这是因为你可以一次性检查平台是否真正兑现了“快速启动”的承诺。
• 这是因为它是客观评价新员工能力的基础。
• 这是因为它是计划下个季度的员工数量的必要值。
• 这是因为您可以决定新的培训课程将组织多少周。

在计算平台采用率时，“积极使用”的最合适定义是什么？

• 发行平台账户的团队数量
• 最近一段时间通过平台路径实际部署变更的团队数量
• 至少访问过一次门户的用户数量
• 查看平台文档的团队数量

当使用平台指标来比较排名并评估团队之间的绩效时会发生什么？

• 团队之间存在良性竞争，从而提高了整体指标。
• 指标收集成本增加
• 测量周期应较短
• 指标成为目标，采取行动增加数字，指标不再告诉我们真实的状态。

SPACE框架与DORA指标的补充最准确的点是什么？

• 更准确地衡量部署管道的性能
• DORA允许在更短的周期内计算四个指标
• 我们关注仅通过系统交付速度无法看到的维度，例如满意度、协作和工作效率。
• 将故障指示器划分为服务单元

DORA变革失败率的正确定义是什么？

• 运营中反映的导致服务质量下降、需要立即采取行动的变化的百分比
• 管道中失败构建的百分比
• 代码审查中拒绝的拉取请求的百分比
• 执行回滚的部署中成功回滚的百分比

DORA 的变更提前期是用什么部分来衡量的？

• 从收到需求到运营部署
• 从构建开始到构建结束
• 从部署开始到流量转化结束
• 从提交代码到更改在生产中生效为止。

对于部署频率高但变更交付时间长的组织来说，最合理的解释是什么？

• 由于两个指标不能同时成立，因此计算时存在误差，必须重新测量。
• 很有可能在部署提交之前等待批准或陷入集成瓶颈，并且累积的更改会立即全部发布。
• 这意味着部署自动化已经到位，因此没有进一步改进的空间。
• 这意味着由于测试覆盖率较低，验证正在被部署所取代。