Handle configuration changes effectively


[PDF]Handle configuration changes effectively - Rackcdn.comhttps://b6b45000d3362c7b69f8-0a7250d8bde19e2e09b93fa07c907bb0.ssl.cf5.rackc...

38 downloads 166 Views 925KB Size

Technical white paper

Handle configuration changes effectively HP Universal CMDB Configuration Manager and HP Service Manager

Table of contents Problem Statement Overview What should you expect from your configuration management system?

2 2

Provided solutions Overview The legacy solution: attribute modeling change control The new solution: policy-based change control Method for policy-based change control

3 3

Conclusion

2

3 3 4 15

Problem Statement Overview Configuration Management is the ITIL v3 process responsible for an organization's single source of information for IT that supports the business. Configuration Management ensures that there is a complete and accurate picture of the IT infrastructure and software, thus improving the quality of most ITIL processes and better facilitating business decision making. A healthy Configuration Management process helps you address immediate pain points within your organization:

• • • • •

Operational issues, such as a lack of stability, resulting in a low quality of service Long resolution time for issues, resulting in dissatisfaction Large numbers of configuration changes (planned and unplanned) Lack of integration of management information from different tools, resulting in poor risk and impact management No insight into dependencies (service to app, app to app, or app to infrastructure), resulting in poor business/IT alignment

What should you expect from your configuration management system? Single source of truth The goal is to provide IT configuration information, including relationships, from service to infrastructure (depth), for all services, applications, and the entire infrastructure (breadth). This accurate information is available for consumption by other IT products or ITIL processes, whether HP’s third party, or homegrown. Those should in turn all use rationalized and coherent data. Note: This does not mean that all the data physically resides at a single place, but that there is a single place from which to retrieve information that may reside elsewhere (federated configuration management database [CMDB]), along with a process to maintain accurate, complete, and up-to-date data quality.

Single place for service models Configuration Management (CMDB/configuration management system [CMS]) must include all configuration information that is related to services, such as configuration items (CIs) and relationships. This should be the single place to model services to provide a service context that can be used by other processes (such as change management and incident management):

• • • • • •

Infrastructure components Applications Service models Mappings from components through services Enrichment of CIs with data from other sources or repositories Configuration Management must also answer key questions such as: – How many different configurations am I supporting? How standardized is my environment? (using Configuration Manager’s Advanced Configuration Analysis) – Which business services do I have? – Which applications support these business services? – What is the supporting infrastructure?

High data quality The data that is provided by the CMS should be of high quality in terms of coverage, completeness, accuracy, and timeliness. This is important for any consuming process, to ensure that those processes receive sufficient information. For example, when handling a service performance incident that is caused by an underlying malfunctioning server, you must know who the owner of that server is and where it is located, to involve the correct people in the remediation activity; such information should be maintained within and provided by the CMS.

2

Automatic Discovery Manually maintaining data in the CMS is difficult and costly if the organization is to keep its CMS up to date with the latest changes occurring in a highly volatile environment. Data entry and maintenance should be as automatic as possible (using Discovery). This also allows for verification of changes, making sure that all changes in the environment originated from requests for changes (RFCs) and were expected. Scalable support for rapidly changing environments With the adoption of further virtualization and automation technologies, environments become much more volatile. Execution of an automated activity might change thousands of servers in a few hours (for example, during patch deployment). The CMS should allow configuration owners to cope with such environments in a scalable and useable way. Detection of unplanned changes Manually modeling RFCs to the detailed attribute level is tedious and time consuming. The CMS should increase the ability to detect and manage unplanned or undesired changes, and reduce the need for detailed modeling of changes.

Provided solutions Overview With the evolution from ITIL v2 to ITIL v3, focus has moved from the CMDB to the CMS. In this context, Universal configuration management database is the authoritative source of CIs in the CMS, and the central hub to which data is federated from other managed data repositories. The HP solution places HP Universal CMDB Configuration Manager as the configuration management application for the CMS. HP Service Manager (SM), being IT Service Management (ITSM) product from HP, consumes the CI data from the CMS, benefitting from its rich and high-quality data.

