🔥 Новый доклад 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 в ближайшем будущем! Регистрация

На Архитектурном трёпе #125 обсудили работу с системами Retrieval-Augmented Generation (RAG).

🎯 С чего начинать: готовые решения или своё?

Я рекомендую сначала взять готовое SaaS-решение за $100 в месяц, проверить свои гипотезы, понять, что именно вам нужно, а уже затем задумываться о собственной разработке

Советы участников по первому этапу:

🔸Быстро тестируйте идеи на готовых решениях
🔸Не усложняйте сразу — идите от простого к сложному
🔸Применяйте проверенные библиотеки (LamaIndex, LangChain)

🧩 Векторный и гибридный поиск

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

Проблемы чистого векторного поиска:

🔹Потеря семантики из-за неправильного чанкирования
🔹Снижение производительности при увеличении объёмов данных
🔹Недостаток точности при обработке сложных запросов

Рекомендуемые практики:

🔸Сочетайте векторы с дополнительными фильтрами
🔸Структурируйте метаданные заранее
🔸Используйте LLM для автоматизации создания метаданных

🗄 Проблемы хранения данных

Участники сошлись во мнении, что оптимальный подход состоит из нескольких уровней:

🔹Исходные файлы (PDF, изображения) — отдельно, например, в S3
🔹JSON-данные и промежуточные структуры — в MongoDB
🔹Финальные векторные данные — в PostgreSQL с PgVector или специализированные векторные базы

📑 Чанкирование и обработка информации

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

Рекомендации по чанкированию:

🔸Начинайте с базовых подходов (по абзацам)
🔸Применяйте LLM для определения границ смысловых блоков
🔸Вручную дорабатывайте чанки для сложных документов

🗃 Разные типы информации — разные архитектурные решения

🔹Простые тексты требуют минимум усилий
🔹Таблицы и формулы нуждаются в отдельной логике обработки
🔹JSON-данные и транскрибации разговоров требуют особой структуры

Каждый тип данных — это новая архитектурная задача. Всегда учитывайте, как новая информация повлияет на вашу RAG-систему

🛠 Реальные кейсы, проблемы и рекомендации

Модератор встречи Peter Hanzo поделился кейсом из практики:

Мы делали поиск агрохимикатов. Пользователь задаёт вопрос, чем лечить томаты от конкретной болезни. RAG-система на основе векторного поиска и фильтрации по метаданным из нескольких тысяч препаратов выделяет 5 подходящих

Другие практические советы от участников:

🔹Используйте реальные запросы пользователей
🔹Тестируйте RAG-системы на заранее подготовленных наборах вопросов
🔹Применяйте LLM для постобработки и улучшения результатов
🔹Не забывайте о пользователях

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

🔗А еще Peter Hanzo поделился списком полезных материалов по теме:

раздел Вступление в RAG
https://docs.llamaindex.ai/en/stable/understanding/rag/
https://github.com/mem0ai/mem0
https://github.com/memodb-io/memobase

раздел Векторный поиск
https://github.com/pgvector/pgvector
https://weaviate.io/blog/multimodal-search-in-typenoscript
https://jkatz05.com/post/postgres/hybrid-search-postgres-pgvector/

раздел Гибридный поиск
https://docs.opensearch.org/docs/latest/vector-search/ai-search/conversational-search/#step-6-use-the-pipeline-for-rag
https://aws.amazon.com/ru/blogs/big-data/amazon-opensearch-service-vector-database-capabilities-revisited/
https://github.com/meilisearch/meilisearch
https://nuclia.com/
https://github.com/infiniflow/infinity

раздел Проблемы и Хранение
https://unstract.com/
https://github.com/quivrhq/megaparse
https://github.com/docling-project/docling

раздел Готовые проекты
https://github.com/infiniflow/ragflow
https://github.com/Cinnamon/kotaemon
https://github.com/deepset-ai/haystack
https://github.com/milvus-io/milvus
https://github.com/HKUDS/LightRAG
https://github.com/oramasearch/orama
https://github.com/gusye1234/nano-graphrag
https://github.com/vanna-ai/vanna
https://github.com/trustbit/RAGathon
https://github.com/danny-avila/rag_api
https://github.com/confident-ai/deepeval

🚀 Завтра встречаемся на митапе «AI-ассистент для разработчиков: внедрение и метрики в большой организации»!

Как встроить AI в ежедневную практику разработчиков? Разбираем реальный кейс: от подготовки репозитория и промптов до измерения метрик и обратной связи от команды.

