Change Management

A change is any modification to IT infrastructure that could impact services.

Change management goal

According to ITIL:

• Ensure changes are evaluated, authorized and documented
• Minimize service disruption risks
• Enable continuous improvement

Change examples

• Application version upgrade
• Server configuration modification
• New service deployment
• Network architecture change
• Security patch installation

Why manage changes?

• Risk control: Evaluate impact before implementing
• Traceability: Know what was changed, when, why
• Coordination: Avoid conflicting changes
• Learning: Analyze successes and failures

Three change types

Standard changes

Characteristics:

• Low risk, well-understood
• Pre-approved by CAB
• Documented procedure exists
• Examples: password reset, workstation deployment

Normal changes

Characteristics:

• Require risk assessment
• Full CAB evaluation
• Scheduled maintenance window
• Examples: application upgrade, infrastructure change

Emergency changes

Characteristics:

• Address critical incidents
• Fast-track approval (limited CAB)
• Full documentation after implementation
• Examples: security patches, critical fixes

Available statuses

Standard workflow

DRAFT → SUBMITTED → PENDING_APPROVAL → APPROVED → SCHEDULED → 
  IMPLEMENTING → COMPLETED → CLOSED
                       ↓
                    FAILED → ROLLED_BACK → CLOSED

The Change Advisory Board (CAB) evaluates and approves changes.

CAB role

• Review risk assessments
• Evaluate implementation plans
• Approve, reject, or request more information
• Schedule maintenance windows

CAB evaluation

For each change, CAB considers:

• Risk: What could go wrong?
• Impact: Who/what is affected?
• Timing: Is the window appropriate?
• Resources: Do we have the right people?
• Rollback: Can we revert if needed?

CAB decision

In KaliaOps:

1. CAB member opens the change
2. Reviews all documentation
3. Clicks "Approve" or "Reject"
4. Adds decision notes

The decision is traced in the change history.

Emergency CAB

For emergency changes:

• Reduced CAB membership
• Faster turnaround
• Post-implementation documentation required

Maintenance windows

A maintenance window is the scheduled time for implementing the change.

Scheduling

Define:

• Start date/time: When implementation begins
• End date/time: When it should complete
• Duration: Estimated implementation time

Window considerations

• Business impact: Choose low-activity periods
• User notification: Allow time for communication
• Resource availability: Ensure implementers are available
• Conflict check: Avoid overlapping changes

Calendar view

KaliaOps provides a calendar view showing:

• All scheduled changes
• Potential conflicts
• Resource allocation

Implementation plan

Document step-by-step:

1. Pre-implementation checks
2. Backup procedures
3. Implementation steps
4. Verification steps
5. Post-implementation checks

Test plan

Define how to validate:

• Service functionality
• Performance criteria
• User acceptance

Rollback plan

For risky changes, document how to revert:

• Triggers: When to initiate rollback
• Steps: How to revert
• Duration: How long rollback takes
• Validation: How to confirm rollback success

Rollback requirement

For high-risk changes:

• Rollback plan is mandatory
• Change cannot be approved without it
• Plan must be tested if possible

Starting implementation

1. Open the approved change
2. Click "Start Implementation"
3. Status changes to "Implementing"
4. Follow the implementation plan

During implementation

Document:

• Actions performed
• Issues encountered
• Deviations from plan

Completing the change

If successful:

1. Click "Complete"
2. Document results
3. Status changes to "Completed"

If unsuccessful:

1. Execute rollback plan
2. Click "Failed" or "Rolled Back"
3. Document what happened

Closure

After completion:

1. Review outcomes
2. Update documentation
3. Close the change

When changes fail

A change fails when:

• Implementation cannot complete
• Service is not restored as expected
• Unacceptable side effects occur

Failure handling

1. Execute rollback plan
2. Restore service
3. Mark change as "Failed" or "Rolled Back"
4. Document what went wrong

Post-failure analysis

Conduct a review:

• What caused the failure?
• Was the risk assessment accurate?
• Was the rollback plan adequate?
• What can we improve?

Learning

Use failures to improve:

• Update procedures
• Enhance testing
• Improve risk assessment
• Share lessons learned

KaliaOps automatically correlates incidents with recent changes.

How it works

When an incident is created:

• KaliaOps identifies changes in the last 24-48 hours
• Shared assets/applications are detected
• Potential correlations are suggested

Correlation indicators

• Time proximity: Incident shortly after change
• Shared assets: Same equipment involved
• Shared applications: Same services affected

Using correlations

When an incident may be change-related:

1. Review the correlated change
2. Check if it could cause the symptoms
3. Consider rollback if confirmed
4. Link incident to change for tracking

Change Success Rate

KaliaOps calculates:

CSR = (Successful Changes / Total Changes) × 100%

Industry target: > 95%