Автоматическое закрытие инцидентов SNOW путем запроса средства защиты данных!
Ситуация -
Механизм защиты данных запускает запланированные задания, и при сбое задания создается инцидент в обслуживании. Затем механизм защиты данных автоматически повторно запускает неудачное задание. Но даже если они будут успешными при следующих повторных запусках, инциденты не будут разрешены, и кто-то должен вручную войти и закрыть все инциденты. Это болезненно, потому что в средстве защиты данных параллельно выполняются сотни заданий. Кроме того, кто-то должен регулярно следить за инцидентами в Service Now.
К счастью, это можно автоматизировать, и эти инциденты можно закрывать автоматически по расписанию. Посмотрим, как мы можем это сделать.
Код - это не волшебство, а просто рукопожатие API двух разных сервисов в одну систему. На рисунке ниже представлена приблизительная архитектура работы системы. Автоматизируем.
Шаг 1. Войдите в систему сейчас
- Вход с аутентификацией по имени пользователя и паролю
- Передайте все необходимые вам состояния в функцию. См. Строку 20, где, например, я передаю только два состояния.
- Строка 8–16 запрашивает снег для каждого состояния и добавляется в snow_data.
Шаг 2. Войдите в систему защиты данных
- Войдите в DP, используя указанный формат, и используйте файл сертификата. См. Ниже информацию о сертификатах.
- Формат полезной нагрузки строки 6 является фиксированным, и это обязательные параметры.
- Строка 11 возвращает токен доступа.
Это с помощью сертификата. Больше информации о том, как это сгенерировать -
Шаг 3. Получите информацию об инциденте от Data Protector
- Для каждого инцидента запросите DP и проверьте запись с ошибкой.
- Строка 6,7 преобразует имя сеанса в соответствии с форматом имени предохранителя DP.
- Фильтр с использованием типа сеанса [0], то есть Резервное копирование, списка данных как спецификации и имени как session_name. Этот фильтр в идеале должен возвращать вам один ответ, потому что имя является уникальным идентификатором.
- Строки 25–28 извлекают информацию о типе резервной копии и время окончания из ответа.
Шаг 4. Проверьте статус успеха и закройте инцидент.
- Для каждого инцидента отфильтруйте DP и проверьте статус успеха, используя тип резервного копирования, спецификацию и время окончания.
- Строки 30–49 для типа резервной копии 0 не проходят фильтр backupType в полезной нагрузке. Вместо этого обработайте строку 47 ответа.
- Строки 51–70 обрабатывают резервный тип 10. Строка 57 передает резервный тип 10 с фильтром запроса.
- Если условия совпадают, то есть статус = 2 (успех), и когда время начала ответа больше, чем время окончания инцидента, то есть эта запись была создана позже, чем та, для которой инцидент был создан в SNOW, то закройте инцидент. .
- Используя обычную аутентификацию, обновите инцидент в SNOW. Строки 7–10 - это обязательные поля. Состояние может быть закрыто / разрешено по вашему выбору.
Здесь следует отметить одну вещь: API фильтра DP не принимает резервный тип 0 в полезной нагрузке запроса.
Понятия не имею, почему, но он возвращает ошибку и говорит, что значение резервной копии должно быть больше 0. Если это ошибка, они должны исправить это сейчас.
Строка 47 реализует дополнительную проверку для типа резервной копии 0, поскольку она не была отфильтрована в полезной нагрузке.
Примечание:
Если вы присмотритесь, я использовал два разных метода для доступа к DP. Один из методов входа в систему использует в запросе аутентификацию по имени пользователя и паролю. Другой в методе закрытия инцидента использует токен, уже созданный с использованием чванства. Вы можете использовать и то, и другое.
Если во время тестирования вы закрываете инцидент, который не должен был закрываться, не паникуйте. Используйте приведенный ниже фрагмент, чтобы снова открыть его.
Используйте эти фрагменты для создания программы и беспроблемного закрытия инцидентов. Хлопайте в ладоши и дайте мне знать в комментариях, если я что-то пропустил.
Больше контента на plainenglish.io
