Архитектурные катастрофы: уроки провальных проектов - Часть 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 фактически похоронила себя этой неудачей.

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

🚀 Как построить AI-инфраструктуру и не сойти с ума?

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

📅 Когда: 14 августа, 20:00 (GMT+3)

💡 В программе:

• Как подойти к проектированию AI-инфраструктуры на разных стадиях компании
• Лучшие практики, проверенные в боевых условиях
• Типичные ошибки и как их избежать
• Лайфхаки, которые экономят время и ресурсы команды

🎙 Формат: доклад + живое обсуждение — можно будет задать свой вопрос и разобрать реальные ситуации участников.

👤 Спикер: Данила Поддубный, Lead DevOps Engineer @ Intel. Специалист по высокопроизводительным вычислениям и инфраструктуре для ИИ-обучения

👉 Регистрация

📢 19 августа приглашаем на Круглый стол о роли технического лидера сегодня!

Вместе с выпускниками и выпускницей программ H&S Skills поговорим честно и без фильтров:
— какие вызовы стоят перед лидерами в 2025 году
— чему учатся и на чём ошибаются
— как внедряют новые технологии и при этом держат команду в фокусе

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

💬 Темы: путь в техлиды, роль и задачи, ошибки и инсайты, работа с AI, команда и процессы.
🎯 В финале: советы тем, кто хочет расти в новую роль, и тем, кто уже делает первые шаги.

🕗 Начало: 20:00 GMT+3

🙌 Регистрируйтесь по ссылке и оставляйте свои вопросы!

Эволюция API: совместимость, версии, депрекация

API неизбежно меняется. Задача техлида — сделать так, чтобы новые возможности не ломали клиентов и чтобы старое уходило предсказуемо. Ниже — концентрат практик для REST/gRPC/GraphQL.

📐 Правила контрактов (REST / gRPC / GraphQL)

REST. Добавляйте — не изменяйте: новые необязательные поля, стабильные коды и семантика. Не переиспользуйте поля, не меняйте форматы без явной версии. Идемпотентность для PUT/DELETE, ETag/If‑Match для конкуренции.

gRPC. В protobuf не трогайте номера полей, не меняйте типы/смысл, помечайте reserved для удалённых. Новое — через optional/поведенческие флаги. Версии — в package/service‑имени, параллельные реализации допускаются.

GraphQL. Расширяйте схему (новые поля/типы), не удаляйте и не переименовывайте. Используйте @deprecated(reason) и телеметрию по полям. Не ужесточайте nullability без major‑миграции.

🚦 Версионирование

Минимум версий — максимум совместимости.

REST: для breaking‑изменений — vN (лучше в header/mediatype; путь — допустимо, но грубо). Для additive — без версии.

gRPC: новая major — новый package/service; клиенты пинят контракт.

GraphQL: обычно одна активная схема; breaking — через параллельную схему/шлюз на время миграции.

🧰 Feature gates и capability‑договорённости

Включайте новые поведения по флагам (per-tenant/per-token). Клиент может передавать заголовок/параметр «хочу новую фичу», сервер — объявлять поддерживаемые возможности (capabilities) в метаданных/SDL.

⏳ Депрекация и sunset policy

Фиксируйте этапы: объявление → фриз → ограничение → отключение. Сигнализируйте в ответах (заголовки/метаданные, предупреждения в GraphQL), укажите дату sunset и альтернативу. Замерьте фактическое использование и держите окно поддержки (например, 6–12 месяцев).

🧪 Контрактное тестирование

Consumer‑driven подход: контракты клиентов выполняются против «будущей» версии (Pact/Spring Cloud Contract). Для REST — проверка OpenAPI/примеров/генерации SDK; для gRPC — buf breaking/lint; для GraphQL — проверки схемы, запроса и директив депрекации. Интегрируйте в CI, блокируйте breaking без явного major.

📣 Коммуникация с клиентами

Единый каталог API, changelog, рассылки/вебхуки о депрекациях, версии SDK и примеры миграции. SLA по окнам поддержки, статусная страница, канареечные релизы. Меряйте: кто вызывает устаревшее, какие поля/методы — и целенаправленно помогайте мигрировать.

✅ Чек‑лист эволюции API (REST / gRPC / GraphQL)

