👋Листаю ленту. Очередная статья-молебен на тему «Как AI сделает из вас архитектора-бога». Пишет ADR-ы, рисует C4-диаграммы, отвечает на тупые письма от менеджеров. Все в восторге. Комментарии — сплошной восторг.

А у меня в голове только одна мысль.🙃

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

Помните, как в школе решали задачи? Сидишь, потеешь, скрипишь мозгами, исписываешь черновики. И вот оно — щелчок. Понимание. Ты не просто получил ответ, ты понял, как он работает. Ты прошел через боль и стал умнее.

А теперь представьте имбецила, которому сразу дали калькулятор. Он получает правильные ответы. Он даже может сдать экзамен. Но он понятия не имеет, что он, черт возьми, делает. Он не может отличить умножение от сложения. Он — оператор кнопок.

Вот это и есть архитектор, который «проектирует» с помощью AI. Он скармливает промпт и получает красивую картинку. Микросервисы, Кафка, вот это всё. Выглядит солидно. Только он не знает, почему система именно такая. Почему здесь нужен CQRS, а не простой CRUD. Почему этот сервис взорвется под нагрузкой.

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

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

AI — это анаболики. Он дает вам быстрый, красивый результат. Ваша презентация выглядит так, будто ее делал бог. Ваши диаграммы безупречны. У вас есть «мышцы». Но это фальшивка. Внутри — пустота. Стоит только столкнуться с реальной, нестандартной проблемой, и вся эта красота схлопывается. Потому что силы нет. Выносливости нет. Мозга нет.

Архитектура — это не про рисование квадратиков. Это про принятие решений с неполными данными. Про выбор меньшего из зол. Про умение сказать «нет» гениальной идее бизнеса, потому что ты видишь на три шага вперед и понимаешь, что она приведет к коллапсу.

Вы правда думаете, что этому можно научить машину?👀

И самое страшное. AI не будет сидеть до ночи с джуном, объясняя ему на пальцах, почему его код — говно, и как сделать лучше. AI не посмотрит в уставшие глаза тимлида и не скажет: «Расслабься, мы справимся». AI не возьмет на себя ответственность, когда все пойдет по одному месту.

А вы? Если вы отдали машине право думать, то кто вы в этой схеме? Вы становитесь просто передаточным звеном. Прокладкой между AI и командой.

И знаете, что делают с ненужными прокладками? Их выбрасывают.

Так что продолжайте радоваться. Генерируйте свои ADR-ы одной кнопкой. Пусть AI думает за вас. Только потом не удивляйтесь, когда однажды вас заменят. Не другой нейросетью. А простым скриптом на Python.

Потому что оператор кнопок должен стоить дешево.💯

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

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

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

Захожу в переговорку. На огромном экране слайд, от которого у меня начинает дергаться глаз: «Стратегия миграции: паттерн „Душитель“». Сидит смузи-тимлид, глаза горят и рассказывает, как они сейчас элегантно и безрисково распилят свой древний монолит.

Я чуть не лопнул от смеха.😁 Безрисково они хотят...

Короче. Давайте я вам объясню, что такое ваш хваленый «душитель», без красивых диаграмм из докладов с конференций.

Представьте, что ваш монолит - старый, ржавый, но рабочий грузовик. Он чудит, жрет масло, но худо-бедно возит грузы и приносит деньги. Вы хотите заменить его на новый блестящий пикап или что-то другое. Идея номер один - сжечь старый грузовик и ждать, пока приедет новый - это подход «Big Bang Rewrite», который проваливается в 99% случаев, оставляя бизнес с голой задницей.💩

Паттерн «Душитель» (Strangler Fig) продается вам как гениальный и простой план: давайте рядом со старым грузовиком потихоньку строить новый, и постепенно перекладывать груз с одного на другой. Звучит вроде как безопасно, да?

Это сказка для менеджеров.

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

Красиво? Да.
Работает? В книжках пишут что да. 👀

А теперь суровая реальность, о которой вам не расскажут на митапах.

