Main activities of Configuration Management

There are 12 main configuration management activities:
I. Configuration Management Plan
Ii. Configuration ID
3. Determine the configuration management scope
Iv. Confirm and record configuration item attributes
5. Define identifiers for configuration items
6. Determine the configuration baseline
VII. Determine the Configuration Structure
8. Confirm configuration item naming rules
9. configuration item Control
10. configuration status report
11. Configuration Verification
12. CMDB backup, archiving and storage

The following details:
I. Configuration Management Plan:
The content should include:
1. Goals and scope of Configuration Management
2. policies, standards andProgram
3. configure management roles and responsibilities
4. configuration item naming rules
5. Schedule and implement configuration management activities
6. Interface Control with third parties (such as change management and suppliers)
7. configuration management system design, including CMDB, storage location of configuration management data, controlled environment for configuration item operation, contact and interface with other service management systems, and support tools such as building and Installation
8. Internal work of configuration management, including license control and configuration item Archiving
9. planned configuration baselines, major releases, milestones, and workload plans and resource plans for each future period

Ii. Configuration ID:
Determine the CI range, attributes, identifiers, baselines, configuration structures, and naming conventions.

3. Determine the configuration management scope:
Including hardware and software and related documentation for building, publishing, verification, installation, distribution, maintenance, recovery, and removal of Ci, is there a translation problem ?).
In my understanding, the scope of configuration management is: all CI management.
These CI include hardware, software, and related documents recognized as ci.
The management of these CI includes building, publishing, verification, installation, publishing, maintenance, deletion, recovery, and other operations.

Iv. Confirm and record CI attributes:
It generally includes the name, number, category, version number, owner, source, date provided, license number, current status, parent configuration item association, sub-configuration item association, accident number, problem number, change request number, change No. and remarks.

5. Define the identifier for the configuration item:
For hardware CI, physical tags or bar codes can be attached or engraved.
For software CI, a tag containing the CI name and version number can be created when the software is copied into the DSL (FINAL software library.
For document CI, you can add a valid date and an update date to the document name to identify it.

6. Determine the configuration baseline:
The configuration baseline describes the configuration items in the previous group at a specific time point.
Content to be included:
1. past, current, and planned release information
2. past, current, and planned changes
3. system status and related documents for approval and implementation of changes
4. system status and documentation during implementation and release
5. Hardware and Software configured in accordance with standard specifications

VII. Determine the configuration structure:
Determine the Configuration Structure of the IT infrastructure to identify and record the CI relationship.

8. Determine the CI naming rules:
Configuration Management should establish naming rules for all CI and control forms (such as rfcs. CI name continuity and easy-to-remember scalability should be considered in the Rules.

9. configuration item control:
Various activities that control CI changes after the formal establishment of configuration documents, including evaluation, coordination, approval or rejection of changes.
Ensure that only those approved and identifiable CI are recorded in the CMDB, and that the addition, modification, replacement, and deletion of the Ci are performed according to the appropriate control document.
Specific activities include:
1. register a new Ci and its version
2. Update Ci
3. License Management
4. Archive related records when revoking or deleting Ci
5. Protect the integrity of various Ci
6. Check the CI regularly to ensure the actual existence and compliance of the Ci, and update the CMDB.

10. configuration status report:
Regularly create configuration status reports for the current version and change history of all controlled CI.
Through the status report, the configuration management personnel can understand the status of the current Ci and the plan, and track the changes between the baseline and the released version.
Content:
1. Baseline and release identifier
2. The latest version of the software used to build the system or application
3. Number of System Changes
4. Number of baselines and released versions
5. CI usage and changes
6. Comparison results of the baseline and released versions

11. Configuration Verification:
The configuration management personnel review the CI and CMDB to ensure that the configuration information in the CMDB can reflect the existence and changes of the Ci in the IT infrastructure.
Timing of verification:
1. After the new CMDB is implemented
2. Before and after major changes to the IT infrastructure
3. Before a software release and installation is imported into the actual action environment
4. After the disaster recovery or after the accident recovers
5. After unauthorized Ci is found
6. When anything else is required (not said)

Tip: some common configuration verification operations can be completed by the audit software. However, even if any inconsistency is found, the audit software prohibits the automatic updating of CMDB, which must be investigated by the relevant team before being updated.

12. CMDB backup, archiving and storage:
To cope with disasters, we recommend that you back up the CMDB to a remote location.
The backup frequency and retention policy should be determined based on the size and changes of the IT infrastructure.

question:
How is the configuration baseline technically implemented? The Guide has not been further elaborated, but this is the key. Further research is required. Does it seem like the implementation principle of version management tools like CC? Do you know if HP has such practices?