Fallback Procedures

The fallback process is specific to components, topology, and services enabled in the network, but all fallback procedures should include some flavor of the following elements:

  • The fallback procedure should be documented and readily available before beginning the upgrade.

  • The fallback procedure should include an estimated time duration needed to perform the fallback. General practice is to use only half of a maintenance window for a major change (such as a JUNOS upgrade). The other half of the maintenance window should be reserved for fallback time and to restore devices, connectivity, and services to the premaintenance window state. (As the old saying goes, “How far can a man walk into a forest? Halfway. If he goes further than halfway, he is in fact walking out of the forest.”)

  • The fallback procedure should identify one person, by name or title, responsible for initiating the fallback procedure. This one person will be responsible for deciding when things have Gone Horribly Wrong. If this occurs, the fallback procedure must be triggered.

  • Because there are many degrees of functionality between Horribly Wrong and completely successful, one person should be responsible for determining whether any partial functionality achieved is an acceptable state.

  • Because there are occasionally unintended consequences or side effects of reaching full functionality, one person must determine whether any of them are a threat and merit a fallback.

Get JUNOS High Availability now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.