Токсичный (it) архитектор

👋Известная истина гласит: люди делятся на два типа - те, кто ещё не делает бэкапы, и те, кто уже делает.

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

Потому что самое главное в бэкапах - это не процесс их создания. Бэкап, который вы никогда не пробовали восстановить - это Бэкап Шрёдингера. Пока вы не попытались поднять из него упавший прод, данные в нём одновременно и существуют, и представляют собой битый gzip-архив весом в 1 килобайт.

Вы можете годами платить за бездонные S3-бакеты и любоваться зелеными галочками в CI/CD: «Backup completed successfully». Вы можете спать спокойно, чувствуя себя ответственным профессионалом.

А потом наступает пятница. Уставший мидл случайно путает контуры и делает DROP TABLE users; на проде. Вы с гордым видом, как спаситель человечества, идете расчехлять бэкап, и тут выясняется прекрасное:

👉Скрипт последние полгода дампил только структуру базы, без самих данных.

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

👉Бэкап абсолютно рабочий, весит 10 терабайт, но чтобы развернуть его и переиндексировать на текущем железе, вам понадобится трое суток. Бизнес в восторге.

Делать бэкапы - это полдела. Это просто складирование файлов. Настоящая работа начинается на этапе восстановления (Disaster Recovery).

1️⃣Бэкап не существует, пока из него не подняли систему. Точка. Если вы не пробовали развернуть данные на чистом тестовом контуре, считайте, что бэкапов у вас нет.

2️⃣Автоматизируйте процесс восстановления. Раз в неделю скрипт должен поднимать временную базу из дампа, прогонять SELECT 1 и базовые тесты целостности, а потом убивать её. И присылать вам алерт, если что-то пошло не так.

3️⃣ Выучите мантру RTO и RPO. Бизнесу плевать на ваши bash-скрипты. Ему важно знать RPO (Recovery Point Objective - за сколько часов мы потеряли данные?) и RTO (Recovery Time Objective - сколько часов мы будем лежать, пока админы потеют?). «Мы всё восстановим» - это не ответ. Ответ звучит так: «Мы поднимемся за 45 минут с потерей данных за последние 2 часа».

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

А теперь признавайтесь в комментариях: когда вы в последний раз пробовали развернуть свой прод из резервной копии? Только честно.

#заметкинаполях

🤡Токсичный (it) архитектор🤡

👋Всем привет! Долго не писал сюда - честно, банально не было времени. Меня тут коллеги попросили прочитать курс по архитектуре микросервисов. И вот, проверяя домашки и общаясь со слушателями, меня в очередной раз посетил вопрос: а насколько вообще живы и адекватно используются такие тяжеловесные подходы, как CQRS и Event Sourcing?

Давайте для начала кратко напомню, что это вообще такое.

CQRS (Command Query Responsibility Segregation)
Что это: Паттерн, который говорит: «Хватит читать и писать данные через одну и ту же модель». Мы жестко разделяем систему на две части: Команды (изменяют состояние, ничего не возвращают) и Запросы (читают данные, ничего не меняют). Физически это часто означает разные базы данных для записи (нормализованная реляционка) и для чтения (какой-нибудь денормализованный ElasticSearch или Mongo).

Плюсы:
👉Асимметричное масштабирование. У вас 10 000 чтений на 1 запись? Отлично, масштабируем только базу для чтения.
👉Оптимизация. Данные для чтения можно заранее собрать в нужном виде (DTO), чтобы отдавать их клиенту без зубодробительных JOIN на 15 таблиц.
👉Изоляция. Тяжелый аналитический запрос не положит транзакционную базу.

Минусы:
👉 Eventual Consistency. Данные из базы записи попадают в базу чтения с задержкой. Если ваш фронтенд не готов к тому, что юзер обновил профиль, а на экране всё ещё старая фотка - готовьтесь к боли.
👉 Сложность инфраструктуры. Вместо одного PostgreSQL вам теперь нужно поддерживать две БД и шину сообщений (Kafka/RabbitMQ) между ними.


Event Sourcing
Что это: Мы перестаем хранить текущее состояние объекта. Вместо UPDATE user SET status = 'active' мы сохраняем историю событий: UserCreated -> EmailVerified -> StatusChangedToActive. Текущее состояние получается путем последовательного наката всех событий (свертка). Это как бухгалтерская книга: баланс — это сумма всех проводок, а не просто цифра в ячейке.

Плюсы:
👉Идеальный аудит. Вы на 100% знаете, не только какое сейчас состояние у системы, но и как она к нему пришла.
👉Машина времени. Можно откатить систему на любой момент в прошлом или воспроизвести баг на локалке, просто прогнав события заново.

Минусы:
👉Ад с версионированием событий. Что делать, если структура события OrderPlaced изменилась через год? Старые события никуда не делись, их всё равно надо уметь читать.
👉Сложность запросов. Нельзя просто сделать SELECT * WHERE balance > 1000. Вы не знаете текущий баланс, пока не прочтете все события. (Именно поэтому Event Sourcing почти всегда используют в жесткой связке с CQRS).

