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

❗️❗️❗️ Друзья, набор на Сентябрь ❗️❗️❗️ Открываю набор на новый 8-недельный интенсив: "ИИ-дополненный процесс разработки" Последний год я довольно плотно внедряю ИИ в процессы разработки в достаточно большой компании. Не только в формате "попросить ChatGPT написать код", а на разных этапах SDLC: требования → планирование → системный дизайн → разработка → тестирование → ревью → CI/CD → ПРОД. За это время накопилось достаточно практического опыта - удачного и не очень - чтобы собрать его в отдельную программу. Зачем этот курс Новые модели, IDE, кодинг агенты, MCP, обещания в несколько раз ускорить разработку или вообще заменить значительную часть работы инженера. Что-то из этого действительно серьезно меняет разработку. Что-то пока значительно лучше выглядит в демо, чем в большом существующем проекте проекте. Мне интереснее другой вопрос: как с помощью всего комплекса современных инструментов (не только ИИ) улучшить сам процесс SDLC? Не просто быстрее написать очередной класс, а быстрее пройти путь от задачи до проверенного изменения в ПРОДе в большой кодовой базе действубщего проекта. При этом фундаментальная инженерная база никуда не исчезает. Скорее наоборот: если код теперь можно генерировать значительно быстрее, еще важнее понимать архитектуру, транзакции, консистентность, сценарии отказа, тестирование и последствия принимаемых решений. ИИ позволяет быстрее реализовать хорошее инженерное решение. Но плохое - тоже. Большое публичное видео Отдельно: сейчас на финальном этапе находится большое многочасовое видео про ИИ-дополненный SDLC. В видео постараюсь полноценно пройти весь процесс: • показать подходы • инструменты • агентов • контекст инжиниринг • работу с большой кодовой базой • тестирование • архитектуру • CI/CD • ПРОД • управление. То есть публичная часть сама по себе будет полноценным большим материалом, который можно посмотреть и использовать независимо от участия в интенсиве. Зачем тогда интенсив Потому что посмотреть, как это работает у кого-то, и научиться применять это самому - разные вещи. На интенсиве основной упор будет на работу руками и проверку ваших решений. Что будет • ИИ в требованиях и планировании • Контекст инжиниринг • Системный дизайн • Работа с большими кодовыми базами • Кодинг агенты и агентный рабочий процесс • Генерация и изменение кода • ИИ-дополненное тестирование • Ревью кода и автоматизация проверок • Документация и База знаний • ИИ в CI/CD • Работа с большим ПРОД-контекстом • Метрики, логи, трейсы и анализ инцидентов • Безопасность и Управление • Человек-в-цикле • Границы автономности ИИ-агентов • Метрики эффективности внедрения ИИ в SDLC Чего не будет • "50 секретных промптов" • Обещаний "теперь можно не уметь программировать" • "Сеньора с AI за два месяца" • Каталога из сотни ИИ-сервисов • Веры в то, что агенту достаточно дать доступ ко всему и отправить работать • Отказа от системного дизайна и фундаментальной инженерной базы Как все устроено • Длительность: 8 недель • Старт: сентябрь 2026 • Онлайн-лекции и встречи в группе • Практические задания • Самостоятельная работа • Индивидуальная проверка и разбор решений • Отдельные разборы сложных вопросов, возникающих по ходу курса • Работа не только с ИИ-инструментами, но и с самим процессом их внедрения в разработку Как попасть Заполнить форму - ССЫЛКА. Вопросы можно задать в личных сообщениях. А само большое публичное видео про ИИ-дополненный SDLC уже на финальном этапе.

Часть 1/2 Подходит к финалу очередной интенсив по Системному дизайну. Как писал ранее, на данный момент как в рамках интенсива "НашКод", так и в рамках интенсива "СистемныйДизайнВДеле" теперь уже активно используем ИИ. При этом я четко вижу, что ИИ не отменил…

