brainstorming
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or planning anything new, in software or out of it (a talk, a business, a renovation).
byted-volcengine-capacity-auditor火山引擎资源巡检、水位评估、容量建议、趋势判断与预算优化 Skill。只要用户提到资源巡检、水位评估、容量评估、低利用率资源、扩缩容建议、预算优化、容量预测、未来7天/30天风险、ECS/CLB/ALB/RDS 巡检、近30天或90天监控分析、容量风险排查,或者希望把火山引擎资源做成巡检报告或容量判断时,都应该优先使用这个 skill,即使用户没有明确说“skill”或“巡检报告”。
Independent GitHub snapshot · Automated classification · Original documentation governs
这个 Skill 用来把“资源清单 + 近 30/90 天监控 + 规则化判断 + 巡检建议 + 趋势判断”收成一条稳定流程。
当前 V1 已验证的范围:
ECS:资源清单、CPU、内存、磁盘使用率、磁盘写 IOPSCLB:资源清单、监听器级 QPS / 并发连接 / 新建连接 / 带宽 摘要(默认先尝试拉取,失败时说明原因)ALB:资源清单、监听器级 QPS / 并发连接 / 新建连接 / 带宽 / 丢连接 / HTTP 5xx 摘要RDS MySQL:资源清单、当前 CPU/内存/磁盘快照、近 30 天 QPS / ConnUsage当前 V1 的已知边界:
CLB 当前已默认尝试拉取监听器级带宽、连接数和 QPS 摘要,但仍缺少规格上限换算与更完整口径,因此先给事实摘要和待补建议,不给结论性扩缩容判断ALB 当前已接入监听器级流量与异常摘要,但仍属于保守判断;如需更细粒度结论,还要继续补监听器/规则/服务器组维度口径RDS MySQL 的历史 CPU / Mem / Disk 监控口径尚未完全映射,当前先使用实例快照 + QPS / ConnUsage 做第一版评估如果任务是在补监控口径或排查“为什么拿不到指标”,读取 references/metric_gaps.md。
这个 Skill 内部统一处理两类请求,不再拆成两个独立 skill:
7/15/30 天风险、预算方向、扩缩容时点如果是趋势模式,读取 references/forecasting.md。
ECS / CLB / ALB / RDS MySQL 资源7/15/30 天风险10% / 业务量增长 20% / 某条链路请求上涨”来判断整条链路应该怎么扩容CLB 容量预测,但当前还没补齐连接/带宽/QPS 监控口径.env.env 至少包含:VOLCENGINE_AK=...
VOLCENGINE_SK=...
VOLCENGINE_REGION=cn-beijing
优先使用内置脚本:
python3 <byted-volcengine-capacity-auditor-skill>/scripts/run_capacity_audit.py \
--env-path ./.env \
--project-name mysite \
--region cn-beijing \
--format markdown
如果用户没有给 project-name,默认输出整个地域下的结果。
如果是链路级趋势判断,使用:
python3 <byted-volcengine-capacity-auditor-skill>/scripts/run_capacity_audit.py \
--env-path ./.env \
--project-name mysite \
--region cn-beijing \
--mode forecast \
--growth-factor 0.1 \
--link-name payment-core \
--format markdown
如果已经有拓扑产物,希望按拓扑链路范围评估链路内相关资源容量,优先使用:
python3 <byted-volcengine-capacity-auditor-skill>/scripts/run_capacity_audit.py \
--env-path ./.env \
--region cn-beijing \
--mode forecast \
--growth-factor 0.1 \
--topology-file ./business_topologies/payment-core/topology.json \
--link-name payment-core \
--format markdown
说明:
--topology-file 后,脚本会先从拓扑里提取链路内命中的资源,再按当前已支持的资源类型做容量评估--topology-file,但存在 business_topologies/<link-name>/topology.json,脚本会自动按该拓扑收敛评估范围CLB / ALB / ECS / RDS MySQLCLB / ALB 若已位于拓扑链路内,也会被纳入整链评估;其中 ALB 已支持监听器级 QPS / 连接 / 带宽 / 丢连接 / HTTP 5xx 摘要,若关键指标仍缺失,报告会明确标记为数据缺口,而不是跳过入口层默认输出两种格式之一:
markdown:适合直接给用户看json:适合继续给脚本、agent 或后续趋势判断流程消费.env 或环境变量里的 AK / SK / REGIONECS / CLB / ALB / RDS MySQL 资源清单ECS 拉取近 30 天 CPU、内存监控;补充近期磁盘和 IOPS 摘要RDS MySQL 拉取当前实例快照和近 30 天 QPS / ConnUsageCLB 默认尝试拉取监听器级流量摘要,拉取不到时说明计费方式、监听器协议或口径缺口;对 ALB 输出监听器级流量与异常摘要7/15/30 天风险当前脚本入口已经支持:
--mode audit:默认巡检--mode forecast:链路级趋势判断--growth-factor 0.1:表示场景增长 10%--link-name xxx:指定链路名称;若存在同名业务拓扑目录,会自动读取其 topology.json--topology-file xxx:显式指定拓扑文件,按拓扑链路筛选本次评估资源如果用户没有给明确阈值,默认使用这套口径,不要临时自创一套不同规则。
如果用户不是单纯要巡检,而是在问“某些监控项为什么拿不到、应该怎么补”,按下面顺序处理:
GetMetricDataNamespace / SubNamespace / MetricName / Dimensions涉及具体排查路径时,读取 references/metric_gaps.md。
默认按下面结构输出:
# 资源巡检报告
## 摘要
## ECS
## CLB
## RDS MySQL
## 建议清单
## 数据缺口
scripts/run_capacity_audit.py:主入口,输出 JSON 或 Markdown 报告参考 evals/evals.json。