Deutsch
When a website supports sales, customer access or essential staff work, the team needs to know who can keep it running and who can act during an outage. Record who makes each operational decision, who steps in when that person is unavailable, and where authorised staff can obtain access.
This guide shows how to assign those responsibilities and document them in an owner map. Create one for each service whose interruption would affect revenue, customers, staff, contractual commitments or another important business process. Store it with the service documentation somewhere the team can still reach during an outage.
Start with the service
An owner map records who may act, who must approve a change and who receives an escalation. It answers practical questions: who may restore yesterday's database, change DNS, take checkout offline or tell customers what happened? Job titles and reporting lines alone rarely answer all of them.
Start with what customers or staff need the service to do. List the systems and decisions required to keep that function working or restore it after a failure. For each area, name a primary owner and a deputy, record where access is held, define the escalation route and note when those details were last checked.
The owner does not have to perform every task personally. They must ensure that an authorised person can follow the procedure and escalate when necessary. Even when a vendor operates a component, name an internal owner who understands the dependency and can decide what to do if the vendor cannot meet the required recovery priority.
Define the impact of an outage
Write down what makes the site critical to the business. A short impact statement should answer four questions:
- Business impact: What stops or becomes unsafe if the service is unavailable, slow, corrupted, or exposed?
- Maximum tolerated interruption: How long can the affected process remain unavailable before the consequence becomes unacceptable?
- Affected customers or processes: Which customer groups, staff workflows, integrations, revenue paths, or contractual obligations are affected?
- Recovery priority: When several systems fail together, where does this service rank and which minimum function must return first?
Use evidence where it exists: order volume, support demand, operational deadlines, contractual commitments, dependency maps, and previous incident timelines. Do not turn a rough business preference into a false technical guarantee. If the organisation has not validated a recovery time through exercises, record it as a target that still needs proof.
Describe partial failures too. The home page may load while login, checkout, form delivery, background jobs or an integration is broken. Agree which customer journeys must work before the team can declare the service restored.
Assign technical responsibilities
Assign responsibility for each system that someone may need to change or recover. A single “website owner” entry leaves gaps when different people control the server, application, domain and data.
The technical map must identify owners for:
- Server: operating system access, patching, capacity, service processes, and host-level recovery.
- Application: source code or CMS, runtime configuration, application logs, releases, and application-level rollback.
- Database: access, migrations, integrity checks, backup consistency, restoration, and data-loss decisions.
- DNS and domain: registrar recovery, domain renewal, authoritative DNS access, record changes, and reversal.
- Backups: backup-job outcome, independent copies, retention, restore procedure, and restore-test evidence. The VPS backup guide provides further recovery-planning context.
- Deployment: repository or artifact access, release approval path, secrets required by the deployment, smoke tests, and rollback steps.
- Monitoring: external availability, application errors, dependency failures, resource pressure, alert routing, and investigation records. The Zabbix introduction is one possible starting point for server monitoring, but the checks and response owners remain the team's responsibility.
- Security access: Linux users, SSH keys, privileged accounts, credential vault, emergency access, access review, and revocation.
For every primary owner, name a backup owner who can actually reach the system and use the procedure. “Engineering” is not a backup owner. Record a controlled team account or named role with an on-call path, then verify that an authorised person in that role can retrieve access without relying on the primary owner's device or memory.
