Что делать
при сбоях критической ИТ-инфраструктуры?

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

1. Опишите самый критичный инцидент, связанный с недоступностью сервисов Яндекса в вашей компании в последнее время. Какие именно процессы встали (браузер, почта, диск, авторизация) и каковы были ваши первые действия, чтобы минимизировать простой бизнеса?
2. Какие неочевидные «костыли», обходные пути или временные технические решения вам пришлось экстренно внедрять, чтобы сотрудники могли продолжать работу во время длительных сбоев?
3. Как вы общаетесь с пользователями и руководством в момент, когда «всё упало» по вине внешнего вендора, а бизнес требует «вернуть как было» прямо сейчас? Какие формулировки или инструкции оказались наиболее эффективными, чтобы снять панику и перевести фокус на конструктив?
4. Заставили ли вас эти инциденты пересмотреть ИТ-архитектуру или политики безопасности компании?
5. Совет себе и коллегам на будущее, как поступать? (Если бы знал, где упадешь, соломки бы подстелил).

На вопросы отвечают эксперты компаний

Иван Вольницыков,
технический директор ООО «СевенПро» (входит в ИТ-бренд «Севен Груп»)

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

1. В нашей компании действует корпоративная подписка на сервисы Яндекс 360. За все время пользования не возникало проблем доступа, которые бы я мог охарактеризовать как критичные. Иногда случались кратковременные сбои в работе отдельных сервисов, но на наших бизнес-процессах они практически не сказывались.

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

Единственный сервис, который у нас полностью встал, был размещен в Яндекс Облаке. Его использовали без согласования с ИТ-службой компании — это пример так называемого Shadow IT. Из-за сбоя в облаке сервис оказался недоступен. Но для нашего бизнеса он не критичен, и мы сможем заменить его на альтернативный.

2. У нас не было длительных простоев.

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

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

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

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

Будьте уверены в своих резервных копиях. Проверяйте и тестируйте бэкапы.

Приоритезируйте информационные системы по влиянию на бизнес.

Задавайте себе вопрос: «Что будет, когда (именно „когда“, а не „если“) система исчезнет на пять минут, час, сутки или насовсем?». Вы должны четко представлять, какими последствиями это обернется для бизнеса и какие шаги вы будете предпринимать для восстановления.

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

Максим Захаренко,
СЕО «Облакотека»

«Единственный способ обеспечить сохранность данных в такой ситуации — это независимое резервирование»

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

Сказал команде: если мы восстановим хоть что-то, это будет чудо. Так вот, на третий день чудо произошло. Коллеги в «Яндексе» что-то восстановили, и бэкап удалось извлечь. Это важный урок: наличие отметки о бэкапе и возможность действительно воспользоваться им — не одно и то же.

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

Проверять нужно весь путь по чек-листу:

• определение периода, за который потеряны последние изменения;
• получение копии;
• развертывание системы;
• возвращение к работе;
• подсчет времени на все процессы.

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

Алексей Чижик,
эксперт, Атрикс

«Когда „всё упало“: как мы пережили сбой Яндекса и что делаем теперь»

Расскажу как есть, без прикрас. Мы — компания, которая живёт в Битрикс24, а Битрикс24 — это облако. Но, помимо этого, вся наша работа была завязана на экосистему Яндекса: проекты, документы, записи встреч, схемы — всё велось там. И когда Яндекс «лёг», я понял, что такое настоящий холодный пот.

Самый жёсткий инцидент — потеря проектной документации. Мы вели всю документацию в Яндекс Вики — это была наша альтернатива сервису Confluence. Схемы, описания процессов, проектная документация — всё там. И когда Вики «лёг», мы не могли даже поставить задачи — потому что вся логика, все схемы, все описания были в Вики. Без них задача — это просто «сделай что-то», а что именно — непонятно. Это был не просто «не работает почта» — это была потеря рабочего инструмента, на котором держалась вся проектная работа.

Что ещё встало? Помимо Вики и почты:

