Pings

If automation cannot heal configuration drift, the question is not how to automate better — but how to observe what actually governs behaviour at runtime.

Automation does not heal configuration drift. It removes randomness — and replaces it with consistent failure.

Most incidents are not caused by bad automation. They are caused by automation faithfully enforcing assumptions that no longer match runtime reality.

Automation enforces intent. It does not explain behaviour. As long as effective runtime configuration remains invisible, automation will keep propagating assumptions — just faster.

Standardization increases consistency. It does not increase correctness. That difference matters more than most automation strategies admit.

Automation does not remove errors. It makes them consistent. If a configuration is wrong, automation ensures that everything is wrong in exactly the same way.

Documentation becomes effective when it is written by the people who do the work, for the people who do the work. It helps with repeatability, clarity and avoiding mistakes. But this value rarely scales. Local documentation reflects reality. Organizational documentation reflects narrative.

Infrastructure-as-Code treats defaults as harmless, stable and irrelevant. But defaults drift, override explicit settings and define most runtime behaviour. If IaC ignores defaults, it governs only a fraction of the truth.

Default values change silently through updates, framework patches or internal fallback logic. By the time the impact becomes visible, the original cause is already buried. Default drift is drift with no fingerprints.

Many teams produce documentation to satisfy organizational expectations — to show that systems are structured, understandable and under control. But if documentation truly reflected reality, people would say: “Read the documentation first.” They rarely do. Instead, they tell you who to ask. Documentation often describes how systems should be, not how they actually work.

Teams own services, repos, pipelines and tickets. But almost nobody owns the job of keeping the technical truth of the landscape visible and coherent. That gap is where most confusion and friction comes from.

Version control shows what you intended to have in production. Runtime shows what is actually there. Those two pictures are rarely identical – and the interesting problems live exactly in that gap.

Modern systems expose health, metrics and traces. But they don’t expose the one thing that explains behaviour: the effective configuration at runtime. That missing contract is why configuration keeps surprising us.

We declare configuration in files and repositories. But systems behave according to configuration that only exists at runtime. Until configuration becomes observable, behaviour will remain unpredictable.

Health is observable. Metrics are observable. Traces are observable. Configuration is not. That asymmetry explains many of today’s “mysterious” system behaviours.

During normal operation, assumptions are cheap. During incidents, you learn how your systems actually behave – which components really matter, which dependencies were hidden, and which “temporary” workarounds became critical path.

If you assume that systems stay as-installed, you will have a bad time. Drift starts with the first emergency change and never really stops. The question is not whether drift exists, but whether you can see it.

Most organisations try to enforce rules on systems they don’t really see. You can’t govern what you don’t understand. Telemetry comes first, then models, then rules – in that order.

Documentation does not describe what is. It describes what somebody believed was true at the time of writing. The longer the distance in time, the more you should treat it as an opinion, not as fact.

You can use the same pipeline, the same artifacts and the same scripts. The environments will still diverge over time – through permissions, data, hotfixes and operational shortcuts. Reproducibility is the goal, not equality.

Defaults are not “just” fallback values. They are production behaviour for every place where nobody made an explicit decision. Ignoring defaults is ignoring a big part of your real system design.

Most CMDBs are not “wrong” in the malicious sense. They are simply late. By the time information arrives there, the systems have already moved on. Treat the CMDB as a hint, not as a source of truth.

Most configuration doesn’t live where people think it lives. What the system actually uses at runtime is the only truth.