This runbook is for platform or SRE operators carrying out a bounded RAG maintenance change. It explains what to change, what must keep serving, and when to stop; choose and assess the deployment topology separately before using it.
Key takeaways
- Separate serving and change paths: identify what must remain reachable while maintenance proceeds.
- Write the stop decision first: name the approver and the observed conditions that end the change.
- Verify the user workflow after each step: include source freshness and access, not just a healthy process.
Prepare for the change
List the components used by the workflow and mark which are changing and which must keep serving. Record versions, configuration, recovery method, and accepted source state; name the application owner, infrastructure operator, and authorized approver. Follow the product's supported procedure, not a generic rolling-upgrade assumption.
Execute one observable step at a time
| Step | Operator action to define | Check before continuing |
|---|---|---|
| Prepare | Confirm recovery material, owners, and the permitted window | Representative queries and monitoring work before the change |
| Drain | Apply the supported request or connection-draining procedure | Remaining serving capacity and in-flight request behavior are visible |
| Change | Update only the component named in this step | The expected surviving route still answers the agreed probes |
| Switch (if supported) | For deployments with an alternate serving route, confirm the destination is ready, then route traffic using the supported procedure | User probes pass on the destination; drain the previous route only as supported |
| Rejoin | Restore the component through its supported procedure | Data state, readiness, and client routing meet the chosen criteria |
| Verify | Run user-level allowed and restricted cases | Answers use accepted sources and preserve current access decisions |
Follow the selected topology's supported order; this is not a universal switch sequence. If no serving route remains, agree on a maintenance interruption rather than assume service will continue.
For the documented Oracle configuration, Oracle's application-continuity documentation describes coordinating planned maintenance with clients; follow the equivalent supported procedure for the selected retrieval engine.
Decide how to handle interrupted requests
Record whether reads can be repeated, how clients reconnect, and the overall user deadline. For writes and tool calls, define idempotency—how to avoid duplicate actions—and how to determine whether the action completed after a timeout, since a timeout alone does not reveal the result. Keep the last accepted user result distinct from backend completion so operators can detect work continuing after the request ends.
Assign maintenance ownership
Seahorse Cloud's product page describes document parsing, vector synchronization, and managed agents. Map the selected configuration's components to this runbook, then confirm the service agreement, hosting and SaaS or installation terms, and supported update procedure to establish whether the supplier or customer owns each change before production.
Roll back to an accepted state
Before starting, agree stop criteria with the authorized change approver: failed allowed or restricted probes, unacceptable errors or latency against the agreed baseline, or stale or withdrawn sources. If a criterion is met, use the supported rollback or recovery path and rerun the user probes. Preserve current permission revocations and source withdrawals when restoring older technical state.
Close the change when the owner accepts the workflow and records versions, limitations, and follow-up.