🔸 Контракт зафиксирован (OpenAPI/Protobuf/SDL), lint и «breaking‑скан» в CI.
🔸 Добавочные изменения — без версии; breaking — только через новую major.
🔸 Feature gates: план включения per‑client, откат и метрики.
🔸 Телеметрия по endpoint/методу/полю, дэшборды использования.
🔸 Sunset policy с датами, сообщениями и альтернативами.
🔸 Consumer‑driven контракты, авто‑ген SDK и примеры миграции.
🔸 Каталог API и понятный changelog; канареечный/теневой прогон.
🔸 План совместного существования версий и критерий выключения (0 трафика N дней).

🧭 План миграции без боли

🔹 Инвентаризация клиентов и их версий; включите метки клиентских приложений.
🔹 Запустите vNext совместимым (тени/dual‑write), соберите метрики.
🔹 Откройте feature gate избранным клиентам → канареечное расширение.
🔹 Заморозьте v1 (только багфиксы), объявите даты и гайды.
🔹 Переведите SDK/CLI и шаблоны; помогите ключевым клиентам руками.
🔹 После 0 трафика на v1 N дней — поэтапно отключайте, оставив «красную кнопку» отката.

Эволюция API – это не разовый "v2". Формализуйте правила, измеряйте использование, коммуницируйте заранее – и ваши изменения станут предсказуемыми для клиентов и безопасными для бизнеса.

Друзья, всех с пятницей!🕺

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

👉 Если у вас есть свой проект (в Telegram, LinkedIn, Medium или где угодно), вы публикуете что нибудь интересное или организуете мероприятия — онлайн или офлайн — делитесь ссылкой в комментариях.

Мы собираем список таких проектов, чтобы потом поискать классные идеи и возможности для коллабораций 💪

PS. или присылайте в личку Даше @d_zherebtsova

Переход в техлиды: как не потерять технические навыки

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

Шире зона ответственности – меньше hands‑on. Из‑за страха потерять форму многие тормозят переход. Поговорим о том, как сохранить технические навыки, когда на первый план выходит лидерство.

🧠 Какие технические навыки должны быть у техлида?

Это не только про написание кода. Технические навыки это еще: 

🔹 Читать и ревьюить PRы 
🔹 Проектировать архитектуру, которую смогут реализовать другие разработчики
🔹 Разбирать инциденты по метрикам/трейсам/логам
🔹 Понимать CI/CD и стоимость инфраструктуры
🔹 Управлять безопасностью и данными

Умение разбираться во всем этом даёт доверие команды, качество решений и возможность преодолевать кризисы, когда важны точные технические trade‑off’ы.

🛠Где углубляться, а где расширяться: T‑shape

Глубина – 1-2 ключевых вертикали вашего домена (например, платформа данных и производительность; надёжность и безопасность). Здесь вы задаёте стандарты и отвечаете за сложные решения. 

Ширина – грамотность в соседних областях: протоколы и интеграции, типы хранилищ, облака/сети, CI/CD, SLO и экономика эксплуатации. 

Суть T‑shape: вы обязаны видеть последствия решений соседей и ставить guardrails, но не становиться единственной «точкой знания» по всем стекам.

⌨️ Как поддерживать навыки написания кода и не стать bottleneck для команды

🔸 Квоты на код. Выделите 4–6 часов в неделю на low-risk задачи: техдолг, тест‑фиксы, внутренние утилиты. Малые PR, trunk‑based, без критического пути
🔸 Tracer‑bullets. Разрабатывайте быстрые прототипы для новых идей (1–2 дня), а затем передавайте другим исполнителям
🔸 Парное программирование. Вы сохраняете практику, команда растёт
🔸 On‑call с кодом. Ротация дежурств раз в квартал с «fix‑forward» правками: учит быстрому чтению незнакомого кода
🔸 Инфраструктурные библиотеки. Курируйте 1–2 общие библиотеки/шаблоны (логирование, ретраи, telemetry). Это регулярный hands‑on и мультипликатор для команды
🔸 Ограничьте блокировки. SLA на ревью (например, ≤24 часа), резервные ревьюеры, запрет «последней кнопки» деплоя у техлида

📏 Как измерять impact, когда не пишешь код?

Смотрите на результаты системы. DORA‑метрики показывают скорость delivery (lead time for changes, частота деплоя, time to recover, доля неуспешных изменений). 

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

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

⚠️ Ошибки и антипаттерны начинающих техлидов

