Точка невозврата: когда инженеру пора переключиться с написания кода на лидерство

Работа технического лидера – не писать качественный код, а разрабатывать качественные системы. А это и архитектура, и процессы, и коммуникации, и, собственно, лидерство.

🙅‍♂️Нужно ли полностью отказываться от кода?

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

🔄 Что делать вместо написания кода?

Роль техлида включает:

🔸Формирование технического видения – определение архитектурных решений и технологического стека.
🔸Менторство – поддержка и развитие членов команды.
🔸Коммуникация с бизнесом – перевод бизнес-требований в технические задачи.
🔸Управление процессами – оптимизация рабочих процессов и внедрение лучших практик.

🧠 Как переключить мышление?

1️⃣ Нужно смотреть на свою работу в контексте всей системы и своего влияния на бизнес, а не в конкретных задачах.
2️⃣ Обсуждать архитектуру и код не менее (а иногда и более) важно, чем его писать. Коммуникации – это тоже работа.
3️⃣ Дальнейший рост возможен только через расширение зоны ответственности. А чем шире зона ответственности, тем меньше возможности погрузиться в задачи глубоко – нужно делегировать.

📋 Как делегировать задачи без потери качества?

Четкое определение задач: ясное описание требований и ожиданий.

Доверие: предоставление команде автономии в принятии решений.

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

Готовы к такой трансформации? Записывайтесь на консультацию перед курсом [Технический Лидер]!

Друзья, завтра возобновляем после майских каникул наши ивенты и первый H&S Conclave пройдет на тему "Реактивное программирование и Spring WebFlux: преимущества, вызовы и интеграция с виртуальными потоками"

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

Основные темы:

1. Основы реактивного программирования и зачем оно нужно
2. Как устроен Project Reactor
3. Что такое backpressure и как с ним работать
4. Разница между Spring WebFlux и Spring MVC
5. Что такое виртуальные потоки (Project Loom) и как они упрощают реактивные решения
6. Практическая демонстрация с WebFlux

🎯 Челлендж перед митапом!
Попробуйте реализовать небольшую задачу: посчитать количество double-click’ов за 5 секунд. Что угодно — консоль, UI, любой язык.
На митапе сравним подходы, обсудим, сколько времени ушло и насколько всё оказалось сложным без реактивщины.

📊 В конце — мини-опрос и обсуждение решений.
👉 Узнать подробнее и зарегестрироваться можно по ссылке

Друзья, мы уже начали! Присоединяйтесь к докладу и обсуждению в Google Meet💪

Друзья, завтра, 22 мая встречаемся на новый H&S Conclave на тему «Data Platforms под капотом: архитектура, инструменты, интеграция»

Начало: в 20.00 GMT+3

Если вы хотите разобраться в устройстве современных платформ данных и узнать, какие подходы применяются для создания гибких и масштабируемых архитектур, этот доклад — для вас!

Что вас ждёт:
🔹 Эволюция хранилищ данных — от традиционных баз до современных решений для работы с данными
🔹 Архитектура платформы данных — компоненты платформы: хранилища, пайплайны, BI-инструменты, оркестрация и мониторинг
🔹 ETL, ELT и Reverse ETL — как различаются эти подходы, где и когда их применять, и как выбрать подходящий для своей задачи

Доклад будет интересен: инженерам, архитекторам и аналитикам, которые хотят глубже понять, как устроены и работают data-driven системы.

Спикер: Александр Кохно, Lead Data Engineer

👉 Зарегистрироваться и оставить вопрос спикеру можно по ссылке

Навыки техлида — делегирование

Что подразумевает навык делегирования в контексте работы tech lead?

Для техлида делегирование — это не просто передача задач, а полноценное управление компетенциями и ресурсами команды. Это умение чётко определять, какие задачи и кому передавать, понимать сильные стороны каждого члена команды и обеспечивать им необходимую поддержку.

