Привет! 🤚

Месяц назад мы частью команды Ruby-платформы Купера собрались в Московском офисе, чтобы вместе поработать над изучением проблемы OSS реализации GRPC-сервера для Ruby, которую мы используем.

🎬 И сняли из этого реалити-шоу, в стиле "один день из жизни..." 


За день получилось:

 - обсудить разные варианты и подходы к решению
 - собрать их "на коленке"
 - провести нагрузочное тестирование
 - сравнить результаты
 - выложить исследования на Github
- и сходить на обед с коллегами 🙂

А еще договорились онлайн с руководителем отдела о выкатке в фикса в продакшен.


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

Приглашаю к просмотру на Youtube 🍿 и жду ваших преложений и комментариев!

🖖 Рубрика "Что почитать технарю".

Неделю назад дочитал художественную книгу Нила Стивенсона "Криптономикон". И пребываю в полном восторге, отчего хочу порекомендовать подписчикам!

Представьте, если бы Квентин Тарантино написал фантастический визионерский экшен-роман на основе исторических событий второй мировой войны, фокусируя внимание на завинчивающейся спирали противостояния и развития криптографии (шифровальная машина "Энигма") и криптоанализа (дешифровка сообщений), проводя параллели с современностью (1999 год), в которой увлеченные криптографией потомки участников войны строят IT-стартап в духе "Цифровой рай". Технические моменты автор поясняет мастерски вплетенными в повествования графиками и схемами.

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

🧑‍💻Эта книга от технаря, о технарях и для технарей!
Перед тем, как решится на ~1000-страничное чтиво, рекомендую статью-обзор книги на Хабре.

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

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

#Reading #NonTechnical

На прошлой неделе посетил конференцию RustCon.

Язык Rust для меня - хобби. Мне нравится новизна заложенных концепций (ownership, borrowing). Местами он похож на Ruby (еще больше на C, который я учил студентом).

💡Внутри популярных Ruby-библиотек часто скрывается код, написанный на C. В основном это специфические гемы для решения определенных задач:
- эффективные структуры данных (murmurhash)
- профилировщики и дебаггеры (stack-prof, byebug, ruby/debug)
- cpu-bound задачи: парсинг, сериализация (pg_query, nokogiri, oj, json, puma (парсинг http1.1))
- шифрование и криптография (bcrypt, digest-crc, xxhash)
- функциональные биндинги к С-библиотекам (karafka-rdkafka, grpc)
- низкоуровневые библиотеки, базирующиеся на системных вызовах (semian)
- клиенты для бд (pg, mysql2)

😡С появлением Rust - некоторые низкоуровневые вещи начинают писать на нем. Я провел небольшое исследование зависимостей Ruby-монолитов в Купере. Итоги:
- ~450 зависимостей
- 34 - используют под капотом С
- 3 - используют Rust (prometheus-client-mmap, pact-ffi)

Дополнительно в Ruby-экосистеме есть:
- packs - аналог фреймворка модуляризации Packwerk
- artichoke - альтернативная MRI-совместимая имплементация Ruby
- поддержака создания ruby-гема с Rust-кодом (статья)


Пока не выглядит как тренд замещения внутренностей Ruby-гемов кодом на Rust, но лед тронулся!

На эту тему на конференции был классный доклад, о переводе cpu-bound задач c Python на Rust, где автору местами удалось достигнуть ускорения x3 (пока доступны только слайды).

Пару кварталов назад наша команда занималась декомпозицией API.

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

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

При этом поддержка совместимости API со старыми клиентами выглядит как тех. долг, который на мой взгляд разумно вынести на BFF (backend for frontend), реализовав композицию новых энд-пойнтов для совместимости старых клиентов.
Это не очень типовой сценарий использования BFF, ведь обычно концепцию применяют для композиции API, а в случае в выделением сервисов - это декомпозиция (надо разобрать старый энд-пойнт на запчасти, каждая из которых получается из отдельного сервиса).

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

