Software Engineering - Евгений Сулейманов

CPU почти пустой. А сервис уже лежит.

Друзья, вышла запись моего доклада с JPoint - "Анатомия зависания: когда thread pool закончился, а CPU почти пустой".

Память в порядке. В логах почти нет ошибок. Но запросы зависают, пользователи жалуются, а по графику CPU кажется, что запас производительности ещё огромный.

В рамках этого доклада мы разбираем обычный Spring MVC-сервис: Tomcat, Hikari, база данных и внешний HTTP-вызов. Никакой экзотической архитектуры.

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

Ресурсы для вычислений есть. Свободных потоков для обработки запросов - уже нет.

Но увидеть этот эффект - только начало. Дальше нужно понять:

• Где именно образовалась очередь: в потоках Tomcat, соединениях к БД или HTTP-клиенте?

• Какие метрики покажут причину, а не просто подтвердят, что пользователю плохо?

• Что менять в настройках: какие таймауты задавать, где ограничивать параллелизм и как согласовать лимиты между пулами?

В докладе мы проходим этот путь на живом сценарии: от зависших запросов до диагностики и исправлений. Чтобы вместо "перезапустили - вроде помогло" был понятный порядок действий.

Что бы вы проверили первым, если сервис не отвечает, а CPU свободен? Держите свой ответ в голове при просмотре.

▶️ "Анатомия зависания" на YouTube

▶️ "Анатомия зависания" на VK

10 лет преподавания.

Друзья, в этом году уже 15 лет, как я разрабатываю системы и 10 лет как начал преподавать разработку. В честь этой знаковой для меня даты я сделал анализ, как именно изменилось само преподавание за это время.

10 лет назад хорошим итоговым проектом для разработчика мог быть Spring Boot + REST + БД + JWT + Docker + тесты.

Сегодня это по-прежнему хороший проект.
Но, на мой взгляд, это уже примерно 40% пути.

Записал видео о том, как за это время изменились требования к разработчику - и почему массовое обучение за этими изменениями часто не успевает.

Для себя я пришел к трем связанным навыкам:

• уметь сделать систему руками
• уметь видеть ее целиком
• уметь довести изменение до ПРОДа.

И отдельно - почему с появлением AI эта планка не снижается, а скорее растет.

Получилось не столько про конкретные курсы, сколько про то, как сегодня развиваться инженеру.

И отдельно спасибо за вашу поддержку все эти годы 🙏

• Ссылка на видео на YouTube
• Ссылка на видео в VK

Друзья, все-таки Пятница, поэтому техничесий материал уже завтра. А пока, на фоне хайпа курсов для аналитиков...

Искусство, которое мы заслужили…
Готовимся к годовому перфоманс ревью ☺️

Друзья открываю набор на обновленный "Системный дизайн в деле".

Это финальный набор в 2026 году.

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

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

Мы не просто добавим знакомые паттерны, а пройдем весь путь:

Увидели проблему → разобрали причины и теорию → сравнили варианты → приняли решение → реализовали → проверили результат.

Архитектурный фундамент курса сохраняется. Главное обновление - теперь решения будем проверять непосредственно в коде, метриках и поведении системы.

Программа

• Неделя 1. Разбираем монолит, определяем требования и контексты, начинаем выделять сервисы. DDD, C4, ADR и коммуникации.

• Неделя 2. Сохраняем корректность после разделения. Saga, Transactional Outbox, Inbox, CDC, идемпотентность и CQRS.

• Неделя 3. Проверяем систему под нагрузкой и на сбоях. Ретраи, перегрузка, кэширование, масштабирование, метрики, трейсы и SLI/SLO.

• Неделя 4. Готовим выпуск и сопровождение. Безопасность, миграции, релизы, откат и ArchOps.

На выходе - репозиторий с переработанной системой, схемами, контрактами, ADR и результатами проверок.

И главное - опыт, позволяющий объяснить не только что вы построили, но и зачем, какой ценой и как проверяете, что решение работает.

Формат: 4 живые встречи, небольшие группы. Между встречами - самостоятельная практика и персональное ревью архитектурных решений. Работа с кодом и задания потребуют времени.

