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]] ← 支持渐进式发布的平台

wiki/entities/Christian-Dior.md

@@ -0,0 +1,22 @@
+---
+title: "Christian Dior"
+type: entity
+tags: [案例, DevOps, FeatureFlag]
+last_updated: 2026-04-16
+---
+
+## 基本信息
+- **类型**：奢侈品时尚集团（ LVMH 旗下）
+- **来源**：LaunchDarkly 案例研究
+
+## 关键事实
+- 通过 LaunchDarkly 将回滚时间从 15 分钟降至即时开关
+- 奢侈品行业高频发布场景下的 DevOps 实践案例
+
+## Aliases
+- Dior
+- Christian Dior
+
+## Connections
+- [[LaunchDarkly]] ← 使用的 Feature Flag 平台
+- [[RTO]] ← 通过即时开关实现的关键改进

wiki/entities/HP.md

@@ -0,0 +1,23 @@
+---
+title: "HP"
+type: entity
+tags: [案例, DevOps, FeatureFlag]
+last_updated: 2026-04-16
+---
+
+## 基本信息
+- **全称**：Hewlett-Packard（惠普公司）
+- **类型**：跨国科技公司
+- **来源**：LaunchDarkly 案例研究
+
+## 关键事实
+- 通过 LaunchDarkly 将软件回滚时间从小时级降至分钟级
+- 案例验证了 Feature Flag 在企业级 DevOps 中的实际价值
+
+## Aliases
+- HP
+- Hewlett-Packard
+
+## Connections
+- [[LaunchDarkly]] ← 使用的 Feature Flag 平台
+- [[RTO]] ← 通过 LaunchDarkly 改善的关键指标

wiki/entities/LaunchDarkly.md

@@ -0,0 +1,34 @@
+---
+title: "LaunchDarkly"
+type: entity
+tags: [DevOps工具, FeatureFlag]
+last_updated: 2026-04-16
+---
+
+## 基本信息
+- **类型**：SaaS / Feature Flag 管理平台
+- **定位**：企业级 Feature Flag 和渐进式发布平台
+- **官网**：launchdarkly.com
+
+## 核心能力
+- Feature Flag 管理：控制功能开关，无需重新部署即可改变行为
+- Kill Switch：一键关闭有问题的功能，RTO 从小时级降至秒级
+- 渐进式发布：分阶段灰度发布（1%→5%→25%→100%）
+- A/B 测试：用户分组对比实验
+- 远程配置：无需更新 App 即可远程调整参数
+
+## 关键数据（2024年用户调研）
+- 86% 的 LaunchDarkly 客户可在一天内从事故中恢复
+- 42% 的客户在数小时内（甚至数分钟）恢复
+- HP：将回滚时间从小时级降至分钟级
+- Christian Dior：将 15 分钟回滚降至即时开关
+- 59% 客户表示运营成本降低 11%-50%
+
+## Aliases
+- LaunchDarkly
+
+## Connections
+- [[Feature Flag]] ← 核心产品
+- [[RTO]] ← 通过 Feature Flag 实现秒级 RTO
+- [[Kill Switch]] ← LaunchDarkly 的核心用例
+- [[渐进式发布]] ← LaunchDarkly 的核心功能

wiki/index.md

@@ -7,6 +7,17 @@
 - [Never Write Another Prompt](sources/Never-write-another-prompt.md) — YouTube 视频笔记：提示词生成工具，描述转结构化提示词 + 变量注入 + 提示词库复用，$100-500/条专业定制降至零成本
 - [OpenAI ChatGPT 个性化定义](sources/OpenAI-ChatGPT-个性化定义.md) — Custom Instructions 配置实例：47岁云服务高管转型 TikTok 跨境电商，偏好详尽推理+反权威论据+精准表达
 
