Каким был 2025 год для Hard&Soft Skills?

Самое время оглянуться назад и подвести итоги насыщенного года:

🎓 Образовательный трек в цифрах

120 инженеров успешно прошли обучение на наших программах. Мы провели 5 курсов:

🔸 2 больших потока курса [Технический лидер]. Кстати, в феврале стартует уже юбилейный 20-й поток, записывайтесь на консультацию!
🔸 2 курса Solution Architect in the Wild.
🔸 1 поток программы из Middle в Senior.

Но самое ценное — это не сухая статистика, а качественный рост наших выпускников.

Вот как они описывают результаты:

Я выбирал между сертификацией TOGAF, институтом SAE и курсом "Технический лидер". Взвесив всё, я понял, что по фундаментальности и прикладной пользе для реальной архитектурной работы курс "Технический лидер" подходит идеально.

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

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

За эти инсайты и рост благодарим наших преподавателей — Антона Дворникова, Светлану Семенову, и, конечно, Павла Вейника!

🌍 Сообщество

В 2025 году мы провели 52 ивента!

🗣 Организовали 9 Архитектурных трепов и 27 Конклавов.
⚙️ Провели 5 Круглых столов и 3 Software craftsmanship митапа.
🏠 Впервые полноценно встретились оффлайн — и сразу дважды: в Батуми и в Алматы! Благодарим наших партнеров и, конечно, всех, кто пришел – без вас не было бы так круто!

Огромное спасибо ведущим, модераторам и участникам круглых столов:

Юрий Морозов, Павел Вейник, Антон Дворников, Алексей Лобан, Вадим Гацура, Александр Орлов, Илья Кремнёв, Евгений Кошелев, Виктория Телюк, Денис Филипкин, Максим Симоненко, Александр Кохно, Никита Щетько, Владимир Хростицкий, Peter Hanzo, Данида Поддубный, Анастасия Бакулова, Игорь Круглов, Ильшат Назаргулов, Ринат Тлеукулов, Марина Хомич, Артём Головачёв, Александр Маркевич, Никита Старостин, Ирина Асон, Максим Аршинов, Евгений Соколов, Андрей Якушин, Alex Pshul, Максим Сальников, Елизавета Булыгина.

2025 получился насыщенным и ярким. Спасибо за то, что помогли нам сделать его таким! Обещаем в следующем году не сбавлять темп. С наступающими праздниками!

Почему вы застряли на уровне Senior и как пробить стеклянный потолок?

🧠 Кто такой Senior на самом деле

Senior – это не “разработчик с 5 годами опыта”, а автономная боевая единица. Это инженер, который конвертирует бизнес-задачи в работающие решения с предсказуемым качеством и сроками.

Для бизнеса Senior – это точка безубыточности. Его не нужно микроменеджить, он сам видит риски и закрывает их.

📉 Смена парадигмы: почему старые методы не работают

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

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

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

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

🚧 Чего не хватает для перехода в Staff/Principal/Lead

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

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

🔹 Фундамент: детали устройства сети, архитектуры компьютера и памяти – это принципы, которые не меняются со сменой версий языка.

🔹 Распределенные системы: знание теоремы CAP, паттернов проектирования, работы с нагрузкой и консистентностью данных.

🔹 Умение находить trade-offs: архитектор не ищет идеальное решение, он выбирает наименее плохое, балансируя между latency, throughput и надежностью.

🔹 Стратегический взгляд: сеньор видит модуль, лид видит взаимодействие сервисов, архитектор видит, как это ложится на бизнес-стратегию компании на 3 года вперед.

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

🛋 Зачем расти дальше, если и так комфортно?

Рост выше Senior необходим, если:

🔸 Вы уперлись в финансовый потолок рынка для Individual Contributor.

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

🔸 Вы хотите масштабировать свою экспертизу: ваш код работает в одном месте, а ваши архитектурные решения работают во всей компании.

🗺 Где взять карту для дальнейшего пути

