Что перестанет работать завтра утром, если отключится ваш основной ЦОД?

Продолжаю цикл про антикризисный ИТ-аудит.

На этот раз - не про стойки, лицензии и красивую презентацию, а про гораздо более приземленную вещь: что именно в компании умрет первым, если основной ЦОД или другая критичная площадка внезапно скажет: «Всем спасибо, все свободны».

Вот минимальный список вопросов, который позволяет понять, насколько ситуация действительно находится под контролем. Или мы снова надеемся на регламенты пятилетней давности, героизм дежурной смены и милость Ктулху. Но главное помнить, что восстановление ИТ - не конечная цель. Цель - продолжение работы компании.

Аварийное восстановление - это не только задача ИТ

План аварийного восстановления - не отдельный героический документ ИТ-службы, который хранится в папке с названием «ФИНАЛ_7_ТОЧНО_ПОСЛЕДНИЙ.pdf». Он должен быть частью общей системы непрерывности бизнеса.

Нет большого смысла быстро восстановить серверы, если компания все равно не может принимать заказы, проводить платежи, отгружать товары, связываться с клиентами или принимать управленческие решения. Поэтому начинать нужно не с оборудования, а с анализа влияния на бизнес.

Это оценка того:

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

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

- сколько будет стоить простой;

- какие функции нужно восстанавливать в первую очередь;

- от каких систем, людей и подрядчиков они зависят.

А уже после этого можно выбирать оборудование, технологии резервирования и порядок восстановления.

Если в ответ на этот вопрос вам начинают перечислять серверы, системы хранения данных и виртуальные машины, то у меня плохие новости. Перед вами не картина устойчивости бизнеса, а экскурсия по инвентаризационной ведомости. Нужно понимать не только, какое оборудование отключится, но и что произойдет с бизнес-процессами:

- интернет-магазин перестанет принимать заказы;

- склад не получит задания на сборку;

- перестанут формироваться электронные накладные;

- не будут проходить платежи;

- контакт-центр потеряет входящую телефонию;

- отдельное направление не сможет совершать исходящие звонки;

- корпоративная учетная система перестанет передавать данные в другие подразделения.

Соглашение об уровне сервиса здесь тоже не дает полной картины.

Сервис может быть доступен на 99,9%, но если каталог работает, а платежи не проходят, то для клиента интернет-магазин не работает. Формально всё живо. Фактически бизнес уже сидит в горящей комнате с табличкой «Всё нормально».

Очень интересный вопрос. Особенно потому, что в большинстве компаний ответ звучит одинаково: «У нас всё критично».

Но если критично всё, значит, приоритетов нет вообще. А в момент аварии это быстро превращается в командную игру «кто громче позвонил руководителю, того и восстанавливаем первым». На практике системы стоит разделить как минимум на три уровня.

Жизненно критичные системы - mission-critical.

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

Их отказ - это не «сотрудникам стало неудобно». Это остановка бизнеса с финансовыми, юридическими или даже физическими последствиями.

Критичные для бизнеса системы - business-critical.

Они необходимы для выручки, управления клиентами, работы сотрудников и долгосрочной устойчивости компании. Но их остановка не всегда убивает бизнес в первые пятнадцать минут.

Например, CRM, расчет заработной платы, кадровые системы или часть аналитических платформ. Их простой на несколько часов может быть терпимым, на несколько дней - уже нет.

Системы офисной и операционной продуктивности.

Почта, мессенджеры, текстовые редакторы, таблицы, внутренние порталы и другие инструменты ежедневной работы.

Они важны. Без них сотрудники начинают общаться через личные телефоны, пересылать файлы самыми творческими способами и вспоминать, как выглядел офис в 2007 году. Но это не значит, что корпоративную почту всегда нужно восстанавливать раньше кассовой системы или складского контура.

Такое разделение необходимо не ради красивой таблицы. Оно определяет очередность восстановления и требования к доступности.

Для каждой системы нужно понимать:

Именно здесь обычно начинается спор подразделений. Логистика уверена, что важнее склада ничего нет. Финансы напоминают, что без учета компания быстро познакомится с регуляторами. Продажи считают, что без CRM жизнь в принципе теряет смысл. Поэтому приоритет нельзя определять голосованием или должностью самого убедительного руководителя. Нужна единая оценка последствий: что остановится, через какое время, сколько это будет стоить и какие риски возникнут. Иначе в аварийном плане первой будет стоять не самая важная система, а та, за которую активнее всех боролись на последнем совещании.

