Very early in my career I worked for a small company, and when we needed to upgrade or patch systems, we did it during the day, with employees accepting downtime. Of course, there were only 2 or 3 machines for the office of 10 at that time.

Later I worked in a busy utility power plant and we had staff there 24 hours a day. Our maintenance window for the network was once a quarter, from Saturday midnight to 4 am. Going over that time required a variance from the plant manager, and we worked hard to avoid ever needing more downtime. Random reboots to fix things, in the late OS/2 and early Windows eras were grudgingly accepted, but not well tolerated.

These days, individuals usually manage their own systems, but for many applications, clients want no downtime. IT departments have built many techniques to minimize downtime, but most systems I know do go down periodically for maintenance. Sometimes this is during business hours, sometimes at nights, and sometimes on weekends. I was thinking about this when I saw maintenance windows for Azure SQL Managed Instance go into preview recently.

Since this is a managed service, you can't choose anytime. Instead you can choose nights or weekends. Changes are blocked from 8 am to 5 pm, local time, but other than 24 hour advance notice, you can't decide when updates occur. For those of us that build software, sometimes with workarounds, this is disconcerting, but I think this is the way of the new world. Many of the cloud vendors will dictate maintenance windows in some sense, and while some might allow you to delay upgrades, it will be for days, not months.

Do you get to negotiate your maintenance windows? Or is your employer flexible for how you maintain your systems? Do you get regular times to patch or even deploy new software? Are there strict blockages during certain times of the year?

I think it is important to make changes when there is limited impact to customers, but I also think we need to allow for some maintenance. I think it matters in not expecting staff to work extra hours when off hours work is performed, and give them some time back in their lives on other days.

Many jobs do require work to be performed at night or weekends, so I don't know we'll ever get completely away from that, but I do think the more you adopt a DevOps flow, where you deploy small and often, the more likely you can do so during normal hours. That doesn't help with lots of maintenance, but I hope that vendors continue to come up with better ways of allowing us to maintain systems with minimal impact on customers.