Вся система держится на одном человеке
Единственный разработчик или администратор знает доступы, схему данных и исторические решения. Его уход или длительная нетрудоспособность останавливает развитие и часть эксплуатации.
Оценка ИТ-рисков
Риски, выраженные в деньгах и сроках
Выясняем, что остановит ваш бизнес, если откажет система, уйдёт разработчик или подведёт подрядчик. Каждый риск получает оценку вероятности, стоимости последствий и конкретные меры с ответственным.
Или сразу: +7 (962) 368-39-51 Telegram
реестр
риски с владельцем и сроком пересмотра
матрица
вероятность на стоимость последствий
BIA
анализ воздействия на бизнес-процессы
квартал
периодичность пересмотра и отчётности
Риски, которые чаще всего не учтены
Это не гипотетические угрозы, а ситуации, которые мы регулярно находим в компаниях среднего размера.
Нет избыточности в инфраструктуре
Один сервер, один диск, один канал связи или один аккаунт у провайдера. Плановая замена оборудования или авария у хостера превращается в простой без запасного варианта.
Резервные копии не проверялись
Копии делаются по расписанию, но восстановление никогда не тестировали. Типичный сюрприз — отсутствие части данных или невозможность развернуть систему из копии за приемлемое время.
Нет плана действий при сбое
При инциденте никто не знает, кто принимает решение, в каком порядке поднимать сервисы и как информировать клиентов. Время уходит на выяснение ролей, а не на восстановление.
Лицензии и права не проверены
Используются библиотеки с несовместимыми условиями, проприетарные компоненты без лицензий, а права на исходники заказной системы не закреплены в договоре с подрядчиком.
Зависимость от одного подрядчика
Подрядчик ведёт систему годами, документации нет, доступы у него, а альтернативу на рынке вы не проверяли. Смена поставщика означает фактически переписывание.
Как устроена работа с рисками
Последовательность от выявления до регулярного пересмотра. Каждый этап даёт документ, которым пользуются после завершения проекта.
Идентификация рисков
Собираем полный перечень угроз по системам, людям, поставщикам, данным и деньгам. Источники — не только опросы, но и разбор инцидентов, договоров и конфигураций.
- Интервью с владельцами процессов и ИТ-командой
- Разбор инцидентов, сбоев и аварийных ситуаций за последние два года
- Анализ договоров с подрядчиками, провайдерами и по лицензиям
- Проверка фактического состояния: доступы, копии, конфигурации, зависимости
Анализ воздействия на бизнес (BIA)
Определяем, что именно произойдёт с бизнесом, если конкретная система или процесс остановится. Это позволяет отделить критичное от неудобного и не тратить бюджет на всё подряд.
- Критичность систем и процессов по влиянию на выручку и обязательства
- Допустимое время простоя и допустимая точка восстановления данных
- Оценка потерь в час простоя по каждому ключевому процессу
- Каскадные эффекты: что останавливается вслед за первым отказом
Оценка и матрица рисков
Каждый риск получает вероятность, стоимость последствий и итоговый уровень. Результат сводится в матрицу, по которой видно, где сосредоточены основные угрозы.
- Реестр рисков с владельцем, причиной и связанными системами
- Оценка вероятности и влияния с обоснованием, а не по интуиции
- Матрица «вероятность × последствия» и карта рисков
- Сравнение остаточного риска со стоимостью его снижения
Планы обработки и непрерывности
Для каждого значимого риска выбирается стратегия: снизить, перераспределить, принять или отказаться от деятельности. Затем оформляются планы, которые можно выполнить в момент инцидента.
- Мероприятия по снижению с бюджетом, сроком и ответственным
- План непрерывности: порядок восстановления сервисов и роли при инциденте
- Проверка восстанавливаемости резервных копий на практике
- Регламент пересмотра реестра рисков и отчётности раз в квартал
Этапы оценки рисков
Работаем последовательно: сначала полный перечень угроз, затем их оценка и только потом меры. Обратный порядок приводит к покупке решений до понимания задачи.
-
01 2–3 недели
Идентификация
Интервью, разбор инцидентов и договоров, проверка фактического состояния систем и доступов. Формируем первичный перечень рисков.
-
02 1–2 недели
Оценка и матрица
Определяем критичность систем, считаем потери от простоя, оцениваем вероятность и влияние каждого риска. Строим матрицу и карту рисков.
-
03 2–3 недели
Планы обработки
Выбираем стратегию по каждому значимому риску, формулируем мероприятия с бюджетом и ответственным, оформляем план непрерывности.
-
04 2–4 недели
Проверка и регламент
Проверяем восстановление из резервных копий на практике, передаём реестр владельцам и вводим регулярный пересмотр раз в квартал.
Почему вероятность риска нужно оценивать обоснованно
Самая частая ошибка в реестрах рисков — колонка «вероятность», заполненная интуицией. В результате весь реестр превращается в список страхов, где «высокая вероятность» стоит у события, не случавшегося ни разу, и у события, происходящего каждый месяц.
Мы опираемся на данные: статистика инцидентов за прошлые периоды, история сбоев у используемых провайдеров, срок службы оборудования, текучесть в ИТ-команде, концентрация знаний на конкретных людях, число внешних зависимостей. Там, где данных нет, вероятность обозначается как неизвестная — и это отдельный пункт плана: сначала собрать статистику, потом принимать решения о бюджете.
Что такое допустимое время простоя и как его определить
Допустимое время простоя — это период, в течение которого отсутствие системы не приводит к необратимым потерям. Оно определяется не техническими соображениями, а бизнесом: сколько часов клиент готов ждать оформления заказа, сколько времени склад может работать на бумаге, сколько секунд допустимо отклонять платежи.
На практике ответ сильно различается по системам. Для интернет-магазина в высокий сезон несколько часов простоя означают прямые потери выручки; для системы внутренней отчётности день недоступности — неудобство. Разделение по этому признаку позволяет не строить дорогую отказоустойчивую конфигурацию для всего подряд: критичные сервисы получают резервирование, остальные — быстрое восстановление из копий.
Резервное копирование: почему копия без проверки не считается защитой
Наличие расписания резервного копирования не означает, что данные восстановимы. Типичные проблемы: копии пишутся на тот же диск или в тот же аккаунт, что и основная система; часть данных (например, вложения или внешние файлы) не попадает в копию; срок хранения слишком короткий, чтобы заметить порчу данных; восстановление занимает сутки вместо часа.
Единственный надёжный критерий — проведённое учение. Мы разворачиваем систему из копии на отдельном контуре и замеряем фактическое время восстановления и полноту данных. Если процесс занимает дольше допустимого простоя или данных не хватает, это не резервное копирование, а его имитация, и в реестре рисков оно отмечается соответствующим образом.
Частые вопросы
Обычно для компании среднего размера получается от 25 до 60 рисков, из которых значимыми признаются 10–15. Реестр не должен быть длинным ради полноты: мы группируем однотипные риски и детализируем только те, по которым планируются меры. Каждый риск в реестре имеет владельца, иначе он не будет обрабатываться.
Базовая оценка строится на трёх составляющих: упущенная выручка за час простоя, дополнительные расходы на ручной обход процесса и потери от нарушенных обязательств перед клиентами и партнёрами. Для внутренних систем вместо выручки считаются затраты рабочего времени сотрудников, чья работа остановлена. Полученные цифры уточняются вместе с финансовым подразделением.
Почти всегда комбинацией, и выбор зависит от соотношения стоимости меры и остаточного риска. Дешевле всего обычно организационные меры: регламент, резервный доступ, документирование, распределение знаний между двумя специалистами. Дорогие технические меры применяются там, где простой действительно критичен, и после того как организационные уже исчерпаны.
Плановый пересмотр — раз в квартал, он занимает один-два часа: проверяются статусы мероприятий, обновляются оценки, добавляются новые риски. Внеплановый пересмотр нужен после крупного инцидента, смены ключевого подрядчика, запуска нового продукта, существенного изменения состава ИТ-команды или смены инфраструктурного провайдера.
IT-консалтинг: другие направления
Смежные задачи, которые обычно решаются в одном проекте с этой.
Знаете, что остановит ваш бизнес?
Опишите ландшафт систем — предложим объём оценки рисков и назовём сроки.