+## Sources (2026-04-16 Batch 4)
+- [DevOps Culture and Transformation](sources/DevOps-Culture-and-Transformation.md) — DevOps 文化转型方法论：四大支柱框架（协作/自动化/Kaizen/客户中心）、敏捷整合、AI/ML 赋能趋势；超越工具的思维模式转变
+- [RTO vs RPO: Key Differences for Modern Disaster Recovery](sources/RTO-vs-RPO-Key-Differences-for-Modern-Disaster-Recovery.md) — RTO/RPO 在现代持续交付中的差异：Feature Flag 将 RTO 从小时降至秒级；三级分层体系（关键/重要/可选）；HP/Dior 案例
+- [Public vs Private vs Hybrid Cloud: Differences Explained](sources/Public-vs-Private-vs-Hybrid-Cloud-Differences-Explained.md) — 公有云/私有云/混合云三种模型对比：弹性vs安全vs成本权衡；混合云是多数组织的实际选择；共享责任模型
+
+## Sources (2026-04-16 Batch 3)
+- [How to get YouTube Channel ID](sources/How-to-get-YouTube-Channel-ID.md) — YouTube 频道 ID 获取方法：view-source 页面查询 `?channel_id` 字符串，可生成 RSS Feed URL 供 n8n 自动化工作流使用
+- [Git Push 连接重置问题修复](sources/Git-Push-连接重置问题修复.md) — GitHub Push `Connection was reset` 修复：Git 全局配置 HTTP/SOCKS5 代理，或切换 SSH 协议；本质是 GFW 的 TCP RST 攻击
+- [Ubuntu 24.04 启用 SSH 服务](sources/Ubuntu-24.04-enable-SSH.md) — Ubuntu 24.04 SSH 服务启用：默认 ssh.socket 按需激活；`systemctl start ssh` + `ufw allow ssh`；切换传统模式方法
+- [递归自优化生成系统的形式化框架](sources/A-Formalization-of-Recursive-Self-Optimizing-Generative-Systems.md) — 递归自优化生成系统数学形式化：自映射 $\Phi$、不动点 $G^*$、Y 组合子；收敛目标是生成器空间不动点而非最优输出
+
 ## Sources (2026-04-16 Batch 2)
 - [在 Ubuntu 安装 Ollama 并运行 Qwen2.5-Coder 7B](sources/在Ubuntu安装Ollama并运行Qwen2.5-Coder7B.md) — Ubuntu 本地部署 Ollama + Qwen2.5-Coder 7B：3 条命令完成安装；qwen2.5-coder:7b 比通用 Qwen2.5 更适合 DevOps/SQL/Kubernetes 等工程任务；OLLAMA_HOST=0.0.0.0 开放远程 API 供 n8n/OpenClaw 调用
 - [如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹](sources/如何在UbuntuServer上通过NFS挂载Synology NAS上的共享文件夹.md) — Ubuntu + Synology NAS NFS 永久挂载：NFS 相比 Samba 保留 Linux 文件权限（rsync 恢复 Docker 卷不报错）；/etc/fstab + _netdev 参数防开机卡死；rsync 备份脚本必须加入 mountpoint 检查
@@ -96,6 +107,14 @@
 - [养虾日记1：用 OpenClaw 管了 28 万张照片](sources/养虾日记1-OpenClaw照片整理实战.md) — OpenClaw AI Agent 照片整理实战：MD5 精确去重、小文件清理、分 8 批次凌晨执行、Telegram 报告
 - [不谈技术：普通人该怎么在AI时代赚钱](sources/普通人如何在AI时代赚钱.md) — AI 时代赚钱三原则：品味是护城河、端到端优于零件、死亡过滤器筛选真正热爱
 
