How to reduce the DevOps bus factor in a software agency

If the person controlling Terraform, CI/CD, access and production is unavailable tomorrow, can the agency keep operating?

The bus factor describes how many people can disappear from a project before work becomes blocked. In many technical agencies the real number is one, even when the organisation chart suggests otherwise.

Signs of critical dependency

Dependency is not assessed by asking whether documentation exists. Observe who can execute the work:

• only one person can deploy to production;
• credentials are tied to personal accounts;
• every Terraform change needs the same reviewer;
• nobody else knows the recovery procedure;
• incidents go directly to whoever created the system;
• holidays cannot overlap important releases;
• the team avoids touching “sensitive” components.

The risk is not only an outage. Waiting, interruptions and conservative decisions also reduce delivery capacity.

Map jobs, not tools

A technology inventory does not reveal dependency. List concrete operational jobs instead:

• create an environment;
• grant and remove access;
• deploy and roll back;
• rotate a secret;
• respond to an alert;
• recover a backup;
• attribute a cost;
• onboard a client.

For every job, record who knows how to do it, who has permission, what documentation exists and how long it takes.

Remove personal access paths

Shared accounts are not the answer. The target is individual identities, roles, traceability and an emergency process.

Governed access makes it possible to know who can change production, who approved a change, which privileges are temporary and what happens when someone leaves.

Turn memory into an executable path

Descriptive documentation is not enough. Critical procedures should include:

1. conditions for starting;
2. required access and information;
3. verifiable steps;
4. success and failure signals;
5. rollback;
6. owner and escalation.

Where reasonable, that path becomes a reviewable pipeline, template or automation.

Distribute ownership

Reducing bus factor does not mean everyone knows everything. It means each layer has a primary owner, a backup and known boundaries.

Application, data, infrastructure, security and support may have different owners. The key is defining handoffs so an incident does not rely on informally finding “the person who knows”.

Test an absence

The best review is practical. During a controlled period, the key person does not intervene in a routine task. The team follows the runbook and records blockers.

This reveals undocumented credentials, implicit decisions and steps that are still not reproducible.

A responsibility map that can be reviewed

A simple table forces the team to separate knowledge, permission and accountability:

Job	Primary owner	Backup	Evidence	Last test
Production deployment	Platform	Senior developer	Pipeline and release record	Date and result
Secret rotation	Security/platform	Technical lead	Inventory and change log	Date and result
Data recovery	Platform	Application owner	Restore report	Date and result
Emergency access	Technical lead	Authorised leadership	Temporary-access record	Date and result

Writing two names does not create backup. The second person needs permission, must understand the procedure and must have executed it under controlled conditions.

Minimum runbook template

A useful runbook contains decisions, not commands alone:

procedure: production-rollback
trigger:
  - error_rate exceeds agreed threshold
  - healthcheck fails after deployment
authorisation:
  owner: platform-owner
  backup: senior-developer
steps:
  - freeze new deployments
  - identify previous verified version
  - execute rollback from pipeline
  - check service, data and queues
evidence:
  - deployment link
  - check results
  - close-or-escalate decision

System names, thresholds and owners must be real. Secrets should never be copied into the document.

A 90-minute absence exercise

1. Choose a frequent, reversible operation.
2. Make the reference person unavailable for the exercise.
3. Give the backup only the intended documentation and access.
4. Record every wait, missing permission, assumption and required conversation.
5. Correct the procedure and repeat it with someone else.

The participant is not being tested. The system that should enable them to work is being tested.

Automated controls that reduce dependency

• individual identities through SSO and roles;
• infrastructure as code reviewed by a second person;
• pipelines with approval, rollback and identifiable artefacts;
• automated inventory of resources and owners;
• alerts directed to a channel and severity;
• periodic backup and restore verification;
• architecture decisions stored beside the affected system.

For a primary reference on continuity, NIST SP 800-34 Rev. 1 describes analysis, strategies, plans, testing and maintenance. It does not prescribe the architecture, but reinforces one principle: an untested plan does not demonstrate recovery capability.

Acceptance criteria

Dependency is reduced when at least two identities can execute the work, use the same procedure, leave comparable evidence and verify the result without asking the system designer. The latest test should have a date, result and outstanding actions.

Useful measures

Progress can be measured without invented promises:

• deployments requiring specific intervention;
• jobs with only one enabled person;
• waiting time for routine changes;
• procedures tested by a second person;
• operational onboarding time;
• incidents always escalated to the same profile.

Reducing dependency is not about producing documentation by volume. It is about keeping the agency able to deliver when one person is unavailable.

The most honest test is to simulate one week without the reference specialist. Anything that becomes blocked, cannot be verified or requires context to be recovered from memory is part of the real risk.