🔹 Супер‑разработчик. Пишете ключевой код сами — команда ждёт. Решение: RACI, владение модулями у инженеров, вы — наставник и арбитр
🔹 Big‑bang переписывания. “Сделаем правильно с нуля”. Решение: эволюция, strangler pattern, поэтапные критерии успеха
🔹 Ревью bottleneck. Все PR через вас. Решение: стандарты кода, обучение ревьюеров, два параллельных потока ревью, авто‑чеки
🔹 24/7 митинги. Календарь съедает все рабочее время. Решение: тайм‑боксы, асинхронные ADR
🔹 Архитектура без эксплуатации. Решения без данных эксплуатации. Решение: дизайн‑сессии с on‑call, телеметрия и canary перед масштабированием

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

⚙️ О нас

Hard&Soft Skills community – это объединение инженеров, для которых разработка – больше, чем код.
Мы создаём среду для ИТ специалистов, которые хотят расти шире кода – разбираться в архитектуре, процессах, продуктах и людях.

🎤 Наши форматы

Мы регулярно проводим онлайн мероприятия в разных форматах: Архитектурные Трепы, технические доклады, митапы, круглые столы, live-design cессии и др.

👉 Расписание ближайших событий смотрите в нашем календаре.

Но мы хотим не только встречаться онлайн, а ещё и знакомиться вживую 🕺

Этой осенью запускаем серию оффлайн-встреч в разных городах: Батуми, Минск, Алматы, Варшава. Первая встреча пройдет 18 сентября в Батуми, следите за апдейтами 👀

🤝 Как участвовать

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

А ещё мы очень ценим вашу повседневную активность 🙌 Когда вы приходите на мероприятия, читаете посты, комментируете и ставите реакции – именно это делает наше комьюнити живым и ценным.

💬 Где общаемся

📢 Канал в Telegram (вы здесь!) – анонсы, полезные материалы, опросы.
💬 Чат в Telegram – задать вопроc, обсудить профессиональные трудности, поделиться новостями или найти поддержку.
▶️ YouTube-канал – записи всех встреч, которые вы могли пропустить.

📚 Лучшие посты и материалы в канале

[Компетенции разработчика: как найти свои слабые и сильные стороны?]
[Чек-лист техлида: все ли хорошо у вас на проекта?]
[Почему проектировать системы сложно?]
[Event Sourcing: что это, зачем нужно и когда применять?]
[Что мешает разработчику расти?]
[4 фундаментальные книги для техлида]
[Чек-лист: готовы ли вы стать архитектором?]
[4 must-read книги для архитектора]

📌 Сохраняйте этот пост, он будет вашим ориентиром. И добро пожаловать в комьюнити Hard&Soft Skills 🫂

Мы не успели обсудить тему поиска работы на прошлом Трёпе, поэтому по вашим запросам проводим её ещё раз 🙌

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

🗓 28 августа, 20:00 (GMT+3)
🎙 Архитектурный Трёп №127

Тема: Как мы ищем работу сегодня: обмен реальными кейсами

Поговорим о том, какие каналы реально работают, что только тратит время, насколько помогают нетворкинг и личный бренд, и разберём успешные кейсы трудоустройства в Европе и США.

👤 Модератор: Виктория Телюк

🔗 Регистрация

Друзья!

26 августа мы провели митап «Технический лидер», на который предварительно зарегистрировалось почти 700 участников!

К сожалению, из-за ограничений Google Meet не все смогли подключиться онлайн.
Мы приносим извинения за неудобства 🙏 и предлагаем вам посмотреть митап в записи:

🎥 Ссылка на запись митапа

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

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

А если у вас ещё остались вопросы – приглашаем на бесплатную консультацию с ex-Architect Miro и EPAM Павлом Вейником:
👉 Записаться на консультацию

Количество слотов ограничено, успейте забронировать!
Всем продуктивного дня ✨

Как мы ищем работу сегодня: обмен реальными кейсами - выводы Архитектурного трёпа #127

🎯 Где и как находят работу сегодня: новые требования к разработчикам

Сегодня выигрывают те, кто соединяют широту навыков с управляемым использованием AI: T‑shaped (бэк, фронт, немного DevOps) + умение объяснить промптинг и валидацию решений

Рабочие каналы – прямые сообщения нанимающим и рефералы. Они срабатывают лучше массовых откликов.

Границы между специальностями стираются… в одном человеке хотят фронт, бэк, шарить за DevOps – и опыт внедрения LLM в процессы

🌍 Состояние рынка по стекам и регионам: AI в работе и на собеседованиях

