已解决：何时决定停止 PPC 活动？
Source: Dev.to
🚀 执行摘要
TL;DR: 未知且昂贵的“僵尸微服务”（比喻为 PPC 广告活动 烧钱）经常消耗大量云资源且依赖关系不明，导致账单高企并产生被迫关闭的恐惧。可使用以下方法安全下线这些服务：
- 逐步资源削减 – “窒息观察”
- 彻底依赖映射 – “考古挖掘”
- 在低流量时段进行受控、可逆的“尖叫测试”
🎯 关键要点
-
勒紧并观察 – 谨慎地减少服务的分配资源（例如，缩减 EC2 实例或降低 cron 频率），并监控系统响应和警报，以在最小化即时风险的同时发现隐藏的依赖关系。
-
考古挖掘 – 使用可观测性工具（DataDog、VPC 流日志等）绘制入口/出口流量和业务功能图谱，然后制定正式的淘汰计划并删除相关的基础设施即代码。
-
尖叫测试 – 对于没有文档或日志的服务，先在预演环境进行受控测试，然后在低流量窗口的生产环境中进行，配备随时回滚的方案，通过观察直接的系统故障来识别关键依赖。
为“僵尸”服务和遗留流程不断攀升的云费用而苦恼？了解何时以及如何安全地退役基础设施，而不导致生产中断。
我的‘PPC Campaign’是僵尸微服务：何时拔掉电源
我记得盯着每月的云账单。那是一个让人胃里打结的五位数，其中有一项格外显眼：一批名为 DataAggregator-PROD 的大型 EC2 实例。它们每月花费我们近 $4,000 a month，仅仅是一直在运行。
我四处打听。新来的产品经理从未听说过它。初级开发者认为它是“我们不碰的某个遗留东西”。它是机器中的幽灵，一个技术 PPC campaign，在没有任何可衡量 ROI 的情况下烧钱。
问题是什么？ 没有人确切知道如果把它关掉会发生什么。这是我在几乎所有工作过的公司里都见过的情形。
“原因”：我们如何产生这些数字幽灵
这并不是在指责任何人。它是增长、优先级变化以及团队人员流动的自然结果。两年前还至关重要的项目被取代，原来的开发者离开了。文档——如果曾经存在——现在只是一条被遗忘的 Confluence 空间中的死链接。我们之所以会出现这些僵尸服务，主要有以下几个原因：
| 原因 | 解释 |
|---|---|
| 对未知的恐惧 | “如果这个服务悄悄支撑着结账页面，而我们导致了百万美元的宕机怎么办？” 与其冒着导致生产故障的风险，不如继续支付账单更省心。 |
| 缺乏所有权 | 当一个服务归属于所有人时，它实际上没有人负责。没有明确的所有者负责其生命周期，它注定会成为技术债务。 |
| 可观测性差 | 如果你无法轻易看到谁在调用某个服务以及该服务在调用谁，你就像盲人一样操作。你无法自信地退役一个你无法完全理解的东西。 |
于是你被迫保留一个昂贵且神秘的流程。你知道它很可能毫无用处，但关闭它的风险让人望而却步。下面让我们一起看看，在实际工作中我们是如何解决这个问题的。
修复方案：从谨慎微调到精算赌博
1. 快速修复 – ‘勒紧观察’ 方法
这是我在政治资本或完整调查时间不足时的首选步骤。虽然有点投机取巧，但很有效。你不是直接杀掉服务，而是让它饿死。目标是让成本变得极低，然后观察谁会喊叫。
- Auto‑scaling 组 – 将期望/最小/最大实例数缩减到 1 台实例，使用尽可能小的实例类型。
- 数据管道 – 将其 cron 调度从 每小时一次 改为 每天凌晨 3 点一次。
服务仍然“在运行”，这可以安抚紧张的利益相关者，但你的费用会骤降。现在，像鹰一样盯紧监控仪表盘。留意上游或下游服务的新错误峰值，检查支持工单队列，并倾听是否有人低声抱怨“嘿，XYZ 报告运行变慢了吗？”。
专业提示： 在执行此操作前，确保你的告警系统一流。如果 legacy‑api‑gw‑01 因为其微小实例负载过重而抛出 503 错误，你必须立刻知道——而不是等到客户投诉后才发现。
2. 永久修复 – ‘考古挖掘’
这才是“正确”的做法。它需要时间和精力，但能消除风险并彻底清理技术债务。你将成为侦探，追踪服务的数字足迹。
你的最佳伙伴是可观测性工具——比如 DataDog、New Relic、Honeycomb，或深入分析 VPC 流日志 与 CloudWatch 指标。你需要回答三个问题：
- 谁在调用该服务？（入口流量）
- 该服务调用了什么？（出口流量）
- 它执行了什么业务功能？（“那有什么意义？”）
你将会：
- 构建 依赖关系图。
- 起草 正式的废弃计划。
- 将计划传达给所有与其交互的团队。
- 安排 退役窗口 并执行基础设施即代码的移除。
3. 精算赌博 – ‘尖叫测试’
对于没有文档或日志的服务，可以执行受控测试：
- 准备测试 – 在预演环境中禁用或限流该服务。验证没有关键功能被破坏。
- 生产低流量窗口 – 在已知的低流量时段（例如周末夜间）在生产环境中复现该变更。
- 回滚计划 – 准备即时的“撤销”手段（例如 Terraform apply 恢复资源，或快速脚本重新启用服务）。
观察系统行为。如果没有告警触发，也没有工单产生，你就有证据表明该服务真的已经孤立，可以安全退役。
结束语
僵尸微服务是快速增长的隐藏成本。通过采用分层方法——从低风险的“扼杀”开始，逐步进行彻底的“考古挖掘”，在必要时进行受控的“尖叫测试”——您可以安全地淘汰这些成本中心，而不会危及生产。
要点: 不要让恐惧让您为无用的负担继续付费。利用可观测性、渐进式削减和严格的回滚计划，将幽灵服务转变为干净且具成本效益的架构。 🚀
Source: …
“核”选项：尖叫测试
说实话。有时你没有任何文档、日志，甚至没有时间。服务像个不透明的盒子，进行 考古挖掘 可能要花几个月。在这些罕见的情况下，你可以执行受控的“尖叫测试”。
这不是牛仔式的冲动行为，而是经过计算的风险。
-
预演环境 – 将服务关闭，并保持关闭一个完整的冲刺周期。如果 QA 团队没有发现任何异常，这就是你的第一块证据。
-
生产环境 – 像外科手术一样计划：
- 在低流量时段（例如周六凌晨 2 点）宣布维护窗口。
- 准备好回滚方案——只需一条命令或一次点击即可让服务恢复上线。
- 关闭服务后等待。
- 如果一小时后没有任何反应，你可以相当有把握地认为它不再被使用。
- 如果一周后仍然没有任何反应，你可以非常有把握。
- 如果三周后 BI 团队因为季度报告失败而找你，你就有答案。你可以暂时把服务重新上线，然后转向 永久修复 方法，此时已经掌握了已知的依赖关系。
警告： 请谨慎使用此选项。若出现问题，可能会损失信任。但有时，这是解决深层技术债务、最终摆脱“幽灵”成本的唯一办法。
示例 Terraform 计划（目标）
# module "legacy_data_aggregator" {
# source = "./modules/ec2-cluster"
# ...
# }
# The above module will be removed in release v3.45.0 on 08/15.
# Ticket: DEVOPS-1234
# Reason: Service has been superseded by the 'realtime-metrics-api'.
# Contact: #devops-team on Slack
👉 阅读 TechResolve.blog 上的原文
☕ 支持我的工作
如果这篇文章对你有帮助，你可以请我喝杯咖啡：
👉