The legacy solution: attribute modeling change control The UCMDB-SM integration solution has been offered since SM version 7.10, and allows the SM change user to model the planned changes all the way down to the specific attribute values that are going to be changed and verified by Discovery, to perform automated change verification and unplanned change detection (closed-loop change). This option provides the most control but requires manual attribute data entry and can generate many unplanned changes to be reviewed and accepted or backed out. Note: This option does not include HP Universal CMDB Configuration Manager and is out of scope for this document.

The new solution: policy-based change control Some customers have found that the first option, legacy solution, (change planning) at the attribute detail level is not necessary for their organization. Using Configuration Manager for state management is the recommended solution for these customers. Leveraging the extensive configuration policy capabilities can significantly reduce the effort of controlling detected changes. In this solution, the authorized state is supported as part of the CMS, and the control over promotion of data from the actual state to the authorized state is done through Configuration Manager. New control capabilities allow the customer to separate control of different environments (views) and CIs to different users, enabling each to choose whether control should be very tight and done manually, or whether to set up policies and rules that involve the user only in exceptional cases (if at all). In this manner, the authorized state within the CMS provides a more holistic and flexible approach that is better suited to the demands of the fast-changing, virtualized, and automated new world. As the state of a configuration item is now fully managed by the CMS (including actual, authorized, and historical states), this means that the SM Discovery Event Manager processing—in which SM must analyze each CI attribute change (as shown in the preceding legacy solution)—is not used. The CMS provides review and validation capabilities for configuration changes (through standards, policies, and SM RFC matching), providing the means for a closed loop change and configuration process.

3

Method for policy-based change control General

• The adoption of the policy-based change control methodology can be broken into two options, which are targeted for different customers – Option 1: CIs’ actual state is pushed to SM – Option 2: CIs’ authorized state is pushed to SM

• Authorization rules can be applied throughout the process or sparingly, depending on the level of control desired for the environment, or types of CIs or services.

• Data entry and data maintenance: – Manually entered data that should be consumed throughout the IT system (for example, CI owner, CI location, and business service criticality) should be maintained in UCMDB. – Attributes that are related only to SM are maintained in SM (such as incident assignment group). – Nondiscoverable data that are maintained in Managed Data Repositories (or other external sources) should be synchronized or federated into UCMDB. – Actual state is displayed in SM on the CI form under the CI actual state pane.

• Controlling configuration changes from actual to authorized state is provided by HP Universal CMDB Configuration Manager (CM). It is not necessary to go through the SM Change Management process to promote data from one state to another.

• RFC information from SM for changes that have been implemented is used to decide whether a configuration change is desired or not.

• When a detected configuration change is found to be related to an RFC, CM adds activity log entries to the corresponding RFC.

• Discovered unplanned configuration changes are no longer logged as unplanned change requests in SM. HP differentiates between configuration changes (Configuration Management process responsibility) and change requests (Change Management process responsibility). When CM determines that an unplanned configuration change is undesired, an RFC is submitted in SM for remediation. Details Adopting the policy-based change-control methodology Option 1—CM as a change review point This stage is about recording all the configuration changes and providing a way to review those changes and correlate them with RFCs, to gain an understanding over all configuration changes that are occurring in the environment. In this stage, CM configuration authorization capabilities are used to mark a configuration change as reviewed. SM continues to consume the actual state configuration, regardless of whether it has been reviewed (authorized) in CM or not. How to get started: 1. 2. 3. 4.

5. 6.

4

Enable UCMDB-SM adapter to push the actual state (as before), for data population and RFC federation. Connect CM with SM to enable RFC submission and updating from CM. Select environments (views) in CM for which you want to monitor configuration changes—gradually add more based on priority. Initialize the authorized state—the newly added views appear in the actual state. Gradually by priority, authorize these views (manually or automatically using authorization rules) so the authorized state will be populated to start reviewing configuration changes. Enable out-of-the-box CM change reports and notifications for these views. Start reviewing changes: a) Investigate configuration changes and drive remediation as needed, such as opening an RFC in SM to begin the change management process. b) Validate RFC-detected change correlations. c) Authorize changes (mark changes as reviewed).

7.

Configure automatic authorization rules to reduce review effort: a) Changes with RFCs b) Changes that do not breach any policies c) Changes in non-critical areas

Option 2—CM as a change control point In this stage, CM configuration authorization capabilities are used to control configuration changes by authorizing, remediating, or rolling back a configuration change. Only configuration changes that have been authorized should be consumed by SM, meaning that the CIs in their authorized state are pushed to SM. The CI’s actual state is available using the actual state tab. How to get started: 1. 2. 3. 4. 5. 6. 7.

