Compute And Disk
Compute And Disk
Assistance operates platform foundations such as cloud accounts, identity guardrails, networking, GitOps, cost controls, backups, and production readiness within an agreed boundary. This page explains the user-facing operating model for compute and disk: what Assistance can operate, what the customer owns, and how onboarding, support, changes, and escalation work.
When to use this#
Use this when a platform needs day-2 ownership, health checks, observability, backups, access reviews, capacity planning, or support handoff.
Good fits include:
- teams that need a documented operating boundary before production changes;
- retained DevOps, SRE, DevSecOps, or platform support where day-2 ownership must be explicit;
- audit, release, migration, or incident work where decisions and evidence need to be traceable.
This is not a generic vendor manual. Vendor-specific commands belong in the customer runbook only when they are part of the agreed workflow.
What Assistance operates#
Within the agreed engagement boundary, Assistance can operate or support:
- operational inventory, dashboards, alerts, maintenance windows, backup checks, change calendar, and improvement backlog;
- onboarding checklists, implementation plans, and production-readiness reviews;
- monitoring signals, alert routing, runbook updates, and incident triage;
- planned change requests, maintenance-window preparation, and rollback notes;
- handoff documentation so customer teams understand how to request help and approve changes.
What the customer owns#
The customer remains responsible for:
- business priorities, launch timing, acceptance criteria, and internal approvals;
- cloud, SaaS, identity, repository, and billing accounts unless a different ownership model is contracted;
- application code, data classification, user access approvals, and product communications;
- legal, regulatory, procurement, and risk decisions based on Assistance-provided evidence.
Engagement models#
Onboarding workflow#
- Intake — confirm systems, owners, environments, repositories, providers, risk level, and success criteria.
- Assessment — review current runbooks, access, alerts, deployment flow, security controls, and known incidents.
- Operating boundary — agree what Assistance operates, what the customer owns, support hours, severity definitions, and approval paths.
- Implementation — apply the agreed changes with reviewable pull requests, change records, and rollback plans.
- Go-live or handoff — validate the workflow, publish runbooks, confirm escalation contacts, and schedule the first review.
- Operate and improve — use incidents, failed changes, support tickets, and audits to maintain an improvement backlog.
Support and change requests#
Route requests through the agreed support channel with environment, affected service, business impact, urgency, recent changes, and relevant logs or screenshots.
Not included by default#
Assistance does not own application business logic, product roadmap decisions, or end-user communications unless those responsibilities are in the engagement scope.
Any stronger SLA, regulated compliance claim, 24/7 coverage, legal responsibility, or provider-account ownership must be written into the statement of work or support agreement.
Related docs and services#
- Cloud infrastructure
- GitOps
- Cloud account management
- Managed infrastructure
- Release readiness
- Incident response runbook
- Support and escalation
Getting started#
Open a support or onboarding request with the service area, current environment, desired outcome, deadline, and known risks. Assistance will confirm the operating boundary before making production-impacting changes.