Разработчик Гуннар Морлинг в 2022 году представил пирамиду ревью кода. По аналогии с ней появилась пирамида отказоустойчивости системы. Она делит отказоустойчивость на уровни и предлагает ответить на ряд важных вопросов по каждому из уровней. Пирамида отказоустойчивости системы помогает лучше понимать и реализовывать эту концепцию.
Инфраструктура
В основе пирамиды лежит инфраструктура. В неё входят физические аппаратные средства, на которых работают системы. А также серверы, сети, центры обработки данных, системы электропитания и многое другое. Какие резервы встроены в вашу инфраструктуру? Инвестиции в избыточную инфраструктуру могут уменьшить количество точек отказа и повысить отказоустойчивость.
Ниже приведены примеры вопросов, которые могут задавать себе инженеры:
Имеет ли система достаточную избыточность ?
Существует ли стратегия резервного копирования?
Насколько устойчива настройка сети к сбоям?
Есть ли единые точки отказа в настройке инфраструктуры?
Что произойдет, если на центр обработки данных или облачный регион обрушится торнадо?
Проектирование системы
В программной инженерии проектирование системы связано с высокоуровневой архитектурой и структурой программы. Как правило, это компромисс между функциональностью и удовлетворением нефункциональных требований.
Некоторые ключевые аспекты проектирования системы:
Архитектура — это общие компоненты системы и их взаимодействие. Архитектура может быть распределённая или монолитная, может содержать модель клиент-сервер, микросервисы и т.д.
Разделение — разбиение системы на модули и компоненты. Это то, как делятся обязанности и функциональность.
Интерфейсы — это то, как компоненты общаются и взаимодействуют друг с другом через API, вызовы функций, протоколы и т. д.
Масштабируемость. Учитывает ли система рост числа пользователей, трафика, объёма данных и т.д. Это влияет на такие вещи, как горизонтальное и вертикальное масштабирование.
Безопасность — существуют ли механизмы контроля доступа, шифрования, обфускации, аудита и т.д.
Надежность. Отказоустойчивость может достигаться за счет избыточности, аварийного переключения, плавной деградации и т. д.
Производительность — оптимизация скорости, отклика и эффективности.
Ремонтопригодность. Позволяет ли проект вносить обновления и изменения без серьезных сбоев/изменений в сервисе.
Основные цели — разбить систему на логические части, определить взаимосвязи и взаимодействия и добиться компромисса по функционалу, качеству и производительности. Этот высокоуровневый план реализуется через другие более низкоуровневые планы.
Данные
Когда дело доходит до вопросов о данных, то здесь нет универсального решения, как улучшить отказоустойчивость. Но можно задать несколько вопросов, которые помогут избежать неожиданных проблем. Проблемы с данными опасны тем, что представляют угрозу всему бизнесу.
Ниже приведен список таких вопросов. На них надо ответить, прежде чем вы приступите к написанию отказоустойчивого программного обеспечения:
Должны ли данные реплицироваться в нескольких местах: хосты, регионы, облака?
Существуют ли механизмы для обеспечения атомарности и согласованности транзакций?
Как система разрешает конфликты?
Какие меры безопасности существуют для защиты целостности данных?
Есть ли риск потери данных?
Какую технологию баз данных мы должны использовать? (вопрос на 1 миллион долларов)
Fault Tolerance (отказоустойчивость)
Базовые возможности отказоустойчивости закладываются на уровне проектирования системы. Но многие компании не могут позволить себе включить эти механизмы в свою архитектуру. Если не делать это заранее, то в будущем могут возникнуть проблемы с надежностью системы.
Общая отказоустойчивость системы складывается из таких механизмов как: избыточность, автоматическое переключение при отказе, деградация и повторные попытки. Их стоит включить в первоначальный проект системы.
Архитектура, в которой с самого начала заложено обеспечение устойчивости, дает системе возможность справляться с неизбежными сбоями и перегрузками.
Вопросы:
Какие сбои или неисправности наиболее вероятны?
Как мы можем создать избыточность в системе? Например: дублировать серверы, создавать резервы, делать развертывание в нескольких регионах.
Как будет деградировать система при перегрузке?
Можем ли мы отказаться от второстепенной работы?
Как система будет реагировать на сбои компонентов? Нужны ли нам проверки работоспособности и автоматический перезапуск?
Какая автоматическая отказоустойчивость необходима? Насколько она должна быть активной?
Как мы можем изолировать сбои и не дать им превратиться в каскадные сбои между компонентами?
Какие запасные варианты/значения мы можем реализовать в случае сбоя частей системы?
Как мы можем реализовать повторные попытки/отсрочку для временных ошибок?
Должны ли мы установить сроки, чтобы избежать ненужной работы?
Как будет защищена целостность системы, если поврежденный компонент необходимо отключить?
Как можно вносить системные изменения и обновления без простоев?
Тесты и наблюдаемость
Этот уровень связан с двумя вопросами:
Как вы проверяете устойчивость?
Как быстро можно выявить и устранить проблемы?
Комплексное тестирование системы включает проверку на всех уровнях, от компьютера разработчика до взаимодействия с клиентом. Вот что сюда может входить:
Всестороннее тестирование на разных уровнях подтверждает надежность; например, модульное, интеграционное, e2e и функциональное тестирование снижают подверженность ошибкам.
Тестирование производительности и нагрузочное тестирование могут помочь выявить узкие места.
Хаос-инженеринг — целенаправленные сбои для проверки отказоустойчивости и проверки гипотез об отказоустойчивости системы.
Надежные инструменты мониторинга и наблюдения обеспечивают обзор состояния системы в режиме реального времени. Это позволяет командам быстро обнаруживать и диагностировать аномалии. Алерты уведомляют инженеров, когда ключевые показатели производительности превышают допустимые пороговые значения. Инженеры должны разобраться и устранить последствия ещё до того, как сбои повлияют на пользователей.
Подход Obeservability позволяет отслеживать основные системные показатели, объединять данные журналов и отслеживать индикаторы работоспособности компонентов. Сопоставление метрик и логов позволяет быстро анализировать основные причины проблем. Для обзора показателей надежности и оценки состояния системы используются дашборды.
Заключение
Пирамида отказоустойчивости системы помогает сформировать представление о надежности. Следование этим принципам на ключевых уровнях позволяет создавать системы, которые могут лучше противостоять нагрузкам, сбоям и отказам. Это сокращает время простоя и защищает клиентов от хаоса реального мира. Насколько устойчивы ваши системы?
Если вас интересуют SRE-практики, приходите на курс SRE: data-driven подход к управлению надежностью систем. Это курс для опытных инженеров эксплуатации и разработчиков, который помогает освоить SRE-подход и внедрить его в своей компании. Вы научитесь:
выбирать и мониторить SRE-метрики (SLO, SLI, error budget) для своего сервиса.
реализовывать мониторинг, опознавать и решать проблемы с инфраструктурой;
настраивать alerting и healthcheck;
использовать разные методы деплоймента, разбираться в инструментах для этого.
На практических занятиях вы станете SRE для сервиса покупки билетов в кинотеатр. Решая предложенные кейсы, вы получите представление, чем занимается SRE в реальности и сможете организовать и возглавить пожарную команду в своей компании.
Старт потока — 22 августа.
Ознакомиться с программой и оставить заявку можно ???? на нашем сайте.