open to work · пишу по ночам после деплоя

Инженерные заметки
без магии и воды

$ cat blog.txt | grep --

Привет! Я Степан, программист. Здесь я разбираю реальные рабочие истории: как мы роняли прод, чинили базы данных, спорили об архитектуре — и что из этого вышло.

0статьи
0лет в разработке
0комментариев
0читателей
рабочее место разработчика
● prod: stable
☕ coffee: ∞
⌥ deploys/week: 14
PHP TypeScript MySQL React Node.js PostgreSQL Docker Kubernetes GraphQL Redis Rust (по настроению) Vite gRPC

// свежие статьи

Каждая статья — это боевая история с работы: с граблями, кодом и выводами.

DevOps

Как я перестал воевать с CI/CD и начал жить

Наш пайплайн собирался 47 минут, а падал чаще, чем прод. Рассказываю, как мы разобрали его на атомы и ускорили в 6 раз.

28 августа 2026 · 8 мин Читать →
Frontend Architecture

Фронтенд-архитектура: от спагетти к фича-модулям

Почему «папки по типам файлов» убивают крупные проекты и как мы переехали на feature-slices без остановки разработки.

14 августа 2026 · 11 мин Читать →
Databases

Postgres на пределе: как мы ускорили запросы в 40 раз

EXPLAIN ANALYZE, частичные индексы и одна очень стыдная функция в WHERE. История одного расследования.

30 июля 2026 · 9 мин Читать →
DevOps Architecture

Микросервисы в Docker: уроки, которые дал прод

12 сервисов, один docker-compose и бесконечная борьба с лимитами. Чек-лист выживания контейнеров в реальном трафике.

12 июля 2026 · 7 мин Читать →
Languages Frontend

TypeScript спас мой проект: строгая типизация на практике

Как мы включили strict-режим в легаси на 300k строк и не уволились всей командой. Пошаговый план и честные грабли.

25 июня 2026 · 6 мин Читать →
Monitoring

Наблюдаемость без боли: логи, метрики, трейсы

Инцидент длительностью в 6 часов научил нас разнице между «у нас есть логи» и «у нас есть наблюдаемость». Разбираю на примерах.

8 июня 2026 · 10 мин Читать →
Мой аватар

Гончаров Степан ·

Staff Software Engineer в финтехе. Пишу о том, с чем сталкиваюсь каждый день: распределённые системы, фронтенд-архитектура, базы данных и культура разработки. Верю, что лучший способ понять проблему — честно написать о том, как ты её решал (или не решил).