Ask an experienced data centre operator what causes outages and you will rarely hear about equipment failing on its own. You will hear about work that was being done at the time.
That is not an argument against maintenance. Plant that is never exercised fails when it is finally called upon. It is an argument for the discipline around the work, which is where facilities differ enormously and where very few customers ever look.
Why change is the risky state
A facility left alone sits in a known configuration. Both power paths are live, the transfer has not been operated, and the cooling is running the way it has run for months. Nothing is being touched, so nothing is being changed into an unexpected state.
Planned work breaks that. Somebody opens a breaker, tests a transfer, takes a chiller offline, updates a controller or re-terminates a cable. For the duration of the work the facility is deliberately in a reduced-resilience state, often running on a single path. If something unrelated fails during that window, the redundancy that would normally absorb it is not there.
That is the whole argument for procedure. Not that the work is hard, but that the window is the exposed period.
What a MOP actually contains
A method of procedure is a script rather than a description. A useful one states the scope and what is explicitly out of scope, the current state of the systems involved, and then a numbered sequence where each step names the action, the person performing it and the expected observable result.
That last part is what separates a real MOP from a task list. "Open breaker 2B" is an instruction. "Open breaker 2B; confirm load transfers to path A and that path A current rises to approximately the previous combined figure; confirm no alarms on the UPS" is a step with a verification built into it. If the expected result does not occur, the procedure stops there rather than continuing on an assumption.
It should also state the risk level, the systems whose redundancy is reduced during the work, the duration, and the conditions under which the work will not proceed at all.
The back-out plan is the part people skip
Every MOP needs a documented route back to the starting state, and it needs to be honest about where that route ends. Many changes have a point of no return: a cable is cut, firmware is committed, a configuration is written. Before that point you can reverse; after it you can only go forward.
Knowing where that point sits, and deciding deliberately whether to cross it, is the difference between a controlled change and an improvised one. A back-out plan that reads "reverse the above steps" has not been thought about, because most sequences are not symmetrical.
Windows, freezes and why they exist
Maintenance windows exist to concentrate risk into periods when the consequences are lowest and the right people are available. The same logic drives how redundant power paths are maintained one side at a time. In practice that means scheduling work when load is predictable rather than simply when it is low, because a facility running at an unusual operating point is not a good time to introduce a change.
Change freezes are the other half: defined periods when nothing non-urgent happens. Around major customer events, during extreme weather, or when a known fault is outstanding elsewhere in the facility. Freezing change during a heatwave, when cooling has no margin, is an obvious example in this region.
A provider with no concept of a freeze is a provider whose change calendar is driven by vendor availability rather than by risk.
Approval is a separate role, not a formality
The person performing a change should not be the person approving it. That is not about competence; it is about the fact that the engineer closest to the work is the least able to see its interaction with everything else happening that week.
A functioning approval gate asks a small number of questions. What else is in a reduced-resilience state right now? Has this procedure been performed here before, and what happened? Who is on site, and who is reachable if it goes wrong? Is the back-out plan valid for the whole sequence? Has the customer been told?
Most facilities have a form. Fewer have a reviewer who will decline.
What customers should be told, and when
Colocation customers are usually notified of planned work that could affect them, but the quality of that notification varies widely. A useful notice says what is being worked on, which of your systems lose redundancy and for how long, what you would observe if the change went badly, and who to contact during the window.
A notice that says maintenance will occur between two times and that no impact is expected gives you nothing to plan around. If your workload has a period where a transfer would be particularly unwelcome, you can only say so if you were told in enough detail to know.
This connects directly to what your agreement actually commits the provider to. Our guide to hosting SLAs, uptime and support terms covers how planned maintenance is usually carved out of availability guarantees, which is worth reading before assuming a window counts against uptime.
How this shows up in commissioning
Change discipline is easiest to build at the start. A facility that was commissioned properly has documented, tested procedures for the transfers and failovers it will need for the rest of its life, performed once under controlled conditions with nobody's workload on the floor.
A facility commissioned loosely discovers those procedures later, in production, with customers connected. The MOP for a transfer that has been executed before under test conditions is a very different document from one written from a manufacturer's manual.
What to ask a provider
Who approves changes, and is that person independent of the engineer performing them? How far in advance are customers notified, and what detail is included? Is work that reduces redundancy ever performed outside a defined window? Do you operate change freezes, and what triggers one? Will you share a redacted MOP for work affecting my power path? When did you last perform a full transfer test, and what was the result?
The last question is the most revealing. A provider who can answer it with a date and an outcome is operating a tested facility. One who cannot is operating a facility whose redundancy is theoretical.
The practical point
Resilient design and resilient operation are different things, and only one of them appears in the marketing. A 2N facility operated without change discipline will deliver worse availability than a well-run N+1 one, because the exposure is not in the topology but in what happens during the hours when somebody is working on it.
Rax Data & Energy operates to documented procedures with approval separated from execution, and shares the detail of planned work affecting a customer's power path rather than issuing a generic notice. If you are evaluating providers and want to compare how each one actually handles change, talk to our team.
A Real Energisation Date, Not a Brochure
Rax operates where transmission investment has run ahead of load, and we are direct about staged capacity and real dates. Talk to our team about sizing a deployment against a timeline.
Contact Rax Data & Energy