+## Entities (2026-04-16 Batch 4)
+- [LaunchDarkly](entities/LaunchDarkly.md) — Feature Flag 管理平台，86% 客户可在一天内恢复；HP/Dior 将回滚从小时级降至秒级
+- [HP](entities/HP.md) — 通过 LaunchDarkly 将回滚时间从小时级降至分钟级
+- [Christian Dior](entities/Christian-Dior.md) — 通过 LaunchDarkly 将 15 分钟回滚降至即时开关
+
+## Entities (2026-04-16 Batch 3)
+- [tukuai](entities/tukuai.md) — 独立研究者，提出递归自优化生成系统的数学形式化框架
+
 ## Entities (2026-04-16 Batch 2 Continued)
 - [Open Notebook](entities/Open-Notebook.md) — NotebookLM 开源平替，14.6k ⭐，支持 16+ AI 提供商和多模态输入
 - [SurfSense](entities/SurfSense.md) — AI 搜索与研究智能体，11.4k ⭐，Notion/YouTube/GitHub 整合+混合搜索+RBAC
@@ -209,6 +228,24 @@
 - [Jellyfin](entities/Jellyfin.md) — 开源媒体服务器，Plex 去GPL分支，支持硬件 QuickSync 转码
 - [CodeWeaver](entities/CodeWeaver.md) — 将任意代码库编织为树形 Markdown，简化 AI 上下文注入
 
+## Concepts (2026-04-16 Batch 4)
+- [RTO](concepts/RTO.md) — Recovery Time Objective，系统最大可容忍停机时间；Feature Flag 将其从小时级降至秒级
+- [RPO](concepts/RPO.md) — Recovery Point Objective，可接受的最大数据丢失量（从故障时刻往前回溯）
+- [Kill Switch](concepts/Kill-Switch.md) — Feature Flag 紧急关闭能力，RTO 保险策略；HP/Dior 案例验证秒级 RTO
+- [渐进式发布](concepts/渐进式发布.md) — 分阶段（1%→5%→25%→100%）控制影响范围，将故障 RTO 降至秒级
+- [共享责任模型](concepts/共享责任模型.md) — 云环境下服务商与客户的责任划分；无论何种部署模式均适用
+
+## Concepts (2026-04-16 Batch 3)
+- [生成器空间 (Generator Space)](concepts/生成器空间-Generator-Space.md) — $\mathcal{G} \subseteq \mathcal{P}^{\mathcal{I}}$，递归自优化的目标收敛空间
+- [自映射 (Self-Map)](concepts/自映射-Self-Map.md) — $\Phi: \mathcal{G} \to \mathcal{G}$，生成器到自身的映射；迭代应用产生收敛序列
+- [不动点 (Fixed Point)](concepts/不动点-Fixed-Point.md) — $\Phi(G^*) = G^*$，递归自优化的收敛目标，稳定生成能力
+- [不动点组合子 (Y-Combinator)](concepts/不动点组合子-Y-Combinator.md) — λ 演算中实现递归的经典组合子，表达自引用不动点
+- [递归自优化循环](concepts/递归自优化循环.md) — 三算子循环：$G$（生成）→ $O$（优化）→ $M$（更新），收敛到生成器不动点
+- [元生成器 (Meta-Generator)](concepts/元生成器-Meta-Generator.md) — $M: \mathcal{G} \times \mathcal{P} \to \mathcal{G}$，用优化结果更新生成器本身的算子
+- [TCP RST攻击](concepts/TCP-RST攻击.md) — GFW 通过 TCP Reset 包阻断连接，国内 GitHub 访问的主要干扰方式
+- [Git代理配置](concepts/Git代理配置.md) — `git config --global http.proxy` 让 Git 流量走 SOCKS5/HTTP 代理规避 TCP RST
+- [SSH Socket Activation](concepts/SSH-Socket-Activation.md) — Ubuntu 24.04 默认 SSH 管理机制，按需启动 sshd 替代常驻进程
+
 ## Concepts (2026-04-16 Batch 2 Continued)
 - [Identity Locking](concepts/Identity-Locking.md) — 通过 14 张参考图锁定角色身份，Nano-Banana Pro 实现多场景面部一致性
 - [Google Search Grounding](concepts/Google-Search-Grounding.md) — 结合 Google 实时搜索结果驱动图像生成，减少幻觉，支持动态数据可视化