🧐 Это невыносимо ДОРОГО и ДОЛГО. «Постепенно» в мире средней компании — это «годами», и не говоря про энтерпрайзы. Все это время вам нужно содержать два зоопарка. Кормить команду, которая ковыряет легаси-говно мамонта, и команду хипстеров, которые пилят новые сервисы на Go. Это двойные расходы на инфру, пайплайны, мониторинг и зарплаты. Это кровоточащая рана в бюджете вашей компании.

🙄 Ваш прокси — это ваш НОВЫЙ "МОНОЛИТ". Только еще хуже. Этот фасад, который вы поставили спереди, становится самой сложной и хрупкой точкой отказа. В нем логика роутинга, аутентификация, трансляция протоколов. Ошибка в конфиге этого монстра кладет ВЕСЬ ваш бизнес. Вы не избавились от монолита, вы просто назвали его API Gateway и сделали сетевым. Гениально.

😡 АД С ДАННЫМИ.  Главный гвоздь в крышку гроба вашего проекта. Как ваш новый сервис профилей будет работать с заказами, которые остались в базе монолита? Будет ходить в старую базу напрямую? Поздравляю, вы только что изобрели распределенный монолит — худшее, что создало человечество после смузи с авокадо. Данные в двух местах, связанные через нестабильную сеть. А как синхронизировать? А консистентность? Вы утонете в скриптах миграции, очередях и бесконечных разборках, почему данные разъехались. 80% времени и нервов уйдет сюда.

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

И ответьте себе на три вопроса, только честно, глядя в зеркало:

😐 НАХРЕНА? Какую бизнес-проблему вы решаете? «Монолит - немодно, надо микросервисы» - это диагноз, а не ответ.

😐 ГДЕ РЕЗАТЬ? У вас есть четкое понимание границ модуля, который вы собрались отпиливать? Вы уверены, что он не связан с остальным монолитом тысячами невидимых нитей? Вы проводили аудит?

😐 ЧТО С ДАННЫМИ? Покажите мне ваш план миграции и синхронизации данных. Не на словах, а на бумаге, с диаграммами и проработанными кейсами откатов. Нет плана? Свободны.

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

#этобаза

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

👋На днях был на собеседовании. Полчаса - нормальный, железный разговор: CAP-теорема, стратегии миграции баз. А потом началось. Следующий час меня мариновали на тему «умения вдохновлять», «разрешения конфликтов» и «проактивного мышления». Я чуть не спросил, им архитектор нужен или тамада на корпоратив.

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

Это бред.

Бред, который убивает проекты. Медленно, но гарантированно.

Представьте, вам нужна сложная операция на сердце и у вас есть два хирурга.

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

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

Кого вы выберете?👀 Если у вас есть инстинкт самосохранения, вы выберете того, у кого самый низкий процент смертности. И плевать вы хотели на его «софт-скиллы».💯

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

Забудьте чушь из HR-буклетов. Вот настоящие «софт-скиллы» архитектора:

🚀Интеллектуальная честность. Способность публично сказать: «Я не знаю» или «Я облажался, вот план, как это исправить». А не лепить умное лицо, неся чушь.
🚀Техническое мужество. Умение быть щитом проекта, а не флюгером. Говорить «нет» бизнесу, команде, гендиру - кому угодно, если их хотелки ведут всех на дно.
🚀Способность к трансляции. Умение переводить с языка байтов на язык денег. Объяснить менеджеру, почему его «маленькая кнопочка» будет стоить полгода рефакторинга.

Всё остальное - мишура.

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

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

Выбирайте. Только потом не жалуйтесь.

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

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

👋Смотрю на часы. 10:45. Наш 15-минутный «ежедневный синк» идет уже сорок пять минут. Сорок пять, Карл! Скрам-мастер, вчерашний выпускник курсов по «лидерству и мотивации», с видом Черчилля перед высадкой в Нормандии водит курсором по Jira.🫡 Тимлид пытается в пятый раз объяснить, почему его задача «в процессе» уже третий день. А я просто жду, когда этот сеанс коллективного самообмана закончится и можно будет по-настоящему работать.

И в этот момент меня накрывает. Окончательно и бесповоротно.

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

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

