Принципы проектирования надежности
Сбои и неисправности являются серьезными проблемами для всех рабочих нагрузок. Надежная рабочая нагрузка должна выдержать эти события и продолжать постоянно предоставлять свои предполагаемые функциональные возможности. Он должен быть устойчивым , чтобы обнаруживать, выдерживать и восстанавливаться после сбоев в течение приемлемого периода времени. Он также должен быть доступен , чтобы пользователи могли получить доступ к рабочей нагрузке в течение обещанного периода времени на обещанном уровне качества.
Нереально предполагать, что сбоев не произойдет, особенно если рабочая нагрузка создана для выполнения в распределенных системах. Некоторые компоненты могут завершиться сбоем, а другие продолжают работать. В какой-то момент может повлиять на взаимодействие с пользователем, что ставит под угрозу бизнес-цели.
Архитектуры рабочих нагрузок должны иметь гарантии надежности в коде приложения, инфраструктуре и операциях. Варианты проектирования не должны изменять намерение, заданное бизнес-требованиями. Такие изменения следует рассматривать как существенные компромиссы.
Принципы проектирования предназначены для предоставления рекомендаций по аспектам надежности, которые следует учитывать на протяжении жизненного цикла разработки. Начните с рекомендуемых подходов и обоснуйте преимущества для набора требований. После настройки стратегии выполните действия с помощью контрольного списка надежности.
Если вы не примените эти принципы к проектированию, рабочая нагрузка, скорее всего, не будет готова к прогнозированию или обработке проблем в рабочей среде. Результатом могут быть перебои в обслуживании, которые приводят к финансовым потерям. В случае критически важных рабочих нагрузок несоблюдение этих принципов может поставить под угрозу безопасность.
Проектирование под бизнес-требования
Соберите бизнес-требования с акцентом на предполагаемую полезность рабочей нагрузки. |
|---|
Требования должны охватывать взаимодействие с пользователем, данные, рабочие процессы и характеристики, уникальные для рабочей нагрузки. Результат процесса требований должен четко указывать ожидания. Цели должны быть достижимы и согласованы с командой с учетом указанных инвестиций. Они должны быть задокументированы для реализации технологических решений, реализаций и операций.
| Подход | Преимущество |
|---|---|
| Количественное определение успеха путем установки целевых показателей для отдельных компонентов, системных потоков и системы в целом. Делают ли эти целевые объекты более надежными потоки пользователей? | Метрики количественно обозначают ожидания. Они позволяют понять сложности и определить, находятся ли нижестоящие затраты на эти сложности в пределах лимита инвестиций. Целевые значения указывают на идеальное состояние. Значения можно использовать в качестве тестовых пороговых значений, которые помогают обнаруживать отклонения от этого состояния и время, необходимое для возврата в целевое состояние. Требования к соответствию также должны иметь прогнозируемые результаты для область потоков. Приоритезирование этих потоков позволяет привлечь внимание к наиболее чувствительным областям. |
| Понимать обязательства платформы. Учитывайте ограничения, квоты, регионы и ограничения емкости для служб. | Соглашения об уровне обслуживания зависят от службы. Не все службы и функции охватываются одинаково. Не все службы или функции доступны во всех регионах. Большинство ограничений ресурсов подписки на каждый регион. Хорошее представление о охвате и ограничениях поможет вам обнаружить смещение и создать механизмы устойчивости и восстановления. |
| Определите зависимости и их влияние на устойчивость. | Отслеживание зависимой инфраструктуры, служб, API и функций, разработанных другими командами или третьими сторонами, помогает определить, может ли рабочая нагрузка работать без этих зависимостей. Это также помогает понять каскадные сбои и улучшить подчиненные операции. Разработчики могут реализовать устойчивые конструктивные шаблоны для обработки потенциальных сбоев при использовании внешних служб, которые могут быть подвержены сбоям. |
Проектирование для обеспечения устойчивости
|
Рабочая нагрузка должна продолжать работать с полной или ограниченной функциональностью. |
|---|
Следует ожидать, что будут возникать сбои компонентов, сбои платформы, снижение производительности, ограниченная доступность ресурсов и другие сбои. Повысьте устойчивость в системе, чтобы она была отказоустойчивой и может корректно снижаться.
| Подход | Преимущество |
|---|---|
| Отличить компоненты, которые находятся на критическом пути , от компонентов, которые могут функционировать в сниженном состоянии. | Не все компоненты рабочей нагрузки должны быть одинаково надежными. Определение важности помогает проектировать в соответствии с критичностью каждого компонента. Вы не будете чрезмерной устойчивости для компонентов , которые могут немного ухудшить взаимодействие с пользователем, в отличие от компонентов, которые могут вызвать комплексные проблемы в случае сбоя. Эта конструкция может быть эффективной при выделении ресурсов для критически важных компонентов. Вы также можете реализовать стратегии изоляции ошибок, чтобы в случае сбоя некритического компонента или его выхода из состояния понижения производительности можно было изолировать, чтобы предотвратить каскадные сбои. |
| Определите потенциальные точки сбоя в системе, особенно для критически важных компонентов, и определите влияние на потоки пользователей. | Вы можете проанализировать случаи сбоя, радиус взрыва и интенсивность сбоя: полный или частичный сбой. Этот анализ влияет на структуру возможностей обработки ошибок на уровне компонентов. |
| Создавайте возможности самосохранения , правильно используя конструктивные шаблоны и модульную структуру для изоляции ошибок. | Система сможет предотвратить возникновение проблемы на подчиненных компонентах. Система сможет устранять временные и постоянные сбои, узкие места производительности и другие проблемы, которые могут повлиять на надежность. Вы также сможете свести к минимуму радиус взрыва. |
| Добавьте возможность масштабирования критически важных компонентов (приложения и инфраструктуры), учитывая ограничения емкости служб в поддерживаемых регионах. | Рабочая нагрузка сможет обрабатывать пики и колебания переменной емкости. Эта возможность имеет решающее значение при возникновении непредвиденной нагрузки на систему, например при резком росте допустимого использования. Если рабочая нагрузка предназначена для масштабирования в нескольких регионах, она может даже преодолеть потенциальные временные ограничения емкости ресурсов или другие проблемы, влияющие на один регион. |
|
Обеспечение избыточности на уровнях и устойчивости на разных уровнях приложений. Стремитесь к избыточности физических служебных программ и немедленной репликации данных. Кроме того, стремитесь к избыточности на функциональном уровне, охватывающем службы, операции и персонал. |
Избыточность помогает свести к минимуму отдельные точки отказа. Например, если есть компонентный, зональный или региональный сбой, избыточное развертывание (в режиме "активный— активный" или "активный — пассивный") позволяет достичь целевых показателей времени безотказной работы. Добавление посредников предотвращает прямую зависимость между компонентами и улучшает буферизацию. Оба этих преимущества повышают устойчивость системы. |
| Чрезмерная подготовка для немедленного устранения отдельных сбоев избыточных экземпляров и буферизации от потребления ресурсов. | Увеличение инвестиций в чрезмерную подготовку повышает устойчивость. Система будет продолжать работать с полной служебной программой во время активного сбоя даже до начала операций масштабирования для устранения сбоя. Аналогичным образом можно снизить риск непредвиденного потребления ресурсов, утверждающего запланированный буфер, набирая критическое время рассмотрения до системных сбоев или агрессивного масштабирования. |
Проектирование для восстановления
|
Рабочая нагрузка должна быть в состоянии предвидеть и восстанавливаться после большинства сбоев всех масштабов с минимальным нарушением взаимодействия с пользователем и бизнес-целями. |
|---|
Даже высокоустойчивым системам требуются подходы к обеспечению готовности к аварийным ситуациям, как при проектировании архитектуры, так и в операциях рабочей нагрузки. На уровне данных должны быть стратегии, которые могут восстановить состояние рабочей нагрузки в случае повреждения.
| Подход | Преимущество |
|---|---|
| Иметь структурированные, протестированные и задокументированные планы восстановления , согласованные с согласованными целевыми показателями восстановления. Планы должны охватывать все компоненты, помимо системы в целом. | Четко определенный процесс приводит к быстрому восстановлению , что может предотвратить негативное влияние на финансы и репутацию вашего бизнеса. Проведение регулярных отработок восстановления проверяет процесс восстановления системных компонентов, данных, а также этапы отработки отказа и восстановления размещения, чтобы избежать путаницы, когда время и целостность данных являются ключевыми показателями успеха. |
| Убедитесь, что вы можете восстановить данные всех компонентов с отслеживанием состояния в целевых объектах восстановления. | Резервные копии необходимы для возвращения системы в рабочее состояние с помощью доверенной точки восстановления, например последнего известного хорошего состояния. Неизменяемые и транзакционно согласованные резервные копии гарантируют, что данные не могут быть изменены и восстановленные данные не повреждены. |
| Реализация возможностей автоматического самовосстановления в проекте. | Такая автоматизация снижает риски, связанные с внешними факторами, такими как вмешательство человека, и сокращает цикл фиксации перерывов. |
| Замените компоненты без отслеживания состояния неизменяемыми временными единицами. | Создание эфемерных единиц, которые можно развернуть и уничтожить по требованию, обеспечивает повторяемость и согласованность. Используйте параллельные модели развертывания, чтобы сделать переход на новые блоки постепенной, сводя к минимуму перебои. |
Разработка с учетом эксплуатации
|
Сдвиг влево в операциях для прогнозирования условий сбоя. |
|---|
Сбои тестирования на ранних стадиях и часто в жизненном цикле разработки и определение влияния производительности на надежность. Для анализа первопричин и посмертных анализов необходимо обеспечить общую видимость состояния зависимостей и текущих сбоев в командах. Аналитические сведения, диагностика и оповещения из наблюдаемых систем имеют важное значение для эффективного управления инцидентами и непрерывного совершенствования.
| Подход | Преимущество |
|---|---|
| Создание наблюдаемых систем , которые могут сопоставлять данные телеметрии. | Мониторинг и диагностика являются критически важными операциями. Если что-то завершается сбоем, необходимо знать, что произошел сбой, когда произошел сбой и почему произошел сбой. Наблюдаемость на уровне компонентов является фундаментальной, но агрегированная наблюдаемость компонентов и коррелированных потоков пользователей обеспечивает целостное представление о состоянии работоспособности. Эти данные необходимы для того, чтобы инженеры по обеспечению надежности сайта могли приоритизировать свои усилия по исправлению. |
| Прогнозирование потенциальных сбоев и аномального поведения. Сделайте активные сбои надежности видимыми с помощью приоритетных оповещений и оповещений с действиями. Инвестируйте в надежные процессы и инфраструктуру, что позволяет ускорить рассмотрение. |
Инженеры по обеспечению надежности сайта могут получать уведомления немедленно, чтобы они могли устранять текущие инциденты на сайте в реальном времени и заблаговременно устранять потенциальные сбои, выявленные прогнозными оповещениями, прежде чем они станут активными инцидентами. |
| Имитация сбоев и выполнение тестов в рабочей и подготовительной средах. | Это полезно, чтобы испытать сбои в рабочей среде, чтобы вы могли установить реалистичные ожидания для восстановления. Это позволяет выбирать варианты проектирования, которые корректно реагируют на сбои. Кроме того, она позволяет протестировать пороговые значения, заданные для бизнес-метрик. |
| Создавайте компоненты с учетом автоматизации и автоматизируйте как можно больше. | Автоматизация сводит к минимуму вероятность человеческих ошибок, что обеспечивает согласованность при тестировании , развертывании и операциях. |
| Фактор в рутинных операциях и их влияние на стабильность системы. | Рабочая нагрузка может подвергаться текущим операциям, таким как редакции приложений, аудиты безопасности и соответствия требованиям, обновления компонентов и процессы резервного копирования. Тщательное изучение этих изменений обеспечивает стабильность системы. |
| Непрерывное обучение на основе инцидентов в рабочей среде. | На основе инцидентов можно определить влияние и контроль над проектированием и операциями, которые могут пройти незамеченными в предварительной подготовке. В конечном счете, вы сможете добиться улучшений на основе реальных инцидентов. |
Простота
|
Избегайте чрезмерной разработки архитектуры, кода приложения и операций. |
|---|
Часто именно то, что вы удаляете, а не добавляете, что приводит к наиболее надежным решениям. Простота уменьшает площадь поверхности для управления, сводя к минимуму неэффективность и потенциальные неправильные настройки или непредвиденные взаимодействия. С другой стороны, чрезмерное упрощение может привести к единичных точках отказа. Поддерживайте сбалансированный подход.
| Подход | Преимущество |
|---|---|
| Добавляйте компоненты в архитектуру только в том случае, если они помогают достичь целевых бизнес-ценностей. Держите критический путь более экономичным. | Проектирование в соответствии с бизнес-требованиями может привести к простому решению, которое легко реализовать и управлять. Избегайте слишком большого количества критически важных компонентов, так как каждый из них является существенной точкой отказа. |
| Установите стандарты в реализации, развертывании и процессах кода, а также задокументируйте их. Определите возможности для применения этих стандартов с помощью автоматических проверок. | Стандарты обеспечивают согласованность и сводя к минимуму человеческие ошибки. Такие подходы, как стандартные соглашения об именовании и руководства по стилю кода, помогают поддерживать качество и упрощают идентификацию ресурсов во время устранения неполадок. |
| Оцените, преобразуется ли теоретический подход в прагматичный дизайн , применимый к вашим вариантам использования. | Слишком детализированный код приложения может привести к ненужной взаимозависимости, дополнительным операциям и сложному обслуживанию. |
| Разработайте достаточно кода. | Вы сможете предотвратить проблемы, которые являются результатом неэффективных реализаций, таких как непредвиденное потребление ресурсов, сбои пользователей или потоков данных и ошибки кода. И наоборот, проблемы с надежностью должны привести к проверкам кода, чтобы убедиться, что код достаточно устойчив для решения проблем. |
| Воспользуйтесь преимуществами предоставляемых платформой функций и предварительно созданных ресурсов, которые помогут вам эффективно достичь бизнес-целей. | Такой подход сокращает время разработки. Это также позволяет использовать проверенные методики , которые использовались с аналогичными рабочими нагрузками. |