В IT есть негласный культ тушения пожаров. Упал критичный сервис. Команда собралась, не спала ночь, нашла баг и всё подняла. Утром все жмут друг другу руки. Все расходятся. Ну вы помните, я писал недавно.

Только вот баг никуда не делся. Вы просто купили небольшую отсрочку до следующего раза.

Разовая победа над инцидентом не стоит ничего, если она зависит только от вашего героизма. Если причина сбоя не превратилась в новое правило, регламент или скрипт, она повторится. Обязательно (по крайней мере, если это не случайная разовая поломка, а повторяемая история или системная слабость).

И тут хорошо подходит термин “институционализация”. Скучное слово, которое и прочитать с первого раза сложно, не то что выговорить. Но именно этот подход отличает человека, который чинит инцидент, от человека, который делает так, чтобы он не повторялся.

Ну вот, например, лёг у вас канал связи из-за кривого обновления на маршрутизаторе. Вы можете зайти и откатить апдейт руками. Всё так, но это работа админа из саппорта. И если это сделал он, то он свою работу делает хорошо и вообще молодец. Вы — нет.

После того как админ сделал свою работу, должна начаться ваша. Ведь вы же знаете, что этот инцидент происходит с завидной регулярностью. Почему бы не написать регламент обязательного тестирования обновлений в песочнице, согласовать его с бизнесом и заставить команду по нему работать?

После каждого серьёзного сбоя я делаю одно: не даю этой ошибке повториться. Пишу регламент, меняю процесс, внедряю автоматизацию.

Герои нужны там, где система не работает или появляется что-то неизведанное. Здоровая система работает скучно и по правилам.

А как у вас в компании? Пишете постмортемы и меняете процессы после аварий, или просто радуетесь, что лампочки снова зеленые?