Навыки уровня Tech Lead или Architect редко приобретаются в повседневной текучке. Они требуют смены мышления и общения с теми, кто этот путь уже прошел.

🗓 Митап «Технический Лидер»

Когда: 20 января в 19:00 (GMT+3)

Разберем реальные кейсы перехода на уровень выше senior, обсудим диаграмму навыков техлида и тренды рынка в 2026 году.

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

📊 Выбираем архитектуру данных
Митап для тех, кто работает с данными, строит продуктовые системы и хочет мыслить на уровне архитектуры.

📆 13 января, 20.00 GMT+3

О чём поговорим:

1️⃣ Что такое архитектура данных?
Чем она отличается от привычной архитектуры ПО и почему без неё сегодня не живёт ни один серьёзный продукт.

2️⃣ Типичные задачи и требования.
С какими проблемами мы сталкиваемся, когда речь идёт о данных, масштабировании, скорости, надёжности и интеграциях?

3️⃣ Как выбрать архитектурный подход.
Разберём ключевые модели и паттерны, их плюсы и ограничения, что работает в каких сценариях и почему.

🎤 Спикер: Илья Гордеенко, Lead Data & Software Architect, более 10 лет опыта.

Регистрация

Закон Конвея: Почему структура вашей команды диктует архитектуру кода

📜 Закон Конвея: база

Любая организация, проектирующая систему, неизбежно создаст дизайн, который копирует коммуникационную структуру этой организации.

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

🧬 Механизмы трансляции: социальная физика кода

Оргструктура влияет на код через транзакционные издержки. Если команды неделю согласовывают контракт API, разработчики инстинктивно выбирают архитектурные паттерны, минимизирующие это общение (например, дублирование логики или создание толстых кэширующих слоев).

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

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

⚖️ Трейд-оффы: ускорение vs изоляция

Зеркальность архитектуры и структуры полезна, когда цель – High Velocity внутри вертикальных доменов. Кросс-функциональная команда, владеющая всем стеком (от UI до БД) в рамках одного бизнес-контекста, движется максимально быстро, так как издержки коммуникации минимальны.

Однако это становится барьером при масштабировании. Если архитектура строго поделена по отделам, реализация сквозной фичи превращается в ад согласований. В таких случаях нужно сознательно "размывать" границы (Shared Kernel, InnerSource), жертвуя изоляцией ради связности продукта.

🔄 Обратный маневр Конвея

Не пытайтесь натянуть чистую архитектуру на старую бюрократию. Сначала спроектируйте команды:

🔹 Stream-aligned teams: Формируйте команды вокруг потока ценности (User Journey), а не вокруг слоев (Frontend/Backend/DB). Так сервисы будут ориентированы на бизнес-домены.

🔹 Platform teams: Выделите инфраструктурную сложность в платформу (X-as-a-Service). Это создаст четкий API-раздел и снизит когнитивную нагрузку на продуктовые команды.

🔹 Interaction Modes: Фиксируйте типы взаимодействия (Team Topologies). Если одна команда зависит от другой, это должен быть либо сервис (API-контракт), либо коллаборация (совместный код), но не "просьбы в личку".

📊 Сигналы и метрики дисбаланса

Как понять, что структура команды ломает архитектуру (или наоборот)? Смотрите в git и трекер:

🔸 Logical Coupling vs Org Distance: Файлы часто меняются вместе в одном коммите, но принадлежат разным командам? У вас архитектурный разрыв.

🔸 Cross-team PR ratio: Если пулл-реквесты часто требуют аппрува внешних команд – значит границы абстракций протекают.

🔸 Change Failure Rate на стыках: Инциденты часто возникают на границах API? Значит, коммуникация о контрактах слабее, чем техническая связность сервисов.

🔸 Conway's Law Mismatch: Сравните граф вызовов сервисов с графом общения в Slack/Jira. Если сервис А вызывает сервис Б, но команды не общаются – ждите проблем с обратной совместимостью.

