Восстановление после сбоя RTO/RPO

Критичные ИТ-сервисы с точки зрения бизнеса

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

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

Уровни критичности

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

Например:

• платежный шлюз в банке или ретейле;
• система управления заказами в интернет-магазине;
• CRM, если продажи идут только через неё;
• системы управления производством (SCADA).

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

Например:

• корпоративная почта;
• системы документооборота (СЭД/ECM);
• внутренние порталы и интранет;
• бухгалтерские системы (в день закрытия или подачи отчетности они «переезжают» на уровень выше).

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

Например:

• системы управления персоналом (HRIS) без учёта зарплатных модулей; 
• трекеры задач (Jira, Trello) для компаний, которые не занимаются разработкой ПО (для них это будет критический уровень);
• тестовые среды разработки.

Низкий уровень (некритичные). Экспериментальные проекты, информационные сайты, устаревшие системы в процессе вывода из эксплуатации.

Читайте также

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

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

Примеры:

• экспозиционные и демонстрационные системы;
• стенды для презентаций;
• архивные базы данных.

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

RTO и RPO

Сначала расшифруем эти два термина.

RTO (recovery time objective) задаёт время, необходимое для того, чтобы «поднять» систему после сбоя, а RPO (recovery point objective) — количество данных, которые мы можем позволить себе потерять с момента последнего бэкапа.

В крупных компаниях с высоким уровнем ИТ-культуры эти параметры присваиваются каждой системе и в обязательном порядке согласовываются как с ИТ, так и со стейкхолдерами. По сути, они — это часть SLA, жёстко задающего требования к инфраструктуре и работе ИТ-специалистов и определяющего затраты как на инфраструктуру, так и на FTE (от full time equivalent, необходимое рабочее время и специалистов определённой квалификации), выделяемого для поддержания этих систем.

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

Экономика RTO/RPO. Расчет цены вынужденной остановки работы и потери данных

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

• Упущенная выгода или прямые потери — деньги, которые не «дошли до кассы», потому что система не работала.
• Стоимость «холостого хода» сотрудников. Когда «падает» внутренняя система типа 1С или Active Directory, сотрудники не могут выполнять свои обязанности, но компания всё равно обязана начислять им зарплату.
• Стоимость восстановления системы — денежный эквивалент ресурсов, которые пришлось выделить на восстановление работоспособности системы с учётом ремонта или замены оборудования и трудозатрат специалистов.

Расчет прямых потерь сильно зависит от типа вышедшей из строя системы.

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

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

Читайте также

Российские банки будут блокировать переводы между физлицами

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

С некритичными системами все немного сложнее. Когда не работает почта или внутренний трекер задач — это неудобно, но сотрудники могут найти обходные пути, компенсирующие отсутствие нужного функционала. Поэтому при расчете RТO для них учитывается только часть стоимости времени работы персонала за период устранения последствий инцидента. Например, если почта «лежала» в течение 8 часов, то потери считают не за 8, а только за 0,8 ч (10%), так как система не является критичной для бизнес-процессов компании.

Стоимость потери данных (RPO) иногда может быть намного больше «цены» вынужденной остановки работы, особенно если данные потеряны безвозвратно.

Её считают по-разному в зависимости от типа данных.

• Стоимость воссоздания данных. Если, например, потеряна конструкторская документация (CAD-модели), то сумма определяется количеством часов работы инженеров, которые необходимо потратить, чтобы «нарисовать» её заново.
• Потеря данных закрытых сделок. Если в CRM утеряны данные о контрагентах и истории переговоров за неделю, и менеджеры не знают, кому звонить, чтобы восстановить их, то часть сделок «умрет» навсегда. Если же система не функционировала в течение одного-двух часов, то есть шанс, что они смогут избежать потерь, по старинке используя Excel или заметки.
• Регуляторные риски. Потеря персональных данных или финансовой отчетности (ФЗ-152) может грозить серьезными штрафами, вплоть до оборотных.

Зависимости и «скрытые узкие места»: что мешает восстановлению чаще всего

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

Другим узким местом становятся недокументированные изменения в системе или её окружении, особенно когда речь идёт о внутренних или «самописных», а не коробочных решениях. Часто оказывается, что восстанавливать надо то, что создавалось разработчиками, которые уже недоступны, а дежурный администратор или DevOps-инженер просто не обладают необходимыми знаниями для восстановления системы и устранения причин сбоя. Сюда же относится и несогласованная перенастройка сетевых правил или ИБ-политик, влияющих на взаимодействие между компонентами системы или с сопряженными системами.

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

Что касается проблем, возникающих по причине своевременно не продлённой лицензии, то 90% вендоров помогают справиться с таким кризисом в течение буквально пары часов. А вот просроченные сертификаты могут сильно испортить жизнь, так как, приводя к полному или частичному отказу системы, они часто оказываются трудно диагностируемыми. Это довольно регулярно случается у наших банков и даже международных ИТ-гигантов. Вспомните хотя бы Meta, у которой по всей планете перестали работать устройства Oculus из-за одного просроченного сертификата — эту проблему решали целых 48 часов.

Сценарии восстановления при различных инцидентах

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

Все начинается с подготовки и наличия правильно выстроенной инфраструктуры.

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

Не менее важно не пренебрегать DevOps- и DevSecOps-практиками, так как если система под постоянным мониторингом и её можно быстро развернуть через CI/CD из собственного контейнера вместе с окружением — это сильно упрощает восстановление. Наличие должного резервирования внутри ЦОД (резервные каналы связи) и резервного ЦОДа позволяет сделать падение и восстановление системы почти незаметным для пользователя.

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

Читайте также

Рынок российских ПАКов 2026: новая инфраструктурная норма

ПАКи в России превращаются из технологического тренда в базовый элемент инфраструктуры — с опорой на регуляторику и запрос на управляемость ИТ-среды. В обзоре IT-World — как устроен этот рынок, где он растет быстрее всего и какие вендоры и решения уже задают его контуры.

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

Кто командует восстановлением и по каким каналам

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

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

Как протестировать способность к быстрому восстановлению и убедиться в отсутствии «дыр»

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

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

Наблюдаемость и время обнаружения угрозы

По сути, любая система критического или высокого уровня для бизнеса должна не просто мониториться с точки зрения «железа» (нагрузка на процессор/память/диск), но и иметь собственные метрики, набор так называемых healthcheck-параметров. Эти данные система должна с определенной периодичностью передавать в средства мониторинга или предоставлять по их запросу, вместе с любого типа ошибками из своих логов.

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

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

* * *

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