https://socake.github.io/tags/playbook/Recent content in Playbook on 黄文卓 | DevOps EngineerHugo -- gohugo.iozh-CN17691281867@163.com (Wenzhuo Huang)17691281867@163.com (Wenzhuo Huang)© 2026 Wenzhuo HuangThu, 30 Apr 2026 17:00:00 +0800https://socake.github.io/playbook/multi-cloud-alerting-consolidation/Thu, 30 Apr 2026 17:00:00 +080017691281867@163.com (Wenzhuo Huang)https://socake.github.io/playbook/multi-cloud-alerting-consolidation/做告警最常见的状态不是没告警，而是有两套甚至三套并行运行的告警系统，渠道交叉、规则重叠、silence 写得到处都是。本文给出从混乱状态收敛成统一治理的完整路径，包含可直接 1:1 复制部署的全量 yaml、脚本与配置。https://socake.github.io/playbook/k8s-cost-optimization-karpenter/Thu, 30 Apr 2026 16:00:00 +080017691281867@163.com (Wenzhuo Huang)https://socake.github.io/playbook/k8s-cost-optimization-karpenter/Karpenter 不是开箱即用的省钱按钮。把它跑出真实收益，需要先做 NodePool 按 workload 分层，再处理 sandbox/gpu 这类不被 K8s 识别的工作负载，最后用 placeholder 占位 Pod 弥合「扩容慢但缩容快」的体验缺口。本文给出可直接 kubectl apply 的完整 yaml 与可 chmod +x 直接跑的脚本，覆盖安装、四类 NodePool、弹性占位、S3 Gateway Endpoint、MQ 降级、监控与告警。https://socake.github.io/playbook/aurora-public-access-tightening/Thu, 30 Apr 2026 15:30:00 +080017691281867@163.com (Wenzhuo Huang)https://socake.github.io/playbook/aurora-public-access-tightening/很多团队的生产 Aurora 长期挂着 0.0.0.0/0 全协议规则，加上几条来源不明的 IP 白名单。直接删规则会立刻打断跨 Region 服务和开发者本地调试，于是收紧工作年复一年被推迟。本文给出一条工程化路径：先用 Flow Logs + Athena + CloudTrail 摸清依赖，把跨 Region 业务切到 VPC Peering + Route53 Private Hosted Zone，再用 SSM Port Forwarding 替代开发者直连，最后原子切换 SG 并清理长尾白名单。每一步都给可直接执行的脚本和 IAM Policy。覆盖 4 个真实踩到的坑。https://socake.github.io/playbook/zerotrust-mesh-headscale/Thu, 30 Apr 2026 15:00:00 +080017691281867@163.com (Wenzhuo Huang)https://socake.github.io/playbook/zerotrust-mesh-headscale/数据库公网入口收紧后，开发调试需求仍然真实存在。SSM Port Forwarding 这类临时方案随着资源增加和团队扩大很快变得不可维护。Headscale + Tailscale 提供了一层统一的访问控制：单台 ECS 跑控制面，每个 K8s 集群部署 Subnet Router Pod，ACL 基于身份控制访问范围。本文给出从阿里云 ECS 创建命令、Caddyfile、完整 Headscale 配置、K8s 完整 manifest、运维脚本、客户端接入脚本到故障 runbook 的一整套可直接复制执行的工件，包含 5 个生产中真实踩到的坑。https://socake.github.io/playbook/schema-check-dual-stage-pipeline/Thu, 30 Apr 2026 14:00:00 +080017691281867@163.com (Wenzhuo Huang)https://socake.github.io/playbook/schema-check-dual-stage-pipeline/很多团队把 schema diff 接进流水线后仍然出 DDL 事故——绿色构建 + warning 通知，没人读，等于没装。本文记录一套已经在 5 条主流水线（MySQL / PostgreSQL）上线两周的双 Stage 设计：pre stage 在 PR 阶段以 warning 模式跑，给开发者『提前修』的窗口；post stage 在合并到 PRE 后以 fail 模式跑，缺表/破坏性 DDL 直接阻塞 PRE → PROD 推进。给出完整 schema_check.py、ignore-rules.yaml、双 stage 云效 Flow YAML、GitHub Actions 等价实现、PR 评论机器人脚本、5 种 DDL 危险场景的 unit test、跨服务依赖图脚本，以及五个踩坑的完整修复与复现脚本。https://socake.github.io/playbook/msk-serverless-to-provisioned/Thu, 30 Apr 2026 13:30:00 +080017691281867@163.com (Wenzhuo Huang)https://socake.github.io/playbook/msk-serverless-to-provisioned/MSK Serverless 看似按用量付费，实际上有一个常被忽视的最低消费层级：每个集群每月固定 $540 起、每个活跃消费者 IAM principal 还要按小时另收。对于流量长期 « 1MB/s 的非生产环境，月费可以是同等吞吐 Provisioned 集群的 5-7 倍。本文记录将 4 个非生产环境从 MSK Serverless 迁回 Provisioned（kafka.t3.small × 2）的完整流程：成本计算脚本、aws kafka create-cluster 完整 JSON、IRSA 三 role 拆分、Java/Go/Python 三栈客户端配置、双集群双写五阶段切换、Schema Registry 导出导入、回滚脚本，以及踩过的多 IRSA、sarama、broker 数不可缩、Schema Registry 漏迁五个坑。https://socake.github.io/playbook/k8s-cluster-consolidation/Thu, 30 Apr 2026 13:00:00 +080017691281867@163.com (Wenzhuo Huang)https://socake.github.io/playbook/k8s-cluster-consolidation/集群合并的好处显性，坏处隐性。本 Playbook 不再停留在『讲个思路』，每段 yaml 都是完整 manifest（含 Namespace / ServiceAccount / RBAC / Secret），每段脚本都能 chmod +x 直接跑，每个步骤含前置 / 执行 / 验证 / 回滚四件套，并附一次真实事故的完整修复 SQL。https://socake.github.io/playbook/cicd-pipeline-templating/Thu, 30 Apr 2026 12:00:00 +080017691281867@163.com (Wenzhuo Huang)https://socake.github.io/playbook/cicd-pipeline-templating/在 80+ 条流水线的体量下，每条服务自己拷一份 yaml 是工程债：字段命名漂移、改一次通知模板要改 80 处、新人不知道照哪条抄。本文把方案从「思路」推进到「拿来即用」：每个标准模板给完整 YAML（含 anchors / 变量组绑定 / 审批节点）、对应 GitHub Actions reusable workflow、Jenkins shared library；附 create-pipeline.sh 端到端脚本、变量组管理 API 调用、模板回归测试 dry-run；7 个云效官方文档不写的硬约束（schedule 不工作 / step envs 失效 / stage 间永远线性渲染等）每个含完整修复 + 通用结论。https://socake.github.io/playbook/multi-environment-isolation-checklist/Thu, 30 Apr 2026 11:30:00 +080017691281867@163.com (Wenzhuo Huang)https://socake.github.io/playbook/multi-environment-isolation-checklist/一个共用 RabbitMQ broker、共用 Aurora cluster、自增 id 都从 1 起步的新子环境上线 24 天，向已有环境的老用户项目里灌入了约 10 万条不属于他们的消息。本文复盘事故根因（4 件套同时成立才会爆雷），对比三种隔离方案的成本与风险，给出推荐架构（独立中间件 + 共享集群 + ID 起点错开），并把 7 条强制 checklist 沉淀为新子环境上线门槛，附完整可执行的 aws cli / kubectl / SQL / Go 中间件代码。https://socake.github.io/playbook/per-pr-isolated-environment/Thu, 30 Apr 2026 11:00:00 +080017691281867@163.com (Wenzhuo Huang)https://socake.github.io/playbook/per-pr-isolated-environment/QA 共享环境是并行开发的最大瓶颈。本 Playbook 给出一套已经在多个业务服务上线、跑通端到端真实代码改动验证的 PR 隔离方案：feature 分支推送即触发 deploy.py 在独立 namespace 拉起 PR Pod，入口域名继续用 QA 域名，HTTPRoute 按 X-env header 把流量切到对应 PR Pod，关闭 PR + 24h cron + 容量水位三层清理避免泄漏。本版（v2 深度版）相对 v1 重点强化了可执行性：所有 yaml 是完整 manifest（含 namespace / RBAC / Secret），所有脚本都能 chmod +x 直接跑，每步含前置 / 执行 / 验证 / 回滚四件套，配 5 个完整踩坑修复 + 2 张 mermaid 图。https://socake.github.io/playbook/end-to-end-devops-pipeline/Thu, 30 Apr 2026 10:30:00 +080017691281867@163.com (Wenzhuo Huang)https://socake.github.io/playbook/end-to-end-devops-pipeline/中等规模公司的 DevOps 体系最常见的两个症状：工具碎片化（GitLab + Jenkins + 手工 kubectl）和阶段衔接断裂（PR 慢、合并后部署延迟、监控滞后）。本文不讲入门概念，给一份真实可落地的全流程蓝图：开发者本机 → Git 提交 → 云效 / GitHub Actions CI（含 Schema Check 双 Stage）→ ECR/ACR → GitOps 仓库自动更新镜像 tag → ArgoCD 自动 sync → K8s 多集群部署 → Prometheus + Loki + 钉钉告警。每个环节标注用什么工具具体到版本号，关键集成点（ApplicationSet / Kustomize overlay / deploy.py）给完整可执行配置，配三个真实坑（GitOps 闭环缺口、deploy.py path-mode 切换混乱、多 ArgoCD 凭据路由），并给出 DORA 风格的 before/after 对比与采集脚本。可以把这篇当成整个 Playbook 系列的目录页。