Эффективное делегирование подразумевает передачу не только задачи, но и ответственности за её результат.

Почему senior-разработчику нужно делегировать свои задачи, чтобы стать техлидом?

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

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

Какие задачи техлиду обязательно нужно делегировать?

Техлиду нужно передавать:

📌 Рутина и повторяющиеся задачи, не требующие глубокого погружения и вашего уровня экспертизы.

🎯 Задачи, выполнение которых развивает необходимые компетенции у членов команды.

📑 Документирование, написание тестов и рефакторинг, если это не требует уникального опыта техлида.

Как развивать навык делегирования?

🌱 Начинайте с малого — постепенно передавайте небольшие задачи и оценивайте результаты.

📖 Давайте чёткие инструкции — объясняйте не только «что» нужно сделать, но и «почему» это важно.

🔄 Регулярно давайте и получайте обратную связь — это поможет улучшить коммуникацию и качество выполнения задач.

🛠 Постепенно снижайте уровень контроля — учитесь доверять своей команде, проверяя только ключевые этапы.

Как делегировать задачи так, чтобы не терять в качестве выполнения этих задач?

🔸 Создайте и поддерживайте понятные критерии приемки задач, установите регулярные code review и внедрите процессы автоматизированного тестирования.

🔸 Используйте четко сформулированные шаблоны постановки задач и контрольные чек-листы.

🔸 Проводите регулярные встречи 1:1 с командой, чтобы обсуждать возникающие сложности и оперативно корректировать направление работы.

Как научиться доверять менее опытным коллегам свои задачи?

Начните с передачи не критических задач, которые имеют низкий риск для проекта. Убедитесь, что сотрудник четко понял задачу, обсудите с ним план выполнения и сроки промежуточных проверок. Используйте подход «наблюдение-обратная связь-коррекция», чтобы вовремя помочь сотруднику справиться с проблемами. Постепенно увеличивайте уровень сложности задач, поощряя самостоятельность и инициативу.

Нужно ли архитектору лезть в работу разработчиков?

Этот вопрос регулярно всплывает на наших мероприятиях, где обсуждается роль solution architect:

📺От инженера до архитектора: живые истории карьерного роста
📺Кто такой Solution Architect и как им стать? Круглый стол
📺Рост и развитие архитектора. Презентация курса [Solution Architect in the Wild] v3

Solution-архитектор контролирует и координирует работу, но не выполняет её за разработчиков. Писать код и решать тактические задачи команд – не задача архитектора. Его задача – формировать рамки, внутри которых строится система, и контролировать соблюдение этих рамок.

🧑‍💻 Что делать, если все-таки хочется влезть в работу разработчиков?

Обычно это желание появляется из-за страха потерять контроль. Лучше всего это контролировать через регулярные встречи с лидами команд, архитектурные ревью и хорошую документацию. Полезно использовать инструменты для наблюдения за системой (observability), чтобы видеть отклонения, не проверяя каждый коммит.

🛠 Как глубоко архитектор должен разбираться в технике?

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

💻 Может ли разработчик стать архитектором и продолжать писать код?

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

🤝 Какие должны быть отношения между архитектором и командой?

Отношения должны строиться на доверии. Архитектор — не начальник, а помощник и партнер команды. Нужно сразу показать команде, что цель архитектора — упростить их работу, а не усложнять. Регулярные встречи и открытые обсуждения помогут поддерживать хорошие отношения.

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

🧠 Архитектурный Треп — уже сегодня!

После большого перерыва (с января 2025😬) снова встречаемся в формате Трепа обсудить, как AI помогает инженерам не только писать код, но и в софт-скиллах, коммуникации, планировании и других задачах.

💬 Приходите поделиться своим опытом и послушать коллег
🕗 Старт в 20:00 (GMT+3)
🔗 Регистрация по ссылке

С началом лета, друзья! 🏖

