You can create relationships between changes and other types of tasks. For this, please complete the following steps:
Relationship Types
Type | Description |
---|---|
Incidents Resolved by this Change | The incidents specified will be resolved after resolving this change request. |
Incidents Caused by this Change | This change request is the cause of the incidents specified. |
The problems specified will be resolved after resolving this change request. | |
Problems Caused by this Change | This change request is the cause of the problems specified. |
Related Changes | This change request has related change requests. |
Related Request | This change request has related service requests. |
The relationship types Incidents Resolved by this Change and To use this feature, please complete the following steps (for the Incidents Resolved):
|
ченджи моэно создавать из проблемов - не похоже, возможно, в ITIL/SN и можно, но не у нас. Узнать у Игоря, как
емердженси из сендж контролов
ченджи из инцидентов? - не похоже, возможно, в ITIL/SN и можно, но не у нас. Узнать у Игоря, как
множественная горизонтальная связь без иерархии
стандартные чейнджи и как его создать
Change request implementing must be planned and scheduled carefully. It's very significant for the successful request implementing. Also, planning and scheduling allows to minimize vital business functions disruption.
When scheduling the change request implementing, it is notably to avoid time overlaps, to not affect multiple services or CI's at a time. It is a good practice to follow the rule: "One timeframe - one change request."
To schedule a change request, please complete the following steps:
To plan a change request, fill in the following fields in the Planning tab:
All these fields are mandatory.
CABs will be also mentioned here as well
автоматически переходит в шедулед
осветить механизм
апрувал тикеты
по разному формируются CABы в зависимости от риска и его вероятности (probability).
обязательно осветить
есть в документации на Яндекс.Диске
если все auth ticekts заапрувлены - все в scheduled, если зареджектили один - canceled все, если change из aurh в reg, то все тикеты падают в cancelled
Basing on the SimpleOne state model, when the change request has been fully processed (scheduled, implemented, and reviewed, it must be closed. When closing the incident, the agent must provide the closure code.
This code specifies an option of the closure. SimpleOne has the following options:
Option | Description |
---|---|
Implemented | This state displays that the change request was fully implemented. |
Partially Implemented | This state displays that the change request was implemented with some exclusions that do not affect the critical functionality of the service. |
Not Implemented | This state displays that the change request was not implemented. |
Cancelled | This state displays that the change request was cancelled because of authorization failed or cancelled by the caller. |
Backout | This state displays that the change request implementation was not successful, and the previous state of service (or CI) was restored. |
The priority of the Change Request can be figured out based on its impact and urgency using a priority matrix.
The impact of a change indicates the level of damage that will be caused to the business user. In SimpleOne, the impact can be categorized as:
The urgency of a change indicates the measure of time until a change has an impact on the business. In SimpleOne, the urgency can be categorized as:
Based on the priority, changes can be categorized as:
The priority matrix
Impact / Urgency | Very High | High | Medium | Low |
High | Critical | Critical | High | Moderate |
Medium | Critical | High | Moderate | Low |
Low | Critical | Moderate | Low | Low |
создаются из ченджей либо с нуля как темплейт, отдельный механизм авторизации, снять с Андрея. из темп только станд ченджи.