wiki-ingest batch 4: DevOps Culture + RTO/RPO + 三种云模型 (2026-04-16 03:02)

wiki/concepts/Kill-Switch.md

@@ -0,0 +1,33 @@
+---
+title: "Kill Switch"
+type: concept
+tags: [DevOps, FeatureFlag, 可靠性工程]
+last_updated: 2026-04-16
+---
+
+## 定义
+Kill Switch（紧急开关）：Feature Flag 的紧急应用场景，可在生产环境出现故障时一键关闭问题功能，无需重新部署代码。
+
+## 核心价值
+- RTO 保险策略：问题发生时 Flip the Flag 而非 Debug under pressure
+- 数据完整性保护：在 bug 持续破坏数据时立即止损，比等待完整回滚部署更快
+
+## 典型应用场景
+- 支付网关故障：立即切换到备用支付提供商
+- 搜索算法异常：回退到旧的搜索算法
+- AI 模型产生幻觉：切换回上一稳定版本
+- 数据库迁移导致性能下降：仅回滚该变更而非整个部署
+
+## 与 Feature Flag 的关系
+- Kill Switch 是 Feature Flag 的一种高级应用
+- Feature Flag 提供 Kill Switch 的工程基础（部署与发布解耦）
+
+## 与 RTO 的关系
+- Kill Switch 将 RTO 从"部署回滚时间"降至"配置变更时间"（秒级）
+- HP 案例：从小时级降至分钟级
+- Christian Dior 案例：从 15 分钟降至即时开关
+
+## Connections
+- [[Feature Flag]] ← Kill Switch 的工程基础
+- [[RTO]] ← 通过 Kill Switch 实现秒级 RTO
+- [[LaunchDarkly]] ← 企业级 Kill Switch 平台

wiki/concepts/RPO.md

@@ -0,0 +1,36 @@
+---
+title: "RPO"
+type: concept
+tags: [DevOps, SRE, 灾难恢复]
+last_updated: 2026-04-16
+---
+
+## 定义
+Recovery Point Objective（恢复点目标）：可接受的最新数据丢失量，以时间衡量（从故障时刻往前回溯）。
+
+## 计算方式
+若数据库在 15:00 崩溃，最后一次备份在 14:00，则 RPO 为 1 小时（14:00-15:00 之间的数据丢失）。
+
+## 典型场景与目标
+| 场景 | RPO 目标 | 原因 |
+|------|---------|------|
+| 电商支付系统 | 0 分钟 | 不能丢失任何交易数据 |
+| 实时聊天 | 5 分钟 | 可接受丢失最近几分钟消息 |
+| 用户分析仪表盘 | 1 小时 | 部分历史数据可重建 |
+| 内部 CRM | 15 分钟 | 最近的客户更新很重要 |
+| 博客/营销站点 | 24 小时 | 一天的评论/注册丢失可接受 |
+
+## 与 RTO 的关系
+- RTO 是速度指标（停机多久），RPO 是数据完整性指标（丢多少数据）
+- 备份频率（CDP vs 定时备份）直接影响 RPO
+- 即使 RTO 优秀（5分钟恢复），RPO 差（1小时前备份）仍意味着大量数据丢失
+
+## 实现技术
+- [[连续数据保护]]（CDP）：持续备份，实现分钟级甚至秒级 RPO
+- 同步复制：零 RPO，但成本高
+- 异步复制：有延迟，通常分钟级 RPO
+
+## Connections
+- [[RTO]] ← 协同指标，共同构成灾难恢复策略
+- [[灾难恢复]] ← RPO 是其核心衡量指标
+- [[连续数据保护]] ← 实现更小 RPO 的技术手段

wiki/concepts/RTO.md