wiki/log.md

@@ -1,3 +1,10 @@
+## [2026-04-16 Batch 3] ingest | 4 sources
+- How to get YouTube Channel ID：view-source 查 channel_id，可拼接 RSS Feed URL 供 n8n 自动化工作流
+- Git Push 连接重置问题修复：TCP RST 攻击（GFW）导致；Git 全局 SOCKS5 代理或 SSH 协议切换解决
+- Ubuntu 24.04 启用 SSH 服务：ssh.socket 按需激活机制替代传统常驻 ssh.service；ufw allow ssh 放行
+- 递归自优化生成系统的形式化框架（tukuai）：自映射 Φ 不动点理论；生成器空间收敛到稳定生成能力；Y 组合子表达自引用；为 self-improving AI 提供数学基础
+- Created: 1 entity (tukuai), 10 concepts (生成器空间/自映射/不动点/不动点组合子/递归自优化循环/元生成器/TCP RST攻击/Git代理配置/SSH Socket Activation/YouTube-RSS-Feed)
+
 ## [2026-04-16 Early Morning Batch] ingest | 3 sources
 - Never Write Another Prompt（YouTube 视频笔记）：提示词生成工具，描述转结构化提示词 + 变量注入，$100-500/条降至零成本
 - OpenAI ChatGPT 个性化定义：Custom Instructions 配置实例，47岁云服务高管转型TikTok跨境电商，精准推理+反权威认知风格
