High-availability systems need a way to stop two machines from believing they both own the same job. Fencing is that safety line. It may power off a host, revoke storage access, disable a switch port, remove a cloud instance, or otherwise prove that the old owner cannot keep writing after failover begins.
A common example is a database cluster where the primary loses network contact with peers but still has disk access. If the standby promotes itself while the old primary continues accepting writes, data diverges. Fencing makes the uncomfortable decision explicit: before the standby becomes primary, the system must make the old primary harmless. Without that step, fast failover can create a worse outage than slow failover.
Good fencing is boring and tested. Operators should know which device performs the action, how long it takes, what evidence confirms completion, and what happens when the fence device itself is unreachable. It should also be safe for a tired operator to verify during a stressful maintenance window.