По стекам спрос смещается: где‑то «потише» по Java, местами активнее зовут на Go; full‑stack‑профили продаются легче, особенно в распределённых командах.

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

На лайвкодинге стали разрешать AI: в работе всё равно будете пользоваться; запрещать — всё равно что заставлять писать в текстовом редакторе

🎰 Процессы найма: как происходит, ATS и «лотерея» откликов

Типовой конвейер удлинился: скрининг → офлайн‑задача → live‑coding → финальный разговор; встречаются IQ/логические этапы и разношёрстные форматы в зависимости от страны и культуры компании.

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

Подался на 168 вакансий: ~67 зависли, ~70 – автодеклайн… в итоге пять офферов

📄 Резюме и личный бренд: pet‑проекты, сертификации, LeetCode

Резюме – до 2 страниц, последние 5 лет и измеримые результаты (формат STAR); актуальные технологии – компактным блоком.

Pet‑проекты позиционируйте как микро‑продукты (проблема → решение → метрика), open‑source даёт видимые артефакты и красивую строчку в резюме.

Сертификации окупаются там, где есть бизнес‑эффект (клауд‑партнёрства, CKA/CKAD для верификации глубины); общие бумажки по языкам редко конвертят.

LeetCode – инструмент по назначению: для корп‑циклов – структурная подготовка (Blind‑75/NeetCode), для продуктовых команд важнее чистый код и кейсовое мышление.

🛠 Практические стратегии поиска работы

Действовать лучше по чек‑листу, а не по вдохновению:

🔸 Ранний отклик (в первые сутки)
🔸 Зарплатные фильтры на площадках вроде Glassdoor/Genie
🔸 Ведение своей статистики воронки
🔸 Локализация коммуникации под страну (лексика, ожидания, формат интервью)
🔸 Использование программ для newcomers там, где они есть
🔸 Тактическая гибкость: при переезде допустим «вход» на пол‑грейда ниже с быстрым ростом внутри

Стратегия – это не список инструментов, а последовательность решений во времени

Коротко: рынок ценит управляемую широту (T‑shaped + AI‑грамотность), прозрачные решения на интервью, видимые артефакты в профиле и дисциплину стратегии — тогда даже длинные воронки и ATS‑фильтры превращаются из лотереи в прогнозируемый процесс

⚡️ Architecture as Code: как AI помогает проектировать и документировать архитектуру

Документация — боль: либо бесполезна, либо устаревает ещё до релиза. Но что, если AI возьмёт рутину на себя и поможет принимать решения прямо в IDE?

На воркшопе:

1. Мы начнём с неструктурированного документа с требованиями, выделим ключевые моменты и построим utility tree, который поможет расставить приоритеты.

2. Затем рассмотрим альтерантивны, оформим trade-off таблицы для наглядного сравнения вариантов и проверим, насколько выбранные решения соответствуют исходным целям.

3. В финале сгенерируем основу для cloud-native приложения на базе выбранной архитектуры.

👤 Спикер: Максим Аршинов, Solution Architect @ EPAM Spain
📅 4 сентября, 20:00 GMT+3

🔗Регистрация и подробная программа на сайте

🚀 Круглый стол с CTO — 9 сентября

Переход из инженерной роли в CTO меняет не только задачи, но и весь подход к работе. Меньше кода — больше стратегии, лидерства, взаимодействия с бизнесом и решений, влияющих на всю компанию.

Вместе с опытными CTO и Engineering Manager'ами обсудим:

🔸 CTO — это вообще про что?
Роль CTO в разных компаниях и почему это не «самый умный инженер».

🔸 Первый шок: переход из инженера в лидера
С какими трудностями сталкиваются в первые месяцы и как меняется стиль мышления.

🔸 Команда, бизнес, стратегия
Как совмещать технологическую глубину с бизнес-фокусом и строить отношения с CEO и командой.

🔸 Как подготовиться заранее?
Что стоит прокачать до перехода и какие советы дали бы себе действующие CTO.

📅 9 сентября, 20:00 GMT+3

👉 Регистрируйтесь и ставляйте свои вопросы участникам круглого стола по ссылке

Build vs Buy vs OpenSource: как CTO принимает решения о технологическом стеке

🎯 Что именно решаем и какие ограничения

Сначала фиксируем бизнес‑результат и жёсткие рамки

Какие целевые эффекты: time‑to‑market, рост выручки/ARPU, выполнение SLO/SLA, требования безопасности и регуляторики, data residency

