STAROps & ROS Agent: End-to-End Cloud Resource Automation from Deploy to Recovery

Introduction

A week before a major promotion, the business decides to launch a new service. The operations engineer faces the usual grind: picking ECS instance types, designing VPC subnets, configuring SLB, sizing RDS, wiring up monitoring — across five consoles and dozens of forms. Three days later the service goes live, but the engineer is still adding dashboards and alert rules at 2 AM. Four days into the promotion, an alert fires at 2:47 AM: CPU is saturated. The engineer juggles multiple tabs and dashboards to answer three questions: what happened, how severe is it, and what to do now. Scaling out requires yet another round of console switching to check which resources can scale horizontally, by how much, and whether quota allows it.

The article argues that while each individual task is not hard, the difficulty lies in their simultaneous burden on one person. From deployment to launch, from monitoring to scaling, every phase repeats the same pattern: find the console, fill the form, wait for execution, then verify. The proposed solution is a partnership that remembers every console location, every resource dependency, and every default parameter — so the engineer only states the goal and approves key decisions.

STAROps and ROS Agent Overview

STAROps is Alibaba Cloud's full-domain intelligent operations platform built on large models and agent technology. It fuses cross-domain observability data with LLM reasoning, breaking the high barrier of traditional ops tools and data silos. Users define goals in natural language; ops agents autonomously perform dynamic planning, safe execution, and result verification — shifting from reactive response to proactive autonomy.

ROS (Resource Orchestration Service) is Alibaba Cloud's Infrastructure-as-Code service. It describes cloud resources and their dependencies via templates, automating creation, update, and deletion.

ROS Agent is a resource-management agent for cloud infrastructure. Through natural language interaction, it assists with resource planning and selection, ROS/Terraform template generation and validation, cost estimation, and authorized resource creation, modification, query, and cleanup.

STAROps digital employee provides a unified conversational entry point. It understands the problem using logs, metrics, and alerts, then delegates infrastructure planning and change tasks to ROS Agent via the alibabacloud-ros-agent skill. ROS Agent clarifies the resource goal, plans resources and dependencies, presents the plan with key parameters and estimated cost, and executes after user authorization. Multi-turn tasks are linked through session context, and execution scope is constrained by account permissions and authorization policies.

Scenario 1: Deploying a Promotional Service in 7 Days

User Request

Deploy an e-commerce promotional service in the Hangzhou region. Daily traffic 2,000 QPS, peak 8,000 QPS. Needs load balancing and database. Reference last year's event service, but this year's traffic is higher — identify what must change.

Agent Response: Five-Step Process

Clarify goals and references: Confirm historical solution, existing resources, and available monitoring data. Perform necessary clarifications on high availability, budget, and application deployment mode. Historical runtime data can be queried by STAROps and fed to ROS Agent as planning reference.

Propose infrastructure plan: Design resource architecture around load balancing, compute, database, and auto scaling. Explain trade-offs between pre-provisioned capacity and on-demand scaling. Capacity recommendations must be validated against application characteristics and stress-test results. If Redis is suggested, business integration and consistency requirements must be clarified — creating the cache resource alone does not complete the business transformation.

Validate resource constraints: Query instance types, availability zones, and inventory. Check deployment constraints against available network planning and quota information. If conflicts or unavailable resources are found, explain impact and propose alternatives; critical adjustments (e.g., CIDR blocks, AZs) are made only after user confirmation.

Produce a reviewable execution plan: Generate and validate templates. Show resource architecture, key parameters, and estimated cost. Provide reasoned suggestions for inferable parameters; continue clarifying items that require user decisions, without a fixed number of follow-up questions.

Execute after confirmation, query real results: After user approval and authorization, ROS Agent deploys via ROS, tracks stack and resource status, and returns execution results. Application release, pre-production stress testing, and business acceptance must be completed separately with actual application tools; template validation and successful resource deployment do not equal passing business stress tests.

Deliverables

A reusable infrastructure template, a document of key configurations and cost estimates, and the resource stack execution results with related resource information for future reuse and iteration. If the task includes application deployment, the application access endpoint is also verified and returned.

Scenario 2: One-Command Data Integration and Alerting

User Request

/数据接入

Help me integrate logs, metrics, and APM application monitoring for the promotional service just deployed, then configure alerts to notify the operations DingTalk group.

Agent Response

STAROps provides a dedicated /数据接入 skill. The agent reuses the resource stack information from the current session, confirms the scope of services, hosts, and dependent resources, checks existing metrics, and guides the onboarding of log collection, required clients, and APM agents. Once logs, metrics, and trace data are queryable, it configures alerts for CPU, memory, load balancer, application error rate, response time, etc., and confirms thresholds, duration, and notification channels.

Recommend confirming that logs, metrics, and traces are queryable before configuring basic resource and application alerts. I will first list the collection scope, integration methods, alert rules, and notification channels, then execute after confirmation.

Key Principle

First have queryable data, then have usable alerts. Through the /数据接入 skill, users describe requirements around the same promotional service; the agent guides data integration and alert configuration. Subsequent troubleshooting then has logs, metrics, and traces as evidence.

Scenario 3: Alert Triggered — Root Cause Analysis and Recovery

Context

