В ноябре 2021 года ИТ-директор Берг Холдинг выступал на конференции с докладом про «обратную сторону ИТ» — то, что для бизнеса обычно скрыто за первой линией поддержки. Он выделил семь зон, где у компании копятся технологические риски: персонал, серверы, сеть, разработка, проекты, эксплуатация и информационная безопасность. Спустя пять лет автор вернулся к той классификации, пересобрал детали, но суть оставил прежней.

Все семь зон он рассматривает через призму непрерывности бизнеса. Исходная аксиома простая: серверы, сети и работающие на них системы будут ломаться. Значение имеет другое — продолжит ли компания работать сразу после сбоя, будет ли поступать выручка и хватит ли мощности, когда поток заказов вырастет. Если по конкретной зоне ответа нет, риск уже существует, просто он ещё не выставил счёт.

Единственный — на каждом уровне

Через все семь зон проходит один узор: критическая функция держится на единственном элементе. В персонале это «незаменимый» сотрудник, который знает инфраструктуру и платформы, а на рынке специалиста с таким же набором навыков нет. Для этого есть отдельные термины — автобусный тест (bus factor) и риск ключевого сотрудника (Key Person Risk): что будет с системой, если этот человек завтра уйдёт.

Тот же узор в железе и сети. Сервер умер — заменить нечем, потому что резерва нет, гарантии на оборудование нет, запчастей нет, а мощность и так под потолком. Сеть собрана на домашних коммутаторах без администрирования и мониторинга, горячего резерва нет, поэтому выход из строя одного роутера бьёт сразу по всем системам. В проектах — один большой договор с единственным поставщиком, который отвечает за всё; на уровне компании это такая же зависимость от ключевого элемента, как «незаменимый» сотрудник.

Разработка: риск, который созревает тихо

Проблемы в коде накапливаются постепенно, и чаще всего причина — рост. Пока компания маленькая, один программист пишет по запросу «напиши»: без архитектуры и документации. Когда нанимают ещё людей, разобраться в этом коде становится тяжелее, а передавать знания некому.

Гибкие методы здесь часто понимают как работу без правил. Agile дисциплину не отменяет: то, что сделала одна команда, должна уметь продолжить другая. Отдельная проблема — зоопарк технологий: сегодня один фреймворк, завтра второй, и на одном продукте набирается десяток решений, под каждое из которых нужны свои люди. Поддерживать такой набор дорого.

Самый жёсткий сценарий — писать сразу на боевой среде, без контура разработки и нормального тестирования. Один неудачный релиз останавливает систему целиком, а откат оказывается плохим планом устранения аварии. Кульминация всех этих проблем — «Спаситель», который помнит весь ворох стеков и костылей и которого невозможно заменить.

Проекты: мегапроект и прыжок без исследования

Классический проектный риск — мегапроект по схеме «внедрим ERP, платите сейчас, результат будет через два года». Автор предлагает делить любой проект на этапы, которые можно «проглотить», так чтобы каждый давал осязаемую ценность, а при форс-мажоре проект можно было остановить без больших потерь.

Рядом идут ещё два риска. Первый — отсутствие предпроектного исследования: поставщика ищут раньше, чем формулируют, что вообще нужно, и через год не могут объяснить, зачем всё делалось. Второй — отсутствие проектной документации: сделали что-то уникальное, но зачем и как оно устроено, не записано, поэтому передать систему в эксплуатацию нельзя. Общая причина — отсутствие проектной культуры; тогда у бизнес-подразделения заводится «карманный» программист, и разработка снова уходит «на коленку».

Эксплуатация: система без хозяина останавливается

Дорогая иллюзия — считать, что после запуска система живёт сама. Информационная система требует доработок, людей и затрат постоянно. Если подрядчик ушёл, а пользователей и собственную ИТ-службу не обучили и документации нет, работоспособная поделка живёт пару недель, а дальше её выбрасывают или начинают разбирательства с исполнителем.

Вторая проблема эксплуатации — «слепой» мониторинг. Администратор может честно говорить, что всё под наблюдением, но следит он за процессорами и памятью без привязки к бизнес-процессам. Он не видит, что произойдёт с инфраструктурой, если поток заказов вырастет вдвое, и в какой момент бизнес упрётся в потолок производительности. Отсюда третий пункт: компания не знает, от каких именно систем она критически зависит. По таким контурам нужны резервирование и отдельный план на случай катастроф, иначе доступность сервисов остаётся делом случая.

Безопасность работает только вместе с остальным ландшафтом

Разговор про IT-риски обычно начинают с информационной безопасности; автор поставил её последней. Базовый набор требований он описывает коротко: сотрудникам нужен доступ к ресурсам, в том числе снаружи, а периметр при этом закрыт; нужны антивирус, резервное и архивное копирование, политика доступа и разбор нарушений. Для бизнес-критичных систем добавляются те же два пункта — резерв и план восстановления.

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

Три оси для быстрой проверки

Для грубой оценки автор использует три оси из методологии TODOIT: System Exposure.

Хрупкость — насколько легко систему сломать: один сервер, один программист, один поставщик означают, что удар в одну точку рассыпает всё. Устойчивость — держит ли система удар и как быстро восстанавливается: сервер может быть один, но при наличии RAID и копии восстановление получается быстрым и недорогим даже при высокой хрупкости. Управляемость — видит ли компания реальное состояние систем или только то, что ей доложили; без мониторинга и понятной реакции на сигналы управление превращается в управление сказкой. В полной методологии есть ещё ось антихрупкости.

Как этим пользоваться

Классификация ничего не внедряет; её задача — убрать слепое пятно. Перед очередным IT-проектом или обсуждением «давайте цифровизируемся» автор предлагает пройтись по семи зонам и по каждой спросить: где точка отказа и что произойдёт с бизнесом, если риск сработает.

Масштаб таких вопросов показывают два примера из того же выступления. В марте 2020 года Ростелеком с дочерними обществами перевёл на удалёнку около 130 тысяч человек за одну-две недели — компания была к этому технологически готова, и это сработало как реакция на кризис. Другой случай: аудитор Coca-Cola спросил, глядя на серверную, что будет, если сюда упадёт самолёт. Ответ был честным — конец серверной и бизнесу. В аудит попало замечание про катастрофоустойчивость: оборудование разнесли по площадкам и обеспечили переключение всей работы на резервный ЦОД за два часа. Сегодня тот же вопрос звучит буднично: что будет, если уволится единственный человек, который знает систему, или поставщик критической системы завтра поднимет цену вдвое.

Если по какой-то зоне ответа нет, счёт по этому риску — вопрос времени.