Для кого: backend-разработчики и техлиды с опытом работы с API, базами данных и интеграциями.

Старт: 2.11.2026
Участие платное
Заявка на участие: ССЫЛКА НА ФОРМУ

Как меняется обучение?

В этом году уже 10 лет, как я занимаюсь преподаванием и сейчас делаю большой анализ, как за это время (в хорошем смысле) "усложнились" программы обучения по всем направлениям.
Самое главное для меня - чтобы подготовка соответствовала тому, с чем инженеры сталкиваются на ежедневной основе.

Именно поэтому приходится постоянно обновлять программы. По 2-3 раза в год.

Ключевой вопрос: за что именно инженер способен отвечать?

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

Это разный масштаб работы. И переход между этими уровнями не происходит автоматически вместе со стажем или новым грейдом.

Именно эту связку сейчас усиливаю в интенсиве "Системый дизайн в деле". Хотел сделать в следующем году, но решил уже в ближайшем наборе использовать обновленный подход.

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

Но сейчас добавляю сквозную практику на работающей системе: будем не только проектировать изменения, но и своими руками проводить их через код, проверять и наблюдать последствия.

На старте у нас будет готовый монолит. В течение четырех недель будем постепенно разделять его на микросервисную систему.

Сначала разберемся, как он устроен, где у него реальные проблемы и что именно хотим улучшить. Посмотрим на код, зависимости, данные и поведение под нагрузкой. Зафиксируем исходное состояние, чтобы потом было с чем сравнивать.

А дальше начнем выделять части и менять взаимодействия.

Причем часть проблем, с которыми мы столкнемся, появится именно потому, что мы сами разделили систему.

• Разнесли данные по отдельным хранилищам. Теперь изменения, которые раньше выполнялись в одной транзакции, могут завершиться только частично.
• Заменили локальный вызов сетевым. Получили тайм-аут. Операция не выполнилась или мы просто не дождались ответа? Можно ли безопасно повторить запрос?
• Перевели обработку на события. Запрос приняли, но пользователь еще не видит результат. Это допустимая задержка, зависшая обработка или потерянное изменение? Как отличить одно от другого?

И вот здесь будем останавливаться и разбираться.

Не сразу добавлять очередной паттерн. Сначала воспроизведем проблему, посмотрим на нее в коде и метриках. Поймем, какую гарантию потеряли и какая нам действительно нужна.

Затем разберем теоретические основы, возможные решения и ограничения каждого. Выберем подходящий вариант, реализуем и снова проверим систему.

Transactional Outbox, Saga, идемпотентность, CQRS и остальные темы будут частью этого пути. С конкретной причиной применения и последствиями, которые можно исследовать.

Меня здесь интересует не только "заработало", но и "что именно стало лучше и чем мы за это заплатили".

• Запросы стали быстрее, но результат теперь появляется с задержкой?
• Компоненты можно выпускать независимо, но восстановление после сбоя стало сложнее?
• Убрали одно узкое место, но получили другое?

Это уже предметный разговор об архитектуре. Есть исходная проблема, решение и наблюдаемый результат.

И после успешной проверки работа не заканчивается.

Нужно определить, что мониторить, как обнаруживать нарушения, как восстанавливать обработку. Поддерживать связь между кодом, контрактами, схемами и причинами принятых решений.

Это и есть важная для меня часть ArchOps: архитектура продолжает жить вместе с системой, а не остается документом, который согласовали перед разработкой.

В этом смысле обновление интенсива продолжает разговор о профессиональном росте.

Можно глубже изучать технологии, но так и не получить практики выбора: что менять, зачем, какие последствия принять и как проверить результат. Тогда следующая сложная задача снова начинается с ожидания, что кто-то другой примет основные решения.

Мне хочется, чтобы и эту часть работы студенты тоже проходили.

Чтобы за словами "я понимаю эту архитектуру" стояло не только умение ее объяснить, но и конкретный опыт.

Возможно, мы не понимаем, что сейчас происходит с рынком разработки.

Недавно писал, что IT-рынок не рухнул, а расслоился.

Деньги в нем по-прежнему есть. Сильные инженеры по-прежнему нужны. Но все хуже работает старая формула:

