На работе computer science, программная инженерия и software design тебе никогда не понадобятся, говорили они. Просто почитай учебник "System Design. Общие принцип прохождения интервью по проектированию ИТ-систем" (рекомендую кстати к изучению в любом случае :), и норм.

...

Таких отчётов с hard work у меня десятки =>
"просто так получилось" (с) )))
И дальше такого дерьма будет только больше.

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

...Мне кажется, у нас весь проект такой. Т.е. один большой артефакт.
...У нас в проекте долго была проблема, которая рождала множество багов. В проекте есть веб-сокет соединение. Изначально система писалась с расчетом на то, что сообщения будут приходить в определенном порядке. Т.е. синхронно, асинхронность в расчет не была взята. Это не было сделано специально, просто так получилось. И это работало, пока не был переписан бэкендовый сервис, который отправляет сообщения. Он перестал гарантировать порядок сообщений. Из-за этого началось большое количество проблем на фронте, потому что он не был готов к этому вообще. Получается, что следствием этого было возникновение багов, а причина багом не была.
...Был у нас баг, который положил всю систему многим клиентам. Для переводов у нас используется weblate - опен-сорсная библиотека для хранения и версионирования переводов. Он жил в одном инстансе. Он обслуживал все запросы от всех клиентов, потому что все переводы им у себя кэшировались. В какой-то момент, точно не помню из-за чего, этот кэш инвалидировался и все запросы стали идти на сервис. Под нагрузкой он лег, возвращал ошибки, как следствие система не грузилась. Был большой инцидент, много клиентов было затронуто.

...Видите какой уровень вложенность Depends fastapi?
Сначала в каждом сервисе, а точнее - в каждом роутере мы должны сформировать функцию для инъкции в обработчик роута/запроса, которая в свою очередь: А) Парсит Authorization хедер (Зависима на библиотеку связанную с авторизацией, тоже вызывает Depends) Б) Проверяет накостыленный RBAC (некоторые запросы могут игнорировать его, например... Внутренние! Ох уж этот распределенный монолит) С) Наконец формирует экземпляр класа в котором запакована вся CRUD логика для обработки запроса.
Это же какое-то дерьмо.
Это не просто боксинг, это мета-боксинг да еще с кучей зависимостей. Это совсем не читаемо и неудобно, ничего не понятно. Пытаясь разобраться в коде или внести новые изменения в тот же самый post на создание Entity, если мы видим этот код и "стиль" первый, второй, третий или даже четверный раз, нам надо посмотреть в "Сценарий" и еще в 2 библиотки.
Это не неудачная абстракция, это откровенное дерьмо. Пару месяцев назад я видел подход, когда в модель базы добавляли методы для обработки круда fastapi, это примерно один и тот же боксинг, но в последнем больше смысла чем в этом Сценарии.

...Старое приложение хостилось еще на iis, после одного из релизов начало падать и перезагружаться стабильно 1 раз в день.
Провозился я, будучи еще мидлом около месяца с поиском этой ошибки.
Оказалось - рекурсивное событие в коде. Нашли с помощью дампа памяти, который сняли перед падением.
Перепробовали все мелкие фиксы, добавляли памяти, увеличивали лимиты и т д.
Не хватало более широкого понимания картины, для начала стоило:
- понять, когда начала появлятся ошибка;
- пересмотреть код с последних релизов;
- сделать выводы и повторить последние два пункта;

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