Новости о дата-центрах Яндекса заставили многих разбираться с отказоустойчивостью прямо во время аварии. При мне в Алматы случился блэкаут, после которого концерт Канье перестал идти по первоначальному плану. Выступление 14 августа 2026 года перенесли на следующий день: среди причин называли перебои электричества и непогоду. А один из сбоев Cloudflare пришелся прямо перед демо моего OSS-проекта.

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

Если ты недавно работаешь проджектом, в такой момент легко решить, что сейчас от тебя требуется стать одновременно CTO, спасателем и человеком с ответами на все вопросы. Я бы предложил другую задачу: помочь команде разобраться в происходящем, получить нужные решения и сохранить связь с людьми, которые зависят от проекта.

Этому можно учиться заранее. Причем начать получится без доступа к продакшену и бюджета на второе облако.

Сначала договоримся, что называем катастрофой

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

Например, заболел тестировщик. Можно перенести задачи, найти замену, пересмотреть релиз. Теперь представь, что недоступна вся команда или целиком потерян доступ к инфраструктуре. Вопрос уже не в том, сколько дней добавить в график, а в том, есть ли у нас способ продолжить работу.

Катастрофические сценарии можно и нужно учитывать в управлении рисками. Тот же ИСО который я зубрил в универе ISO 31000 не ограничивает его мелкими неприятностями. Но запись в реестре сама по себе не назначает руководителя восстановления, не создает резерв и не объясняет поддержке, что говорить клиентам.

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

Полезный майндсет: любопытство вместо обязанности все знать

Начинающему PM полезнее научиться уточнять, чем изображать уверенность. На фразу «у нас все зарезервировано» можно спокойно ответить: «Помоги разобраться, от каких отказов это защищает и когда мы последний раз проверяли восстановление?» Ответ конечно может огорчить, но да ладно)

Это не экзамен для инженера. Начни с объяснения своей задачи: ты хочешь правильно оценивать сроки, понимать ограничения и не обещать клиентам невозможное. Не обязательно заходить с позиции «я прочитал статью (или вероятнее мне ИИ подсказал) и сейчас найду, что у вас сделано неправильно».

Я бы держал в голове несколько привычек:

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

2. Оставлять неизвестное неизвестным. «Срок восстановления пока не подтвержден» нормально написать в статусе. Хорошо сразу добавить, кто его уточняет и когда вернется с обновлением. Не стоит заменять пробел оптимистичной оценкой, чтобы на встрече стало спокойнее.

3. Отделять решение от предположения. «Должно переключиться» и «переключилось на учениях» требуют разного уровня уверенности. Я бы прямо отмечал: проверено, только описано, неизвестно. Это рабочие состояния, а не оценки качества людей.

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

До кризиса: начни с одной операции пользователя

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

Попроси технического лида пройти ее вместе с тобой:

Пользователь открывает приложение -> входит -> создает заказ -> оплачивает -> получает подтверждение.

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

Вместо попытки угадать конкретную причину предложи состояние: «Платежи недоступны сутки» или «Основное облако недоступно неделю». Обсудите, что продолжит работать, что придется остановить и кому станет хуже первым.

Для первого разговора хватит небольшой таблицы:

Это стартовая схема обсуждения, не универсальное распределение должностей.

Такой анализ называют Business Impact Analysis, рекомендую погуглить или спросить ИИ что это и как делается.

Как обсуждать резерв с CTO без конфликта

Представим: почти все работает у одного провайдера. Независимое восстановление не проверено. Ты поднимаешь вопрос, а CTO объясняет, что второй контур сейчас слишком дорогой.

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

Мне нравится формулировка:

Я не предлагаю прямо сейчас покупать второе облако. Хочу понять, что мы обещаем бизнесу при длительном отказе первого. Давайте сравним минимальные варианты защиты и зафиксируем решение.

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

Например, с платежами, в условном проекте:

У нас один эквайер. При его отказе новые оплаты остановятся. Второй канал требует договора, интеграции, проверки и дальнейшей поддержки. Даже демостенды могут выдаваться сутки.

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

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

Отказаться от резерва иногда разумно. Неясность насчет последствий лучше не оставлять частью этого решения.

Есть классная книжка Orange Book, руководстве британского госсектора по управлению рисками, осознанное сохранение риска прямо предусмотрено. https://www.gov.uk/government/publications/orange-book/the-orange-book-management-of-risk-principles-and-concepts Скорми ее условному NotebookLM и попроси объяснить как оно работает на пальцах. Будет очень полезно.

Что записать после обсуждения

Я бы составил короткую запись: какой сценарий рассматриваем; что теряем; какие варианты оценили; что выбрали; кто утвердил; как действуем при аварии; когда пересматриваем. Что-то похожее на ADR, но скорее просто обычное решение.

Письменное подтверждение нужно для общей памяти. Через несколько месяцев состав команды, оборот и обязательства могут измениться. Фраза «все были в курсе» не поможет восстановить договоренность.

Если выбран сценарий ожидания провайдера, тоже нужен порядок действий. Кто уведомляет клиентов? Кто получает новости? Какие операции приостановлены? Чем занимаются остальные? После какой длительности простоя решение нужно пересмотреть?

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

Когда авария случилась: помоги людям понять, что делать дальше

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

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

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

Как сообщать плохие новости без лишней тревоги

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

Условный пример для внутреннего канала:

С 12:10 не проходят новые оплаты. Уже созданные заказы доступны. Состояние платежей без подтверждения проверяем.

Технический лид координирует восстановление с провайдером. Подтвержденного срока пока нет. Поддержка уведомляет клиентов.

