83 lines
2.9 KiB
Markdown
83 lines
2.9 KiB
Markdown
# ITOM Cloud Service Delivery : Cloud Change Management Process
|
||
|
||
Created by Yun Zhao, last modified on Jan 23, 2025 EST
|
||
|
||
## Introduction
|
||
|
||
This document describes how to manage changes in an Opentext Cloud environment.
|
||
|
||
## Change Type
|
||
|
||
### Planned Change
|
||
|
||
Change is defined as anything - hardware, software, system components, services or processes that is deliberately introduced into the production environment and which may affect a service level agreement (SLA) or otherwise affect the functioning of the environment or one of its components.
|
||
|
||
|
||
Changes may be required for many reasons, including, but not limited to:
|
||
|
||
- User requests
|
||
- Vendor recommended/required changes
|
||
- Changes in regulations
|
||
- Hardware and/or software upgrades
|
||
- Hardware or software failures
|
||
- Changes or modifications to the infrastructure
|
||
- Unforeseen events
|
||
- Periodic Changes
|
||
|
||
All changes falling under this definition should be governed by a change management policy, and implemented by a change management methodology and change management process.
|
||
|
||
Planned Changes will be scheduled at least two (2) weeks in advance when Customer action is required, or at least four (4) days in advance otherwise.
|
||
|
||
### Emergency Changes
|
||
|
||
Critical change to prevent service functionality or availability.
|
||
|
||
Emergency Changes require approval of Cloud Delivery Manager, TO Manager or CS Manager.
|
||
|
||
Emergency Change will be scheduled at least one (1) day in advance unless it is critical to resolve a major incident immediately.
|
||
|
||
## Customer Notification
|
||
|
||
Opentext Cloud Service will use a centralized notification system to deliver proactive communications about service changes, outages, and scheduled maintenance.
|
||
Details can be found on the relevant Service Health portal for your service which includes:
|
||
|
||
- Current availability of the SMAX environment that their tenants are part of
|
||
- Details of any upcoming planned maintenance
|
||
- Outage reports for any incidents that have been identified by our support teams
|
||
- Historical SLO data
|
||
|
||
For example: [https://smax-health.saas.microfocus.com/](https://smax-health.saas.microfocus.com/)
|
||
|
||
## Change Approval
|
||
![[IMG-20260917124012726.png]]
|
||
|
||
|
||
## Change Record
|
||
|
||
For any changes, need to submit change record in the [Essentials](https://essentials.saas.microfocus.com/itg/dashboard/app/portal/PageView.jsp) system.
|
||
|
||
For details, please refer to document How to submit Change Record in Essentials System.
|
||
|
||
## CAB Review
|
||
|
||
### No CAB Required
|
||
|
||
Such change will not be discussed in the CAB meeting. List of changes that are mostly routine and were pre approved by an executive.
|
||
The likelihood of those changes to disrupt service is very slim and those changes are executed frequently.
|
||
e.g.:
|
||
|
||
- Monthly Patch Upgrade
|
||
- Routine EKS upgrade
|
||
- etc.
|
||
|
||
### CAB Required:
|
||
|
||
All non exempt changes, mostly changes that will occur during maintenance window, and involves more than one executer.
|
||
|
||
e.g.:
|
||
|
||
- Product major version upgrade
|
||
- AWS Infrastructure Change
|
||
- Landing zone migration
|
||
- etc.
|