Don’t let your outage window best you

Outage windows. They vary from after 5pm, to a 4 hour window per quarter, and even just 17 seconds per year. They are valuable. They are something that shouldn’t be squandered. The sad thing is that some treat them was free overtime pay and don’t give a second thought to the windows value. Generally they don’t do a second one.

I’d like to share to you something my father always loves to slip in “Prior preparation prevents piss poor performance”. You know what? As much as I may have rolled my eyes every time I heard that when I was younger, a wiser self thinks the old bugger was right.

The Change, depending on the process, can be a process that is as simple as a sign off email, notification of affected service(s) to relevant parties, and away you go. The alternative is months of planning and configuration revisions, templating, rollback procedures, last well knowns and more. Co-ordination of assets is important. No one organisation has infinite resources whether it be staff, material, or time.

The aim of this post was to engage though and thinking and not explain every caveat of a change process. Well established guidelines (yes, guidelines, not gospels) are out there such as ITIL, PRINCE, Cisco Lifecycle (think PPDIOO) and plenty others. I see guidelines are required for BAU activities. Skill sets in a team vary. Everyone has something different to bring to the team environment but all need to follow a guideline process.

Each person works in different ways. If your tasks was to provision a new Vlan, assign ports, ACLs, and a HSRP group, how would you go about it? When would you perform verification? How do you identify dependency technologies? Not everyone considers this information and attacking a problem in a sporadic fashion can lead to issues and time wasted troubleshooting. This is why guidelines exist. Picture this workflow and compare it to a haphazard, pin the tail on the donkey approach. A business could outline a workflow for small activities such as Scope, Create, Refine, Test, Implement, Verify, Close. Each step along the way, an engineer using his knowledge could complete a task knowing it would be done to a satisfactory standard. This would ensure consistency with configuration, deployment, and improve change requests.

Just some food for thought next outage window. Try creating an implementation plan or a guideline framework and see how you go?

Leave a Reply

Your email address will not be published. Required fields are marked *