Признак, по которому пора проводить аудит, один и не связан с поломками: никто в компании не может назвать число работающих сценариев и сказать, что произойдёт при отключении каждого. Пока такой человек есть, аудит не нужен. Как только его нет — а это происходит примерно на восемнадцатом сценарии или в первый же отпуск того, кто их собирал, — парк начинает жить своей жизнью и тратить деньги без ведома компании.
Хорошая новость в том, что первый проход стоит один рабочий день. Восемь часов одного сотрудника — 5 600 ₽ по полной стоимости часа — дают реестр, ответы по двадцати пунктам и список находок. Плохая новость: находок всегда больше, чем ожидает руководитель, и часть из них требует действий в тот же день.
Ниже — где искать сценарии, сам чек-лист на 20 пунктов, что обычно находится в парке из 30, как расставить приоритеты и во что обходится тот же аудит, если делать его не самим.
Пять мест, где искать сценарии за один день
Панель площадки — очевидное место и самое неполное. Сценарии живут не только в ней: часть логики уехала в расписания учётной системы, часть в надстройки таблиц, часть в чей-то личный аккаунт. Реестр собирается из пяти источников подряд, и порядок здесь важен: каждый следующий добавляет то, чего не было в предыдущем.
- 1Панель самой площадки. Выписываются все сценарии, включая выключенные, с датой последнего запуска и числом прогонов за месяц. Здесь же берётся счёт за последний месяц — он понадобится в четвёртом разделе чек-листа.
- 2Системы-источники. В каждой подключённой системе — CRM, учёт, почта, телефония, площадки объявлений — открывается список выданных приложений и ключей доступа. Именно здесь обнаруживается то, чего нет в панели: подключения, оставшиеся от старых экспериментов, и ключи, выданные людям, а не интеграциям.
- 3Почтовые ящики и рабочие каналы. Куда приходят алерты и служебные письма от сценариев. Если алерты уходят на личную почту сотрудника, а не в общий канал, это отдельная находка. Если не уходят никуда — тем более.
- 4Общие каталоги, таблицы и папки. Куда сценарии складывают файлы и выгрузки. Здесь находятся отчёты, которые собираются годами, и которые никто не открывал последние восемь месяцев.
- 5Люди. Три вопроса каждому руководителю отдела: что у вас происходит само, кому вы жалуетесь, когда это перестаёт работать, и что вы делаете руками, когда оно не сработало. Последний вопрос даёт больше всего — обычно выясняется, что часть «автоматизированного» процесса давно закрывается ручным обходом.
По каждому найденному сценарию фиксируются семь вещей: имя, что он делает одной фразой, чем запускается, в какие системы ходит, кто владелец, дата последнего прогона и что сломается при отключении. Последнее поле — самое ценное и самое трудное: если ответ «не знаю», сценарий автоматически попадает в список кандидатов на выключение. Расширенный набор полей и правило их ведения мы описывали в материале про версионирование и документирование сценариев.
Карта связей: в центре крупный блок «Реестр сценариев: 7 полей на каждый». К нему сходятся пять стрелок от пяти узлов, расположенных по кругу. Узел 1 «Панель площадки» — подпись на стрелке «список, дата последнего запуска, счёт за месяц». Узел 2 «Системы-источники: CRM, учёт, почта, телефония, площадки» — подпись «выданные приложения и ключи доступа». Узел 3 «Почта и рабочие каналы» — подпись «куда приходят алерты». Узел 4 «Общие каталоги и таблицы» — подпись «куда складываются выгрузки». Узел 5 «Руководители отделов» — подпись «что вы делаете руками, когда не сработало». Толщина стрелок разная: от узлов 2 и 5 самые толстые. Под картой подпись «8 часов работы, 5 600 ₽». Чертёжный стиль, подписи по-русски.
Чек-лист: 20 пунктов в четырёх разделах
Каждый пункт сформулирован как утверждение, на которое отвечают «да» или «нет». Оценки «частично» и «в целом да» не принимаются: они и есть то состояние, ради выхода из которого проводится аудит.
| № | Раздел «Инвентарь» | Ответ «нет» означает |
|---|---|---|
| 1 | Есть письменный список всех сценариев с назначенным владельцем по каждому | Парк не управляется — начните отсюда |
| 2 | У каждого сценария записано, что он делает и что сломается при отключении | Выключить нельзя ничего, даже мёртвое |
| 3 | Известно, кто и когда менял каждый сценарий в последний раз | Откат невозможен, причину сбоя ищут опросом коллег |
| 4 | Нет двух сценариев, делающих одно и то же в разных местах | Двойная работа и расхождение данных между системами |
| 5 | Каждый сценарий запускался хотя бы раз за последние 30 дней | В парке есть призраки — они тратят операции и внимание |
| № | Раздел «Надёжность» | Ответ «нет» означает |
|---|---|---|
| 6 | У каждого сценария, который теряет данные при сбое, настроен алерт | О поломке узнаёте от клиента, а не от системы |
| 7 | Есть сигнал молчания: алерт, если сценарий не отработал за отведённый интервал | Тихие сбои не ловятся вовсе — сценарий просто отсутствует |
| 8 | Настроены повторы с растущей задержкой и ограничением числа попыток | Массовый сбой превращается в ретрай-петлю и в счёт |
| 9 | Есть очередь необработанного, и её кто-то разбирает по расписанию | Записи, не прошедшие с первого раза, исчезают молча |
| 10 | Есть суточная выгрузка парка, по которой можно вернуться на вчера | Неудачная правка не откатывается, восстановление идёт по памяти |
| № | Раздел «Безопасность» | Ответ «нет» означает |
|---|---|---|
| 11 | Ключи и пароли не вписаны в узлы открытым текстом | Экспорт сценария = полный доступ к вашим системам |
| 12 | У каждой интеграции отдельный ключ с минимальными правами | Одна утечка открывает всё, разобрать действия по журналу нельзя |
| 13 | Ни один действующий ключ не выпущен на уволенного сотрудника | У бывшего сотрудника остался работающий доступ |
| 14 | Известно, какие сценарии передают персональные данные и куда | Обязанности оператора выполняются вслепую |
| 15 | В договоре с площадкой указан срок хранения журналов прогонов | После инцидента выясняется, что данные хранились дольше, чем вы думали |
| № | Раздел «Стоимость» | Ответ «нет» означает |
|---|---|---|
| 16 | Известно, сколько операций тратит каждый сценарий в месяц | Счёт растёт, а причина роста не локализуется |
| 17 | Настроен алерт на 80 % лимита тарифа в общий рабочий канал | Лимит заканчивается в четверг днём и без предупреждения |
| 18 | Ни один сценарий не опрашивает чужую систему чаще, чем это нужно делу | Платите за холостые прогоны и грузите чужие системы |
| 19 | Известно, что произойдёт при исчерпании лимита: остановка, доплата или очередь | Последствия обнаруживаются на практике, а не в планах |
| 20 | Стоимость владения парком за год посчитана и с кем-то согласована | Расходы на автоматизацию не сравнивались с эффектом ни разу |
Пункты 16–19 разобраны подробно в материале про лимиты и тарификацию операций, пункты 11–15 — в разборе безопасности данных в облачном конструкторе. Здесь достаточно отметить, какой из двадцати пунктов чаще всего оказывается единственным «нет» в благополучном парке: это седьмой. Алерты на ошибку есть почти у всех, сигнала молчания — почти ни у кого.
Что обычно находится в парке из 30 сценариев
Модельные цифры ниже — это не статистика рынка, а типичная картина парка, который два-три года рос без назначенного владельца. Проверьте по своему: расхождения обычно в пределах трети.
- Девять сценариев-призраков из тридцати. Работают, тратят операции и не нужны никому: процесс изменился, отчёт перестали открывать, отдел расформировали. Признак — либо ноль запусков за 30 дней, либо запуски есть, но на вопрос «что сломается при отключении» никто не отвечает. Проверяются выключением на неделю: если никто не заметил, сценарий был мёртвый.
- Четырнадцать сценариев без назначенного владельца. Их кто-то собрал, и этот кто-то уже не считает их своими. Именно они дольше всего лежат сломанными, потому что алерт приходит человеку, который не считает себя ответственным.
- Одиннадцать сценариев без единого алерта. Половина из них ничего не теряет при сбое, и это нормально. Вторая половина — теряет, и о поломке компания узнаёт от клиента.
- Три пары, делающие одно и то же. Классика: заявку в CRM кладёт и сценарий с сайта, и сценарий из почты, потому что второй собрали, когда про первый забыли. Отсюда же берётся половина дублей в карточках.
- Четыре действующих ключа уволенных сотрудников. Ключ выпущен на человека, человек ушёл, интеграция продолжает работать под его учётной записью. Это одновременно и дыра в доступах, и мина: как только его учётку заблокируют по кадровому регламенту, четыре сценария встанут одновременно.
- Два сценария, опрашивающих чужую систему чаще, чем нужно. Обычно это остатки настройки «на всякий случай почаще», сделанной в первый день и с тех пор не пересматривавшейся.
Горизонтальная столбчатая диаграмма на фоне серой полосы «парк — 30 сценариев». Шесть столбцов с числами и подписями сверху вниз: «Без назначенного владельца — 14», «Без единого алерта — 11», «Сценарии-призраки — 9», «Действующие ключи уволенных — 4 подключения», «Пары, делающие одно и то же — 3», «Опрашивают чужую систему чаще нужного — 2». Столбцы «призраки» и «ключи уволенных» выделены штриховкой с подписью «требуют действия сразу». Справа врезка: «выключение 9 призраков — 4 500 ₽ в месяц, 54 000 ₽ в год». Чертёжный стиль, подписи по-русски.
Обратите внимание, что в расчёт вошли только две находки из шести — те, у которых есть прямое денежное выражение. Остальные четыре считаются не экономией, а снятым риском: сценарий без владельца дороже не становится, он просто дольше лежит сломанным, а действующий ключ уволенного сотрудника вообще не имеет цены до момента, когда им кто-то воспользуется.
Приоритизация: сегодня, на неделе, на квартал
Список находок из двадцати пунктов легко парализует: непонятно, за что браться, и в итоге не делается ничего. Порядок задаётся не размером эффекта, а обратимостью последствий — то, что нельзя отменить задним числом, чинится первым.
| Когда | Что чинится | Почему именно сейчас |
|---|---|---|
| Сегодня | Действующие ключи уволенных, ключи открытым текстом в узлах, сценарии без алерта, которые теряют данные | Последствия необратимы: утечка не отменяется, потерянная заявка не возвращается |
| На этой неделе | Алерт на 80 % лимита, сигнал молчания, выключение призраков, разбор трёх дублирующих пар | Дёшево, быстро и сразу останавливает утечку денег и внимания |
| В течение квартала | Паспорта сценариев, карта запусков, правило именования, назначение владельцев, перевод опроса на события | Требует не часов, а договорённостей внутри компании — за неделю это не делается |
| Никогда | Переименование ради единообразия, объединение узлов ради изящества, переписывание работающих сценариев | Не даёт ни денег, ни надёжности, зато создаёт риск сломать то, что работало |
Соблазн выключить все девять найденных сценариев в один день велик и обходится дорого. Правильный порядок другой: выключать по два-три, ждать неделю и смотреть, не всплыло ли что-нибудь. Из девяти «мёртвых» обычно один-два оказываются живыми — их результат читал отчёт, о котором никто не помнил. Обнаруживается это на седьмой день, и если выключено было девять, разбираться придётся с девятью сразу.
Что даёт аудит у подрядчика и сколько это стоит
Своими силами закрывается инвентарь и большая часть безопасности. Разделы «надёжность» и «стоимость» требуют человека, который умеет читать журналы прогонов и считать операции, — своими силами их обычно проходят наполовину. Если решено звать подрядчика, вот что имеет смысл требовать на выходе.
- Реестр с паспортами. По каждому сценарию — восемь полей, включая «что сломается при отключении» и «кто владелец». Это единственный артефакт аудита, который продолжает работать после его окончания.
- Карта запусков. Кто кого вызывает, какие сценарии пишут в один и тот же объект, что встанет при отключении каждого узла. Отдельно отмечаются места, куда пишут два и более сценария, — будущие дубли.
- Отчёт по двадцати пунктам. С ответом «да» или «нет» по каждому и с указанием, на каких именно сценариях ответ отрицательный. Не «требует улучшения», а перечень.
- Список находок с ценой правки. По каждой находке — что произойдёт, если не чинить, сколько часов займёт починка и в каком приоритете она стоит. Без цены находка превращается в упрёк, а не в задачу.
- Смета владения парком на год. Подписка, операции, работа инженера, часы внутреннего владельца и цена простоев. Обычно это первый раз, когда компания видит полную стоимость своей автоматизации, — методику мы разбирали в материале про стоимость владения парком за год.
Трудозатраты на такой аудит парка из 30 сценариев — 16–24 часа, то есть 48 000–72 000 ₽ по ставке 3 000 ₽/час, срок 1–2 недели. Вилка по рынку шире: 40 000–120 000 ₽, и верхняя граница обычно означает, что в работу включён не только разбор, но и первые правки. Проверочный вопрос при заказе один: что именно я получу на руки. Если ответ «отчёт с рекомендациями» без реестра и без цен правок, вы платите за мнение, а не за артефакт.
Когда аудит проводить не надо
Сплошной проход стоит времени и почти всегда заканчивается списком дел. Четыре случая, в которых его лучше отложить.
- Сценариев меньше восьми и все собраны одним человеком, который на месте. Он и есть реестр. Порог, после которого нужен явно назначенный ответственный и письменный список, — около восемнадцати сценариев; до него достаточно суточной выгрузки и получаса на паспорта. Подробнее эту границу мы считали в материале про то, кто в компании ведёт сценарии.
- Прямо сейчас идёт переезд или крупная перестройка. Аудит парка, половину которого через месяц выключат, — работа по описанию того, чего не будет. Правильный порядок обратный: сначала инвентаризация в рамках переезда, потом аудит того, что осталось.
- Уже есть свежий реестр и по нему работают. Повторный аудит имеет смысл раз в год или после смены владельца сценариев, а не по календарю. Между полными проходами достаточно двух проверок в квартал: ноль запусков за 30 дней и ключи уволенных.
- Нет никого, кто возьмётся за находки. Аудит без последующих действий — это 5 600 ₽ за список, который вызывает тревогу и не меняет ничего. Если браться за находки некому, полезнее сначала решить вопрос владельца парка, а аудит провести уже вместе с ним — тогда список станет его планом работ, а не чужим упрёком.
Автоматизация, о которой никто не может сказать, сколько её и что она делает, — это не актив, а обязательство.
