You provisioned three web servers from the same image. Six months later, one handles 40% more traffic than the others, one crashes on Tuesdays, and one has a Python version nobody remembers installing. Welcome to configuration drift: the slow, silent divergence of systems that were supposed to be identical.

Drift happens because servers are touched. Someone SSHs in to debug a production issue and installs tcpdump. A hotfix bumps a kernel parameter. An auto-updater runs on two boxes but not the third because the third was rebooting. Each change is small. None get recorded. After a year, your "fleet" is a museum of accumulated exceptions.

Why it matters: drift breaks the core assumption that lets you reason about distributed systems — that any instance behaves like any other. When drift exists, load balancing becomes a lottery, incident reproduction becomes archaeology, and rolling deploys become russian roulette.

Real-world example: Knight Capital, 2012. A deployment updated code on 7 of 8 servers. The 8th ran old code that reused a repurposed feature flag. In 45 minutes, the mismatched server executed $7 billion in erroneous trades and lost the company $440 million. One drifted server. One flag. Bankruptcy.

How to fight drift:

• Declarative configuration — describe desired state (Ansible, Terraform, Kubernetes manifests), not the steps to get there. The tool reconciles reality against the spec.
• Immutable infrastructure — never modify a running server. Rebuild from an image and replace. Drift can't accumulate on a server that only lives for a week.
• Disable SSH in production — the fastest way to prevent manual changes is to make them impossible. If you need to debug, you need better observability, not shell access.
• Continuous drift detection — tools like chef-inspec, osquery, or AWS Config compare running state against desired state and alert on deltas.
• Reprovision on a schedule — the Phoenix Server pattern: kill and rebuild instances weekly. Drift resets to zero.

Rule of thumb: if the mean age of your production instances exceeds 30 days, you have drift, whether you can see it or not. If it exceeds 90 days, you have snowflakes. If any single instance has been running for more than a year, you have a pet with a name and a story, and rebuilding it will be a multi-week project.

The uncomfortable truth: drift isn't a technical problem, it's a discipline problem. Every "just this once" SSH session is a deposit in a debt account that compounds silently until it forecloses on you during an outage.