@@ -326,3 +333,9 @@ Created/updated: 3 entity pages (Ollama[更新], Qwen[更新], Apache Superset[
 - Nano-Banana Pro Prompting Guide.md：Google Nano-Banana Pro 进阶提示词策略；10 大能力维度（Text Rendering/Identity Locking/Search Grounding/Editing/2D↔3D/4K/Thinking Mode/Storyboarding/Layout/Pixel Art）；黄金四法则：Edit不重roll、自然语言、具体描述、提供上下文
 - 普通人如何在AI时代赚钱.md：乔布斯视角 AI 时代赚钱三原则——品味值钱（护城河）、端到端优于零件、死亡过滤器筛选热爱；正确问题框架：「AI 让我能做到什么以前做不到的事」
 Created: 7 entity pages (Open Notebook, SurfSense, Podcastfy, PageLM, Nano-Banana Pro, 乔布斯.skill, NotebookLM[更新]), 6 concept pages (Identity Locking, Google Search Grounding, AI时代赚钱三原则, 品味[更新], 端到端[更新], 死亡过滤器[更新]).
+
+## [2026-04-16 03:02] ingest | 3 sources — DevOps 文化 + RTO/RPO + 三种云模型
+- DevOps Culture and Transformation：四大支柱框架（协作/自动化/Kaizen/客户中心）、敏捷整合、AI/ML 赋能趋势；超越工具的思维模式转变
+- RTO vs RPO：RTO 速度指标 vs RPO 数据完整性指标；Feature Flag 将 RTO 从小时降至秒级；三级分层体系（关键/重要/可选）；HP/Dior 案例验证秒级 RTO
+- Public vs Private vs Hybrid Cloud：公有云（弹性/成本）、私有云（安全/合规）、混合云（策略驱动负载分配）三种模型对比；共享责任模型无论何种部署模式均适用
+Created: 3 source pages, 3 entity pages (LaunchDarkly, HP, Christian Dior), 5 concept pages (RTO, RPO, Kill Switch, 渐进式发布, 共享责任模型).

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 设计与测试
+- **合规性**：满足行业法规要求

wiki/sources/DevOps-Culture-and-Transformation.md

@@ -1,70 +1,58 @@
 ---
 title: "DevOps Culture and Transformation: Fostering Collaboration, Agile Practices, and Innovation"
 type: source
-tags: [DevOps, Agile, CI/CD, 企业文化, 数字化转型]
+tags: [DevOps, 转型, 文化]
 date: 2025-03-02
-sources: ["https://www.linkedin.com/pulse/devops-culture-transformation-fostering-collaboration-hemant-sawant-4qsve"]
-last_updated: 2026-04-15
 ---
 
 ## Source File
-- raw/Cloud & DevOps/DevOps Culture and Transformation Fostering Collaboration, Agile Practices, and Innovation  LinkedIn.md
+- [[raw/Cloud & DevOps/DevOps Culture and Transformation Fostering Collaboration, Agile Practices, and Innovation  LinkedIn.md]]
 
 ## Summary
-- 核心主题：DevOps 文化与转型方法论，涵盖团队协作、敏捷实践、技术自动化
-- 问题域：组织如何在数字化竞争中通过 DevOps 打破孤岛、加速交付
-- 方法/机制：四大支柱（协作、自动化、持续改进、客户中心）、Agile 集成、战略性转型 playbook
-- 结论/价值：DevOps 是持续演进的文化变革，而非一次性项目
+- 核心主题：DevOps 文化与数字化转型方法论，超越工具层面进入思维模式转变
+- 问题域：打破开发与运维的孤岛，提升软件交付速度与可靠性
+- 方法/机制：四大支柱框架、敏捷整合、战略转型 playbook、AI/ML 赋能趋势
+- 结论/价值：DevOps 是持续演进而非一次性项目，拥抱文化原则、授权团队、整合敏捷实践是制胜关键
 
 ## Key Claims
-- DevOps 核心是文化转型而非工具引入，组织需优先改变协作心智模型
-- 跨职能团队（Cross-functional Teams）通过共享 KPI（部署频率、MTTR）实现开发与运维目标对齐
-- 自动化（CI/CD、IaC）是加速反馈循环、降低人工错误的核心手段
-- 持续改进（Kaizen）需通过无责复盘（blameless post-mortems）和混沌工程实践
-- Agile 与 DevOps 协同：Scrum/Kanban 提供结构化迭代，CI/CD 压缩反馈周期
-- Shift-Left 实践（DevSecOps、性能测试左移）将安全问题前置到开发阶段
-- 转型策略：领导层背书 → 小范围试点 → 快速迭代 → 规模化推广
-- 未来趋势：AI/ML 赋能 DevOps、GitOps、Serverless DevOps、Edge Computing DevOps、DevSecOps 深化
+- DevOps 的本质是文化与运营革命，不只是工具和自动化
+- 四大支柱：协作优先、自动化赋能者、持续改进（Kaizen）、客户中心
+- 敏捷与 DevOps 是共生关系：敏捷聚焦迭代开发，DevOps 将敏捷扩展到运维
+- 变革领导者必须以身作则，将 DevOps 目标与业务成果对齐
+- 最小化可行产品（MVP）试点快速验证价值，再迭代扩展到整个企业
+- 传统灾难恢复已过时：现代 DevOps 的最大风险是代码缺陷而非硬件故障
+- GitOps 将 Git 作为单一真实源管理基础设施和部署
+- Serverless DevOps 通过 FaaS（Lambda）减少运维开销
+- Edge Computing DevOps 实现更接近终端用户的实时应用性能优化
 
 ## Key Quotes
-> "DevOps isn't just about tools or automation; it's a mindset shift that prioritizes collaboration, continuous learning, and customer-centricity." — Hemant Sawant
-> "DevOps isn't a checkbox—it's a continuous evolution." — Hemant Sawant
+> "DevOps isn't a checkbox—it's a continuous evolution." — 核心洞察
+> "Organizations that embrace its cultural tenets, empower teams, and integrate Agile practices will not only survive but thrive in the digital age."
 
 ## Key Concepts
-- [[DevOps]]：一种文化和运营变革，弥合开发（Dev）与运维（Ops）团队之间的鸿沟
-- [[CI/CD Pipelines]]：自动化测试、集成和部署的流水线
-- [[Infrastructure as Code]]：使用代码管理基础设施，实现版本控制和环境一致性
-- [[Agile]]：迭代式开发方法论，强调适应性规划和快速交付
-- [[DevSecOps]]：在 DevOps 流程中集成安全实践
-- [[GitOps]]：使用 Git 作为唯一真实源来管理基础设施和部署
-- [[Serverless DevOps]]：利用函数即服务（FaaS）减少运维开销
-- [[Edge Computing DevOps]]：在边缘节点部署和运维实时应用
-- [[Kaizen]]：持续改进哲学，强调小步迭代和无责复盘
+- [[DevOps]]：开发与运维团队之间的文化与运营革命，打破孤岛、加速交付
+- [[Kaizen]]：持续小步改进，DevOps 文化的第三支柱
+- [[CI/CD Pipelines]]：Jenkins/GitHub Actions/GitLab CI 自动化测试、集成、部署流水线
+- [[Infrastructure as Code]]：Terraform/AWS CloudFormation 实现版本控制的环境管理
+- [[DevSecOps]]：在 CI/CD 中内置安全，SonarQube/Snyk 集成
+- [[GitOps]]：以 Git 作为单一真实源管理配置和部署
+- [[Feature Flag]]：部署与发布分离，支持渐进式发布和即时回滚
+- [[Chaos Engineering]]：主动测试系统韧性的工程实践
 
 ## Key Entities
-- [[LinkedIn]]：文章发布平台
-- [[Atlassian Jira]]：团队协作与工作流透明化工具
-- [[GitHub Actions]]：CI/CD 流水线工具
+- [[Atlassian]]：Jira 平台提供跨职能团队实时协作与工作流可见性
 - [[Jenkins]]：开源 CI/CD 自动化服务器
-- [[GitLab CI]]：GitLab 内置 CI/CD 工具
-- [[Terraform]]：基础设施即代码工具
-- [[AWS CloudFormation]]：AWS 基础设施编排服务
-- [[Prometheus]]：监控系统与时序数据库
-- [[Grafana]]：可观测性数据可视化平台
-- [[Datadog]]：云端监控与可观测性平台
-- [[SonarQube]]：代码质量与安全静态分析工具
-- [[Snyk]]：开源安全与依赖漏洞扫描工具
-- [[Kubernetes]]：容器编排平台
-- [[Ansible]]：自动化配置管理与应用部署工具
-- [[Docker]]：容器化平台
-- [[AWS Lambda]]：函数即服务（FaaS）无服务器计算服务
+- [[HashiCorp]]：Terraform 基础设施即代码工具的开发商
+- [[Slack]]：跨职能团队实时沟通透明化平台
 
 ## Connections
-- [[DevOps]] ← 依赖 ← [[Agile]]（DevOps 延伸 Agile 的迭代理念至运维侧）
-- [[CI/CD Pipelines]] ← 依赖 ← [[Docker]] + [[Kubernetes]]（容器化环境支撑流水线）
-- [[DevSecOps]] ← 依赖 ← [[SonarQube]] + [[Snyk]]（安全工具集成至 CI/CD）
-- [[GitOps]] ← 依赖 ← [[GitHub Actions]]（Git 工作流驱动部署自动化）
-- [[Serverless DevOps]] ← 依赖 ← [[AWS Lambda]]（FaaS 承载无服务器运维）
+- [[DevOps]] ← 是 [[DevOps成熟度模型]] 的文化基础
+- [[DevOps]] ← 整合 [[Agile]] 实践形成完整交付体系
+- [[CI/CD Pipelines]] ← 依赖 [[Infrastructure as Code]] 实现环境一致性
+- [[DevSecOps]] ← 是 [[DevOps]] 的安全内嵌实践
+- [[GitOps]] ← 延伸 [[CI/CD Pipelines]] 以 Git 为单一真实源
 
 ## Contradictions
-- 暂无冲突记录
+- 与传统 IT 对比：传统观点认为"硬件故障是最大风险"，本文认为"代码缺陷才是现代 DevOps 的最大风险"
+  - 当前观点：风险重心已从硬件转向软件交付过程
+  - 对方观点：灾难恢复计划仍需覆盖物理基础设施故障

wiki/sources/Public-vs-Private-vs-Hybrid-Cloud-Differences-Explained.md

@@ -0,0 +1,52 @@
+---
+title: "Public vs Private vs Hybrid Cloud: Cloud Differences Explained"
+type: source
+tags: [Cloud, DevOps, 架构]
+date: 2025-06-18
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public vs Private vs Hybrid Cloud Differences Explained.md]]
+
+## Summary
+- 核心主题：公有云、私有云、混合云三种部署模型的核心差异、优缺点与适用场景
+- 问题域：组织如何根据安全/性能/成本/合规需求选择最适合的云架构
+- 方法/机制：三层云模型对比分析法，基于业务需求的多云策略设计
+- 结论/价值：三种模型并非互斥，实际选择应基于工作负载特征采取混合策略；云责任是共享模型
+
+## Key Claims
+- 公有云：第三方提供商在多租户环境中交付，按用量计费，优势是弹性、成本效益、快速上线；缺点是安全性最低、成本随规模指数增长、供应商依赖
+- 私有云：专属于单个组织的云环境，优势是高安全、可定制、合规友好；缺点是 TCO 高、远程访问受限、运维复杂
+- 混合云：同时使用公有云和私有云，优势是兼顾安全与弹性、成本可控、业务连续性；缺点是集成复杂、成本管理复杂、安全风险（跨云传输）
+- 公有云适合：可预测计算需求、开发测试环境、应对峰值负载的额外资源
+- 私有云适合：高度监管行业（金融/政府）、敏感数据、需强控制的大型企业
+- 混合云适合：多垂直领域服务、需在不同安全/性能/成本间平衡的工作负载
+- 云责任是共享模型：无论哪种云环境，组织仍需对访问控制、安全加密、灾难恢复规划负责
+- 平衡是云架构的核心驱动力：随业务发展需持续调整云策略
+
+## Key Concepts
+- [[公有云]]：多租户环境，按需弹性扩展，Pay-as-you-go 定价
+- [[私有云]]：单一组织专用，高安全高控制，TCO 相对较高
+- [[混合云]]：公有云+私有云组合，策略驱动的工作负载分配
+- [[多云策略]]：同构（单一厂商）或异构（多厂商）的跨云部署
+- [[SLA]]：Service Level Agreement，服务可用性和性能保证协议
+- [[TCO]]：Total Cost of Ownership，总拥有成本
+- [[CapEx vs OpEx]]：资本支出转为运营支出，云计算的核心财务优势
+- [[共享责任模型]]：云厂商负责基础设施灵活性，组织负责安全与访问控制
+
+## Key Entities
+- [[AWS]]：公有云领导者，提供最广泛的 IaaS/PaaS 服务
+- [[Azure]]：Microsoft 公有云，与企业 Microsoft 生态深度集成
+- [[GCP]]：Google 公有云，以 Kubernetes 和数据/AI 能力见长
+
+## Connections
+- [[公有云]] ← 组成 [[混合云]] 的弹性资源层
+- [[私有云]] ← 组成 [[混合云]] 的安全合规层
+- [[混合云]] ← 是 [[多云策略]] 的一种实现形式
+- [[多云策略]] ← 与 [[混合云]] 经常重叠但不一定同时存在
+- [[CapEx vs OpEx]] ← 是组织选择云迁移的核心财务驱动力
+
+## Contradictions
+- 与"纯云优先"观点对比：有人认为应将所有工作负载迁移到公有云
+  - 当前观点：应根据工作负载特征选择混合策略，高安全需求保留私有云
+  - 对方观点：公有云规模效应使成本始终优于私有云

