56 lines
4.8 KiB
Markdown
56 lines
4.8 KiB
Markdown
---
|
||
title: "CTP Topic 41 NFR's and Error Budgets"
|
||
type: source
|
||
tags: []
|
||
date: 2026-04-14
|
||
---
|
||
|
||
## Source File
|
||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-41-nfrs-and-error-budgets.md]]
|
||
|
||
## Summary（用中文描述）
|
||
- 核心主题：NFR（非功能需求）与 Error Budget（错误预算）在云转型和敏捷开发中的实践——SRE 团队如何驱动产品组与运维协作，满足客户期望，以敏捷方式确保运维要求，并理解错误预算边界以快速可靠地交付功能。
|
||
- 问题域：云环境下的可靠性工程、敏捷开发中的运维融合、NFR 的云原生落地
|
||
- 方法/机制：NFR Epic 模板将需求集成到 Sprint Backlog；Error Budget 通过 SLO/SLI 量化系统可容忍的不可靠程度；混沌工程主动注入故障验证系统韧性
|
||
- 结论/价值：Error Budget 归一化失败弥合开发与运维的鸿沟；NFR 应更具规范性并利用云原生服务；监控能力是衡量 Error Budget 是否达标的关键
|
||
|
||
## Key Claims（用中文描述）
|
||
- NFR 是评判系统运行的准则，Error Budget 是系统可容忍的最大故障时间，两者共同构成云环境下可靠性工程的基石
|
||
- AWS 共享责任模型将基础设施管理责任转移给云提供商，但公司必须在云中架构和管理服务以满足 NFR
|
||
- Error Budget = 1 - 可用性 SLO（如 99.9% SLO → 0.1% Error Budget），用于衡量系统在影响客户前可承受的不可靠程度
|
||
- Error Budget 将失败归一化为开发流程的一部分，弥合了开发与运维之间的文化鸿沟
|
||
- 混沌工程通过主动注入故障测试系统韧性，确保 NFR 得到满足
|
||
|
||
## Key Quotes
|
||
> "We want to drive collaboration across our product groups and operations to ensure our obligation to our customers." — Brendan Standing，SRE 协作目标
|
||
> "Error budgets normalize failure as part of the development process." — Error Budget 的核心理念
|
||
> "SLRs are quantifiable measures of reliability, SLOs define how a service should perform, and SLAs are customer-level agreements." — 三层服务等级体系
|
||
|
||
## Key Concepts
|
||
- [[NFR（非功能需求）]]：评判系统运行的准则，涵盖可用性、性能、安全性、可扩展性等维度；云环境下应更具规范性，充分利用云原生服务
|
||
- [[Error Budget（错误预算）]]：系统可容忍的最大故障时间，由 SLO 推导而来；用于归一化失败并驱动开发和运维决策
|
||
- [[SLO（服务等级目标）]]：定义服务应如何表现的绩效目标
|
||
- [[SLI（服务等级指标）]]：可量化的可靠性度量指标
|
||
- [[SLA（服务等级协议）]]：客户级别的正式协议
|
||
- [[SLR（服务等级需求）]]：服务等级需求，与 SLO 配套使用
|
||
- [[NFR Epic]]：将 NFR 模板集成到 Sprint Backlog 的敏捷实践，确保任何重大变更都考虑非功能需求
|
||
- [[Chaos Engineering（混沌工程）]]：主动注入故障以测试系统韧性，确保 NFR 得到满足
|
||
|
||
## Key Entities
|
||
- [[Brendan-Standing]]：Micro Focus SRE 负责人（Head of SRE），本视频主讲人
|
||
- [[AWS]]：Amazon Web Services，提供共享责任模型和云原生服务
|
||
- [[Micro-Focus]]：企业云转型主体，OpenText 旗下公司
|
||
|
||
## Connections
|
||
- [[ctp-topic-30-managing-change]] ← related_to ← [[ctp-topic-41-nfrs-and-error-budgets]]（NFR/Error Budget 与 SRE 变更管理实践高度关联，SRE 团队是 Error Budget 度量体系的核心执行者）
|
||
- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]] ← related_to ← [[ctp-topic-41-nfrs-and-error-budgets]]（NFR 中的可用性目标和 DR 策略直接相关，Error Budget 是衡量恢复能力的量化工具）
|
||
- [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] ← extends ← [[ctp-topic-41-nfrs-and-error-budgets]]（监控能力是衡量 Error Budget 是否达标的必要前提）
|
||
- [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]] ← related_to ← [[ctp-topic-41-nfrs-and-error-budgets]]（NFR/Error Budget 是 SRE 度量弹性目标的工具，与 SRE 转型的方向一致）
|
||
- [[devops-maturity-model-from-traditional-it-to-advanced-devops]] ← extends ← [[ctp-topic-41-nfrs-and-error-budgets]]（DevOps 成熟度模型将 Error Budget 作为衡量系统可靠性和运维能力的核心指标）
|
||
|
||
## Contradictions
|
||
- 与 [[ctp-topic-30-managing-change]] 在 SRE 职责范围上存在视角差异：
|
||
- 冲突点：Topic 30 强调 SRE 的变更管理职责（Standard/Normal/Emergency Change），Topic 41 强调 SRE 的可靠性工程职责（NFR/Error Budget）
|
||
- 当前观点：两者是 SRE 职责的一体两面——变更管理是 SRE 的运营职责，NFR/Error Budget 是 SRE 的工程职责，共同构成完整的 SRE 能力体系
|
||
- 对方观点：Topic 30 侧重"如何处理变更"，Topic 41 侧重"如何定义可靠性目标"，两者互补而非矛盾
|