Monitoring показывает 200 OK, а внутри 500 Error. Дебаггинг самооценки инженера

Вечер. Сложный тикет закрыт, тесты зеленые. Заказчик доволен, ПМ ставит 🔥 в чат, на карту упала зарплата, которая в Nx раз выше средней по региону.

Внешний мониторинг (Grafana вашей жизни) показывает стабильное плато и Status 200 OK. А внутри, на уровне ядра, возвращается 500 Internal Server Error.

Ощущение, будто ты Mock-объект. Фейковая заглушка, которая только имитирует полезную деятельность и возвращает захардкоженные ответы. Кажется, что внутри спагетти-код, TODO-комментарии пятилетней давности и костыли на изоленте. И фоном крутится демон с приоритетом Critical:

“Рано или поздно они запросят git blame, заглянут в исходники и поймут, что я ничего не умею. Все узнают, что я джун, который просто удачно притворяется сеньором”.

Это баг в модуле самооценки, известный как “Синдром Самозванца”. В нашей инженерной реальности – это критический рассинхрон между показателями Внешнего Мониторинга (карьера, деньги, фидбек) и Unit-тестами (внутреннее ощущение компетентности).

Давайте проведем Post-Mortem анализ этого инцидента. Почему инженеры с 10-летним опытом ^[1] боятся, что их раскроют?

Баг 1. Сравнение своего Бэкенда с чужим Фронтендом

Мы часто попадаем в классическую ловушку некорректного сравнения архитектур. Что мы знаем о себе? Мы имеем root доступ к своему Бэкенду и базе данных. Мы видим:

• Тот самый if-else костыль, который пришлось вставить в 3 ночи, чтобы релиз не упал.

• Историю поиска: “как центрировать div” или “разворот списка Python” на десятом году карьеры.

• Логи ошибок, паники при деплое и часы прокрастинации на Reddit.

А что мы видим у других (коллег, спикеров на HighLoad, авторов статей на Хабре)? Мы видим их отрендеренный Фронтенд:

• Красивый UI успешных кейсов.

• Уверенный голос на дейли.

• Статьи “Как мы переписали монолит на микросервисы за выходные и сэкономили миллион”.

Попытка сравнить свои сырые логи (stderr) с чужой главной страницей (index.html) неизбежно выдает TypeError: Incompatible Types.

Мы просто не видим, как этот “Гениальный Тимлид” пил валерьянку перед митингом, а “Крутой Архитектор” скопипастил кусок решения со StackOverflow и потом два часа не мог понять, почему оно не билдится. Нам виден только фасад. Из-за этого возникает иллюзия, что легаси и бардак под капотом только у нас. Спойлер: бардак, скорее всего, у всех. Просто у сеньоров он лучше документирован и обернут в Docker-контейнер, чтобы не воняло.

Баг 2. Deprecation Warning и гонка фреймворков

Второй источник ошибки ^[2] – скорость обновления зависимостей в нашей индустрии. В медицине анатомия человека не меняется тысячелетиями. В юриспруденции законы живут десятилетиями. В IT твои знания устаревают быстрее, чем молоко в холодильнике.

Ты потратил 3 года на изучение крутого фреймворка, стал экспертом. А сегодня утром на HackerNews вышла статья: “Почему Х – это отстой, мы все переходим на Y”. В консоли твоей головы постоянно висит предупреждение: Warning: Your skills are deprecated. Please update to v.2026.0

Из-за этого возникает ощущение, что ты вечный студент, который опаздывает на лекцию. Мы путаем Фундаментальные Алгоритмы (которые не меняются) с Синтаксическим Сахаром (который меняется каждый год). Тот факт, что мы не знаем, как работает новая фича в React 19 или финтифлюшка в AWS, не делает нас плохим инженером. Это просто проблема кэширования – мы еще не загрузили новые данные.

Баг 3. Flaky Tests (Мигающие тесты)

Похоже, что конфиг нашего внутреннего “QA-отдела” сломан. Внутренние тесты на профессионализм (Self-Tests) написаны криво и почти всегда возвращают False, независимо от качества инпута.

Давайте посмотрим на код этого внутреннего теста:

Python

