Последние несколько лет глобальная IT-индустрия переживает волну масштабных сокращений. В 2023 году крупнейшие технологические компании, включая Meta, Amazon, Alphabet и Microsoft, объявили о десятках тысяч увольнений. Хотя у российского рынка были свои особенности, эти события показали: в условиях нестабильности компании стремятся сохранять прежде всего тех, кто понимает, как устроены системы и решения, и способен решать сложные инженерные задачи.
Кроме того, перед пандемией и во время неё рынок онлайн-образования в IT пережил настоящий подъём курсов. Прошло пять лет: джуны стали мидлами, и у них возник вопрос — а куда развиваться и расти дальше? Один из возможных треков — как раз начать решать архитектурные задачи.

К тому же почти каждый инженер рано или поздно сталкивается с задачей, когда ему нужно спроектировать сложное изменение в системе, которое затронет сразу несколько продуктов или команд. Так разработчики опытным путём приходят к необходимости погрузиться в архитектуру программного обеспечения — систематизировать опыт и научиться понимать паттерны, ограничения и компромиссы.
На связи команда курса «Архитектура программного обеспечения» в Яндекс Практикуме. В этом материале мы расскажем, как ответили на запрос рынка и разработчиков и стали готовить инженеров в области архитектуры ПО, а также какие изменения внесли в курс совсем недавно.
Что было главным
В архитектуре есть множество паттернов, технологий и подходов. И это отпугивает многих инженеров, которые задумываются о следующем шаге в карьере. Они видят сложные термины (DDD, CQRS, event-driven) и боятся, что не потянут.
Поэтому мы выделили ключевые проекты, с которыми чаще всего сталкиваются специалисты, проектируя архитектуры системы, и сделали упор именно на те технологии, что востребованы на рынке. Например, в первом спринте студенты прорабатывают микросервисную архитектуру системы управления умными домами и изучают паттерны проектирования микросервисов, Domain-Driven Design и особенности контейнеризации. Ведь архитектура — это не только решение на бумаге, но и реальная инфраструктура.

Исходя из этого мы, кстати, и собирали команду авторов, наставников и ревьюеров — экспертов в области распределённых и высоконагруженных решений. Суммарно у них набралось более 100 лет рабочего опыта в темах курса в самых разных сферах: финансах и финтехе, IT, медицине, телекоммуникациях и даже аграрном секторе. Они занимают архитектурные должности в Кинопоиске, Magnit Tech, МТС, Газпромбанке, Райффайзенбанке и Альфа-Банке.
Нам было важно, чтобы у команды наставников был максимально современный и живой опыт, чтобы студенты сталкивались с реальными проектами, идентичными тем, что их ждут потом на собесах и в рабочих задачах. Мы просили наших экспертов рассказать, с чем они работают каждый день и какие знания и навыки хотели бы передать самим себе в прошлом. Поэтому курс сфокусирован не на теории, а на практике — в каждом из 11 спринтов студентов ждёт финальный проект, который сдаётся на ревью и который можно добавить в портфолио.
Например, в спринте про highload в real-time-среде студенты работают над приложением компании, которая предоставляет агрегационные услуги в сфере страхования. Задача — решить проблемы классического быстрого роста MVP. Среди них и медленная загрузка страниц, и нарушение SLA для B2B-клиентов, и, разумеется, падения приложения. В частности, в первом задании нужно спроектировать технологическую архитектуру приложения так, чтобы оно отвечало требованиям бизнеса, и уделить внимание стратегии масштабирования и отказоустойчивости, а также проработать вопросы, связанные с деплоем в несколько зон доступности. На входе студентам даётся диаграмма приложения в модели C4, а в качестве артефакта решения — схема To-Be будущей архитектуры сервиса. Задача учебная, но вот проект вполне рабочий, так что его можно добавить в портфолио.
Было здорово и важно, когда актуальность начали отмечать и выпускники.
«Я приятно удивился актуальности материала. Всё это так или иначе спрашивают сейчас на собесах и реально используют в работе»
«Курс научил меня читать инфраструктурные схемы и видеть за требованиями реальные технические ограничения. Например, раньше фраза “репликация БД между зонами доступности” была абстракцией — сейчас я понимаю её последствия для RPO/RTO»

