diff --git a/wiki/concepts/Kill-Switch.md b/wiki/concepts/Kill-Switch.md new file mode 100644 index 00000000..16b0ef0a --- /dev/null +++ b/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 平台 diff --git a/wiki/concepts/RPO.md b/wiki/concepts/RPO.md new file mode 100644 index 00000000..0a70a615 --- /dev/null +++ b/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 的技术手段 diff --git a/wiki/concepts/RTO.md b/wiki/concepts/RTO.md new file mode 100644 index 00000000..3d4e6930 --- /dev/null +++ b/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 改善工具 diff --git a/wiki/concepts/共享责任模型.md b/wiki/concepts/共享责任模型.md new file mode 100644 index 00000000..17bb6492 --- /dev/null +++ b/wiki/concepts/共享责任模型.md @@ -0,0 +1,32 @@ +--- +title: "共享责任模型" +type: concept +tags: [Cloud, 安全, 合规] +last_updated: 2026-04-16 +--- + +## 定义 +Shared Responsibility Model：云环境下云服务商与客户之间对安全、合规、运维等责任的划分模型。无论采用何种云部署模式，责任均由双方共同承担。 + +## 责任划分原则 +- **云服务商**负责：底层基础设施的物理安全、硬件维护、网络基础设施的可用性和弹性 +- **客户（组织）负责**：访问控制与身份管理、数据安全与加密、灾难恢复规划、应用程序层安全、合规性 + +## 不同部署模式的差异 +| 责任领域 | 公有云 | 私有云 | 混合云 | +|---------|--------|--------|--------| +| 物理安全 | 云厂商 | 组织/厂商 | 混合 | +| 网络基础设施 | 云厂商 | 组织/厂商 | 混合 | +| 访问控制 | 客户 | 客户 | 客户（跨云） | +| 数据加密 | 客户 | 客户 | 客户 | +| 灾难恢复 | 客户 | 客户 | 客户（跨云设计） | + +## 关键误解 +- 误以为使用 SaaS 应用后所有安全问题由服务商负责 +- 实际上客户仍需负责：谁有访问权限、数据如何被使用、是否符合合规要求 + +## Connections +- [[公有云]] ← 共享责任模型的核心框架 +- [[私有云]] ← 责任划分偏向组织内部 +- [[混合云]] ← 跨云环境的共享责任复杂性更高 +- [[灾难恢复]] ← 属于客户责任，云厂商提供工具但规划由客户负责 diff --git a/wiki/concepts/渐进式发布.md b/wiki/concepts/渐进式发布.md new file mode 100644 index 00000000..a1f60770 --- /dev/null +++ b/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]] ← 支持渐进式发布的平台 diff --git a/wiki/entities/Christian-Dior.md b/wiki/entities/Christian-Dior.md new file mode 100644 index 00000000..e3b99da8 --- /dev/null +++ b/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]] ← 通过即时开关实现的关键改进 diff --git a/wiki/entities/HP.md b/wiki/entities/HP.md new file mode 100644 index 00000000..cbdc8b3e --- /dev/null +++ b/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 改善的关键指标 diff --git a/wiki/entities/LaunchDarkly.md b/wiki/entities/LaunchDarkly.md new file mode 100644 index 00000000..6cdca489 --- /dev/null +++ b/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 的核心功能 diff --git a/wiki/index.md b/wiki/index.md index a0cee31c..d6c5255a 100644 --- a/wiki/index.md +++ b/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 实时搜索结果驱动图像生成，减少幻觉，支持动态数据可视化 diff --git a/wiki/log.md b/wiki/log.md index cb2b877c..5580c234 100644 --- a/wiki/log.md +++ b/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, 渐进式发布, 共享责任模型). diff --git a/wiki/overview.md b/wiki/overview.md index ba2bc905..671f0e38 100644 --- a/wiki/overview.md +++ b/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 设计与测试 +- **合规性**：满足行业法规要求 diff --git a/wiki/sources/DevOps-Culture-and-Transformation.md b/wiki/sources/DevOps-Culture-and-Transformation.md index 5af6c30f..f9b1c9ef 100644 --- a/wiki/sources/DevOps-Culture-and-Transformation.md +++ b/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 的最大风险" + - 当前观点：风险重心已从硬件转向软件交付过程 + - 对方观点：灾难恢复计划仍需覆盖物理基础设施故障 diff --git a/wiki/sources/Public-vs-Private-vs-Hybrid-Cloud-Differences-Explained.md b/wiki/sources/Public-vs-Private-vs-Hybrid-Cloud-Differences-Explained.md new file mode 100644 index 00000000..bcd29d64 --- /dev/null +++ b/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 +- 与"纯云优先"观点对比：有人认为应将所有工作负载迁移到公有云 + - 当前观点：应根据工作负载特征选择混合策略，高安全需求保留私有云 + - 对方观点：公有云规模效应使成本始终优于私有云 diff --git a/wiki/sources/RTO-vs-RPO-Key-Differences-for-Modern-Disaster-Recovery.md b/wiki/sources/RTO-vs-RPO-Key-Differences-for-Modern-Disaster-Recovery.md new file mode 100644 index 00000000..8e3805e6 --- /dev/null +++ b/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，无需重新部署 + - 对方观点：代码变更仍需要完整回滚机制作为最后手段