Где эти подходы реально нужны сегодня?

Джуны обожают притащить все что им интересно в очередной CRUD для блога или интернет-магазина, чтобы «сделать всё по красоте». А потом через полгода команда воет от того, что добавление одного поля в табличку занимает неделю.

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

Финтех и Биржи.
Ни один нормальный банк не меняет баланс через UPDATE. Деньги — это всегда события (MoneyDeposited, MoneyWithdrawn). Если налоговая или служба безопасности придет с вопросом: «Откуда у этого парня миллион на счету?», вы обязаны предоставить всю цепочку событий. Event Sourcing здесь - это не архитектурный изыск, это требование регулятора.

Системы бронирования с дикой асимметрией (Авиабилеты, Отели).
Миллионы людей ежесекундно ищут билеты на Aviasales (Запросы). И лишь единицы в эту же секунду их покупают (Команды). CQRS здесь спасает жизни: поисковый трафик бьет по супер-быстрым кэшам для чтения, а редкие транзакции покупок аккуратно складываются в надежную мастер-базу.

CQRS и Event Sourcing - спасают от конкретных тяжелых проблем (асимметрия нагрузки, строгий аудит), но если применять их бездумно (в обычном CRUD), вы просто сожжете бюджет и убьете команду.

А как у вас в компаниях? Внедряете CQRS по нужде бизнеса или потому что на Хабре написали, что так модно?

#этобаза

🤡Токсичный (it) архитектор🤡

👋Всем привет. Сегодня пост не про архитектуру и технические решения. Сегодня у нас минутка экзистенциальной фрустрации на тему ИИ.

Недавно наткнулся на комментарии: мол, контент у меня сгенерирован нейронкой, а сам я ничего нового «своими словами» не несу.

Может и так. Но давайте пофилософствуем.

Ещё пару лет назад мы мечтали, чтобы машины писали за нас код, а рекомендательные сервисы давали именно то, что мы хотим. Сегодня это наступило, и мир изменился. Глупо говорить, что ИИ нас заменит. Он просто дал нам основу для творчества.

Давайте пройдемся по фактам.

1️⃣Музыка: от производства до потребления.

Я занимаюсь музыкой, и, конечно, этот мир тоже стонет, что Suno и Udio убьют музыкантов. Чушь. ИИ просто удешевил производство «фона». Чтобы сделать джингл, теперь не надо платить композитору и ждать три дня. Вы генерируете это за вечер. Мы просто убили слой ремесленников, которые штамповали однотипный контент.

Поменялось и потребление. Одно время мы радовались, что «Моя волна» в Яндексе подсовывает нам музыку, которая нам нравится. Но ИИ пошел дальше. Теперь вы можете попросить Suno генерить вам бесконечный поток треков под ваше настроение. Хотите техно с волынкой или гуслями 24/7? Пожалуйста. Это персональное радио, где контент создается в реальном времени только для вас.

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

В музыке мы боимся использовать стандартные пресеты, так как они стоят там «с завода», и загоняем себя в угол, пытаясь придумать велосипед. А зря. Вспомните Gorillaz. Основная тема хита «Clint Eastwood» (тот самый узнаваемый бит) - это не гениальная композиция с нуля. Это стандартный пресет «Rock 1» из дешёвого синтезатора Suzuki Omnichord. Дэймон Албарн просто нажал кнопку. Стал ли трек от этого хуже? Нет. Это хит. ИИ - это просто новый, очень умный пресет.

2️⃣Тексты и Код: Проблема авторства.

Когда текст тупо сгенерирован и даже не вычитан - это зашквар, согласен. Но объясните мне разницу:

👉Вариант А: Я накидал идеи, отдал живому копирайтеру, он причесал текст. Вердикт: «Авторский контент».

👉Вариант Б: Я накидал идеи, скормил их GPT, он причесал текст. Вердикт: «Фу, нейронка!».

Это лицемерие. Посмотрите на нас, разработчиков. Сеньоры уже давно не пишут бойлерплейт руками. Мы делаем ревью того, что написал Copilot.

С текстами - то же самое. Я делаю ревью того, что написал GPT. Идея - моя. Структура - моя. Слова - его (отредактированные мной).

3️⃣Информационный шум.

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

4️⃣Конференции и уникальность.

Мы читаем каналы и ходим на конфы не ради сакральных знаний. В литературе всего 7 сюжетов, но это не мешает нам наслаждаться шедеврами. Так и в архитектуре: всё давно сказано, и найти что-то принципиально новое очень сложно.

Зачем тогда мы ходим? Чтобы потешить самолюбие, поспорить и убедиться, что другие страдают так же.


Итог.
Давайте отвечу на висящий в воздухе вопрос: использую ли я LLM? - Да.

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

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

А вы уже смирились с тем, что половина контента в вашей ленте - синтетика, или всё ещё ищете «тёплую ламповую душу» в каждом абзаце?