wiki/sources/RTO-vs-RPO-Key-Differences-for-Modern-Disaster-Recovery.md

@@ -0,0 +1,51 @@
+---
+title: "RTO vs RPO: Key Differences for Modern Disaster Recovery"
+type: source
+tags: [DevOps, 灾难恢复, SRE]
+date: 2025-07-26
+---
+
+## Source File
+- [[raw/Cloud & DevOps/RTO vs RPO Key Differences for Modern Disaster Recovery.md]]
+
+## Summary
+- 核心主题：RTO（恢复时间目标）与 RPO（恢复点目标）在现代持续交付中的差异与应用
+- 问题域：传统灾难恢复规划与现代高频部署场景之间的错配
+- 方法/机制：基于业务影响的三级分层体系、Feature Flag 即时回滚、渐进式发布
+- 结论/价值：Feature Flag 将 RTO 从小时级降至秒级，是现代软件交付的 RPO/RTO 保险策略
+
+## Key Claims
+- RTO 衡量系统从故障到恢复的速度，RPO 衡量可接受的数据丢失量（从故障时刻往前计算）
+- 传统灾难恢复聚焦"稀有大事"（火灾/硬件故障），现代 DevOps 最大风险是代码变更引入的缺陷
+- Feature Flag 将部署（deploy）与发布（release）解耦，实现秒级 RTO
+- RTO 和 RPO 必须同时优化：快速恢复但大量数据丢失，或缓慢恢复但零数据丢失，都是不完整的策略
+- 三级分层系统：Tier 1 关键系统（RTO<5分钟，RPO<1分钟）、Tier 2 重要系统（<1小时，<15分钟）、Tier 3 可选系统（<4小时，<1小时）
+- 渐进式发布（1%→5%→25%→100%）将影响范围控制在局部，将 RTO 从小时降至秒级
+- 成本收益原则：不要为防止 $10K/小时停机损失而花 $100K/年基础设施
+- HP 将回滚时间从小时级降至分钟级；Dior 将 15 分钟回滚降至即时开关
+
+## Key Concepts
+- [[RTO]]：Recovery Time Objective，系统可容忍的最大停机时间
+- [[RPO]]：Recovery Point Objective，可接受的最大数据丢失量（从故障时刻往前回溯）
+- [[Feature Flag]]：将代码部署与用户可见性解耦，支持即时回滚和渐进式发布
+- [[Kill Switch]]：Feature Flag 的紧急关闭能力，RTO 保险策略
+- [[渐进式发布]]：分阶段（1%→5%→25%→100%）控制影响范围
+- [[Blameless Post-Mortem]]：无责复盘，从失败中提取改进而不追责
+- [[连续数据保护]]（CDP）：持续备份而非定时快照，实现更小 RPO
+
+## Key Entities
+- [[LaunchDarkly]]：Feature Flag 管理平台，86% 客户可在一天内从事故恢复
+- [[HP]]：通过 LaunchDarkly 将回滚时间从小时级降至分钟级
+- [[Christian Dior]]：通过 LaunchDarkly 将 15 分钟回滚降至即时开关
+
+## Connections
+- [[RTO]] ← 必须与 [[RPO]] 协同优化，不可偏废其一
+- [[Feature Flag]] ← 改变 [[灾难恢复]] 范式：从部署回滚变为配置变更
+- [[Kill Switch]] ← 是 [[Feature Flag]] 的紧急应用场景
+- [[灾难恢复]] ← 已从基础设施层延伸到应用代码层（Feature Flag 角色）
+- [[渐进式发布]] ← 是 [[RTO]] 控制的核心工程实践
+
+## Contradictions
+- 与传统灾难恢复观点对比：传统认为"回滚 = 重新部署代码"，本文认为"回滚 = 改变 Feature Flag 配置"
+  - 当前观点：Feature Flag 实现秒级 RTO，无需重新部署
+  - 对方观点：代码变更仍需要完整回滚机制作为最后手段