Анатомия повторяющихся сбоев: как мы расследуем Root Cause в чужой инфраструктуре

Стабильно падающий по четвергам сервис, который дежурный администратор привычно перезапускает перед утренним кофе, — классическая картина для многих крупных компаний. Инцидент закрывается с пометкой «временная нестабильность», пользователи возвращаются к работе, а реальная проблема консервируется на месяцы или даже годы. Управление проблемами (problem management) начинается не с первого сбоя, а с неудобного вопроса: «Почему это повторяется?». Для сервисного провайдера поиск первопричины (Root Cause) в инфраструктуре заказчика — это всегда детективное расследование с множеством неизвестных. Мы сами инициируем глубокий анализ, когда серия однотипных происшествий перестаёт быть статистической погрешностью и становится системой. Однако найти корень зла — это лишь половина дела, особенно если вы работаете в формате аутсорсинга.

Ловушка рутины: почему инциденты не становятся задачами

Главная преграда на пути к стабильности — организационная слепота. Когда авария превращается в регламентированную процедуру («если упало X, нажми Y»), она исчезает из поля зрения менеджмента как риск. Команда тратит десятки человеко-часов в месяц на латание дыр, списывая эти потери на операционную деятельность. Проблема маскируется под высокую доступность, ведь сервис «в итоге работает». Истинный простой пользователей между падением и ручным перезапуском игнорируется. В одном из наших кейсов финансовый департамент ежемесячно терял около 15% рабочего времени из-за падения внутренней системы отчётности каждые 72 часа. Каждый раз служба поддержки просто перезагружала сервер приложений, считая это особенностью старой платформы. Никто не связывал эти микро-простои с общей неэффективностью бизнес-процесса до тех пор, пока мы не собрали статистику за полгода.

Расследование первое: легаси против интеграции

В первом расследовании точкой отказа оказалась система документооборота крупного промышленного предприятия. Падения происходили строго при загрузке файлов объёмом более 50 МБ. Стандартные проверки логов приложения ничего не давали — ошибки были хаотичными. Углублённый анализ показал, что проблема крылась не в самом продукте вендора, а в стыке систем. Десять лет назад систему внедрили с расчётом на небольшие документы. За это время бизнес-процессы изменились, инженеры начали прикладывать тяжёлые чертежи, но инфраструктура осталась прежней. Сетевой экран между сканерами в цехах и сервером СУБД был настроен со старым таймаутом сессии в 30 секунд. Загрузка большого файла занимала 31 секунду. Соединение рвалось, транзакция откатывалась, сервис падал от перегрузки очередью битых запросов. Решение требовало перенастройки оборудования третьего подрядчика, отвечающего за сеть, что выходило далеко за рамки нашего контракта на поддержку ПО.

Расследование второе: ошибка в ДНК продукта

Второй случай выглядел похоже — еженедельные падения CRM-системы, — но имел принципиально иной финал. Анализ дампов памяти и профилирование нагрузки указали на утечку ресурсов внутри самого коммерческого программного обеспечения известного зарубежного вендора. При обработке определённого типа отчётов модуль генерации PDF создавал тысячи временных объектов в памяти, которые не очищались сборщиком мусора. Перезапуск сервиса просто стирал память, скрывая симптом. Здесь мы столкнулись со стеной: вендор отказывался признавать проблему, ссылаясь на «неподдерживаемый сценарий использования», хотя этот сценарий был описан в их же документации. Заказчик оказался перед выбором: переписывать всю кастомную отчётность под кривой API вендора или заставить его выпустить патч. После трёх месяцев эскалаций и предоставления технических доказательств нам удалось добиться включения исправления в следующий квартальный релиз.

Когда лечить дороже, чем болеть: осознанный отказ от решения

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

Практические шаги после нахождения Root Cause

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

Документирование всех зависимостей: необходимо составить карту, показывающую, какой компонент, принадлежащий какому владельцу (заказчик, ваш подрядчик, внешний вендор), участвует в сбое.
Формирование доказательной базы: вместо фразы «всё тормозит» нужно предоставить графики метрик, фрагменты логов и результаты нагрузочного тестирования, однозначно указывающие на источник.
Оценка стоимости простоя: переведите технические симптомы на язык бизнеса. Сколько денег теряет компания за каждый час недоступности сервиса?
Эскалация по матрице ответственности: направьте формализованный запрос владельцу проблемного компонента с указанием сроков и последствий бездействия.

Как проверить с помощью Perimeter: Платформа внешнего управления поверхностью атаки (EASM) помогает выявить подобные скрытые зависимости и аномалии ещё до того, как они станут причиной регулярных сбоев. Модули OSINT и Exposure позволяют увидеть вашу инфраструктуру глазами атакующего и обнаружить устаревшие сервисы или неправильно опубликованные компоненты, которые часто являются источниками нестабильности. Регулярный аудит конфигураций TLS и веб-серверов через платформу может указать на настройки таймаутов или ограничения ресурсов, аналогичные тем, что приводили к падению системы документооборота в нашем примере.