The promotion starts. Pre-warm scaling did not complete in time: the auto-scaling group's CPU target is 60%, but only 6 ECS instances are serving traffic, with CPU already above 85%. The scaling group has triggered scale-out, but new instances are still starting and becoming application-ready. The alert fires before scale-out completes. Numbers and target values below illustrate the decision process; actual capacity must be determined from real-time traffic and stress-test results.

Diagnosis

STAROps correlates the alert, logs, metrics, APM traces, and resource topology to judge business impact and bottleneck location, and cross-checks recent changes. ROS Agent queries relevant resource status, availability, and constraints to assist in formulating an infrastructure change plan. In this example, diagnosis points to insufficient ready capacity at launch: traffic grows faster than new instances can enter service.

Current 6 ECS instances all exceed 85% CPU; load balancer backend shows health-check timeouts; database and network metrics show no obvious anomalies. Auto-scaling group has triggered scale-out, new instances not yet ready. Lowering the CPU target value cannot shorten the startup time of this batch of instances. Below are three approaches ordered by degree of change to the running environment, from aggressive to conservative.

Three Recovery Strategies

Strategy 1: Aggressive — Rolling Upgrade

Action: After confirming spare capacity, drain traffic from each instance, upgrade ECS instance type and reboot, restore traffic after health checks pass; sync the upgraded type for subsequent scale-outs.

Applicable when: Current instance type is too small, horizontal scaling is limited, and there is a maintenance window or sufficient redundant capacity.

Cost & boundaries: Involves downtime or reboots; available capacity decreases during cutover; higher cost and change risk. Merely modifying the scaling configuration does not upgrade existing instances.

Strategy 2: Moderate — Scale Out Same Spec

Action: Determine target total capacity from real-time load and stress-test results, account for instances already starting, and fill the gap; adjust maximum instance count if needed.

Applicable when: Service can scale horizontally, need to increase capacity while avoiding changes to existing instances. This is the primary candidate in the example.

Cost & boundaries: Adds instance cost; still constrained by quota, inventory, and instance readiness time. If current scaling activity does not allow concurrency, must wait for it to finish before adding more capacity.

Strategy 3: Conservative — Adjust Scaling Policy

Action: For example, lower CPU target from 60% to 50% so future scaling retains more capacity headroom, and observe the outcome of the current scale-out.

Applicable when: Current scale-out is about to complete, in-flight capacity is already sufficient, and business error rate and latency remain acceptable.

Cost & boundaries: Lower target usually requires more instances. Relief for the current gap depends on new capacity becoming ready; cannot directly accelerate instance startup.

In this scenario, the agent prioritizes Strategy 2 (fill capacity gap with same-spec instances). If verification shows that in-flight instances are already enough to handle traffic and business metrics are acceptable, Strategy 3 (observe) can be chosen.

Execution and Verification

After the user selects a strategy, ROS Agent explains target capacity, estimated cost, and execution conditions. Upon confirmation and authorization, it executes and queries the resource change results. STAROps then verifies recovery effectiveness using application readiness, backend health checks, error rates, and response times. Resource change success does not equal business recovery.

Cross-Scenario Summary

The following comparison captures the user's role, traditional approach, and agent-assisted work across the three scenarios:

Scenario 1 (Deploy): User states deployment requirements, answers key decisions, approves plan. Traditional: modify last year's parameters, fill forms in five consoles, worry about launch stability. Agent assists: resource planning & selection, deployment constraint validation, template generation & validation, cost estimation, resource deployment & result query.

Scenario 2 (Data Integration & Alerting): User describes log, metric, APM, and alert needs via /数据接入. Traditional: separately configure log collection, metrics, APM, and alerts. Agent assists: organize collection scope, verify integration status, configure alerts and notifications.

Scenario 3 (Incident Response): User asks for root cause in one sentence, confirms recovery plan. Traditional: cross-console investigation, meeting to align plan, manual scale-out. Agent assists: cross-verify logs, metrics, traces, and topology; compare upgrade, scale-out, and policy adjustment options.

Applicability

ROS Agent suits infrastructure tasks that require resource planning, dependency orchestration, and multi-step execution. Typical scenarios: planning cloud resources from business goals; generating, interpreting, validating, and modifying ROS/Terraform templates; creating, updating, querying, and cleaning up cloud resources; clarifying requirements, adjusting plans, and confirming operations through multi-turn dialogue. Resource count is not a capability threshold.

For simple queries of a single known resource or general cloud product knowledge Q&A, STAROps can handle directly with its built-in capabilities — no delegation needed. Tasks unrelated to infrastructure are outside the scope of this article.

The integration demonstrated and validated here covers Alibaba Cloud resource management, involving ECS, RDS, Server Load Balancer, VPC, Redis, OSS, and other cloud products. Executable operations depend on resource type, service capability, and account permissions. For create/update/delete actions, the agent shows scope and impact and requests confirmation per authorization policy; execution remains subject to RAM permissions.

Quick Start

Log in to the STAROps console (https://starops.console.aliyun.com/) and create a digital employee.

In the Skill Center, search for alibabacloud-ros-agent and attach it.

Describe your deployment or troubleshooting needs in the chat box.

Actual time and results depend on your account's resource scale, monitoring data completeness, and chosen plan. It is recommended to verify the flow first with a non-production requirement.