def test_im_a_good_engineer(self):
    # INPUT: Успешный релиз сложной фичи
    result = self.deploy_to_prod()
    
    if result == "SUCCESS":
        # ОЖИДАЕМОЕ ПОВЕДЕНИЕ: self.pride += 10
        # РЕАЛЬНОЕ ПОВЕДЕНИЕ:
        raise ImposterError("Просто повезло, QA плохо смотрели")
    
    # INPUT: Коллега спросил совета
    if self.answer_question():
         # РЕАЛЬНОЕ ПОВЕДЕНИЕ:
         raise ImposterError("Я это нагуглил 5 минут назад, я обманщик")

    # INPUT: Повышение зарплаты
    if self.salary_increase():
         # РЕАЛЬНОЕ ПОВЕДЕНИЕ:
         raise ImposterError("Рынок перегрет, они просто не нашли никого лучше")

Это классические Flaky Tests. Тест падает не потому, что система (вы) работает плохо, а потому что сама процедура проверки (Я должен знать всё наизусть и никогда не ошибаться) некорректна. Мы требуем от себя быть Википедией, но в ТЗ к живому инженеру таких требований нет. В ТЗ написано: решать задачи бизнеса.

ПАТЧ: Как пофиксить баги восприятия?

Просто “поверить в себя” – совет сомнительный (это как сказать перегретому серверу “не грейся, братан”). Попробуем применить инженерные решения.

Фикс 1. Переход на External Monitoring (Логи не врут)

Внутренние ощущения – это Client-Side Validation. Она ненадежна, зависит от браузера (настроения), погоды и уровня выгорания. Опираться на неё для принятия решений рискованно. Единственный источник правды – Server-Side Logs (Внешний мир).

• Вам платят деньги? (Лог транзакции подтвержден).

• Вас не уволили за год? (Uptime > 99%).

• Ваш код работает в проде и приносит деньги? (Status 200).

• Коллеги просят помощи? (Значит, ваша API документация востребована).

Если внешняя система мониторинга (рынок, работодатель, команда) говорит, что вы Сеньор, а внутренняя система утверждает “Ты самозванец”, то с вероятностью 99.9% ошибка на внутренней стороне. Рынок рискует своими деньгами, нанимая вас. А ваши страхи не рискуют ничем. Факты – единственная метрика, которая имеет значение в инженерии.

Фикс 2. Black Box и Кэширование

Нужно переписать интерфейс IEngineer. Сместить фокус с “я должен знать всё” (In-Memory DB) на “я умею находить решения” (High-Load Gateway). Сеньор – это не ходячая энциклопедия. Это интерфейс, который умеет эффективно маршрутизировать запросы.

Не так важно, как решена задача: написана по памяти ^[3], найдена в документации или адаптирована с индусского ютуба. Для бизнеса инженер – это Black Box.

• Input: Задача.

• Output: Работающее, поддерживаемое решение.

• Performance: Приемлемое время (Latency).

Что происходит внутри коробки – магия нейросетей мозга ^[4], Google или StackOverflow – это детали реализации. Использование Google – это не читерство, это работа с распределенной базой знаний. Мы просто “выгрузили из RAM в Cloud”, чтобы освободить память для решения текущей задачи.

Фикс 3. Brag Document (Логирование успехов)

Человеческая память работает как logrotate – старые логи удаляются. Мы отлично помним свои факапы трехлетней давности, но забываем ^[5], какую крутую фичу запилили месяц назад. Решение: Завести текстовый файл success_log.md ^[6] (или Brag Document). Например, раз в две недели записываем туда списком:

• Что я сделал?

• Что я изучил?

• Кому я помог?

Когда накатывает приступ “я ничего не умею”, открываем этот лог. Это лучший способ борьбы с когнитивными искажениями с помощью хард-данных.

Итог

Эффект Даннинга-Крюгера работает в обе стороны. Настоящая некомпетентность редко сомневается в себе. Наличие сомнений, страха облажаться и ощущения “я недостаточно хорош” – это часто техническое доказательство компетентности.

Только специалист высокого уровня способен оценить объем того, чего он еще не знает. Наша область “Неизвестного” растет пропорционально области “Знаний”. Так что этот страх ^[7] – индикатор того, что наша база знаний расширилась и соприкоснулась с новыми сложными доменами.

Если код в мастере, а прод не лежит, значит, мы на своем месте. А то, что иногда страшно – так это просто шум кулера под нагрузкой. Процессор работает.

Самое время нажать Deploy.

P.S. Коллекционирую такие баги мышления ^[8] и ищу к ним патчи в своем телеграмм-канале ^[9].