Процесс надежности — это пошаговый процесс, в котором каждый этап строится на предыдущем этапе, чтобы обеспечить доступность систем и удовлетворения ожиданий пользователей. Эта модель зрелости предназначена для оценки текущего состояния и предоставления структурированного пути для улучшения.
Начальная установка базовых возможностей надежности, предлагаемых Azure, осуществляется через такие встроенные функции надежности, как избыточность по зонам, для немедленного улучшения без значительных затрат на оптимизацию.
Парадоксально, но для достижения высокой надежности необходимо принять тот факт, что сбои неизбежны. Вместо того чтобы попытаться предотвратить каждую проблему, более эффективно спланировать, как ваша система будет реагировать при возникновении проблем. Ваши бизнес-требования помогают определить, какие риски стоит упреждать. Команды инвестируют в расширенные системы мониторинга с использованием структурированной наблюдаемости, расширяют меры по устранению сбоев, чтобы включать проблемы на уровне приложений, и начинают тестировать меры устойчивости.
Затем команды интегрируют бизнес-аналитику с техническими навыками. Команды внедряют моделирование работоспособности, анализ видов и последствий отказов, а также подготовка комплексных планов аварийного восстановления. На этом этапе обеспечивается подотчетность с помощью измеримых целей и систематической подготовки к различным сценариям сбоя.
После того как система работает, акцент переходит к управлению проблемами рабочих сред, включая управление изменениями и работу с ростом данных и операционной сложностью, а также тем, как они влияют на надежность вашей системы.
Финальный уровень работает неограниченное время, и его цель - сохранять устойчивость. Этот уровень представляет собой переход от технического контроля к архитектурной адаптивности. Этот уровень фокусируется на том, чтобы системы могли противостоять новым и непредвиденным рискам по мере развития и роста рабочих нагрузок.
Модель структурирована на пяти отдельных уровнях зрелости, каждая из которых имеет основную цель и набор основных стратегий. Используйте приведенные ниже вкладки, чтобы изучить каждый уровень. Не забудьте также проверить выделенные компромиссы и связанные риски по ходу выполнения.
Установите прочную основу для устойчивости в инфраструктуре и операциях под нагрузкой, вместо того чтобы уделять время задачам оптимизации.
Уровень 1 модели зрелости предназначен для того, чтобы помочь командам, работающим с нагрузками, создать прочные основы надежности системы. Основное внимание уделяется процессу "bootstrap", который представляет собой этап настройки базовых элементов для принятия будущих решений о надежности. Этот этап в основном включает в себя функциональную реализацию с небольшими расширениями в текущие практики.
Этот этап включает исследования, получение аналитических сведений и создание инвентаризации ваших систем. Он также использует встроенные функции надежности в Azure, такие как включение зональной избыточности для немедленного повышения надежности.
Установив эти основы, вы можете подготовить свою команду к повышению уровня надежности модели зрелости, чтобы постепенно повысить устойчивость и производительность системы.
Ключевые стратегии
✓ Оценка возможностей для разгрузки операционной ответственности
Эта стратегия принципиально представляет собой подход: строить или покупать или полагаться. Решение зависит от того, сколько ответственности можно принять на себя на этом этапе, при этом поддерживая будущее развитие. Вы хотите использовать ресурсы, относящиеся к рабочей нагрузке, но всегда следует изучить возможности для разгрузки их обслуживания. Ниже приведены некоторые классические варианты использования, в которых может потребоваться применить этот подход.
Передайте ответственность на облачную платформу, выбрав платформу как услугу (PaaS). Они предоставляют готовые решения для распространенных задач устойчивости, таких как репликация, переключение при отказе и хранилища резервных копий. При таком подходе поставщик облачных служб отвечает за размещение, обслуживание и повышение устойчивости.
Например, поставщик облачных служб реплицирует данные по нескольким вычислительным узлам и распределяет реплики между зонами доступности. При создании собственного решения на виртуальных машинах необходимо самостоятельно управлять этими аспектами, которые могут быть трудоемкими и сложными.
Переложить обязанности для операций, которые не связаны напрямую с бизнес-целями нагрузки. Некоторые специализированные операции, такие как управление базами данных и безопасность, могут повлиять на надежность рабочей нагрузки. Изучите возможность работы с опытными командами, технологиями или обеими задачами.
Например, если у вашей команды нет опыта работы с базой данных, используйте управляемые службы, чтобы помочь переключить ответственность на поставщика. Этот подход может быть полезен при запуске, так как он позволяет команде сосредоточиться на функциональных возможностях рабочей нагрузки. Многие предприятия совместно используют централизованно управляемые службы. Если команды платформы доступны, используйте их для обработки этих операций. Однако этот подход может добавить зависимости и сложность организации.
Кроме того, если у вашей команды есть правильный опыт, вы можете принять явное решение использовать свои навыки и выбрать службы, которые не включают возможности управления.
Передайте обязанности поставщикам, не относящимся к компании Майкрософт. Выберите продукты вне полки в качестве отправной точки. Создавайте настраиваемые решения только в том случае, если они способствуют ценности вашей рабочей нагрузки.
Риск: Если вариант покупки или полагаться на частично соответствует вашим требованиям, может потребоваться реализовать пользовательские расширения. Этот метод может привести к "блокировке настройки", когда обновления и модернизация становятся нецелесообразными. Регулярно просматривайте свои требования и сравнивайте их с возможностями решения. Разработайте стратегию выхода, когда между ними существует значительное отклонение.
Противоположный сценарий также является риском. Хотя вариант покупки или использования может оказаться проще сначала, он может потребовать повторной оценки и перепроектирования позже, если ограничения службы PaaS, решения поставщика или ресурсов, принадлежащих платформе, не соответствуют необходимой детализации или уровню автономии, необходимой для рабочей нагрузки.
✓ Определение критически важных потоков пользователей и системных потоков
Разрыв рабочей нагрузки на потоки имеет решающее значение на этом этапе. Сосредоточьтесь на потоках пользователей и систем . Потоки пользователей определяют взаимодействие пользователей, а системные потоки определяют взаимодействие между компонентами рабочей нагрузки, которые не связаны напрямую с задачами пользователей.
Например, в приложении электронной коммерции клиенты выполняют внешние действия, такие как просмотр и заказ. Между тем внутренние транзакции и системные процессы выполняют запросы пользователей и обрабатывают другие задачи. Эти отдельные потоки являются частью одной системы, но они включают разные компоненты и служат различным целям.
На этом этапе начните создавать каталог потоков. Наблюдайте за взаимодействием пользователей и взаимодействием с компонентами. Создайте список и классифицируйте потоки, определите их начальные и конечные точки, и учтите зависимости. Документируйте результаты и исключения с помощью схем для ясности. Этот каталог может служить важным инструментом для первоначального диалога с заинтересованными лицами бизнеса, чтобы определить наиболее важные аспекты с их точки зрения. Эта беседа может информировать первый уровень приоритезации.
Классифицируйте поток как критически важный путем оценки риска и влияния на основные бизнес-действия. Если вы ожидаете прерывание, то плавная деградация сосредоточена на поддержании этих критически важных потоков. В примере электронной коммерции критически важные потоки включают поиск продуктов, добавление элементов в корзину и получение, так как эти задачи важны для бизнеса. Другие процессы, такие как обновление данных продукта и обслуживание образов продуктов, не так важны. Убедитесь, что критические потоки остаются в рабочем состоянии во время сбоя, чтобы предотвратить потерю доходов, позволяя пользователям продолжать поиск продуктов и добавлять элементы в корзину.
Замечание
Бизнес-процесс может быть критически важным, даже если он не учитывает время. Критическое значение времени является ключевым фактором. Например, выполнение требований аудита имеет критически важное значение, но вам может не потребоваться сразу представлять данные для аудита. Процесс остается важным, но его своевременность не является критичной, так как восстановление в течение нескольких часов приемлемо.
Дополнительные сведения см. в статье Azure Well-Architected Framework: оптимизация проектирования рабочей нагрузки с помощью потоков.
✓ Выберите правильную модель проектирования, ресурсы и функции
Эту стратегию следует применить на следующих уровнях:
Архитектура: Проектирование рабочей нагрузки должно учитывать ожидания надежности на различных уровнях инфраструктуры. Ваши первоначальные решения могут быть выбором между контейнеризацией или PaaS для размещения приложения. Кроме того, вы можете рассмотреть такие сетевые настройки, как концентратор и периферийный сервер или одна виртуальная сеть.
Необходимо также задать границы, которые создают сегментацию на основе функциональных возможностей. Например, вместо размещения всего на одной виртуальной машине с одним зонным виртуальным диском рекомендуется разделить вычислительные ресурсы и хранилище данных и использовать выделенные службы.
Осторожность
В сценариях миграции принятие подхода "lift-and-shift" без рассмотрения новых возможностей может привести к упущенным преимуществам и неэффективности. Важно исследовать модернизацию на ранних стадиях, чтобы избежать сложности с конфигурациями, которые трудно изменить, и воспользоваться преимуществами лучших вариантов и улучшений.
Службы Azure: Используйте деревья принятия решений, чтобы помочь вам выбрать нужные службы для проектирования. Выберите компоненты, которые соответствуют текущим потребностям, но остаются гибкими, чтобы вы могли переключать службы по мере развития рабочей нагрузки и требовать дополнительных функций.
Номера SKU или уровни в службах Azure: Просмотрите функции каждого номера SKU и изучите гарантии доступности платформы. Чтобы понять охват, предоставляемый в контексте опубликованного процентиля, изучите соглашения об уровне обслуживания.
Функции, поддерживающие надежность: Выберите облачные службы для повышения доступности с помощью простых конфигураций без изменения кода. Важно понимать параметры и намеренно выбирать конфигурации, такие как увеличение избыточности зоны или репликация данных в дополнительный регион.
✓ Используйте базовый уровень избыточности при развертывании
В каждой части решения избегайте единственных точек отказа, таких как одиночные экземпляры. Создайте несколько экземпляров для повышения надежности вместо этого. Сервисы Azure часто берут на себя обеспечение избыточности, особенно это касается PaaS-сервисов, которые, как правило, включают локальную избыточность по умолчанию и предоставляют возможности обновления. Предпочтительно использовать резервирование зоны для размещения этих экземпляров в нескольких центрах обработки данных Azure. Если вы этого не сделаете, по крайней мере обеспечьте локальную избыточность, но этот метод сопряжён с более высокими рисками. В будущих уровнях вы оцениваете, могут ли выполняться требования к надежности, расширяя решение с помощью геоизбыточного компонента.
Компромисс: Одним из значительных компромиссов является увеличение затрат на избыточность. Кроме того, взаимодействие между зонами может привести к задержке. Для устаревших приложений, требующих минимальной задержки, избыточность может снизить производительность.
Риск: Если приложение не предназначено для среды с несколькими экземплярами, оно может бороться с несколькими активными экземплярами, что может привести к несогласованным данным. Кроме того, если приложение создано для локальной установки с низкой задержкой, использование зон доступности может нарушить его производительность.
✓ Включение метрик, журналов и трассировок для мониторинга потоков
Выберите собственные инструменты платформы, такие как Azure Monitor, чтобы обеспечить видимость метрик, журналов и трассировок. Используйте встроенные функции для задания оповещений для потенциальных проблем. Для отправки уведомлений и получения оповещений необходимо иметь базовое оповещение. Воспользуйтесь преимуществами возможностей платформы Azure, которые указывают на изменения состояния работоспособности служб, например:
Настройте группы действий Azure Monitor для инфраструктуры и приложения.
Компромисс: При сборе дополнительных журналов необходимо управлять увеличением объема, что влияет на затраты, связанные с хранилищем этих журналов. Используйте политики хранения для управления объемом. Используйте Azure Monitor, чтобы задать ежедневное ограничение в рабочей области. Дополнительные сведения см. в рекомендациях по настройке для надежности.
Для начала создайте наблюдаемость на следующих уровнях.
Инфраструктура
Сначала включите журналы диагностики и убедитесь, что вы собираете собственные метрики из компонентов платформы для анализа. Сбор сведений об использовании ресурсов, таких как ЦП, память, входные и выходные данные и сетевое действие.
Заявление
Сбор метрик на уровне приложения, таких как потребление памяти или задержка запросов, и журналирование деятельности приложения. Выполняйте операции ведения журнала в потоке или процессе, отдельном от основного потока приложения. Этот подход не приводит к тому, что ведение журнала замедляет выполнение основных задач приложения.
Кроме того, проверьте базовые тесты доступности в Application Insights.
Данные
Чтобы отслеживать базы данных на базовом уровне, соберите ключевые метрики, которые выдают ресурсы базы данных. Аналогично компонентам инфраструктуры, отслеживайте использование ресурсов в контексте хранилищ данных, таких как сетевые метрики. Сбор данных о том, как соединения объединяются в пул, важны для повышения эффективности на последующих этапах.
Для надежности важно отслеживать метрики подключения, такие как мониторинг активных и неудачных подключений. Например, в Azure Cosmos DB возвращается код состояния 429, когда число запросов превышает выделенные единицы запросов и подключения начинают завершаться ошибкой.
✓ Начало создания сборника схем устранения сбоев
Сбои варьируются от периодических до незначительно продолжительных временных и катастрофических отключений.
На уровне 1 сосредоточьтесь на сбоях платформы. Несмотря на то, что они выходят за рамки вашего контроля, у вас по-прежнему должны быть стратегии для их обработки. Например, устраняйте неполадки в зонах с помощью зон доступности. Предвидите временные ошибки на уровне платформы и обработайте их в рабочей нагрузке.
Процесс обработки этих сбоев зависит от сложности. Начните документирование потенциальных сбоев на уровне платформы, связанных с ними рисков и стратегий устранения рисков. Это упражнение является главным образом теоретическим и созревает с автоматизацией на более поздних уровнях.
Следует документировать сбои, включая факторы, такие как их вероятность, влияние и стратегии устранения рисков. Используйте масштаб критичности, соответствующий целям рабочей нагрузки. Ваше масштабирование может включать:
Высоко. Полный сбой системы, который приводит к значительной финансовой потере и снижению доверия пользователей.
Средняя. Временное нарушение, которое влияет на часть рабочей нагрузки и приводит к неудобствам пользователей.
Низко. Небольшая проблема с программным обеспечением, которая влияет на невенсиальную функцию приложения и приводит к минимальному простою для пользователей.
Ниже приведен пример шаблона:
| Проблема |
Риск |
Исходный материал |
Степень серьезности |
Вероятность |
Смягчение последствий |
| Временный сбой сети |
Клиент теряет подключение к серверу приложений. |
Платформа Azure |
Высоко |
Очень вероятно |
Используйте шаблоны проектирования в логике на стороне клиента, например логику повторных попыток и средства разбиения цепи. |
| Сбой в зоне |
Пользователь не может связаться с приложением. |
Платформа Azure |
Высоко |
Маловероятный |
Включите устойчивость зоны для всех компонентов. |
| Окончание срока действия сертификата TLS |
Клиент не может установить сеанс TLS с приложением. |
Ошибка из-за действий человека |
Высоко |
Вероятно |
Используйте автоматическое управление сертификатами TLS. |
| Использование ЦП или памяти достигает определенных ограничений и приводит к сбою сервера. |
Истекло время ожидания запросов. |
Заявление |
Средний |
Вероятно |
Реализуйте автоматические перезапуски. |
| Компонент недоступен во время обновления. |
Пользователь испытывает необработанную ошибку в приложении. |
Развертывание или изменение конфигурации |
Низкий уровень |
Высокая вероятность во время развертывания и маловероятно в другое время |
Обработка компонентов в логике на стороне клиента. |
На уровне 1 не стремитесь к полноте, потому что всегда существуют непредвиденные случаи сбоя. При непредвиденных сбоях задокументируйте причины и устранение рисков в сборнике схем. Этот ресурс рассматривается как живой документ, который вы обновляете с течением времени.
✓ Добавление механизмов для восстановления после временных сбоев
В облачной среде временные сбои распространены. Они указывают на краткосрочные проблемы, которые обычно можно решить повторными попытками в течение нескольких секунд.
Используйте встроенные пакеты SDK и конфигурации для обработки этих ошибок для поддержания активности системы. Встроенные конфигурации часто являются параметром по умолчанию, поэтому может потребоваться проверить реализацию. Кроме того, реализуйте шаблоны, предназначенные для обработки временных сбоев в архитектуре. Дополнительные сведения см. в шаблонах проектирования архитектуры, поддерживающих надежность.
Сохраняющиеся проблемы могут указывать на сбой, который не является временным или началом сбоя. В этом сценарии требуется больше, чем просто исправление локализованных проблем в приложении. Он включает изучение критически важных пользовательских потоков и потоков системы и добавление методов самосохранения и мероприятий по восстановлению. Методы, характеризуемые уровнем 2, являются зрелыми практиками.
✓ Запуск базовых тестов
Интеграция базового тестирования надежности на ранних этапах жизненного цикла разработки программного обеспечения. Найдите возможности для тестирования, начиная с модульных тестов для проверки функциональности и конфигурации.
Кроме того, разработайте простые тестовые случаи для проблем, которые вы определяете в сборнике схем по устранению рисков. Сосредоточьтесь на более высоком влиянии, снижении усилий по устранению рисков. Например, смоделируйте проблемы с сетевыми сбоями или периодическими проблемами подключения, чтобы узнать, как логика повторных попыток устраняет нарушения.
Риск: Тестирование часто приводит к трению в цикле разработки. Чтобы устранить этот риск, сделайте тестирование надежности отслеживаемым вместе с задачами разработки.
Разработка функций является приоритетом, и тестирование может привести к трению в цикле разработки. Проще начать тестирование до завершения разработки компонентов. Проектирование нефункциональных аспектов приложения в начале позволяет расширить их при добавлении функциональных возможностей, а не создавать невыполненные задачи для дальнейшего решения. Хотя этот подход требует больше усилий изначально, он управляется и предотвращает более крупные проблемы позже.
гарантирует, что система остается функциональной и стабильной, включив возможности самосохранения и имея базовый план восстановления для управления сбоями.
Сбои в облаке неизбежны. Стратегии устойчивости должны стремиться к поддержанию функционирования системы во всех условиях. Уровень 1 содержит методы для решения временных сбоев. Уровень 2 посвящен включению стратегий самосохранения для предотвращения, обнаружения и восстановления после длительных сбоев. Если они останутся неразрешёнными, эти проблемы могут привести к полным сбоям.
Критически важные потоки, которые вы определяете на уровне 1, принимают приоритет. Они требуют повышения устойчивости и восстановления для всех компонентов, включая приложения, службы и базы данных. Следует настроить начальные настройки, количество экземпляров вычислений и политики автомасштабирования для уменьшения рисков отказа.
На этом уровне целенаправленно отслеживайте и тестируйте практики. Используйте расширенные методы мониторинга, которые соответствуют техническим потребностям и ориентированы на команды разработчиков. Расширьте простые директивы, чтобы включить архитектурные компоненты, которые вы разрабатываете и которыми управляете, такие как код приложения.
Ключевые стратегии
✓ Оцените текущее состояние устойчивости для защиты от сбоев
Достаточно ли уровень избыточности, чтобы выдержать сбои? Определите стратегию избыточности, указывающую количество избыточных ресурсов для обслуживания. Определите, где размещать эти ресурсы, будь то локально, между зонами или в географически распределенных расположениях. Оцените параметры облачной платформы и выберите уровень, соответствующий бизнес-потребностям и приемлемым компромиссам.
Достаточно ли изолированы компоненты рабочей нагрузки, чтобы локализовать их сбои? Такие шаблоны, как шаблон отсеков, помогают создавать устойчивость и изолировать сбои. Шаблон "Переборка" разделяет систему на изолированные компоненты, известные как переборки, чтобы предотвратить распространение сбоев на другие части системы.
Взаимодействуют ли компоненты на критическом пути асинхронно? В противном случае используйте методы связи, такие как очереди. Такой подход обеспечивает работу системы, даже если нижестоящий компонент откажет. Она также запрещает системе вводить неопределенное состояние. Ознакомьтесь с параметрами Azure, включая служебную шину Azure для очередей и Центров событий Azure для потоков событий.
Компромисс: Асинхронное взаимодействие может помочь предотвратить каскадные сбои путем развязывания процессов. Однако она добавляет задержку в пути связи, которая может представлять проблему для критически важных компонентов. Оцените влияние на производительность перед внесением изменений в шаблон проектирования.
Предназначены ли операции для согласованности? Ресурсы, такие как секреты приложений и сертификаты, могут истекть и требовать регулярного обновления. Несоответствия в стандартных обновлениях могут привести к проблемам надежности.
В идеале определите и исключите текущие задачи, управляемые человеком, так как они подвержены ошибкам и могут привести к несоответствиям, которые представляют риски надежности. Выгрузите максимальное количество операционных задач поставщику облачных служб. Например, используйте управляемые удостоверения, которые предоставляет идентификатор Microsoft Entra ID и сертификаты TLS, управляемые Azure Front Door.
Мониторинг необходим для упреждающих мер, таких как отслеживание срока действия сертификата и получение уведомлений. Приложение должно регистрировать важные события, такие как сертификат TLS, приближающийся к истечении срока действия. Использование нескольких методов для проверки потенциальных сбоев помогает обеспечить выполнение необходимых действий.
✓ Добавление технических возможностей в систему мониторинга
На уровне 1 вы собрали данные мониторинга из компонентов рабочей нагрузки с акцентом на инфраструктуре. Базовый анализ завершен и заданы базовые оповещения. Эта настройка необходима для понимания базовой производительности компонентов рабочей нагрузки и выявления аномального поведения.
Уровень 2 выполняет мониторинг дальше, добавив расширенные возможности наблюдения в ресурсы рабочей нагрузки и применяя более структурированный подход к анализу данных мониторинга. Воспользуйтесь преимуществами средств аналитики, которые предоставляет облачная служба. Например, инструменты аналитики Azure Monitor, такие как аналитика виртуальных машин и аналитика сети, предоставляют визуализации работоспособности и производительности всех зависимостей.
Планирование возможностей наблюдения на следующих уровнях.
Заявление
Реагирование на проверку состояния работоспособности. Разрешить приложению реагировать на запросы проверки работоспособности от зондов. Приложение должно иметь выделенные конечные точки для проверок исправности, которые предоставляют сведения о состоянии, такие как исправность или неисправность, как минимум. Такой подход позволяет системам мониторинга оценивать, правильно ли функционирует приложение и способно обрабатывать запросы, или есть проблемы, которые необходимо устранить.
Службы балансировки нагрузки Azure, такие как Azure Front Door, диспетчер трафика Azure, шлюз приложений Azure и Azure Load Balancer, поддерживают пробы работоспособности. Мониторы работоспособности отправляют запросы проверки состояния приложениям.
Перейдите к семантике ведения журнала. Включите структурированные сведения о событиях и действиях в приложении. С структурированным ведением журнала данные журнала записываются в согласованном формате с помощью четко определенной схемы. Эта схема упрощает создание автоматизации, поиска и анализа на более поздних этапах. Включите определенные поля, такие как метки времени и коды ошибок, чтобы быстро определить и устранить проблемы.
Реализуйте распределенную трассировку. Когда запрос проходит через различные компоненты системы, важно записывать данные трассировки по границам. Эти данные полезны для получения аналитических сведений о поведении приложений и выявлении узких мест производительности, ошибок и проблем с задержкой. Azure Monitor поддерживает сбор данных на основе OpenTelemetry с помощью Application Insights.
Данные
Отслеживайте длительность запроса, неудачные запросы и другие соответствующие метрики. Длительные запросы могут указывать на ограничения ресурсов и, возможно, необходимость в настройке структуры схемы.
На этом этапе база данных уже некоторое время работает. Обратите внимание на темп роста данных, особенно в таблицах, которые неожиданно быстро растут. Эта информация важна для планирования будущих потребностей в хранении данных и решения проблем с производительностью на ранней стадии.
Отслеживайте состояние репликации базы данных с помощью средств и панелей мониторинга, предоставляемых системой управления базами данных. Например, если вы используете Azure Cosmos DB, используйте аналитику Azure Cosmos DB. Для Базы данных SQL Azure или Управляемого экземпляра SQL Azure рекомендуется использовать наблюдатель за базами данных, чтобы получить диагностические сведения о базах данных.
По мере роста базы данных проблемы схемы могут стать более очевидными, что влияет на производительность. Чтобы оптимизировать эффективность запросов, попробуйте добавить индексы или изменить схему, так как эти изменения могут повлиять на надежность.
Операции
Уровень 1 фокусируется на предыдущих слоях. На уровне 2 вы начинаете формировать операционные процессы вокруг системы мониторинга.
Сохраняйте журналы достаточно долго, чтобы получить аналитические сведения. С точки зрения надежности настройте длительность хранения, чтобы можно было собирать достаточно данных для обнаружения шаблонов сбоев, устранения неполадок и выполнения анализа первопричин.
Мониторинг процессов резервного копирования и восстановления. Убедитесь, что резервные копии успешно хранятся в планируемых местоположениях, а данные рабочей нагрузки восстанавливаются в разумные сроки. Мониторинг этих процессов важен для настройки базовых показателей для целевых показателей точки восстановления (RPO) на более поздних уровнях.
✓ Расширение сборника схем устранения сбоев
Уровень 1 фокусируется на ожидаемых сбоях платформы. На уровне 2 вы устраняете точки сбоя компонентов и операций в рамках собственной рабочей нагрузки. По мере запуска кода на платформе точки взаимодействия между платформой и приложением увеличиваются. Ожидайте сбоев от ошибок в коде, неудачных развертываний и человеческих ошибок. Устранение этих проблем с помощью тактики самосохранения или восстановления.
Расширьте сборник схем устранения сбоев, чтобы включить ошибки и проблемы с развертыванием. Следующая таблица основана на шаблоне на уровне 1.
| Проблема |
Риск |
Исходный материал |
Степень серьезности |
Вероятность |
Смягчение последствий |
| Код не обрабатывает по крайней мере однократную доставку сообщений. |
Повторная обработка сообщений из шины приводит к повреждению данных. |
Заявление |
Высоко |
Вероятно |
— переработка с использованием секционирования шины и внедрением идемпотентности в процесс.
— Отойти от конкурирующих моделей потребителей, что делает производительность компромиссом. |
| Скрипт ежедневного резервного копирования не выполняется. |
Нарушение RPO происходит, потому что данные устарели более чем на 24 часа. |
Автоматизированный процесс |
Высоко |
Маловероятный |
Настройте оповещение о процессе резервного копирования. |
| Регулярное использование и всплески активности после выхода новой версии. |
Производительность приложения снижается и время ожидания запросов пользователей. |
Заявление |
Высоко |
Маловероятный |
Настройте операции горизонтального масштабирования на основе расписания. |
| Ошибка параллелизма находится в коде. |
Непредсказуемое поведение и возможное повреждение данных. |
Заявление |
Высоко |
Вероятно |
Используйте безопасные формы параллелизма и избегайте ручной обработки элементов управления параллелизмом. |
| Непредвиденный сбой во время развертывания оставляет среду в несогласованном состоянии. |
Сбой приложения. |
Цепочки развертывания |
Средний |
Вероятно |
Используйте сине-зеленые развертывания, канареечные развертывания или другие подходы к постепенному развертыванию изменений. |
Это упражнение может стать чрезмерным, если вы пытаетесь учесть все возможные ошибки. Чтобы упростить работу, сосредоточьтесь на компонентах, входящих в критически важные потоки пользователей. Этот живой документ продолжает развиваться по мере совершенствования рабочих процессов.
✓ Разработка базового плана восстановления
Сборник схем устранения сбоев является основой для создания базового плана восстановления. Стратегии устранения рисков могут включать реализацию шаблона проектирования, корректировку конфигурации платформы, управление инцидентами в реальном времени, автоматизированные тесты и обучающий персонал для обнаружения проблем во время проверок кода.
Начните со стратегии постепенной деградации, которая включает и временные исправления, когда части системы не работают должным образом. Цель заключается в том, чтобы продолжать обслуживать пользователей, несмотря на сбои, отключив нерабочие части и изменив взаимодействие с пользователем. Например, если база данных отключена, приложение может отключить затронутую функцию и сообщить клиентам, что служба временно недоступна с помощью кодов состояния HTTP.
Для корректного снижения производительности изолируйте системные компоненты, чтобы только затронутые части столкнулись с проблемами, а остальные компоненты продолжают функционировать. Используйте шаблон bulkhead для обеспечения изоляции сбоя.
Воспользуйтесь этой возможностью пересмотреть варианты проектирования, которые могут замедлить восстановление. Например, направление записей системы доменных имен (DNS) непосредственно на ваше приложение в сервисе App Service Azure может привести к задержкам во время восстановления из-за задержки распространения DNS. Используйте выделенную службу, например Azure Front Door, в качестве точки входящего трафика, чтобы упростить перенастройку во время восстановления.
Ожидается, что этот базовый план будет развиваться в полный план аварийного восстановления на более зрелых уровнях.
✓ Создание планов тестирования
Создайте тестовые планы путем имитации сбоев и проблем, выявленных в сборнике схем по устранению рисков. Дополните эти меры предотвращения с помощью простых тестов, чтобы обеспечить их работу должным образом и являются осуществимыми. Убедитесь, что эти функции работают правильно, и проведите тесты деградации, чтобы узнать, как система работает в случае отказа определенных компонентов. Оставьте результат простым, убедившись в том, что тест либо завершается ошибкой, либо проходит успешно.
Используйте такие средства тестирования, как макетирование платформ для внедрения ошибок в HTTP-запросы, которые помогают тестировать политики повторных попыток более явным образом. Azure Chaos Studio предоставляет комплексный набор тестов для имитации сбоев компонентов и других проблем, что делает ее ценной службой для изучения. Вы можете постепенно внедрять Chaos Studio по мере того, как вы ознакомитесь с её функциями.
✓ Оценка влияния операций масштабирования на надежность
Для обработки пиков нагрузки критически важные компоненты должны эффективно масштабироваться горизонтально или вертикально. Воспользуйтесь преимуществами автомасштабирования, которые предоставляет Azure. Эти возможности настраивают ограничения емкости службы на основе предопределенных конфигураций. Эта корректировка позволяет масштабировать службу вверх или вниз по мере необходимости.
Определите потенциальные узкие места и понять риски, которые они могут представлять. Например, высокая пропускная способность не должна привести к разрыву потока.
Поймите шаблоны загрузки. Статические модели использования могут сделать узкие места менее критичными, но изменения в динамике использования и потребления могут усугубить риски.
Замечание
Могут быть компоненты, которые не могут масштабироваться, например монолитные базы данных и устаревшие приложения. Заранее отслеживайте кривую нагрузки, чтобы обеспечить повторное проектирование при необходимости.
Определите ограничения масштабирования, которые являются разумными на основе требований к производительности и надежности. Для проблем с производительностью постепенное увеличение масштаба является наиболее распространенным. Однако для критически важных потоков может потребоваться более быстрое масштабирование, чтобы избежать сбоев. В любом случае избегайте бесконечного масштабирования.
Риск: При работе с проблемами, связанными с производительностью, масштабирование может быть полезной стратегией устранения неполадок. Однако масштабирование — это временное исправление, а не решение. Изучите и решите основную проблему, например утечку памяти или неконтролируемый процесс. В противном случае вы рискуете снова применить ту же минимизацию рисков в другой критической точке и платить за ресурсы, которые вам не нужны. Обращаясь к первопричине, вы можете обеспечить долгосрочную стабильность и эффективность затрат.
задает цели надежности и целевые показатели для обеспечения ответственности команды в процедурах восстановления.
На ранних уровнях ваши команды сосредоточены на простых победах и основных возможностях. Они начинают с небольших улучшений, решая простые проблемы для создания надежной основы, в основном опираясь на возможности надежности Azure. По мере роста команд они сталкиваются с более техническими проблемами, связанными с собственными ресурсами и процессами.
На уровне 3 команды должны интегрировать бизнес-аналитику и технические навыки для планирования восстановления. Они устанавливают цели и планируют процессы восстановления с помощью расширенного мониторинга. Этот подход помогает инженерам надежности сайта (SREs) быстро удовлетворять целевые показатели надежности.
Ключевые стратегии
Цели надежности помогают настроить подотчетность для команд, занимающихся нагрузками. Важно иметь совместную беседу с бизнес-заинтересованными лицами, чтобы обсудить время восстановления и затраты, а также сделать компромиссы, которые соответствуют бизнес-целям. Соберите заинтересованных лиц и проводите эту дискуссию в качестве семинара. Рассмотрим следующие моменты повестки дня семинара:
Объясните метрики, лежащие в основе целей. Начните с объяснения ключевых метрик, используемых для определения целей, таких как цели уровня обслуживания, цели времени восстановления (ОСРВ) и цели точки восстановления (RPOS). Узнайте, как эти метрики соответствуют бизнес-целям. Сосредоточьтесь на критически важных потоках пользователей. Например, в приложении электронной коммерции RTO для обновления предпочтений электронной почты менее важен, чем выполнение пользователями процесса оформления заказа.
Обмен данными о компромиссах. Заинтересованные лица часто ожидают больше, чем то, что можно достичь. Объясните, как расширение области влияет на бюджет, операционные требования и производительность.
Предложить целевые цели. Основываясь на архитектурном опыте и проектировании рабочих нагрузок, рекомендуется устанавливать целевые показатели, такие как 99,9% времени доступности, при этом RPO и RTO устанавливаются в четыре часа. Организуйте обсуждение для заинтересованных сторон, чтобы они могли предоставить обратную связь и внести изменения. Убедитесь, что как бизнес,так и технические заинтересованные лица защищены от нереалистических ожиданий. Подходите к обсуждениям с настроем на сотрудничество.
Достичь консенсуса или решения. Стремитесь к консенсусу, но если это невозможно, пусть лицо, принимающее решения, определит цели для обеспечения прогресса.
✓ Упреждающий мониторинг с помощью модели работоспособности
На уровне 1 данные мониторинга собираются из компонентов рабочей нагрузки, включая службы платформы и приложения. Базовый анализ и оповещения устанавливаются для установления базовой производительности и выявления аномалий. На уровне 2 фокус перемещается на получение данных о наблюдаемости из компонентов рабочей нагрузки, таких как код приложения.
Уровень 3 улучшает мониторинг путем добавления бизнес-контекста в критически важные потоки и определения здоровых, неработоспособных и пониженных состояний с помощью моделирования работоспособности. Соглашение заинтересованных лиц необходимо для определения приемлемых компромиссов взаимодействия с пользователем и должно использоваться в качестве входных данных для определения состояний работоспособности.
Моделирование состояния требует операционной зрелости и опыта в средствах мониторинга. Команда проверяет необработанные данные, уровни производительности и журналы для создания пользовательских метрик и пороговых значений, определяющих состояние работоспособности потока. Они должны понять, как эти значения связаны с общей работоспособностью системы. Сообщите о четких определениях и пороговых значениях заинтересованным лицам.
Визуализируйте модель работоспособности на дашбордах, чтобы помочь SREs быстро определить проблемы, фокусируясь на нездоровых или деградировавших потоках.
Модель работоспособности определяет состояние приложения и критически важные потоки. Зеленый цвет указывает, что все критически важные потоки работают должным образом. Красный указывает на сбой. И желтый цвет показывает тенденции к проблемам. Итерация версий модели здоровья обеспечивает надежность и точность, но требует значительных усилий для крупных приложений.
Изменение состояния работоспособности должно быть настроено в качестве оповещений. Тем не менее, чтобы оповещения оставались необходимыми, необходимо учитывать важность компонента.
Дополнительные сведения см. в разделе Well-Architected Framework: моделирование состояния здоровья.
✓ Настройка оповещений, доступных для действий
Чтобы повысить эффективность реагирования, четко определите оповещения и предоставьте достаточно информации для быстрого действия. Подробные имена оповещений и описания могут сэкономить время и усилия во время устранения неполадок. Тщательно настройте серьезность, имя и описание с особым вниманием к уровням серьезности. Не каждое событие является чрезвычайным ситуацией. Тщательно оцените уровни серьезности и установите критерии для каждого уровня, например, всплеск ЦП с 80% до 90% квалифицируется как чрезвычайная ситуация. Задайте соответствующие пороговые значения, чтобы обеспечить эффективное определение оповещений.
Эффективное управление оповещениями гарантирует, что оповещения уведомляют нужных людей в нужное время. Частые и разрушительные оповещения указывают на необходимость корректировки и могут стать контрпродуктивными, когда они игнорируются. Уменьшите ненужные уведомления, задав соответствующие пороговые значения для фильтрации ложных предупреждений. Определите возможности, в которых автоматизация может активировать операционные процедуры.
Создайте одну целевую страницу с необходимой информацией для эффективного устранения неполадок оповещений. Этот подход экономит время по сравнению с входом на портал Azure и поиск метрик. Если встроенные функции Azure Monitor не полностью соответствуют вашим потребностям, рассмотрите возможность разработки пользовательской панели мониторинга.
✓ Проведение анализа режимов отказов
На предыдущих уровнях вы создали простой сборник схем устранения сбоев для отдельных компонентов. На этом уровне преобразуйте этот набор стратегий в формальное упражнение по анализу видов и последствий отказов (FMEA). Целью этого упражнения является упреждающее определение потенциальных режимов сбоя.
FMA предполагает обнаружение потенциальных точек сбоя в нагрузке системы и планирование мер по снижению рисков, таких как самовосстановление или аварийное восстановление (DR). Чтобы начать, отслеживайте увеличение частоты ошибок и выявляйте влияние на критические потоки. Используйте прошлые опыты и тестовые данные для выявления потенциальных сбоев и оценки радиуса взрыва. Приоритизируйте основные проблемы, такие как сбой по всему региону.
Важно классифицировать действия как предотвращающие или реактивные. Действия по предотвращению определяют риски, прежде чем они вызывают сбой, что снижает их вероятность или серьезность. Реактивные действия нацелены на решение проблем, чтобы улучшить состояние работоспособности или предотвратить сбой.
В примере приложения электронной коммерции команда по управлению нагрузкой хочет провести FMA, чтобы подготовить себя к крупному событию. Одним из ключевых потоков пользователей является добавление элементов в корзину. Компоненты, входящие в поток, включают фронтенд, CartAPI, ProductCatalogAPI, UserProfileAPI, PricingAPI, Azure Cosmos DB и Azure Event Hubs.
| Проблема |
Риск |
Потенциальный источник |
Степень серьезности |
Вероятность |
Действия |
| Число полученных заказов падает до уровня ниже 100 в час, при этом не наблюдается соответствующего снижения активности пользовательских сессий. |
Клиенты не могут размещать заказы, даже если приложение доступно. |
CartAPI, PaymentsAPI |
Высоко |
Маловероятный |
Реактивные действия:
— Просмотрите модель работоспособности или данные мониторинга, чтобы определить проблему.
— протестируйте приложение для проверки его функциональности.
— Если происходит сбой компонента, выполните переключение на резервный комплект инфраструктуры.
Действия по предотвращению:
— Разместите искусственные заказы, чтобы убедиться, что поток работает.
— улучшение наблюдаемости, чтобы обеспечить мониторинг сквозного потока. |
| Неожиданное увеличение нагрузки приводит к истечении времени ожидания при хранении заказов в Azure Cosmos DB |
Клиенты не могут размещать заказы или получать неудовлетворительную производительность, если они могут размещать заказы. |
Azure Cosmos DB (облачная база данных) |
Высоко |
Маловероятный |
Реактивные действия:
— проверка нагрузки на основе телеметрии приложения.
— Временно масштабируйте единицы запросов Azure Cosmos DB.
Действия по предотвращению:
— Настройка автомасштабирования.
— пересмотр ожидаемой нагрузки и пересчет правил масштабирования.
— Переместите некоторые действия в фоновый процесс, чтобы уменьшить нагрузку базы данных из этого потока. |
| Служба рекомендаций полностью отключена |
Страница корзины покупок не загружается из-за исключения, вызывающего службу рекомендаций. |
Заявление |
Средний |
Маловероятный |
Реактивные действия:
— Реализуйте правильную стратегию снижения, чтобы отключить функциональные возможности рекомендаций или отобразить жестко закодированные данные рекомендаций на странице корзины покупок. При оценке службы применяйте этот подход при возникновении исключения. |
| Периодические тайм-ауты возникают при доступе к API ценообразования со страницы корзины покупок при высокой нагрузке. |
Периодические сбои происходят на странице корзины покупок из-за сбоев доступа к службе корзины. |
Заявление |
Средний |
Вероятно (под высокой нагрузкой) |
Реактивные действия:
— Реализуйте ценовую стоимость кэша в хранилище данных корзины покупок вместе с меткой времени истечения срока действия кэша.
— Доступ к API ценообразования только в том случае, если истек срок действия кэша данных о ценах. |
FMA является сложным и может занять много времени, поэтому постепенно развивайте свой анализ. Этот процесс является итеративным и продолжает развиваться на более поздних этапах.
Дополнительные сведения см. в рекомендациях RE:03 по выполнению FMA.
✓ Подготовка плана аварийного восстановления
На уровне 2 вы создали план восстановления, ориентированный на технические элементы управления для восстановления системных функций. Однако для аварии требуется более широкий подход из-за катастрофической потери или сбоя. Планы аварийного восстановления основаны на процессах. Они охватывают обмен данными, подробные этапы восстановления и потенциально включают технические артефакты, такие как скрипты.
Во-первых, определите типы инцидентов для планирования, такие как сбои в работе регионов, сбои на уровне всей платформы Azure, нарушения инфраструктуры, повреждение базы данных и атаки программ-вымогателей. Затем разработайте стратегии восстановления для каждого сценария и убедитесь, что механизмы установлены для восстановления операций. Бизнес-требования, ОСРВ и RPO должны направлять планы аварийного восстановления. Для небольших ОСРВ и RPO требуются явные автоматизированные процессы, а более высокие ОСРВ и RPO позволяют использовать более простые методы восстановления и проводить ручной анализ.
DR в основном включает следующие действия:
Уведомите ответственных сторон. Важно иметь ясность о том, кто должен включать и когда. Убедитесь, что ваша команда использует правильные процессы, имеет правильные разрешения и понимает свои роли в восстановлении. Некоторые обязанности, такие как отчет генерального директора рынку или соблюдение нормативных требований, должны быть определены на раннем этапе.
В идеале у вас должны быть отдельные роли восстановления и коммуникации, и назначьте разных людей для каждой роли. Изначально ИТ-специалист, который обнаруживает проблему, может справиться с обеими ролями. Но по мере эскалации ситуации высокопоставленный персонал может справиться с техническим восстановлением, а бизнес-человек управляет коммуникациями.
Принятие бизнес-решений. Во время катастрофы уровень стресса может быть высоким, что делает четкие решения важными. Хорошо структурированный план аварийного восстановления требует непрерывных обсуждений между технической командой и заинтересованными лицами бизнеса для определения предварительных вариантов принятия решений. Например, рассмотрите, должны ли ресурсы рабочей нагрузки работать в одном регионе Azure, а резервные копии храниться в другом регионе, или следует заранее подготовить активы IaC для создания новых ресурсов или восстановления из резервной копии при отказе.
Действия, принятые в соответствии с планами аварийного восстановления, могут быть разрушительными или иметь значительные побочные эффекты. Важно понять варианты, взвесить свои плюсы и минусы, и определить подходящее время для их применения. Например, оцените, требуется ли восстановление в другом регионе, если основной регион, как ожидается, будет работать в течение приемлемого периода времени.
Восстановление системных операций. Во время аварии основное внимание должно уделяться восстановлению операций, а не выявлению причины. Для технического восстановления, особенно в регионе переключения отказа, заранее определите подходы, такие как активный-активный, активный-пассивный, горячий резерв или холодный резерв.
Подготовьте определенные шаги восстановления на основе выбранного подхода. Начните с конкретного списка шагов по восстановлению операций. По мере развития процесса необходимо определить план аварийного восстановления как скрипт с минимальным взаимодействием вручную. Используйте управление версиями и безопасно храните скрипт для простого доступа. Этот подход требует больше предварительных усилий, но сводит к минимуму стресс во время фактического инцидента.
Дополнительные сведения см. в разделе "Развертывание в активно-пассивном режиме" для аварийного восстановления.
Проведение анализа после инцидента. Определите причину инцидента и найдите способы его предотвращения в будущем. Внесите изменения для улучшения процессов восстановления. Это упражнение также может выявить новые стратегии. Например, если система переключилась на вторичную среду, определите, требуется ли основная среда и каким должен быть процесс возврата на основную среду.
План аварийного восстановления (DR) — это живой документ, который адаптируется к изменениям в ваших рабочих процессах. Обновите план аварийного восстановления по мере появления новых компонентов и рисков. Уточнение плана на основе полученных сведений, полученных из учений или реальных катастроф, путем сбора точной информации от операторов резервного копирования и восстановления.
Контролируйте риски, связанные с техническими и операционными изменениями, и определяйте приоритеты в управлении инцидентами.
На предыдущих уровнях команда рабочей нагрузки фокусируется на создании функций и обеспечении работоспособности системы. На уровне 4 фокус смещается на обеспечение надежности системы в эксплуатации. Управление инцидентами становится столь важным, как обеспечение тщательного тестирования и безопасного развертывания любых изменений, чтобы избежать нестабильной системы.
Этот процесс требует улучшения операционных элементов управления, таких как инвестиции в выделенные команды для управления инцидентами надежности. Он также требует технических средств управления для повышения надежности системы за пределами критически важных компонентов, усиленных на предыдущих уровнях. Так как система продолжает работать в рабочей среде, рост данных может потребовать изменения, такие как секционирование, чтобы обеспечить надежный доступ и обслуживание.
Ключевые стратегии
✓ Надежное управление изменениями
Самые большие риски надежности возникают во время изменений, таких как обновления программного обеспечения, корректировки конфигурации или изменения процессов. Эти события являются критически важными с точки зрения надежности. Цель заключается в том, чтобы свести к минимуму вероятность проблем, сбоев, простоев или потери данных. Для каждого типа изменений требуются конкретные действия для эффективного управления уникальными рисками.
На уровне 4 надежность пересекается с безопасными методиками развертывания, описанными в разделе "Операционный превосходство", при сохранении стабильной среды при управлении изменениями. Надежное управление изменениями — это требование для обеспечения стабильности рабочей нагрузки. Рассмотрим следующие ключевые аспекты:
Реагировать на обновления платформы. Службы Azure имеют различные механизмы обновления служб.
Ознакомьтесь с процессами обслуживания и обновите политики каждой используемой службы. Узнайте, поддерживает ли служба автоматическое или ручное обновление и период времени для обновлений вручную.
Для служб, для которых обновления запланированы, эффективно управляйте процессом их обновления, планируя их на наименее загруженное время. Избегайте автоматических обновлений и откладывайте их до тех пор, пока вы не оцените риск. Некоторые службы позволяют контролировать время, а другие службы предоставляют льготный период. Например, с помощью службы Azure Kubernetes (AKS) у вас есть 90 дней, прежде чем обновление станет автоматическим. Тестирование обновлений в непроизводном кластере, который зеркально отражает рабочую настройку, чтобы предотвратить регрессию.
Постепенно применять обновления. Даже если тестирование показывает, что обновление безопасно, применение его ко всем экземплярам одновременно может быть рискованным. Вместо этого обновите несколько экземпляров одновременно и подождите между каждым набором.
Регулярно проверяйте уведомления об обновлениях, которые могут быть доступны в журналах действий или других каналах, относящихся к службе.
Отслеживайте внезапные или постепенные изменения после применения обновления. В идеале ваша модель здоровья должна уведомлять вас об этих изменениях.
Тщательное тестирование с помощью автоматизации. Интегрируйте большее количество тестов в ваши конвейеры сборки и развертывания, когда вы внедряете изменения. Найдите возможности преобразования ручных процессов в автоматизированные части конвейеров.
Выполните комплексное тестирование с помощью сочетания различных типов тестов на различных этапах, чтобы убедиться, что изменения работают должным образом и не влияют на другие части приложения. Например, позитивное тестирование может подтвердить, что система работает должным образом. Он должен проверить, нет ошибок и правильность потоков трафика.
При планировании обновлений определите шлюзы тестирования и типы применяемых тестов. Большинство тестов должно выполняться на этапах предварительного развертывания, но тесты дыма также должны выполняться в каждой среде при обновлении.
Следуйте рекомендациям по безопасному развертыванию. Используйте топологии развертывания, включающие окна проверки и методики безопасного развертывания. Реализуйте шаблоны безопасного развертывания, такие как канареарные и зеленые развертывания, чтобы повысить гибкость и надежность.
Например, в канареечных развертываниях небольшое подмножество пользователей получает новую версию в первую очередь. Этот процесс обеспечивает мониторинг и проверку перед развертыванием всей пользовательской базы. Такие методы, как флаги функций и темные запуски, упрощают тестирование в рабочей среде перед выпуском изменений для всех пользователей.
Обновите план аварийного восстановления. Регулярно обновляйте план аварийного восстановления, чтобы обеспечить его актуальность и эффективность. Избегайте устаревших инструкций. Этот подход гарантирует, что план отражает текущее состояние вашей системы, развернутой в рабочей среде, и используемой пользователями. Включение уроков, извлеченных из учений и реальных инцидентов.
Дополнительные сведения см. на уровне 4 операционного превосходства
✓ Инвестируйте в выделенную команду для обработки инцидентов
Изначально команда разработчиков может принимать участие при возникновении инцидентов. На уровне 4 инвестировать в инженерию надежности сайта (SRE) для управления инцидентами. SREs специализируется на производственных проблемах и являются экспертами в области эффективности, управления изменениями, мониторинга, реагирования на чрезвычайные ситуации и управления емкостью. Опытная команда SRE может значительно снизить зависимость от команды инженеров.
Предоставьте инженерам по надежности (SRE) инструменты, информацию и знания, необходимые для самостоятельного управления инцидентами. Эта подготовка снижает зависимость от команды инженеров. Службы безопасности должны быть обучены в сборниках схем и модели работоспособности рабочей нагрузки, разработанной на предыдущих уровнях, чтобы быстро распознать распространенные шаблоны и инициировать процесс устранения рисков.
Инженерная группа должна иметь время, чтобы отразиться на повторяющихся проблемах и разработать долгосрочные стратегии, а не решать их по отдельности каждый раз.
✓ Автоматизация процессов самовосстановления
На предыдущих уровнях стратегии самовосстановления разрабатываются с использованием избыточности и шаблонов проектирования. Теперь, когда у вашей команды есть опыт использования в реальном мире, вы можете интегрировать автоматизацию для устранения распространенных шаблонов сбоев и снижения зависимости от команды инженеров.
Компромисс: Автоматизация может занять время и быть дорогостоящим для настройки. Прежде всего сосредоточьтесь на автоматизации наиболее затронутых задач, таких как задачи, которые часто происходят или могут привести к сбоям.
Настройте действия на основе триггеров и автоматизируйте ответы со временем для создания автоматизированного сценария действий для SRE. Одним из подходов является улучшение сборника схем с помощью сценариев, реализующих шаги по устранению рисков. Изучите собственные параметры Azure, например с помощью групп действий Azure Monitor, чтобы настроить триггеры, которые автоматически инициируют различные задачи.
✓ Расширение устойчивости к фоновым задачам
Большинство рабочих нагрузок включают компоненты, которые напрямую не поддерживают потоки пользователей, но играют важную роль в общем рабочем процессе приложения. Например, в системе электронной коммерции, когда пользователь помещает заказ, система добавляет сообщение в очередь. Это действие активирует несколько фоновых задач, таких как подтверждение электронной почты, завершение оплаты кредитной карты и уведомление хранилища для подготовки к отправке. Эти задачи работают отдельно от функций, обслуживающих запросы пользователей на веб-сайте, что снижает нагрузку и повышает надежность. Системы также используют фоновые задачи для очистки данных, регулярного обслуживания и резервного копирования.
После оценки и улучшения основных потоков пользователей рассмотрите фоновые задачи. Используйте методы и инфраструктуру, которые уже существуют, и добавьте улучшения для фоновых задач.
Применяйте контрольные точки. Контрольная точка — это метод сохранения состояния процесса или задачи в определенных точках. Контроль точек особенно полезен для длительных задач или процессов, которые могут быть прерваны из-за непредвиденных проблем, таких как сбои сети или системные поломки. Когда процесс перезапускается, он может продолжить с последней сохраненной контрольной точки, тем самым сводя к минимуму влияние прерываний.
Сохраняйте идемпотентные процессы. Обеспечьте идемпотентность в фоновых процессах, чтобы при сбое задачи другой экземпляр мог взять её и продолжить обработку без проблем.
Обеспечение согласованности. Запретить системе вводить несогласованное состояние, если фоновая задача останавливается во время обработки. Контрольные точки и идемпотентность на уровне задач — это методы, позволяющие обеспечить большую согласованность в операциях фоновых задач. Выполните каждую задачу как атомарную транзакцию. Для задачи, охватывающей несколько хранилищ данных или служб, используйте идемпотентность на уровне задачи или компенсирующие транзакции, чтобы убедиться, что она завершена.
Интеграция фоновых задач в систему мониторинга и методики тестирования. Обнаружение сбоев и предотвращение незамеченных прерываний, которые могут привести к функциональным и нефункциональным последствиям. Система мониторинга должна записывать данные из этих компонентов, задавать оповещения о нарушениях и использовать триггеры для повтора или возобновления процесса автоматически. Обработайте эти ресурсы как часть рабочей нагрузки и проводите автоматическое тестирование таким же образом, как и для критически важных компонентов.
Azure предоставляет несколько служб и функций для фоновых заданий, таких как Функции Azure и веб-задания службы приложений Azure. Ознакомьтесь с рекомендациями и ограничениями при реализации потоков, ориентированных на надежность.
остается устойчивым по мере развития архитектуры рабочей нагрузки, что позволяет системе противостоять новым и непредвиденным рискам.
На уровне 5 основное внимание уделяется повышению надежности решения и отходит от реализации технических мер управления. Инфраструктура, приложения и операции должны быть достаточно надежными, чтобы быть устойчивыми к сбоям и восстановить их в течение целевого времени восстановления.
Используйте данные и будущие бизнес-цели, чтобы признать, что если бизнес должен идти дальше, изменения архитектуры могут потребоваться. По мере развития рабочей нагрузки и добавления новых функций старайтесь свести к минимуму сбои, связанные с этими функциями, а также сократить количество сбоев для существующих функций.
Ключевые стратегии
✓ Используйте данные о надежности для направления эволюции архитектуры
На этом уровне принимать решения в сотрудничестве с бизнес-заинтересованными лицами. Обратите внимание на следующие факторы:
Анализ метрик, указывающих, сколько раз система пересекает пороговые значения надежности в течение определенного периода времени и допустимо ли это. Например, в течение одного года возникает пять основных сбоев, которые могут привести к переоценке системного проектирования и операционной практики.
Оцените критически важное значение для бизнеса системы. Например, служба, поддерживающая критически важные рабочие процессы, может нуждаться в перепроектировании для развертываний с нулевым временем простоя и моментальной отработки отказа, даже если это увеличивает затраты или сложность. И наоборот, служба ограниченного использования может воспользоваться более расслабленными целями уровня обслуживания.
Оцените, как изменения в других компонентах влияют на надежность. Например, для повышения мер безопасности могут потребоваться меры по обеспечению надежности для дополнительных переходов безопасности, что может привести к потенциальным точкам сбоя.
Оцените операционные затраты на поддержание надежности. Если эти затраты превышают бюджетные ограничения, рассмотрите возможность изменения архитектуры для оптимизации и контроля расходов.
Чтобы помочь заинтересованным лицам, инженерам и руководителям продуктов принимать обоснованные решения, рассмотрите возможность визуализации предыдущих точек данных вместе с дополнительными аналитическими сведениями. Такой подход обеспечивает полную картину надежности.
✓ Запуск контролируемых тестов в рабочей среде
На этом уровне рассмотрите контролируемые эксперименты в рабочей среде только в том случае, если рабочая нагрузка требует максимальной надежности. Эти методики тестирования называются инженерией хаоса. Тесты проверяют, что система может восстановиться корректно и продолжить работу в неблагоприятных условиях.
Рассмотрим следующие примеры использования:
Анализ потока зависимостей: Распространенный вариант использования — тестирование приложений, разработанных как микрослужбы. Вы можете отключать случайные экземпляры микрослужб, чтобы убедиться, что сбои не распространяются и не нарушают пользовательский опыт. Этот подход можно расширить до системных потоков, отключив определенные компоненты, чтобы проанализировать реакцию подчиненных систем. Цель заключается в определении жесткой связи или скрытых зависимостей и тестировании того, как выполняются планы избыточности системы.
Грациозное тестирование ухудшения состояния: Оцените, как система выполняется с ограниченными возможностями во время сбоя. Например, можно скрыть некритичные функции, если система рекомендаций дает сбой.
Моделирование отказов третьих сторон: Отключайте или ограничивайте вызовы внешних API, чтобы проверить, как работает ваша система, и правильно ли реализованы механизмы резервирования или повторных попыток.
Проектирование хаоса является золотым стандартом для тестирования устойчивости. Однако оставляйте эту практику для зрелых систем и команд, работающих с нагрузками. Убедитесь, что меры безопасности установлены, чтобы ограничить радиус взрыва и предотвратить влияние пользователя.
Подготовьтесь, проводя тренировочные дни. Начните в непроизводственных средах, которые имитируют реальные условия с помощью настроек более низкого риска с искусственными транзакциями. Этот подход помогает выявить пробелы в процессе, пути ошибок человека и недостатки архитектуры.
Если тестирование в непроизводственной среде перестает давать ценные выводы, возможно, пора перейти в рабочую среду, если вы уверены. Перед переходом обязательно перечислите все вопросы, оцените устойчивость и решите любые проблемы.
Ограничить область экспериментов. Например, можно завершить работу только одного экземпляра. Четко определите назначение теста. Понять, что вы тестируете и почему.
Эти тесты должны соответствовать соглашениям уровня обслуживания путем работы в предопределенных ограничениях и бюджетах ошибок. Выберите соответствующие временные интервалы для этих экспериментов. Как правило, выполнение их во время рабочего дня гарантирует, что команда полностью укомплектована и имеет достаточно ресурсов для реагирования на любые инциденты, которые могут возникнуть.
✓ Проведение учений по аварийному восстановлению
Инженерия хаоса проверяет устойчивость технических элементов управления. Тренировки по аварийному восстановлению (DR) оценивают устойчивость процессов контроля. Цель учений по аварийному восстановлению — проверить эффективность процедур, координации и действий человека при восстановлении системы после крупных сбоев или катастроф.
Для нормативных рабочих нагрузок требования соответствия могут определять частоту тренировок по аварийному восстановлению, чтобы обеспечить учет усилий. Для других рабочих нагрузок рекомендуется регулярно проводить эти учения. Шестимесячный интервал обеспечивает хорошую возможность для отслеживания изменений рабочей нагрузки и обновления процедур аварийного восстановления соответствующим образом.
Учения по аварийному восстановлению должны быть больше, чем обычные упражнения. При правильном выполнении учения по аварийному восстановлению помогают обучить новых участников команды и выявить пробелы в инструментах, взаимодействии и других задачах, связанных с учениями. Они также могут выделить свежие перспективы, которые могут быть пропущены в противном случае.
Рассмотрим следующие ключевые методы проведения учебных тревог по аварийному восстановлению, каждый из которых различается по степени риска и практичности.
Полностью имитировано: Эти упражнения проводятся на доске и включают пошаговые процедурные руководства без воздействия на какие-либо системы. Они подходят для обучения и первоначальной проверки. Однако они не предоставляют аналитические сведения о реальных инцидентах.
Реальные тесты в непроизводственных средах: Эти тесты позволяют проверять автоматизацию, сценарии и процессы без каких-либо бизнес-рисков.
Реальные тренировки в производстве: Эти тренировки обеспечивают высочайший уровень уверенности и реалистичности. Проводите эти тренировки только после того, как вы протестируете первые два метода. Тщательное планирование и стратегии отката важны для минимизации рисков. Не продолжайте, если есть какой-либо шанс вызвать сбои.
Независимо от типа тренировки восстановления после сбоев четко определите сценарии восстановления рабочей нагрузки. Проводите учения так, как если бы это были реальные инциденты. Такой подход гарантирует, что команда следует хорошо понятным контрольным спискам. Документируйте и классифицируйте результаты для непрерывного улучшения. Подготовка аварийного восстановления (DR) может включать следующие процессы:
Поймите системы управления инцидентами и убедитесь, что команда обучена процедурам эскалации.
Предоставьте перечень инструментов для сотрудничества и обновления статуса, включая альтернативы на случай, если основные системы будут затронуты.
Предоставьте материалы для обучения в соответствующих тестовых сценариях для рабочей нагрузки.
Отслеживайте несоответствия для отслеживания проблем, возникающих во время реализации.
Компромисс: Эти учения обычно не создают нарушений, но они занимают время. Чтобы максимально повысить эффективность, сосредоточьтесь на ключевых аспектах и избежать ненужных задач. Не забудьте выделить время для этой практики в вашем бэклоге.
При создании планов аварийного восстановления или проведении учений аварийного восстановления, в частности для первых нескольких учений, рассмотрите возможность привлечения специализированных экспертов. Их вклад в проекты с многорегиональным дизайном, стратегии резервирования и восстановления после сбоев, а также в предложения по службам или инструментам может быть бесценным. Если у вашей организации есть команда Cloud Center of Excellence, обязательно включите их в процесс планирования.
✓ Оценка модели данных и сегмента при необходимости
Данные являются динамическими и постоянно развивающимися. В отличие от других компонентов в архитектуре, данные обычно растут по мере взаимодействия пользователей с системой. Мониторинг шаблонов данных с течением времени и оценка их влияния на другие части архитектуры являются важными. На этом уровне рассмотрим методы, упрощающие управление данными и повышающие производительность для повышения общей надежности. Секционирование — это ключевая стратегия достижения этих результатов.
Изучите такие методы, как горячее секционирование, которое делит данные на основе шаблонов доступа и сохраняет их отдельно. Используйте такие критерии, как частота доступа или релевантности, чтобы решить, что следует секционировать.
Горячее секционирование можно объединить с сегментированием, который делит большую базу данных на небольшие единицы, называемые сегментами. Каждый сегмент содержит часть данных, и вместе они образуют полный набор данных. Такой подход обеспечивает независимое управление данными.
Компромисс: Для балансировки сегментов требуются операционные процессы для оценки и подтверждения их распределения. Этот подход помогает избежать горячих разделов, где один раздел используется чрезмерно. Однако она также требует постоянных усилий и ресурсов для поддержания баланса.
При выборе метода секционирования рассмотрите следующие преимущества надежности:
Улучшенная производительность: Распределяя запросы между несколькими секциями, можно уменьшить нагрузку на отдельные хранилища. При эффективной реализации сегментирование позволяет системе обрабатывать миллионы запросов на запись в день. Эта стратегия повышает производительность и сокращает задержку.
Секционирование может упростить горизонтальное масштабирование. Например, сегментирование может разделить пользователей или клиентов на примерно равные контейнеры.
Улучшено управление данными: Горячее секционирование позволяет применять различные уровни управления данными к каждому уровню хранилища. Например, перемещение архивных данных в отдельное хранилище помогает предотвратить замедление операций и резервных копий. Аналогичным образом не все данные журнала должны храниться в реляционной базе данных. Он может храниться в другом хранилище данных, пока активные данные рабочей нагрузки остаются реляционными.
Специализированные политики надежности: Различные политики надежности могут применяться для обеспечения каждого раздела соответствующим уровнем отказоустойчивости и предотвращения превращения одного хранилища в узкое место. Горячие разделы могут быть полностью резервированными, включая зональное резервирование и георезервирование, тогда как холодные разделы основываются на резервных копиях. Дополнительное преимущество надежности заключается в том, что можно уменьшить радиус взрыва некоторых типов сбоев. Например, если сбой влияет на один сегмент, он может не повлиять на другие сегменты.
Компромисс: Это может быть трудно поддерживать или изменять секции из-за сильных взаимозависимостей между разными секциями данных. Эти изменения могут повлиять на возможность проверки согласованности и целостности данных, особенно при сравнении с одним хранилищем данных. По мере увеличения числа секций потребность в надежных процессах для поддержания целостности данных становится более важной. Без этих мер надежность может быть скомпрометирована.