А story points? О, это моя любимая корпоративная астрология.🍄 Попытка натянуть сову на глобус, чтобы создать иллюзию предсказуемости там, где ее быть не может. Сидят взрослые, бородатые мужики и на полном серьезе спорят, два «попугая» стоит эта задача или три с половиной. Это же бред сивой кобылы. Вы просто боитесь признаться бизнесу в страшной правде: разработка - это исследование, а не конвейер. Точные оценки невозможны. Но нет, мы будем играть в покер планирования, рисовать графики сгорания и делать вид, что управляем хаосом. Это ложь. Сладкая, успокаивающая ложь для тех, кто не выносит неопределенности.

И роль архитектора в этом балагане? У тебя два пути, и оба ведут в ад.

Первый - стать цербером. 😠Ты стоишь на страже «правильной» архитектуры, и ни одна задача не проходит без твоего благословения. Команда, окрыленная «гибкостью», приносит тебе на ревью очередной архитектурный франкенштейн, слепленный из трех фреймворков и скотча. Ты заворачиваешь, объясняешь, рисуешь диаграммы. В итоге ты - бутылочное горлышко. Главный тормоз команды, который мешает «быстро поставлять ценность».

Второй путь - стать наблюдателем.😳 Ты машешь рукой, мол, «самоорганизующаяся команда», и позволяешь им творить. Они счастливы. Velocity растет. Менеджеры хлопают в ладоши. А ты молча смотришь, как варвары строят из твоего Рима уродливые фавелы. Как закладывается технический долг такого размера, что расплачиваться за него будут три поколения программистов. А через год, когда система встанет колом под нагрузкой, кто будет виноват? Правильно, архитектор. «Куда же ты смотрел?!»

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

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

🚀Дейли - три вопроса: Что сделал? Что буду делать? Что мешает? Пять минут на команду. Все. Остальное - в личку или отдельные встречи.
🚀 Оценки - забудьте про story points. Оценивайте в днях, вилками (например, 2-5 дней), и честно говорите, что это предположение, а не клятва на крови.
🚀Архитектура - она не возникает из хаоса. Она должна опережать разработку хотя бы на шаг. Выделите время на проектирование. Да, это «не по Agile». Плевать. Либо так, либо через год будете жить в руинах.

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

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

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

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

Всем привет!👋

"Очередной созвон. На экране расшаренная VS Code. Молодой и восторженный тимлид с горящими глазами показывает мне… код. Код, который генерирует диаграммы.

«Мы внедряем LikeC4! - вещает он. - Теперь у нас будут живые, актуальные схемы прямо в репозитории! Больше никакого Miro, который вечно устаревает!»

Я молча отхлебнул кофе. В его голосе было столько щенячьего восторга, будто он не инструмент для рисования коробочек нашел, а лекарство от рака."

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

LikeC4 - это набор инструментов и специализированный язык (DSL), который описывает архитектуру в виде единой модели, а затем компилирует ее в различные диаграммы.🔥

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

#интересное

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

Привет,👋 на этой неделе хочется поговорить про CAP-теорему.🧐 Попытаюсь в несколько постов раскрыть эту тему.

И начнем с истории. Меня как-то позвали на «архитектурное ревью», где сидят двадцать человек с горящими глазами, изучают слайды. 👀Микросервисы, кубернетес, распределенная база данных. И тут тимлид, с придыханием, произносит сакральное: «Мы выбрали AP-систему, потому что для нас важна доступность. Будем жить с eventual consistency».

Давайте начистоту. Теорема CAP - это не сложная компьютерная наука. Это тест на IQ для инженеров. Простейший выбор из трех стульев, на двух из которых пики точеные.

У вас есть три вещи:
🗿Consistency (C): Все видят одни и те же данные в один и тот же момент. Никаких «подождите, у меня другая версия».
🗿Availability (A): Система всегда отвечает на запросы. Не падает с ошибкой, даже если внутри у нее армагеддон.
🗿 Partition Tolerance (P): Система продолжает работать, даже если часть ее серверов перестала «видеть» другую часть. Например, сетевой кабель перегрызла крыса в дата-центре.

Так вот, CAP говорит: когда случается (P) - а он, вашу мать, всегда случается, это закон Мерфи в железе, - вы должны выбрать что-то одно. Либо (C), либо (A). Нельзя и рыбку съесть, и в кресло сесть.

