#манагерское

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

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

Как продакту, мне интересно делать идеальные продукты с совершенным UX и мегафичами, кастдевить пользователей и получать восторженный фидбек. И чтобы все было аналитикой обвешано - тестить дерзкие гипотезы и дизраптить рынок. Потому что это мегакруто. Правда еще выручку растить нужно, и чтобы экономика сходилась, иначе инвесторы денег не дадут. А тут эти технари с нытьем про техдолг и костыли.

Как предприниматель (у мен одного ощущение, что слово “бизнесмен” сейчас воспринимают как пошлый атавизм из 90х?) в гробу я видал всю эту вашу итшечку и смузи-фичи. Каждое утро я просыпаюсь и думаю, как бы вообще ничего не делать и побольше заработать. Вчера продал пару новых проектов крупным партнерам и собрал концепт нового стратегического направления. Нужно быстро запустить все за пару недель, максимум месяц. В смысле, какой проект важнее? Все важно, они издеваются что ли?! Даже сроки внятные назвать не могут.

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

#архитектура

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

Например, CAP-PACELC теорема. Она рассматривает синхронизацию между нодами хранилища и задает нам два простых вопроса:

— Если сбой, что важнее: консистентость или доступность?

— Если штатно, что важнее: консистентность или скорость отклика?

Круто, и что мне с этим делать? Я архитектуру кафки и постгри проектировать не собираюсь. Чтобы кто-то садился и задавался вопросом: “Какую же модель мне выбрать для сервиса заявок: CP или AP??” - тоже никогда не встречал. Тогда зачем мне это кроме шаблонных собесов?

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

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

Есть пара: процессинг заказов и платежный сервис, что критичнее
— консистетность или доступность?
— консистентность или время отклика?

А для пары процессинг заказов и бухгалтерия?

Из ответов следует выбор модели strong / eventually consistency. А из этого следует, как будем управлять распределенными транзакциями: оркестрация, хореография, воркфлоу и т.д. А из этого, где нам нужны будут ретраи с идемпотентностью, а где события будем кидать.

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

Часто фундаментальные концепции из computer science не дают конкретные рекомендации для локальных задач, но позволяют расширить сознание, чтобы более системно и целостно подходить к проектированию.

#архитектура

Выложили записи докладов с ArchDays’2024.

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

Работа Кафки просто и наглядно

Шикарная визуализация работы Кафки: https://softwaremill.com/kafka-visualisation

И менее шикарная, но тоже пригодится: https://evoura.com/kafka-traffic-visualizer

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

Разбираемся с основами, начинаем здесь:

1. Установите: 1 брокер, 1 консьюмер группа, 1 консьюмер, 2 партиции. Посмотрите, как сообщения распределяются между партициями.

2. Добавьте второго консьюмера в существующую группу. Посмотрите, как распределяются между ними сообщения.

3. Добавьте третьего консьюмера в существующую группу. Посмотрите, как распределяются между ними сообщения.

4. Перенесите третьего консьюмера в отдельную консьюмер группу. Сравните потребление сообщений в двух консьюмер группах.

Теперь понаблюдаем за работой с ключами, переключитесь сюда:

5. Установите 2 партиции, key range = 4. Посмотрите как сообщения с одинаковым ключом распределяются между партициями

6. Установите 3 партиции, потом 4.

7. Установите 6 партиций. Что изменилось? Почему так происходит?

Возвращаемся в основной симулятор:

8. Установите: 2 брокера, фактор репликации - 2, 1 консьюмер группа, 1 консьюмер. Посмотрите, где и как реплицируются партиции и сообщения.

9. Установите: 3 брокера, фактор репликации = 2. Посмотрите, как теперь работает репликация.

10. Установите: фактор репликации = 1. Посмотрите, как теперь работает репликация.

11. Установите: фактор репликации = 3. Обратите внимание, как распределяются между брокерами мастер-партиции (яркие) и их реплики (блеклые)

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

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

#брокеры

#брокеры

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

Нашелся репозиторий вида "все про интеграцию": технологии, паттерны, протоколы. Не знаю, как использовать, но может вам полезно будет: https://github.com/stn1slv/awesome-integration

#манагерское #книжное

Уже писал, что "требований" как вещи-в-себе не существует.

