Сбои в сервисах: уровни и причины

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

Уровни сбоев в сервисах

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

зеленый уровень,
желтый уровень,
оранжевый уровень,
красный уровень,
черный уровень.

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

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

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

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

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

Пример:

Представим, что у услуги 200 тысяч клиентов. В момент высокой нагрузки, в 15:00, система стабильно обрабатывала запросы 15 тысяч пользователей в минуту. Однако в 15:01 произошел сбой, и количество успешно обработанных запросов снизилось до 7 тысяч. Таким образом, доля пострадавших составит не 3,5% (7 тысяч от общего числа клиентов), а 53%, так как исходная пропускная способность была 15 тысяч запросов.

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

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

Основные виды рисков при сбоях

Репутационный риск.

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

Судебный риск.

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

Регуляторный риск.

Невыполнение требований регуляторов может привести к штрафам, а в некоторых случаях — даже к уголовным последствиям. Этот риск особенно высок в финансовом и телекоммуникационном секторах.

Финансовый риск.

Сюда относятся как прямые финансовые убытки от сбоев, так и косвенные — например, из-за необходимости компенсировать клиентам потери или нарушения SLA.

Мониторинг последствий

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

Финансовые и репутационные потери

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

Роль постмортемов и триггеров

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

Триггеры и причины сбоев

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

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

Постмортем

После устранения сбоя важно провести постмортем (postmortem) — это анализ и разбор инцидента или сбоя в системе, который произошел в процессе создания, тестирования, развертывания или эксплуатации программного обеспечения. Постмортем помогает командам разобраться, что именно пошло не так, найти слабые места в архитектуре или процессе разработки, и, самое главное, улучшить процессы, чтобы такие проблемы не повторялись.

Для проведения постмортема важно следовать структурированному подходу:

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

Постмортем чаще всего включает в себя следующие разделы:

Краткое содержание

Когда и как произошел сбой, кто был затронут, как это повлияло на пользователей и бизнес.

Причины сбоя и хронология

Какие факторы или ошибки привели к возникновению проблемы.

Процесс устранения

Как была решена проблема, какие меры были приняты для восстановления системы.

Меры по предотвращению

Какие шаги будут предприняты для предотвращения подобных инцидентов в будущем.

Работа команды QA с инцидентами

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

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

Заключение

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

Обсудить статью, узнать больше можно в телеграм каналах «Тимлиды нужны» и «Тестировщики нужны».