На улице тепло и солнечно (хотя и не везде – привет, Беларусь ☔️), и как-то не до обучения и развития. Мы уходим на небольшие каникулы, так что контента от нас в эти месяцы будет меньше.

🔥 Но это все не просто так! Мы готовим много интересного – практикумы по Highload, AI, no-code/low-code, квантовым вычислениям и не только.

Подробности будут ближе к осени, stay tuned!

А пока почитайте, как на этой неделе прошел Архитектурный Треп. Всем хорошей пятницы!

Первый после долгого перерыва и 123-й по счету Архитектурный трёп стал площадкой горячей дискуссии об ИИ в рабочих и личных процессах.

Участники встречи не просто рассуждали теоретически — они делились реальными кейсами и личными эмоциями.

🌍 ИИ в повседневной жизни и путешествиях

Многие участники уже активно интегрировали ИИ в бытовые вопросы.

Он мне посоветовал съездить на ферму, где семья уже лет 50-60 занимается поиском трюфелей. Они делают разные продукты, проводят дегустации и даже устраивают охоту на трюфели. Мы туда съездили, и я была просто в восторге

Но не всё так идеально. Модератор встречи Никита Щетько напомнил:

Советы надо проверять — ИИ легко может порекомендовать закрывшийся год назад ресторан

🚦 Что уже можно доверить ИИ, а что ещё рано

Искусственный интеллект уже прекрасно справляется с рутинными задачами:

- Создание summary встреч и логов.

- Переводы и улучшение текстов.

- Написание писем и характеристик.

- Подготовка черновиков документов.

- Базовые исследования.

Однако в сложных технических задачах ИИ ещё часто подводит:

- QuickFix в коде часто ошибочен. Как и сам код

- Отсутствие детерминизма: «Меня бесит, когда он угадывает ответы».

- Задачи, где нужен настоящий креатив и творчество.

Есть вещи, которые глубже, чем просто набор правил и статистика. В них ИИ ещё не до конца хорош, и он не может полностью заменить человеческий анализ и опыт

🔍 Разные LLM-модели для разных задач

- Gemini удобен благодаря визуальному интерфейсу и лёгкой смене контекста.

- Copilot любят фронтенд-разработчики: «Идеален для простых задач и шаблонов»

- Локальные модели (Llama, Nano LLM) ценят за автономность и приватность, но ругают за высокую нагрузку на устройства.

Не видел такой нагрузки — вентиляторы гудели, как самолёт

🧠 Промпт-инжиниринг: как правильно говорить с ИИ

Самые удачные ответы от ИИ участники получали, разбивая запросы на этапы:

1️⃣ Задать общий вопрос.

2️⃣ Получить базовый ответ.

3️⃣ Попросить уточнить отдельные пункты.

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

❗️ Но когда контекст слишком велик, ИИ начинает путать темы, теряя качество ответов.

👥 ИИ в работе менеджера и тимлида

Менеджеры и тимлиды активно используют ИИ для решения конфликтов и написания фидбэка сотрудникам.

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

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

Я бы расстроилась, узнав, что мой личный фидбэк написал ChatGPT. Если менеджер написал рекомендации, я воспринимаю это серьёзно и лично. И если окажется, что он считает, что со мной всё нормально, а текст написал ИИ — это неприятно

⚖️ Этические и культурные вызовы

Частое использование ИИ может привести к «клиповому мышлению», когда люди теряют способность глубоко погружаться в проблемы:

❗️ Поверхностность знаний.

❗️ Неясность ответственности за ошибки ИИ.

🔒 Локальные модели и приватность

Локальные ИИ-решения (Nano LLM, Llama) интересны своей автономностью и приватностью:

- Минимальная задержка и работа без сети.

- Безопасность данных

Локальные LLM, которые на девайсе, смогут хотя бы делать вид, что это secure. Вот это будет интересный тренд, который, наверное, мы увидим в ближайшее время, и будет интересно наблюдать, как он будет развиваться

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

