In this technical overview we will look at automation and monitoring, and how they can be deployed to work hand-in...
You are here
3 Reasons Not to Make Major IT Changes on Fridays
Working late on a Friday night is something that every sysadmin wants to avoid. We've heard endless horror stories of servers being down and network outages occurring at the most inconvenient of times; when you are packing up to go home for a weekend of rest! However, both IT professionals and their customers continue to be guilty of making large scale system updates at the end of the week despite the consequences if something goes wrong. While it is safer for most businesses to experience periods of downtime during the weekend, you are setting yourself up for a 7 day work week by breaking the 'Read Only Friday' mantra. Every IT environment has its own unique set of processes and requirements, but here are three reasons why you shouldn't make changes on Fridays.
If something breaks, there goes your weekend
From new server installs to changing IP addresses of critical systems, there are countless IT tasks that take a few days of fixing if implementation does not go as smoothly as planned. So if your server goes down due to manual updates late on a Friday afternoon, it is highly likely that you will have to spend your weekend solving the problem if your department is reliant on its functioning. Some might be tempted for things to break so they can earn overtime, but any social gatherings or family time you have planned will have to be put on hold if your boss demands that all systems are up-and-running as soon as possible. Save yourself some sanity and enjoy your weekends away from the computer screen…there will always be more bugs to fix when you get back to the office on Monday!
Vendor support may not be 24/7
If you have full control over your IT environment and don’t mind working on a Saturday night, more power to you. But if your job requires a consistent level of communication with an external vendor, the concept of 'Read Only Friday' becomes even more paramount. Just because you are open to working on a weekend, it doesn’t mean that your vendor will be on-call for support at a moment's notice. The worst case scenario is infrastructure downtime and not having the power to fix the issue on your own, so it is vital to be on the same page with vendors and have a mutual respect for each other's time. Spending the weekends away from phone call conferences and vendor meetings is the best way to ensure the relationship doesn’t suffer from over-communication.
Your backup system may not be up to par
Having a powerful backup system should be top of mind for all IT departments, but there are plenty of organizations who still don't place enough importance on having all their tracks covered when executing major updates. If you are in the unfortunate position of working for a company with a questionable backup system, making changes on Fridays becomes even more risky. Going through proper testing before executing any upgrades should be regulatory procedure, but if something slips through the cracks and you don't have the right backup solution in place, a Friday IT overhaul is a recipe for disaster. If your backup system is not up to par, make it a priority to get a solution that gets the job done. But until then, avoid making changes on Fridays at all costs.
Standard maintenance and clean-up operations are quite common in IT. But there is a reason why 'Read Only Friday' threads run rampant on sysadmin online forums. From large enterprises to SMBs, the best way to avoid a weekend of stress is by executing large scale updates when you have the capability to fix things on the fly as necessary. Head over to Reddit if you want to read some entertaining examples of people breaking the 'Read Only Friday' rule and if you need a robust monitoring solution to ensure your IT environment is always being looked after, sign up for a trial of Opsview!
More like this
The key things you need to know when comparing Nagios to other IT monitoring solutions.
Packet loss is the failure of one or more transmitted packets to arrive at their destination. Find out how you can fix it.