• автоматические рассылки (письма от Яндекса перестали уходить);
• СКУД (отчёты времени у клиентов встали);
• интеграция с Диском по API перестала работать;
• записи встреч в Телемосте;
• сотрудники («не могу открыть документ», «где схема?», «не могу поставить задачу». А бизнес требует: «верни как было, прямо сейчас»).

Первое, что я сделал — убрал панику. Затем собрал команду и сказал: «это не мы сломали, это внешний вендор. Наша задача — не чинить Яндекс, а дать людям работать». И мы начали экстренно искать обходные пути.

Что мы сделали после? Этот опыт мы учли и провели большую работу по восстановлению. Да, это заняло время, были провалы в работе. Но мы не сидели сложа руки.

• почту перевели на альтернативные почтовые серверы. Тем, кто был на коробке Битрикса, заменили главные почты на облака от других провайдеров;
• интеграции — складские системы со СКУД и Битрикс перевели на альтернативные каналы;
• бэкапы — развернули копии локальных бэкапов из разработки. Тут сработала старая привычка разработчика: пара восьмёрок терабайт в резерве для бэкапов локально — хорошая практика. Это нас и спасло: мы были в одной системе.

Где мы сейчас? Честно: до сих пор нет полного доступа к некоторым файлам, нет некоторых схем. Но есть всё, чтобы работать. Что-то работает нестабильно, но мы восстанавливаем и работаем. Мы знаем, что у многих легли облака, в частности 1С, и это случилось в отчётный период. Реклама тоже пострадала: новых лидов нет, потребовалось восстановление, резервные почты, много работы. Но ничего не остановилось слишком сильно.

Как я общался с людьми. Не врал и не обещал «сейчас всё починим» — потому что не мог. Говорил прямо: «Яндекс упал, это не наша вина, мы делаем всё, чтобы вы могли работать. Вот временные решения». И люди успокаивались. Честность и конкретика снимают панику лучше, чем «всё под контролем».

Главный вывод. Мы ещё раз убедились: не держи всё в одном месте или дублируй. Резервные каналы, локальные копии, альтернативные облака. Да, это дороже, но когда бизнес стоит это дороже в разы.

Совет себе и коллегам. Если бы я знал, где упаду, подстелил бы соломку. Но мы не знаем. Поэтому правило простое: критичное — дублируй, резервные каналы — держи под рукой, и не паникуй сам, тогда и команда не запаникует.

Сбой Яндекса — это не «конец света». Это напоминание: инфраструктура — это твоя ответственность, а не «где-то там у провайдера». Готовься заранее и переживёшь любой форс-мажор.

Тимур Рахматуллин,
старший инженер-программист

«Когда люди боятся наказания, они скрывают ошибки. Когда не боятся — рассказывают, что именно пошло не так и почему»

Сбой критической инфраструктуры — это не вопрос «если», а вопрос «когда». За годы работы с высоконагруженными data-системами я вывел несколько правил, которые реально спасают бизнес и нервы команды.

Первые 15 минут решают всё. В MyTona у нас упал Airflow scheduler в пятницу вечером. 200+ DAG’ов встали, аналитика компании ослепла. Спас не героизм дежурного, а runbook — пошаговая инструкция на каждый компонент: Airflow, Kafka, BigQuery. Человек открыл документ, выполнил шаги, поднял scheduler за 12 минут. Без runbook это были бы часы паники и звонков. Runbook должен лежать там, где его найдёт даже новичок в три часа ночи.

Каскадные сбои — главная опасность. Один упавший компонент тянет за собой всю цепочку. Типичный сценарий: в Каfка-кластере теряется лидер — данные копятся в буферах, downstream-системы начинают показывать нули, менеджмент получает пустые дашборды. В Softline Solutions, где мы обслуживаем 1500+ клиентских аккаунтов GCP, мы внедрили подход circuit breaker на уровне данных. Если источник молчит, pipeline не падает с ошибкой, а помечает данные как incomplete и продолжает работу. Бизнес видит пометку «данные неполные» вместо полного отказа. Это даёт время на диагностику без потери остального потока.