🛠 Тактики безопасной миграции

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

🔹 Анти-коррупционные слои (ACL): Если вы не можете изменить легаси-команду, изолируйте их систему адаптером, который транслирует их модель данных в вашу "чистую" модель. Это позволяет вашей архитектуре эволюционировать независимо от их оргструктуры.

🔹 Strangler Fig Pattern: Создайте новую команду под новый домен. Позвольте им перехватывать трафик по кусочкам, постепенно "удушая" старую функциональность. Здесь архитектурная миграция следует за перераспределением ответственности людей.

🔹 Временные Task Forces: Для реализации сложных сквозных изменений (например, смена ID провайдера) создавайте временные команды с полномочиями коммитить в любые репозитории.

После завершения работы команда распускается, а владение кодом возвращается в стримы. Риск здесь – потеря знаний, поэтому документация (ADR) критична.

💳 Inside a Payment Gateway или почему платёжный мир всё ещё держится на монолитах

Сегодня вечером разбираем платёжные системы изнутри:

– Payments 101: что такое платёжный домен и из чего он состоит
– Как требования enterprise-мерчантов формируют архитектуру gateway
– Почему решения, принятые десятилетия назад, продолжают работать
– Как бюджет, партнёрства и инфраструктура влияют на архитектурные подходы
– И главное: почему старые монолиты всё ещё выигрывают

🎙 Спикер: Илья Чекун, backend-инженер из Швейцарии, эксперт по платёжным системам и альтернативным методам оплаты.

🗓 15 января 20:00 GMT+3

Регистрация

System Design vs Architecture: В чем разница и почему их путают?

🧶 Что есть что и где граница

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

System design – это то, как именно система все это делает: какие конкретно используются БД, кэши и библиотеки, какие паттерны проектирования применяются, чтобы удовлетворить нефункциональные требования.

То есть, system design – составляющая часть архитектуры.

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

🎭 Кто за что отвечает: Архитектор vs Техлид vs Senior

В идеальном мире разграничение выглядит так:

Архитектор владеет нефункциональными требованиями (NFR) верхнего уровня: Availability, Modifiability, Security. Он принимает решение пожертвовать strong consistency ради доступности в распределенной системе.

Техлид транслирует архитектуру в код. Он решает, как именно реализовать eventual consistency (Saga или 2PC), и балансирует технический долг со сроками.

Senior-разработчик отвечает за локальный дизайн модуля. Он выбирает стратегию блокировок в базе или алгоритм сжатия данных.

В реальности, особенно в небольших командах, все эти роли могут лечь на одного сеньора.

Конфликт возникает, когда локальная оптимизация (Senior хочет сэкономить байты через Protobuf) ломает глобальный принцип (Архитектор требует JSON для читаемости и debuggability). Здесь помогает матрица RACI, где четко прописано, кто Accountable за межсервисные контракты.

⚖️ Метрики успеха

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

🔸 Метрики архитектуры:

Evolutionary Cost: Сколько человеко-часов стоит добавление новой сущности?

DORA Metrics: Показывают эффективность процессов, заданных архитектурой:

1. Deployment Frequency – как часто катим
2. Lead Time for Changes – время от коммита до прода
3. Change Failure Rate – процент релизов, требующих фикса
4. Time to Restore Service – время восстановления после сбоя

Total Cost of Ownership: Стоимость инфраструктуры + лицензии + стоимость поддержки. Если архитектура требует x3 ресурсов облака для простых задач – это архитектурный провал.

🔸 Метрики дизайна:

Operational: Throughput, P99 Latency, Error Rate.

Code Quality: Тестовое покрытие, цикломатическая сложность, время сборки.

Fan-in / Fan-out
1. Fan-in: сколько модулей зависят от текущего
2. Fan-out: от скольких модулей зависит текущий

Архитектура считается успешной, если при росте нагрузки (метрика дизайна) стоимость изменений (метрика архитектуры) растет нелинейно медленно.

