Чёрный лебедь в дата-центре и реестры рисков

Недавно я писал о пожаре в американском дата-центре Lake Mariner. Там всё оказалось весьма топорно: проблемы с пожарной безопасностью и размазанная ответственность.И кончилось безобидно вроде.

А сегодня пожар произошел в дата-центре Яндекса в Сасово. Причина совсем другая — атака беспилотников. Площадка остановлена, проблемы возникли у сторонних сервисов (ну вы наверняка ощутили).

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

Вот вы сегодня работаете руководителем проекта или аналитиком. Проектируете систему, согласовываете требования, организуете разработку, внедряете. А завтра дата-центр, на котором всё работает, — фьюить! И результаты нескольких месяцев работы недоступны. Разумеется, вы не можете предотвратить пожар или вражескую атаку. Но можете ещё на этапе проектирования задать несколько вопросов - как минимум себе.

Что произойдет, если завтра исчезнет вся площадка? 

Сколько времени бизнес готов прожить без системы? 

Сколько данных допустимо потерять? 

Есть ли резервный сценарий? 

Кто и как будет восстанавливать работу? 

И ответы (если их получите...) превратить в конкретные нефункциональные требования: восстановление за четыре часа (RTO), потеря не более 15 минут данных (RPO), сохранение документов при недоступности внешнего сервиса. Цифры условные)

За всё это приходится платить. И решение, сколько потратить на защиту от маловероятной катастрофы, — оно уже не техническое, а как раз управленческое. И один из "проектных" уроков этой ситуации в том, что вероятность риска — ни разу не константа. Мир меняется, иногда быстрее, чем наши реестры рисков и проектные допущения. Я, кстати, когда учился на курсах РП в Яндексе, как раз на уроке про управление рисками услышал от лекторов, что никакие реальные реестры они не продумывают, а просто копируют таблички. Но это было давно)

Ну и подборочка, где почитать подробнее — про такие вот риски и их проработку:

• Как составить план аварийного восстановления — вполне доступное объяснение RTO, RPO, анализа влияния на бизнес и планирования восстановления. С примерами.

• Проектирование отказоустойчивости ИТ-систем — о том, как учитывать отказы компонентов и внешних зависимостей при проектировании.

• ГОСТ Р ИСО 31000-2019 — общая методология управления рисками: выявление, оценка, обработка и пересмотр.

• ГОСТ Р ИСО 22301-2021 — управление непрерывностью деятельности организации, подготовка к сбоям и восстановлению.

• ГОСТ Р ИСО/МЭК 25010-2015 — модель качества программных систем, в том числе надёжность, отказоустойчивость и восстанавливаемость.