@@ -0,0 +1,36 @@
+---
+title: "RTO"
+type: concept
+tags: [DevOps, SRE, 灾难恢复]
+last_updated: 2026-04-16
+---
+
+## 定义
+Recovery Time Objective（恢复时间目标）：系统从故障发生到完全恢复可用的最大可容忍时间。
+
+## 计算方式
+从系统故障时刻开始计时，到用户可以再次正常使用系统为止。
+
+## 典型场景与目标
+| 场景 | RTO 目标 | 原因 |
+|------|---------|------|
+| 电商支付系统 | <5 分钟 | 停机直接损失收入 |
+| 实时聊天 | <30 秒 | 用户期望即时响应 |
+| 用户分析仪表盘 | <30 分钟 | 停机影响有限 |
+| 内部 CRM | <4 小时 | 可人工 workaround |
+| 博客/营销站点 | <2 小时 | 业务影响相对较小 |
+
+## 与 RPO 的关系
+- RTO 是速度指标，RPO 是数据完整性指标
+- 两者必须协同优化：快速恢复但丢大量数据，或缓慢恢复但零数据丢失，均不完整
+
+## 与 Feature Flag 的关系
+- Feature Flag 将 RTO 从"部署回滚时间"（小时级）降至"配置变更时间"（秒级）
+- Kill Switch 是实现秒级 RTO 的核心机制
+
+## Connections
+- [[RPO]] ← 协同指标，共同构成灾难恢复策略
+- [[灾难恢复]] ← RTO 是其核心衡量指标
+- [[Feature Flag]] ← 实现秒级 RTO 的工程手段
+- [[Kill Switch]] ← RTO 保险策略
+- [[LaunchDarkly]] ← 企业级 RTO 改善工具

wiki/concepts/共享责任模型.md

@@ -0,0 +1,32 @@
+---
+title: "共享责任模型"
+type: concept
+tags: [Cloud, 安全, 合规]
+last_updated: 2026-04-16
+---
+
+## 定义
+Shared Responsibility Model：云环境下云服务商与客户之间对安全、合规、运维等责任的划分模型。无论采用何种云部署模式，责任均由双方共同承担。
+
+## 责任划分原则
+- **云服务商**负责：底层基础设施的物理安全、硬件维护、网络基础设施的可用性和弹性
+- **客户（组织）负责**：访问控制与身份管理、数据安全与加密、灾难恢复规划、应用程序层安全、合规性
+
+## 不同部署模式的差异
+| 责任领域 | 公有云 | 私有云 | 混合云 |
+|---------|--------|--------|--------|
+| 物理安全 | 云厂商 | 组织/厂商 | 混合 |
+| 网络基础设施 | 云厂商 | 组织/厂商 | 混合 |
+| 访问控制 | 客户 | 客户 | 客户（跨云） |
+| 数据加密 | 客户 | 客户 | 客户 |
+| 灾难恢复 | 客户 | 客户 | 客户（跨云设计） |
+
+## 关键误解
+- 误以为使用 SaaS 应用后所有安全问题由服务商负责
+- 实际上客户仍需负责：谁有访问权限、数据如何被使用、是否符合合规要求
+
+## Connections
+- [[公有云]] ← 共享责任模型的核心框架
+- [[私有云]] ← 责任划分偏向组织内部
+- [[混合云]] ← 跨云环境的共享责任复杂性更高
+- [[灾难恢复]] ← 属于客户责任，云厂商提供工具但规划由客户负责

wiki/concepts/渐进式发布.md

@@ -0,0 +1,32 @@
+---
+title: "渐进式发布"
+type: concept
+tags: [DevOps, 发布策略, FeatureFlag]
+last_updated: 2026-04-16
+---
+
+## 定义
+Gradual Rollout / Progressive Delivery：将新功能分阶段向用户群体发布的发布策略，而非全量一次性发布。
+
+## 标准分阶段
+1. **1% 用户**：监控错误率、性能指标
+2. **5% 用户**：监控转化率、用户反馈
+3. **25% 用户**：检查对下游系统的负载压力
+4. **100% 用户**：全量发布
+
+## 核心价值
+- 将影响范围控制在局部，故障影响从全局降至局部
+- 将 RTO 从"小时级紧急回滚部署"降至"秒级 Feature Flag 关闭"
+- 提供真实的用户数据反馈，而非仅靠测试环境
+
+## 细分策略
+- **金丝雀发布**（Canary Release）：向小比例用户发布新版本，观察后再全量
+- **蓝绿部署**（Blue/Green Deployment）：两套环境并行，切换流量
+- **A/B 测试**：不同用户看到不同版本，对比效果
+- **特性分支隔离**：按用户属性（地区/平台/角色）分批发布
+
+## Connections
+- [[Feature Flag]] ← 渐进式发布的工程基础
+- [[Kill Switch]] ← 渐进式发布过程中的应急机制
+- [[RTO]] ← 渐进式发布将故障 RTO 降至秒级
+- [[LaunchDarkly]] ← 支持渐进式发布的平台