Большинство «модных» команд, начитавшись блогов Netflix, как мантру повторяют: «Нам нужна доступность! Выбираем AP!». Звучит круто. На деле это означает: «Мы готовы отдавать пользователю любую чушь, лишь бы он не увидел ошибку 500». Система доступна, да. Но данные в ней - каша. Один сервис видит, что товар на складе есть, а другой - что его уже купили. Привет, потерянные заказы и злые клиенты. Ваша «eventual consistency» на практике часто означает «consistency never». Так что кроме как на лайки такие подходы ставить не стоит.

А есть и другая крайность - CP-системы. Банки, биллинг. Там, где за расхождение данных можно присесть. Система лучше упадет и перестанет отвечать (потеряет A), чем покажет неверный баланс (сохранит C). Это честный, взрослый выбор.

Но знаете, что самое смешное? Пока вы тут выбираете между C и A, вы забываете, что сеть падает не все время. Большую часть времени она работает. И тут на сцену выходит старший, еще более злой брат CAP — теорема PACELC.😳

Она задает вопрос, от которого у многих начинает дергаться глаз: «Хорошо, сейчас сеть в порядке (нет P). Что выберешь теперь: Latency (L) или Consistency (C)?».

И вот это - ваш ежедневный ад. Отдать ответ быстро, но с риском, что данные чуть устарели? Или заставить пользователя подождать, пока система синхронизирует все реплики и выдаст 💯% точный результат?

Системы, построенные только по CAP, игнорируют этот аспект. Они как одноклеточные: «сеть упала - действуем по плану Б». А PACELC заставляет думать постоянно. Когда все хорошо (Else), мы жертвуем консистентностью ради скорости (EL) или скоростью ради консистентности (EC)?

Ваша новомодная MongoDB - это PA/EL. В случае сбоя она выберет доступность. В штатном режиме - низкую задержку. А какой-нибудь VoltDB - это PC/EC. Упадет, но не соврет. И в обычном режиме будет проверять данные до посинения, жертвуя скоростью.

Так что прекратите кичиться знанием трех букв. CAP - это гигиенический минимум. Сейчас стоит думать в терминах PACELC, и думать не только когда сеть падает, но и когда все идет по плану. Задайте себе два вопроса:
🚀Что для бизнеса страшнее: простой или вранье? (Это ваш выбор C или A при P).
🚀Что для пользователя важнее: скорость или 100% актуальность данных? (Это ваш выбор L или C, когда все работает).

Ответы на эти вопросы для сервиса корзины и для сервиса авторизации будут, мягко говоря, разными.

#этобаза

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

👋Ну что продолжаем неделю про CAP теорему и поговорим про "С"

Для большинства из вас «консистентность» - это как «любовь» для подростка. Что-то одно, великое и непонятное. Вы думаете, это тумблер: включил - и все хорошо, выключил - и наступила «eventual consistency». Так вот, бред это сивой кобылы. Консистентность - это не выключатель. Это, мать его, регулятор мощности на электростанции, где каждое деление на шкале стоит вам денег, производительности и седых волос.

Давайте я вам разложу на пальцах, какой бывает эта ваша "C" и почему ваш выбор «строгой» консистентности - это, скорее всего, выстрел себе в ногу.💩

🔥Строгая консистентность (Linearizability)

Представьте себе одного-единственного бухгалтера на всю компанию, который сидит в запертой комнате. Любая операция - списание, зачисление, запрос баланса - идет через него. Он обрабатывает их строго по одной. Да, это медленно. Да, у его двери всегда очередь. Но, черт возьми, вы можете быть на 100% уверены, что в любой момент времени баланс - единственно верный.

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

🔥Последовательная консистентность (Sequential Consistency)

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

Когда это нужно: Системы, где важен порядок событий. Например, в чате сообщение А должно всегда приходить раньше ответа Б на него. Или в системе совместного редактирования документа правки должны применяться у всех в одной и той же последовательности, чтобы не получилась каша.

🔥Причинная консистентность (Causal Consistency)

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

Когда это нужно: Социальные сети. Вам важно увидеть комментарий под постом, а не наоборот. Но вам абсолютно все равно, в каком порядке вам покажут два несвязанных поста от разных людей. Это отличный компромисс между строгостью и производительностью для 90% систем.