#заметкинаполях

🤡Токсичный (it) архитектор🤡

👋Сижу как-то на очередном «техкоме». Целый час двадцать вроде бы взрослых людей с зарплатами выше средней обсуждают, на чем им делать CI/CD. Jenkins, видите ли, «устарел и плагинами обмазан», в GitLab CI «не хватает гибкости», а GitHub Actions «слишком дорогой».

Смотрю на этот цирк с конями и думаю: вы в своем уме?

Вы покупаете профессиональные марафонские кроссовки человеку, который не умеет ходить.

Запомните: тулинг - это следствие, а не причина. Инструмент никогда не заменит вам мозги и не починит бардак в процессах. Если команда не понимает, что она делает, как она это делает и зачем, то дайте ей хоть самый распрекрасный CI - на выходе будет всё тот же мусор. Только доставляться он будет автоматически.

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

Главное - помните: не бывает «правильных» процессов, как не бывает «правильного» молотка. Бывают те, что подходят для вашей задачи, и те, которыми вы отшибете себе пальцы. Перестаньте искать священный грааль в книжках по SAFe. Это чужие ответы на чужие проблемы.

Хотите построить нормальный процесс? Перестаньте читать, начните думать.

1️⃣Запритесь в комнате всей командой. Никаких Jira и Notion. Только белая доска и маркер.
2️⃣Нарисуйте три блока: «ВХОД», «РАБОТА», «ВЫХОД». Это ваш скелет.
3️⃣А затем заполните эти блоки:

➡️ ВХОД: Откуда прилетает задача? В каком виде? Кто ее ставит? Что должно быть в ней (Definition of Ready), чтобы мы вообще начали чесаться?
➡️ РАБОТА: Что происходит с задачей? Не надо рисовать BPMN на 100500 шагов. Опишите по-простому: «Петя пишет код, Вася ревьюит, робот гоняет тесты».
➡️ВЫХОД: Что мы считаем результатом? Код в main? Выкатка на прод? Счастливый клиент? Как мы передаем результат дальше?


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

И вот когда вы, глядя на схему, все вместе кивнете и скажете: «Да, у нас это работает именно так», - поздравляю. У вас появился процесс.

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

Хватит искать волшебную кнопку. Её просто не существует.

А у вас в компании инструменты подбирают под задачи или пытаются натянуть процессы на купленный энтерпрайз-тулинг?

#заметкинаполях

🤡Токсичный (it) архитектор🤡

👋Смотрел вчера резюме очередного «сеньора-помидора». 12 лет в одной конторе. Гордится стабильностью, ждет медаль. А я смотрю на это и вижу не лояльность, а диагноз.

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

Если ты сидишь на одном месте десяток лет, ты не архитектор. Ты — хранитель костылей.

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

В продуктовом же энтерпрайзе ты просто выучил свою систему. Ты знаешь историю каждого «велосипеда», изобретенного в 98-м, и начинаешь верить, что это и есть индустриальный стандарт. Твой кругозор сузился до размеров корпоративной VPN. Ты не решаешь проблемы бизнеса, ты просто знаешь, в каком месте пнуть этого монстра Франкенштейна, чтобы он не сдох до понедельника. Это не архитектура, это стокгольмский синдром.

Способен ли теоретический опыт из книг сделать хорошего практика? Не смешите мои тапочки. Теория без боли от внедрения в разных контекстах — это беллетристика. Если ты не видел, как твои «гениальные» паттерны с треском ломаются в другой среде, ты — теоретик. Картонный генерал.

И тут возникает вопрос: «А если я меняю работу, но остаюсь в одной сфере?».

Прыжки между двумя банками — это как пересаживаться из одной камеры в другую. Стены те же, решетки те же, только баланда чуть солонее. Ты учишься решать специфические банковские проблемы (ACID любой ценой, бюрократия, легаси на мейнфреймах), а не инженерные. Глаз замыливается. В итоге ты начнешь пихать транзакционную целостность даже в сервис лайков для котиков, просто потому что «мы в банке всегда так делали».

И что нам остается делать?

✅3-5 лет — золотой стандарт. Спроектировал, внедрил, хлебнул горя с поддержкой (это обязательно!), исправил свои косяки — и вали. Не засиживайся.

✅Меняй домены. Уйди из финтеха в ритейл, из ритейла в IoT или медиа. Это больно, страшно, но это единственное, что выбивает дурь из головы и учит думать, а не копипастить.

Не путай опыт с выслугой лет. Один год опыта, повторенный 20 раз подряд — это не 20 лет стажа. Это стагнация.

❓Делитесь мнением: верите ли вы в существование крутого архитектора с одной записью в трудовой за 15 лет? Или это миф?

#заметкинаполях

🤡Токсичный (it) архитектор🤡

👋Всем привет. Сегодня нет желания токсичить, есть вопрос к вам.

Из каждого утюга сейчас вещают, как ИИ «изменит всё», «повысит маржу» и «сделает нас счастливыми».

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

