«Все время терпит неудачу». - Вернер Фогельс

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

В этой статье вы найдете десять действенных методов защиты ваших самых ценных ресурсов.

1. Резервное копирование, резервное копирование, резервное копирование

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

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

RPO против RTO

Целевая точка восстановления (RPO) описывает, сколько часов простоя мы можем выдержать. RPO равное 10 означает, что ваш бизнес может позволить себе потерю данных не более десяти часов в соответствии с вашим планом обеспечения непрерывности бизнеса. Вы можете думать о RPO с точки зрения «устаревания» резервной копии плюс время восстановления. При RPO = 10 мы позволяем нашим данным быть устаревшими на десять часов после восстановления (то есть не содержать изменений, внесенных в течение последних десяти часов).

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

2. Проверьте свой сценарий восстановления.

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

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

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

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

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

3. Документирование процессов, основанных на этих данных (база)

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

4. Примените принцип безопасности с наименьшими привилегиями.

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

Кроме того, рекомендуется регулярно проверять эти разрешения. Возможно, кто-то, кто ушел из компании, все еще имеет доступ к производственным ресурсам.

5. Назовите свою производственную базу данных соответствующим образом.

Что, если ваша производственная база данных не указана как prod ресурс и кто-то перепутает ее с чем-то другим? Лучше всего использовать правильные названия производственных ресурсов, чтобы люди, глядя на ресурс, знали, что к нему нужно относиться с большой осторожностью.

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

6. Не доверяйте никаким ресурсам, настроенным вручную

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

7. Не позволяйте одному человеку управлять всей инфраструктурой.

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

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

8. Расскажите своим сотрудникам о любом ресурсе, прежде чем предоставлять им к нему доступ.

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

Как всегда, эффективное общение - наш лучший друг.

9. Бессерверное использование и мониторинг своих ресурсов.

Использование хранилищ данных, таких как AWS RDS, - это здорово, но у него есть обратная сторона. В конце концов, мы по-прежнему несем ответственность за то, чтобы наша база данных оставалась работоспособной. При использовании бессерверных хранилищ данных, таких как DynamoDB, мы можем полагаться на экспертов AWS DevOps для мониторинга и поддержания работоспособности базовых серверов.

Если вы используете платформу наблюдения, такую ​​как Dashbird, вы можете быстро идентифицировать неправильно настроенные ресурсы или сбои в вашей бессерверной инфраструктуре. Dashbird недавно выпустил функцию под названием Well-Architected-Lens, которая постоянно сканирует ваши ресурсы на предмет аномалий. Например, он предупредит вас о любой таблице DynamoDB, для которой не включено непрерывное резервное копирование и восстановление на определенный момент времени. Это один из самых простых способов обеспечить работоспособность и отказоустойчивость вашего хранилища данных, потому что:

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

На изображении ниже вы можете видеть, что Dashbird автоматически обнаружил, что резервное копирование не включено:

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

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

10. По возможности отделите хранилище от компьютера.

Этот момент связан с аналитическими базами данных. Это хорошая практика в хранилищах аналитических данных, чтобы ваши вычисления и хранилище были независимыми друг от друга. Представьте, что ваши данные надежно хранятся в объектном хранилище, таком как S3, и вы можете запрашивать их с помощью бессерверного механизма, такого как AWS Athena или Presto. Разделение того, как хранятся ваши данные и как они запрашиваются, упрощает обеспечение устойчивости вашей аналитической инфраструктуры.

Вы можете установить автоматическую репликацию между бакетами S3, включить управление версиями (что позволяет восстанавливать удаленные ресурсы) или даже запретить кому-либо перезаписывать или удалять что-либо из S3, используя блокировки объектов. Затем, даже если ваше определение таблицы Athena будет удалено, ваши данные сохранятся, и их можно будет легко запросить по определению схемы в AWS Glue.

Я большой поклонник хранения необработанных извлеченных данных для целей ETL в хранилище объектов перед их загрузкой в ​​любую базу данных. Это позволяет использовать его в качестве промежуточной области или озера данных и обеспечивает большую отказоустойчивость аналитических конвейеров. Соединения с реляционной базой данных хрупкие. Представьте, что вы загружаете большие объемы данных из некоторой исходной системы прямо в хранилище данных. Затем, незадолго до завершения задания ETL, происходит сбой, поскольку соединение было принудительно закрыто удаленным хостом из-за некоторых сетевых проблем. Необходимость повторять этап извлечения может создать дополнительную нагрузку на исходную систему или может быть даже невозможна из-за ограничений на запросы API.

Заключение

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

Ссылки и ресурсы