🔍 Ошибка восприятия: Дизайн или Архитектура?

Часто плохой архитектурой называют просто отсутствие контрактов или документации.

Если вам приходится править 5 микросервисов, чтобы добавить одно поле на фронтенде – это ошибка архитектуры.

Если же сервис упал из-за out of memory при обработке большого файла – это ошибка дизайна (неправильная работа с потоками), даже если она привела к отказу всей системы.

🛡 Практики эволюции

Чтобы не переписывать систему каждые два года, нужно внедрять инструменты, фиксирующие договоренности на уровне кода и процессов.

🔹 ADR: Не просто "мы выбрали Kafka", а почему, какие были альтернативы и с чем придется жить. Это снимает вопросы "кто это придумал?" через год.

🔹 Consumer-Driven Contracts: Тесты, которые гарантируют, что изменения в дизайне продюсера не сломают архитектурный контракт с консьюмером.

🔹 Fitness Functions в CI/CD: Автоматические проверки архитектурных правил. "Слой контроллеров не должен ходить в базу напрямую". Если правило нарушено – пайплайн падает.

🔹 Версионирование API и Tolerant Reader: Принципы дизайна, которые спасают архитектуру от жесткой связности при эволюции схем данных.

Quality Attributes и как их измерять

🎯 Бизнес-импакт и карта рисков

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

Если падает Scalability, мы теряем не RPS, а долю рынка во время пиковых распродаж.

Если падает Maintainability, растет Time-to-Market, и конкуренты нас обгоняют.

Для эффективного измерения разделите метрики на два класса:

Lagging (Запаздывающие): SLA, MTTR, стоимость инцидента. Они говорят, что уже сломалось и сколько денег потеряно.

Leading (Опережающие): Cyclomatic Complexity, Code Churn, время сборки, покрытие тестами. Они предсказывают, где рванет через месяц. Рост сложности кода сегодня — это гарантированный рост MTTR завтра.

🧩 Композитные метрики

Одиночная метрика (например, Average Latency) лжет. Она сглаживает пики и скрывает "длинный хвост", где страдают пользователи. Чтобы видеть реальную картину, стройте композитные индексы здоровья системы, объединяя сигналы разной природы.

Например, для атрибута Reliability (Надежность) недостаточно просто считать 200 OK.

Композит должен включать:

🔸 Success Rate: Процент успешных бизнес-транзакций (а не просто HTTP-запросов).
🔸 Latency Distribution: 99-й перцентиль задержки (p99) — именно здесь живут ваши самые требовательные пользователи.
🔸 Freshness: Возраст данных, отдаваемых пользователю (актуально для read-heavy систем с кэшированием).
🔸 Durability: Гарантия того, что принятые данные записаны на диск и реплицированы (lag репликации).

Нормализуйте эти показатели по текущей нагрузке и окнам релизов. Резкий скачок ошибок сразу после деплоя и плавный рост ошибок при неизменном коде — это сигналы для разных команд (Dev vs Ops).

📉 Шум vs. Реальная деградация

Алерт на каждый спайк CPU — верный путь к выгоранию on-call инженера. Ваша задача — отделить случайный шум от системного деградационного тренда.

Используйте SLO Burn Rate вместо мгновенных значений. Это скорость, с которой расходуется ваш "бюджет на ошибки". Если за час мы сожгли 2% месячного бюджета ошибок — это инцидент. Если 0.01% — это шум.

Для детекции трендов применяйте статистические методы:

Change Point Detection: Алгоритмы (например, CUSUM), которые находят момент смещения среднего значения или дисперсии. Это позволяет увидеть деградацию производительности после релиза на 5%, которую глаз на графике не заметит.

A/B и Canary: Валидируйте гипотезы через сравнение когорт. Если на новой версии latency p99 выше на 10ms с p-value < 0.05 — это не флуктуация, а повод для отката.

🔭 Доверие к данным

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