Представим пятницу, вечер. Основная площадка работает нестабильно. Нужно решить: продолжать попытки восстановить ее или переключаться на резерв.

Кто принимает это решение? Кто может утвердить большое технологическое окно с остановкой или ограничением части сервисов? Кто скажет: «Переключаемся»? Кто, наоборот, остановит работы, если риск слишком велик? Это не должен быть один человек, который случайно оказался на связи. В принятии решения нужны как минимум представители ИТ и бизнеса. ИТ должно объяснить технические риски, длительность работ и возможные ограничения. Бизнес - оценить последствия для продаж, клиентов, склада, финансов и других функций. При этом решение должно быть коллегиальным, но не бесконечным. Если для переключения требуется собрать совет старейшин, дождаться полнолуния и найти генерального директора на рыбалке, процесс аварийного восстановления уже находится под угрозой.

Технические специалисты восстанавливают системы. Но кто управляет всем процессом? Кто определяет очередность действий, собирает информацию, взаимодействует с бизнесом, контролирует сроки и сообщает руководству, что происходит? В аварии команда не становится автоматически спокойнее, собраннее и мудрее. Наоборот. Люди устают, совершают ошибки, начинают одновременно проверять одно и то же или, наоборот, уверены, что нужное действие уже выполнил кто-то другой. А ключевой архитектор, на которого рассчитывали все, может внезапно сесть в углу, обнять колени и смотреть в одну точку. Стресс - штука непредсказуемая.

Поэтому должны быть заранее определены:

- основной координатор;

- его заместители;

- технические ответственные;

- представители бизнеса;

- каналы связи;

- порядок передачи информации;

- пошаговые протоколы восстановления.

Координатор не обязан лично чинить сервер. Его задача - не дать процессу превратиться в коллективную импровизацию.

Вопрос звучит просто, пока не выясняется, что инструкция лежит на сервере, который только что отключился. Это уже не аварийное восстановление, а квест с плохим сценарием. Инструкция должна быть доступна вне основной инфраструктуры. В ней должны находиться:

- последовательность действий;

- контакты ответственных;

- порядок оповещения;

- критерии переключения;

- необходимые доступы;

- перечень зависимых систем;

- порядок перехода на резервную площадку;

- порядок возврата на основную площадку.

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

6. Кто последний раз проверял инструкцию?

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

Полное переключение действительно может быть дорогим и сложным. Но можно проводить частичные проверки:

— разбирать сценарий на штабной тренировке;

— проверять контакты и роли;

— восстанавливать отдельные системы;

— тестировать резервные копии;

— проверять последовательность действий;

— моделировать недоступность ключевого сотрудника или подрядчика.

Инструкция без регулярной проверки — это исторический роман с элементами фантастики.

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

Полное переключение действительно может быть дорогим и сложным. Но можно проводить частичные проверки:

- разбирать сценарий на штабной тренировке;

- проверять контакты и роли;

- восстанавливать отдельные системы;

- тестировать резервные копии;

- проверять последовательность действий;

- моделировать недоступность ключевого сотрудника или подрядчика.

Инструкция без регулярной проверки - это исторический роман с элементами фантастики.

Допустим, интернет-магазин восстановили. Страница открывается. Кнопки нажимаются. Все рады. Но потом выясняется:

- каталог не обновляется;

- остатки недоступны;

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

- склад не получает задания;

- служба доставки не видит новые заказы.

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

Не по документу. Не по обещанию поставщика. Не по расчету, сделанному четыре года назад. А по результатам последнего полноценного теста. Для каждого критичного процесса нужно определить два показателя:

Определять эти значения бизнес и ИТ должны вместе. Бизнес понимает последствия простоя и потери информации. ИТ понимает, сколько будет стоить выполнение заявленных требований и можно ли их вообще обеспечить на существующей архитектуре. Потому что фраза «восстановите всё за 15 минут и ничего не потеряйте» звучит прекрасно. Примерно до того момента, когда рядом появляется стоимость серверов, систем хранения данных, каналов связи, лицензий, стойко-мест и резервной площадки. Это один из моих любимых моментов при сборе требований.

Спрашиваешь у бизнеса:

- Какое время восстановления вас устроит?

- Ну, минут пятнадцать.

После этого показываешь порядок затрат на инфраструктуру, способную обеспечить эти пятнадцать минут. И внезапно выясняется, что пятнадцать минут были не жестким требованием, а скорее мечтой. Почти новогодней. После нормального обсуждения часто оказывается, что один процесс действительно нужно восстановить за 15–30 минут, другой спокойно переживет два часа, а третий можно поднять через восемь часов или даже на следующий день.

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