Часть 1/2 Подходит к финалу очередной интенсив по Системному дизайну. Как писал ранее, на данный момент как в рамках интенсива "НашКод", так и в рамках интенсива "СистемныйДизайнВДеле" теперь уже активно используем ИИ. При этом я четко вижу, что ИИ не отменил фундаментальные знания. Он поднял цену их отсутствия. То, что я напишу ниже ОЧЕНЬ ПЛОХО ПРОДАЕТСЯ, именно поэтому эти мысли крайне непопулярны и активно высмеиваются отдельными джентльменами на просторах интернета. Но мой опыт и опыт коллег явно показывает, что "та самая база" остается всегда и именно она ключ к успеху в нашей работе. • Очень заманчиво звучит "3-4 месяца и ты будешь супер-инженером" с ЗП 300К в нс. • Очень демотивирующе звучит - 3-4 года успердной, монотонной и местами скучной работы над собой, чтобы в перспективе 5-6 лет быть востребованным специалистом, который способен решать сложные задачи. Сегодня можно попросить агента создать Spring Boot/Go/Python/ВЫБРАТЬ_СВОЕ-сервис, написать миграцию, подключить Kafka, добавить тесты и собрать Docker Compose, набросать архитектуру и т.д. Через несколько минут у вас будет код, который выглядит вполне убедительно. Но дальше начинаются вопросы: • Почему запрос использует Seq Scan вместо индекса? • Почему после добавления retry система создаёт дубликаты? • Почему CPU почти свободен, а сервис перестал отвечать? • Почему транзакция держит соединение из пула во время внешнего HTTP-вызова? • Почему сообщения в Kafka пришли не в том порядке? • Почему увеличение числа реплик не повысило производительность? • Почему после подключения кэша пользователи начали видеть устаревшие данные? • Почему приложение работает локально, но падает за reverse proxy? • Почему предложенная ИИ архитектура технически красива, но слишком дорогая и ненадежная? Ответы на эти вопросы находятся не в синтаксисе кода и не в очередной аннотации или диаграмме. Они находятся в понимании: • архитектуры компьютера и операционных систем • баз данных, индексов, транзакций и блокировок • сетей, TCP, TLS, DNS и HTTP • веб-серверов, прокси и балансировки • брокеров сообщений и гарантий доставки • безопасности • наблюдаемости и механизмов надежности • алгоритмов и структур данных • принципов масштабирования и системного дизайна. Фреймворки скрывают большую часть этой сложности. Но только до первого серьезного инцидента. Когда система начинает деградировать, абстракции заканчиваются. Остаются сокеты, потоки, очереди, файловая система, сетевые тайм-ауты, блокировки, планы выполнения запросов и ограничения конкретного железа. ИИ хорошо ускоряет исполнение. Но инженер по-прежнему должен: 1. Правильно сформулировать задачу. 2. Выбрать допустимые компромиссы. 3. Проверить полученное решение. 4. Увидеть скрытые режимы отказа. 5. Принять ответственность за последствия в ПРОДе. Без фундаментальных знаний разработчик не становится быстрее. Он просто начинает быстрее создавать системы, корректность которых не способен проверить.

Друзья, скоро буду выступать на JVM Day с докладом: "Превратности кэша: как Redis спасает latency и тихо ломает корректность в Spring-сервисах" Это не обзор Redis и не инструкция по установке @Cacheable. На примере одного Spring Boot-сервиса разберём цепочку…

Друзья, напоминаю, что наиболее качественный контент я публикую в закрытом платном платиновом БУСТИ КАНАЛЕ. Сегодня там новый материал по взаимодействию в команде и как эффективно вести себя в коллективе. Приятного просмотра. ССЫЛКА НА МАТЕРИАЛ