🚀 Будущее профессии разработчика

Профессия разработчика заметно изменится:

🔸 Писать код просто уже недостаточно.

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

🔸 Порог входа для новичков возрастёт.

Надо прокачивать экспертизу. Просто писать код — уже прошлый век

🌟 Креативность и адаптация как залог успеха

Уникальный личный опыт останется важным преимуществом человека.

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

🔹 Навык «учиться учиться».

🔹 Системное и абстрактное мышление.

Наша задача идти на уровень выше и учиться взаимодействовать с ИИ, а не бояться его

🔥 Новый доклад H&S Conclave: Cassandra — база данных для распределённых систем

📅 12 июня, в 20:00 (GMT+3)

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

🧩 О чём поговорим:
— Когда нужны распределённые БД и зачем выбирать Cassandra
— Масштабирование, отказоустойчивость, модель данных
— Как Cassandra устроена внутри: partitioning, консенсус, репликация, gossip-протокол и многое другое.

🎤 Спикер: Владимир Хростицкий, Senior Backend Engineer. С 2010 года в разработке, сейчас работает с высоконагруженными финтех-сервисами, совмещая роли сеньора и техлида.

👉 Подробности и регистрация — на сайте. До встречи!

🎙 AI в работе инженера
Сегодня встречаемся на Архитектурном Трепе — обсудим, какие AI-инструменты стоит освоить, чтобы оставаться на волне.

📌 Легкий формат, живой разговор и короткое демо от спикера в начале.
А дальше — свободное общение и обмен опытом.

🕗 Начало в 20:00 по GMT+3
🔗 Регистрация и подробности — на сайте

Ждём вас! 🙌

🚀 Уже в этот четверг — разбираем RAG системы!

📅 19 июня | 20.00 GMT+3

Как быстро и без лишней боли собрать RAG систему — с учётом бизнес-реальности, open-source и реальных ограничений?

• Почему базовых LLM бывает недостаточно
• Что такое RAG и где он действительно работает
• С какими подводными камнями сталкиваются разработчики
• Как open-source инструменты помогают собрать RAG-систему под ключ

👨‍💻 Спикер — Данила Поддубный, Lead DevOps Engineer @ Intel
📍 Подробное описание и регистрация по ссылке

На 124-ом Архитектурном Трепе мы продолжили тему ИИ. В этот раз вместе с Peter Hanzo обсудили AI-инструменты, которые стоит освоить инженеру.

🤖 AI-агенты и как они устроены

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

У всех агентов есть обязательные составные части:

- LLM-модель («мозги» агента)
- Системные подсказки (характер агента)
- Динамические подсказки (формируются в процессе работы и зависят от контекста)
- Функции и MSP-интеграции

Агент — это такой ленивый джун. Ты ему должен объяснить задачу. Три-четыре уточнения — и он делает отлично. Но если за 3–4 не добился результата — всё, бросай

📝 Промпты: новый язык общения с машиной

Промпт – это не просто инструкция, а своеобразная игра в ассоциации, направляющая модель в нужное русло

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

Рекомендации по составлению эффективных промптов:

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

🧠 RAG-системы

RAG-система — это база знаний. У нас есть данные, документы, чаты, неважно что, мы положили их в систему и получаем ответы, быстро доставая точную информацию из памяти

Практические рекомендации для эффективной RAG-системы:

- Тщательно планируйте структуру данных и чанкинг.
- Используйте гибридный поиск (семантический, векторный и по метаданным).
- Регулярно тестируйте систему на контрольных вопросах.

У нас есть pipeline: берём документы, конвертируем в Markdown плюс метаданные в JSON. Очищаем их, делаем итоговый JSON или SQL. Исходники храним отдельно, а причесанные данные — отдельно для быстрого извлечения. Самый сложный момент — это структура исходящего JSON

🚪 MSP (Multi-Service Protocol)

