byted-volcengine-topology-change-impact

Change Risk Analysis Skill

Capability Positioning

This Skill is responsible for turning a "change description" into an executable static risk analysis result.

• The input is usually a natural language change ticket, and can also be a short code/configuration change description
• The analysis basis is the existing topology.json, not runtime monitoring or real-time health status
• Focus on three types of results: risk level, impact scope, and upstream/downstream impact description
• The first version prioritizes covering two types of objects: "services/components" and "cloud resources"

This Skill does not directly build topology; if the current workspace does not yet have business_topologies/<business>/topology.json, you should first use topology-graph-builder to generate the underlying data.

Dependencies: This Skill only needs the topology-graph-builder generated by topology.json as data input. It also depends on the guidelines in references/risk_assessment_rules.md for risk inference.

Input Prerequisites

By default, look in the current workspace for:

business_topologies/
  <business>/
    topology.json
    topology.md

If the workspace contains .trae/business_topologies/, it can also be reused directly.

The prerequisite for static risk analysis is that the user provides at least most of the following two types of information.

• Change action: for example, "modify configuration", "open port 80", "scale replicas from 4 down to 2", "switch ingress CLB"
• Change target: for example, service name, component name, ECS, CLB, EIP, security group, subnet, VPC

If the user only says "help me evaluate this change" but does not specify the target object, ask a follow-up question first.

Standard Process

1. Extract the change card

First organize the user input into a simplified change card:

• change_type: code change / configuration change / scale up / scale down / network policy / ingress switching / other
• target: target service, component, or cloud resource
• action: add / delete / modify / replace / open up / tighten / scale up / scale down
• scope: if the user provides business, environment, or region, include them as well
• assumption: missing information must be explicitly marked as an assumption

If the user provides a code change or configuration change but no resource ID appears directly, first extract the most likely service name, component name, application name, gateway name, configuration item name, or resource keyword, then perform candidate matching in the topology.

2. Prioritize using scripts for structured analysis

Do not directly scan with your eyes topology.json. Prioritize executing the script included with the current Skill:

python3 ./skills/byted-volcengine-topology-change-impact/scripts/change_risk_from_topology.py \
  --node "<target>" \
  --output markdown

Among them, --node is the change target. The script is only responsible for querying structured topology data and the affected ECSs.

If the user has already explicitly provided the business:

python3 ./skills/byted-volcengine-topology-change-impact/scripts/change_risk_from_topology.py \
  --business "<business>" \
  --node "<target>" \
  --output markdown

The script directly reads topology.json internally for node matching and graph analysis, automatically obtaining:

• Matched targets and basic information
• Affected downstream ECSs
• Associated resources and ingress links
• Textual description of the upstream/downstream structure

3. Read the guidelines and infer risk with the large model

Core Requirements: The script does not output any "risk level" or "risk conclusion". You (the large model) must:

1. Read the references/risk_assessment_rules.md。
2. Combine the user's original change description (action) and the structured data output by the script (affected resources), and based on the principles in the guide,independently reason out the risk level, risk conclusion, and impact boundary of this change。

4. When there are multiple candidates, control risk first

If multiple candidates are returned:

• id:exact、public_ip:exact For high-confidence hits like this, you can proceed with the analysis based mainly on the first candidate
• If it is only name:fuzzy、metadata:fuzzy, first give the candidate list to the user for confirmation
• If service names and resource names are mixed together, clearly state that "the current matching is static matching based on topology fields and metadata"

Do not draw conclusions directly under low-confidence hits.

Answering principles

1. Conclusion first, then evidence

The answer must cover at least the following parts:

• Change object hit result
• Risk level, risk conclusion, and core reasons
• Directly affected objects
• Upstream entry links
• Downstream hosting or associated resources
• Textual description of upstream and downstream impacts

2. Distinguish confirmed impacts from potential impacts

Organize using the following three levels:

• 直接影响: 1-hop associations of the target node, or ECS / entry links that can be clearly inferred to be affected
• 潜在影响: reachable within 2 hops in the same local topology, but it cannot be statically confirmed that they are definitely affected
• 待确认项: parts lacking business boundaries, environment information, or runtime data

3. Do not fabricate service names

If the topology can only confirm infrastructure resources, honestly write:

• Currently can only locate EIP/CLB/ECS/安全组/子网/VPC
• No clear application name or service field was found
• Suggest the user supplement the service mapping relationship

4. Descriptions must serve decision-making

When outputting textual descriptions:

• You must clearly write out the change target node
• Try to clearly state the link order of "upstream entry -> intermediate forwarding -> affected ECS"
• If the target itself is not an entry resource, additionally explain its relationship with the affected nodes
• For node expression, prefer type:id, and supplement with name

5. Risk conclusions must refer to the guide

Must strictly follow the standards defined in references/risk_assessment_rules.md to output critical / high / medium / low, and translate the level into a risk judgment (including risk conclusion, impact boundary, and confidence explanation).

6. Interpretation calibers for different change types

Topology cannot directly tell you "which line of code will call whom", so the following calibers are needed for interpretation:

• If the user gives a code change: understand it as "a behavior change of that service or component", focusing on the entry link, dependency link, and hosting nodes where that node is located
• If the user gives a configuration change: understand it as "a change in routing, connections, access control, instance scale, or entry policy"
• If the user gives scale-up or scale-down: prioritize analyzing traffic entry, backend hosting nodes, and redundancy changes

The conclusion must clearly state: this is "impact inference based on static topology", not a runtime call chain.

Recommended output structure

Prefer using this template:

结论：
- 变更对象：...
- 风险等级：critical / high / medium / low
- 风险结论：...
- 核心判断：...
- 影响边界：...
- 置信说明：...

影响范围：
- 直接影响：...
- 潜在影响：...
- 待确认项：...

上下游影响描述：
- 上游入口链路：...
- 中间转发/依赖层：...
- 受影响承载节点：...
- 与目标直接关联的资源：...

判断说明：
- 本次分析基于静态 topology.json 推断
- 不代表运行时调用链或实时健康状态

Example scenarios

Example 1

User:

把 payment-api 这个服务的副本数从 4 缩到 2，帮我分析影响面，并说明它的上下游影响链路。

Answer focus:

• First try using payment-api as the node keyword to match the topology
• If the match is CLB / ECS / server_group, you can also continue the analysis
• Output the scale-in risk, risk conclusion, traffic load change, and entry link
• Provide a textual description of the upstream and downstream impact

Example 2

User:

安全组 sg-xxx 要开放 443 端口，这个变更会波及哪些上下游资源？

Answer focus:

• Match the security group
• Find the affected ECS
• Trace back the entry link
• Output the risk level, risk conclusion, verification items, rollback suggestions, and textual impact description

Example 3

User:

我要把公网入口从老 CLB 切到新 CLB，先帮我做一次变更风险分析。

Answer focus:

• Extract the "entry switch" action
• Analyze the backend server group and ECS behind the CLB
• Emphasize health checks, canary verification, rollback plan, and execution window suggestions

Fallback rules

• If there is currently no topology.json, explicitly prompt to run topology-graph-builder
• If the target node cannot be matched, directly state that there is no match and provide suggested supplementary information
• If there is only a fuzzy match, output the candidate ranking first and do not force a risk conclusion
• If the user is asking "is it already failing right now", remind them that this only performs static risk analysis