AI-Disrupt PDLC: как Сбер предлагает перестроить разработку вокруг ИИ-агентов Сбер опубликовал whitepaper "AI-Disrupt PDLC. Инженерия намерения. Новая архитектура генеративной разработки ПО". Я изучал его ранее, а в свете сегодняшнего поста его упомянули и решил добавить небольшое описание от себя. Сначала - просто обзор самого документа, а потом уже мое мнение по его сильным и слабым (как мне кажется) сторонам. Формула документа: ИИ-эффект = среда работы агентов × редизайн процессов. Если просто добавить генерацию кода в прежний SDLC, код появится быстрее, но ограничения в постановке задач, ревью, интеграции, безопасности и эксплуатации сохранятся. Архитектурное ядро - два цикла и два сквозных контура. 1. Петля намерения Человек отвечает за то, что и зачем строить. До генерации команда проходит Discovery: • формулирует проблему • готовит PR/FAQ • задает измеримую гипотезу результата • выбирает между автоматизацией старого процесса и его перепроектированием • определяет, нужен ли здесь агент. Результатом становится SDD - машиночитаемый контракт между намерением и реализацией. В нем фиксируются: • бизнес-результат • требования и инварианты • участие человека • уровень автономии • evals • откат • проверка эффекта после релиза. Для самих агентных продуктов предусмотрены Agent Specification и отдельный жизненный цикл ADLC. 2. Петля реализации Агенты в этой петле: • получают спецификацию • пишут код и тесты • обновляют документацию • вызывают инструменты • запускают сборку • исправляют результат. Длинные задачи разбиваются на сессии с контрольными точками и передачей состояния. 3. Сквозная валидация Проверка не выносится в позднюю стадию. Evals, агент-ревьюер, регрессионные и проверки безопасности работают внутри цикла. Задача завершается после формирования Evidence Bundle: • изменений • результатов проверок • аудита • стоимости выполнения • ссылки на проверку бизнес-результата. 4. Governance Mesh Управление также встроено в каждый шаг. • Политики выражаются кодом • Действия агента ограничиваются лестницей R0–R5 • События попадают в неизменяемый аудит • Guardian Agents могут наблюдать, перенаправлять, блокировать и исправлять опасные действия. Отсюда второй центральный тезис: Среда важнее модели. Стратегическим активом считается не подписка на конкретную LLM, а собственная платформа разработки: • контекст • память • инструменты • песочницы • model gateway • MCP/A2A-интеграции • библиотека паттернов • среда длительных задач • наблюдаемость • политики. Модель можно заменить, не перестраивая процесс. Меняется и роль инженера. Он становится: • постановщиком задачи • архитектором • оркестратором • валидатором результата. Нужны: • мышление спецификациями • проектирование evals • грамотность в валидации • контекст-инжиниринг. В зрелой модели документ описывает Tiny Teams из 3–6 человек, управляющие агентами. Измерять предлагается не объем сгенерированного кода. К DORA добавляются: • регрессии от агентов • галлюцинации на заданном горизонте • повторное использование спецификаций • полнота Evidence Bundle • самовосстановление • перераспределение сэкономленного времени • стоимость результата • доля подтвержденных гипотез. Скорость всегда рассматривается вместе с качеством и эффектом. Внедрение разбито на три горизонта: • фундамент и пилоты в первые 6 месяцев • масштабирование SDD и долгих агентных процессов до 18 месяцев • координированные команды агентов. Для старта предложен 90-дневный MVP: • базовые метрики • пилотные команды • Discovery • первый SDD • агент-ревьюер • Evidence Bundle • проверка результата первой фичи. Для российского ентерпрайза собственная среда исполнения рассматривается и как условие локализации, аудита, соблюдения 152-ФЗ и снижения зависимости от зарубежных поставщиков. В итоге AI-Disrupt PDLC - не концепция "ИИ пишет код". Это операционная модель, где: • человек владеет намерением и результатом • агент - реализацией • платформа - средой и инструментами • валидация - доказательствами качества • governance - допустимостью и аудируемостью действий.