🎤 Спикер — Ильшат Назаргулов, Lead Backend Developer с 10+ годами опыта.

📅 Присоединяйтесь, начало в 20.00 GMT+3

🎙 Друзья, завтра собираемся обсудить один из самых волнующих вопросов этого года - что происходит с работой в 2025 и что нас ждёт дальше?

Когда: 24 июля, в 20.00 GMT+3

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

‣ Где действительно сейчас находят работу?
‣ Нужно ли backend-инженерам осваивать фронт (и наоборот)?
‣ Две работы одновременно - норма или путь к выгоранию?
‣ Как AI уже меняет нашу работу, и какие риски и возможности ждут впереди?

📌 Регистрация
До встречи!

Навыки техлида: Architectural Vision и его значение

🏗 Architectural Vision: фундамент успешного проекта

Architectural vision – это способность задать технический курс разработки: спроектировать систему под бизнес-цели, предвидеть будущие потребности и создать целостную структуру, которой будет следовать команда.

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

🧭 Роль техлида в архитектуре

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

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

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

Эффективный техлид сочетает навыки архитектора и ведущего разработчика: создаёт в команде общее техническое видение и несёт ответственность за качество технических решений.

⚠️ Когда архитектурного видения не хватает

Отсутствие продуманной архитектуры способно похоронить даже перспективный проект. По данным исследования Standish Group, 50% провалов IT-проектов происходят из-за ошибок в архитектуре.

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

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

📋 Architectural Vision на практике: что делает техлид?

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

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

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

🔸 Доносит архитектуру до команды: эффективный техлид не держит архитектурные идеи в голове – он визуализирует их. Это позволяет разработчикам понять свои задачи в контексте всей системы. Обсуждая архитектуру вместе с командой, техлид повышает общую инженерную культуру и вовлечённость – каждый понимает, зачем выбран тот или иной подход.

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

🚀 Взгляд вперёд как ключевой навык

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

🧠 Уже завтра встречаемся на митапе - Agentic AI: зачем он нужен и как работает?

📅 29 июля, 20:00 GMT+3

Что такое агентный ИИ и почему за ним будущее? Обсудим архитектуру AI-агентов, реальные кейсы, ограничения LLM-подходов и как их преодолевает agentic AI.

👨‍💻 Спикер: Данила Поддубный, Lead DevOps Engineer @ Intel

Регистрация

Привет, друзья! 👋
А есть тут кто из Казахстана? 🇰🇿

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

Если вы в Алмате или поблизости — очень ждём ваш голос! 🙌

PS. И если вам интересно помочь с организацией, поделиться советом или выступить на митапе — пишите Даше: @d_zherebtsova

📌 Архитектура без архитектора? Приходите обсудить!

Круглый стол для инженеров и техлидов — обсудим, где заканчивается зона ответственности разработчика и начинается архитектура. Что происходит, когда решения принимаются “де-факто”? И нужна ли вообще формальная роль архитектора?

📅 7 августа, 20:00 GMT+3
🎙 Ведущий: Антон Дворников, Principal Solution Architect
👥 Участники:
‣ Вячеслав Панасов, руководитель направления
‣ Артём Жильцов, Tech Lead в FinTech

👉 Зарегистрироваться

На 126-м Архитектурном Трёпе обсудили текущее состояние рынка труда в IT, новые тренды в найме и использовании AI.

Вот краткая выжимка беседы:

📉 Текущая ситуация на рынке труда и тренды в найме

Рынок IT стал более конкурентным:

🔸На каждую вакансию теперь поступают сотни откликов
🔸Процессы собеседования усложнились и включают больше этапов даже в небольших компаниях
🔸Важность личного нетворкинга выросла в разы
🔸Компании используют автоматизированные системы отбора (ATS), поэтому критично включать правильные ключевые слова в резюме
🔸В Европе ужесточились языковые требования – часто обязательно владеть местным языком

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

🤖 ИИ и его влияние на разработчиков

AI уже плотно интегрирован в повседневную работу разработчиков и приносит существенные бонусы:

🔹Сильно ускоряет рутинные задачи и кодинг
🔹Ускоряет навигацию и поиск информации в больших проектах

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

Но участники выражают опасения о качестве сгенерированного кода:

Люди бездумно копируют код, сгенерированный AI, не понимая, как он работает. Это создаёт проблемы поддержки и качества продукта в долгосрочной перспективе

🛠 Новые требования к профессиональным навыкам разработчиков

