SRE

Время отклика - время выполнения запроса

Трафик - количество запросов к сервису (запросы в секунды, транзакции, потоки и тд)

Ошибки - количество ошибок.

Загруженность/утилизация - показывает насколько полно загружен сервис. Процент загрузки процессора или пропускной способности сети.

• SLI (Service Level Indicator) — это числовой показатель, качества работы сервиса. Примеры: доля успешных запросов, среднее время ответа API, процент времени доступности сервиса. Это метрика факта.
• SLO (Service Level Objective) — это целевое значение для SLI, которого команда стремится достичь.
• SLA (Service Level Agreement) — это юридическое или формализованное соглашение между потребителем и сервисом. Оно включает SLO, но добавляет ответственность: штрафы, компенсации, обязательства.

• Модульное тестирование - тестируется поведение одного конкретного модуля или компонента программы, например класса или функции.
• Интеграционное тестирование - тестирование взаимодествия компонент
• Системное тестирование - наиболее масштабные тесты запускаемые для всей развернутой системы:
  1. Smoke test - тесты общей доступности.
  2. Тесты производительности - позволяет убедиться что производительность будет оставаться на требуемом уровне в течении цикла жизни ПО. Гарантируют что с течением времени система не деградирует или не станет слишком дорогой из-за необходимости наращивания мощностей
  3. Регрессионные тесты - набор прошлых кейсов для предотвращения ошибок в коде.
• Нагрузочное тестирование - тестирование для понимания ограничений самой системы и ее отдельных компонентов в частности.

• tcp - балансировщик отправляет пакет TCP SYN на сервер. Сервер возвращает пакет SYN-ACK. Если балансировщик не получает пакет SYN-ACK в течение времени ожидания, он объявляет, что сервер не работает, и отправляет пакет RST для завершения TCP-соединения. Если балансировщик получает пакет SYN-ACK от сервера в течение времени ожидания, он отправляет пакет ACK и объявляет, что сервер здоров
• http/https - периодически система отправляет HTTP-запрос к указанному URL. Сервер возвращает код состояния HTTP. Если код ответа в течение заданного интервала (тайм-аут проверки) совпадает с заданным кодом, сервер считается здоровым. Если ответа не получено в течение тайм-аута, сервер помечается как неработающий.

• Программные проблемы. Неправильная конфигурация ошибки настройки системы могут привести к некорректному распределению трафика, перегрузкам и последующим сбоям. DDoS атаки: масштабные атаки могут перегружать систему, вызывая сбои и даже полный выход из строя.
• Проблемы сети. Перегрузка сетевого интерфейса (избыточный трафик) может приводить к снижению производительности или полной остановке работы. Неверная настройка маршрутов внутри сети может препятствовать нормальной работе балансировщика нагрузки.
• Аппаратные проблемы. Если балансировка аппаратная то могут быть следующие причины такие как перегрев компонент, скачки напряжения в сети, межаническое воздействие.

1. Circuit Breaker (разрыв цепи)
   Зачем нужен: Circuit Breaker (разрыв цепи) – центральный паттерн для предотвращения каскадных отказов. Его задача – разорвать поток запросов к сервису, если тот начал падать или слишком медленно отвечать.
   Как работает: Имеет три состояния CLOSED, OPEN и HALF_OPEN. В "закрытом" состоянии запросы к сервису выполняются нормально. Если сбои начинают учащаться, состояние переключается на "открытое", и вызовы временно блокируются. После определенного времени система переходит в "полуоткрытое" состояние, где некоторые вызовы тестируются, чтобы проверить, исправился ли сбой.
   Алгоритмы определения необходимости активации Circuit Breake:
   • Порог ошибок (Error threshold) - Circuit Breaker переходит в открытое состояние, когда количество ошибок в определенном временном интервале превышает заданный порог.
   • Процентный порог ошибок (Error rate threshold) - Вместо фиксированного количества ошибок, Circuit Breaker активируется, когда процент ошибок от общего числа запросов превышает заданный уровень.
   • Оценка времени ответа (Response time evaluation) - Активация Circuit Breaker происходит, если среднее время ответа сервиса превышает установленный порог.
2. Bulkhead (изоляция ресурсов) — это паттерн, который изолирует элементы в системе таким образом, что если один из них выходит из строя, это не влечет за собой каскадный сбой всей системы. Это достигается путем разделения элементов системы на изолированные группы. Зачем нужен: Bulkhead (перегородка) – паттерн, призванный изолировать сбой одного компонента от других.
   Что делает: Bulkhead препятствует исчерпанию общих ресурсов. Например сервис не отвечает и клиент начинает плодить новые коннекты к нему тем самым забивая у себя ресурсы не только к этому сервису, но и к другим работающим. Пример реализации пулл коннектов к БД.
