Operations & Infrastructure

Configuration Drift

sharppoint 

Configuration Drift: When Identical Systems Stop Being Identical

Configuration drift is what happens when systems that were once identical slowly diverge over time, even though no one explicitly decided to change them. At the start, everything looks clean. Setups are cloned, procedures are copied, and standards are documented. Then real operations begin. Small changes are made to solve immediate problems, exceptions are handled manually, and temporary fixes quietly become permanent. Months later, systems that were supposed to behave the same way no longer do — and no one can fully explain why.

This drift doesn’t happen because people are careless. It happens because systems operate under real conditions, not ideal ones. Time, pressure, staff turnover, and local constraints all push systems away from their original configuration.

Why Configuration Drift Is Almost Inevitable

The assumption behind “identical systems” is that sameness can be preserved through documentation and intent. In practice, sameness requires continuous enforcement, and enforcement is expensive. Every time a workaround is applied, a parameter is adjusted, or a process is bypassed to keep things moving, the system shifts slightly. Each shift feels harmless in isolation. Collectively, they create divergence.

Drift is especially common in environments where uptime matters more than cleanliness. When the priority is “don’t stop operations,” people fix what’s in front of them rather than realign everything back to standard.

Oil & Gas: Same Standards, Different Reality

In Malaysia’s oil and gas sector, this phenomenon is well understood, even if it’s not always called configuration drift. Companies operating under Petronas standards may have multiple facilities, terminals, or offshore assets designed around the same operating procedures, safety frameworks, and maintenance schedules. On paper, these sites are configured identically.

In reality, each site adapts to local conditions. One facility may adjust inspection intervals because of weather exposure. Another may use a slightly different workaround due to equipment availability or vendor lead times. A third may rely more heavily on experienced personnel rather than documented procedures. Over time, the sites remain compliant at a high level, but operationally they behave differently. When an incident occurs, the question is rarely “what failed?” and more often “why did this site behave differently from the others?”

The drift didn’t come from violating standards. It came from operating within them, under pressure.

Government-Linked and Regulated Operations

Configuration drift also shows up in government-linked companies and regulated environments in Malaysia. Multiple branches may use the same internal systems, follow the same SOPs, and report to the same central authority. Yet daily operations differ. One branch develops informal shortcuts to handle workload. Another strictly follows procedure but compensates with extra manual steps. A third relies heavily on a particular individual to “make things work.”

From the outside, everything appears standardised. Internally, each unit has its own configuration — shaped by staffing levels, leadership style, and historical decisions. When a central change is introduced, the impact varies wildly because the starting conditions are no longer the same.

Retail and Physical Infrastructure Drift

Configuration drift isn’t limited to technical systems. In large malls such as Sunway Pyramid, retail outlets may operate under identical tenancy agreements, operating hours, and facility rules. Yet stores drift operationally over time. One unit negotiates informal access arrangements. Another adapts staffing to cope with specific footfall patterns. Maintenance practices differ based on past incidents or relationships with contractors.

When something goes wrong — power issues, access delays, or operational disruptions — some outlets recover quickly while others struggle, even though they are supposedly operating under the same conditions. The difference is not policy. It’s accumulated drift.

SMEs and Repeated Setups

For Malaysian SMEs operating multiple outlets, warehouses, or online assets, configuration drift often appears even faster. A setup is copied because it works. Then minor tweaks are applied to deal with local constraints — landlord rules, staffing differences, supplier availability, or connectivity issues. These changes are rarely documented because they feel obvious at the time.

Months later, troubleshooting becomes confusing. An issue appears in one location but not another. Fixes that work in one place fail elsewhere. The assumption that “they’re all set up the same” becomes actively misleading.

Why Drift Is Hard to Detect

Configuration drift rarely triggers alarms. Systems still function. Output continues. Revenue flows. Problems appear intermittently and seem random. This makes drift hard to diagnose because there’s no clear failure event. Instead, there’s a gradual loss of predictability.

By the time drift is recognised, the original configuration may no longer exist anywhere. What people remember as “the standard setup” is often an abstraction rather than a real, current state.

The Cost of Drift Isn’t Failure — It’s Complexity

The biggest cost of configuration drift isn’t that things break immediately. It’s that understanding the system becomes harder. Every investigation takes longer. Every fix requires more checking. Confidence drops because behaviour is no longer consistent.

Teams start compensating by adding manual checks, informal knowledge, and cautious workarounds. This stabilises operations in the short term, but it accelerates drift in the long term. Complexity increases even though no one intended to make the system more complex.

Why Identical Is a Temporary State

Identical systems only exist at the moment of deployment. From that point on, time pushes them apart. Different people touch them. Different pressures shape them. Different local optimisations are applied. Expecting systems to remain identical without continuous effort is unrealistic.

What matters operationally is not whether systems stay identical, but whether divergence is understood. Unacknowledged drift creates false confidence. Acknowledged drift creates at least the possibility of control.

Drift Is a Sign of Life

Configuration drift is not always a sign of failure. In many cases, it’s a sign that systems are being used, adapted, and kept alive under real constraints. The danger lies in pretending drift isn’t happening, or assuming sameness where it no longer exists.

Once you recognise drift as a natural property of operating systems over time, problems stop feeling mysterious. They become explainable. And explainable problems, even difficult ones, are far easier to live with than surprises.

Recommended Posts

Operations & Infrastructure

Operational Debt: The Cost of Keeping Things “Working”

Operational debt is what accumulates when systems continue to function without being properly realigned to how they’re actually used. Unlike technical debt, which is often associated with code or architecture, operational debt lives in processes, handovers, permissions, exceptions, and informal practices. It’s the residue of survival decisions—choices that made sense at the time, solved an […]

sharppoint 
Uncategorized

Standardisation vs Reality in Malaysian Operations

Standardisation is one of the most common promises made inside organisations. Same SOPs, same systems, same rules, same expectations. On paper, standardisation creates predictability, control, and efficiency. In reality, especially in Malaysia, standardisation rarely survives contact with daily operations. What emerges instead is a negotiated version of the standard — shaped by people, environment, constraints, […]

sharppoint 
Operations & Infrastructure

Configuration Drift

Configuration Drift: When Identical Systems Stop Being Identical Configuration drift is what happens when systems that were once identical slowly diverge over time, even though no one explicitly decided to change them. At the start, everything looks clean. Setups are cloned, procedures are copied, and standards are documented. Then real operations begin. Small changes are […]

sharppoint