MSP — это более гибкий подход к интеграции данных и сервисов, особенно в контексте AI-агентов:

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

С MSP вы не беспокоитесь о том, что завтра добавится новая функция, и придётся снова писать код. Всё, что добавляется на стороне сервиса, автоматически доступно агенту, это снимает большую головную боль с разработчиков и бизнеса

🔎 Валидация и трассировка работы AI-агентов

Недетерминированность AI-агентов сильно усложняет их трассировку и тестирование. Нужны специальные инструменты и подходы

Рекомендации по эффективной валидации:

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

💡 Практическое применение AI: Реальные кейсы

Участники делились реальными примерами успешного применения AI в бизнесе и повседневной жизни:

🔸Создание контента и генерация документов.
🔸Использование AI в разработке (GitHub Copilot).
🔸Персональная продуктивность.
🔸Автоматизация общения с клиентами (чат-боты и поддержка).
🔸Внутренний обмен информацией (RAG-системы, Notion).
🔸Обработка документов, счетов и заявок с помощью AI.

💼 Карьерные перспективы: AI как обязательный навык

Если сотрудник не умеет работать с AI, он менее эффективен. Это уже не бонус, а обязательное требование работодателя

В эпоху AI появятся новые роли: AI-интегратор, специалист по мониторингу AI-агентов.

Советы по карьерному росту:

🔹Регулярно обновляйте знания и следите за AI-новинками.
🔹Развивайте не только технические навыки, но и soft skills (аналитика, критическое мышление).
🔹Используйте AI для повышения личной продуктивности и эффективности в своей сфере.

Integration Development: от общей архитектуры до Mulesoft на практике

📅 26 июня | 🕗 20:00 (по GMT+3)

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

🔗 Подробности и регистрация — на сайте. До встречи!

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

Ответ на этот вопрос – матрица навыков Hard&Soft Skills. Она основывается на анализе опыта нескольких десятков IT-компаний – от небольших стартапов до Big Tech. Поговорим о том, как она устроена, и как ей пользоваться:

⚙️ Hard Skills: 

Две группы навыков: Код и Архитектура. Первая – про работу руками. Вторая – про понимание устройства систем.

🔸 Код. Написание кода, архитектура кода, владение инструментами, владение AI, тестирование и устранение багов.

Между кодом и архитектурой – навык написания документации.

🔸 Архитектура. Технический кругозор, System Design, Architectural Vision.

Между архитектурой и навыками коммуникации – умение убеждать и обосновывать свои решения.

💡 Soft Skills: 

Коммуникация – про взаимодействие с людьми. Impact – про влияние на организацию.

🔸 Коммуникации. С командой, с другими командами, менторинг.

Между коммуникациями и impact-ом – умение проводить митинги.

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

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

👥 Менеджмент: 

Stakeholder management – про взаимодействие с теми, на кого нет прямых рычагов управления. Лидерство – про работу с подчиненными.

🔸 Stakeholder management. Выявление стейкхолдеров в проекте, коммуникация со стейкхолдерами, сбор требований.

Между стейкхолдер-менеджментом и лидерством – способность решать конфликты.

🔸 Лидерство. Делегирование задач, создание и оптимизация процессов, управление командой/командами.

Замыкая круг, возвращаемся к hard skills. Между лидерством и кодом – умение проводить код-ревью и контролировать качество кода.

📍 Как определить свой текущий уровень по диаграмме навыков?

- Оцените сложность и количество реализованных задач end-to-end. Оцените свой вклад в архитектурные решения. 

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

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

После этого нанесите результаты на диаграмму. Используйте шкалу от 0 до 7:

0-1 — нет или минимальный опыт.
2 — выполняю с чьей-то помощью.
3 — работаю автономно на продакшене.
4 — выполняю наиболее сложные задачи, могу делиться экспертизой (в том числе в качестве спикера на мероприятиях)
5 — задаю стандарты в команде.
6 — влияю на несколько команд.
7 — мои решения сказываются на всей компании.

