Перезагрузка, которая докатилась до склада
В логистической компании работали 600 человек, а в IT-отделе четверо. Серверы они вели в таблице: имя, адрес, операционная система, кто отвечает. Таблица была точной. Никто не мог вспомнить, чтобы она хоть раз ошиблась.
Во вторник днём один из инженеров перезагрузил сервер app-07, чтобы поставить обновление. В таблице он значился как «сервер приложений». Там не было сказано, что app-07 печатает транспортные этикетки для склада, что складская система обращается к нему за этикеткой каждый раз, когда посылка уходит с рампы, и что в половине третьего у рампы стоит грузовик. Перезагрузка заняла четыре минуты. Гору посылок без этикеток разбирали два часа.
Ничего необычного в этой истории нет. Таблица не врала. Ей просто не хватало второй половины фразы: app-07 это сервер приложений, без которого склад не может работать. В списке есть строки. А у сервиса есть люди, которые от него зависят.
Почему списка мало
Почти все команды начинают со списка, потому что это просто. Выгрузить его можно откуда угодно. Он отвечает на вопрос «что у нас есть?», и на этот вопрос действительно нужен ответ.
Беда в том, что почти любое решение в IT касается связей, а не строк. Можно ли перезагрузить этот сервер сегодня вечером? Смотря что на нём работает. Можно ли перенести этот диапазон адресов? Смотря какие сервисы им пользуются. Какая лицензия перестанет работать, если удалить эту программу? Кого предупредить, если система резервного копирования встанет на час? Сортировкой столбца ни на один из этих вопросов не ответишь.
Поэтому ответы хранятся в головах. Инженер, которая когда-то настраивала печать этикеток, знает, что app-07 важен. Когда она в отпуске или уже перешла в другую компанию, это знание уходит вместе с ней. А таблица выглядит точно так же, как раньше.
Запишите всю цепочку
В AverDesk сервер это лишь одна запись из многих. В учёте хранится и то, что на самом деле важно бизнесу: продукты, сервисы внутри них, работающие копии каждого сервиса, серверы, на которых они крутятся, оборудование, адреса, программы, лицензии, помещения и здания, учётные записи, проверки и правила резервного копирования. У каждой записи свои поля, своя история изменений и свои связи с остальными. (Для IT-специалиста: продукты, сервисы, экземпляры сервисов, хосты, оборудование, IP-адреса, подсети, ПО, лицензии, локации, учётные записи, мониторы и требования к резервному копированию.)
Для печати этикеток цепочка выглядит так. Продукт «Складские операции». Внутри него сервис «Печать этикеток». У сервиса одна рабочая копия, она работает на сервере app-07, а тот стоит на конкретной физической машине, в конкретной стойке, в конкретном здании. В карточке сервиса записаны ещё порты, которые он занимает, внешняя система печати, с которой он общается, и место, где лежит запасная копия на случай, если основная откажет.
Когда цепочка есть, у вопроса «можно перезагрузить app-07?» появляется видимый ответ. Открываете сервер и видите всё, что над ним. Схема зависимостей поднимается по цепочке: сервер, работающая копия, сервис, продукт, люди, которые им пользуются. Решать о перезагрузке всё равно вам. Просто она больше не станет сюрпризом.
Связи по правилам
Такая карта полезна, только пока в ней порядок, поэтому AverDesk ставит ограничители на связи. Каждая организация сама решает, какие виды связей разрешены и сколько связей каждого вида может быть у объекта. Петли не допускаются: если кто-то попробует через три шага сделать сервис зависимым от самого себя, система откажет и покажет путь, который замкнул бы круг.
Некоторые поля передаются вниз по цепочке. Работающая копия может взять расположение или правило резервного копирования у сервиса над ней, и никому не придётся вбивать одно и то же дважды. Если два «родителя» говорят разное, никто ничего не угадывает. AverDesk показывает расхождение, и правильное значение выбирает человек. У каждого поля есть история, так что видно, кто сменил ответственного за сервер, когда и что там было записано до этого.
Мы называем это живой документацией. Не нужно писать отдельную страницу про печать этикеток, чтобы потом забыть её обновить. Карточка сервиса с его серверами, портами, внешними подключениями и запасной площадкой и есть документация. И она меняется, когда меняется сама система.
Найдите то, что никто не связал
Есть и проблема потише: объекты, которые числятся в учёте, но ни к чему не привязаны. Тестовый сервер, который забыли удалить. Лицензия, которую так и не прикрепили к программе. Диапазон адресов, которые заняты, хотя ни один сервис их за собой не числит.
AverDesk ищет такие вещи специально. Карта инфраструктуры подсвечивает объекты без связей и объекты, связи которых так и не доходят до продукта. Обычно это значит, что никто не помнит, зачем они нужны. Ежедневная проверка сообщает обо всём, что «потерялось» за последние сутки, и куча сирот не растёт тихо целый год, пока её кто-нибудь не заметит.
С чего начать
Описывать всё IT в первый же день не нужно. Возьмите один сервис, остановка которого будет больно бить: такой, что склад, цех или отдел продаж заметят его отсутствие в течение часа. Запишите его продукт, сам сервис, работающие копии и серверы. Добавьте людей, которые за него отвечают. Это один вечер работы. В следующий раз, когда кто-то откроет этот сервер перед перезагрузкой, он сразу увидит за ним склад.
Если хотите попробовать на своей инфраструктуре, начните с плана Free. Одна организация, один оператор, без карты, плюс демо-организация, которую можно ломать без последствий.
Начать бесплатно
IT-инвентаризация, связанные сервисы и ежедневная поддержка.