еще несколько лет опыта → следующий грейд → следующая вилка.

И чем выше уровень разработчика, тем это заметнее.
Еще 5 лет назад все было довольно ясно:

• Учишься лучше писать код.
• Разбираешься глубже в своем стеке.
• Берешь более сложные задачи.
• Начинаешь видеть проблемы раньше других.

Но сейчас особенно явно возникает неприятный вопрос:

```
а что именно должно стать следующим уровнем?
```

• Еще лучше знать Spring?
• Еще глубже JVM?
• Выучить очередной фреймворк?
• Стать быстрее писать код?

Проблема в том, что именно производство кода сейчас дешевеет быстрее всего.

Не в смысле "разработчики завтра не нужны".

А в гораздо более приземленном смысле: все больше работы, которая еще недавно отличала сильного разработчика от среднего, становится проще выполнить с помощью инструментов.

• Написать реализацию.
• Разобраться в чужом коде.
• Провести рефакторинг.
• Добавить тесты.
• Подготовить документацию.
• Найти несколько вариантов решения.

Порог входа во все это постепенно снижается.

А значит, само по себе умение хорошо производить код все сложнее использовать как единственный профессиональный дифференциатор.

И вот здесь интересно посмотреть на другую сторону рынка.

Чем выше ответственность человека, тем меньше его ценность определяется количеством написанного кода.

От него ждут другого.

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

А потом сделать так, чтобы через год команда все еще понимала, почему система устроена именно так.

И здесь для меня соединяются два последних наблюдения.

С одной стороны, рынок все внимательнее смотрит на зону ответственности инженера, а не просто на количество лет в профессии.

С другой - то же самое происходит с архитектурой.

Я недавно писал, что архитектура для меня давно перестала быть набором правильно нарисованных компонентов и паттернов.

Но есть еще один шаг.

Мало уметь принять хорошее архитектурное решение. Нужно уметь провести его через весь жизненный цикл.

Условно:

проблема → ограничения → гипотеза → решение → реализация → проверка → эксплуатация → наблюдение → изменение.

Причем самое интересное часто начинается после слова "решение".

Потому что схема может выглядеть прекрасно, при этом:

• реализация покажет скрытую связанность.
• нагрузочные тесты - неверное предположение.
• ПРОД - неожиданный режим деградации.

Через полгода код уйдет вперед, а архитектурная документация останется описывать систему, которой больше не существует.

Постепенно меняется само определение сильного инженера.

Раньше большой частью профессионального капитала было:

"я знаю, как это реализовать".

Сейчас все больший вес получает:

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

Это не обязательно роль архитектора или новый тайтл.

Наоборот, думаю, что эта граница будет все сильнее проходить внутри обычной инженерной работы.

Это не значит, что завтра всех заменит ИИ и "нужно срочно переучиваться".

Моя основная мысль:

можно еще несколько лет становиться лучше в той части профессии, ценность которой относительно других частей постепенно снижается.

При этом следующая ступень находится совсем рядом - просто она уже не столько про написание кода.

Она про способность отвечать за техническое решение целиком.

И мне кажется, что в ближайшие несколько лет разница между этими двумя траекториями станет намного заметнее, чем сейчас.

Какие мысли будут у сообщества?

Друзья, завтра Пятница и многим нужно будет давать статус апдейт лиду за прошедшую неделю. Помните…

Добрый вечер...

Что такое хорошая архитектура

Недавно на проекте завязался спор - "что такое хорошо и что такое плохо?" 🙂
Раньше я во многом смотрел на архитектуру как на правильную структуру системы.

Хорошие границы. Понятная декомпозиция. Контракты между компонентами. Подходящие паттерны. Нормальная модель данных. Аккуратные диаграммы.

Все это по-прежнему важно. Но со временем я перестал считать этого достаточным.
Можно нарисовать очень красивую архитектуру, которая плохо переживает отказ одной зависимости.