📈 Как понять, каких компетенций и навыков не хватает?

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

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

🔴Критически важные для бизнеса и продукта.
🟡Важные для карьерного роста.
🟢Простые в улучшении – «быстрые победы».

💪 Как максимально использовать свои сильные стороны?

Ваши сильные стороны — это то, на чём можно строить ваш профессиональный бренд и карьеру. Вот несколько примеров:

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

Если ваша сильная сторона — коммуникация и менторинг, то растите в сторону engineering-менеджера.

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

Почему проектировать системы сложно?

Потому что архитектура — это отражение не только кода, но и людей, процессов и бюджета. Чем больше бизнес‑доменов и команд участвует, тем чаще приоритеты конфликтуют: Latency спорит с consistency, гибкость — со стоимостью.

Мы проектируем не «идеальную» систему, а компромисс между десятком противоречивых критериев, и на согласование такого компромисса уходят недели.

🚦 Какие ограничения управляют архитектурой?

Помимо функциональных требований – того, что должна делать система, – есть три группы ограничений, о которых легко забыть:

🔸 Организация. Conway’s Law: архитектура наследует оргструктуру, а не наоборот.
🔸 Нефункциональные требования. Безопасность, комплаенс, observability и data residency обычно приходят поздно и требуют пересобирать фундамент.
🔸 Экономика. Архитектура без бизнес‑модели превращается в золотой прототип; CapEx, OpEx и стоимость простоя критичны не меньше, чем RPS.

🌪 Как неопределённость требований ломает даже безупречные схемы?

Доля известных требований на старте редко превышает 10 %. Остальное — гипотезы. Если мы фиксируем слишком много деталей заранее, каждая новая бизнес‑гипотеза вызывает каскад изменений.

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

Такой подход сокращает стоимость изменений и позволяет эволюционировать, не переписывая ядро.

🚲 Какие паттерны усложнения мы тащим из проекта в проект?

🔹 «А вдруг пригодится». Добавляем feature‑флаги, лишние слои абстракции и используем 10 % сегодня, поддерживаем — 100 %.
🔹 «Сделаем, как в BigTech». Копируем решения FAANG без их масштаба – получаем избыточную сложность. Кроме того, даже в FAANG работают люди (пока еще), и они, совсем как мы, не знают свои требования и ошибаются.
🔹 «Каждый сервис максимально автономен». Граф зависимостей растёт быстрее, чем успеваем управлять SLA – в итоге надёжность падает.

🛠 Какие приёмы реально упрощают проектирование?

🔸 Документируйте контекст вместо картинок. ADR + Context Map дают больше ценности, чем идеальная C4‑диаграмма.
🔸 Разделяйте «сложно» и «часто меняется». Самую динамичную логику выносите в stateless‑слои или покупайте как SaaS.
🔸 Проверяйте гипотезы экспериментами. GameDays, chaos‑injectors и canary‑запуски дают дешёвый и правдивый фидбек.
🔸 Упростите коммуникацию. Чем меньше стейкхолдеров в критическом пути, тем меньше компромиссов отражается в коде.
🔸 Метрики поверх диаграмм. Введите 2–3 показателя (Mean Time to Recovery, Cost per Transaction, Cycle Time) — то, что не измеряется, стремительно усложняется.

Архитектурные катастрофы: уроки провальных проектов

🐌 Friendster – пионер, споткнувшийся о масштабирование

Соцсеть Friendster первой взорвала рынок, но техническая архитектура не выдержала успеха. С ростом аудитории сайт чудовищно тормозил – загрузка страницы доходила до 40 секунд! Руководство же отвлеклось на новые фичи (VoIP, локализация) вместо решения проблемы производительности.

В итоге миллионы перебрались на более шустрые MySpace и Facebook, которые уже не споткнулись о критические ошибки масштабирования.

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

🐋 Twitter и эра Fail Whale