Ибо нет человека, который точно знает: если (не) сделать Х, то мы получим такой-то профит / урон. Бизнес всегда оперирует неопределенностью и вероятностями. Исключениями могут быть:

Заказная разработка
Подкладываем портянку "требований" к договору, по которому происходит оплата с приемкой. Спасает не всегда - с крупными клиентами можете остаться без денег или попасть в блеклист.

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

Что тогда приносят стейкхолдеры, продакты, бизнес-эксперты? Да что угодно: боли, хотелки, потребности, готовые решения, поток сознания - причем никогда не угадаешь, что они принесли в этот раз. Тогда что делать? Разбираться в людях и контексте.

Мне в этом плане нравится книга The Mom Test / Спросите вашу маму

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

Кому стоит прочитать:

 • Продакту и заказчику - чтобы понять контекст и проблемы клиентов / пользователей

 • Аналитику и тимлиду - чтобы понять, зачем эта фича нужна заказчику

 • Разрабу и QA - чтобы понять, зачем аналитик запихал этот метод в апи

 • Владельцу внутренней платформы типа ESB, CI/CD и т.п. - чтобы заранее планировать развитие ваших сервисов

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

#конференции

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

У меня все. Встречаемся завтра.

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

Забирайте и проходите, если еще не. Штука не только полезная, но и залипательная - успокаивает лучше рыбок.

Ультимативный гайд по софтам

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

1. Не давайте коммитов, пока полностью не поймете задачу. Если не понимаете - сообщите об этом и задайте вопросы.

2. Когда начинаете работать над задачей, дайте знать об этом заинтересованной стороне.

3. Если не можете взять задачу сразу или в оговоренные сроки - сразу сообщите об этом.

4. Если вы столкнулись с проблемой, и не можете ее решить - сообщите об этом.

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

6. Если понимаете, что не успеете в сроки - сообщите об этом сразу. Это никому не понравится, но отрулить будет на порядок проще, чем в последний момент.

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

8. Если на встрече у вас нет ответа на вопрос, так и скажите: пока не могу ответить, беру в работу. Буллшит-импровизации и попытки увильнуть видны почти всегда.

Поздравляю! Вы адекватнее ~83,57% людей на рынке.

#коммуникации #манагерское

#интеграция #API

Пережили конфу, в субботу начнем десятый поток курса по проектированию API.

С одной стороны, это Yet Another REST API Course для джунов-миддлов, чего вы там не видели? Люди знакомятся c HTTP, учатся делать типичный REST API, тестить и документировать сервиcы.

С другой - все чаще вижу на занятиях сеньоров и лидов. Зачем им это?

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

“Делать правильно” никому не нужно. Важно спроектировать API, которое не превратится через полгода в нечитаемое месиво, а под каждую доработку не нужно будет втыкать костыли на каждой стороне. Для этого мы разбираем уровни зрелости REST API, их границы применения, и когда стоит использовать RPC API.

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

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

Так что приходите за обязательной базой или расширением горизонтов. 5-23 апреля, рега тут.

План конференций на апрель:

— 11 апреля StormConf, о которой уже писал. Кто вживую собирается?

— 12-13 апреля Systems Design Online с большой секций по архитектуре

— 25 апреля DUMP в Екатеринбурге, буду рассказывать про API как продукт

— 26 апреля открытый Flow в олнайне, там вещаю про фейлы, которые собрали при проектировании этого API

Как бы еще везде успеть и выжить, пожалуйста.

Вот да

🔥 Снижай драматизм: уроки от Slack

Давайте сразу: проект провалился. Все, расходимся, жизнь кончена?! Да хрен там плавал!

Вот история Slack, который вырос из игры Glitch. Если по-простому: ребята несколько лет делали онлайн-игру, вбухали кучу денег и сил, но все никак. Игрушка не взлетела. Что, плакать и расходиться? Нет, они закрыли проект без лишних слез и заметили, что внутри команды круто работают их же внутренние чаты. И сделали пивот в корпоративный мессенджер. Теперь весь мир знает Slack.

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

Где логика в том, чтобы загонять команду в панику и драматически орать «мы горим!»? Это тупик, господа.

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

А у вас бывали пивоты в карьере или проекте, которые внезапно «выстреливали»?

Карьера продакта

Кто о чем, а мы о сисдизайне

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

Стрим с Филом Дельгядо о сисдизайне на интервью