Чтобы данные были action-oriented:

🔹 Семантика ошибок: Разделяйте ошибки инфраструктуры (502/504) и ошибки бизнес-логики (4xx или “недостаточно средств”). Это разные атрибуты качества (Availability vs Usability).
🔹 High-Cardinality Tags: Обогащайте метрики tenant_id, версией клиента, feature-флагом. Это позволяет мгновенно локализовать проблему (тормозит только у iOS-клиентов в Европе).
🔹 Умный семплинг: Вместо random sampling используйте tail-based sampling. Сохраняйте 1% успешных трейсов и 100% ошибочных или медленных. Это даст полную картину сбоев без перегрузки хранилища.

⚙️ От дашбордов к инженерным решениям

Измерение — не самоцель. Цикл должен замыкаться на действии. Переводите метрики QA в язык ROI для бизнеса.

Не просите время на рефакторинг. Покажите тренд:

За последние полгода Cyclomatic Complexity модуля Core выросла на 40%, что коррелирует с ростом MTTR с 2 до 8 часов. Мы теряем $X на каждом простое. Рефакторинг вернет MTTR к норме и окупится за 3 месяца.

Внедряйте Fitness Functions в CI/CD пайплайны. Если PR ухудшает метрику startup time на 50ms или снижает покрытие документацией, сборка должна падать.

Так атрибуты качества превращаются из абстрактного пожелания в жесткий инженерный контракт.

Архитектурный Трёп №132 уже завтра!

📅27 января, 20.00 GMT+3

Как менять технологическое направление, когда карьера уже сложилась

Поговорим честно про:
• что становится триггером для смены направления
• страх потери статуса, влияния и ощущения компетентности
• реальные стратегии перехода: pet-projects, внутренние трансферы, менторство, contribution, курсы
• и правда ли, что технологии вторичны, а инженерное мышление - главный transferable skill

🎙 Модератор: Анастасия Бакулова

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

Я допиливаю программы курсов по AI, и у меня есть вопрос что вам больше интересно:
1. «Я все пропустил, что там происходит?»: от промптинга/рулов/скилов до последних трендов, системный взгляд на область AI. Разумеется, агенты, использование AI для кода и для процессов/документации, основы MCP, RAG и прочих аббревиатур, и конечно - когда и что использовать из существующих подходов/моделей/сред разработки. На выходе - человек, который спокойно ориентируется в текущем состоянии отрасли и в трендах, и который может заниматься «обычной» прикладной автоматизацией или другими проектами теперь и с помощью AI.
2. «Я разрабатываю агенты, делаю свои MCP, использую RAG»: архитектура агентов (оркестрация, долгосрочная память, chain of thought и др способы планирования действий), knowledge graphs, agentic RAG. MCP в глубину - управление состоянием внутри сервера MCP, security/auth, транспорты для удаленных агентов. Как не только разработать, но и поддерживать/документировать/управлять - LLMOps, observability, автоматическая оптимизация промптов. при интересе - и как/какие/для чего модели ставить on premise или в собственном облаке.
3. «Я - первый вайбкодер-единорог!»: все для быстрой разработки и валидации гипотез, для запуска своих проектов с помощью AI и существующих инструментов. TTM - наше все! скоростное написание кода, full-stack генерация приложений, инфраструктура из коробки, low code и no code инструменты, growith hacking и маркетинг, быстрое прототипирование мобильных приложений. Про инвестиции не будет ничего, но если что найдем способ помочь.
4. «Я участвую в разработке и улучшаю LLM»: почему перемножение матриц внутри LLM вдруг стало думать как люди(или лучше людей)? Архитектура LLM внтутри - токены, вектора слов, матрицы, механизм внимания, feed forward networks. Пространства смыслов и операции с ними, фантазия (probabilistic determinism vs галлюцинации) в LLM. Где именно модель думает, а где вспоминает факты (induction heads, sparse autoencoders, ablation). Тут вы узнаете почему модель не может считать (пальцы, буквы) и где возникает смысл. Для домашних заданий потребуется много оперативки.
5. «Не угадал, я напишу в чате что мне больше интересно.»
(Павел Вейник)

