Today's organizations need to quickly ship products and features to customers to keep up with the market, and this puts a huge stress on IT operations. As new applications and services are developed, the Operations team needs to have the infrastructure ready to deploy the necessary changes as they come in. As more and more development teams embrace Agile practices, changes can come at an alarming rate. The infrastructure must always be ready to deploy the changes coming down the pipeline. This requires the operations teams to be agile, sometimes even more so than the development teams.
The changes coming from development teams need to be supported by operations managing the day-to-day change that enables efficiency. Business applications and services consist of three inputs: the OS (provisioning management), the business configuration (configuration management), and the external configuration (patch management) which are updates from external sources such as OS distributions and vendors. Each of the three inputs have regular changes that need to be managed.
It's easy to think of each input of change as a single entity, separate from the others. For instance, we tend to think of patch management as an ongoing process separate from configuration management. However, the reality is patching software affects the applied configuration of a node. Changing the configuration can change what needs to be patched. Upgrading the OS can change the applied configuration. Having a change management process that allows operations teams to easily understand how the three inputs (provision, configuration, and patch) relate and affect one another, enables us to better manage all of the ongoing change within our infrastructure. Staying on top of the ongoing infrastructure change has the benefit of keeping our infrastructure ready for anything that comes down the pipeline, enabling agile operations.
I'm going to walk through the three inputs of provision management, configuration management, and patch management, and illustrate how they relate to each other at a high level. In later posts, we'll dive into the details of implementation.
In this post, change management refers to the operations process that collects incoming change from the three inputs, relates the changes to each other, and applies the changes together. This process can be fully automated or use a mixture of automation and manual review.
Provision Management
Provision management refers to the selection and installation of an operating system, as well as the ongoing management of a provisioning system. The first phase of creating any node is provisioning the OS. We tend to think of the OS as static, not as something having change we need to manage. We usually ascribe managing OS updates to the patch management process, including OS point releases to get us from, for example, Red Hat 6.1 to Red Hat 6.2.
The reality is the core operating system will inevitably have a major version release that should be treated as an item for change management. Upgrading the major release of an OS can have an effect on the configuration management. As new ways of managing the OS are introduced, the applied configuration may need to change to ensure the applications and services deployed won't be affected. Further, a new major OS version means new software updates to manage.
Configuration Management
Whether you use a configuration management tool like Puppet or do manual configuration, there will be changes to applied configuration that should be managed in a change management process. New applications will need to be deployed. Existing applications will need updates. Some of these new applications and updates won't need changes to the configuration of the underlying OS, but when they do, your change management process needs to be able to handle it efficiently.
When new packages are required to be installed on the OS to enable new applications and services, any updates to those packages will have to be managed by the patch management system.
Patch Management
Every operating system will have updates. Traditionally, we tend to think of software updates as being directly related to the nodes the updates are available on. However, when software updates are approved and applied, they aren't being approved for the nodes. They're being approved for the specific configuration of the node they're being applied on. Therefore, software updates should be tested, approved, and applied to configurations, not nodes. Any change management process should test, approve, and apply software updates alongside incoming changes to configuration management.
Conclusion
A change management process should take all three inputs that deliver business applications and services, and manage the flow of change from each input in a single process. If you are managing change from each piece in isolation, you're missing the relationship between the incoming changes. Understanding and testing the relationships between seemingly disparate changes is the best way to ensure the efficiency and reliability of your change management processes.
No comments:
Post a Comment