3. Timeout (ограничение времени ожидания)
   Зачем нужен: Timeout нужен, чтобы не ждать клиента слишком долго и освободить его ресурсы.
   Что делает: Применение таймаутов гарантирует, что любой долгий запрос прервётся по прошествии определённого времени. После срабатывания таймаута можно перейти к Fallback или бросить исключение дальше. Без таймаута попытка обратиться к зависшим сервисам может “дожить до миллиона лет”.
   Как работает: В Spring Boot для операций предусмотрен модуль TimeLimiter, который можно использовать для задания максимального времени исполнения метода.
4. Rate Limiter (ограничение пропускной способности)
   Зачем нужен: RateLimiter (ограничение скорости запросов) позволяет предохранить сервис от перегрузки большим числом одновременных запросов.
   Что делает: RateLimiter особенно полезен при пиковых нагрузках или в сценариях с агрессивными клиентами. Он защищает сервис, контролируя throughput – число запросов за период. Например, если сервис может обрабатывать максимум 100 запросов в секунду, RateLimiter задаёт эту скорость. Если приходят лишние запросы, сервис сразу возвращает ошибку о превышении лимита или временно задерживает обработку.
   Как работает: RateLimiter делит время на равные циклы (time buckets) и выдает фиксированное число разрешений (permits) на каждый цикл. Например, в каждой минуте даётся 100 разрешений; как только они исчерпаются, последующие вызовы либо отклоняются, либо ждут начала следующего периода.
5. Fallback (запасной ответ)
   Зачем нужен: Fallback (запасной механизм) нужен для того, чтобы система могла вернуть осмысленный результат или выполнить альтернативную логику вместо полного сбоя.
   Что делает: Этот паттерн предотвращает резкие провалы функциональности. После исчерпания повторов (Retry) или при открытом CircuitBreaker он срабатывает, выполняет альтернативное действие и “спасает” процесс.
6. Retry Pattern - предусматривает повторные попытки выполнения операции в случае ее сбоя.
7. Паттерн API Health Check - редставляет собой механизм мониторинга, позволяющий в режиме реального времени получать информацию о состоянии отдельных сервисов в приложении на базе микросервисов. Реализация Health Check API позволяет обнаружить проблемы на ранней стадии, что дает возможность предпринять превентивные действия до того, как они перерастут и повлияют на общую производительность системы.
8. Sidecar - паттерн, при котором дополнительные функциональные возможности, такие как логирование, мониторинг или безопасность, выносятся в отдельный контейнер (sidecar), работающий вместе с основным микросервисом.
9. Saga - разбиения сложных и длинных транзакций на более мелкие, управляемые шаги. Каждый микросервис в цепочке выполняет свою локальную транзакцию, которая может быть атомарной и возвращать систему в предыдущее согласованное состояние при ошибке.
10. Aggregator - микросервис-агрегатор собирает данные из нескольких других микросервисов и предоставляет их клиенту в одном ответе
11. Database per Service - каждый микросервис имеет свою собственную базу данных, что позволяет избежать зависимости от общей базы данных и уменьшить количество связанных между собой компонентов.

• Масштабируемость: разделение на микросервисы позволяет индивидуально масштабировать компоненты системы, упрощая управление ресурсами и обеспечивая эффективное распределение нагрузки.
• Гибкость в разработке: параллельная работа разных команд над изолированными сервисами ускоряет процесс внедрения новых функций и значительно сокращает цикл разработки.
• Устойчивость системы: нарушения в работе одного микросервиса не приводят к отказу всей системы, что существенно повышает надежность и устойчивость.
• Независимое развертывание: возможность разворачивать и обновлять микросервисы индивидуально снижает время простоев и ускоряет выпуск обновлений.
• Технологическая независимость: каждый микросервис может разрабатываться с использованием различных языков программирования и использовать разные технологии, что позволяет выбирать оптимальные инструменты для решения специфичных задач.

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

• Тест поиска максимальной производительности - пошаговое увеличение нагрузки до предельной. Длительность между шагами повышения нагрузки определяется возможностью стабилизации системы и типично равно от 5 до 30 мин. По завершении теста фиксируется предельный уровень нагрузки L0.
• Тест подтверждения максимальной производительности - контрольный тест определения максимальной производительности, проводится на нагрузке несколько меньшей чем L0 (определяется экспертно). Длительность нагрузки должна быть не меньше 1 часа. Если в процессе теста фиксируется недогруженность или перегруженность до максимальный уровень нагрузки корректируется и обозначается Lmax.
• Тест надежности - выполняется на уровне типичной нагрузки, который обычно составляет 70% от Lmax. Длительность интервала определяется требуемым уровнем доступности системы.
• Тест горизонтальной масштабируемости - запускается тест с нагрузкой 70% от Lmax после 15-20 минут выхода на стабильную нагрузку добавляются 2 пода и проверяется отсутствие роста %ошибок, рост использование CPU и роста времени ответа сервиса. После удаляется 2 пода и проверяется ортсутствие деградации сервиса.
• Тест отказоустойчивости - выполняется на нагрузке 70% от Lmax. В ходе тестирования моделируется сбой смежной системы, одного из плеч kubernetes или master сервера БД.
• Spike test - тестирование производительности подачей внезапной нагрузки, превыщающей максимальное значене пиковой нагрузки.