По мотивам ITIL и ГОСТ
Мы не любим показывать свои ошибки. Скрываем опечатки, и больные зубы. Если мы спотыкаемся, или одеваем не ту одежду, над нами смеются. Смехом общество наказывает за оплошности. В этом практический смысл смеха. Мы боимся ошибаться. Скрываем.
Производство довольно сильно страдает от этой человеческой особенности. Многие аминистраторы тяготеют к сокрытию сбоев. Мало кто хочет информировать об ошибках своё ИТ- начальство.
Начальство может не только высмеять, но и наказать.
Но и начальник подразделения ИТ боится.
Он боится сказать о сбое(инциденте) ИТ-системы пользователям, заказчику ИТ-системы. По тем же причинам.
Сбой информационной системы может возникать неожиданно, последствия сбоя для заказчика становятся непредсказуемы. Неприятно, если вы два часа заполняли данные в системе, а они бац и пропали, потому что в системе произошел сбой, про который промолчал админ.
Банкомат, неожиданно съел вашу карточку — это ещё одна история о том, как не предупредили клиента о сбое.
Наука и практики управления ИТ(ITIL) рекомендуют следующее при устранении сбоя:
1) Оповестить пользователей о том, что произошел сбой.
2) Применить временное, или обходное решение, позволяющее восстановить работоспособность системы.
3) Осуществить переход на резервную технологию, если невозможно восстановить работоспособность системы.
4) Оповестить пользователя о том, что всё в порядке.
В крупных ИТ-компаниях время всех этапов нормировано. К примеру так:
Кажется всё логично, зачем про это говорить? Между тем, наука рекомендует эту последовательность действий оформить в виде регламента управления инцидентами– закона для администратора ИТ-системы. Зачем оформлять очевидное?
Есть ещё один нюанс мышления в том числе администратора ИТ: при внедрении процесса управления инцидентами, я часто сталкивался с мнением о том, что зачем мне тратить время на оповещение – важней устранить сбой. Чем быстрей, тем лучше. Нет. Это ошибка.
Временное или обходное решение. Обходное решение инцидента - это, согласно вики: уменьшение или устранение влияния инцидента или проблемы, для которых в текущий момент недоступно полное разрешение. Перезагрузка– самое распространённое обходное решение устранения инцидента. Устранение инцидента(сбоя) и устранение причины инцидента – вещи разные. Большинство студентов не устраняют инцидент, а устраняют причину. Вместо того, чтобы рестартануть систему, они читают логи и расследуют. Как головоломку и кроссворд. Это увлекательно.
В большинстве крупных ИТ-компаний есть перечень обходных решений по устранению инцидентов в соответствии с симптоматикой. Перечень готовых решений по устранению проблемы. Выглядит примерно так:
Если обходное решение не сработало, или его нет, то осуществляется переход на резервную технологию. В многих ИТ-компаниях есть резервные сервера, базы данных, дампы и т.п. Штука обычно недорогая, но может реально помочь. Наука данные нюансы так же рекомендует регламентировать.
И. Важно. Все шаги по устранению сбоя желательно фиксировать, чтобы потом понять, что произошло. Расследование и устранение причин сбоя – это следующий этап лечения ИТ-системы. На данный момент мы просто сбили температуру. Мы ещё никого не вылечили и доолжны знать симптомы.
Есть админы, которые врут при описании сбоя, мер по устранению сбоя. Причины те же. Страх наказания, того, что тебя высмеют за неправильные действия при восстановлении системы. Но. Врать надо тоже уметь. Начальники админов тоже врут. Ещё хлеще.
В результате вранья мы не получаем достоверной информации о состоянии системы и не можем, к примеру, купить что-то новое. Складывается ситуация, при которой ни директор ни клиент не знают, что у них глючная система. Не всегда, но часто.
После того, как устранили сбой, логично оповестить клиента о том, что сбой устранён. Хорошо если оповещение автоматизировано, а если нужно звонить? Одна очень умная девушка администратор стеснялась звонить наверх, потому, что там орали. Не оповестила с непривычки (система не падала годами). Ей уволили. Наняли нестеснительного, система стала сбоить каждый месяц.
Резюмируя:
• Необходимо оповещать, восстанавливать работоспособность с помощью обходного решения/перехода на резерв, и снова оповещать.
• Человек слаб и нужно регламентировать особо острые моменты. Не надо писать талмуды. В виде простого рисунка, таблички -матрицы будет лучще.
• Лучше не орать. А то будет, как с той умной, но стеснительной девушкой.
Мы так и не починили систему и, может быть, новый сбой. Да, пока не устранена корневая причина инцидентов- может быть новый сбой. Выявление и устранение сбоев – происходит в рамках управления проблемой (problem management). Про это потом. А пока вы бесплатно прошлись по основным моментам управления инцидентами из практик управления ИТ.
Забыл. Полностью картинка работы со сбойной системой выглядит так:
Если вы на своём предприятии управляете инцидентами по-другому – пишите нюансы.
