План восстановления после катастрофы для DevOps

Хорошо разработанный план восстановления после бедствий критически важен для снижения рисков, быстрого восстановления после сбоев и обеспечения целостности ваших данных и инфраструктуры.

Существуют ли мифы, связанные с DR в DevOps?

Некоторые организации по-прежнему ошибочно предполагают, что инструменты DevOps, такие как GitHub, GitLab, Bitbucket, Azure DevOps или Jira, имеют встроенное, универсальное восстановление после бедствий. Однако не следует забывать о моделях совместной ответственности, которые четко разъясняют, что, хотя поставщики защищают свою инфраструктуру и бесперебойно запускают свои услуги, пользователи должны защищать свои собственные данные учетной записи. 

Например, давайте посмотрим на цитату из практик безопасности Atlassian:

“Для Bitbucket данные реплицируются в другой регион AWS, и независимые резервные копии создаются ежедневно в каждом регионе. Мы не используем эти резервные копии для отмены разрушительных изменений, инициированных пользователем, таких как поля, перезаписанные с помощью скриптов, или удаленные проблемы, проекты или сайты. Чтобы избежать потери данных, мы рекомендуем регулярно делать резервные копии.”

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

Уникальные проблемы в экосистеме DevOps

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

Экосистемы DevOps всегда имеют сложную архитектуру, такую как взаимосвязанные конвейеры и среды (например, интеграция GitHub и Jira). Таким образом, один сбой, будь то из-за поврежденного артефакта или атаки вымогательского вредоносного ПО, может привести к каскадному эффекту по всей системе. 

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

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

Почему восстановление после катастрофы является неотъемлемой частью DevOps

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

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

Факты и статистика: В 2023 году количество инцидентов, повлиявших на пользователей GitHub, выросло на более чем 21% по сравнению с 2022 годом. Что касается GitLab, около 32% событий были признаны как оказавшие влияние на производительность сервиса и на пользователей. (Статистика взята из отчета о состоянии угроз DevOps).

• Соответствуйте требованиям в области соблюдения и регулирования — например, ISO 20071, GDPR или NIS 2 обязывают организации иметь надежные механизмы защиты данных и их восстановления. Несоблюдение может повлечь за собой крупные штрафы и юридические последствия.

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

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

Лучшие практики по созданию надежного плана аварийного восстановления

Необходимо ли, чтобы ваш план восстановления после катастрофы предвидел любой возможный сценарий катастрофы и предоставил вам и вашей команде все необходимые шаги для быстрого реагирования на случай сбоя? Давайте разберем компоненты эффективного плана восстановления после катастрофы…

Оцените все критические компоненты

Вы должны определить самые критически важные активы DevOps. К ним могут относиться репозитории исходного кода, метаданные, конвейеры CI/CD, артефакты сборки, файлы управления конфигурацией и т. д. Вам нужно знать, какие данные являются приоритетными для восстановления в случае сбоя.

Реализация лучших практик резервного копирования

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

По этой причине ваше решение для резервного копирования должно позволять вам:

• Автоматизировать резервное копирование, запланировав его с наиболее подходящим интервалом между копиями резервных копий, чтобы избежать потери данных в случае сбоя,
• Обеспечить долгосрочное или даже неограниченное хранение, что поможет вам восстанавливать данные из любой точки времени,
• Применить правило 3-2-1 резервного копирования и обеспечить репликацию между всеми хранилищами, чтобы в случае сбоя одного из мест резервного копирования вы могли запустить восстановление из другого,
• Защита от программ-вымогателей, которая включает шифрование AES с вашим собственным ключом шифрования, неизменяемые резервные копии, возможности восстановления и аварийного восстановления (восстановление на момент времени, полное и детализированное восстановление, восстановление на несколько мест назначения, таких как локальная машина, та же или новая учетная запись, или между любыми из GitHub, GitLab, Bitbucket и Azure DevOps).

Определите свои метрики восстановления

Критически важно для организации установить свои измеримые цели, такие как RTO или RPO.

• Recovery Time Objective (RTO) относится к тому, как быстро должны функционировать системы вашей компании после наступления катастрофы. Например, если ваша организация устанавливает свой RTO как 8 часов, то в течение этих 8 часов она должна возобновить свой обычный рабочий процесс после происшествия катастрофы. Обычно, чем ниже RTO, установленное организацией, тем лучше она подготовлена к сбоям.
• Recovery Point Objective (RPO) показывает допустимую потерю данных, измеренную во времени, которое компания может выдержать. Например, если компания легко может обойтись без 3 часов данных, то ее RPO составляет 3 часа. Чем ниже у вас RPO, тем чаще должны выполняться резервные копии вашей организации.

Регулярно тестируйте и проверяйте ваши операции по резервному копированию и восстановлению

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

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

Обучите свою команду

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

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

Изучение случаев применения DRP в DevOps

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

Простои в обслуживании

Крупная цифровая корпорация полностью полагается на GitHub (может быть другой поставщик услуг, такой как GitLab, Atlassian или Azure DevOps). Вдруг компания понимает, что поставщик услуг испытывает простой… однако компании необходимо продолжать свою деятельность как можно быстрее — не забывайте, что средние затраты на простой составляют 9 тыс. долларов в минуту.

Имея комплексный DRP, организация восстанавливает свои данные из последней резервной копии, используя восстановление на определенный момент времени, в GitLab (или Bitbucket или Azure DevOps). Таким образом, организация быстро возобновляет свою деятельность, исключает потерю данных и обеспечивает минимальное время простоя.

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

Человеческая ошибка против простоя инфраструктуры

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

К счастью, DRP организации предвидит такую ситуацию, следуя правилу резервного копирования 3-2-1. Таким образом, ИТ-команда компании запускает резервное копирование из другого хранилища, чтобы обеспечить непрерывность бизнеса.

Атака вымогательского ПО

Средняя по размеру программная компания столкнулась с атакой программ-вымогателей, шифрующей её основные репозитории Git. Успешно внедрив эффективный план восстановления после бедствий (DRP) с автоматизированными резервными копиями и защитными функциями от программ-вымогателей, такими как неизменяемые резервные копии, компания смогла восстановить свои данные с того момента, когда они не были повреждены.

Результат? Компания восстанавливает свою деятельность в течение нескольких часов, избегая многомиллионного выкупа и минимизируя время простоя.

Вывод

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

Стратегия резервного копирования должна стать основой для любого DRP, даже самого требовательного. Таким образом, вы должны иметь возможность:

• Настроить политики резервного копирования для автоматизации процессов резервного копирования в рамках самых строгих RTO и RPO,
• Хранить данные в нескольких местах, соблюдая правило резервного копирования 3-2-1,
• Иметь надежные механизмы защиты от программ-вымогателей,
• Мониторить производительность резервного копирования с помощью аналитических панелей, уведомлений в Slack/email, SLA, отчетов о соответствии и т.д.,
• Проводить тестовые восстановления,
• Восстановить данные в случае любой ошибки, так как решение предусматривает любые сценарии DR и предоставляет надежные возможности восстановления, включая полное восстановление данных, детализированное восстановление, восстановление на момент времени, восстановление на тот же или новый аккаунт, восстановление на вашу локальную инстанцию и
• Обеспечить соблюдение норм и киберустойчивость.