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

При росте из 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 же сыпало маркетинговыми фичами вместо того, чтобы лечить ядро – и упустило трон

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

🚀 Приглашаем на митап Взаимодействие и конфликт между СТО и СРО/СЕО

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

📅 25 сентября, 19:00 GMT+3

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

🎙 Нагрузка ≠ трафик: что на самом деле убивает системы

📅 7 октября, 20.00 по GMT+3

📌 Программа доклада:
• Неочевидные bottleneck’и: метаданные, блокировки, сетевые очереди
• Сценарии «снежного кома» (cascading failures)
• Почему observability (tracing, logs, metrics) важнее, чем «магия оптимизаций»

👨‍💻 Спикер: Андрей Якушин, Solution Architect и Engineering Manager с 18+ годами опыта в IT.

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

Краткий гайд по observability

Потому что одного мониторинга уже недостаточно. Современные системы сложны, и бизнес требует надёжности.

🎯 Что наблюдать и зачем?

Наблюдаем мы прежде всего то, что влияет на пользователей и цели бизнеса. Для этого вводятся SLI/SLO – измеримые показатели качества сервиса, привязанные к бизнес-требованиям. Например, если сервис обещает 99.9% аптайма, то SLO = 99.9%, а error budget = оставшиеся 0.1% допуска на сбои.

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

📡 Сигналы и телеметрия: что и как собираем?

Observability стоит на трех столпах: метрики, логи и трейсы.

🔹Метрики – числовые показатели нагрузки и производительности
🔹Логи – подробные записи событий
🔹Трейсы – путь запросов через распределённую систему.

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

Архитектура телеметрии обычно включает агентов на компонентах, которые отправляют метрики, логи и трассировки в централизованное хранилище.

Важно применять открытые стандарты – например, OpenTelemetry – чтобы унифицировать форматы данных и избежать привязки к одному вендору.

🚨 Алёрты и дашборды, которые помогают on-call

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

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

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

🔍 От сигнала – к причине и действию

Типичный процесс инцидент-менеджмента:

🔸 Оценка симптомов. Определите, какой SLI вышел из нормы (например, резко выросли ошибки 5xx или упала скорость ответов).
🔸 Локализация причины. Просмотрите трейсы и логи, чтобы найти проблемный компонент, и проверьте, не совпал ли сбой с деплоем или скачком нагрузки – такие факторы сузят поиск.
🔸 Ремедиация. Предпримите меры для восстановления: откатить неудачный релиз, переключить трафик на резервные мощности или добавить ресурсы.
🔸 Постмортем. Разберите инцидент: по данным мониторинга подтвердите причину и решите, что изменить, чтобы проблема не повторилась.

📈 Зрелость observability и окупаемость

Главный KPI наблюдаемости – снижение MTTR (времени восстановления). Меньше простоя = меньше убытков и выше доверие пользователей.

Лидеры observability показывают отличные результаты: 89% уверены в надёжности своих сервисов (у новичков 43%), а 86% говорят, что возврат инвестиций превзошёл ожидания – соответственно, чем выше наблюдаемость, тем ниже риск сбоев и тем быстрее развитие новых функций.

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

Друзья! Уже на следующей неделе мы стартуем 4-ый поток курса [Solution Architect in the Wild].

👉 Запишитесь на бесплатную консультацию перед курсом!

Кому курс будет полезен:

🔹 Опытные senior-разработчики
🔹 Техлиды
🔹 Архитекторы и staff engineers
🔹 Выпускники курса [Технический Лидер]

Что будет на курсе:

- Разберем теорию Solution Architecture. В соответствии с TOGAF, как нужно выстраивать архитектуру и архитектурный процесс в организации.
- Рассмотрим коммуникации Solution Architect. Обсудим виды культур в организациях, стадии ЖЦ организации, а также оптимальный способ поведения Solution Architect в зависимости от контекста организации
- Поделимся реальными кейсам и историями. Поймем, что не все архитектурные задачи возможно решить, обсудим истории успехов и провалов в компания различного типа, а также разберем риски в работе Solution Architect.
- Выполним задания по кейсам, которые созданы по реальным ситуациям в проектах.

