Почему я перестал оценивать ИТ по количеству серверов, лицензий и закрытых заявок
О том, почему устойчивость бизнеса важнее технических показателей
За последние годы я участвовал в десятках проектов - инфраструктура, ИБ, непрерывность. Но почти везде видел одну и ту же картину.
ИТ-служба показывает отчет:
- доступность 99,9%;
- заявки закрываются в срок;
- оборудование обновлено;
- бэкапы идут;
- критических инцидентов нет.
На экране всё зеленое.
В презентации - порядок. Формально вопросов нет.
А потом задаешь простой вопрос: что будет с бизнесом, если завтра эта система перестанет работать?
И внезапно выясняется, что "всё под контролем" - это про ИТ. Но не про бизнес.
Иллюзия контроля
ИТ отлично знает:
- где стоит сервер;
- сколько в нем ядер;
- когда закончится поддержка.
Но часто хуже понимает:
- какой бизнес-процесс на этом живет;
- сколько денег он приносит;
- сколько компания теряет при остановке.
В результате возникает парадокс:
Система доступна, а бизнес-процесс - нет.
Во многих компаниях ИТ измеряют через удобные метрики:
- количество закрытых заявок;
- время реакции;
- SLA;
- число релизов;
- объем закупок.
Это полезно. Проблема начинается, когда это становится единственной правдой.
Бизнес не зарабатывает на серверах. Он зарабатывает на операциях:
- принял заказ;
- провел платеж;
- отгрузил товар;
- закрыл период.
Все остальное - обслуживающая функция.
Пример из практики: система работает стабильно, мониторинг зеленый, но учет не готов к изменениям законодательства. В итоге продавать можно, а корректно учитывать - уже нет.
Формально - не авария. Фактически - бизнес остановился.
Конфликт, который никто не признает
Отдельный жанр - отношения ИТ и коммерции.
Маркетинг приходит с идеей увеличить конверсию.
ИТ отвечает: "Это нереалистично".
В этот момент полезно помнить простую вещь: зарплата ИТ в конечном итоге платится из выручки.
Если выручка не растет, то задачи по оптимизации всё равно появятся. Просто формулировка станет короче и жестче.
Сколько стоит один час тишины
Ключевой разворот в мышлении происходит, когда начинаешь считать не системы, а стоимость простоя операций.
Не "упала CRM", а:
- остановился прием заказов;
- не проходят платежи;
- склад не отгружает;
- касса не работает.
И у каждой операции есть цена простоя.
После этого многое меняется.
Двухчасовое окно ночью может быть нормальным, а 20 минут сбоя в пике - дороже месячной поддержки.
В результате появляются правильные вопросы:
- где реальные узкие места;
- какие инциденты повторяются;
- что дешевле: устранить причину или продолжать тушить.
Да, это тот самый problem management. Тот, который редко красиво выглядит в отчетах. Закрыть 100 инцидентов - хороший слайд. Убрать их причину за полгода - скучный. Но бизнесу обычно нужен второй вариант.
Резервирование из PowerPoint
Отдельная иллюзия - отказоустойчивость. Резервные ЦОДы, DRP, схемы, регламенты. Дорого, солидно, убедительно. Пока не начинается тест. В одном проекте переключение на резерв не произошло, потому что уведомление было настроено на сотрудника, который уже уволился.
Резерв есть. Процесс есть. Человека - нет.
В другом случае бэкапы делали исправно. Но никто не считал, сколько времени займет восстановление. Оценка - несколько дней только на перенос данных.Т.е. формально всё есть. Фактически - восстановление в теории.
Бэкап Шрёдингера
Любимая формулировка в отчетах: "Резервное копирование выполняется успешно". Хорошо. Когда последний раз восстанавливали систему?
Если ответа нет - это не бэкап. Это архив с хорошей отчетностью.
Пока вы не проверили восстановление целиком - данные, доступы, интеграции - вы не знаете, работает ли это.
Что действительно стоит измерять
Со временем я перестал начинать аудит с серверов и лицензий.
Собственнику важнее другое:
- Стоимость часа простоя конкретной операции
- Допустимое время восстановления
- Единые точки отказа
- Зависимость от конкретных людей
- Полный ущерб (не только выручка, но и штрафы, срывы, ручной труд)
Технические метрики никуда не деваются. Они просто перестают быть самоцелью, потому что 99,9% доступности - это цифра ни о чем, пока не понятно, на какие именно 0,1% пришлись.
Непрерывность - это не только ИТ
Частая ошибка - считать, что всё заканчивается на инфраструктуре.
Не заканчивается. После восстановления должны заработать:
- финансы;
- продажи;
- логистика;
- безопасность;
- операционные процессы.
Можно поднять ERP за 2 часа и еще сутки ждать человека с правом подписи.
Можно восстановить складскую систему и обнаружить, что на площадке нет нужного оборудования.
Можно запустить интернет-магазин и не иметь возможности доставить заказ.
Непрерывность - это способность компании работать,а не просто включить серверы.
Почему я об этом пишу?
Между ИТ и бизнесом почти всегда есть разрыв. Бизнес говорит про деньги, сроки и риски. ИТ - про архитектуру, релизы и инфраструктуру.
Решения часто принимаются не на основе риска, а на основе:
- бюджета;
- влияния;
- "кто громче".
Вопрос "что безопаснее для компании" подменяется вопросом "что дешевле сейчас". Иногда дорогой проект действительно не нужен, но отказ от него может стоить дороже. Поэтому я не верю ни в абсолютную правоту бизнеса, ни в абсолютную правоту ИТ.
Работает только одно: считать последствия, проверять факты и убирать иллюзии.
Этот блог - как раз про это.
Не про железо и не про «лучшие практики», а про то, как отличить реальную устойчивость бизнеса от красивого зеленого дашборда.