🔥Консистентность в конечном счете (Eventual Consistency)

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

Когда это нужно: Там, где цена расхождения данных - ноль. Лайки, счетчики просмотров, рекомендации товаров. Ну лайкнул пользователь пост, а счетчик обновился через 10 секунд. Кто-то умер? Нет. Быстро, дешево, масштабируемо. Но применять это к корзине или балансу пользователя - это профессиональное самоубийство.

🔥И что в итоге

Прежде чем орать на совещании «нам нужна консистентность», задайте себе один вопрос, но честно:

Какова цена ошибки, если данные на долю секунды разойдутся?

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

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

#этобаза

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

👋Ну что продолжаем про CAP. Меня умиляют команды, которые на каждом углу кричат: «Наш главный приоритет - доступность!». Они пишут это в README, вставляют в презентации для начальства. Звучит солидно. А потом у них падает база данных, и вся их «доступность» превращается в тыкву, потому что никто не подумал о репликации.

Давайте начистоту. Доступность (Availability) - это не галочка в Jira. Это самая дорогая и лживая метрика в IT. Вы не можете просто «выбрать доступность». Вы покупаете ее. За деньги, сложность и бессонные ночи вашей команды поддержки.

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

🔥Уровень 1: «Бытовая доступность»

Это ваш типичный проект-монолит на одном сервере. Доступен ли он? Да, пока сервер работает. Когда он падает - из-за сбоя питания, обновления ОС или потому что уборщица выдернула шнур - система недоступна. Все просто и честно. Это ларек с шаурмой. Если продавец заболел, ларек закрыт. Никто не ждет от него доступности 24/7.

Когда это нормально: 90% внутренних систем, админок, MVP, которые вы показываете инвестору. Короче, везде, где минута простоя стоит дешевле, чем зарплата еще одного инженера.

🔥Уровень 2: «Три девятки» (99.9%) - Начало боли

Это примерно 8.7 часов простоя в год. Чтобы этого достичь, одного сервера уже мало. Вам нужен как минимум второй сервер и балансировщик нагрузки. Теперь, если один сервер падает, второй подхватывает трафик. Звучит просто? А теперь подумайте: вам нужна репликация данных между ними, консистентность этих данных, система мониторинга, которая поймет, что первый сервер упал, и автоматический механизм переключения. Ваша архитектура усложнилась в три раза. Цена - деньги на железо и зарплата DevOps-инженера.

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

🔥Уровень 3: «Пять девяток» (99.999%) - Элитный клуб самоубийц

Это 5 минут простоя в год. ПЯТЬ. МИНУТ. Это включает время на развертывание, обновление, любые сбои. Чтобы достичь такого, вам уже недостаточно двух серверов. Вам нужны несколько дата-центров в разных городах. Геораспределенная репликация. Автоматическое восстановление после сбоев. Канареечные релизы. Команда SRE-инженеров, которые 24/7 смотрят в дашборды. Это стоит как чугунный мост.

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

Вы все еще хотите поговорить о «видах» доступности? Это не виды. Это ценники.

Перестаньте гоняться за девятками, как за покемонами. Вместо этого задайте себе и бизнесу один-единственный вопрос:

Сколько денег мы теряем за каждую минуту простоя нашего сервиса?

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

Доступность - это не технология. Это экономика. И тот, кто этого не понимает, обречен платить за свои амбиции из кармана компании.

#этобаза

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

👋И под конец недели еще одна заметка про CAP. На очередном «архитектурном комитете» какой-то юный гений выдал: «Для этого сервиса мы можем пожертвовать Partition Tolerance, потому что он будет работать в одной приватной сети».

В этот момент я понял, что в IT-индустрии победила не наука, а маркетинг.😡

Слушайте сюда, дети. Запомните раз и навсегда. Partition Tolerance (P) - это не опция в вашем конфиге. Это не то, что вы выбираете, как соус к картошке. Это не компромисс.

P - это гравитация. Она просто есть. Она неизбежна.💩

CAP-теорема - это не выбор из трех опций C, A и P. Это констатация факта: когда случается P (а он случится), вам придется выбирать между C и A. P - это не переменная, это условие задачи.

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

🔥Классический разрыв. Нож и кабель.