С таким фокусом на надежность, требовалось очень много бойлерплейт-кода, по манипулированию трафиком и расчетом метрик "совпания/точности" (о которых я рассказывал в статье). Поэтому коробочное решение нам не подходило (в индустрии используется Krakend). И мы приняли решения писать композицию вручную.

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

Получилось удобно: более гибко, чем конфигурировать композицию в манифесте (например в Krakend), но при этом достаточно стандартизованно, чтобы строить унифицированные метрики композиции.

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

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

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

🙄О полученном опыте расскажу в след посте, но прошу Вас в комментарии выбрать, что более Вам более интересно:
1️⃣каким принципами нужно руководствоваться, чтобы композиция не превратилась в ад
2️⃣подробней, почему решили делать самописное на первом этапе и какие нюансы
3️⃣как и за счет чего композиция позволила ускорить эндпойнты в x3

Привет! Прочитал и рекомендую книгу "Изучаем OpenTelemetry: современный мониторинг систем" (далее OT - OpenTelemetry). Особенно, если:
- вы планируете работать над развитием наблюдаемости в своих сервисах
- вы занимаетесь разработкой библиотек
- занимаетесь платформенной разработкой и стандартизацией
- проектируете инфраструктуру под сбор телеметрических данных
- или в вашей компании поддерживается несколько несвязанных друг с другом инструментов (для сбора метрик/логов/трейсов/ошибок и тд), например Sentry vs OpenTracing

Отмечу несколько моментов, которые меня заинтересовали:

1️⃣Авторы рассказывают о концепциях современной телеметрии, как и куда развивается стандарт OpenTelemetry и для чего он нужен. Для меня откровением стала масштабность решения. К примеру, OpenTelemetry заточен не только под сбор трейсов (раньше это был OpenTracing), стандарт гибкий позволяет в перспективе перейти на сбор метрик и логов одинаковым способом. Это определенное новшество, ведь обычно это делается по-разному. Делать по разному визионеры OT называют "текущим положением дел", намекая, что мы уйдем от этого 😄

2️⃣Авторы описывают архитектуру сбора телеметрии (трейсы, логи, метрики), точнее сказать возможные варианты архитектур, которые можно построить на базе стандарта (OT Collector). Стандартизации протокола с коллектором (приемник метрик) позволяет строить различные пайплайны сбора, фильтрации и агрегации данных.

3️⃣Отдельная глава посвящена инструментированию (организации сбора телеметрии из кода) библиотек и приложений, и как его лучше готовить. Авторы сетуют на пока еще небольшой процент поддержки OSS-библиотеками OT.
Как один из разработчиков общего платформенного тулинга - подтверждаю, и платформе приходится посполнять этот пробел.

Авторы (они же и участники движения OT) делают огромную работу, чтобы привести большинство библиотек базовых OT-библиотек разных стеков к общему знаменателю (к примеру, унифицированные настройки через одинаковые ENV-переменные).


💡Я раньше считал, что наблюдаемость библиотеки - это дополнительная фича, которую стоит реализовать в отдельно, заложив возможность расширения поведения, например, через механизм Middleware (промежуточный слой). На деле же рекомендуется делать сбор трейсов нативно, прямо из кода библиотеки. Именно для этого вся OT-инструментация во всех стеках при подключении не активириется по-дефолту (это тоже стандарт). Такой подход снимает массу проблем (зависимости, неактуальности, изменения, актуализация).

4️⃣Отдельная глава посвящена демонстрационной системе, состоящей из нескольких сервисов, иллюстрирующей OT в действии. Запустив все в докере одной командой - можно поэкспериментировать с телеметрией, посмотреть дэшобрды с метриками, логами и трейсами, а так же комбинацией фича-флагов симулировать внештаную ситуацию в системе, чтобы понять как наблюдаемость помогает ее отобразить.

За OT однозначно будущее, потому что:
- системы становятся сложней и нужна интроспекция, чтобы понимать как все работает
- повсеместно используются различные приложения/сервисы/форматы. OT призвана стандартизовать формат. К примеру, Sentry уже поддерживает OT
- при этом стандарт не накладывает органичений на способы применения телеметрии, а скорее помогает. К примему, вы возможно захотите использовать ML для выявления коллеряций и прогнозирования. Или строить архитектурные диаграммы, соответствующие продакшену. Стандарт здесь помогает