Мнение: Нет никакого AI-driven и AI-first SDLC/PDLС/ВСТАВИТЬ_СВОЕ_ПО_ВКУСУ Сейчас вижу много статей про отдельные методологии вроде Spec-Driven Development, AI First или AI-Driven Development и утверждения, что агенты "решат все". Лично я не согласен с этими утверждениями. Есть некоторые практики, которые действительно делают работу с агентами более удобной, предсказуемой и эффективной, но слова о том, что ИИ, агентная разработка и прочее - это прямо новая методология и нужно вообще все процессы перестроить под нее - я считаю не совсем обоснованными и слабо подтвержденными фактами. В лучшем случае это новые названия для отдельных акцентов внутри нормального SDLC. Спецификация - способ зафиксировать требования, ограничения и критерии приёмки. ИИ - инструмент для ускорения анализа, разработки, тестирования, документирования и ревью. Но основа остаётся прежней: • понятные требования и границы системы • архитектурные решения и ответственность за них • критерии готовности и QG (quality gates) • тестирование, наблюдаемость и безопасная поставка изменений на ПРОД • метрики lead time, change failure rate, MTTR и качества • мониторинг ПРОДа и процессы реагирования на инциденты. В команде "здорового человека" ИИ действительно дает сильный эффект: • снимает рутину • ускоряет подготовку изменений • помогает быстрее проходить уже выстроенный процесс. В команде "курильщика" он ускоряет другое: • появление лишнего кода • дефектов • технического долга • изменений, которые никто не успевает нормально проверить. Количество созданных PR растет. Скорость поставки ценности на ПРОД - не обязательно. Новые ярлыки хорошо выглядят на презентациях, помогают получить бюджет и показать руководству "трансформацию". Но настоящий ПРОД довольно быстро отделяет трансформацию от имитации. Поэтому одним командам агенты дают кратный прирост, а другим не помогают или даже ухудшают результат. Разница обычно не в модели и не в промптах. Разница в том, была ли сама команда инженерной или "Spring/Gin/Angular/выберать_свое Developer", был ли у команды нормальный инженерный процесс, который стоило ускорять. Сначала - инженерная дисциплина. Потом - автоматизация. ИИ не заменяет SDLC. Он показывает его качество и иногда - ускоряет. При этом по опыту вижу, что корректное использование ИИ дает существенный прирост, но только при его наложении на уже готовые и налаженные процессы. Какие мысли у сообщества на этот счет?

📰 Новости с последствиями. В OpenTelemetry Spring Boot Starter появилась декларативная конфигурация: начиная с версии 2.26.0 весь пайплайн телеметрии можно описать внутри application.yaml: • resource attributes • propagators • exporters • processors • sampling • включённые модули инструментации. Раньше простые настройки раскладывались по десяткам OTEL_*, а для сложных сценариев приходилось писать @Bean и собственную конфигурацию. Теперь базовый профиль наблюдаемости можно хранить рядом с кодом, версионировать и проверять через пул реквест. При этом есть важный нюанс: сама схема OpenTelemetry 1.0 уже стабильна, но ее поддержка в Spring Boot Starter пока отмечена как экспериментальная. Например, можно отказаться от принципа "собираем все" и явно включить только нужные инструментации: otel: file_format: "1.0" distribution: spring_starter: instrumentation: default_enabled: false enabled: - spring_web - jdbc Это важно не потому, что YAML красивее переменных окружения. Главное - команда получает возможность задать единый подход: • обязательные service.name и окружение • единый OTLP ендпоинт • стандартные propagators • sampling политики • batch processors • список разрешенных инструментов • исключение health-check и технических ендпоинтов. Конфигурация поддерживает Spring профили и переопределения через переменные окружения, поэтому один шаблон можно адаптировать для dev, stage и prod. Но главная проблема наблюдаемости никуда не исчезла Простая настройка ускоряет не только внедрение OpenTelemetry. Она позволяет так же быстро собрать слишком много бесполезных данных. Особенно опасна кардинальность метрик. Здоровый человек: http.route=/orders/{id} http.response.status_code=500 Курильщик: url.path=/orders/827361 user.id=918273 order.id=827361 OpenTelemetry Metrics SDK хранит отдельное состояние для каждой уникальной комбинации атрибутов. По умолчанию лимит составляет 2000 комбинаций на один стрим метрик. После достижения лимита новые комбинации объединяются в точку: otel.metric.overflow=true Измерения не теряются, но их атрибуты исчезают. В результате общий счетчик остается корректным, а алерт по success=false или конкретному роуту может начать недосчитывать ошибки. То есть конфигурация технически валидна, экспортер работает, данные приходят - а диагностически телеметрия уже работает некорректно. Что стоит сделать 1. Иметь корпоративный подход, а не копировать случайный YAML между сервисами. 2. По умолчанию включать только нужные инструментарии. 3. Запретить user_id, order_id, raw URL и другие идентификаторы в аттрибутах метрик. 4. Отслеживать появление otel.metric.overflow=true. 5. Ограничивать sampling, batch size и объем экспортируемых данных. 6. Измерять стоимость телеметрии на сервис и команду. 7. Добавлять кастомные спаны и метрики только там, где по ним действительно принимается решение. 8. Для Spring Boot 3.5+ обязательно импортировать opentelemetry-instrumentation-bom: без него декларативный конфиг может завершить запуск ошибкой NoClassDefFoundError. ПРОД-вердикт Декларативная конфигурация - хороший шаг к Observability as Code. Но единый YAML еще не создает единый подход к наблюдаемости. Фреймворк может стандартизировать экспорт, sampling и инструментарий, но он не знает, какие данные действительно помогают вашей команде расследовать инцидент. Плохой подход теперь просто можно распространить на сотню сервисов быстрее. У вас OpenTelemetry настраивается централизованно или каждый сервис собирает телеметрию по-своему? Ссылка на материалы: • The Voyage of a Small Environment Variable • Declarative configuration • Metrics #НовостиСПоследствиями #OpenTelemetry #SpringBoot #Observability #Backend