Спрашивают: «Как припахать ИИ к реальным архитектурным задачам?».

Понятно, что нейронка не заменит нам мозги. Если вы не понимаете CAP-теорему, ChatGPT просто сгенерирует вам очень убедительный говнокод.

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

1️⃣Валидация ADR (Architecture Decision Records). Скормить контекст и спросить: «Где я идиот?». Иногда он реально находит граничные случаи, про которые вы забыли в 3 часа ночи.

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

3️⃣Быстроскриптинг. Накидать на коленке Python-скрипт для расчета метрик или парсинга логов, чтобы не вспоминать синтаксис библиотек.


Короче, вопрос к вам, выжившие.

Как вы реально применяете ИИ в работе? Не для «вдохновения» и генерации картинок с котиками, а для дела. Что можно внедрить в курсы или рассказать коллегам, чтобы они научились делегировать машине именно мусорную работу?

Жду ваши кейсы в комментариях.

#заметкинаполях

🤡Токсичный (it) архитектор🤡

👋На днях ревьювил архитектурную схему одного юного дарования, свежеиспеченного выпускника модного курса. Везде микросервисы, CQRS, Event Sourcing, Kafka... И всё это на проекте, где нужно было сделать CRUD для трех табличек.

Я посмотрел на схему, потом на него, и спросил: «Тебе самому-то не смешно?».

Проблема в том, что люди разучились включать голову. А ведь это главная задача архитектора - думать.💯

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

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

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

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

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

И тут возникает резонный вопрос: «А что, тогда не учиться по книгам? Есть же классика проектирования!»

Отвечаю: Книги и курсы - это не инструкция к применению. Это каталог.

Каталог чужих решений для чужих проблем. И это бесценно. Когда у вас действительно возникнет боль, вы сможете заглянуть в этот каталог и найти подходящий анальгетик. У нас медленные запросы на чтение? Окей, давайте посмотрим, что там пишут про CQRS.

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

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

#заметкинаполях

🤡Токсичный (it) архитектор🤡

👋Сижу, смотрю на дашборды мониторинга. Тишина. Первая часть января прошла без алертов.

Мои джуны сияют: «Смотрите, какой мы надежный код написали! Прод не упал!».
Ага, щас. Размечтались. Прод не упал не потому, что вы гении инженерии, а потому что вся страна две недели доедала оливье и смотрела сериалы, а не нагружала ваши кривые API.

Сегодня Старый Новый год.🔥 Отличный повод перестать верить в Деда Мороза и начать верить в технический долг.

Вы там спрашиваете: «Как исправить архитектуру, чтобы продукт развивался?».

Сразу предупреждаю: если ваша первая мысль - «Давайте всё перепишем с нуля на модном стеке», то дверь вон там.

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

Архитектуру не «исправляют» кавалерийским наскоком. Её лечат долго и нудно.

Как это делается в реальном мире, а не во влажных мечтах:

1️⃣Диагноз перед операцией. Не лезьте в код, пока не обвешаетесь метриками. «Мне кажется, тут тормозит» - это к психологу. Мне нужны графики Latency, Error Rate и Throughput. Чиним только то, что реально болит у бизнеса, а не то, что «некрасиво написано».
2️⃣Паттерн «Душитель» (Strangler Fig). Заучите это. Мы не переписываем монолит. Мы строим рядом новую систему и по капле переводим туда трафик. Старый код умирает сам, от некроза, когда становится ненужным.
3️⃣Стоп-лосс на рефакторинг. Выделяйте 20% времени спринта на техдолг. Не больше. Если вы продадите бизнесу идею «мы на полгода уйдем в рефакторинг», через полгода у вас не будет ни рефакторинга, ни работы.

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

За работу. Всех с наступившим 2026 годом. Давайте просыпаться и делать наши продукты лучше💯

#заметкинаполях

🤡Токсичный (it) архитектор🤡

👋На днях собеседовал очередного кандидата. Сеньор. Резюме - хоть сейчас в рамку, на стену вешай. Все модные слова на месте: Kafka, Kubernetes, Istio, все дела. Светится, как новогодняя елка.

Ну, думаю, дай спрошу что-нибудь простое, из жизни. Говорю: «Окей, представь. У нас есть сервис А и сервис Б. Сервис А меняет какие-то важные данные. Как ты обеспечишь консистентность этих данных в сервисе Б с минимальной задержкой и гарантией доставки?»

Парень завис. Похлопал глазами. А потом его понесло. Он начал мне рассказывать про партиции в Kafka, про брокеров, про репликацию и retention policy. Он говорил минут десять. Я слушал. А потом остановил его и спросил: «Подожди. А почему именно Kafka? А если у нас там нагрузка - три сообщения в час? Может, хватит обычной таблицы в Postgres для исходящих событий?»

И всё. Синий экран. В его мире любая задача по передаче данных решалась одним-единственным инструментом. Тем, который он вписал себе в резюме.😈

