Методология успешного выполнения Synapse: выполнение проверки готовности к работе

Примечание.

Эта статья входит в серию статей, посвященных успешному внедрению Azure Synapse, предпосылки к которому закладываются изначально. Общие сведения о серии см. в статье "Внедрение Azure Synapse — успешно по умолчанию".

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

Приоритетные направления

К приоритетным направлениям относятся операционные цели, готовность решения к работе, безопасность, мониторинг, обеспечения высокого уровня доступности (HA) и аварийного восстановления (DR).

Операционные цели

Задокументируйте ожидания от службы с точки зрения клиента и получите согласие организации относительно этих ожиданий. Внесите необходимые изменения для достижения целей и задач службы.

Соглашение об уровне обслуживания (SLA) каждой службы Azure зависит от службы. Например, корпорация Майкрософт гарантирует определенный ежемесячный процент времени бесперебойной работы. Дополнительные сведения см. на странице Соглашение об уровне обслуживания для Azure Synapse Analytics. Убедитесь, что эти Соглашения об уровне обслуживания соответствуют Соглашениям об уровне обслуживания, действующим в организации, и задокументируйте все разногласия. Кроме того, важно определить любые соглашения операционного уровня (OLA) между разными командами и обеспечить их соответствие Соглашениям об уровне обслуживания.

Готовность решения

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

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

Безопасность

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

• Проверка подлинности. Убедитесь, что проверка подлинности Microsoft Entra используется по возможности. Если используется проверка подлинности, отличной от Майкрософт, убедитесь, что механизмы надежных паролей находятся на месте и что пароли поворачиваются регулярно. Дополнительные сведения см. в документе по использованию паролей. Ведется мониторинг для выявления подозрительных действий, связанных с проверкой подлинности пользователей. Рассмотрите возможность использования Защиты идентификации Azure для автоматизации обнаружения, защиты и исправления рисков, связанных с идентификацией.
• Управление доступом. Имеются надлежащие средства управления доступом, поддерживающие принцип наименьших привилегий. Используйте функции безопасности, доступные в службах Azure, для повышения уровня безопасности решения. Например, Azure Synapse предоставляет детализированные функции безопасности, включая безопасность на уровне строк (RLS), безопасность на уровне столбцов и динамическое маскирование данных. Дополнительные сведения см. в техническом документе по безопасности Azure Synapse Analytics: управление доступом.
• Защита от угроз. Имеются соответствующие механизмы обнаружения угроз, предназначенные для предотвращения, обнаружения угроз и реагирования на них. Для аудита, защиты и мониторинга баз данных в Azure Synapse предусмотрены следующие инструменты: аудит, SQL обнаружение угроз SQL и оценка уязвимостей. Дополнительные сведения см. в техническом документе по безопасности Azure Synapse Analytics: обнаружение угроз.

Дополнительные сведения см. в техническом документе по безопасности Azure Synapse Analytics.

Наблюдение

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

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

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

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

• DWULimit
• DWUUsed
• AdaptiveCacheHitPercent
• AdaptiveCacheUsedPercent
• LocalTempDBUsedPercent
• ActiveQueries
• QueuedQueries

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

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

Высокая доступность

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

Каждая из служб Azure публикует набор рекомендаций и метрик об ожидаемой высокой доступности службы. Убедитесь, что эти метрики высокого уровня доступности соответствуют ожиданиям вашей организации. В противном случае может потребоваться настройка. Например, выделенный пул SQL в Azure Synapse поддерживает восьмичасовую точку RPO с точками автоматического восстановления. Если этой точки RPO недостаточно, в соответствии с вашими потребностями можно настроить определяемые пользователем точки восстановления с соответствующей частотой. Дополнительные сведения см.в статье Резервное копирование и восстановление в выделенном пуле SQL в Azure Synapse.

Аварийное восстановление

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

Используйте встроенные механизмы аварийного восстановления, доступные в службах Azure для создания собственного процесса аварийного восстановления. Например, Azure Synapse выполняет стандартную геоархивацию выделенных пулов SQL раз в день в связанный центр обработки данных. Геоархивацию можно использовать для восстановления после аварии в основном расположении. Можно также настроить Azure Data Lake Storage (ADLS) для копирования данных в другой регион Azure, который находится в значительном удалении. При возникновении аварии в основном расположении можно инициировать отработку отказа для преобразования дополнительного расположения хранилища в основное. Дополнительные сведения см. в статье Аварийное восстановление и отработка отказа учетной записи хранения.

Следующие шаги

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