CAP и PACELC: Базовые законы, которые нельзя нарушить (даже если очень хочется)

🛡 CAP: Иллюзия выбора двух из трех

Многие трактуют теорему Брюера как меню в ресторане: "Выберите любые два пункта". Но для распределенной системы Partition Tolerance (P) – это не опция, а данность. Сети ненадежны: свитчи горят, GC-паузы останавливают ноды, пакеты теряются.

Когда происходит сетевое разделение (partition), вы теряете связь между узлами. В этот момент (и только в этот!) вы обязаны сделать жесткий выбор:

Отказаться от Availability (вернуть ошибку или тайм-аут), чтобы сохранить данные согласованными (CP).

Пожертвовать Consistency (отдать устаревшие данные), чтобы система продолжила отвечать (AP).

Попытка построить "CA-систему" в распределенной среде – это игнорирование физики сетей. Если вы утверждаете, что у вас CA, вы просто еще не столкнулись с разделением сети, которое сломает вашу линеаризуемость.

⚖️ PACELC: О чем молчит CAP в мирное время

CAP описывает поведение системы только во время сбоя в сети. Но системы работают в штатном режиме 99.9% времени. Здесь на сцену выходит расширение теоремы – PACELC.

Она формулируется так:

If P (Partition), then choose A (Availability) or C (Consistency).

Else (no Partition), choose L (Latency) or C (Consistency).

Это фундаментальный трейд-офф, который часто упускают: даже когда сеть работает идеально, вы не можете получить мгновенный отклик (low latency) и строгую согласованность одновременно. Репликация данных требует времени.

Хотите, чтобы все узлы всегда видели одни и те же данные? Платите за round-trip синхронизации (увеличиваем latency).

Хотите отвечать мгновенно? Читайте с локальной реплики, но рискуйте получить stale data (жертвуем consistency).

🎛 Градиент, а не переключатель: Tunable Consistency

Для Senior-инженера выбор базы данных – это не просто "Postgres vs Cassandra", а понимание моделей согласованности. Современные БД позволяют гибко настраивать этот баланс через кворумы (Quorums).

Формула $R + W > N$ (где N – фактора репликации, R – узлов для чтения, W – узлов для записи) – база, но дьявол в деталях:

🔹 Strong Consistency (CP / PC в терминах PACELC):
Требует $W = N$ или большинства (Quorum). Это алгоритмы консенсуса (Paxos, Raft). Примеры: CockroachDB, Etcd, Zookeeper.

Цена: Высокая latency на запись, невозможность записи при падении миноритариев.

🔹 Eventual Consistency (AP / EL):
Допускаем $R + W ≤ N$. Система "в конечном счете" станет согласованной. Примеры: Cassandra, DynamoDB (с дефолтными настройками), Riak.

Цена: Конфликты версий (Vector Clocks, LWW), риск потери данных при одновременной записи, сложность отладки.

🔹 Causal Consistency:

Золотая середина, которую часто упускают. Гарантирует, что операции, связанные причинно-следственной связью, видны в правильном порядке. Это слабее, чем линеаризуемость, но сильнее, чем eventual consistency, и не так сильно бьет по latency.

🧠 Consistency в CAP ≠ Consistency в ACID

Критически важное различие для техлида.

ACID Consistency: Переход базы данных из одного валидного состояния в другое с учетом бизнес-правил (инвариантов, constraints).

CAP Consistency: Это Linearizability (линеаризуемость). Если операция записи завершилась, любая последующая операция чтения (на любой ноде) должна вернуть новое значение. Это свойство системы, а не данных.

Ошибочное смешивание этих понятий ведет к архитектурным просчетам, когда от NoSQL базы ожидают соблюдения foreign keys только потому, что выбрали "CP-mode".

