Best practices for Maintenance Schedules

[Roger Poore]

As it is now, our shop is using one schedule for all of our IT maintenance.   Regardless of whether the maintenance is on a critical business service or a single cluster node, we have to use the same time blocks to perform the maintenance.  

The way I see it, business services should have separate maintenance windows.     For example, performing maintenance on the Active Directory business service is hardly the same as performing maintenance on one of 6 domain controllers.     In addition to that, performing maintenance on a single node system isn't the same as performing maintenance on one node out of a 3 node cluster.

So, my plan is to have two main categories for maintenance windows:   one for business or IT services and another for the underlying servers/systems that provide those services.

There's more but I'd like to get some opinions on my plan to separate those things first.   Bad plan?   Good plan?

Thanks

-Roger

[ArunKRam]

Hi Roger,

i think its a very good plan to separate it, said that i would like to tell you that you should have different classes for the cmdb items which you mentioned on top which will help you to achieve your requirement. In the schedule window, you can choose the table in "Applies To" field.

Thanks,

Arun

[Christian Prob2]

Hi Roger,

what are you trying to achieve?

If the one schedule works for your business don't complicate things just because it's possible or feels right 😉

Are you using maintenance scheduled for automated change conflict identification - then it makes probably sense, assuming you have enough time windows to define multiple schedules for the various services (or service lines).

Also what has been driving this in my past lives was the SLA with the business where agreed, pre-defined maintenance windows were documented. Do you have any agreements regarding maintenance windows with your business / clients?

One of my current clients has the same setting as your 'old' status and for them it works. If they would introduce different windows if would limit the various service owners to default scheduling into those windows and using another "free" slot not assigned to their service would be impossible or require extra effort.

Hope that helps a bit?

Christian

---

Please "like" or mark helpful if you feel so 🙂

[Roger Poore]

Hey Christian!

The static "change windows" that we have now were brought to us by management who used that process at a former company.     I am one of 3 engineers that are responsible for hundreds of servers.   Our change windows are Tuesday after 9pm, Thursday after 9pm, and Friday 6pm-8am Saturday.   Many of our systems are multi-node clusters so bringing down a single node affects nothing but that single node.   Yet, we are forced to make this change after hours.   When I have a bunch of systems to patch, well, there goes my night.

So, this static thing may work for our management but it doesn't work for the people that are responsible for actually making the change.

We aren't using any maintenance windows or SLA's or agreements but that's where I want us to move toward.     I just wanted to to gather some opinions from this community and use them in my quest for better change management.

I do appreciate everyone's input.

[Christian Prob2]

Hi Roger,

So if I understand you correctly, "all" you would achieve by defining such maintenance windows is a better guidance for you guys which system would go into which windows so it would help you avoiding a situation where you work on a "business service" component and at the same time on an infrastructure or underlying shared service that may be required for the business service.

Sounds like a good idea to start with.

Still wouldn't save you from loosing an entire night every now and then nor allowing you to execute no-impact changes in multi-cluster systems during service hours. For that - I guess - you still need to chat with management. If you are relating incidents to changes in ServiceNow you may be able to collect better data how risky - or in this case non-risky those changes are and maybe the helps you to convince your management to take a different approach that works better for you without impacting availability adversely...   just a thought 🙂

Christian

----

Please "like" or mark helpful if you feel so 🙂