Я не вижу ваших репостов! Поднимите ваши репосты выше! Давайте, давайте, оба ваших репоста!


Ладно, если серьёзно, покидайте, пожалуйста, друзьям go-шникам, плюсовикам и питонистам. Мы учим полиглотству. И космополитии немножко (международные офисы).

Как считать железо

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

Подготовка
Прежде, чем считать хоть что-то, нужно разработать API и подсчитать примерно количество запросов в это API (в запросах в секунду aka rps). Реализация не обязательна, но интерфейс — да. Нужно знать, какие будут точки входа в сервис, какие и какого размера данные они будут получать на вход и отдавать на выход.

Теперь думаем, сколько у нас примерно пользователей в день. Это примерно как считать количество настройщиков пианино в Чикаго. Думаем, сколько времени в день в среднем они будут пользоваться нашим сервисом. Из этих данных можно понять среднюю нагрузку (rps). Дальше правило большого пальца: в пиковый час будет нагрузка х2 от средней (или х2.5 по Бунину). Вы великолепны, у вас есть максимальный ожидаемый rps.

CPU
Начнём с самого сложного. И уже тут нужно примерно понимать, что будет в реализации: несколько random access в память или сплошные кэш хиты (походы по сети/в бд/на HDD или SSD считать нужно, как сисколы, потому что процессор вряд ли будет простаивать и ждать, пока ему ответят с внешних устройств). Очень примерно, очень грубо. Неправильно: 3 похода в память + чтение 137КБ с HDD. Правильно: ну там несколько сотен случайных походов в память, давай примерно 50мкс скажем.
Для каждой точки входа нужно понять, за сколько времени в среднем она будет отрабатывать.
Следим за руками: если наша функция отрабатывает в среднем за 10мс, то одно ядро за одну секунду (1000мс) может обработать максимум 100 запросов.
Теперь из подготовленных данных смотрим, сколько мы ожидаем rps в пиковой загрузке, делим в данном случае на 100 и получаем количество ядер. Ура!

RAM
Для баз данных или какого-нибудь машинного обучения стоит посмотреть на примерный размер юнита (датасет или средняя запись в базе) и умножить его на количество таких объектов. Потом надо заложить запаса на индексы, фрагментацию, кеши, копирования для промежуточной обработки, бэкапы. Здесь всё сильно зависит от вендора и реализации.
Если у вас не планируется in-memory кешей, масштабной мемоизации или каких-то особенных структур данных, то рост будет чаще всего суб-линейным. В типичном веб-сервисе данные очень активно переиспользуются между запросами, а потому не растут линейно с ростом rps. Довольно понятной, но грубой оценкой снизу можно считать rps*размер входящего сообщения (его надо десериализовать).
Но единственным более или менее надежным способом здесь является запуск приложения и замер (ну потому что очень уж много способов память отжать: mmap, IPC, частая аллокация и т.д.). И не забыть про RAM под нужды ОС!
Если вы знаете способ лучше — жду вас в комментариях! Я не нашёл.

Продолжаем считать железки. Теперь к переферии.

NETWORK
Тут всё несложно. У нас уже есть rps, размеры входящих и исходящих данных. Обычно, всякая мета типа хедеров сетевых протоколов пренебрежимо мала по сравнению с данными, поэтому можно дополнительно об этом не думать. Умножаем rps на размеры входящего и исходящего сообщений, получаем upload/download объёмы трафика. Дальше смотрим в таблицу красных резиновых мячей пропускных способностей сетевых карт и интерфейсов. Теперь мы можем понять, сколько нам нужно машин и с какими интерфейсами (10Gb Ethernet или 100Gb Ethernet или что-то ещё).

STORAGE
Если это не база данных или что-то подобное, то чаще всего здесь у нас будут только ОС, бинари приложения и логи. Зная rps и прикидывая, сколько примерно будем писать догов на один запрос, мы можем понять рейт записи логов (сколько байт в секунду). Тут можно уже выбрать железо (конкретные характеристики и количество), но обычно хватает самых простых конфигураций.
Дальше смотрим, как часто будем ротировать логи, понимаем, сколько максимально места нужно под это. Вот вам и число — объём диска. Если у вас там ещё всякие raid массивы, то нужно домножить на соответствующий мультипликатор.

А если база данных? То, во-первых, можно посмотреть в интернете, что там в вашей версии БД требуется, желательно и т.д. Базово вы отталкиваетесь от объёмов данных, которые планируете хранить, но нужно иметь в виду, что скорее всего вы захотите всякие индексы, а данные будут фрагментироваться — это всё тоже место, но зависит от конкретной базы.

