OSS QPS/Bandwidth Quota & Throttling Diagnosis

Diagnose Alibaba Cloud OSS quota and throttling problems: "my requests get 503 TotalQpsLimitExceeded at peak hours", "the bucket bandwidth seems saturated during nightly backups", "clients time out but the OSS side shows no errors", "how do I apply for a higher QPS/bandwidth quota or dedicated bandwidth".

Core approach: verify the caller identity, locate the bucket's real region and attributes with the read-only GetBucketInfo control-plane query, report the official quota context of that region (bandwidth/QPS defaults, sourced from the official documentation), then run a symptom decision tree that attributes 503 / SlowDown / timeout symptoms to server-side throttling, hotspot partitions, or the client-side/network path. OSS exposes no public API to query the actual bandwidth/QPS watermark (utilization) - watermark assessment is knowledge guidance only (console Usage Query > Basic Data, CloudMonitor, x-oss-qos-delay-time header). Conclude with evidence-based findings only; this skill never changes anything and never submits quota applications.

Absolute Rules

1. ABSOLUTE PROHIBITION (read-only enforcement): Under NO circumstances may you generate, write, or execute any command/script calling a mutating OSS API - e.g. PutBucket*, PutObject*, DeleteObject*, any ACL/policy/QoS configuration change. This includes commands "for the user to run manually". Quota increases and dedicated-resource (resource pool QoS) applications are ticket-based: only output the application guidance, never submit anything.
2. MANDATORY entry-point enforcement: All diagnostics MUST be performed by running the scripts under scripts/ (oss_quota_diagnosis.py as the entry, sts_token.py for identity). The Agent is forbidden from assembling its own ossutil / SDK / curl commands against the OSS control plane or bypassing the scripts - the scripts embed timeout, error degradation, and observability guarantees. Read the script output, interpret it, and compose the report; do not re-implement the queries.
3. ABSOLUTE PROHIBITION (credential handling): Never read, print, or pass raw credential values (key pair or session token) explicitly. The OSS SDK resolves credentials exclusively from the environment variables of the default credential chain; the identity check uses the aliyun CLI default credential chain. Never accept credential values from the user or from another script.
4. NO FABRICATION (watermark honesty): OSS has no public API to read the actual bandwidth/QPS utilization. Never present guessed or invented watermark/utilization numbers as measured data; the quota context this skill reports is the official default limits, and actual utilization must be checked in the OSS console (Usage Query > Basic Data) or CloudMonitor, or via the x-oss-qos-delay-time header of throttled responses. Every conclusion must be grounded in script output or user-provided evidence.
5. EXECUTION RULE FOR ERRORS: On any API error, log [WARN] <category>: <message> to stderr, continue with the remaining steps (including the ListBuckets fallback), and still produce the final report with STATUS: DEGRADED and a NEXT_ACTION line - never silently skip or abort without a report.
6. SCOPE BOUNDARY: This skill only answers quota/throttling attribution and performance-optimization questions. It does NOT handle single-request error code troubleshooting, transfer acceleration selection, endpoint/DNS errors, billing disputes, or attack-induced traffic abuse - for such requests, state the boundary and defer to the matching skill or manual guidance only.

Official Doc Verification

MANDATORY: For configuration or usage questions, the entry script MUST be invoked with --question "". The script first matches embedded knowledge, then verifies against official OSS docs (doc_verification, llms-index). The final answer MUST cite the URLs from doc_verification.docs. If doc_verification.note starts with DEGRADED, state explicitly: "Unable to verify against online official docs (offline)."