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

wiki/overview.md

@@ -28,6 +28,9 @@ last_updated: 2026-04-16 Early Morning
 // 新增领域：递归自优化生成系统（2026-04-15）
 // 新增领域：AI产品经理工作流（2026-04-15）
 // 新增领域：baoyu-skills Claude Code技能集（2026-04-15）
+// 新增领域：DevOps Culture and Transformation 四大支柱框架（2026-04-16 Batch 4）
+// 新增领域：RTO/RPO 现代灾难恢复体系与 Feature Flag 秒级 RTO（2026-04-16 Batch 4）
+// 新增领域：公有云/私有云/混合云三种部署模型对比与共享责任模型（2026-04-16 Batch 4）
 ---
 
 # LLM Wiki Overview
@@ -665,7 +668,9 @@ Agentic AI（行动型 AI）与 GenAI（生成型 AI）的根本区别在于：A
 ### 关键洞察
 - AI 不会让普通人变富，但会让那些知道自己要做什么、且对品质有执念的人变得极其强大
 
-// 新增领域：baoyu-skills Claude Code 技能集（2026-04-15 PM）
+// 新增领域：DevOps Culture and Transformation 四大支柱框架（2026-04-16 Batch 4）
+// 新增领域：RTO/RPO 现代灾难恢复体系与 Feature Flag 秒级 RTO（2026-04-16 Batch 4）
+// 新增领域：公有云/私有云/混合云三种部署模型对比与共享责任模型（2026-04-16 Batch 4）
 // 新增领域：Multi-Agent 虚拟团队协作模式（2026-04-15 PM）
 // 新增领域：Vibe-Kanban + OpenCode Ubuntu 部署（2026-04-15 PM）
 // 新增领域：Home Office 自托管服务三件套——MariaDB + Navidrome + rsync 增量备份（2026-04-15 Evening）
@@ -933,3 +938,93 @@ Google Nano-Banana Pro 从"娱乐级"升级到"专业级资产生产"，是"思
 
 ### 来源
 [[乔布斯.skill]] — 通过 Claude Code Skills 封装的乔布斯视角思维框架
+
+## 新增领域：DevOps Culture and Transformation 四大支柱框架
+
+DevOps 超越工具层面，进入思维模式转变，通过文化、运营和技术三位一体实现软件交付能力的系统性提升。
+
+### 四大支柱
+- **协作优先于孤岛**：跨职能团队共享软件全生命周期所有权，打破 Dev 与 Ops 的组织壁垒
+- **自动化即赋能者**：CI/CD Pipeline + IaC 将人工程序自动化，释放团队聚焦高价值工作
+- **持续改进（Kaizen）**：无责复盘、数据驱动瓶颈识别、混沌工程主动测试系统韧性
+- **客户中心**：Feature Flagging 嵌入式反馈、A/B 测试数据驱动决策
+
+### 敏捷整合
+- Scrum/Kanban 为结构化迭代或持续流动提供框架
+- DevSecOps 将安全左移（Shift-Left）在开发阶段即嵌入
+- Value Stream Mapping 可视化工作流消除等待和浪费
+
+### AI/ML 赋能趋势
+- GitOps 以 Git 作为单一真实源管理基础设施
+- Serverless DevOps 通过 FaaS 减少运维开销
+- Edge Computing DevOps 实现近用户侧实时应用性能优化
+
+### 关键实体
+- [[Atlassian]]：Jira 提供跨职能团队实时协作
+- [[Jenkins]] / [[GitLab]] / [[GitHub]]：主流 CI/CD 工具
+- [[HashiCorp]]：Terraform IaC 工具
+
+## 新增领域：RTO/RPO 现代灾难恢复体系与 Feature Flag 秒级 RTO
+
+传统灾难恢复聚焦稀有硬件故障，现代 DevOps 的最大风险已转向代码变更引入的缺陷。Feature Flag 将 RTO 从"部署回滚时间"（小时级）降至"配置变更时间"（秒级）。
+
+### RTO vs RPO 核心差异
+- **RTO**：系统可容忍的最大停机时间，衡量速度
+- **RPO**：可接受的最大数据丢失量（从故障时刻往前回溯），衡量数据完整性
+- 两者必须协同优化：快速恢复但大量数据丢失，或缓慢恢复但零数据丢失，均不完整
+
+### 三级分层体系
+| 级别 | 示例 | RTO | RPO |
+|------|------|-----|-----|
+| Tier 1 关键 | 支付/用户认证 | <5 分钟 | <1 分钟 |
+| Tier 2 重要 | 管理后台/报表 | <1 小时 | <15 分钟 |
+| Tier 3 可选 | 内部工具/文档站 | <4 小时 | <1 小时 |
+
+### Feature Flag 改变灾难恢复范式
+- **部署 ≠ 发布**：代码可部署到生产环境但默认不向用户开放
+- **Kill Switch**：Flip the Flag 而非 Debug under pressure
+- **渐进式发布**：1%→5%→25%→100%，将影响范围控制在局部
+- HP：将回滚时间从小时级降至分钟级
+- Christian Dior：将 15 分钟回滚降至即时开关
+
+### 关键洞察
+- "预防优于补救"：主动质量保障（渐进式发布+测试）成本永远低于被动灾难恢复
+- 成本收益原则：不要为防止 $10K/小时停机损失花 $100K/年基础设施
+
+### 关键实体
+- [[LaunchDarkly]]：企业级 Feature Flag 平台，86% 客户可在一天内恢复
+
+## 新增领域：公有云/私有云/混合云三种部署模型与共享责任
+
+三种云部署模型并非互斥，实际组织应根据工作负载特征采取混合策略，每种模型在安全/性能/成本/合规之间有不同权衡。
+
+### 三种模型对比
+| 维度 | 公有云 | 私有云 | 混合云 |
+|------|--------|--------|--------|
+| 成本 | 按需弹性，规模化后指数增长 | TCO 高，固定投入 | 可优化，但管理复杂 |
+| 安全 | 多租户，隔离弱 | 专用环境，高安全 | 敏感负载在私有，弹性在公有 |
+| 合规 | 需额外措施 | 高度可控 | 按负载分配 |
+| 弹性 | 强 | 受限于物理硬件 | 公有侧弹性，私有侧稳定 |
+| 适用 | 开发测试/峰值扩展 | 金融/政府/敏感数据 | 大多数企业实际选择 |
+
+### 公有云适用场景
+- 可预测计算需求（固定用户量的通信服务）
+- 软件开发测试环境
+- 应对不可预测的峰值负载
+
+### 私有云适用场景
+- 高度监管行业（金融/政府/医疗）
+- 敏感商业数据
+- 需要强控制和定制化的超大型企业
+
+### 混合云核心价值
+- 策略驱动的工作负载分配：安全敏感负载在私有云，弹性需求在公有云
+- 业务连续性：分布式架构使灾难恢复更容易
+- 成本效率：日常负载在廉价的公有云，峰值弹性扩展
+
+### 共享责任模型
+无论哪种部署模式，组织均对以下责任负责：
+- **访问控制**：谁可以访问什么资源
+- **数据安全与加密**：静态和传输中数据加密
+- **灾难恢复规划**：RTO/RPO 设计与测试
+- **合规性**：满足行业法规要求