Основная задача руководителя

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

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

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

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

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

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

Добавим сюда ещё стандартные замедляторы:
- переключения контекста от задачи к задаче
- потеря контекста из-за встреч, обеда, выходных, вопросов коллег
- откладывание и прокрастинация из-за непонятно поставленной задачи

И ещё куча разных факторов, которые тимлиды и руководители более высоких уровней постоянно мусолят на конференциях и в чатах.

По-существу, большая часть всех этих элементов включается в ёмкое понятие: планирование.

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

Поэтому основная задача руководителя: иметь план. Для команды и для себя. И чем дальше вперёд этот план есть, тем проще работать, проще что-то в нём менять, проще управлять рисками.

Алгоритмы мои, алгоритмики

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

Тем не менее! Скрести вилкой медленный код приходилось много, а с завистью читать о том, как скребут другие, ещё больше (у них, небось, тоже по полторы реальные истории, но всё равно завидно).

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

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

Какие есть улучшения? Самое известное — galloping binary search. Это гибрид линейного с бинарным. Мы топаем вперёд по степеням двойки, пока не перепрыгнем, а там уже линейный. Здесь всего один бранч миспредикшен и довольно неплохой префетч.

Что ещё? Ещё довольно популярное решение — B-tree. Это дерево поиска, у которого не два дочерних узла, а k. Можно подобрать k таким, чтобы полностью его выбирать, например, с одного блока HDD или, что для нас сейчас интереснее, чтобы k полностью занимал кеш-линию. Здесь, кажется, что с бранчами не радужно: ведь мы снова в ситуации 50/50. К тому же на каждой итерации (в каждом узле) добавляется подпроцедура поиска внутри узла. Но зато количество кеш-промахов минимальное!

Однако, вот в этой статье от то ли 2015, то ли 2017 года авторы нашли решение ещё лучше.

Многие знают, что бинарная куча очень хорошо ложится в массив. Причём так, что для каждого элемента, находящегося по индексу j, можно найти его потомков по индексам 2*j и 2*j+1.
Но мало кто знает, что можно точно так же уложить и бинарное дерево поиска!
Вот так можно сложить отсортированный массив чисел от 1 до 7:
4261357

Такая укладка носит имя Eytzinger, в честь изобретателя.
Теперь следите за руками. Очень хитрый хак. Мы топаем по индексам (2*j, если число меньше либо равно искомого; 2*j+1 в противном случае), пока не вылезем за границы массива. Так как все походы в левое поддерево — удвоения индекса, то по сути весь путь зашифрован в двоичном представлении получившегося индекса. Поэтому, нам нужно отрезать все последние походы в правое поддерево и мы получим искомый индекс. Это всё делается битовыми операциями. Более того, можно совсем избавиться от бранчей, если скастить условие к int:

while (j <= n)
    j = 2 * j + (a[j] < x);

Скорее всего, нифига не понятно написал, поэтому любопытным предлагаю подсмотреть здесь. Там краткая выжимка конкретного алгоритма.

Почему хорошо работает? Потому что мы всё время движемся в одну сторону по массиву, хороший бранч предикшен (просто цикл while, причем еще и условие хорошее) и очень понятный паттерн префетча. Настолько понятный, что можно префетчить сразу много кэшлиний. И в этом ключ! Несмотря на то, что у B-tree количество кэш промахов меньше, для него мы должны префетчить линии последовательно, сложно угадать, какая будет следующая. Для укладки Eytzinger же мы можем не ждать, пока получим следующую линию, а тащить их в кэши сразу пачками. Таким образом B-tree ограничено латенси доступа в память, а укладка Eytzinger — фрупутом (простите).

Любопытное наблюдение. B-tree это алгоритм cache-aware, то есть требующий знания о размере кэш линии. А вот Eytzinger binary search как-будто бы cache-oblivious, то есть он учитывает, что кэши существуют, но ему не требуется знание об их размерах. ПЕРЕНОСИМОСТЬ.
Нахожу интересным то, что в данном случае дополнительная информация не помогает разогнать алгоритм.

Пятничного негатива минутка

