Changes to your computer network have the possibility of causing unintentional end-user impacts if the change blows up and/or is not well thought out.
Infrastructure includes:
- Servers
- Firewalls
- Web Filters
- UPSs
- NAS Storage Arrays
- Network Switches and Routers
- Internet Connectivity Routers and Modems
- WiFi Access Points
- Printers
The following recommendations for infrastructure changes follows industry best practices:
- All changes should be documented with some type of tracking ticket.
- All changes should have a back-out plan. If there is no back-out plan, then the change should not be implemented.
Example: Firmware needs to be updated on a Barracuda Firewall. The back-out plan would be to install the previous version of firmware. That means that the previous version firmware file must be readily available. - All changes should have a test plan. How will you know if the change is working correctly. A change should not be implemented if there is no test plan. If you make a change and follow your test plan, then there should be no unintentional impact to end-users. If there is an impact, then you did not have a very good test plan.
- Whenever possible, make the change on a Development piece of equipment before making the change on a production piece of equipment.
- Some changes will result in a brief impact to end-users. Those types of changes should be made outside of business hours.
Example: Upgrading the firmware on a Netgear switch requires that the switch be rebooted. Rebooting the switch will impacted any end-users that are attached to the switch. This type of change should only be made outside of business hours. Keeping in mind that some end-users may be using the system outside of business hours. - Whenever a change is going to impact several end-users, then contact the end-users several days in advance of the change so that they will know what to expect. After the change is completed, then follow-up with the impacted end-users to make sure that everything is working OK. If a planned change will impact all end-users, then an All Staff email should be sent out in advance of the change. The end-users may bring up issues that had not been considered.
- Do not implement changes if you do not understand why the change is needed, what the change will impact on operation, etc. If you are implementing a vendor recommended change, then the vendor will provide info as to why the change is needed. It never hurts to give advance notice to the IT team about a change that you plan to implement.
- After the change is completed, then let the IT team know that the change was successful. The IT Team should not have to try to figure out why the system is working differently – after a change has been made.
- Any associated documentation needs to be updated after a change is made. Do not wait weeks/months to update documentation.