Друзья, скоро буду выступать на JVM Day с докладом: "Превратности кэша: как Redis спасает latency и тихо ломает корректность в Spring-сервисах" Это не обзор Redis и не инструкция по установке @Cacheable. На примере одного Spring Boot-сервиса разберём цепочку инженерных решений: • PostgreSQL перестаёт справляться с повторяющимися чтениями • Redis действительно снижает latency и нагрузку на БД • после обновления пользователи начинают получать старые данные • даже правильная инвалидация не закрывает гонку между чтением и записью • один протухший ключ создаёт лавину одинаковых SQL-запросов • новый префикс кэша спасает совместимость релиза, но создаёт холодный кэш. Главная идея доклада: Каждое исправление закрывает одну проблему, но одновременно меняет систему и открывает следующий класс рисков. Будут Spring-код, конкурентные сценарии, нагрузочные тесты, Grafana и репозиторий, в котором проблемы можно воспроизвести самостоятельно. Организаторы также дали мне три билета на JVM Day. Разыгрывать их за репосты, отметки друзей и комментарии "участвую" не хочется. Поэтому подготовил небольшой инженерный квиз по теме кэширования. Это ПРОД-сценарий со Spring Cache, Redis и PostgreSQL. Нужно восстановить порядок конкурентных операций и определить, почему устаревшее значение вернулось в кэш даже после успешного обновления и удаления ключа. Условия: • заполнить Google-форму до 30.07.2026 • указать действующий Telegram никнейм • один участник - одна попытка. Если правильных ответов будет не больше трёх, билеты получат все ответившие корректно. Если больше - случайно выберем трёх победителей среди участников с правильным ответом. Квиз: JVM DAY QUIZ После завершения опубликую подробный технический разбор: почему правильный вариант работает и почему остальные ответы выглядят разумно, но не объясняют происходящее. Без обязательных подписок, репостов и приглашений друзей. Только небольшая инженерная задача и три билета на JVM Day.