🔸Высокий спрос на fullstack-специалистов с пониманием бизнеса и инфраструктуры
🔸Ценность разработчиков, умеющих эффективно интегрировать AI-инструменты в рабочий процесс
🔸Важность навыков системного и архитектурного мышления

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

🌍 Этические и культурные аспекты использования AI

Использование AI в коммуникациях и управлении сотрудниками поднимает важные этические вопросы:

🔹Проблемы доверия к автоматизированной коммуникации
🔹Ответственность за ошибки, допущенные при использовании AI
🔹Риск снижения творческого потенциала сотрудников

Если сотрудник узнает, что важный фидбэк был написан AI, это может серьезно подорвать доверие и внутреннюю культуру компании

⚡️ Практические советы для кандидатов и работодателей

🔸Активно развивайте свой LinkedIn-профиль и нетворк
🔸Используйте AI не для слепого копирования, а для помощи в работе и ускорения рутинных задач
🔸Старайтесь глубоко разбираться в задачах, не полагаясь полностью на автоматизацию

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

ИИ — угроза или возможность?
Как меняется работа инженера под давлением искусственного интеллекта?

🗓 12 августа, в 20.00 GMT+3

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

Темы дискуссии
📉 Тренды и рынок:
– Что происходит с ИТ-вакансиями?
– Какие роли исчезают, а какие наоборот набирают вес?

🤖 Влияние ИИ:
– Какие задачи уже автоматизирует ИИ?
– Станет ли команд меньше? Как изменится найм?

🧩 Новые навыки:
– Какие компетенции становятся must-have в 2025?
– Нужно ли инженерам изучать Prompt Engineering и LLM?

🔁 Найм и карьера:
– Что определяет сильного кандидата сегодня?

🧭 Личное и системное:
– Как понять, что ты отстаёшь от рынка?
– Где искать точки роста — и как помогает комьюнити?

👉 Оставить свой вопрос и зарегистрироваться

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

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

🌩 Netflix – трёхдневный сбой, изменивший всю архитектуру

В августе 2008 у Netflix из-за серьёзной порчи базы данных лег почти на три дня, остановив отправку DVD-дисков подписчикам. Корень проблемы – монолитная система с единой точкой отказа.

Инженеры Netflix отказались от вертикально масштабируемого монолита с централизованной БД и перешли к распределённой облачной системе микросервисов, устранив «single point of failure».

За последующие годы Netflix постепенно перенёс все компоненты в AWS, добившись высокой отказоустойчивости и масштабируемости. Появилась «Chaos Monkey» – утилита, намеренно ломающая произвольные части системы в продакшене, чтобы убедиться, что всё выдержит падение любого узла.

Сегодня Netflix сегодня способен пережить отключение целого дата-центра без заметных последствий.

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

🗑 Netscape – переписали с нуля и проиграли «войну браузеров»

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

На это понадобилось больше двух лет, за которые конкуренты ушли далеко вперед. Internet Explorer от Microsoft (бесплатный и агрессивно продвигаемый) захватил пользователей, пока в Netscape работали над новой версией. Когда переписанный Netscape 6 наконец вышел, было поздно – аудитория уже ушла, доля рынка рухнула.

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

Netscape стал ярким примером Second System Syndrome, когда попытка создать «идеальный» второй вариант убивает рабочий первый.

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

🏙 SimCity 2013 – «всегда онлайн», в который никто не смог играть

Релиз игры SimCity 2013 стал примером того, как неудачное архитектурное решение способно уничтожить репутацию продукта в первый же день. Компания EA заложила в архитектуру требование always-online: даже одиночная игра требовала постоянного подключения к серверу.

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

Обязательное подключение было навязано в основном как DRM (защита от пиратства), а не ради геймплея. Разработчики уверяли, что без онлайн-сервисов игра не сможет работать, но пользователи быстро доказали обратное – энтузиасты вскоре запустили нелегальный офлайн-режим.

Оказалось, что ничего критичного в онлайне не было, и маркетинговые заявления EA были неправдой. Это подорвало доверие окончательно. Даже спустя время, когда патчи частично исправили ситуацию, игра уже потеряла аудиторию (которая перебралась в Cities: Skylines и другие проекты). Легендарная серия SimCity фактически похоронила себя этой неудачей.

Урок: Если вы закладываете жёсткие ограничения ради бизнес-целей, убедитесь, что ваша инфраструктура потянет. Архитектура должна служить интересам пользователя – навязывание неудобных решений (ещё и плохо реализованных) оборачивается катастрофой для продукта.