Create UCMDB views for the entire synced scope. Enable the UCMDB-SM adapter to push authorized state. Connect CM with SM to enable RFC submission and updating from CM. Turn on full automatic authorization. Select environments (views) in CM for which you want to monitor configuration changes—gradually add more based on priority. Enable out-of-the-box CM change reports and notifications for these views and start reviewing Changes. Put brakes on automatic authorization: a) Changes without any RFCs b) Changes with policy—gradually (no need to put policies on everything) c) Break for critical areas—only manual approvals

Data entry and data maintenance

• Discoverable attributes should not be manually maintained but always populated through Discovery (HP Universal Discovery or any other trusted Discovery source).

• Nondiscoverable core CI attributes and attributes related to Configuration Management (such as a CI’s location, owner, and service) should be maintained within UCMDB. A user can choose one of these methods: – Update the CI’s information using the IT Universe Manager or the UCMDB Browser – Update the CI’s relationship to a service, application, and so on using the Modeling Studio – Bulk update a set of CIs (from an external data source, such as Excel)

• Nondiscoverable CI attributes that do not exist in the CMS and are private to SM should be maintained within SM. • Actual state data is still consumed by SM, as before, using federation. An SM user can still access the actual state of the UCMDB through the CI actual state tab. The difference between the two options is in the data that is being pushed to SM—actual state in the first and authorized state in the second. Promotion from actual to authorized state is done through Configuration Manager

• The Configuration Manager administrator registers Configuration Manager to the relevant UCMDB Foundation views that encompass the data that should be managed.

• The different views, capturing either different applications/services or CI inventories, are then associated with their

owning users, and those users are given the correct permissions. For example, the group that owns Windows® servers is given the permissions to manage states for its Windows servers.

• Each owner can decide on a data promotion strategy: – Tight control: manually promote every configuration change that is observed within the actual state of the CIs. In option 1, this means that every detected change is reviewed in CM but in parallel is pushed to SM. In option 2, this means that SM is not updated with new configuration changes until those changes are reviewed and authorized in CM. – No control: any changes in the actual state are automatically promoted to the authorized state. Because in this case the actual and authorized states of a CI are kept identical (regardless of the maturity stage), SM immediately becomes aware of any updates.

5

– Rule-based control: set up rules that determine which changes should be automatically promoted to the authorized state, and which changes call for the owner’s intervention. For example, the addition of new servers is automatically promoted to the authorized state, but only when the servers’ owning group and location is captured within the CMS (thus controlling the quality of data that is available for SM and other consumers). RFC information from SM is utilized when deciding whether a configuration change is desired

• Upon logging in to CM State Transition module, the CI owner can view the current discrepancies between the actual and authorized states. The CI owner can view exactly what changed in the CI, whether the change caused any configuration policy breach, and which RFCs are associated with that CI.

• CM suggests RFCs for a particular CI change according to the following logic: – The CI or the CI container is marked as affected by the RFC in SM. – The RFC is in one of the following states: approved/implemented/closed. – The RFC is either planned to be implemented or was actually implemented between the time that the CI configuration change was detected and the time it was last authorized.

• The administrator can change the out-of-the-box configuration of the relevant RFC phases for the RFC retrieval as well as set up additional filters.

• The automatic authorization process can take RFC information into consideration as one of the supported authorization rules. When a detected configuration change is found to be related to an RFC, CM adds activity log entries to the corresponding RFC. For every configuration change that is found to be related to an RFC, CM adds an entry in the RFC activity log as part of the authorization action. CM keeps a link between the authorized change and the RFC for auditing purposes, thereby enabling a report that shows all authorized configuration changes with their relevant RFCs. Unplanned changes are managed and audited in CM and undesired changes can be remediated with a new RFC

• As the state of a configuration item is now fully managed by the CMS (in the State Management module of CM), this means that the current control of states through the closed-loop change process within SM is not used.

• Unplanned configuration changes are detected and managed in CM. A desired unplanned change is handled and promoted to the authorized state without opening an unplanned change ticket in SM.

• When an undesired unplanned change is found, an RFC can be submitted from CM to SM in order to revert to the previous configuration. (Note that in this case as well, the submitted RFC is not an unplanned change ticket).