• Можно идеально разделить систему на микросервисы и получить распределенный монолит, где любое изменение требует синхронизации пяти команд.
• Можно правильно применить cache-aside и неожиданно изменить договор с пользователем о свежести данных.
• Можно выбрать Kafka там, где она действительно уместна, а через год обнаружить, что никто уже не способен ответить, какую версию данных пользователь должен видеть прямо сейчас.
• Можно построить технически элегантное решение, которое стоит бизнесу в пять раз дороже более скучной альтернативы.
• И можно иметь прекрасную C4-модель системы, которая практически ничего не говорит о том, что произойдет, когда один из квадратиков перестанет работать.

Поэтому сегодня первое, что мне интересно в архитектурном решении, - не количество паттернов и не красота схемы.

Мне интересно другое.

Какие ограничения мы учитывали? От чего сознательно отказались? Где находится цена выбранного решения? Что произойдет при частичном отказе? Как система будет деградировать? Как ее обновлять? Как откатывать изменения? Что станет узким местом при росте нагрузки? Кто будет сопровождать все это через три года?

И особенно важный вопрос: насколько хорошо мы понимаем последствия собственного решения?

Потому что у архитектуры почти никогда нет варианта "правильно".

• Берем Redis - выигрываем latency, платим сложностью: консистентность и инвалидация.
• Переходим на асинхронность - уменьшаем связанность по времени, платим сложностью наблюдения за состоянием операции.
• Дробим систему - получаем независимость компонентов, но добавляем сеть, распределенные отказы и организационную стоимость.
• Оставляем монолит - сохраняем простоту взаимодействия, но со временем начинаем платить за связанность изменений.

Архитектура практически всегда выглядит как:

что именно мы готовы купить и какую цену готовы за это заплатить.

Поэтому хорошая архитектура для меня сегодня - не система, в которой все сделано "по best practices".

Это набор осознанных компромиссов, последствия которых команда понимает и умеет контролировать.
А хорошая архитектурная схема - это уже просто способ этот разговор зафиксировать.

Рынок IT не рухнул. Он расслоился.

В течение последних нескольких месяцев собирал ряд данных по текущему ландшафту (техническому и финансовому) нашего IT рынка.

Если смотреть на цифры, видно довольно простую картину:

• в IT по-прежнему есть деньги
• но сам факт работы "в айти" уже почти ничего не гарантирует
• все сильнее решают грейд, роль, компания и масштаб ответственности

Что особенно бросается в глаза:

1. Главный рост - до Senior.
Самые заметные скачки дохода происходят на переходах Junior → Middle и Middle → Senior.
Дальше рост уже не такой "вкусный".

2. Lead - уже не волшебная кнопка.
Сам тайтл больше не гарантирует резкий скачок дохода.
Если не растет реальная зона ответственности, вилка растет намного слабее, чем многие ожидают.

3. Менеджмент, архитектура и ML по-прежнему дорогие.
Рынок хорошо платит за тех, кто отвечает не только за код, но и за решения, систему и результат.

4. Компания меняет вилку сильнее, чем кажется.
Иногда разница между работодателями влияет на доход не меньше, чем разница между специализациями. Банки дают существенно более высокие ЗП по сравнению с другими компаниями.

Мой главный вывод такой:

эра "зайти в IT и ЗП сама вырастет вместе с рынком/перейду в соседнюю компанию на +100К" заканчивается.
Но спрос на сильных инженеров никуда не делся и даже усилился.

Просто теперь рынок намного внимательнее смотрит, за что именно он готов платить.

Наиболее перспективные технические направления на ближайшие 2-3 года, по моему мнению:
• Архитектура
• DevOps

Наибольшие сложности (здесь прямо беда и перспективы крайне туманные):
• FE
• Manual QA

Хороший разработчик и хороший инженер - не всегда одно и то же.

Чем дольше я работаю с ПРОД-системами, тем сильнее разделяю две способности: хорошо реализовывать решение и хорошо принимать инженерные решения.

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

Причем локально код может быть совершенно нормальным.

Возьмем простой пример.

Внешний сервис периодически отвечает по таймауту. Разработчик добавляет ретрай с бэкофом. Код хороший, библиотека подходящая, тесты зеленые.

Но инженерный вопрос начинается чуть раньше:

а можно ли эту операцию вообще безопасно повторять?