И вот что я вам скажу. Мы перестали растить инженеров. Мы начали штамповать операторов конкретных технологий.

У нас есть «Postgres-эксперты», «Kafka-евангелисты», «Kubernetes-гуру». Каждый из них вырыл себе очень глубокий, но очень узкий колодец. Они знают всё о своей маленькой ямке, но понятия не имеют, что происходит на поверхности. Они видят небо в виде крошечного круга и думают, что это и есть весь мир.

👀Архитектура в таких командах превращается в ад. Это как в притче про слепых и слона. Один пощупал ногу и кричит: «Это колонна!». Другой схватил за хвост: «Это веревка!». Третий наткнулся на хобот: «Это змея!». И никто из них не видит слона - то есть всю систему целиком. А архитектор бегает между ними, единственный зрячий, и пытается объяснить, что их веревки и колонны - части одного живого организма, который вот-вот на них наступит.

Проблема в том, что эти узкие специалисты решают не проблемы бизнеса. Они решают свои личные технические головоломки. «Kubernetes-гуру» будет строить вам кластер на пятьдесят нод для сайта-визитки, просто потому что он умеет и ему это интересно. А то, что поддержка этой махины будет стоить как крыло от самолета, его не волнует. «Kafka-евангелист» прикрутит вам отказоустойчивый кластер туда, где хватило бы простого RabbitMQ, потому что это «правильно» и «надежно».

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

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

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

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

С наступающим. И не наступайте на те же грабли.💯

#заметкинаполях

🤡Токсичный (it) архитектор🤡

👋Открываю календарь. Всё рябит от разноцветных квадратиков. 10:00 - дейли, 11:00 - груминг, 12:00 - какой-то мутный «alignment meeting» с соседним отделом.

Это не работа. Это ритуальное сожжение самого дорогого ресурса - времени инженера.

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

Давайте честно: 90% встреч - это коллективная безответственность.

Вам страшно принять решение в одиночку? Вы боитесь взять на себя риск? Поэтому вы собираете 15 человек на час, чтобы размазать ответственность тонким слоем по всем присутствующим, как дешевый маргарин по хлебу. Если проект рухнет - «мы же вместе решили».

Посчитайте burn rate. Десять инженеров на час - это стоимость нового Макбука, выброшенного в окно. И ради чего? Ради резолюции «давайте соберемся еще раз через неделю»?

Мои три правила выживания в этом цирке:

1️⃣Нет адженды и четкой цели - инвайт летит в корзину. Без разговоров. Мое время - не мусор.

2️⃣ Встреча без протокола - преступление. Нет письма с итогами «кто-что-когда»? Значит, встречи не было. Вы просто украли у компании час времени.

3️⃣Правило красной трубки. Если ты молчишь больше 15 минут и не понимаешь, зачем здесь, - жми красную кнопку. Ваше время дороже чужих обид.

Работа делается в тишине, в IDE и консоли, а не в болтовне. Хотите эффективности? Объявите «дни без встреч» и посмотрите, как внезапно начнут закрываться тикеты, которые висели месяцами.

#заметкинаполях

🤡Токсичный (it) архитектор🤡

👋Сижу, пью свой утренний американо. Всё как обычно. Тихо, спокойно, мозг еще не включился в режим тушения пожаров. И тут в корпоративный чат падает оно. Объявление, полное фальшивого восторга и эмодзи с хлопающими ладошками: «Наш Сеньор Хуан Помидор едет на главную IT-конференцию года с докладом о том, как мы победили энтерпрайз!»

Давайте я вам, дети, расскажу, что такое современная IT-конференция.💩

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

❗️Главный экспонат - спикер. Вчерашний инженер, который вдруг решил, что его умение настраивать K8s - это сакральное знание. Ментально этот человек выпадает из команды на месяц. Он больше не решает задачи бизнеса. Он «готовит слайды» и «репетирует перед зеркалом». Он превращается из инженера в инфоцыгана.

Компания оплачивает ему всё: перелет, отель класса «я-слишком-хорош-для-хостела», суточные и полную зарплату.

А что взамен? Иллюзия «прокачки HR-бренда». Мифическая вера, что джуны в зале тут же захотят к вам работать.

На практике компания инвестирует в то, чтобы сотрудник красиво упаковал себя для рынка и получил +$500 к офферу от конкурента, который клюнет на строчку «Спикер на крутой конфе».

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

А что с залом?

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

Раньше привозили мировых звезд - Фаулера, дядюшку Боба. Это был глоток воздуха. А сегодня? Локальные спикеры, которых ты и так встретишь на любом митапе или в YouTube на x1.5 скорости бесплатно.

Самыми честными остались бесплатные митапы от компаний.

Да, это неприкрытый хантинг. Но здесь всё прозрачно. Компания говорит: «Смотрите, какие задачи мы решаем. Вот пицца, вот вакансии». Разработчик приходит, ест, слушает и, возможно, меняет работу. Сделка честная. Никакого пафоса про «миссию» и «развитие комьюнити».

