Пирамида отказоустойчивости системы

Разработчик Гуннар Морлинг в 2022 году представил пирамиду ревью кода. По аналогии с ней появилась пирамида отказоустойчивости системы. Она делит отказоустойчивость на уровни и предлагает ответить на ряд важных вопросов по каждому из уровней. Пирамида отказоустойчивости системы помогает лучше понимать и реализовывать эту концепцию. 

Инфраструктура

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

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

• Имеет ли система достаточную избыточность ?

• Существует ли стратегия резервного копирования?

• Насколько устойчива настройка сети к сбоям?

• Есть ли единые точки отказа в настройке инфраструктуры?

• Что произойдет, если на центр обработки данных или облачный регион обрушится торнадо?

Проектирование системы

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

Некоторые ключевые аспекты проектирования системы:

• Архитектура — это общие компоненты системы и их взаимодействие. Архитектура может быть распределённая или монолитная, может содержать модель клиент-сервер, микросервисы и т.д.

• Разделение — разбиение системы на модули и компоненты. Это то, как делятся обязанности и функциональность.

• Интерфейсы — это то, как компоненты общаются и взаимодействуют друг с другом через API, вызовы функций, протоколы и т. д.

• Масштабируемость. Учитывает ли система рост числа пользователей, трафика, объёма данных и т.д. Это влияет на такие вещи, как горизонтальное и вертикальное масштабирование.

• Безопасность — существуют ли механизмы контроля доступа, шифрования, обфускации, аудита и т.д.

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

• Производительность — оптимизация скорости, отклика и эффективности.

• Ремонтопригодность. Позволяет ли проект вносить обновления и изменения без серьезных сбоев/изменений в сервисе.

Основные цели — разбить систему на логические части, определить взаимосвязи и взаимодействия и добиться компромисса по функционалу, качеству и производительности. Этот высокоуровневый план реализуется через другие более низкоуровневые планы.

Данные

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

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

• Должны ли данные реплицироваться в нескольких местах: хосты, регионы, облака?

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

• Как система разрешает конфликты?

• Какие меры безопасности существуют для защиты целостности данных?

• Есть ли риск потери данных?

• Какую технологию баз данных мы должны использовать? (вопрос на 1 миллион долларов)

Fault Tolerance (отказоустойчивость)

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

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

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

Вопросы:

• Какие сбои или неисправности наиболее вероятны?

• Как мы можем создать избыточность в системе? Например: дублировать серверы, создавать резервы, делать развертывание в нескольких регионах.

• Как будет деградировать система при перегрузке?

• Можем ли мы отказаться от второстепенной работы?

• Как система будет реагировать на сбои компонентов? Нужны ли нам проверки работоспособности и автоматический перезапуск?

• Какая автоматическая отказоустойчивость необходима? Насколько она должна быть активной?

• Как мы можем изолировать сбои и не дать им превратиться в каскадные сбои между компонентами?

• Какие запасные варианты/значения мы можем реализовать в случае сбоя частей системы?

• Как мы можем реализовать повторные попытки/отсрочку для временных ошибок?

• Должны ли мы установить сроки, чтобы избежать ненужной работы?

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

• Как можно вносить системные изменения и обновления без простоев?

Тесты и наблюдаемость

Этот уровень связан с двумя вопросами:

• Как вы проверяете устойчивость?

• Как быстро можно выявить и устранить проблемы?

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

• Всестороннее тестирование на разных уровнях подтверждает надежность; например, модульное, интеграционное, e2e и функциональное тестирование снижают подверженность ошибкам.

• Тестирование производительности и нагрузочное тестирование могут помочь выявить узкие места.

• Хаос-инженеринг — целенаправленные сбои для проверки отказоустойчивости и проверки гипотез об отказоустойчивости системы.

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

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

Заключение

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

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

• выбирать и мониторить SRE-метрики (SLO, SLI, error budget) для своего сервиса.

• реализовывать мониторинг, опознавать и решать проблемы с инфраструктурой;

• настраивать alerting и healthcheck;

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

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

Старт потока — 22 августа.

Ознакомиться с программой и оставить заявку можно