Несколько тезисов:

— Секция сисдизайна не показывает, может ли человек проектировать системы в рамках своих задач - внезапно, да?

— Многие кандидаты приходят со знаниями из книг по интервью. Причем интервьюеры тоже.

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

— Единообразие и прозрачность обычно противоречат эффективности. В том числе в найме.

— Отдать найм в команды, может быть намного эффективнее, чем делать его централизованным.

В целом рекомендую его выступления - живое руководство по критическому мышлению.

А вот доклад Александра Поломодова, как и почему проводят сисдизай секции в ТБанке

#архитектура

#архитектура

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

Если конкретнее, мы берем реальные задачи из разных доменов и проходим весь путь проектирования решения: от выявления требований к декомпозиции системы на сервисы, выбору технологий, проектированию апи и модели данных. Никаких книжных ютубов, url-shortner’ов и key-value хранилищ, с которыми вы никогда в жизни не встретитесь.

Вот примеры некоторых кейсов: выпуск и доставка карты, умная лента заказов для маркетплейса, система A/B-тестов, риалтайм доска “миро-заменитель”.

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

Суббота, в 10:00 мск, рега тут

#оффтоп

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

Интересно, понимал ли автор, на сколько точно его фраза будет отражать реальность эпохи LLM?

У нас постепенно распространяется роль техпродакта, но пока нет единого мнения, что это за зверь. Поэтому сегодня делаем стрим с Леной Царьковой - техпродактом из Авито, в прошлом СА.

Сегодня в 19:00 мск, рега тут.

И думаю, он будет не последним.

#образование

Галлюцинации LLM - это не баг, а мега фича для образования.

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

Почему этот же паттерн не срабатывает при обучении у других людей?

Есть мировые авторитеты, условные Ричардсон, Ньюман, Фаулер, еще кто. У них большой опыт разработки, огромный в консалтинге, тысячи часов размышлений над темой. Значит ли, что их предпосылки и выводы всегда верны? Значит ли, что их опыт переносим в вашу сферу?

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

За ними идут эксперты с авторскими программами, где они напрямую делятся опытом. Но не такие известные в комьюнити. Значит ли, что их опыт “хуже”? Конечно, нет. Но и споров и челленджей со стороны комьюнити они могли пережить меньше. А могли больше.

Про школы с кураторами "от года", менторов-вкатнуов и прочих вспоминать не буду.

Интересно, как чОтко критическое мышление срабатывает на LLM, но отключается, если нам приглянулся образ или история человека. Если не доверяете глюкам AI - то обучение с ними может быть эффективнее и безопаснее, чем с людьми.

Галлюцинирую - значит, существуют

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

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

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

Примеры интересного:

— инфографика с основными способами интеграции

— чек-лист стандартов в области интеграции и API

— 10 техник проверки полноты требований

— скрытая работа по проектированию систем, которую выполняет системный аналитик

— применение ChatGPT в работе системного аналитика: раз и два

А еще недавно Юрий был у нас в гостях, обсуждали профессию, перспективы, тренды и много всякого.

#конференции

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

С какого-то момента междисциплинарные конференции стали куда интереснее за счет знакомства и общения с людьми из смежных ролей - их боли, проблемы, мысли дают куда больше инсайтов, чем очередной спич на профильной конфе. Поэтому если вы скучающий сеньористый сеньор, то попробуйте сгонять на подобное событие. Где еще вы будете обсуждать с ML-лидом использование ТРИЗ на собесах в 4 утра?

От себя выделю доклады:

 • Наталья Потемина - о противостоянии продукт vs коммерция-маркетинг. Рыдал, когда слушал, ибо вот прям все болячки из доклада собрали на последнем проекте.

 • Александра Брызгалова - еще один взгляд со стороны теории ограничений на “эффективность”, личную и командную. Что это такое, и почему больше и быстрее - не значит лучше.

 • Даниил Смирнов - как продакты убивают бизнес, или почему критично важно участвовать в продажах, если вы работаете в b2b.

Краткая мораль
Если вы избегаете продаж, то вы не продакт, а товаровед (с) Саша Брызгалова

Сам рассказывал о публичных API глазами продакта, в открытый доступ записи где-то через полгода выложат.

Спасибо DUMP и до встречи через год ❤‍🔥