Масштаб: текущая/пиковая нагрузка (RPS, throughput), сезонность, прогноз роста

Зависимости: смежные сервисы и контракты, команды, данные и интеграции

Вывод: без чёткого «что и зачем» сравнение Build/Buy/OSS превращается во вкусовщину

🧩 Где дифференциация и что считать core

Определите источник преимущества: уникальные алгоритмы, собственные данные/опыт, UX, платформенные способности (расширяемость, observability, DevEx). Commodity — стандартные функции, где важнее предсказуемость и скорость

Правило: Build — когда это сердцевина конкурентного преимущества; Buy/OSS — когда функция типовая и ценится скорость, надёжность и предсказуемая эксплуатация

💰 TCO и Time‑to‑Value на горизонте 3–5 лет

🔹 Build: FTE на разработку/поддержку, инфраструктура, тестирование/безопасность, «хвост» сопровождения (релизы, апдейты, инциденты), opportunity cost команды

🔹 Buy: лицензии/подписки и сверхлимиты, интеграции/кастомизации, типы саппорта (SLA/Premium), зависимость от roadmap вендора

🔹 OSS: интеграции и адаптация, hardening/безопасность, операционка (SRE, бэкапы, апгрейды), платная поддержка, риск bus factor

Точка безубыточности: при каком объёме трафика/данных и сроке владения суммарные CAPEX+OPEX Build пересекают стоимость Buy/OSS

Добавьте метрики: рост RPS ×2, удвоение данных, +20% к ценам вендора, текучесть команды

Time‑to‑Value — время до первых ощутимых бизнес‑метрик (например, MRR/конверсия, сокращение TTM), фиксируем целевой порог и окно (n недель)

🗜 Риски и lock‑in, и как их смягчать

🔸 Технические: масштабируемость, производительность, «узкие места». Смягчение: перф‑бюджеты, нагрузочные бенчмарки, профилирование, кэш/очереди, горизонтальное масштабирование, chaos/FAIL‑инъекции

🔸 Операционные: доступность, DR/BCP, комплаенс. Смягчение: SLO+error budget, много‑AZ/region, RTO/RPO, runbooks и учения DR, контроль доступа/секретов, аудит логов/трейсов

🔸 Юридические/лицензии: для OSS — MIT/Apache/GPL (совместимость, copyleft), SBOM и проверка зависимостей; для Buy — условия выхода, экспорт данных, аудит, escrow. Смягчение: юр‑ревью, DPA, право на выгрузку в открытом формате, escrow‑ключи/исходники, регулярные аудиты

🔸 Lock‑in: переносимость данных/контрактов. Смягчение: портируемое ядро, adapter/anti‑corruption layer, минимизация vendor‑specific кода, миграционный plan‑B: «переключаемся за N недель», оценка стоимости миграции, shadow‑traffic перед cutover

🧪 Как принимаем решение: POC → оценка → rollout → пересмотр

POC с чёткими критериями: целевые SLO (P95/P99), стоимость на транзакцию/RPS, скорость разработки, требования безопасности

Бенчмарки: холод/тёплый старт, деградации под пиком, отказоустойчивость, тесты интеграции и совместимости схем

Оценочная матрица (веса и баллы): fit‑to‑outcome, экономика (TCO, TTM, TTV), риск (тех/операц/юрид), орг‑влияние (штат, найм, процессы). Выбираем лучший взвешенный скор

Внедрение этапами: tracer‑bullets → пилот на ограниченном сегменте → canary/feature‑flags → прогрессивный rollout, обучение on‑call. Обязателен kill‑switch и детальный rollback

Регулярный пересмотр через ADR/RFC: раз в квартал пересчитываем экономику и риски, проверяем SLA/SLO, окна для renegotiation с вендорами, актуализируем exit‑plan

👉 Приходите на митап [Как CTO может влиять на бизнес: стратегия, архитектура, команда]. Разберём 12 зон ответственности CTO и их приоритизацию для ускорения роста и эффективности команды

📆 11 сентября
⏰ 19:00 GMT+3

Регистрируйтесь и приходите с вопросами!

🌊 Batumi is on!

Мы рады объявить первый офлайн-ивент!
18 сентября встречаемся в Батуми в офисе компании Andersen на совместном митапе.

📌 В программе:
🎙 Доклад от Стаса Степанова: инсайты о том, на что CTO продуктовой компании тратит своё время
🤝 Много времени для неформального общения, знакомств и обмена опытом
🎤 Ведущий встречи — Никита Щетько.