Разумеется, такой вывод нельзя делать «на глаз». Для платежей, учета, персональных данных или регуляторной отчетности ручное восстановление может быть невозможным или слишком рискованным. Но именно поэтому требования нужно считать, а не назначать по принципу «чем меньше цифра, тем надежнее».

И здесь снова возникает резервная копия Шрёдингера. Она вроде есть, но пока из нее не восстановили полноценную систему, нельзя точно сказать, спасет она компанию или создаст еще один сюрприз. То же самое относится к плану аварийного восстановления. Пока переключение не проверили, у вас не план, а план аварийного восстановления Шрёдингера: он одновременно существует и не существует. Особенно если последний тест проводился несколько лет назад, а объем данных с тех пор вырос до нескольких петабайт.

Чаще всего восстановление срывает не тот риск, который красиво выделен красным цветом в отчете.

Например:

- на резервной площадке недостаточно вычислительных мощностей;

- канал связи, загруженный на те самые 67 процентов, не справляется с передачей резервных копий;

- у подрядчика закончился договор;

- нужный специалист находится в отпуске без связи;

- права доступа есть только у одного человека;

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

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

Электричество есть. Генераторы работают. Топлива скоро не будет. Вот он, настоящий нежданчик.

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

Ситуацию спасло то, что для другой площадки использовалась вторая обслуживающая компания, которая смогла быстро подключиться к работам. Да, единый подрядчик мог бы дать скидку за объем. Но эта экономия испарилась бы примерно за десять минут простоя основной площадки. Поэтому резервировать иногда нужно не только оборудование, но и каналы, подрядчиков, поставщиков топлива, специалистов, договоры и способы связи.

Пока техническая команда восстанавливает системы, бизнес должен понимать:

- кто и по каким каналам информирует клиентов;

- какие операции можно выполнять вручную;

- кто принимает заказы;

- как фиксируются платежи;

- как работает склад;

- как поддерживается связь с поставщиками;

- кто принимает решение о переходе в ограниченный режим;

- как потом данные из ручных операций будут возвращены в системы.

В этом процессе участвует не только ИТ. Финансы должны знать, как проводить платежи и закрывать период. Продажи - как принимать и фиксировать заказы. Логистика - как собирать и отгружать товар. Административно-хозяйственный блок - как обеспечить помещения, электричество, связь и доступ сотрудников. Служба безопасности - как управлять доступом в изменившемся режиме. Можно восстановить корпоративную учетную систему за два часа, а потом еще сутки ждать человека, который имеет право согласовать платеж.

Технически система восстановлена. Бизнес всё еще стоит. Что должно появиться после такого разговора. После обсуждения должны остаться не ощущения и не фраза «в целом мы готовы», а конкретные результаты:

- карта критичных бизнес-процессов;

- перечень зависимых систем, людей и подрядчиков;

- допустимое время простоя;

- допустимый объем потери данных;

- последовательность восстановления;

- критерии перехода на резервную площадку;

- ответственные и их заместители;

- пошаговые инструкции;

- план оповещения;

- график проверок и тренировок.

Тестировать нужно не только само переключение.

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

Чаще всего угол срезают в четырех местах:

Но если стратегию восстановления начинают придумывать уже во время аварии, это не стратегия. Это импровизация с очень дорогими билетами. Отдельная классика - принимать решение как политический компромисс между ИТ и бизнесом. Кто-то продавил бюджет. Кто-то продавил отказ от проекта. Кто-то победил аргументом «слишком дорого». Цена решения действительно важна. Но без оценки ущерба, рисков и выгод она показывает только половину картины. Дорогой проект может быть неоправданным. Но отказ от него иногда обходится еще дороже.

Собственнику не нужен культ ЦОДа и красивые презентации о том, что всё зарезервировано и соответствует лучшим практикам. Ему нужна уверенность, что компания сможет продолжать работать тогда, когда что-то действительно пойдет не по плану. Ему нужна понятная картина:

- что именно остановится;

- через какое время;

- сколько это будет стоить;

- кто примет решение;

- по какому сценарию пойдет восстановление;

- как компания будет работать, пока ИТ чинит фундамент.

Это уже не разговор про стойки, серверы и системы виртуализации. Это разговор про деньги, управляемость и способность компании пережить плохое утро без героизма, паники и вызова Ктулху.