80 lines
2.9 KiB
Markdown
80 lines
2.9 KiB
Markdown
# Cloud-Change-Management-Process_686087713
|
|
## 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
|
|
|
|
|
|
|
|
## 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.
|