Изначально Twitter работал на монолитной архитектуре с базой MySQL, что приводило к каскадным сбоям при взрывном росте пользователей. Каждый крупный инцидент сопровождался появлением “кита, поднятого птицами” (символ Fail Whale).

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

Урок: не накапливайте технический долг – без периодической переработки архитектура достигнет «точки излома». Инвестируйте в масштабируемость и отказоустойчивость до того, как система начнет сыпаться.

💸 Knight Capital – сбой, стоивший $440 млн

При ручном обновлении трейдингового софта инженер забыл обновить 1 из 8 серверов – там остался старый код. На следующий день этот сервер запустил «призрачный» алгоритм и начал бесконтрольно скупать и продавать акции тысячами ордеров в секунду. За 45 минут компания потеряла ~$440 млн, фактически обанкротившись.

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

Урок: нельзя полагаться на героя-одиночку в продакшене. Один из разоривших Knight факторов – полное отсутствие надежных процессов выпуска и контроля качества.

🏥 Провал Healthcare.gov и чудесное спасение

В 2013 США запустили портал Healthcare.gov для Obamacare – и он мгновенно лег. В первый день из 4 миллионов посетителей лишь шестеро смогли зарегистрироваться! Критически плохая интеграция десятков государственных систем, отсутствие сквозного тестирования и раздробленное руководство превратили запуск в кошмар.

Белый дом создал команду из топ-инженеров Кремниевой долины, чтобы выправить архитектуру. За 6 недель они устранили ~400 дефектов и сократили время отклика до 1 секунды. Проект удалось вытащить, но цена вопроса превысила $2 млрд.

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

🕸 Стартап, задушенный микросервисами (и спасённый отказом от них)

Стартап из 5 разработчиков Kitrum решил «сделать всё правильно» и с самого начала разбил продукт на 7 микросервисов (отдельно: пользователи, платежи, уведомления и т.д.).

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

Осознав ошибку, команда откатилась к одному хорошо организованному монолиту – и скорость разработки сразу подскочила вдвое.

Урок: не стоит усложнять архитектуру раньше времени. Часто простой монолит на старте дает скорость и фокус, а масштабировать и дробить можно уже после достижения успеха.

Как устроены RAG-системы в реальной разработке? С какими проблемами сталкиваются команды при масштабировании на сотни тысяч документов? Как взаимодействие с LLM меняет поведение системы? Что чаще всего ломает качество ответов — и как это исправлять?

Завтра на Архитектурном Трёпе №125 обсудим практический опыт построения и масштабирования RAG-систем:
— разберём архитектурные подходы,
— поделимся кейсами из реальных проектов,
— обсудим типичные ошибки и подводные камни при работе с retrieval + LLM.

📅 Старт в 20:00 (GMT+3)
📌 Регистрация по ссылке

Завтра, 17 июля на H&S Conclave доклад на тему "Будущее для Manual QA: как AI переизобретает подходы в тестировании"

🧭Начало в 20.00 GMT+3

Поговорим о том, как искусственный интеллект меняет мануальное тестирование и трансформирует подходы к QA-планированию. Вы узнаете, какие задачи уже сегодня можно делегировать AI, как изменяются роли тестировщиков и какие риски стоит учитывать при внедрении новых инструментов.

🔍 Что обсудим:

• Как AI помогает генерировать тест-кейсы и тест-планы на основе требований и кода

• Интеграции с Jira, Allure TestOps, GitHub — автоматизация тестирования без лишней рутины

• Автоматический анализ Pull Requests и сопоставление изменений с требованиями

• Практические аспекты внедрения AI: что реально работает в продакшене, а что нет

• Как изменяются подходы к QA-планированию под влиянием новых технологий

• Реальные кейсы использования Cursor в инженерных командах

🤝 Подключайтесь завтра и обсудим, что ждёт Manual QA в ближайшем будущем! Регистрация