📚 Что почитать по теме

Daniel J. Abadi – "Consistency Tradeoffs in Modern Distributed Database System Design" (оригинальная статья по PACELC).

Martin Kleppmann – "Designing Data-Intensive Applications" (Главы 7, 8, 9 – обязательное чтение для любого сеньора).
Можно посмотреть обсуждение у нас на YouTube

Monitoring и Observability: В чем принципиальная разница?

Многие считают Observability просто маркетинговым ребрендингом мониторинга, но различие лежит в плоскости теории управления и работы с данными.

🧠 Control Theory и математическая суть

В инженерном контексте термины имеют четкое разделение, уходящее корнями в теорию управления (Control Theory) 1960-х годов.

🔹 Monitoring — это действие. Процесс сбора, агрегации и отображения предопределенных метрик. Это взгляд на систему "снаружи", позволяющий понять, находится ли она в здоровом состоянии относительно заранее известных пороговых значений.

🔹 Observability — это свойство системы. Мера того, насколько хорошо можно понять внутреннее состояние системы (internal state), основываясь только на знании её внешних выходных данных (external outputs/telemetry).

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

🔮 Known Knowns vs Unknown Unknowns

Главный водораздел проходит по типу вопросов, которые вы можете задать системе.

🔸 Monitoring — это про "Known Knowns". Вы знаете, что диск может заполниться, CPU — загрузиться, а latency — вырасти.

Вы пишете чеки и дашборды для ответов на вопросы, которые вы заранее предусмотрели. Это статические проверки для предсказуемых сбоев.

🔸 Observability — это про "Unknown Unknowns". В распределенных микросервисных архитектурах большинство инцидентов никогда не повторяются дважды одинаково.

Вы не можете написать дашборд для бага, который возникает только при сочетании: Android v10 + определенный region + конкретный feature-flag + редкая race condition.

Observability дает возможность задавать новые вопросы к системе "на лету", чтобы изолировать проблему.

🔢 Проблема High Cardinality и Dimensionality

Это технический аспект, который часто упускают при проектировании.

Традиционный мониторинг (например, Prometheus) построен на агрегации. Метрики эффективны, потому что они сжимают данные. Но агрегация убивает контекст. Вы видите, что p99 latency выросла, но не видите связи между user_id, build_id и endpoint.

Observability требует поддержки High Cardinality. Это возможность добавлять в телеметрию миллионы уникальных значений (например, конкретный request_id, shopping_cart_id или customer_uuid) без того, чтобы ваша Time Series БД взорвалась или стала стоить как крыло самолета.

Полноценная Observability оперирует не агрегатами, а событиями (structured events) с сотнями измерений. Это позволяет "нарезать" данные по любому произвольному признаку, чтобы найти ту самую иголку в стоге сена.

🛠 Смена парадигмы отладки

Переход к Observability меняет workflow инженера во время инцидента:

🔹 Вместо: "Смотрим на 20 дашбордов, пытаемся сопоставить скачки графиков визуально, гадаем на кофейной гуще, добавляем print в код, деплоим, ждем".

🔹 Становится: "Видим аномалию → Группируем ошибки по build_id → Видим, что проблема только в canary-релизе → Фильтруем по customer_tier → Понимаем, что затронуты только Enterprise-клиенты с определенным конфигом".

⚠️ Миф о Трех столпах

Часто говорят, что Observability = Logs + Metrics + Traces. Это заблуждение. Наличие всех трех типов данных не гарантирует наблюдаемость, если они разрозненны.

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

Это единое хранилище событий, а не три разных базы данных под каждый тип сигнала.

📚 Где углубиться в тему

"Observability Engineering" (Charity Majors, Liz Fong-Jones, George Miranda) — фундаментальная книга от создателей Honeycomb, детально описывающая переход от мониторинга к observability.

Google SRE Book, Chapter 6: Monitoring Distributed Systems — база о том, зачем вообще мы следим за системами.