Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Difference between revisions of "EGI Change Management"

From EGIWiki
Jump to navigation Jump to search
(Mark the page as deprecated and moved to EGIPP confluence space)
 
(44 intermediate revisions by 5 users not shown)
Line 1: Line 1:
{{DeprecatedAndMovedTo|new_location=https://ims.egi.eu/display/EGIPP/EGI+Change+Management+CHM}}
= The EGI&nbsp;Change Management (CHM)&nbsp;Process Introduction<br> =
= The EGI&nbsp;Change Management (CHM)&nbsp;Process Introduction<br> =


This is the homepage on the EGI&nbsp;Wiki of the EGI&nbsp;Change Management Process.  Change management within the EGI’s production IT environment is extremely important in ensuring high-quality delivery of IT services.
This is the homepage on the EGI&nbsp;Wiki of the EGI&nbsp;Change Management Process.  Change management within the EGI’s production IT environment is extremely important in ensuring high-quality delivery of IT services.


The purpose of the IT Change Management Policy is to manage ''higher risk changes'' in a planned and predictable manner in order to assess risks, assign resources, and minimize any potential negative impact to services.  This is done by requiring change owners to prepare a Change Request document ([[File:Request+for+change+template.doc]]) where a set of standard questions regarding the change are answered and presented to the Change Advisory Board (CAB).   
The purpose of the IT Change Management Policy is to manage ''higher risk changes'' in a planned and predictable manner in order to assess risks, assign resources, and minimize any potential negative impact to services.  This is done by requiring change owners to prepare submit a [https://jira.egi.eu/projects/IMSCHM Jira ticket] including information about the change, which is then considered by the Change Advisory Board (CAB).   


The CAB meets to assess and approve changes and is coordinated on the '''egi-cab@mailman.egi.eu''' mailing list.  It consists of employees of the EGI Foundation including the Technical Director and members of the senior operations and management team.  Currently, the chair of the CAB is Matthew Viljoen.  Other members include: Tiziana Ferrari, Vincenzo Spinoso, Alessandro Paolini, Diego Scardacci, Peter Solagna and Gergely Sipos.  Others may be invited to join to provide additional expertise when discussing specific changes.  The decision to approve changes should be made unanimously by the CAB using input from experts, when present.  CAB meetings are tracked on Indico [https://indico.egi.eu/indico/event/3218/ here].
The CAB meets to assess and approve changes and is coordinated on the '''egi-cab@mailman.egi.eu''' mailing list.  It consists of employees of the EGI Foundation including the Technical Director and members of the senior operations and management team.  The CAB chair and members consists of employees of the EGI Federation.  Others may be invited to join to provide additional expertise when discussing specific changes.  The decision to approve changes is made unanimously by the CAB using input from experts, when present.  CAB meetings are now tracked on Indico [https://indico.egi.eu/indico/category/193/ here].


The basic process is as follows:
The basic process is as follows:
# For '''higher risk changes''' (score >4), the Change Owner (usually the Service Instance Owner - see below) submits a completed Change Request ([[File:Request+for+change+template.doc]]) to: '''change-mgmnt@rt.egi.eu'''.  Lower risk changes do not need to be recorded unless the Change Owner feels that there is benefit from doing so.
# For '''higher risk changes''' (score >4), the Change Owner (usually the Service Instance Owner - see below) opens a [https://jira.egi.eu/projects/IMSCHM Jira ticket].  Lower risk changes ''do not need to be recorded'' unless the Change Owner feels that there is benefit from doing so.
# The change risk of something going wrong (risk = likelihood X impact) should then be recorded by setting the Custom Fields on the RT ticket in preparation for the CAB review.  Further details about evaluating risk may be found [[: File:IMS-RMGuideline-060117-1020-4791.pdf|here]].
# The change risk of something going wrong (risk = likelihood X impact) should be recorded in the ticket in preparation for the CAB review.  Further details about evaluating risk may be found [[: File:IMS-RMGuideline-060117-1020-4791.pdf|here]].
# The Change Owner should request the [mailto:matthew.viljoen@egi.eu CAB Chair] to convene the CAB who reviews the change with the Change Owner present.  Once approved, this decision should be recorded on the ticket (along with the planned intervention date) and the change may proceed. '''Lower risk changes''' (score =<4) may be approved by the Change Owner and the ticket (if it exists) should be updated to this effect. 
# If the change is urgent, the Change Owner should send an email to [mailto:egi-cab@mailman.egi.eu EGI-CAB] to convene the CAB which reviews the change with the Change Owner present.  Once approved, this decision is recorded on the ticket (along with the planned intervention date) and the change may proceed.  
# After the change, the Change Owner should update the ticket with the intervention date, a comment about the outcome of the change.
# After the change, the Change Owner should update the ticket with the intervention date, a comment about the outcome of the change.
# The change is reviewed at the next CAB and the ticket closed, with the intervention date recorded, if different from the planned intervention date.
# The change is reviewed at the next CAB and the ticket closed, with the intervention date recorded, if different from the planned intervention date.


In addition, repeated changes of a similar type may be approved as a Standard Change by the CAB.  Subsequent changes do not then require explicit approval by the CAB; it is sufficient for the Service Instance Owner to submit a ticket to the "change-mgmnt@rt.egi.eu" recording the change is about to take place and confirming that it is a standard change.
In addition, repeated changes of a similar type may be approved as a Standard Change by the CAB.  Subsequent changes do not then require explicit approval (or review) by the CAB; it is sufficient for the Service Instance Owner to submit a [https://jira.egi.eu/projects/IMSCHM Jira ticket] to recording the change and confirming that it is a standard change.  After the change, the Service Instance Owner can then review the change by adding a comment to the ticket saying whether the change was successful and close the ticket.


Click [[:File:20170105-EGI-IMS_CHM-Process_Intro-Overview_v1.pdf|here]] for a more detailed presentation introducing the process.
Click [[:File:20170105-EGI-IMS_CHM-Process_Intro-Overview_v1.pdf|here]] for a more detailed presentation introducing the process.


== Services that fall under Change Control ==  
 
== Services that fall under EGI Change Control ==  
 
This is the list of services that are under the scope of EGI Change Control, along with the people responsible for them.


{| width="776" cellspacing="1" cellpadding="1" border="1" height="78"
{| width="776" cellspacing="1" cellpadding="1" border="1" height="78"
|-
|-
| '''Service Title<br>'''
| '''Service Title<br>'''
| '''Service Instance Owner'''<br>
| '''Service Supplier'''<br>
|-
|-
| EGI DataHub<br>
| DataHub<br>
| Lukasz Dutka, Bartosz Kryza<br>
| Lukasz Dutka, Bartosz Kryza<br>
|-
| Training Infrastructure<br>
| Gergely Sipos<br>
|-
| Collaboration Tools (Document Repository, Indico, Mailing lists, Mediawiki, RT, SSO)<br>
|Miroslav Ruda<br>
|-
|Notebooks<br>
|Enol Fernandez<br>
|}
== Previous services that fell under EGI Change Control but are now under EOSC-hub Change Control ==
Under the EOSC-hub project, a new Service Management System has been set up. Within it is Change Management covering the services within the EOSC Hub portfolio.  This include some services that were previously under EGI Change Management.  As such, changes to these services should no longer be submitted to the EGI Change Management, but instead should be submitted [https://jira.eosc-hub.eu/projects/EOSCCHM here].
{| width="776" cellspacing="1" cellpadding="1" border="1" height="78"
|-
| '''Service Title<br>'''
|-
|-
| EGI AppDB<br>
| EGI AppDB<br>
| Marios Chatziangelou<br>
|-
|-
| Operations Portal<br>
| Operations Portal<br>
| Cyril L'Orphelin<br>
|-
|-
| Service Monitoring - ARGO<br>
| Service Monitoring - ARGO<br>
| Kostas Koumantaros<br>
|-
|-
| Configuration Database - GOCDB<br>
| Configuration Database - GOCDB<br>
| George Ryall<br>
|-
|-
| Helpdesk - GGUS<br>
| Helpdesk - GGUS<br>
| Guenter Grein, Helmut Dres<br>
|-
|-
| Accounting - Accounting repository (Computing and Grid)<br>
| Accounting - Accounting repository (Computing and Grid)<br>
| Adrian Coveney<br>
|-
|-
| Accounting - Accounting Portal<br>
| Accounting - Accounting Portal<br>
| Iván Díaz Álvarez<br>
|-
|-
| Messaging<br>
| Messaging<br>
| Themis Zamani<br>
|-
| Training Infrastructure<br>
| Gergely Sipos<br>
|-
|-
|Check-in<br>
|Check-in<br>
|Nicolas Liampotis<br>
|}
|}


Line 65: Line 76:
{| width="776" cellspacing="1" cellpadding="1" border="1" height="78"
{| width="776" cellspacing="1" cellpadding="1" border="1" height="78"
|-
|-
| '''Service<br>'''
| '''Service'''
| '''Title<br>'''
| '''Title'''
| '''Description'''<br>
| '''Description'''
| '''RT&nbsp;Ticket Reference'''<br>
| '''RT Ticket Reference'''
|-
|-
| Helpdesk - GGUS<br>
| Helpdesk - GGUS
| Install patches on GGUS servers<br>
| Install patches on GGUS servers
| The installation of patches is required on all GGUS servers for keeping the system secure.<br>
| The installation of patches is required on all GGUS servers for keeping the system secure.
| [https://rt.egi.eu/rt/Ticket/Display.html?id=12262 RT#12262]<br>
| [https://rt.egi.eu/rt/Ticket/Display.html?id=12262 RT#12262]
|-
| DataHub
| Upgrade Onedata on the EGI DataHub
| Upgrade of the EGI DataHub Onezone.
| [https://rt.egi.eu/rt/Ticket/Display.html?id=12396 RT#12396]
|-
|-
| EGI DataHub<br>
| Collaboration Tools
| Upgrade Onedata on the EGI DataHub<br>
| Reboot of a VM following a regular OS update
| Upgrade of the EGI DataHub Onezone.<br>
| Rebooting Collaboration Tools VMs following regular OS updates.
| [https://rt.egi.eu/rt/Ticket/Display.html?id=12396 RT#12396]<br>
| [https://jira.egi.eu/browse/IMSCHM-28 JIRA#IMSCHM-28]
|}
|}


== Software Development changes ==
== Software Development changes ==


Most changes that fall under the scope of CHM will likely be to production service delivery (e.g. upgrades, major hardware changes etc). However, changes may also be in the form of software development to production services.  For example, if a user community requests new functionality from developers that requires 2 months of development effort, there may be a risk of insufficient funded effort, or reduced manpower elsewhere in the project.  This can especially be the case if such development is unforeseen at the beginning of a project.  In such cases, persons managing services are encouraged to bring such changes to the CAB for discussion, approval and (where appropriate) appropriation of development effort.
Most changes that fall under the scope of CHM will likely be to production service delivery (e.g. upgrades, major hardware changes etc). However, changes may also be in the form of software development to production services.  For example, if a user community requests new functionality from developers that requires 2 months of development effort, there may be a risk of insufficient funded effort, or a risk of reduced manpower elsewhere in the project.  This can especially be the case if such development is unforeseen at the beginning of a project.  In such cases, persons managing services are encouraged to bring such changes to the CAB for discussion, approval and (where appropriate) appropriation of development effort.


The workflow of such changes can be seen on this diagram, which additionally shows how the output of the Change Management process interacts with the Release and Deployment process.
The workflow of such changes can be seen on this diagram, which additionally shows how the output of the Change Management process interacts with the Release and Deployment process.
Line 91: Line 107:
== Federated Change Management ==  
== Federated Change Management ==  


The EGI Change Management is a centralized process for the EGI Federation.  If organisations are providing EGI branded services and are already running their own internal Change Management process, they may continue to do so if their process meets the minimum requirements of ISO20k.  If any changes are planned that have the potential to impact other EGI branded services, then the EGI Change Management process should be informed in advance by submission of a ticket to the RT queue linked above.
The EGI Change Management is a centralized process for the EGI Federation.  If organisations are providing EGI branded services and are already running their own internal Change Management process, they may continue to do so if their process meets the essential requirements of ISO20k with respect to change management:
* is there a systematic way of evaluating the risk for changes?
* is there a procedure within the organisation for approving high-risk changes
* are high-risk changes recorded (who implemented the change, when was it implemented and what was its outcome)?
In addition to the above, if any changes are planned that have the potential to impact other EGI branded services, then the EGI Change Management process should be informed in advance by submission of a ticket to the Jira queue linked above.
 
EGI should keep track of organizations running their own internal Change Management process and should periodically run a lightweight audit to ensure that the above requirements are being met.


== Full Procedure Documentation ==
== Full Procedure Documentation ==


Documentation of the complete CHM procedures and policy is available on the [https://confluence.egi.eu/ internal EGI Confluence].  Please note that these pages are only accessible to EGI Employees, so PDF snapshots of these pages are additionally available here:<br>
Documentation of the complete CHM procedures and policy is available on the [https://confluence.egi.eu/ internal EGI Confluence].  Please note that these pages are only accessible to EGI Employees, so PDF snapshots of these pages are additionally available here:<br>
[[:File:IMS_CHM_Process_Definition_Goals_Requirements_Roles_Definitions-1084081-290617-1640-37.pdf|Change Management Process Definition, including Goals, Requirements, Roles and Definitions]]<br/>
[[:File:IMS-ChangeManagementCHM-021219-1306-5013.pdf|Change Management Process Definition, including Goals, Requirements, Roles and Definitions]]<br/>
[[:File:IMS_CHM_Changemanagementpolicy-290617-1642-41.pdf|Change Management Policy]]<br/>
[[:File:IMS-Changemanagementpolicy-021219-1307-5015.pdf|Change Management Policy]]<br/>
[[:File:IMS_CHM_1_Managechangesincludingemergencychanges-290617-1641-39.pdf|CHM1 - Manage changes including emergency changes]]<br/>
[[:File:IMS-CHM1Managechangesincludingemergencychanges-021219-1255-5007.pdf|CHM1 - Manage changes including emergency changes]]<br/>
[[:File:IMS_CHM_2_Maintainthelist,descriptionsandstep-by-stepworkflowsforwell-knownandrecurringchanges-290617-1637-35.pdf|CHM2 - Maintain the list, descriptions and step-by-step workflows for well-known and recurring changes]]<br/>
[[:File:IMS-CHM2Maintainthelist%2Cdescriptionsandstep-by-stepworkflowsforwell-knownandrecurringchanges-021219-1256-5009.pdf|CHM2 - Maintain the list, descriptions and step-by-step workflows for well-known and recurring changes]]<br/>
[[:File:IMS-CHM3ManagementofFederatedChangeManagement-021219-1256-5011.pdf|CHM3 - Federated Change Management]]
<br/>


== Contact ==
== Contact ==


If you have any questions relating to EGI Change Management, please contact Matthew Viljoen (matthew.viljoen AT egi.eu).
If you have any questions relating to EGI Change Management, please contact Matthew Viljoen (matthew.viljoen AT egi.eu).

Latest revision as of 09:19, 22 October 2020

Alert.png This article is Deprecated and has been moved to https://ims.egi.eu/display/EGIPP/EGI+Change+Management+CHM.



The EGI Change Management (CHM) Process Introduction

This is the homepage on the EGI Wiki of the EGI Change Management Process. Change management within the EGI’s production IT environment is extremely important in ensuring high-quality delivery of IT services.

The purpose of the IT Change Management Policy is to manage higher risk changes in a planned and predictable manner in order to assess risks, assign resources, and minimize any potential negative impact to services. This is done by requiring change owners to prepare submit a Jira ticket including information about the change, which is then considered by the Change Advisory Board (CAB).

The CAB meets to assess and approve changes and is coordinated on the egi-cab@mailman.egi.eu mailing list. It consists of employees of the EGI Foundation including the Technical Director and members of the senior operations and management team. The CAB chair and members consists of employees of the EGI Federation. Others may be invited to join to provide additional expertise when discussing specific changes. The decision to approve changes is made unanimously by the CAB using input from experts, when present. CAB meetings are now tracked on Indico here.

The basic process is as follows:

  1. For higher risk changes (score >4), the Change Owner (usually the Service Instance Owner - see below) opens a Jira ticket. Lower risk changes do not need to be recorded unless the Change Owner feels that there is benefit from doing so.
  2. The change risk of something going wrong (risk = likelihood X impact) should be recorded in the ticket in preparation for the CAB review. Further details about evaluating risk may be found here.
  3. If the change is urgent, the Change Owner should send an email to EGI-CAB to convene the CAB which reviews the change with the Change Owner present. Once approved, this decision is recorded on the ticket (along with the planned intervention date) and the change may proceed.
  4. After the change, the Change Owner should update the ticket with the intervention date, a comment about the outcome of the change.
  5. The change is reviewed at the next CAB and the ticket closed, with the intervention date recorded, if different from the planned intervention date.

In addition, repeated changes of a similar type may be approved as a Standard Change by the CAB. Subsequent changes do not then require explicit approval (or review) by the CAB; it is sufficient for the Service Instance Owner to submit a Jira ticket to recording the change and confirming that it is a standard change. After the change, the Service Instance Owner can then review the change by adding a comment to the ticket saying whether the change was successful and close the ticket.

Click here for a more detailed presentation introducing the process.


Services that fall under EGI Change Control

This is the list of services that are under the scope of EGI Change Control, along with the people responsible for them.

Service Title
Service Supplier
DataHub
Lukasz Dutka, Bartosz Kryza
Training Infrastructure
Gergely Sipos
Collaboration Tools (Document Repository, Indico, Mailing lists, Mediawiki, RT, SSO)
Miroslav Ruda
Notebooks
Enol Fernandez

Previous services that fell under EGI Change Control but are now under EOSC-hub Change Control

Under the EOSC-hub project, a new Service Management System has been set up. Within it is Change Management covering the services within the EOSC Hub portfolio. This include some services that were previously under EGI Change Management. As such, changes to these services should no longer be submitted to the EGI Change Management, but instead should be submitted here.

Service Title
EGI AppDB
Operations Portal
Service Monitoring - ARGO
Configuration Database - GOCDB
Helpdesk - GGUS
Accounting - Accounting repository (Computing and Grid)
Accounting - Accounting Portal
Messaging
Check-in

Standard Changes

This is the list of standard, or pre-approved changes, listed by Service. The RT link references the original change that was approved by the CAB.

Service Title Description RT Ticket Reference
Helpdesk - GGUS Install patches on GGUS servers The installation of patches is required on all GGUS servers for keeping the system secure. RT#12262
DataHub Upgrade Onedata on the EGI DataHub Upgrade of the EGI DataHub Onezone. RT#12396
Collaboration Tools Reboot of a VM following a regular OS update Rebooting Collaboration Tools VMs following regular OS updates. JIRA#IMSCHM-28

Software Development changes

Most changes that fall under the scope of CHM will likely be to production service delivery (e.g. upgrades, major hardware changes etc). However, changes may also be in the form of software development to production services. For example, if a user community requests new functionality from developers that requires 2 months of development effort, there may be a risk of insufficient funded effort, or a risk of reduced manpower elsewhere in the project. This can especially be the case if such development is unforeseen at the beginning of a project. In such cases, persons managing services are encouraged to bring such changes to the CAB for discussion, approval and (where appropriate) appropriation of development effort.

The workflow of such changes can be seen on this diagram, which additionally shows how the output of the Change Management process interacts with the Release and Deployment process.

CHM-RDM

Federated Change Management

The EGI Change Management is a centralized process for the EGI Federation. If organisations are providing EGI branded services and are already running their own internal Change Management process, they may continue to do so if their process meets the essential requirements of ISO20k with respect to change management:

  • is there a systematic way of evaluating the risk for changes?
  • is there a procedure within the organisation for approving high-risk changes
  • are high-risk changes recorded (who implemented the change, when was it implemented and what was its outcome)?

In addition to the above, if any changes are planned that have the potential to impact other EGI branded services, then the EGI Change Management process should be informed in advance by submission of a ticket to the Jira queue linked above.

EGI should keep track of organizations running their own internal Change Management process and should periodically run a lightweight audit to ensure that the above requirements are being met.

Full Procedure Documentation

Documentation of the complete CHM procedures and policy is available on the internal EGI Confluence. Please note that these pages are only accessible to EGI Employees, so PDF snapshots of these pages are additionally available here:
Change Management Process Definition, including Goals, Requirements, Roles and Definitions
Change Management Policy
CHM1 - Manage changes including emergency changes
CHM2 - Maintain the list, descriptions and step-by-step workflows for well-known and recurring changes
CHM3 - Federated Change Management

Contact

If you have any questions relating to EGI Change Management, please contact Matthew Viljoen (matthew.viljoen AT egi.eu).