[Начало аудиозаписи (бодрый голос, с нотками цинизма и усталости)]
Протокол вскрытия № 666-IT/2025. Дата: 17 мая 2025 года. Время: 05:30.
- Я, ведущий DevOps-патологоанатом Сисадминов А.А., приступаю к патологоанатомическому исследованию неопознанного распределенного монолита, поступившего из ООО "Светлое Будущее" после фатального падения системы, зафиксированного 16 мая 2025 в 23:58 по московскому времени.
- Присутствуют: я, младший специалист Логинов П.Р., стажер Архитекторова Н.Ю.
- Итак, начнем. Внешний осмотр. Перед нами типичный корпоративный монолит — старожил цифрового мира. Судя по следам от PHP 5.3 в виде комментариев к коду, датированным 2011 годом, ему не меньше 14 лет. Внушительный возраст для любой системы в кровавом Энтерпрайзе, не находите, Логинов?
- Да, это почти живой мамонт!
- Отмечаю критическую анемию документации. В репозитории — одинокий README.md от 2012 года с гордой надписью "TODO: написать документацию".
- Так, что у нас тут… Kubernetes? О, да! Модный, молодежный. Оркестрация уровня «дирижер в запое». Поды висят в CrashLoopBackOff чаще, чем разработчики этого чуда видят кофейный аппарт. Логи… о, мда, логи! «Something went wrong», «Error: null», «PANIC: KERNEL PANIC (not really, just kidding, or am I?)». Креативненько, ничего Логинов, возьмите образцы на анализ.
- Первичный осмотр выявляет множественные очаги копипасты. Особенно вопиющий случай — модуль авторизации. Код проверки прав доступа размножен 47 раз с минимальными правками. Это уже не просто технический долг, это цирк абсурда ролевых моделей!
- Вижу следы восьми разных фреймворков, некоторые из которых не совместимы. Это мне напоминает "инновационный борщ, тёщи, приправленный усушенными котлетками и жаренными пельменями", брр. А вот это что? Закомментированный кусок кода с пометкой «// Игорь, это не трогай, я сам не знаю, как оно работает, но без него все падает!!!11». Игорь, если ты это слышишь, ты был не прав – оно и с ним упало. Из мешанины использованных языков программирования в разных модулях, можно предположить, что разработчики стремились изобрести свой высокоуровневый Brainf**k, совсем чуточку не успели.
- Ага, вот и причина непосредственного отказа. Один из «сервисов» решил, что ему мало 128 Гб оперативной памяти и попытался сожрать еще столько же из свопа. Классический OOM Killer пришел и сделал свою работу. Но это, так сказать, орудие убийства. Причина отказа куда глубже.
[идет продолжительная работа]
- Отказ наступила из-за необратимых изменений кода, навороченных за 13 лет разными разработчиками с их "уникальным видением". Рекомендации родственникам: кремация кодовой базы и старт с нуля. Пациент был нежизнеспособен с момента зачатия идеи в воспаленном мозгу тимлида.
- Ладно, хватит лирики. Пойду оформлять официальный протокол, Логинов, мне нужны результаты анализов. Эти бюрократы из «МинЦифЗдрава» требуют всё по форме.
[Щелчок выключения диктофона]
Заместитель начальника Отдела цифровой патологии и реанимации информационных систем
ПРОТОКОЛ № 666-IT/2025 патологоанатомического вскрытия информационной системы
Наименование «ИТ» организации, в которой производится вскрытие: Отдел цифровой патологии и реанимации информационных систем Департамента по надзору за стабильностью критической инфраструктуры.
Дата и время поступления системы: 17.05.2025, 04:48 (MSK)
Идентификатор «умершего»: Проект «Прорыв-2012», версия - неизвестная.
Возраст (время эксплуатации до фатального сбоя): 14 лет, 3 месяца, 2 дня (в режиме «постоянно падает, но мы поднимаем»).
Дата и время «полного отказа»: 16.05.2025, 23:58 (MSK)
Основной «клинический» диагноз (предварительное заключение службы эксплуатации): «Все сломалось, ничего не работает, пользователи в ярости, не могут закрыть спринт».
Дата и время вскрытия: 17.05.2025, 05:30 (MSK)
Вскрытие производил: Ведущий DevOps-патологоанатом Сисадминов А.А.
Присутствовали: Младший специалист по цифровой некроскопии Логинов П.Р., стажер Архитекторова Н.Ю. (сбежала через 15 минут с криком «О боже! Да я лучше бухгалтерию, буду переводить на метод ФИФО!»).
НАРУЖНЫЙ ОСМОТР СИСТЕМЫ: «Кожные пользовательские интерфейсы» недоступны, ответ сервера HTTP 503 (Service Unavailable) на всех эндпоинтах. «Трупные ошибки в логах» обильные, хаотично распределены по всем компонентам системы. «Трупное зависание процессов» наблюдается в 6 из 8 основных модулей. Сопроводительная документация-анамнез разработки фрагментарна, содержит ненормативную лексику и наскальные рисунки, не относящиеся к делу. Архитектурная схема представлена в виде эскиза на длинном бумажном чеке из КБ, вызывает сомнения.
ВНУТРЕННЕЕ ИССЛЕДОВАНИЕ СЕРВИСОВ И ПОЛОСТЕЙ СИСТЕМЫ:
«Центральная нервная система Оркестратор Kubernetes»: Версия 1.25.х (устаревшая). Множественные Pod'ы в состоянии CrashLoopBackOff и ImagePullBackOff. Обнаружены некорректно сконфигурированные readiness и liveness пробы, приводящие к преждевременному «умерщвлению» работоспособных экземпляров. Конфигурационные файлы содержат критические данные в открытом виде.
«Сердечно-сетевая система межсервисного взаимодействие»: Топология сети избыточно сложная, напоминает «Гордиев узел». Задержки при взаимодействии между «микросервисами» достигают нескольких десятков секунд. Обнаружены следы использования самописного протокола поверх HTTP/1.1 для передачи бинарных данных, что приводило к их регулярной закупорке каналов связи. «Микросервисы» по факту являются монолитными приложениями, упакованными в Docker-контейнеры, с высоким уровнем связанности (tight coupling).
«Дыхательная API Gateway система»: API Gateway перегружен из-за отсутствия кэширования и неоптимальных запросов от фронтенда. Модуль «AuthService» демонстрирует признаки «гипертрофии» (размер Docker-образа 3 Гб) и «кислородного голодания» (регулярные OOM Killed). Обнаружены многочисленные хардкод-адреса зависимых сервисов.
«Пищеварительная база данных»: Основная СУБД PostgreSQL – горизонтально шардированная. Структура БД ненормализована, наименования таблиц и полей не соответствуют общепринятым стандартам (например, tbl_prod_final_v2_important). Индексы на часто запрашиваемых полях отсутствуют. Обнаружены следы «несварения» данных (неконсистентность) между репликами. Обнаружена метастаза в виде документно-ориентированной MongoDB из одной коллекции, c полу структурированными данными.
«Опорно-двигательная кодовая база»: Код написан на смеси Python, Go и Node.js (в рамках одного «микросервиса»), в наличии остаточные следы PHP. Присутствуют многочисленные «велосипеды» (самописные решения для стандартных задач). Уровень покрытия тестами – предположительно, менее 5%. Обнаружены закомментированные участки кода с пометками «не трогать, магия» и «костыль, убрать перед релизом».
ПАТОЛОГОАНАТОМИЧЕСКИЙ ДИАГНОЗ:
Основное «заболевание»: Острая декомпенсированная архитектурная недостаточность, развившаяся на фоне тотального игнорирования принципов проектирования распределенных систем и DevOps-практик. Тип: «Распределенный Монолит с полиорганной дисфункцией микросервисов».
Осложнения: Синдром каскадного отказа модулей. Терминальная стадия технического долга. Критическая зависимость от «магического кода Игоря», о чем свидетельствуют множественные коммиты. Фатальные уязвимости безопасности.
Сопутствующие «заболевания»: Хроническое отсутствие автоматизированного тестирования. Дефицит компетентной документации. Синдром «Неприятия чужой разработки» (NIH) в тяжелой форме.
ЗАКЛЮЧЕНИЕ О ПРИЧИНЕ «ОТКАЗА» СИСТЕМЫ: «Отказ» информационной системы «Прорыв-2012» наступила в результате совокупности критических архитектурных просчетов, некомпетентной реализации, отсутствия контроля качества и пренебрежения базовыми принципами разработки и эксплуатации ПО. Непосредственной причиной остановки функционирования явился отказ модуля «AuthService» вследствие исчерпания выделенных ресурсов памяти (OOM Killer), что вызвало цепную реакцию отказа зависимых компонентов. Система стала нежизнеспособна в долгосрочной (и, как оказалось, краткосрочной) перспективе.
Признать проект «Прорыв-2012» полностью несостоятельным.
Провести служебное расследование с целью выявления ответственных за принятие губительных архитектурных и технических решений.
Останки системы (репозитории, артефакты сборки, конфигурации) архивировать с пометкой «Крайне токсично. Не реанимировать!».
Команде разработки в полном составе пройти курсы повышения квалификации по темам: «Основы архитектуры ПО», «DevOps для чайников», «Тестирование – это не больно».
При планировании аналогичных проектов в будущем закладывать бюджет на привлечение внешних ИТ-архитекторов и независимых стейколдеров.
Ведущий DevOps-патологоанатом
___________________ Сисадминов А.А.
М.П. (Отдела Цифровой Патологии)