• CM keeps an audit of all the configuration changes on a CI, and can provide reports on authorized changes, planned and unplanned, for a specific CI. SM still holds the change request information.

6

Option 1 examples Example 1—Automatically controlling a planned change 1. 2. 3. 4. 5.

An RFC is opened in SM to add memory to Host 1 (totaling 8 GB). The RFC is approved and implemented. Universal Discovery runs and detects that Host 1 now has 8 GB of memory. The authorized state of Host 1 is still set to 4 GB. SM updates the host memory attribute in its own data repository to 8 GB. CM captures the change of the host memory from 4 GB to 8 GB. a) CM validates that there is no configuration policy breach as a result of this new state of the CI. b) CM checks whether a corresponding RFC exists for this configuration change.

6.

All rules are met, and CM automatically marks this change as reviewed (authorizes it). a) CM adds an entry to the RFC activity log indicating the new configuration that has been captured and reviewed.

7.

The RFC is closed in SM.

7

Example 2—Manually controlling a planned change 1. 2. 3. 4. 5.

An RFC is opened in SM to add memory to Host 1 (totaling 8 GB). The RFC is approved and implemented. Universal Discovery runs and detects that Host 1 now has 8 GB of memory. The authorized state of Host 1 is still set to 4 GB. SM updates the host memory attribute in its own data repository to 8 GB. The owner of Host 1 logs into CM and is notified of new discrepancies. The owner drills down into the details to see that Host 1’s memory was changed from 4 GB to 8 GB. a) The owner is presented with the information of whether or not there are any policy breaches. b) The owner sees potential RFCs that are associated with this change, and can correlate the appropriate one to the change.

6.

The owner marks this change as reviewed (authorizes it) and provides editable comments for the authorization. a) CM adds an entry to the RFC activity log indicating the new configuration that has been captured and reviewed.

7.

The RFC is closed in SM.

8

Example 3—Managing an unplanned change 1. 2. 3.

4. 5.

Universal Discovery runs and detects that Host 1 now has 8 GB of memory. The authorized state of Host 1 is still set to 4 GB. SM updates the host memory attribute in its own data repository to 8 GB. CM captures the change of the host memory from 4 GB to 8 GB. a) CM validates that there is no configuration policy breach as a result of this new state of the CI. b) CM checks whether a corresponding RFC exists for this configuration change. In this case, there is no RFC. RFC existence was not a defined authorization rule in this case, and if all other authorization rules are met, CM automatically marks this change as reviewed (authorizes the change). Manual action is supported as well. The unplanned change (among other changes) is audited in CM. Reporting on reviewed (authorized) unplanned changes can be done in CM.

9

Example 4—Rolling back an unplanned change 1. 2. 3.

4.

Universal Discovery runs and detects that Host 1 now has 8 GB of memory. The authorized state of Host 1 is still set to 4 GB. SM updates the host memory attribute in its own data repository to 8 GB. CM captures the change of the host memory from 4 GB to 8 GB. a) In this case, a policy breach is identified by CM. b) CM checks whether a corresponding RFC exists for this configuration change. In this case, there is no RFC. As there is no RFC for this change and the configuration change caused a policy breach, the owner of Host 1 marks the change as reviewed in CM (authorizes it) and submits an RFC from CM for rolling back to the previous configuration (a policy breach is just one example for rolling back a configuration change).

Note: Since the authorized state is used as a reviewed state, even if a configuration change is found to be undesired, the user marks it as reviewed (authorized) once a proper remediation action is taken (for example, an RFC is submitted to roll back the change).

5.

10

The rollback RFC is considered a planned change, so the use case continues with example 1 or example 2 (for controlling a planned change).

Option 2 examples Example 1—Automatically controlling a planned change 1. 2. 3. 4. 5.

An RFC is opened in SM to add memory to Host 1 (totaling 8 GB). The RFC is approved and implemented. Universal Discovery runs and detects that Host 1 now has 8 GB of memory. The authorized state of Host 1 is still set to 4 GB. The SM user can see the CI’s new actual state in the Actual State tab in SM (which displays the information from the CMS). CM captures the change of the host memory from 4 GB to 8 GB. a) Configuration Manager validates that there is no configuration policy breach as a result of this new state of the CI. b) Configuration Manager checks whether a corresponding RFC exists for this configuration change.