⁉️Поделитесь в комментариях опытом работы с телеметрией/трейсингом, как у вас в компании обстоят дела, какие есть сложности, или кейсы когда телеметрия выручала 🙏

🖐 Всем привет! Давно не виделись!

Я без познавательного контента. Зато с вакантным билетом на конференцию Let's GoConf, которая состоится уже скоро - 12 сентября 2025.

Не сочтите за рекламу - мы его сейчас разыграем!

Билет получит первый, кто расскажет в комментарии курьезный случай из свой практики разработки на Golang, что-нибудь с пустым интерфейсом, забытым замыканием или неправильными использование каналов (тут я не помощник - вы сами все знаете! 😉), и как это заафектило продакшен!


А если курьезов не было - то есть просто скидка 20% на билеты по промокоду salakhutdinov!

Работа клеем (being glue/glue work)

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

В статье "Being Glue" Таня Рейли дала такой работе название "glue work" - "работать клеем".

Это малозаметная,работа на стыке: людей и архитектур, команд и процессов, бизнеса и технологий, которая скрепляет команду и проектную работу воедино. Она важна хотя бы потому, что:
1️⃣ любой крупный проект требует координации множества людей. Без "клеевой" работы проекты распадаются на изолированные части, не стыкующиеся друг с другом (работа клеем неизбежна)
2️⃣ это эффективный способ масштабировать работу. К примеру, Вы провели звонок и устранили блокер для дальнейшей работы. ЭТо позволило целой группе инженеров работать продуктивно (force multiplication)
3️⃣взяв организационные и коммуникационные преграды на себя, вы позволяете другим инженерам войти в состояние «потока» и сосредоточиться на сложной технической работе, создав для них возможность войти в поток (creating flow)

⁉️Автор настаивает, что это не "менеджмент на минималках", а полноценная инженерная дисциплина, требующая глубоких технических знаний для принятия верных решений. Являсь необходимой частью успеха любого проекта, "работа клеем" зачастую остается незамеченной и не оцененной, не фиксируется как "приносимая результат", не используется на перформанс-ревью как аргумент.

Парадокс в том, что хороший исполнитель подобной работы рискует попасть в ловушку (the glue trap) - навсегда стать закрепленным за этой ролью. Менеджмент воспринимает его как "человека, решаюшего проблемы" (как Мистер Вульф из Криминального Чтива), и всю такую работу автоматически делегируют ему. Отчего инженер перестает заниматься глубокой инженерной работой (deep technical work), теряет навыки и техническую экспертизу, а вместе с ней — и свой авторитет, который и позволял ему эффективно заниматься клеевой работой.

Чтобы разорвать этот порочный круг, автор рекомендует

❓Инженерам:
- вести свой дневник клеевой работы (glue journal), фиксировать что сделано и на что повлияло. Дневник превратит невидимую работу в видимую, поможет представить ее прозрачной и понятной. На эту есть классный доклад.
- частично делегировать работу клеем мидлам, чтобы развивать их и не концентрировать скилл решения проблем в одних руках и разгрузить себя
- не позволять работе клеем занять все ваше время - стоит резервировать время под грубокую инженерную работу в том числе
- приоритезировать, а не просто реагировать на все подряд. Спросить себя "Какая деятельность максимально приблизит нас к стратегическим целям?"

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