Посмотрел я тут выпук(sic!) книжного клуба. Это шок контент для меня. Я даже и представить себе не мог, что можно _так_ прочесть биографию Фейнмана.
Книга буквально вся состоит из самоиронии. Читая её, понимаешь, что Нобелевские лауреаты тоже люди. Со своими странностями, глупыми поступками и ошибками.
Комики же почему-то решили, что
- это автобиография (да, там на обложке написано, что автор Фейнман, но по факту это не так, эта книга основана на рассказах Фейнмана, но это не автобиография)
- Фейнман постоянно рассказывает, какой он крутой (смотрит на взрыв атомной бомбы через стекло)
- Фейнман хвастается мудацкими и глупыми поступками (чаевые под окном воды, взломы сейфов)
- у Фейнмана нет друзей (про них якобы нет упоминаний)
- главное (и, видимо, единственное) достижение Фейнмана — создание атомной бомбы (любой физик знает, что это даже не близко к правде, его вклад в бомбу не такой большой, как нескольких других, более старших коллег)
- что свои причуды Фейнман принимает, как проблемы окружающих (я не понимаю, чем надо было читать, чтобы это так увидеть)

Короче, я прям хорошо отношусь к тому, что делают Квашонкин и Ловкачёв, в частности к книжному клубу. Но это просто какая-то феерия.

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

Новый набор в ЦМФ

Уже идёт набор на осенний семестр центра математических финансов на программу количественного анализа. В этот раз произошли несколько серьезных изменений.
Во-первых, в этот раз обучение будет проходить на английском языке.
Во-вторых, группы будут международными, уже есть апликанты из-за пределов СНГ.
В-третьих, отбор в этот раз значительно строже, чем был в предыдущие годы. Там уже надо торговую стратегию запилить.
Изменится также и проектная работа. Вместо кучи проектов на миллион тем теперь будут: один проект HFT, один проект на medium/long term стратегии и один проект на выбор.

Фокус этого потока — трудоустройство квантом в серьезные зарубежные трейдинговые компании. Это довольно сложная задача, а значит и цель подготовить тех, кто способен пробиться — амбициозная.
Если вам интересно поучаствовать в организации, преподавании или иным образом помочь ЦМФ, то для вас тоже новость: идёт набор в команду ЦМФ. Увидимся :)

Недавно дочитал очень крутую книгу про перфоманс

Чтобы не томить, вот книжка. Денис Бахвалов, @Performance Analysis and Tuning on Modern CPUs". Серёга Мельников её рекомендовал еще году в 2019, но я тогда не увидел смысла джависту в таком материале, а зря! Книга кроме рецептов даёт методологии (некоторые для меня оказались новыми) и хорошо объясняет перфоманс CPU. Фронтенд и бэкенд процессора, бранч миспредикты, спекулятивные исполнения, анролы циклов и вот это вот всё, о чём все вокруг говорят. Но никто толком не понимает, почему это должно работать.
К книге есть курс на гитхабе. Который довольно сложно проходить без знаний из книги (trust me). А ещё Денис ведёт блог и иногда проводит соревновашки на оптимизации.

Для меня новыми методами поиска узких мест стали roofline анализ и TMA (Top-down Microarchitecture Analysis). Почему-то в мире java такими штуками пользоваться не принято. В отличие, например, perfomance counter'ов. Вероятно, это связано с архитектурными ограничениями (отсутствием векторизации и JIT'ом).

Ещё я стал гораздо лучше понимать принципы работы современных процессоров. Если помните, я когда-то расшаривал исторические документы про архитектуры супер-ЭВМ, но те материалы всё-таки не дают такого представления о _современных_ процессорах, как книга Дениса.

Короче, рекомендую. Книга хорошая, годная, 10/10.

Уже несколько месяцев читаю канал Боря программирует. Там незаслуженно мало подписчиков, я считаю. Вероятно потому, что, как и у меня, никакой регулярности, да и темы скачут (хоть и с меньшей амплитудой, чем у меня).
Мне нравятся посты про всякие костыли. Про раст не особо нравятся (я его не знаю). Вот вам моя подборка.

https://t.iss.one/bminaiev_blog/13 — про победу микрооптимизаций над асимптотикой

https://t.iss.one/bminaiev_blog/34 — про эмпирическую оценку размера кэшей

https://t.iss.one/bminaiev_blog/37 — memory allocation profiler на bash 😁

Рекомендую.

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

Опыт очень классный, невероятно интересный. Я каждый день хожу на работу с довольствием, хотя иногда и с плохим настроением. Это ощущение мне напоминает мои первые несколько лет в разработке. Настолько же всё прямо зудит, так же легко проглатываются книги и статьи (ладно, чуть сложнее), настолько же интересно обсуждать работу с коллегами.
Чего не хватает мне в этой работе, так это бесконечной череды успехов и заборотых задач — программировать было проще.
Что ещё есть такого особенного из минусов? Очень длинный цикл обратной связи. Просто невозможно попробовать разные идеи в какой-то сжатый промежуток времени. И неприятные беседы. Увольнения, замечания, плохие ревью и корректирующая обратная связь — это всё моя работа. За два года мне стало сильно легче этим заниматься, но всё равно это каждый раз требует усилий. Вот бы все сами по себе хорошо работали и получали высшие оценки на ревью (я б тогда был не нужен, получается).

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

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

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

