VictorOps is now Splunk On-Call! Learn More.
In DevOps and IT operations, we’re always talking about building incident management plans and speeding up the software delivery lifecycle. But, another common element of IT service management (ITSM) includes change management. In general, change management is a tool for preparing people, processes and technology for any kind of organizational change. In IT operations, a change management plan refers to a framework for the implementation and upkeep of IT infrastructure and applications through change controls, processes, training and communication.
Change management is an essential principle of the IT Infrastructure Library (ITIL), ITSM and DevOps because no matter how your organization operates, it needs to be prepared for change. Complex, distributed systems and microservices in a world of continuous integration and delivery naturally lead to constant change – not to mention external pressures such as changing legal or external third-party requirements. So, the team needs a cohesive plan for change management in order to quickly adjust applications and infrastructure without hindering security or reliability.
People typically think of change management in IT as initially being part of ITIL. But, many examples of change management in IT service management existed before ITIL was established. And now, with the growth of DevOps, change management processes are being implemented to ensure developers and IT professionals can easily manage system configurations, deploy new code quickly and fix incidents faster.
Change management plans can apply to any industry – but they’re particularly important to the DevOps and IT industry because these are the people maintaining the systems on which everyone works. There are numerous people and processes interacting with technical systems on a day-to-day basis – constantly shipping new code, adjusting network configurations, running automated tests and much, much more. So, defining a change management plan ahead of time can help your team with the identification and installation of required changes to servers, networks and other computer systems.
A change management plan allows your team to proactively identify required changes in applications and IT infrastructure and implement those changes. In a DevOps environment, developers and operations teams will collaborate closely, improve workflow visibility and automate much of the configuration, deployment and upkeep process – leading to rapid software delivery that doesn’t hinder reliability or security. Then, with an associated incident response plan, the team is also ready to respond to any problems that come up while making changes to your systems.
With that in mind, let’s dive into the next section where we lay out a template for a change management plan for DevOps teams:
The business teams and the greater engineering and IT organization need to know why a change is necessary. Are you continuously seeing disk usage spike around noon? Do you need to add additional servers at certain times of the day to make up for this? Then, how does this affect other integrated systems or teams? It’s important to show the benefits of a change outweigh any risks. The greater team needs to see how a change will increase scalability, reliability, security or speed. If the change improves any of those four qualities, then the team will see why a change should be implemented.
How many people will be needed to execute a change? How long will the change take? How much time and money is taken away from future development to address changes to your current configurations and systems? The scope of the change can dictate the importance of the project and where it should fall in the prioritization of all projects across IT and engineering.
As we touched on above, the change needs to show benefits in the form of improved scalability, reliability, security or speed. If the change will lead to improved productivity or happiness in the people on your development or IT team, then showcase these benefits. A change in IT applications or infrastructure can benefit people, processes, or technology – or all of the above. Try to show exactly how the team will benefit in the short-term and the long-term from each specific change.
Once the team has bought into the change, you need to determine the implementation schedule and any associated costs. Who’s needed when? How can the team go about executing the tasks needed to configure the system and implement a change? A well-defined schedule can help you facilitate the processes and tooling you need to efficiently implement the change.
Then, you need to define a communication plan. How should the team communicate before, during and after the change? How should you let customers or other external stakeholders know about downtime, performance issues or other potential ramifications? Do you warn external stakeholders ahead of time? The answer to many of these questions depends on the size of the change and the potential blast radius. But, it’s important to define best practices for communication beforehand so the team knows where to look for information and when/how to reach other teammates.
Do you have monitoring and alerting systems in place to quickly identify major issues during a change? Will you be able to quickly roll back a change in case of an error? Who gets notified when something goes wrong? A comprehensive monitoring and alerting strategy can help you feel better about making a change while you’re making the change. Knowing how you’ll collaborate with technical systems during a change is one of the most essential parts of change management. Define how you’ll detect incidents during a change, how the team will be alerted and how the team will respond to production issues in real-time.
Documenting any actions or communication that takes place during a change can help you analyze the change later. Did you start to realize the expected benefits? Report on what worked and what didn’t. What can you improve upon next time you make a change? Painting a cohesive picture with documentation and historical communication records can help you conduct post-incident reviews and improve your change management plan in the future.
Change management becomes easier and faster when teams are DevOps-minded. Through improved collaboration, transparency and automation – DevOps teams are able to make changes faster and more reliably. Combining the best parts of Agile practices and ITSM lead to software development and IT operations teams who work closely together. Then, the team will continuously improve on workflow transparency and automation throughout all aspects of engineering and IT.
Automated configuration management and automation of other tasks in IT operations can lead to a change management process that’s faster and more reliable. Then, if something does go wrong, the team has visibility into the problem, can fix the issue and will be able to quickly communicate with stakeholders. DevOps principles lead to an Agile change management plan – helping you spend time building new features and services instead of changing current IT applications and infrastructure.
See how DevOps and IT teams can bolster change management even more by crafting an incident management plan and leveraging a centralized solution for monitoring, alerting and collaboration. Download our free eBook, The Incident Management Buyer’s Guide, to learn more.