❗️❗️❗️ Друзья, набор на Сентбярь ❗️❗️❗️ Детали 8-недельного интенсива "НашКод". - Без громких обещаний. - Просто структурная, честная и тяжёлая работа. Кому подойдёт - Тем, кто уже знаком с промышленным Java-стеком - Тем, кто работает, но чувствует, что "упёрся в потолок" - Тем, кто "вошёл в IT", но не знает, куда теперь двигаться Чего не будет - "Серебряной пули" - Конкурсов и геймификации - Весёлых презентаций и розовых лимузинов - Панибратства и "сеньора за 30 дней" - Иллюзии, что развитие можно "пересидеть" Что будет - Моё видение, основанное на годах работы в реальной разработке - Индивидуальный подход: я искренне верю, что обучение инженеров нельзя просто поставить на поток - Проект, в котором мы будем много кодить, править и обсуждать - как в реальной команде - Много кода, много ревью, много правок - Активное использование ИИ для работы с кодом, тестами и документацией - но без отказа от инженерного мышления, проверки решений и ответственности за результат ИИ уже позволяет значительно быстрее выполнять рутинную работу. Освободившееся время мы будем тратить на архитектуру, качество и понимание системы. Как всё устроено - Только 6 человек в группе - никаких исключений - Старт: ориентировочно 7 Сентября 2026 года - Формат: раз в неделю лекция и онлайн-сессия - Далее - самостоятельная работа и общение в мини-чате - Домашние задания сдаются индивидуально в фоновом режиме - Учебный проект: микросервисы, архитектура, тесты, документация, нагрузка - "вот это вот всё" - Участие платное Как попасть Более подробно ознакомьтесь с условиями и заполните форму по ССЫЛКЕ. Вопросы также можно задать в личных сообщениях

Друзья, начинаю новый большой цикл публикаций - "Разгоняем сервис до 1M RPS". В первой статье не пишем контроллер и не подбираем параметры JVM. Сначала разбираемся, что вообще означает заявление "система выдерживает миллион запросов в секунду" и какие условия должны стоять рядом с этой цифрой. На выходе мы создадим полноценную развернутую в облаке систему, с метриками, дашобрдами и т.д. Сначала сделаем реализацию на Java, а затем на Go и увидим, что чаще всего "язык" это лишь малая часть всего решения. В статье разбираем: • почему 1M RPS без latency, уровень ошибок, размера ответа и описания стенда практически ничего не означает • чем отличаются предложенная нагрузка, завершенная нагрузка и пропускная способность • как связаны пропускная способность, latency и конкурентность и почему при 1M RPS внутри системы могут одновременно находиться десятки тысяч запросов • почему средней latency недостаточно и зачем отдельно смотреть на p95, p99 и p999 • что такое SLI, SLO, SLA и бюджет ошибок и как зафиксировать технический контракт до начала оптимизации • какую систему будем строить в рамках цикла - Offer Snapshot Service для получения цены и доступности товара по SKU и региону • по каким правилам будем сравнивать Java/Spring Boot и Go, чтобы не подменить инженерный эксперимент холиваром • как будет развиваться весь цикл: Java baseline, нагрузочное тестирование, профилирование, оптимизация, Kubernetes, отказы, готовность к ПРОДу и только затем реализация на Go. Ссылка на статью: Разгоняем сервис до 1M RPS: с чего начинается производительность

❗️❗️❗️Друзья, набор на Май❗️❗️❗️ Детали 8-недельного интенсива "НашКод". - Без громких обещаний. - Просто - структурная, честная и тяжелая работа. Кому подойдёт - Тем, кто уже знаком с промышленным Java-стеком - Тем, кто работает, но чувствует, что "упёрся…

🍃 Уже завтра! Митап Spring АйО & Aston ⛔️Завтра, 22 июля встречаемся на онлайн-митапе для Java-разработчиков, который проводим вместе с нашими друзьями из Aston В программе три практических доклада: ☑️ «Что не так с вашим Spring AOP? Отвечает Axelix» Михаил Поливаха, технический руководитель проекта Axelix Разберемся, как связаны Spring AOP, проксирование и AspectJ и в каких случаях возможностей Spring уже недостаточно. ☑️ «Превратности DLT: как топик ошибок становится кладбищем бизнес-событий» Евгений Сулейманов, технический директор ProzyTech Обсудим, почему Dead Letter Topic без мониторинга и оповещений может привести к потере важных бизнес-событий. ☑️ «Эволюция ИИ-агентов. Как простой запрос превращается в полноценную архитектуру» Максим Александров, старший разработчик программного обеспечения Aston 📅 22 июля, 18:00 по Москве 📍 Онлайн 🎯 Для специалистов любого уровня 🔗 Регистрация по ссылке