Assumptions
- курс рубля к доллару будет ослабевать
- ЦБ будет защищать порог курса в 100 рублей за доллар интервенциями на рынок (по политическим причинам)

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

Inefficiency
Потолок курса

Idea
Давайте будем покупать доллар за рубль, таким образом надавливая на курс в сторону 100. Покупаем дёшево (по 95, 97, 99). В это же время ставим заявку на продажу баксов по 99.75 (главное не торгануть с собой лол). ЦБ будет видеть, что КУРС ДВИЖЕТСЯ К ОПАСНОЙ ТОЧКЕ. Простите, не удержался. И продавать свои баксики нам по 99.75! Всё, продали дорого, заработали много денег, мы великолепны.
Подписываемся на платный канал с сигналами от квант валериан, платим комиссии бирже и брокеру, платим налоги, покупаем себе лавандовый раф на всю котлету.

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

ОЙ, ОШИБСЯ

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

Под руку попался подкаст Make Sense. И я тыкнул в выпуск про юнит-экономику. То, что рассказывал гость мне очень понравилось. Кроме того, предыдущий выпуск, про теорию ограничений, был с сотрудником той же самой компании. Я разу же послушал и его. В нём много воды, но зато обсуждается книга Цель (The Goal). Книга художественная, это важно.

Как обычно это бывает, рекомендующий говорит, что книга читается за пару вечеров. Я купил аудиокнижку. Двенадцать часов. Не похоже на пару часов. Впрочем, пора уже перестать верить чужим оценкам времени на чтение. Макс Бабенко, помню, тоже говорил, что WEPSKAM читается за неделю по вечерам.

Но я ж всё ещё болел. К вечеру воскресенья мне осталось послушать часа четыре. Так что я успешно закончил книгу вечером понедельника.

Очень крутая книга. Вот знаете Артура Хейли? У него СЮЖЕТЫ, в которые фоном вплетается производство (как управлять отелем или аэропортом). А у Элияху наоборот, в центре внимания производство, а сюжет фоном идёт. И то тоже очень интересно.
Что мне понравилось? Во-первых, что в книге достаточно времени, чтобы подумать и успеть сообразить сильно раньше, чем главный герой. Это сделано нарочно. Во-вторых, многие вещи, которые делает главный герой, я делал/делаю сам, без всяких подсказчиков. И теперь я, кажется, знаю, какие нужно будет перестать делать, как только я разгребу завал. В-третьих, я-то действую рассудительно, но во многом интуитивно, а в книге есть чёткий и полный (!) путь от основ. Основы у нас с главным героем тоже совпадают, приятно.

Утверждается, что в книге изложена теория ограничений (TOC). А ещё утверждается, что почти никто не может применить её у себя после прочтения одной лишь этой книги.

Скажу так. Идеи донесены очень доходчиво и ясно. Шаблон для рассуждений дан чёткий. К своей работе применять пока не пробовал, надо бы для начала выздороветь. Но я полон энтузиазма. Тем более, что неделю назад приобрёл книгу по Tameflow. А это (вроде как) как раз канбан с теорией ограничений. Разберусь — расскажу.

Но книжку Цель почитать советую. Очень круто.

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

Latency = 1 / Throughput IS WRONG

Недавно разговаривал с одним программистом, который улучшал перфоманс софта в одной там известной компании. Спрашиваю его: а что оптимизировал-то: латенси или фрупут? А он мне: ну так в данном случае это одно и то же. Брал функцию, запускал кучу раз, смотрел, сколько времени заняло.

Но вот только это вообще не одно и то же. МЕНЕДЖЕРЫ, не спим, вас тоже касается.

Итак, представьте себе московское метро. Эскалатор. Много людей столпилось и оператор кричит: "Занимайте обе стороны эскалатора!". Действительно, если стоять по двое не ступеньке, то в единицу времени с эскалатора будет входить вдвое больше людей, чем было бы с одной занятой стороной.
Но москвичи всё время куда-то бегут, им важно добраться до конца эскалатора как можно быстрее. Они бегут по левой стороне. Каждый конкретный человек слева поднимается таким образом быстрее, чем если бы он стоял, но вот количество сходящих с эскалатора людей в единицу времени небольшое.
Получается, что у полностью занятого эскалатора выше пропускная способность (фрупут), а у свободной левой стороны ниже латенси (время нахождения на эскалаторе).

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

Но вот у нас однопоточная программа, никаких синхронизаций нет. Запускаем её саму за собой. Значит, без разницы, что мерить?