Самый тупой и понятный вид раздела. Экскаватор порвал оптоволокно между дата-центрами. Сгорел свитч. Администратор случайно выдернул не тот кабель. Ваши серверы в ДЦ1 больше не видят серверы в ДЦ2. Все честно, все понятно. Сеть либо есть, либо ее нет.

Когда готовиться: Всегда. Если у вас больше одного сервера. Это гигиенический минимум.

🔥Болото, а не обрыв. Медленная сеть.

Вот тут начинается настоящий ад. Сеть не упала. Она просто стала медленной. Пакеты теряются, ходят с дикими задержками. Ваш сервис посылает запрос другому, не получает ответа за 500 миллисекунд и считает, что тот умер (timeout). А тот сервис живой! Просто ответ застрял в пути. Система начинает сходить с ума, потому что она не может отличить мертвый узел от просто очень медленного.

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

🔥Узел-зомби. Процесс, а не машина.

Самый коварный вид раздела. Машина работает. Пингуется. Сеть в порядке. Но процесс, который должен отвечать на запросы, завис. Ушел в бесконечный цикл, словил deadlock или, мое любимое, ушел в long GC pause на 30 секунд. Для остальной системы этот узел - мертв. Он не отвечает. Произошел раздел, хотя физически все компоненты на месте и связаны.