Так что же делать?

✅Инженеру: Хочешь на сцену? Не вопрос. Но рассказывай не про то, как ты прочитал книжку по DDD, а про то, как вы полгода внедряли его, трижды упали, потеряли данные и набили шишки. Покажи шрамы, а не глянцевую обложку. Твой доклад должен быть «посмертным вскрытием», а не рекламным буклетом.

✅Руководителю: Прекрати отправлять людей на «отдых» под видом обучения. Задай сотруднику после конференции один вопрос: «Что конкретно мы внедрим в работу завтра?». Если в ответ тишина - ты спустил бюджет в унитаз. Лучше купи команде подписку на O'Reilly или курсы у реальных практиков.

Настоящее развитие происходит не в конференц-залах, а в IDE, в код-ревью и в отчетах об инцидентах. Всё остальное - театр.

#заметкинаполях

🤡Токсичный (it) архитектор🤡

👋Сижу, разгребаю очередную «архитектуру» стартапа. Ребята распилили монолит на двадцать кусков, а теперь с ужасом поняли, что данные разъехались, как ноги коровы на льду. И теперь, чтобы все хоть как-то работало используют Saga Pattern.

Давайте честно. Сага - это не «паттерн проектирования». Это признание поражения или признание того, что вы усложнили систему раньше времени. Вы расписались в том, что не смогли правильно определить границы контекстов, и теперь пытаетесь склеить разбитую вазу скотчем и молитвами.🤬

Вы правда думаете, что Хореография (Choreography) - это красиво? Это когда сервисы перекидываются событиями, как горячей картошкой. Сервис А списал деньги, крикнул в Kafka, Сервис Б услышал (или нет), попытался зарезервировать товар... Ой, ошибка. А Сервис А уже забыл, что он вообще что-то списывал. 💩

В итоге у вас не «танец», а пьяная драка в темном баре. Никто не знает, кто начал, кто виноват, и почему клиент остался без денег и без штанов. Отладка этого ада - лучший способ выгореть за месяц.

🔹Оркестрация (Orchestration) чуть лучше. Вы ставите надсмотрщика (Оркестратор), который пинает сервисы. Но теперь вы создали «Божественный сервис», в котором зашита вся логика. Поздравляю, вы переизобрели монолит, только теперь он тормозит по сети.

🔥И самое сладкое - компенсирующие транзакции. Помните из универа четыре волшебные буквы: ACID? Конкретно одну из них - «I», Isolation, «Изоляция»? Это когда грязное белье одной транзакции не видит другая. Все происходит как бы в вакууме. Так вот, в вашем распределенном шапито этой буквы нет со всеми вытекающими.

Что с этим делать:

1️⃣Избегайте распределенных транзакций любой ценой. Если два действия должны быть атомарны - держите их в одном сервисе и одной БД.

2️⃣Если прижало - выбирайте Оркестрацию. Вам нужен лог состояния, чтобы понимать, на каком шаге все рухнуло. Хореография годится только для примитивных событий «пожар-забыл».

3️⃣Идемпотентность - это религия. В распределенной среде сообщения дублируются. Если ваш сервис спишет деньги дважды по одной Саге - вас уволят, и правильно сделают.

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


#этобаза

🤡Токсичный (it) архитектор🤡

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

И тут мне на глаза попадается анонс  от моих друзей и коллег True Tech Arch 8.

Обычно я говорю: забейте на конференции. В 90% случаев это ярмарка тщеславия, где джуны охотятся за бесплатным мерчем, а спикеры продают вам свои костыли под видом «инноваций».

Но тут есть нюанс. Arch Kata.

Организаторы, похоже, решили включить голову. Вместо того чтобы просто кормить вас слайдами, они заставляют работать. Выдача кейсов, решение, защита. Это, черт возьми, прекрасно. Архитектура - это не рисование стрелочек в Draw.io, это умение принимать решения в условиях неопределенности и защищать их перед теми, кто хочет вас закопать.

Программа на 10 декабря такая:

- 17:00: Сбор, кофе (ладно, кофеин нам нужен).
- 18:00: Парочка докладов. Надеюсь, без воды.
- 20:00: Самое "мясо" - защита проектов Arch Kata.

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

Короче, план такой:
Если вы в Москве и у вас есть хоть капля профессиональной гордости - регистрируйтесь. Мест мало, халяву любят все. Если вы далеко или слишком заняты «горящими» задачами - ждите запись или участвуйте онлайн.

Но лучше прийти. Нетворкинг там, говорят, будет. Шанс найти адекватного инженера среди толпы «скрам-мастеров» сейчас на вес золота.

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

Регистрируйтесь!

#интересное

🤡Токсичный (it) архитектор🤡

👋Сижу, пью эспрессо и листаю очередную презентацию от «бизнес-архитекторов». Слайды красивые, спору нет. Красивый зеленый квадрат «Омниканальные продажи». Рядом - «Единый профиль клиента». И, конечно, гвоздь программы - карта капабилити. Выглядит как меню в дорогом, но отвратительном ресторане. Никаких конфликтов, никаких гонок состояний, никаких распределенных транзакций. Рай.