Сегодняшний релиз приостановлен решением руководителя. Следующее обновление в 13:00, даже если новых сведений не появится.

Внешний текст нужно согласовать с ответственными за клиентскую коммуникацию. Не все подробности внутреннего обсуждения полезны пользователю.

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

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

Если кризис затянулся, попроси организовать смены и передачу контекста. От тебя не требуется быть доступным бесконечно. Договориться о подмене тоже часть заботы о работе.

Шесть зависимостей, которые стоит обсудить с командой

Я бы использовал этот список как начало разговора, не как требование немедленно все продублировать. У каждого пункта нужны владелец, понятный сценарий отказа и способ проверить готовность.

Домен, DNS и сертификаты

Домен нужен пользователю, чтобы найти сервис; DNS помогает определить адрес, сертификат участвует в проверке защищенного подключения. Спроси, кто управляет этими вещами и сохранится ли доступ при отказе основного поставщика.

У ответа «поменяем DNS» есть детали. Например, Cloudflare предупреждает: при прямом подключении пользователей к серверу сертификат Origin CA может не вызывать доверия браузера. Значит, альтернативный маршрут нужно проверять вместе с сертификатами, а не только с адресом.

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

Платежи

Есть ли второй банк или эквайер? Проверена ли интеграция? Кто решает переключаться? Что увидит пользователь?

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

Связь с пользователями и командой

Где публикуем статус, если приложение и основной сайт недоступны? Можно ли попасть в этот канал без отказавшей корпоративной авторизации? Где лежат контакты нужных людей?

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

Серверы и средства восстановления

Есть ли доступная мощность на резервной площадке? Или только аккаунт и надежда заказать ее во время аварии? Можно ли получить конфигурации, образы приложения, ключи и инструменты развертывания без основного облака?

Два размещения стоит проверять на общие зависимости: авторизацию, управление, сеть, обновления. У Microsoft в failure mode analysis разбираются зависимости и распространение отказов. Начинающему PM я бы предложил читать этот материал вместе с картой своей критической операции.

Данные и резервные копии

Спроси, когда последний раз восстанавливали копию, кто это делал и что получилось. Доступна ли она без основного провайдера? Есть ли ключи? Сколько последних изменений можно потерять?

У GitLab в аварии 2017 года обнаружились проблемы с механизмами восстановления. Вернуть базу помог снимок, подготовленный для другой среды; в разборе компания указала на отсутствие ясного владельца регулярной проверки backup-процедуры. Это конкретный исторический случай, не описание нынешнего GitLab. Вообще очень крутой посмотмортем

https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/.

Новости от поставщиков

Кому приходит письмо о блокировке аккаунта, проблемах с оплатой или изменении условий? Кто увидит его, если человек в отпуске? Как сообщение попадет к тем, кто может действовать?

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

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

Начать учения можно с разговора за столом

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

Пройдите первый час такой ситуации. Кто ее обнаружит? Кого вызовут? Где соберутся? Кто примет решение о резерве? Какой текст получат клиенты? Что произойдет, если основной технический лид недоступен?

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

Следующий уровень -> техническое упражнение вместе с инженерами: развернуть критическую функцию из доступных копий, проверить данные, переключение и возврат. A

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

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

После настоящей аварии стоит отдельно проверить зависшие операции и очереди. Затем провести постмортем, разбор произошедшего: восстановить хронологию, понять, что затруднило работу, и назначить исправления. У Google есть материал о разборе без поиска козла отпущения. Это не отменяет ответственности за выполнение последующих действий, он простейший https://sre.google/sre-book/postmortem-culture/.

Что почитать: от понятных историй к рабочим руководствам

Я бы не начинал с попытки осилить все стандарты. Лучше выбрать одну книгу, один разбор аварии и одну практическую задачу. Спроси ChatGPT и сам выбери что подходит. Можно начать с классики Проект феникс https://flibusta.su/book/9211-proekt-feniks-roman-o-tom-kak-devops-menyaet-biznes-k-luchshemu/.

Что самостоятельно поковырять с Claude Code или Codex

Я бы использовал ИИ как помощника в учебном эксперименте. Пусть объясняет команды, помогает собрать маленький стенд и задает вопросы. Вывод о готовности рабочей инфраструктуры оставим людям, которые ее знают и вправе проверять.

Упражнение 1. Сделать копию и вернуть приложение из нее

Я начинающий PM. Помоги провести учебный эксперимент
в отдельной папке pm-recovery-lab. Сначала уточни мою ОС
и проверь наличие Python. Ничего не устанавливай без согласия.

Сделай маленькое локальное приложение на стандартной
библиотеке Python с SQLite и вымышленными заказами.
Оно должно слушать только 127.0.0.1. Никаких внешних API.

Проведи меня по этапам, не выполняя все сразу:
1. Создаем 10 заказов и проверяем их через приложение.
2. Делаем согласованную копию через SQLite backup API.
3. Создаем еще 2 заказа после копирования.
4. Останавливаем приложение. Основную базу переименовываем,
   не удаляем. Все действия только внутри учебной папки.
5. Восстанавливаем копию в отдельный каталог и запускаем
   приложение с восстановленной базой.
6. Проверяем сохраненные заказы и возможность создать новый.

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

В конце объясни, какие заказы сохранились и почему.
Измерь время пройденного восстановления и перечисли,
что этот эксперимент не проверяет в настоящем облаке.

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

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

Упражнение 2. Сам обсуди с ИИ чего ты не понимаешь и что еще стоит пощупать руками на примере упражения 1.

Вместо резюме

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