Про клиентские метрики.

В рамках backend-разработки клиентские метрики - это метрики запросов из сервиса А в сервис Б, когда со стороны сервиса А измеряются RPS, latency, error rate и тд и тп по всем вашим интеграциям как с внутренними сервисами/системами компании, так и с внешними, с которыми вы, например, взаимодействуете по интернету.

Для внешних интеграций это актуально по множеству причин, начиная с банального, что нельзя слепо доверять тому, что вам говорят ваши партнёры, и заканчивая тем, что между вами могут быть firewall и прочие слои ИБ-инструментов, которые точно будут влиять на скорость ответа между вами, при этом сам партнёр об этом может не знать. Он предоставит вам данные о метриках со своего сервиса «в кубе» или чуть-чуть выше, но о том, что где-то ещё сильно-сильно выше стоит какой-нибудь WAF, он может не подозревать. Актуально для IT-гигантов, где тысячи инженеров, сотни команд, десятки отделов и передача верной информации затруднительна из-за эффекта сломанного телефона.

Для внутренних интеграций, например, в случае взаимодействия внутри куба, это позволяет оценить "здоровье" вашей внутренней сети. Если между вами только внутренняя локальная сеть, то время на транспорт должно занимать не более условных 3-5 ms.

На скрине (latency 99p) я наложил "клиентские метрики", как сервис A видит запросы в сервис B, на "серверные метрики", которые собирает сам сервис B по этим же запросам c самого себя.

Жёваный крот! Щука, брат!

Можно ли ругаться матом на работе? Хочется сразу ответить категорически "нет", но на деле всё не так просто. Почему мы вообще ругаемся матом? В критических ситуациях только мат (к сожалению) может передать всю глубину и сложность проблемы и/или ситуации, с которой мы столкнулись.

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

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

Вариант 2
Ёлки-палки, уже 30 минут ни черта не работает. Что за ерунда?

Вариант 3 (осторожно мат)
Какого хрена у нас сайт лежит? Где все?

1-й и 3-й варианты крайности, которые неуместны. 2-й вариант наверное, какая-то золотая середина, но он всё равно ни разу не передаёт всю глубину и проблематику ситуации. Что делать?

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

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

P.S.: я так и не понял, как правильно, "жеваный" или "жованый", вроде как "жеваный", но все мемасы через "о".

Как назвать?

В Магнит в 2021 году я разработал (возможно, откуда-то и скопировал, но уже не помню) свой паттерн именования каналов в корпоративном мессенджере. Тогда это был MS Teams, но это не столь важно. Знаю, что этот подход до сих пор используется в Магнит OMNI с некоторыми вариациями. В ЗЯ я его немного доработал, вот что в итоге получилось.

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

Всё базируется на префиксах team, tool, guild, release, support, proj, recruit и постфиксах qna, news.

Итак:
• team-<team_name>-<theme>, например team-main-qna, team-fs-news. qna - в данном случае это "приёмная" команды, куда может обратиться кто угодно с любым вопросом извне. news - это соответственно, канал новостей команды, которые команда может транслировать вовне, например о запуске какой-то крупной и важной фичи. Зачастую хватает только канала qna.
- guild-<guild_name>-<theme>, например guild-ios-qna. Тут всё аналогично team.
- tool-<tool_name>-<theme>, например tool-mattermost-qna, tool-mattermost-news.
- proj-<project_name>, например proj-new-search или proj-tips. proj - префикс, отражающий крупный проект/фичу, которая затрагивает множество команд где им нужно синхронизировать общие вопросы и сроки.
• release-<mobile|web> - каналы релизов МП и веба.
• recruit-<theme> - каналы про найм, например recruit-android или recruit-net.

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

Про 360 и оценку сотрудников.

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

При оценке сотрудников в формате 360 "школьный подход" часто приводит к конфликту восприятия, тк в нашей работе невозможно постоянно быть отличником. Задачи разные, контекст меняется, а результат зависит не только от усилий конкретного человека. Поэтому 3 - это нормальный, те ожидаемый результат. И это НОРМАЛЬНО!

Мое воспринятие:
1 - значительно ниже ожиданий. Провал, требуется срочного исправление.
2 - ниже ожиданий. Немного не дотянул до нормы.
3 - соответствует ожиданиям. Уверенная норма, те все ОК.
4 - выше ожиданий. Заметно лучше требуемого уровня.
5 - выдающийся, редкий результат. Уровень Rockstar.

Про офис для руководителя.

Пока вокруг все говорят про внедрение ИИ, про удалёнку, про распределённые команды, про метрики и т. д. и т. п., хочется вернуться во времена, когда мы просто приходили в офис, завтракали на кухне, потом садились за общий стол на 3–4 человека и вместе работали. Без созвонов, встреч и календаря.

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

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

Было же время!

P.S.: картинка отсюда.

Пост про бардак.

Я глубоко уверен, что первопричиной большого количества проблем в современном IT (и не только) является простой бардак. Попробую, попытаюсь объяснить.