А теперь спускаемся с небес на землю.

Тот самый «Единый профиль» в реальности - это пять разных баз данных, которые синхронизируются скриптом на Perl, написанным уволенным пять лет назад стажером. А «Омниканальность» падает, если одновременно зайти с айфона и через веб, потому что ваш легаси-монолит сходит с ума от двух сессий.😠

И вот что я вам скажу. Вся эта ваша бизнес-архитектура - в 90% случаев карго-культ и профанация.

Это новая любимая игрушка менеджеров, которые хотят «как в Google», и архитекторов, которые разучились говорить с инженерами. Они рисуют эти карты, чтобы создать иллюзию контроля над хаосом. «Управление маркетингом», «Взаимодействие с клиентом». Серьезно? Вы только что описали любой бизнес на планете. Какая в этом ценность?

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

Пока вы двигаете пиксели в PowerPoint, конкуренты выкатывают фичи. Ваши красивые схемы превращаются в пыльный артефакт, который достают раз в год, чтобы показать новому C-level, как у вас «все по уму».

Карта капабилити - это не стратегия. Это даже не карта. Это просто список существительных. Она не отвечает на вопрос «как?». Она не говорит, где у вас пожар, а где - болото. Это инструмент для тех, кто боится испачкать руки в коде и процессах.

Хватит рисовать. Начните говорить с людьми.

🔍Вместо карты «капабилити» соберите карту проблем. Где болит? Где мы теряем деньги? Где клиенты от нас уходят? Вот ваша архитектура. Она должна быть не про абстрактные «способности», а про конкретные «боли» и способы их лечения.

Перестаньте играть в стратегов. Будьте инженерами.

#заметкинаполях

🤡Токсичный (it) архитектор🤡

👋 На днях ко мне подходит техлид соседней команды. Глаза горят, руки трясутся от возбуждения. Предлагает переписать стабильный, годами работающий модуль отчетов на Rust.

Я делаю медленный глоток кофе, смотрю ему в переносицу и задаю всего два слова: "Чтобы что?"

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

Давайте проясним раз и навсегда.

«Чтобы что?» - это не пассивная агрессия. Это главный инструмент инженерной гигиены.🚀

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

Вы привыкли измерять работу в «стори-поинтах» и закрытых тикетах. Вы путаете движение и результат. Вам кажется, что если вы три недели прикручивали Kafka туда, где хватило бы HTTP-запроса - вы молодцы.💩

А я вижу другое: вы сожгли 1,000,000 рублей, чтобы усложнить систему и добавить новые точки отказа.

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

Как отвечать на этот вопрос, чтобы я от вас отстал (и даже зауважал):

1️⃣Говорите на языке денег, а не хайпа.

Плохо: «Нам надо внедрить GraphQL, потому что REST устарел».
Хорошо: «Внедрение GraphQL сократит трафик в мобильном приложении на 40%, и мы перестанем терять клиентов с плохим интернетом».

2️⃣Доказывайте через проблему, а не через решение.

Не «давайте перепишем код», а «текущий код падает при 1000 RPS, мы теряем заказы, рефакторинг поднимет планку до 5000».

3️⃣Имейте смелость признаться.

Если вы просто хотите поиграть с новой технологией - так и скажите: «Хочу изучить Rust, сделаю пет-проект в свободное время». Но не тащите это в продакшн за счет компании.

Перестаньте видеть в вопросе «Чтобы что?» личное оскорбление. Это спасательный круг.

Я задаю его сейчас, чтобы через полгода, когда всё рухнет, бизнес или инвестор не спросил вас: «А зачем вы вообще здесь нужны?».

#заметкинаполях

🤡Токсичный (it) архитектор🤡

👋Прилетает мне тут на днях инвайт: «Рабочая группа по унификации микросервисов». В участниках - 15 человек. Трое пишут код, двенадцать - имеют «ценное мнение».

Я отклонил встречу. Я и так знаю, чем это закончится.

Рабочая группа - это эвфемизм для коллективной импотенции.👀

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

Знаете, что вы будете делать следующие три месяца? Вы будете спорить о цвете кнопок и отступах в JSON-е. Вы потратите сотни человеко-часов на «выработку консенсуса», который никому не нужен.

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

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

Вот несколько пунков чтобы перестать имитировать бурную деятельность и начать работать:

📍DRI (Directly Responsible Individual) или смерть. У любой задачи должна быть одна фамилия. Если за задачу отвечают двое - за неё не отвечает никто. Назначьте ответственного, дайте ему полномочия посылать советчиков лесом и спросите результат.

📍RFC вместо митингов. Хочешь предложить изменение? Не созывай группу. Напиши документ (Request for Comments). Четко, письменно, с примерами. Пусть остальные оставят комменты асинхронно. Нет документа - нет обсуждения.