Когда готовиться: Если вы пишете на языках с автоматической сборкой мусора (Java, Go, C#) или используете сложный софт, который может деградировать под нагрузкой.

Так что прекратите нести этот бред про «отказ от P». Это невозможно. Вместо того чтобы задавать идиотские вопросы про «виды P», начните задавать правильные:

🍄Как мы обнаруживаем раздел? Через какие таймауты? Как мы отличаем сбой от медленной работы?
🍄Что мы делаем, когда обнаружили раздел? Переключаемся в режим read-only? Отдаем старые данные? Показываем пользователю ошибку?
🍄Как мы «склеиваем» систему обратно, когда сеть восстановилась? Как мы решаем конфликты данных, которые возникли в разных частях системы, пока они жили своей жизнью?

Partition Tolerance - это не выбор. Это ваша работа. Ваша система надежна ровно настолько, насколько надежен ваш план на случай этого самого 'P'. А если у вас его нет - у вас нет и распределенной системы. У вас просто куча компьютеров, которые ждут удобного момента, чтобы вас подставить.

#этобаза

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

👋Меня тут HR поймал у кофе-машины. С сияющей улыбкой сообщил, что они запускают «корпоративный университет» с «индивидуальными траекториями развития» и «геймификацией». 👀

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

🙄Давайте я вам открою страшную тайну. Компания не должна вас учить и точка. Ее задача - зарабатывать деньги, а не выдавать вам дипломы, с которыми вы потом побежите к конкуренту за дополнительные денежные бонусы. Вся эта возня с «обучением» - в 90% случаев симуляция бурной деятельности и попытка HR-отдела доказать свою полезность.

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

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

Спасение утопающих - дело рук самих утопающих. Всегда так было и будет. Рынок меняется, технологии устаревают. Если вы сами не тратите свои вечера и выходные, чтобы оставаться в форме, вы - сбитый летчик. Никакой «корпоративный университет» вас не спасет.

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

Она не курсы вам покупает. Она ставит перед вами задачи, от которых хочется выть на луну. Задачи, для которых нет готовых ответов на Stack Overflow. Она бросает вас в кипящий котел легаси-кода и говорит: «Разберись». Она дает вам ответственность за кусок продукта и заставляет вас принимать решения, цена которых - реальные деньги.

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

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

💩Первое - это болото легаси. Когда вы сидите с Java 8. Любая задача — это боль. Никаких новых технологий, никакого простора для маневра. Вам скучно и вы считаете, что деградируете.

💩Второе - стена бюрократии. Вы приходите с идеей, а в ответ слышите: «Нам надо согласовать это с отделом безопасности, с архитектурным комитетом и с тетей Глашей из бухгалтерии». И ваша инициатива тонет в болоте корпоративных процедур. Поздравляю, вы работаете в корпорации.

И если компания - это болото и стена одновременно, то давайте без соплей, у вас ровно два пути.

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

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

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

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

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

Всем привет. 👋

Смотрю, мой последний пост про обучение разнесли по паре каналов. Спасибо, конечно, за трафик коллегам из @TrueTechArch и канала @mialinist.

И, судя по комментариям, не все поняли что хотел сказать автор.

Давайте еще раз, для тех, кто в танке, медленно и по слогам. Тема многогранная, так что для начала определимся с терминами.

Есть два типа «обучения». И вы их постоянно путаете.

🔥Тип первый: «Промывка мозгов» под видом развития.
Это когда компания учит вас своим внутренним процессам, фреймворкам, продуктам. DocHub в Сбере, какой-нибудь проприетарный ETL-инструмент в банке, хитрая админка интернет-магазина.

Вы должны понимать: это не ваше обучение. Это инвестиция компании в свое будущее, а не в ваше. Она делает из вас ходячий мануал к своему кастомному велосипеду. Это знание абсолютно неконвертируемо. Как только вы уволитесь, оно превращается в тыкву. Вы не сможете прийти на рынок и сказать: «Я эксперт по внутренней CRM "Рога и Копыта", платите мне в два раза больше». На вас посмотрят как на идиота.

Вы становитесь носителем информации, полезной только одной-единственной конторе. Это не делает вас дороже. Это делает вас удобнее. Правда только для них.

🔥Тип второй: Обучение, за которое платит рынок.
Это знание фундаментальных технологий и подходов. Kubernetes, Go, Rust, системный дизайн, теория ограничений. Это то, что вы можете вписать в резюме и получить +30% к офферу в любой другой компании.

А теперь включите голову и ответьте на один вопрос: с какого перепугу компания должна оплачивать вам ваш будущий побег к конкуренту?

Facebook не «учил» мир ReactJS из доброты душевной. Они создали стандарт, выкинули его в опенсорс и получили бесконечный рынок специалистов, которые сами себя подготовили за чужой счет. Это гениальный ход, а не благотворительность. И они не одни такие.

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

А первый тип - это не обучение. Часто это технологическое сектантство. Вас заставляют поверить в уникальность и незаменимость внутренних инструментов, чтобы вы боялись смотреть по сторонам.😳

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

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

Перестаньте искать компанию-няньку. Ищите компанию, которая даст вам реальные, сложные задачи. Только так и растут. Все остальное - иллюзия.

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

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

👋Наткнулся на крик души: системные аналитики не нужны. Мужик прав, но не видит корня проблемы.

Настоящая болезнь - расчленение инженера.

Раньше инженер говорил с бизнесом, проектировал и кодил. Он был цельным. Отвечал за результат от начала до конца. А потом мы решили его распилить на куски.

🍄Аналитик - это «эксперт по месту разреза», если уходить в медицинскую терминологию, который никогда не держал скальпель. Человек-диктофон. Человек-переводчик, который часто не знает ни одного из языков, с которых пытается переводить. Прокладка, генерирующая шум и сломанный телефон.

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

Хотя кто-то скажет: "Разделение ролей = разделение ответственности: это не баг, а фича"💩

Знаете «хорошего аналитика»? Скорее всего, это будущий продакт или архитектор, который по ошибке носит этот шильдик. Исключение, подтверждающее дебильность правила.

А кто сшивает этого Франкенштейна? Архитектор. Единственный, кто еще помнит, как выглядит целая машина.🙄

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

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

👋Опять позвали на «аудит».

Картина маслом: команда в огне, тикеты летают, CI/CD гудит без остановки. Продуктивность, мать ее.

Только вот продукт еле дышит.

Хватит читать статьи про Agile. Возьмите старую книгу «Цель» Голдратта. Да, она про завод, но там больше правды о вашей работе чем в этих модных книгах про Agile. 💯

Запомните раз и навсегда: результат всей вашей команды равен производительности самого медленного ее звена и точка.

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

Так что хватит этой имитации. Вот вам план:

- Найдите одно узкое место. Человек, система, процесс - неважно.

- Заставьте его работать на 100% полезной мощности. Защитите от всего.

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

Перестаньте суетиться. Найдите то, что вас реально тормозит, и убейте это. Все остальное - пустая трата времени и денег.

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

#интересное

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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