Если внешний сервис успел выполнить операцию, а потерялся только ответ, ретрай может выполнить ее второй раз.

И тогда проблема вообще не в реализации ретрая.

Проблема в том, что мы неправильно поняли семантику операции.

То же самое происходит постоянно.

Можно идеально реализовать кэш - и получить устаревшие данные там, где пользователь ожидает актуальное состояние.

Можно красиво вынести работу в Kafka - и внезапно превратить понятную синхронную ошибку в пятнадцатиминутное отставание данных, которое никто не мониторит.

Можно сделать корректную транзакцию - но держать ее открытой во время сетевого вызова и однажды положить пул соединенийl.

Можно поднять Prometheus, Grafana - и все равно не иметь возможности ответить на вопрос: получил ли пользователь правильный результат?

Во всех этих случаях разработчик мог хорошо выполнить свою работу.

Но инженерная задача была шире самой реализации.

Поэтому мне все меньше нравится оценивать сильного специалиста по тому, насколько сложный код он способен написать.

Код - только один из артефактов инженерного решения.

Гораздо интереснее, какие вопросы человек задает до того, как начинает писать код.

• Что произойдет при частичном отказе?
• Какую гарантию мы действительно даем?
• Что будет при конкурентном выполнении?
• Где находится источник истины?
• Что произойдет, если зависимость станет отвечать в десять раз медленнее?
• Можно ли это решение безопасно изменить через два года?
• Как мы узнаем в ПРОДе, что оно перестало выполнять свое предназначение?

И что особенно важно - какие последствия нашего локального решения появятся за пределами компонента, который мы сейчас меняем.

Наверное, поэтому хороший инженер для меня - это не человек, который обязательно знает больше технологий.

Это человек, который умеет смотреть на изменение не как на набор классов, таблиц и ендпоинтов, а как на изменение поведения всей системы.

И здесь, кстати, ИИ ничего принципиально не меняет. Он просто делает эту разницу заметнее.

Получить качественно написанную реализацию становится все дешевле.

А понять, какую реализацию вообще можно считать правильной, по-прежнему сложно.

Поэтому одна из самых ценных инженерных привычек сейчас - после вопроса:

"Как это реализовать?"

научиться автоматически задавать второй:

Что после этого изменится в системе и что может пойти не так?"

Вот где, на мой взгляд, разработка заканчивается как просто производство кода и начинается инженерия.

Друзья, прошел JVM Day.

В этот раз выступал с докладом про кэширование - "Превратности кэша: как Redis спасает latency и тихо ломает корректность".

Мне хотелось сделать не очередной рассказ про @Cacheable, TTL и "не забывайте инвалидировать кэш". Поэтому весь доклад строился как расследование одной системы: мы последовательно решали вполне реальные проблемы - высокий p95, нагрузку на PostgreSQL, устаревшие данные, stampede, холодный кэш, несовместимость данных при релизах - и почти каждый раз обнаруживали, что хорошее на первый взгляд исправление меняет систему сильнее, чем кажется, и открывает следующий класс проблем.

В итоге для меня весь доклад свелся к нескольким довольно простым, но важным мыслям:

• hit ratio показывает, как часто мы нашли значение, но не говорит, можно ли этому значению верить
• evict после выполнения метода еще не означает evict после успешного коммита
• cache miss не должен автоматически превращаться в SQL-запрос
• кэш - это не просто ускоритель, а договор о том, насколько старые данные система имеет право показать ради скорости.

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

Для меня это обычно лучший критерий технического доклада: не когда аудитория просто соглашается с набором "best practices", а когда после выступления люди начинают сравнивать услышанное со своими ПРОД-системами и спорить о границах применимости решений.

Спасибо организаторам JVM Day и всем, кто пришел, голосовал на интерактивах, задавал вопросы и продолжил обсуждение после доклада.

В целом, огранизация мероприятия была на очень высоком уровне.

Ссылка на презентацию

Запись, насколько понимаю, появится позже - когда будет, тоже поделюсь.

А пока главный вывод оставлю здесь:

Кэш - это не место хранения быстрых ответов. Это контракт о том, когда системе разрешено отвечать не из источника истины.