Преподаватели:

Антон Дворников – Head of Architecture
Павел Вейник – Solution Architect, Staff Engineer

Подробнее о курсе и том, как расти, если ты уже архитектор – запись митапа [Рост и развитие архитектора]

Как писать документацию, которую реально читают?

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

📦 Форматы и где их хранить

Доки должны жить рядом с изменениями и иметь один канонический адрес

🔹 ADR – фиксация значимых решений. Хранить в репозитории сервиса (/docs/adr/2025‑10‑03‑slug.md). Структура: Контекст → Опции → Решение → Последствия. Ссылку на ADR ставьте в PR и код
🔹 RFC – изменения с кросс‑командным влиянием. Хранить в /rfcs монорепо или отдельном архитектурном репо. Жизненный цикл: Draft → Review → Accepted/Rejected → Implemented (с метками владельца и даты)
🔹 Runbooks – операции и дежурства: симптомы, метрики, команды, rollback, SLO, эскалации. Хранить рядом с сервисом (/docs/runbook.md) и дублировать в системе он‑колла
🔹 Decision log – поток мелких решений между ADR: одна страница на продукт, записи с датой, ссылками на PR/ADR
🔹 Навигация – индекс и поиск: /docs/index.md, оглавление по доменам, стабильные пермалинки. Нет ссылки – нет документа

🛠 Док‑конвейер: сделать правильно по умолчанию

Чтобы документация не покрывалась пылью, используйте подход docs‑as‑code: авторы пишут тексты в plain text/Markdown, хранят их в git, а изменения проходят ревью вместе с кодом. Без аппрува владельца документа раздел никто не меняет

Подготовьте шаблоны для ADR, RFC и runbook, чтобы команда не тратила время на структуру. Интегрируйте обновление документации в pull‑request: в чек‑листе ревью должно быть "обновлены docs"

Линтинг документов в CI/CD – обязательная часть конвейера. Так же, как линтеры следят за кодом, docs‑linting проверяет синтаксис, стиль и ссылки. Инструменты вроде Vale, Write Good или TextLint работают в GitHub Actions и прерывают сборку, если в тексте есть ошибки

Автопубликация: Docusaurus, MkDocs или Backstage автоматически собирают документацию из репозитория и публикуют на внутренний портал. CI-пайплайн проверяет, что ADR соответствует шаблону, а ссылки не битые

✂️ Пишем коротко и по делу

Начинайте с TL;DR на 5–8 строк: проблема, контекст, решение, последствия, ссылка на PR

Пишите для читателя "через 6 месяцев": уберите локальный жаргон, добавьте дату и владельца

Где можно – схемы вместо прозы: C4 (контейнеры/контексты) и 1–2 последовательности

Процесс – чек‑листом: нумерованные шаги, команды в код‑блоках, критерии успеха

Примеры важнее описаний: пример запроса/контракта, негативный пример, edge‑кейсы. Один файл – одна цель

✅ Документация как часть Definition of Done

🔸 Добавьте в DoD: "обновлены ADR/RFC/Runbook/диаграммы, есть TL;DR, ссылки в PR"
🔸 Гейты в CI: если менялись публичные API, SLO или флоу – требовать связанный ADR/RFC
🔸 В PR‑шаблоне проставьте чекбоксы "Docs updated" и "Owner assigned"
🔸 Демо – только с ссылкой на доки; без нее фича не считается завершенной

🔥 Как побудить команду писать и читать

Сделайте чтение частью ритуалов: архитектурные ревью начинаются с TL;DR, инцидент завершается апдейтом runbook и ссылкой в постмортеме

Введите роль "док‑садовника" по ротации: раз в спринт человек чинит битые ссылки, объединяет дубли

Превратите вклад в документы в метрику признания: учитывайте ADR/RFC в performance review и на демо отмечайте "best doc of the week"

Упростите обнаружение: единый портал с поиском по тегам (домен, сервис, SLA), быстрые "стартовые" страницы для новых людей

Добавьте аналитику: уникальные читатели, время до первого апдейта после инцидента, список "устарело >90 дней" – это топ‑лист для следующего спринта