Друзья, если кому-то не пришла ссылка на трансляцию, дублирую повторно: • VK • YouTube

❗️❗️❗️Набор на практический курс по системному дизайну ❗️❗️❗️ Формат: 4 недели, 4 живые встречи, группа 8 человек. Между встречами - самостоятельная работа и персональное ревью архитектурных решений. Весь курс строится вокруг одного сквозного корпоративного сценария - платёжной вертикали. За четыре недели доведём её от определения границ и NFR до архитектуры, готовой к эксплуатации. Программа Неделя 1. Контекст, границы и коммуникации • NFR и архитектурные драйверы • DDD, Bounded Contexts и Context Map • C4 и ADR • sync/async, REST, gRPC и события • Kafka и RabbitMQ • API Gateway • UUIDv7, Snowflake и DB sequence. Неделя 2. Данные и консистентность • денежные инварианты и состояния платежа • Saga: оркестрация и хореография • Transactional Outbox, Inbox и CDC • идемпотентность и дедупликация • callback внешнего провайдера • CQRS и read-модели. Неделя 3. Надёжность, масштабирование и наблюдаемость • таймауты, ретраи, circuit breaker, bulkhead и rate limiting • очереди, DLQ, ретрай-потоки и backpressure • горизонтальное масштабирование и планированирвоание капасити • безопасное кэширование • метрики, логи и трейсы • SLI, SLO, error budget и алерты. Неделя 4. Безопасность и эксплуатация • OAuth2, OIDC, JWT и Keycloak • service-to-service security • защита webhook: подпись, anti-replay и идемпотентность • Vault, KMS и управление секретами • zero-downtime миграции • rolling, blue-green и canary deployment • rollback, runbooks и release checklist. Что будет на выходе Не набор разрозненных диаграмм, а связный архитектурный проект: • Context Map и C4-диаграммы • sequence-диаграммы основных и аварийных сценариев • API- и event-контракты • ADR и обоснование компромиссов • таблицы resilience-политик • SLI/SLO и схема наблюдаемости • планы миграции, релиза и отката. Главный результат - умение не просто предложить архитектуру, а объяснить: • какие требования она закрывает • где находятся риски • почему выбран конкретный вариант • чем пришлось пожертвовать • как решение будет вести себя в production. Для кого Курс рассчитан на разработчиков и технических лидеров, которые уже понимают основы баз данных, API и сетевых интеграций. Конкретный язык и стек не принципиальны. Это интенсивный формат. Домашние задания потребуют времени: решения будут разбираться подробно, включая противоречия между диаграммами, контрактами и NFR. Старт: ~13.07.2026 Размер группы: строго 8 человек Участие: платное Форма заявки: ССЫЛКА

Друзья, 30-й квиз по распределенным системам. ❗️❗️❗️Задача❗️❗️❗️ Feature Flags как источник инцидентов: почему выключить фичу - не значит откатить ее Сценарий: Сервис Payments запускает новый процесс возврата средств Refund V2 под feature flag. Функция включена…

Вчера вечером обсуждали рынок труда и экономическую ситуацию в нашей сфере. По итогу, все обсуждение свелось вот к этому видео: IT аналитика Я не мог не поделиться :) И хорошего всем дня, друзья!

Друзья, 30-й квиз по распределенным системам. ❗️❗️❗️Задача❗️❗️❗️ Feature Flags как источник инцидентов: почему выключить фичу - не значит откатить ее Сценарий: Сервис Payments запускает новый процесс возврата средств Refund V2 под feature flag. Функция включена…