Мониторинг — это не про количество алертов. 200 алертов в час — это ноль алертов. Команда перестаёт их читать уже на второй день. Мы в MyTona разделили всё на три уровня. P1 — SMS и звонок дежурному: упал production pipeline, данные не поступают. P2 — Telegram-канал команды: деградация, но система работает. P3 — dashboard для утреннего review. Такая градация сократила время реакции на критические инциденты втрое.

Post-mortem без поиска виноватых. Blameless post-mortem — единственный способ реально улучшить процесс. Когда люди боятся наказания, они скрывают ошибки. Когда не боятся — рассказывают, что именно пошло не так и почему. Мы фиксируем: что произошло, timeline событий, что починило проблему, что надо изменить в системе.

Тренировки disaster recovery. В Softline Solutions мы раз в квартал имитируем сбой: отключаем компонент и засекаем, за сколько минут команда его поднимет. Кто не тренируется — тот в панике при реальном инциденте. После каждой тренировки обновляем runbook.

Готовиться к сбоям нужно в спокойное время. Runbook, градация алертов, circuit breaker, регулярные тренировки — всё это стоит дёшево в сравнении с ночью хаоса на production.

Вячеслав Козн,
владелец ИТ-компании Usertech

«Составьте список процессов, без которых компания не сможет работать уже завтра, и проследите их зависимости до уровня облака, авторизации, DNS и каналов связи»

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

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

Для продаж иногда разумнее временно фиксировать обращения в отдельном реестре, а после восстановления переносить их в CRM с проверкой дублей. Экстренная смена почтового сервиса тоже не всегда мгновенна: обновление DNS-записей может занять время. А вот отключать двухфакторную аутентификацию ради скорости категорически не рекомендую.

В момент аварии руководству нужен понятный статус: что сломалось, на что влияет и что уже работает в обход. Вместо «Яндекс лежит, ждём» лучше сказать: «Часть заявок не поступает в CRM. Включили резервный канал, проверили получение. Следующее обновление дадим через 30 минут». Сотрудникам нужна короткая инструкция с перечнем недоступных операций, альтернативами и контактом ответственного. Регулярные сообщения снижают поток одинаковых вопросов в ИТ-отдел.

После таких ситуаций важно пересмотреть архитектуру. Копия данных в соседней папке того же облака не поможет при недоступности провайдера. Резервные данные стоит хранить независимо от основной платформы, а возможность восстановления регулярно проверять. Для важных систем нужно определить RTO — допустимое время простоя и RPO — допустимый объём потери данных. Это позволяет выбирать резервирование исходя из реальных рисков и затрат. При этом размещение сервисов в разных зонах доступности одного провайдера не гарантирует защиту от масштабной аварии.

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

Максим Невмержицкий,
специалист отдела системного администрирования в компании «DBI»

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

1. Для нас это был не только вопрос доступности облачных ресурсов, но и проверка готовности к аварийному восстановлению одновременно собственной и клиентской инфраструктуры. Часть сервисов оказалась недоступна из-за отказа зоны доступности в Яндекс Облаке. При этом даже в других зонах восстановление ресурсов шло нестабильно, а возможность быстро развернуть дополнительные мощности была ограничена.

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

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

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

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

Второе направление — независимое хранение резервных копий. Мы настраивали репликацию данных из Яндекс Облака во внешнее S3-хранилище другого провайдера. В приоритете были базы данных и вложения критичных сервисов. Параллельно прорабатывали запуск синхронизации с отдельного сервера, чтобы копирование не зависело от работоспособности исходного облака.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ключевые слова: отказоустойчивость, ИТ-инфраструктура, Яндекс, сбой, потеря данных, резервное копирование.

Подпишитесь на журнал

Комментарии могут оставлять только зарегистрированные пользователи