6.

All rules are met, and CM automatically authorizes this change (the authorization is audited within Configuration Manager). a) CM adds an entry to the RFC activity log indicating the new configuration that has been captured and authorized.

7. 8.

UCMDB pushes the new authorized state of Host 1 to SM (only the delta is communicated). SM updates the host memory attribute in its own data repository to 8 GB, thereby providing its users and use cases the exact same data that resides in the CMS. The RFC is closed in SM.

9.

11

Example 2—Manually controlling a planned change 1. 2. 3. 4. 5.

An RFC is opened in SM to add memory to Host 1 (totaling 8 GB). The RFC is approved and implemented. Universal Discovery runs and detects that Host 1 now has 8 GB of memory. The authorized state of Host 1 is still set to 4 GB. The SM user can see the CI’s new actual state in the Actual State tab in SM (which displays the information from the CMS). The owner of Host 1 logs into CM and is notified of new discrepancies. The owner drills down into the details to see that Host 1’s memory was changed from 4 GB to 8 GB. a) The owner is presented with the information of whether or not there are any policy breaches. b) The owner sees potential RFCs that are associated with this change, and can correlate the appropriate RFC to the change.

6.

The owner authorizes this change (and can provide editable comments for the authorization). a) CM adds an entry to the RFC activity log indicating the new configuration that has been captured and authorized.

7. 8.

UCMDB pushes the new authorized state of Host 1 to SM (only the delta is communicated). SM updates the host memory attribute in its own data repository to 8 GB, thereby providing its users and use cases the same data that resides in the CMS. The RFC is closed in SM.

9.

12

Example 3—Managing an unplanned change 1. 2. 3.

4. 5. 6. 7.

Universal Discovery runs and detects that Host 1 now has 8 GB of memory. The authorized state of Host 1 is still set to 4 GB. The SM user can see the CI’s new actual state in the Actual State tab in SM (which displays the information from the CMS). CM captures the change of the host memory from 4 GB to 8 GB. a) CM validates that there is no configuration policy breach as a result of this new state of the CI. b) CM checks whether a corresponding RFC exists for this configuration change. In this case, there is no RFC. The existence of an RFC was not a defined authorization rule in this case, and if all other authorization rules are met, CM automatically authorizes this change (manual authorization is supported as well). The unplanned change (among other changes) is audited in CM. Reporting on authorized unplanned changes can be done in CM. UCMDB pushes the new authorized state of Host 1 to SM (only the delta is communicated). SM updates the host memory attribute in its own data repository to 8 GB, thereby providing its users and use cases the exact same data that resides in the CMS.

13

Example 4—Rolling back an unplanned change 1. 2. 3.

4.

5.

14

Universal Discovery runs and detects that Host 1 now has 8 GB of memory. The authorized state of Host 1 is still set to 4 GB. The SM user can see the CI’s new actual state in the Actual State tab in SM (which displays the information from the CMS). CM captures the change of the host memory from 4 GB to 8 GB. a) In this case, a policy breach is identified by CM. b) CM checks whether a corresponding RFC exists for this configuration change. In this case, there is no RFC. As there is no RFC for this change and the configuration change caused a policy breach, the owner of Host 1 decides to submit RFC from CM for rolling back to the previous configuration. (Note that a policy breach is just one example for rolling back a configuration change). The rollback RFC is considered a planned change, so the use case continues with example 1 or example 2, for controlling a planned change.

Conclusion With the tight integration of HP Universal CMDB Configuration Manager and HP Service Manager, you can take advantage of the ability to review and validate configuration changes (through configuration standards, policies, and SM RFC matching), thereby achieving a closed loop change and configuration process. This paper described two options for achieving this process:

• Option 1 where Configuration Manager is leveraged as a change review point • Option 2 where Configuration Manager is leveraged as a change control point Select the level of control appropriate to your organization and start achieving the benefits of improved configuration and change management processes.

Learn more Manage configuration changes more effectively with HP Universal CMDB Configuration Manager and HP Service Manager. Visit hp.com/go/cm and hp.com/go/itsm.

Get connected hp.com/go/getconnected Current HP driver, support, and security alerts delivered directly to your desktop

© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. Windows is a U.S. registered trademark of Microsoft Corporation. 4AA0-7486ENW, Created July 2012

15