Почему я перестал оценивать ИТ по количеству серверов, лицензий и закрытых заявок

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

О том, почему устойчивость бизнеса важнее технических показателей

За последние годы я участвовал в десятках проектов - инфраструктура, ИБ, непрерывность. Но почти везде видел одну и ту же картину.

ИТ-служба показывает отчет:

- доступность 99,9%;

- заявки закрываются в срок;

- оборудование обновлено;

- бэкапы идут;

- критических инцидентов нет.

На экране всё зеленое.

В презентации - порядок. Формально вопросов нет.

А потом задаешь простой вопрос: что будет с бизнесом, если завтра эта система перестанет работать?

И внезапно выясняется, что "всё под контролем" - это про ИТ. Но не про бизнес.

Иллюзия контроля

ИТ отлично знает:

- где стоит сервер;

- сколько в нем ядер;

- когда закончится поддержка.

Но часто хуже понимает:

- какой бизнес-процесс на этом живет;

- сколько денег он приносит;

- сколько компания теряет при остановке.

В результате возникает парадокс:

Система доступна, а бизнес-процесс - нет.

Во многих компаниях ИТ измеряют через удобные метрики:

- количество закрытых заявок;

- время реакции;

- SLA;

- число релизов;

- объем закупок.

Это полезно. Проблема начинается, когда это становится единственной правдой.

Бизнес не зарабатывает на серверах. Он зарабатывает на операциях:

- принял заказ;

- провел платеж;

- отгрузил товар;

- закрыл период.

Все остальное - обслуживающая функция.

Пример из практики: система работает стабильно, мониторинг зеленый, но учет не готов к изменениям законодательства. В итоге продавать можно, а корректно учитывать - уже нет.

Формально - не авария. Фактически - бизнес остановился.

Конфликт, который никто не признает

Отдельный жанр - отношения ИТ и коммерции.

Маркетинг приходит с идеей увеличить конверсию.

ИТ отвечает: "Это нереалистично".

В этот момент полезно помнить простую вещь: зарплата ИТ в конечном итоге платится из выручки.

Если выручка не растет, то задачи по оптимизации всё равно появятся. Просто формулировка станет короче и жестче.

Сколько стоит один час тишины

Ключевой разворот в мышлении происходит, когда начинаешь считать не системы, а стоимость простоя операций.

Не "упала CRM", а:

- остановился прием заказов;

- не проходят платежи;

- склад не отгружает;

- касса не работает.

И у каждой операции есть цена простоя.

После этого многое меняется.

Двухчасовое окно ночью может быть нормальным, а 20 минут сбоя в пике - дороже месячной поддержки.

В результате появляются правильные вопросы:

- где реальные узкие места;

- какие инциденты повторяются;

- что дешевле: устранить причину или продолжать тушить.

Да, это тот самый problem management. Тот, который редко красиво выглядит в отчетах. Закрыть 100 инцидентов - хороший слайд. Убрать их причину за полгода - скучный. Но бизнесу обычно нужен второй вариант.

Резервирование из PowerPoint

Отдельная иллюзия - отказоустойчивость. Резервные ЦОДы, DRP, схемы, регламенты. Дорого, солидно, убедительно. Пока не начинается тест. В одном проекте переключение на резерв не произошло, потому что уведомление было настроено на сотрудника, который уже уволился.

Резерв есть. Процесс есть. Человека - нет.

В другом случае бэкапы делали исправно. Но никто не считал, сколько времени займет восстановление. Оценка - несколько дней только на перенос данных.Т.е. формально всё есть. Фактически - восстановление в теории.

Бэкап Шрёдингера

Любимая формулировка в отчетах: "Резервное копирование выполняется успешно". Хорошо. Когда последний раз восстанавливали систему?

Если ответа нет - это не бэкап. Это архив с хорошей отчетностью.

Пока вы не проверили восстановление целиком - данные, доступы, интеграции - вы не знаете, работает ли это.

Что действительно стоит измерять

Со временем я перестал начинать аудит с серверов и лицензий.

Собственнику важнее другое:

  1. Стоимость часа простоя конкретной операции
  2. Допустимое время восстановления
  3. Единые точки отказа
  4. Зависимость от конкретных людей
  5. Полный ущерб (не только выручка, но и штрафы, срывы, ручной труд)

Технические метрики никуда не деваются. Они просто перестают быть самоцелью, потому что 99,9% доступности - это цифра ни о чем, пока не понятно, на какие именно 0,1% пришлись.

Непрерывность - это не только ИТ

Частая ошибка - считать, что всё заканчивается на инфраструктуре.

Не заканчивается. После восстановления должны заработать:

- финансы;

- продажи;

- логистика;

- безопасность;

- операционные процессы.

Можно поднять ERP за 2 часа и еще сутки ждать человека с правом подписи.

Можно восстановить складскую систему и обнаружить, что на площадке нет нужного оборудования.

Можно запустить интернет-магазин и не иметь возможности доставить заказ.

Непрерывность - это способность компании работать,а не просто включить серверы.

Почему я об этом пишу?

Между ИТ и бизнесом почти всегда есть разрыв. Бизнес говорит про деньги, сроки и риски. ИТ - про архитектуру, релизы и инфраструктуру.

Решения часто принимаются не на основе риска, а на основе:

- бюджета;

- влияния;

- "кто громче".

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

Работает только одно: считать последствия, проверять факты и убирать иллюзии.

Этот блог - как раз про это.

Не про железо и не про «лучшие практики», а про то, как отличить реальную устойчивость бизнеса от красивого зеленого дашборда.

33
11