Далее в своей книге (The Staff Engineer's Path), Таня приходит к выводу, что это не случайная дополнительная нагрузка, а основной инструмент воздействия staff-инженера. А ключ к успеху - управлять ею стратегически, делая видимой и обеспечивая баланс с технической работой, не попадая в ловушку. А не проcто ее делать 🤔

Что думаете о работе клеем? Часто ее делаете? Фиксируете где-то? Как повышаете ее прозрачность? Расскажите в комментариях 🙏

Привет! 🤚Давно ничего не писал. Но знаю - вы соскучились по простым житейскийм постам. Не про AI, не про SDLC и не про то, как всё быстро меняется. А про то, что не меняется.

После недавнего 1:1 с руководителем в очередной раз вышел на неприложные истинк: высокий уровень влияния стафф-инженера на все вокруг? Я открыл любимый справочник по теме - книгу Тани Рейли . Там влияние разложено на три уровня:
1️⃣Индивидуальный: вы влияете на свою работу, 1:1, свой код.
2️⃣ Групповой: вы обучаете команду, меняете процессы внутри неё.
3️⃣ Каталитический: масштаб и прямое участие масштабируется.

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

Очень абстрактно? Давайте на практике:
🔹 MSA-трансформация. Никто в компании не знает (или не успевает) правильно декомпозировать большое приложение в MSA. Вы прорабатываете план, реализуете пилот с командой, фиксируете методологию, описываете процесс. Другие команды начинают идти по вашему шаблону. Вы уже не участвуете, но эффект размножается.
🔹 OSS и стандарты. В индустрии все решают одну задачу по-своему. Вы упаковываете своё решение в библиотеку, публикуете, доводите до стабильности (уровень 2). Вы формулируете единый стандарт, который объединяет разрозненные решения (яркий пример, OpenTelemetry). Уровни могут сливаться, но вектор один: вы создаёте инфраструктуру для других.
🔹 Кросс-функциональные проблемы. В отделе А есть болевая точка, но решить её может только кооперация команд А + Б + В. Работа не начинается. Вы формулируете проблему, измеряете масштаб, декомпозируете задачи, находите стопор и снимаете его. Запускаете совместную работу. Потом автоматизируете рутину так, что аналогичные задачи решаются без привлечения Б и В, а инструментарий несёте в массы (платформенный подход)
🔹 Тут должен быть пример, как вы перестроили структуру компании под эффективное использование AI, а не просто вайбкодите. Вот отличный пример.

📖 Как это выглядит в других сферах (по книге):
• Консультирование: вы делаете так, чтобы консультировать мог каждый, а процесс не требовал вашего участия.
• Карьера: вы создаёте среду и практики, в которых коллеги растут органически.
• Обучение: вы делаете материалы или форматы, которые живут и распространяются без вас (курсы, туториалы, внутренние/внешние конференции).

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

Идем индуктивно, от простого к сложному, не забывая про каталитический уровень:
1️⃣Делайте сами. Решайте, ковыряйте, получайте опыт.
2️⃣Упаковывайте. Делайте так, чтобы по вашей методичке это мог повторить коллега.
3️⃣Системизируйте. Делайте так, чтобы процесс работал без вашего участия.
4️⃣Свобождайтесь. С такими навыками вы всегда найдёте следующую проблему. Не цепляйтесь за успех – двигайтесь дальше.

Каталитическое влияние - сделать себя ненужным в точках, которые вы уже разобрали.
А у вас есть примеры, когда ваше решение "отработало и ушло в тень"? Делитесь в комментариях 👇

Привет!

📣Разыгрываем 1 билет на Let`s Go Conf, которая пройдет 11 сентября в Москве!
Программа интересная:
- хардкорные доклады по Go
- круглый стол про разрботку с AI
- Golang-мозгобойня 🤔

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

Летс go! 🚀

Всем Привет 🤚

📣 17 октября планирую выступить на конференции HardFest в столице родного Урала - Екатеринбурге.
Если вдруг окажетесь там - буду рад встретится 🤗

Мой доклад - обощение опыта построения online/inference feature-стора и миграции множества ML-сервисов на него. Этим в RWB я занимаюсь без малого год (после перехода из Купера).

Любопытно, что под фиче-стором в индустрии понимают разное: от фасада для доступа к данным (красивая крыша на прохудившиеся стены) до большой развеститой системы оркестрации дата-пайплайнов (идеальный замок, на построение которого уйдут годы). И сложности начинаются уже с разночтения и предубеждений, какие проблемы призван решить новый технологический франкенштейн. На стыке разработки, эксплуатации, data-инженерии и ML/DS (гремучая смесь компетенций, согласны?).

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

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

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

Вот и спойлера конец, еще увидимся!