Нееет, разница всё ещё есть. Давайте так. Действительно, средняя пропускная способность = 1 / среднюю латенси. Но когда вас в последний раз интересовала _средняя_ латенси? Правильный ответ: никогда. В лучшем случае вы смотрели медиану, но не среднее. Средняя латенси — это как средняя зарплата: ни о чем не говорит. 9 рабочих получают по рублю, а директор 50001 рубль, в среднем получают все получают по 5001 рублю. При оптимизации латенси, вас должны интересовать персентили. А не среднее. Например, хочу, чтобы 98% запросов обрабатывались за ,20ms, а оставшиеся 2% не дольше, чем за 100ms. Вот это адекватный таргет.
Среднюю латенси довольно легко сдвинуть: залипла одна задача на секунду и всё, средняя запорота. Вообще не понятно, а че там как у остальных-то было?

Другое дело пропускная способность. Суть метрики в том, чтобы понять, сколько можно наваливать задач на вход в единицу времени, чтобы не копилась большая очередь. _Масленькая_ очередь при этом копиться может. Всё по той же причине, что одна какая-то конкретная задача залипла дольше, чем обычно. Как раз эта маленькая очередь обеспечивает систему работой, в обратном случае, когда задачка проскочила неожиданно быстро. Именно из-за особенностей эксплуатации системы, оптимизируемой на фрупут, нам и важно смотреть на среднее — потому что всё усредняется вот этими вот очередями.

Если менеджеры всё-таки дочитали до сюда, то моё увОжение. А причем здесь менеджмент? А при том, что чаще всего мы управляем командами, для которых важно, сколько работы они могут делать в единицу времени. И менее важно, за сколько времени каждый конкретный unit of work проскочит. Поэтому измерять качество работы команды по "ну вот ту задачу долго делали" — в корне неверно. Тем более неверно держать абсолютно пустой бэклог (а вдруг взятые задачи проскочат молниеносно?). Вот вам неплохая ментальная модель, можно какие-то инсайты получить.

Про сложности распределённых команд

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

Самое первое, что приходит в голову — часовые пояса. У нас не так уж много таймзон задето, всего 4 часа между крайними точками, но это уже мешает. По крайней мере мне. Рабочий день тимлида норовит начаться пораньше, а закончиться попозже. Почему так? Вспоминаем мой какой-то относительно давний тезис про то, что задача тимлида — помогать команде не простаивать. Вот и бегай с утра до ночи, отвечая на вопросики, проглядывая ПРы и т.п.

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

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

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

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

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

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

Рецептов в этом посте не будет. Попробуйте подумать и посоветовать чего-нибудь в комментариях.

Я сегодня коротко.
Короче, помните, я про приоритезацию размышлял? Что надо сначала самое прибыльное. А ещё надо сначала такое, которое прибыль начнёт приносить раньше. Ну типа если обещают доход по 10к/неделю завтра против миллион/месяц, но первый раз через год, то надо сначала делать 10к. Потому что до "через год" можно и не дожить.
Вот это всё на словах хорошо, а надо число, желательно одно.

Cost of Delay. Сколько потеряем/недозаработаем и т.п., если отложим задачу на, скажем, неделю (ну или сколько там у вас типичный цикл). Ёмко, а? То-то же.

CD3 (Cost of Delay Divided by Duration). Теперь ещё отнормируем на время разработки (чаще всего получим такой вот ROI). Ещё лучше. Потому что учитывает, на сколько задержим других.

А теперь делим только на время обработки ограничением (констрейнтом в см. ТОС). Получаем честную отдачу на затраты в смысле Throughout Accounting. Теперь мы гораздо честнее оцениваем на сколько задержим других. Катарсис!

Короче, беру на вооружение.

Ура!
Вышел в открытый доступ доклад Саши, на который я несколько раз ссылался в канале. Если вас зацепили посты про memory orderings/memory models, то смотреть доклад обязательно :)

Я разобрался с Tameflow. И это офигенно. Действительно, авторы очень часто проводят параллели с Kanban method, в основном противопоставляя ему tameflow, но по-существу многие инструменты похожи.

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

Ребята предлагают найти ограничение во всём флоу разработки (вот этот конвеер, который стартует с очередной гениальной идеи вашего продакта и амплифицирует тасочки на всю компанию). Это будет какая-то команда. А потом нужно найти ограничение внутри процесса этой команды.
Дальше всё по канонам 5 шагов:
- найти ограничение
- загрузить его, чтобы не простаивало
- подчинить все процессы этому ограничению
- любым способом долить в него ресурсов
- искать новое

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