Поделиться через

Принципы проектирования надежности

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

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

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

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

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

Проектирование бизнес-требований

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

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

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

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

- Какой уровень устойчивости, восстановления, наблюдаемости и простоты необходим?
— Существуют ли определенные ограничения, связанные с затратами, соответствием, географией или задержкой?

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

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

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

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

Учитывайте централизованную инфраструктуру, мандаты безопасности, политики маршрутизации сети или решения платформы, которые непосредственно влияют на то, что можно обещать с точки зрения устойчивости, доступности и восстановления.		 Понимание вашей зависимости от служб, не находящихся под вашим контролем, помогает разрабатывать с реалистичными ожиданиями надежности. Это гарантирует, что целевые показатели RTO/RPO и SLO достижимы и четко сообщены, избегая чрезмерных обещаний и уменьшая количество неожиданных ситуаций.

Проектирование для обеспечения устойчивости

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

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

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

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

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

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

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

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

Проектирование для восстановления

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

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

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

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

Проектирование операций

Значок цели Сдвиг влево в операциях для прогнозирования условий сбоя.

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

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

Инвестируйте в надежные процессы и инфраструктуру, что приводит к более быстрой обработке.		 Инженеры надежности сайта могут быть немедленно уведомлены, чтобы они могли устранять текущие инциденты в реальном времени и заранее устранять потенциальные сбои, выявленные прогнозными оповещениями, прежде чем они становятся активными инцидентами.
Имитация сбоев и выполнение тестов в рабочих и предварительных средах. Полезно испытать сбои в рабочей среде, чтобы вы могли задать реалистичные ожидания для восстановления. Это позволяет сделать варианты проектирования, которые корректно реагируют на сбои. Кроме того, он позволяет протестировать пороговые значения, заданные для бизнес-метрик.
Создавайте компоненты с учетом автоматизации и автоматизируйте столько, сколько вы можете. Автоматизация сводит к минимуму потенциал для человеческой ошибки, что приводит к согласованности для тестирования, развертывания и операций.
Учитывайте рутинные операции и их влияние на стабильность системы. Рабочая нагрузка может быть подвержена текущим операциям, таким как редакции приложений, аудиты безопасности и соответствия требованиям, обновления компонентов и процессы резервного копирования. Тщательное изучение этих изменений обеспечивает стабильность системы.
Непрерывное изучение инцидентов в рабочей среде. На основе инцидентов можно определить влияние и упущения в проектировании и операциях, которые могут остаться незамеченными на предпроизводственном этапе. В конечном счете, вы сможете добиться улучшений на основе реальных событий.

Оставить его простым

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

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

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

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

Дальнейшие шаги

Контрольный список надежности

  • Last updated on