Начнём издалека, с некоторой аллегории. Представьте, что к вам подходит ваш ребёнок и просит помочь собрать пазл из LEGO. Вы, конечно же, готовы помочь. Идёте в комнату, а там бардак. Игрушки разбросаны, кровать не убрана, одежда валяется на полу и тд и тп. Можно ли в такой комнате собрать LEGO на фоне бардака? Наверное, да, но хочется сначала навести порядок, а уже потом собирать LEGO.

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

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

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

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

Про оценку настроения/cчастья команды.

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

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

Я не знаю, как правильно, я лишь помню, как это было на одном из мест моей работы. Бот стучался к тебе в личку каждый день ближе к концу рабочего дня и просил оценить твой день по шкале bad/hard/neutral/good/excellent и, опционально, оставить комментарий. В итоге ты как менеджер видел анонимную среднюю оценку настроения своей команды каждый день в динамике, с историческими данными, и мог понять, как и какие события тем или иным образом на нее влияют.

У меня, к сожалению, не осталось пруфов (скриншотов), как это выглядело, но те, кто со мной работал тогда, помнят этот сервис TeamMood. Кажется, что спустя многие годы ничего такого же простого и удобного не появилось.

"Письмо" в редакцию.

Ниже текст не обиженного луддита, настальгирующего по good old days - а скорее анализ происходящего и попытка трезво принять будущее.

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

В Software Engineering всегда было разделение на «художников» и «маляров». Художники творят Linux, Redis, Python. Маляры решают прикладные задачи перематывая всё это изолентой. Спрос на вторых рос десятилетиями, но сейчас приходит смерть профессии в ее привычном виде, ака демократизация малярного дела.

Все мои знания аргументов grep, параметров gunicorn или трюков оптимизации Docker-образов больше не нужны (даже мне так то!). Даже хитровыебанные знания, вроде паттернов проектирования или систем дизайна. LLM в них компетентнее. Когда я получаю от нейронки снисходительное «You are absolutely right», мы оба знаем: это просто вежливая лесть за уплоченны токены.

Мы поднимаемся на новый уровень абстракции, где становится неважно, *как это сделано*. Нам же плевать на регистры и сдвиги в ассемблере? Теперь этот подход добрался до нашего “высокоуровневого” кода,

Я вижу это на ревью: прилетает PR на 1000 строк нового кода в репозиторий, где всего их 3000. Там всё ок: тесты, документация, структура.
• Да, можно это сделать проще через стороннюю библиотеку - так уж вышло что я это знаю.
• Да, это стоило бы разбить на пять мелких PR, чтобы я не сошел с ума это всё ревьюить.

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

Так уж вышло что последние 10 или сколько там лет я практиковался именно в “как”. Как сделать код поддерживаемы, безопасным. Как побить на зависимости и сделать общие части переиспользуемыми. Как сделать красиво - ну это самый кайф в нашем достаточно скучном корпаротивном болоте. Теперь этот навык превращается в избыточную нагрузку для бизнеса – хотя wait a second, it always been.

Про настоящий gamechanger от AI.

Что действительно может быть сделано на основе AI, что драматически перевернёт весь мир? Создание полнометражного фильма уровня Голливуда одним человеком? Создание новой игры типа GTA7 одним человеком? Нет. Это, конечно, сильно поломает текущие индустрии развлечений, но всё же нет.

Если вы читали или смотрели экранизацию книги «Автостопом по галактике», то там была рыбка, которая позволяла главному герою понимать любую речь в галактике. Вот оно. Уже сейчас есть Neuralink. Если его как-то скрестить с AI и позволить работать как эта рыбка, то вот он геймченджер. Не надо больше учить никакие языки. Вы понимаете всё, что слышите, и вас также понимает любой слушатель. Мир радикально изменится, так как обмен любой информацией с любым человеком на Земле больше не будет иметь никаких преград.

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

Про успешный успех.

Недавно слушал свежий выпуск подкаста безвотэтоговотвсего с CTO flowwow.

Я не знаю, это какие-то особенности бьюти-рынка или рынка услуг, но flowwow очень близок к ЗЯ в вопросе подготовки к 8 марта и той нагрузки, которая приходит на наши сервисы в этот день. В подкасте было сказано про рост x30, в чём-то автор прав.

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

Спасибо всей команде! Молодцы!

С AI работа стала еще более асинхронной.

Но по факту я хотел заставить агента немного поработать в выходной, не себя 😁

Лет 15–20 назад была популярна шутка "Мой код компилируется". Можно было написать пару строчек кода, нажать Build и пойти пить чай. Всё циклично, и сейчас мы вернулись к похожей ситуации, только уже в формате "Я жду ответа от своего AI-агента". Конечно, время ожидания отличается, но суть очень похожа.

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

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

Про первый AI skill

Написал свой первый AI скилл. Суть простая. На вход передаёшь агенту путь до исходников на локальном диске, а на выходе получаешь C4 L1/L2 архитектуру и sequence-диаграммы их взаимодействия между собой в формате .md файла. Если подключены плагины к Notion или Miro, потом можно попросить загрузить результаты туда.

На github много похожих скилов, но свой велосипед всегда приятнее ;)