📍Правило «Минус один». Если на встрече рабочей группы вы не можете сказать, кто здесь лишний - значит, лишние здесь все. Оптимальный размер группы для принятия решений - 3 человека. Максимум - 5. Всё, что больше - это уже митинг-ток-шоу.

Вам нужны не «рабочие группы», а компетентные лидеры, готовые брать на себя риск и принимать непопулярные решения. Всё остальное - корпоративный шум.

#заметкинаполях

Токсичный (it) архитектор

👋Смотрю тут пулл-реквест одного героя из прошлого поста. Вижу хардкод URL-ов внешних сервисов и  бизнес-логику, намертво вшитую в контроллер, вперемешку с сырыми SQL-запросами.

Спрашиваю: «Какого чёрта? Где абстракции? Где конфиги?»
А он мне с умным видом: «YAGNI! You Ain't Gonna Need It. Зачем усложнять сейчас, если нам это может не понадобиться?»


YAGNI - это не индульгенция на говнокод. И это не оправдание для вашей лени.

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

Архитектура - это возможность вносить изменения с минимальной болью, а не попытка угадать будущее

Давайте запомним простые истины:

📍YAGNI это про то, что делает код, а не про то, как он написан. Код должен быть чистым всегда.

📍Hardcoded strings - это технический долг, а не упрощение.

📍Разделение ответственности (SRP) не нарушает YAGNI. Это база, которая позволяет проекту выжить.

Ваша «простота» сегодня - это паралич разработки завтра.

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

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

#заметкинаполях

Токсичный (it) архитектор

👋Сижу вчера на ревью архитектуры. Команда гордо презентует новый сервис: Kubernetes, Istio, асинхронщина через Kafka, база - какая-то модная NoSQL дичь, название которой я даже запоминать не хочу.

Спрашиваю: «Какая нагрузка планируется?».
Ответ: «Ну, человек 50 в день... но мы готовимся к скейлу!».

В этот момент мне захотелось выйти в окно.

Давайте начистоту. Это не проработка архитектуры и не забота о будущей нагрузке. Это резюме-ориентированная разработка.

Вы тащите в проект технологии не потому, что они нужны бизнесу. А потому, что с ними ваше резюме выглядит сексуальнее для рекрутеров из Big Tech. Вам плевать, как это потом поддерживать. Главное - получить строчку в CV и свалить на +100к, пока этот карточный домик не рухнул.

Это не инженерия, а профессиональный саботаж.

Вы строите «Звезду Смерти» для доставки пиццы. В итоге мы получаем:

❗️Оверинжиниринг. Сложность системы растет экспоненциально, а польза - линейно.

❗️Техническую беспомощность. Когда ваш Istio отрыгнет ошибку, никто не поймет, почему. Потому что вы скопировали конфиг с Medium или Хабра, даже не читая документацию.

❗️Бюджет в трубу. Вместо фич бизнес платит за оплату облаков, которые просто греют воздух.

Хватит играть в стартаперов из Кремниевой долины.

📍Скука - это надежность. Скучный монолит + PostgreSQL вывезет 99% ваших задач.

📍Доказывайте необходимость. Хочешь Kafka? Покажи мне метрики, где RabbitMQ задыхается или где база лочит таблицу. Не можешь? Иди пиши код, а не занимайся ерундой.

📍Думайте о TCO (Total Cost of Ownership). Стоимость технологии - это не цена лицензии. Это зарплата тех бедолаг, которые будут чинить ваши «инновации» в 3 часа ночи.

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

#заметкинаполях

Токсичный (it) архитектор

👋Тут на выходных в соседнем телеграмм канале я увидел крик души. Человек пытается сделать благое дело — описать простую, прагматичную архитектуру для Go. Он хочет собрать сбалансированный, проверенный набор принципов, паттернов и примеров кода, который можно взять за основу для реальных проектов.

И знаете, что я об этом думаю? Это одновременно и прекрасно, и ужасно.

Прекрасно — потому что это глоток здравого смысла среди всего этого карнавала с DDD, Clean Architecture и гексагонами, которые пихают в каждый CRUD-сервис на три с половиной ручки.

А ужасно — потому что сама потребность в такой «инструкции» — это диагноз всей нашей индустрии.

Человек пытается написать простую, внятную поваренную книгу. А знаете, почему она нужна? Потому что 90% команд разучились жарить яичницу, но пытаются повторить рецепт из мишленовского ресторана. Начитаются Фаулера, насмотрятся докладов и тащат в свой проект репозитории, юзкейсы, адаптеры, порты...

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

🔥Так вот, запомните. Хорошая архитектура — это не та, в которую нечего добавить, а та, из которой нечего убрать. Ваша задача — решать проблему бизнеса, а не строить собор по всем канонам.

Начинайте с тупого монолита с пакетами по фичам (`feature-based layout`). Когда реально понадобится — вынесете интерфейс, добавите слой. Не раньше.💯

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

#заметкинаполях

Токсичный (it) архитектор