Регламентное обслуживание перейти к списку

Исполнительная часть регламентного обслуживания: что фактически выполняется над оборудованием, ОС и сервисами и по какому расписанию. Декларативная часть — Требования по обслуживанию: работа “выполняет требования” (одноимённое поле), и именно это сопоставление позволяет находить объекты, у которых требования ничем не закрыты.

Схема на примере резервного копирования:

требование РК (GFS-сценарий) предъявлено сервису и унаследовано на ВМ;
работа соответствует реальному механизму — например, заданию Veeam в котором явно заявляется, что оно удовлетворяет эти требования;
включение ВМ в состав работы (поле “ОС/ВМ”) фиксирует, что требование ВМ закрыто.

Работа, выполняющая требование, автоматически удовлетворяет и все требования, которые оно перекрывает — рекурсивно по всей цепочке. Поэтому объекту с несколькими требованиями достаточно попасть в одну работу, закрывающую самое строгое из них.

Работы могут быть иерархичными («Входит в состав»): частные операции объединяются в общий регламент; расписание, сервис и выполняемые требования наследуются от родителя, если не заданы у потомка.

Каждая работа ведётся «В рамках сервиса» — отсюда определяются ответственный и команда поддержки этой регламентной операции.

Атрибуты

Атрибут	Описание
ID id
Ссылки links	С информацией по данному обслуживанию Каждая строка — одна ссылка: сначала описание, последнее слово — сам URL (без пробелов, вместо них %20). Пример: описание сервиса https://wiki.domain.local/services:inventory подробнее о типе: Ссылки (список URL) »
Архивирован archived	Помечается, если в работе этот объект более не используется, но для истории запись о нем лучше сохранить
Время изменения updated_at	Дата/время изменения объекта в БД Дата и время в формате ГГГГ-ММ-ДД ЧЧ:ММ; можно выбрать в календаре.
Редактор updated_by
Доп. связи external_links	JSON структура с дополнительными объектами и ссылками на внешние информационные системы. Хранятся в виде JSON структуры. При записи значений старые узлы структуры объединяются с новыми. Запись {"link1":"value1"} изменит во всем наборе ссылок только "link1", остальные останутся без изменений. Для удаления элемента из структуры надо записать для него пустое значение, например {"link1":""}. Запись пустой строки или пустого JSON {} не меняет никаких значений. Значение — структура в формате JSON, например {"key": "value"}. подробнее: Регламентное обслуживание → Доп. связи »
Дата изменения changed_at	Дата и время в формате ГГГГ-ММ-ДД ЧЧ:ММ; можно выбрать в календаре.
Название name	Понятное имя для регламентного обслуживания
Дочерние children	Дочерние операции регламентного обслуживания входящие в состав этого обслуживания
Дочерние (включая потомков) childrenRecursive	Все дочерние операции обслуживания, включая потомков потомков
ОС/ВМ comps_ids	Обслуживаемые в рамках этой регламентной операции
Описание description	Описание регламентных операций с пояснением деталей
Объекты objects
Входит в состав parent_id	Если это обслуживание является частью более общего регламента, то необходимо указать родительское регламентное обслуживание тут.
Выполняет требования reqs_ids	Какие требования по регламентному обслуживанию выполняет эта операция
Ответственный responsible	Кто отвечает за это регламентное обслуживание
Расписание schedules_id	Расписание когда производятся регламентные операции
В рамках сервиса services_id	В рамках какого сервиса/услуги производятся операции обслуживания. Нужно для определения ответственного и поддержки Если подходящего сервиса/услуги нет, то нужно завести
Сервисы services_ids	Обслуживаемые в рамках этой регламентной операции
Поддержка support	Команда поддержки регламентного обслуживания
Оборудование techs_ids	Обслуживаемое в рамках этой регламентной операции