В конце августа 2025 года индустрия программного обеспечения и IT-операций столкнулась с серьезным испытанием, когда одна из ведущих платформ для управления инцидентами - PagerDuty - оказалась в центре масштабного сбоя. Этот инцидент стал уроком для множества организаций, зависящих от своевременных и точных оповещений о сбоях в своих системах. В результате бага в инфраструктуре, связанной с Apache Kafka, большая часть уведомлений перестала обрабатываться, оставив компании по всему миру "слепыми" перед лицом технических проблем. Его последствия и уроки стали предметом обсуждений и глубокого анализа в сообществе инженерных команд и специалистов по DevOps. PagerDuty - это платформа, которая используется большинством крупными и средними бизнесами для мониторинга состояния технических сервисов.
Основная её задача - быстро уведомлять ответственных лиц о любых инцидентах, чтобы минимизировать простой и оперативно реагировать на неполадки. Сбой на стороне PagerDuty, особенно затронувший обработку вызовов и уведомлений, обернулся для многих компаний реальной проблемой, ставшей причиной длительных простоев и потерь. Проблема была вызвана ошибкой в недавно введенной функции, предназначенной для улучшения контроля над использованием API и ключей доступа. Нововведение предполагало совершенствование аудита и логирования, но из-за неправильного использования библиотеки pekko-connectors-kafka для работы с Kafka, в коде провалился базовый принцип: вместо одного общего Kafka-продюсера создавался новый продюсер на каждый API-запрос. В итоге количество одновременно работающих продюсеров выросло в 84 раза по сравнению с обычным уровнем и достигло 4,2 миллиона в час.
Это аномальное количество продюсеров вызвало перегрузку кластера Kafka, который используется компанией для передачи сообщений между внутренними сервисами. Kafka начала "трешиться" - процесс, при котором система входит в состояние постоянного восстановления из-за нехватки ресурсов, особенно памяти JVM. В результате кластер исчерпал выделенный ему объем памяти, что вызвало цепную реакцию отказов. Службы, зависящие от Kafka, потеряли возможность обмениваться данными, что усилило масштаб проблемы и существенно увеличило время восстановления. Катастрофа длилась более девяти часов.
Фактически, за 38 минут до 95% входящих событий были отвергнуты, а около 130 минут 18% запросов создавали ошибки. Это привело не только к отсутствию входящих уведомлений, но и к тому, что обновления по статусу инцидента от самой компании PagerDuty не показывались на открытой странице статусов, что усугубило чувство неопределенности и паники у клиентов. Реакция сообщества и самих пользователей PagerDuty была бурной. В социальных сетях и специализированных форумах пользователи делились историями стресса и чувства абсолютной "слепоты" в критические моменты. Многие инженеры в режиме OnCall испытывали давление со стороны клиентов из-за отсутствия оповещений о неполадках в их продуктах.
Это происшествие ярко показало зависимость современных организаций от стабильности и надежности систем мониторинга. И в то же время оно подчеркнуло важность создания резервных схем оповещения и проактивного многоканального контроля, чтобы минимизировать риски при сбоях ключевых сервисов. Инцидент PagerDuty не был уникальным случаем. Аналогичные длительные простои были зафиксированы и у других инструментов для инцидент-менеджмента, таких как Opsgenie, который пережил масштабный сбой в 2022 году, продлившийся две недели. Опыт этих ситуаций указывает на необходимость переосмысления архитектуры систем оповещений, а также повышения внимания к мониторингу инфраструктуры самих инструментов для управления инцидентами.
В своем официальном отчете PagerDuty открыто признал ошибку в разработке и предоставил подробный цикл событий, вызвавших сбой. Компания также поделилась планами по улучшению: они собираются внедрить более глубокий мониторинг JVM и Kafka, а также усилить процессы управления изменениями, чтобы операторы могли быстрее и безопаснее внедрять обновления без риска подобных сбоев. Это подтверждает культуру организации, ориентированную на обучение на ошибках и постоянное совершенствование. Одним из важных уроков, вынесенных из инцидента, является понимание того, что современные распределённые системы и микросервисные архитектуры часто имеют множество скрытых точек отказа и сложных взаимозависимостей. Небольшая ошибка в одном узле способна вызвать каскадные сбои, выходящие за рамки очевидных диаграмм систем.
Это делает прогнозирование и предотвращение подобных сбоев технически и организационно сложной задачей. Для инженеров и команд, управляющих инфраструктурой, ситуация стала напоминанием о необходимости установки и поддержания многоуровневых систем резервного оповещения и контроля. Надежные планы на случай непредвиденного сбоя основного решения должны стать обязательной практикой. Мониторинг собственных инструментов мониторинга и оповещения - ключевой элемент надежности. В результате инцидента PagerDuty стало ясно, насколько важна прозрачность и оперативная коммуникация с клиентами во время аварий.
Отсутствие своевременных обновлений приводит к росту недоверия и паники, что может повлиять на репутацию и привести к экономическим потерям. В свете этого многие компании сегодня активно инвестируют в автоматизированные средства общения с пользователями и механизмы удержания внимания на процессах восстановления. Не менее важной является и культурная составляющая. PagerDuty продемонстрировала сильный фокус на создании безопасной для ошибок среды, где сотрудники не боятся признавать проблемы и учаться на них. Такой подход способствует быстрому выявлению и ликвидации сбоев, а также стимулирует инновации и устойчивость бизнес-процессов.
Сбой, произошедший с PagerDuty, сделал очевидным, что даже платформы, созданные для повышения устойчивости и контроля, сами могут стать объектом сбоев, что ставит под вопрос традиционные подходы к надежности. Это приводит к росту интереса к архитектурам с высоким уровнем избыточности и использованию принципов наблюдаемости, которые позволяют предугадывать и обходить потенциальные проблемы еще на ранних этапах. В итоге, опыт PagerDuty - яркий пример комплексности современных систем и диктатуры качества кода и архитектуры в них. Для специалистов по DevOps, инженеров по надежности (SRE) и руководителей проектов стало важным напоминанием о необходимости постоянного контроля, тщательного тестирования новых функций и готовности к быстрому реагированию в случае непредвиденных сбоев. Сегодня индустрия развивается в сторону усиленного внедрения искусственного интеллекта и автоматизированных систем управления инцидентами.
Однако человеческий фактор, грамотное планирование и резервирование останутся основой любой успешной технологии. И уроки, почерпнутые из крупных инцидентов как у PagerDuty, несомненно повлияют на стандарты построения надежных сервисов в будущем, помогая создавать более устойчивые, прозрачные и эффективные системы для управления инцидентами во всем мире. .
