Maintain five small records instead of one giant manual
- Service inventory: purpose, owner, environment and criticality of each component.
- Topology: permitted connections and dependencies between platform, hosting, data and business systems.
- Configuration baseline: approved account, group, instrument and integration settings.
- Access register: role owners and the process for requesting, reviewing and revoking access.
- Operational runbooks: detection, diagnosis, escalation and recovery for specific incidents.
Choose formats that the actual support team can maintain. A diagram that is simple and current is more useful than an elaborate architecture drawing that describes a previous installation.
Write runbooks from observable symptoms
Use titles such as “clients in one region cannot connect” or “prices are stale for one instrument group.” Start with the observations needed to establish scope, then list safe checks and escalation boundaries. State which actions require a separate approval and which steps must not be taken during an incident.
Every runbook should identify its owner, last validation date and prerequisites. Include a link to the monitoring view or configuration record without embedding credentials. Explain how to preserve a timeline so a later investigation can separate cause from recovery actions.
Document decisions and unresolved assumptions
Record why a hosting region, connection model or backup arrangement was chosen. Include the workload and business assumptions behind it. When the business changes, those assumptions show which decisions need to be reviewed. A list of current server sizes alone cannot explain whether the design still fits.
Illustrative example: a secondary region is initially used only for client access. A later team assumes it can recover the complete brokerage there. The topology and recovery record should make that distinction explicit, preventing an access location from being mistaken for a complete standby environment.
Validate the documentation through a handover exercise
- Ask an authorised operator who did not write the runbook to locate the affected service and its owner.
- Have them explain the dependency path and retrieve the approved baseline.
- Walk through a staged incident or restoration rehearsal.
- Record missing information and update the documents immediately.
For an MT4 environment, preserve the details of legacy integrations and naming assumptions. For MT5, distinguish relevant server roles and account-model dependencies. Keep documentation changes in the same release process as configuration changes, with access limited according to the sensitivity of the material.
Keep documents useful and appropriately accessible
Should access details include passwords?
Document roles, owners and the approved retrieval process rather than embedding reusable credentials in runbooks. Match access to the sensitivity of each document. An operator needs a reliable route to authorised access without turning an architecture pack into an unprotected credential store.
What proves that a runbook is ready?
A second authorised operator should be able to identify prerequisites, explain the safe steps and locate the escalation owner. A staged walkthrough exposes missing assumptions. Record its result and the last validation date so future users can judge whether the procedure matches the current environment.