Но главное — это отличный шанс наконец-то встретиться вживую, познакомиться и пообщаться с комьюнити! 🥳

📍 Ждём вас 18 сентября в офисе Andersen в Батуми.
⚠️ Количество мест офлайн ограничено — успейте зарегистрироваться по ссылке!
Для всех остальных будет доступна онлайн-трансляция.

🔎 Зачем проекту архитектор?

Solution Architect — роль важная, но всё ещё окутанная мифами. Когда он действительно нужен, чем отличается от инженера и как понять, что архитектура работает?

📅 15 сентября (понедельник), 20.00 GMT+3
Тема митапа: «Зачем проекту архитектор? Измеряем и оцениваем работу Solution Architect»

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

👉 Присоединяйтесь к митапу и задайте свой вопрос спикеру

Организационный дизайн: как структурировать команды разработки в зависимости от архитектуры проекта

🧩 Естественные границы в разных архитектурах

Границы команд берём из домена: бизнес‑потоки, bounded contexts, владение данными, требования к latency/availability, внешние интеграции.

Модульный монолит: контексты = модули одного деплоя; data gravity — общая БД (часто schema‑per‑module), дешёвые внутрипроцессные вызовы.

Микросервисы/event-driven: контексты = сервисы с отдельными хранилищами, явные SLA/SLO на интерфейсы, большая нагрузка на сеть.

Data/ML‑интенсивные: слои ingestion/processing/serving, владение датасетами и фичами, SLO на freshness/quality и latency inference.

Эти границы становятся границами команд (Conway/Inverse Conway).

Артефакты: карта доменов, контекстные диаграммы, реестр критических интеграций. 

🏗 Командная топология под текущую архитектуру

Подбираем mix из stream‑aligned / platform / enabling / complicated‑subsystem, удерживая когнитивную нагрузку, независимость релизов и нужные SLO.

🔸 Модульный монолит: 2–4 stream‑aligned команд по value streams; thin‑platform (CI/CD, шаблоны, observability). Enabling — точечно для практик (trunk‑based, контрактные тесты). Complicated‑subsystem — редко, как "ядро платежей" или "поиск" внутри монолита.

🔸 Микросервисы/шина событий: больше stream‑aligned команд с “you build it — you run it”; сильная плафторма (service mesh, API gateway, schema registry, secrets, runtime). Выделяем complicated‑subsystem (поиск, биллинг, ML‑рантайм). Enabling — для миграций и стандартов API/Events.

🔸 Data/ML‑интенсивные: data/ML‑платформа как X‑as‑a‑Service (feature store, model registry, batch/stream compute, lineage). Stream‑aligned команды владеют своими схемами/контрактами данных и инференсом.
 
Лимиты: ≤8 инженеров на команду, ≤3–5 сервисов/дата-продуктов в активном владении.

🔑 Владение API/данными/SLO

В монолите — владение модулями (код+схемы миграций), системные SLO и локальные error budgets по модулям. 

В микросервисах — владелец на каждый сервис/событие/схему, отдельные SLO/SLA, on‑call у продуктовой команды, RACI для кросс‑доменных изменений.

В data/ML — владельцы датапродуктов с контрактами (freshness, completeness, accuracy), политики версионирования моделей и rollback/shadowing. 

Контракты: версионирование, deprecate policy, контрактные тесты, единый schema registry.

Артефакты: каталог сервисов/владельцев, SLO‑карты, ADR/RFC шаблоны, политики версионирования.

🤝 Интерфейсы и режимы взаимодействия

Режимы Team Topologies: 

🔹 collaboration — для delivery сквозных фич; 
🔹 X‑as‑a‑Service — платформа и общие capability; 
🔹 facilitating — enabling‑команды ускоряют освоение технологий. 

Транспорт:

🔸 В монолите — публичные интерфейсы модулей и внутренние события; 
🔸 В распределённой системе — REST/gRPC и Events с чёткими схемами и backward‑compatible эволюцией. 

Артефакты: стандартный CI/CD (one‑click deploy, progressive delivery), шаблон сервиса, секреты и policy‑as‑code, централизованная телеметрия (logs/traces/metrics), API style guide, правила совместимости событий, чек‑лист интеграционных тестов.

📏 Метрики эффективности и когда делать reverse Conway

