Junos® OS For Dummies®, 2nd Edition

Implementing Controlled Change

In the early days of networks, changing anything was a source of anxiety and tension. Adding new links, routes, applications … in short, any hardware or software at all … imperiled network stability and introduced a new number of unknowns into the network. Therefore, network changes were “requested” and introduced at fixed intervals, usually over a weekend so that if things went haywire, the old network state would be restored by Monday.

The more essential the network to the organization, the longer the interval between changes. Small companies changed weekly or monthly. Banks changed only every quarter or so, and some critical networks operated on even longer change schedules.

No network could function that way today, but these early practices emphasized the useful idea of controlled change into networks.

Controlled change does not necessarily mean batching up changes and making them at once, although this is still sometimes done. Controlled change means that if there is a network problem, you don't just wildly plunge in and start changing configurations and operational parameters. The emphasis is on control.

Similar to “Show me a good one,” the basic idea behind controlled change is often, “Can I make the problem move somewhere else?” or the opposite of, “What do two instances of the problem have in common?” As a simple, non-network example, imagine that you have a monitor that inexplicably blanks out when a portion of the web page is blown up to ...