Ещё мы с командой считаем, что архитектура — это не только решение на бумаге, но и реальная инфраструктура, которая состоит из кода, сервисов, API и многого другого. Классный специалист может не только спроектировать, но и внедрить решение. Так что мы учим студентов не только самим технологиям, востребованным на рынке, но и тому, как применять их в проектах, работая с исходным кодом, отладкой и конфигурацией.
Также есть отдельный блок, как общаться с бизнесом на одном языке и выбирать оптимальную технологическую стратегию. В одной из проектных работ студенты с помощью Business Capability Map и описания организационной структуры банка и процессов создают карту текущего IT-ландшафта и схему интеграции приложений с указанием участников процессов. Так команда цифровой трансформации понимает, что не даёт делать депозиты и накопительные счета клиентов полностью цифровым продуктом. Подобный анализ должен помочь снизить издержки на процессы, в которых задействованы сотрудники бэк-офиса. Тоже вполне типичная архитектурная задача, на которую выпускники курса умеют смотреть с точки зрения бизнеса.
Рефакторинг
Прошло полгода после выхода курса «Архитектура программного обеспечения» на рынок, когда мы поняли, что, несмотря на все успехи, нам нужен рефакторинг. Как говорится, всё хорошо, но нужно переделать. Причин было несколько.
Первая — постоянные изменения в мире IT, когда раз в пару месяцев появляются новые решения. Да, есть фундамент архитектуры ПО, но, например, к середине 2025 года стало понятно, что тем, кто разрабатывает её в реальной жизни, уже не обойтись хотя бы без базового понимания Machine Learning, RAG и так далее. Так в курс добавился блок про нейросети. Нет, один спринт не научит студентов самостоятельно их писать, но точно даст базовое представление, что это такое и как работают популярные решения.

Вторая — обратная связь от студентов. Это одна из важнейших ценностей Практикума — нам важно не просто выпускать продукты, а помогать менять карьеры (а возможно, и жизни в целом) студентов. Поэтому мы не могли закрыть глаза, когда студенты «умирали» в самом начале программы при знакомстве с микросервисной архитектурой. Это очень важный блок, но у студентов, которые раньше не сталкивались с архитектурой ПО даже в общем виде, этот спринт вызывал много сложностей. А у кого-то даже отбивал всякое желание иметь дело и с микросервисной архитектурой, и с архитектурой вообще. Разумеется, нас это не могло устроить.
Ещё студенты просили разнообразить форматы обучения. К традиционным System Design интервью, которые помогают готовиться к собеседованиям, мы добавили Q&A-сессии и кейс-клуб. Последний нужен для обмена опытом и общения студентов без привязки к потокам — участники кейс-клуба разбирают нестандартные кейсы вне тем уроков и развивают профессиональную насмотренность. А это, как вы понимаете, очень важно для тех, кто проектирует архитектуру.

Однако самой большой сложностью рефакторинга, буквально со звёздочкой, стало то, что на курс пришли очень разные студенты. Кто-то говорил, что тратил на обучение всего час в день и со всем успешно справлялся (или справлялась). А для кого-то проектная работа после каждого из 11 спринтов была в разы сложнее, чем подготовка дипломной работы в университете.
Например, был такой отзыв:
«Я старался уделять обучению час времени каждый день. Когда-то больше, когда-то меньше, но всё успел сделать в срок без особого напряга. На каникулах отдыхал, чтобы не перегореть»
И тут же:
«Я фронтенд-разработчик, и практически вся информация для меня была новой. У меня не было времени на чтение дополнительных материалов к курсу, что, уверена, сделало бы мою учёбу ещё полезнее»
Как объединить такую разную аудиторию? Первые требовали больше более сложных заданий, а вторые пытались успеть справиться с тем, что есть. Так весной 2025 года на курсе появились тарифы: «Базовый» и «Продвинутый». Первый для тех, кто делает первые шаги в архитектуру ПО. Второй — для более опытных студентов, которые уже работали над архитектурными задачами ранее и готовы решать что-то посложнее.
Вместо заключения
Современная разработка давно вышла за рамки написания кода «под задачу» — она требует системного мышления, умения строить гибкие, масштабируемые и адаптируемые решения. Всё это как раз и даёт знание архитектуры программного обеспечения. Однако решить учиться ей — та ещё задачка для программистов. На русском языке обучение архитектуре ПО — всё ещё очень нишевое направление, так что неудивительно, что качественной информации на русском в открытом доступе в разы меньше, чем на английском. К сожалению, далеко не все инженеры свободно владеют им, чтобы читать профильные статьи или смотреть выступления ведущих разработчиков.

Да, тот же ChatGPT или любая другая нейросеть помогут в учёбе. Но в качестве эксперимента попросите любую LLM создать для самой себя учебную программу и расставить в ней приоритеты. Вы наглядно увидите все слабые стороны такого подхода. К тому же с большими языковыми моделями нужно уметь правильно работать, знать, как они анализируют источники и приоритизируют ответы. Для этого нужно находиться в позиции эксперта, которому нейросеть ассистирует, а не новичка, который просит предоставить готовые ответы.
Именно поэтому мы в Практикуме и создали курс «Архитектура программного обеспечения». Ведь по сути важен не столько объём знаний, сколько выбор той самой оптимальной «тропинки» через сложную область, чтобы научиться важным вещам, не утонув в деталях и получив опыт из первых рук. А именно опыт для инженеров зачастую играет определяющую роль, тем более если этот опыт пропущен через грамотно выстроенную обратную связь. Поэтому мы сделали фокус на обмене живым опытом, решении реальных задач и работу в группах и командах. Как говорит создатель ядра Linux Линус Торвальдс: Talk is cheap. Show me the code.
Мы ждём новых студентов. Пройдите бесплатный тест, чтобы проверить, что курс будет вам по силам и по душе.