Смотрим на DORA (lead time, deployment frequency, MTTR, CFR), долю кросс‑командных зависимостей, время согласований, количество "чужих" инцидентов, опрос когнитивной нагрузки, долю использования golden path. 

Триггеры перестройки: новые домены/регуляторика, хронические блокировки между командами, рост времени поставки, деградация SLO. 

Процесс эволюции: гипотеза → пилот на 1–2 потоках → пересборка владения и on‑call → обновление контрактов и онбординг. 

Артефакты: дэшборд потоков изменений, регламент reverse‑Conway maneuver, план миграции владения.

👉 Митап [Рост и развитие архитектора] — обсудим карьерный путь, реальные вызовы, работу с AI, LLM и no‑code/low‑code. 

📆17 сентября
⏰19:00 GMT+3

Регистрируйтесь и приходите с вопросами!

А кто-то может объяснить, как так Perl попал на 10е место в TIOBE index? Он же лет 13-15 не всплывал. Старые проекты потребовали поддержку? Олдскулы трясут стариной?

🧑‍💻Всем продуктивного начала рабочей недели!

На прошлой неделе у нас прошел митап [Как CTO может влиять на бизнес: стратегия, архитектура, команда]. Если вы пропустили, посмотреть можно на нашем YouTube-канале.

👉 Сегодня вечером мы встречаемся на 30-м Software Craftsmanship митапе [Зачем проекту архитектор? Измеряем и оцениваем работу Solution Architect]. Ведущий – Антон Дворников, Head of Architecture. Регистрируйтесь и задавайте свои вопросы!

👉 А в среду пройдет митап [Рост и развитие архитектора]. Обсудим карьерный путь, реальные вызовы, работу с AI, LLM, no-code & low-code инструментами. Ведущие – Антон Дворников, Head of Architecture, и Павел Вейник, Solution Architect, Staff Engineer. Присоединяйтесь по ссылке!

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

💥 GitLab – когда человеческий фактор стал ахиллесовой пятой

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

За ночь команда восстановила данные по крупицам – удалось вернуть почти всё, потеряв ~6 часов транзакций. Инцидент прозвали «IT-мелтдауном»: разработчики GitLab публично транслировали ход спасательной операции, а СМИ недоумевали, как такое вообще возможно. Компания выжила и сделала выводы

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

💣 Atlassian — 775 клиентов офлайн на 2 недели

Из-за сбоя в коммуникации команда Atlassian передала скрипту удаления не те идентификаторы. Вместо ID старого плагина для Jira был указан ID всего облачного сайта. Скрипт не проверял тип ID, а сразу удалял что передано и в результате мгновенно стер сайты 775 компаний

Около 0,5% всех клиентов Atlassian лишились доступа к Jira и Confluence; некоторым пришлось ждать восстановления до 14 дней. Полной потери данных удалось избежать, но доверие пользователей было подорвано

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

Урок: Даже рутинные скрипты требуют предельной осторожности. Стоит внедрить “мягкое удаление” и дополнительные проверки, чтобы случайно не уничтожить данные. Важно наладить коммуникацию между командами и регулярно тренироваться в аварийном восстановлении систем

🌐 Facebook — 6 часов глобального офлайна

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

Все приложения компании (включая Instagram и WhatsApp) легли примерно на 6 часов

К тому же внутренние инструменты и системы администрирования перестали работать, поэтому инженерам пришлось ехать в дата-центры лично – удалённо подключиться было невозможно

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

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

🕸 MySpace – социальный гигант, запутавшийся в собственной паутине кода

В середине 2000-х MySpace доминировал среди соцсетей, но его техническая основа – прототип на PHP разросся в неуправляемого «франкенштейна» из скриптов и костылей. Архитектура изначально не была рассчитана на масштабирование

Новые функции прилеплялись без оптимизации, а сайт заметно тормозил и часто ломался. Например, за пару лет MySpace внедрил все подряд: игры и видеосервис MySpace TV, разделы объявлений и мероприятий, музыкальные плееры и кастомизацию профилей

Страницы пользователей, перегруженные блестящими виджетами и автопроигрыванием музыки, еле открывались (если вообще открывались). А тем временем набирал силу «скучный» Facebook – чистый, быстрый и просто работающий

Пользователи перебрались туда, где ничего не падало, оставив MySpace умирать под собственным legacy. Руководство MySpace же сыпало маркетинговыми фичами вместо того, чтобы лечить ядро – и упустило трон

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