Operate

From request to response

A practical loop for publishing an application, seeing what Tiyi sees, investigating suspicious traffic, and making the narrowest safe change.

1. Publish an application

Start the backend, create a site, and verify routing before changing public DNS. A newly created site is active immediately; the one-step command creates its upstream pool and uses the built-in Standard policy.

tiyi site create \
  --name shop \
  --host shop.example.com \
  --upstream-url http://10.0.0.20:9000 \
  --tls none

curl -i -H 'Host: shop.example.com' http://127.0.0.1/

Use Application Delivery → Sites for TLS, path routes, health state, and site-level security overrides. For one hostname with several apps, use longest-prefix routes such as /api/ and /static/, keep a fallback, and probe every route after saving.

2. Establish a baseline

In Overview, select a site and time range, then inspect request rate, blocked rate, status classes, latency, and top attackers. Use Monitoring → Telemetry Explorer for Top-K and API Inventory; use Monitoring → Log Pipeline for consumer health.

Truth planeAnswersFailure isolation
Exact countersHow much traffic passed or was blocked?Never sampled by detail policy.
Findings/evidenceWhat happened and which requests prove it?Compact and retained for investigation.
Detail + SIEMWhat must be exported or examined deeply?Independent retry; cannot block proxy traffic.

3. Investigate an alert

  1. Open Detection & Response → Active Alerts and follow its evidence URL.
  2. Pin site and time range, then copy the X-Request-Id.
  3. Correlate the Security Finding with access and error evidence.
  4. Review the Incident lifecycle, source/target, Geo/ASN caveat, and MITRE projection.
  5. When incidents share a larger source/target/TTP pattern, triage the persistent Attack Campaign and its revisions, graph, and timeline.
  6. Acknowledge, assign, and note the case; resolve only after mitigation is verified.

AI is advisory. Enrichment is optional and default-off. Verify retained evidence and the compiled policy before applying any suggestion.

4. Tune safely

  1. Reproduce and identify the rule, site, path, and client class.
  2. Preview effective policy or inspect the UI diff.
  3. Use log-only/canary behavior where available.
  4. Scope exclusions to the exact rule and path.
  5. Send malicious and legitimate regression requests.
  6. Watch blocked rate, status codes, and new Findings after apply.

An IP allow list is not a rule exclusion. A WAF bypass skips remaining inspection and must be scoped more tightly than a normal per-rule pass.

5. Operate agents

tiyi agents issue-token --tag edge --ttl 1h
tiyi agents list

Use Agent Groups for stable targeting. Before rollout, inspect the bundle diff; afterward verify online state, applied revision/hash, apply result, and proxy health. “Offline” and “online on an old revision” are different failures.

6. Daily and change checks

Daily

Health, disk, certificate expiry, agents, pipeline backlog, firing alerts, open incidents, campaign changes, API Inventory, failed SIEM/channel delivery, and audit chain.

Every change

tiyi doctor → tiyi diff → apply → health → functional request → tiyi audit verify.

Back up state.db, the KEK, uploaded certificate sources, license, and declarative manifests. Test restoration, not just backup creation.

← PreviousInstallation