System Design & Highload (Alexey Rybak)

27 April 2024 11:36

Нагрузочное тестирование с wrk2/wrkx. Онлайн-митап DevHands.io 14 мая 18:30 MSK

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

С тех пор мы сильно прокачались в этом инструменте, причем некоторые участники буткемпа, кажется, прокачались сильнее меня 🙂 Например, Даниил Дук придумал и разработал софт для автоматизации стрельб, а так же обнаружил ряд очень неприятных багов в wrk2 и нашел патчи, которые эти баги исправляют.

Основной репозиторий wrk2, к сожалению, активно не обновляется с 2016 года, поэтому все эти патчи там "висят” годами. Так появился github-репозиторий wrkx (https://github.com/devhands-io/wrkx), “wrk2 c community-патчами”, а ещё github-репозиторий Данила wrk-helper (https://github.com/neduck/wrk-helper), для автоматизации стрельб и визуализации результатов.

Во вторник 14 мая 18:30 MSK мы проведем открытый митап “Нагрузочное тестирование с wrk2/wrkx”, на котором расскажем:
* Что такое wrk2, как его использовать, и как автоматизировать нагрузочное тестировение с wrk
* Что такое Coordinated Omission, и как с ним бороться
* Что вошло в wrkx, как при запуске “прибить” к ядрам треды стрелялки, а также многое другое.

Как попасть на митап? Ща расскажу, но сначала поделюсь болью. Когда я проводит митап в прошлый раз, я опубликовал ссылку на событие Google Calendar и был очень раз такому простому способу регистрации без заполнения форм, СМС и всего прочего. Однако, как выяснилось, к этому эвенту тупо невозможно было присоединиться, посколько число участников почти мгновенно перевалило за 100, а у Гугла есть вот такое идиотское ограничение.

Поэтому теперь делаю всё по-модному. Встречайте бота: /channel/devhands_meetup_bot. Вы его добавляете в один клик, и он работает как напоминалка. Он ненавязчивый, напомнит о митапе утром и за час до мероприятия, выдаст все нужные ссылки, и даже (может быть) раздаст подарки. Enjoy.

System Design & Highload (Alexey Rybak)

24 April 2024 11:54

Карьера в хайлоад-проекте: к чему готовиться - I?

Что такое “хайлоад-проект” для инженера, например, бекендера? Каждый раз, отвечая на подобный вопрос, вспоминаю расхожую фразу о том, что хайлоада не существует. Что за бред, как так? - спросите вы. Поясняю.

Во-первых, простите за занудство, в англоязычном мире просто не говорят “highload“, наиболее близкий термин – “large scale”. Термин “хайлоад” - русское изобретение, полагаю, это придумали Олег Бунин и Павел Рогожин, когда делали первую конференцию по разработке высоко-нагруженных систем, если не ошибаюсь, в 2007-м году. Сделали крутое дело, название отличное, прижилось, но для английского уха это звучит как нечто, простите, на наркоманском слэнге: high и loaded - это всё натурально “under the influence”, “под воздействием веществ”.

Во-вторых, хайлоад начинался с треда “как писать сервера” в RU.UNIX.PROG и веб-страницы “C10K (10000 connections) Problem” от Dan Kegel, посвященной проблеме обработки десяти тысяч одновременных соединений одним сервером. Поэтому один из моих приятелей любит говорить, что хайлоад начинается с 10K RPS (десять тысяч запросов в секунду на ноду). Но сейчас даже в очень многих крупных проектах одна нода держит тысячи или вовсе сотни RPS, и виной всему сложная, нещадно сжирающая процессор бизнес-логика, крайне редко позволяющая отдать больше сотни запросов в секунду с одного ядра. Масла в огонь подливает повальное использование скриптовых языков без JIT, но это отдельный разговор (мы их любим не только за это). А, ну и Постгрес до сих пор под каждое активное соединение использует процесс - полный хайлоад, конечно.

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

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

(продолжение следует)

System Design & Highload (Alexey Rybak)

10 April 2024 11:40

Слайды с бекенд-митапа DevHands Open Sessions

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

Если кому-то интересно - прикладываю ссылку на youtube. Можете смело смотреть на скорости 1.5. Презентация начинается с 25-й минуты и длится чуть больше часа, вопросы начинаются в 1:38:00.

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

Будем такие встречи повторять, следите за анонсами. И, кстати, планируется новый митап для бэкендеров - по нагрузочному тестированию, что нужно знать и уметь бекендерам. А кто хочет получить продвинутые бекендерские навыки - заканчивается набор на апрельские потоки буткемпа “Производительность и масштабируемость” и курс “Системный дизайн высоконагруженных проектов” - 5 дней действует скидка 10%(волшебное слово SYNSYNACK). Потом будет пауза в наборе, будем масштабироваться и запускать другие треки.

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

System Design & Highload (Alexey Rybak)

01 April 2024 10:20

Как расти бекендеру и как подготовиться к интервью?

В следующий вторник, 9-го апреля (18:30 msk) у devhands.io открытый вебинар для бекендеров. На этот раз на животрепещущие карьерные темы: Как расти бекендеру и как подготовиться к интервью?

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

Ниже ссылка на календарь, добавляйте себе. В описании к календарю и в комментариях - ссылки на комнату в Zoom и трансляция Youtube.

Что обсудим? Сначала посмотрим на карту развития бекэнд-программиста, от мидла до эксперта. Её можно использовать как для составления плана на обучение, так и для быстрой проверки “зон роста” (в том числе тех зон, которые нужно подтянуть как для перехода на новый “уровень”, так и для прохождения интервью - а часто это разные зоны).

Затем обратимся к тем, кто собирется менять работу или находится уже в процессе поиска. Поговорим о следующем:
* Как вообще понять, менять работу или нет?
* Обсудим типовые ошибки, которые совершают программисты на разных этапах
- составление резюме: формат, фокус и почему (и когда) это до сих пор важно, нужны ли референсы и сопроводительные письма
- от общения с рекрутером до общения с будущим руководителем
- прохождение coding sessions
- прохождение architecture (system design) sessions
* Как можно было бы классифицировать компании, чтобы понять компания “нормальная” или нет
* Какие вопросы задать себе, чтобы понять, что вы хотите сами, и в зависимости от этого сформировать список вопросов для компании, чтобы понять, ваша это компания или нет
* Ну и если успеем, поучаствуем в спец-олимпиаде: какой трек выбрать, IC или EM?

Приходите сами и приводите друзей. Регистрация не нужна.

Если вам интересны какие-то ещё темы - напишите, пожалуйста, в комментариях.

Добавляйте себе в календари:

https://calendar.app.google/RpQVZqfgJyee7Rme6

System Design & Highload (Alexey Rybak)

06 March 2024 06:51

Разминка для математических мозгов: взлом теста для программистов

Математики, физики, machine learning специалисты и к ним примкнувшие, нужна помощь.

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

Итак, сама задача. Имеется классический и самый обычный тест для программистов. Это черный ящик, который предлагает вопросы, принимает ответы и на выходе даёт числовой результат. За правильный ответ присваивается балл. Конечный результат теста - сумма баллов (или число правильных ответов). За одну серию (испытание) спрашивается m вопросов, они случайно достаются из банка с n вопросами, причем n заметно больше, чем m.

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

В статье (ссылка в комментарии) зачем-то было очень много матана, но суть там была очень простой.

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

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

System Design & Highload (Alexey Rybak)

19 February 2024 10:37

Наблюдения про корпоративный тулинг

Работаем с Avito - интересные наблюдения.
* Кажется, почти не осталось PHP-разработчиков, все - гошники. Оценку не даю, просто наблюдение. По-прежнему считаю именно связку Go+PHP удачным выбором для бекенда, позволяющую держать баланс между гибкостью, сложностью и костами.
* Кстати, про статистику использования языков: tiobe, github, stackoverflow surveys - всё смещено и неправда. Статистика, которая нужна - внутри компаний, доступ к ней обычно закрыт. Есть статистика джоб-бордов, туда не попадает крупняк. Есть статистика в анкетах у Олега Бунина (конференции HighLoad), но (1) конференции большие, а инженеров больше на порядки; я знаю кучу хороших компаний и людей, кто не был и не собирается на хайлоад (2) кажется, они не делают исследований, и не открывают данные (а надо бы предложить).
* Для описания сервисов в Авито рекомендован стандарт C4. Обсудили мою критику C4 - про “нечеткость” названий. Кто реально сталкивался в попыткой "следовать стандарту" - с моими доводами согласны. Опубликовать стандарт что ли? Но тривиальная же вещь: роли, сценарии, компоненты.
* 2500 микросервисов. Кстати, был интересный обзорный доклад на Хайлоаде: “Ах как хочется вернутся, ворваться, в монолит”, https://www.youtube.com/watch?v=yLrSp174yc0. На самом деле им не хочется. С некоторым удивлением в списке “проблемных” зон микро-сервисов от Авито не увидел проблему консистентности данных. Обсудим, как они её решают системно.
* В компании на редкость богатый “тулинг”, позволяющий очень многое автоматизировать. Постгрес разворачивается уже “managed”, c баунсером, бекапами и прочим добром. Ручки-экспортеры и мониторинг поверх пром-стека из коробки. Детали поддержки многих датацентров пока не уточнял, но в целом такую поддержку они давно внедрили.

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

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

System Design & Highload (Alexey Rybak)

15 February 2024 13:07

freenginx

Друзья, если кто не в курсе, вчера вечером Макс Дунин анонсировал форк nginx - freenginx. Макс - старейший сотрудник nginx и core-контрибьютор как я понимаю ещё со времен Рамблера. Есть возможность задать Максу вопросы про freenginx - Макс любезно согласился на интервью. Хотите что-то добавить к этим вопросам? Просто пишите комментарии, я перешлю ему.

- Почему ты решил форкнуть nginx и запустить проект freenginx? Почему ты делаешь акцент на свободе, в чём был несвободен nginx внутри F5?
- Ты будешь работать один или уже есть команда, кто будет работать над проектом? Есть ли у тебя понимание, чем ты займешься в первую очередь, для кого позиционируется новый продукт?
- Пишут, что с момента закрытия офиса nginx в Москве ты работал “волонтером”. Связывают ли тебя сейчас какие-то контрактные обязательства с F5/nginx и накладывает ли это какие-то ограничения на новый продукт?
- На YCombinator пишут, что причиной возникновения freenginx стала какая-то не очень понятная история со внесением в реестр CVE уязвимости в экспериментальном коде. Ты не мог бы рассказать подробнее, что там было, и почему вообще это важно?
- У nginx становится достаточно запутанная экосистема: Nginx от F5, nginx+, Nginx Unit, форк Angie, PPA (personal packages) с интересными дополнительными модулями типа поддержки brotli, теперь твой форк. Куда вообще всё идёт? Можно ли говорить о том, что F5 недостаточно внимания уделяет управлению и выращиванию экосистемы в целом?
- Nginx занял прочное место фронта обслуживания внешнего трафика, но внутри инфраструктуры его активно теснят “cloud-native” решения типа envoy. Почему это происходит, собирается ли freenginx (или может быть F5) что-то с этим делать?

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

System Design & Highload (Alexey Rybak)

27 January 2024 08:49

Самый идиотский вопрос на интервью

В одном очень большом и очень популярном канале (источник в комментариях) недавно был пост-совет, как отвечать на вопрос “кем вы себя видите через 5 лет”. Даются в целом разумные рекомендации, как забулшитить рекрутера в зависимости от того, в какой компании он работает, продемонстрировав (1) лояльность (если не сказать сервильность) и (2) понимание культуры и потребностей компании.

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

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

Хотите понять, насколько человек лояльный и будет “привязан” к месту работы - ну спросите по опыту работы, по кейсам из практики, выясните его “культурный код”, спросите его про собственное карьерное/профессиональное развитие.

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

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

----
https://devhands.io/ru/ - образовательные треки по хайлоаду, системному дизайну, linux и другим advanced темам
/channel/feedmetoo - интересные статьи, ссылки, презентации

System Design & Highload (Alexey Rybak)

17 January 2024 11:46

Lessons learned полгода спустя и новости DevHands

Полгода назад написал такой немного наивный leassons learned пост - по опыту работы с пилотными группами обучения DevHands, вот он: /channel/rybakalexey/41

Вкратце, на что тогда обратил внимание, с текущими статусами

1. Разные образовательные пути в рамках буткемп-трека: не делаем, разводим треки через доп. курсы и отправку в более поздний поток

2. Фаст-трек для “занятых” без большого количества практики: сделали трек “Системный Дизайн”

3. Переход между потоками: сделали неограниченное количество переходов/академов (сложнее менеджить, но фокус на удобстве участников и конверсии)

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

5. Повышение ценности и мотивации для модуля “нагрузочное тестирование”: модуль переработан, добавлено несколько демо-встреч с более наглядным разьяснением, конверсия в прохождение теперь устраивает

6. Маркетинг и каналы продаж: бесконечная история, работаем 🙂 в феврале запускаем проект с крупной интернет-компанией, надеюсь в 2024 году сделать существенную часть продаж в корп. треках (L&D-менеджеры, приходите обсуждать!).

Но самое главное, что произошло: меняем позиционирование, расширяем воронку и потихоньку обрастаем смежными курсами. Из самого интересного: запустили для инженеров трек “Системный дизайн” и “Управление собственным linux-сервером”.

Про всё можно почитать (и записаться) тут: https://devhands.io/ru/.

P.S. Менеджерский трек - в процессе, сначала отработаем “групповую” методику в пилоте. Там очень интересные сегменты и потребности, которые надо грамотно разделить.

System Design & Highload (Alexey Rybak)

21 December 2023 09:22

Сухо самые важные выводы голосования на текущий момент:
* полная безоговорочная поддержка 12-ти принципов гибкой разработки - 16%
* поддержка с небольшим количеством оговорок (0-2, суммарно) - 37%
* значительное несогласие (3-6+, суммарно) - 63%
* серьезное несогласие (6+, половина и более принципов) - 22%.

Погрешность уже не очень большая, несколько процентов (сужу не по математике, а по тому, как «плавают» цифры).

Осталось всего пять голосов до 100. А ну-ка менеджеры, давайте поднажмём! Текст принципов - в предыдущем посте.

System Design & Highload (Alexey Rybak)

20 December 2023 15:08

Обучение менеджеров разработки ПО

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

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

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

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

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

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

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

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

Для того, чтобы опробовать пилот, я запускаю закрытую группу с рабочим названием “Миссия выполнима”. Будем разбирать такое управление производством ПО, в котором сложные проекты делаются качественно, в срок, в рамках бюджета, а сотрудники довольны, развиваются и не уходят.

System Design & Highload (Alexey Rybak)

15 December 2023 12:39

Вечный вопрос про зарплаты и справедливость

Вынесу из одного чата вопрос о вечном:
Вот есть у вас в команде 2 сеньора, которые долго в компании и ЗП у них на уровне рынка. Вам нужен еще один сеньора, но на рынке все хотят выше рынка чтобы пойти к вам. Допустим вы берете такого сеньора, который получает выше чем остальные, а отличие лишь в том, что новенький умеет себя продавать, а другие уже много лет работают и то ли стесняются, то ли не знают себе цену. Вопрос - нужно ли тут включать "справедливость" и как-то уравнивать, либо "ты сам творец своей судьбы"?

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

1. Справедливости, может, и не существует, но к ней нужно стремиться. Тезис “справедливости не существует” - циничный. Опустим, что он ещё и используется как коммуникация уровня идите-в-жопу. Мне этот тезис неприятен как человеку. Даже если умом понимаю, что её, падлы, не существует. Этим тезисом можно начать оправдывать гадости. Помножим это на русский коллективизм, нашу “любовь” к предпринимателям, философии индивидуализма Айн Рэнд, и вот это всё. Да, ладно, справедливости не существует. Но несправедливость в целом - плохо. Несправедливость нужно уменьшать. Как уменьшать? Грейды, вилки и регулярный ревью.

2. Разница в доходах != несправедливость. Внутри вилки плюс-минус всегда будет разница. И понимание рынка сотрудниками всегда смещено. Мы запоминаем “приятные” и “неожиданные” суммы. В компании X синьорам платят семьсот! А я - синьор, и значит я стою семьсот. Нет, дорогой. Это значит только то что если ты синьор, и если подойдешь компании X, то возможно, твоя зарплата будет где-то около этой суммы. Всё, не более. Подумайте о сценариях. Информация может быть неточной. А точно это ваш уровень? Сходите к ним на интервью. А много таких компаний? На какие суммы нанимают другие? А может, эта компания вообще отчаянно пылесосит рынок, наймет несколько человек, выжмет и высушит их за полгода и выкинет выгоревшими инвалидами. А ты потом полгода будешь греть попу на белом тайском песке, да так и не отойдешь? Следи за рынком по-умному: читай разные источники, и ходи сам на интервью. Будешь лучше понимать рынок. А рынок - это грейды, вилки и регулярный ревью.

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

4. Значительная разница в доходах - очень неприятно и фатально. Утрата доверия 80-го уровня со скоростью света. Если приходит новый синьор на зарплату +50% выше чем у старичков-синьоров, и при этом у нового сотрудника нет очевидного преимущества - скорее всего старичок уже уволился, даже если продолжает ходить на работу. Пипец уже произошел. Фарш не провернуть назад. Вы можете думать, что все циники, и вот они придут с претензией, и когда и если это произойдет, то мы им пересмотрим, и все будут довольны и вопрос будет решен. В российских коллективах это не так. Это меняется, но крайне медленно. Скорее всего всё плохое уже произошло. Отсчет времени пошел. Не делайте так. Как делать? Грейды, вилки и регулярный ревью. На крайняк - большая “переменная” часть, если готовы аккуратно её менеджить (скорее всего не готовы).

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

System Design & Highload (Alexey Rybak)

21 November 2023 09:45

На чьём плече обезьяна?

Образ проблемы-обезьяны - одна из основных концепций по делегированию и управлению проектами, который должен уяснить любой менеджер, особенно менеджер менеджеров. Этой идее - 50 лет, она была описана в статье Harvard Business Review 1974 года (Onken, Wass), и я абсолютно уверен, что большинство её не знает. Рассказываю суть.

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

Релокация обезьяны происходит в любой сложной и непонятной ситуации, как только босс скажет что-то вроде “хорошо, дайте мне подумать об этом”, или “я свяжусь с таким-то и таким-то, посмотрю, чем они могут помочь” или даже ”окей, напишите мне об этом” - то есть как только босс вдруг сам инициирует “переключение ответственности”, и принимает задачу на себя: опа! поздравляем, у вас на плече +1 обезьяна.

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

Кормить обезьяну разрешается строго по правилам: только по расписанию, только дозированно, и она всё так же продолжает сидеть на плече подчиненного: до кормления, во время кормления, и после кормления. Обезьяну можно только кормить. Или пристрелить.

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

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

System Design & Highload (Alexey Rybak)

07 November 2023 10:35

Есть места на бесплатный онлайн ML/DL-воркшоп в пятницу 10 ноября 17:00 мск

Мы с Денисом Пархоменко (МГУ, ВШЭ, московский Хуавэй, эксперт в Machine Learning и Deep Learning) проведем в эту пятницу ML/DL-воркшоп с рабочим названием “вкатись в ML/DL”. Рассчитан он в первую очередь на профессиональных бекендеров, кто хочет познакомиться с deep learning, но не хочет долго и нудно изучать основы. Мы предлагаем сразу же практику: на предоставленной нами инфраструктуре каждый участник сразу же выполнит типовые DL-задачи, познакомившись с основными инструментами в процессе.

Если более подробно, то всё будет онлайн в Zoom. Сначала будет небольшая лекция, а потом все зарегистрированные участники получат примерно на час-полтора свой личный Jupyter-notebook на 5-гигагерцовой ноде, и прям в ноутбуке обучат сетку и проведут классификацию объектов или распознавание рукописного текста - на что хватит время. Часть воркшопа будет посвящена методам визуализации. Весь код на питоне, но он вроде там несложный.

Участие бесплатное, но количество мест ограничено, поскольку нужно будет резервировать мощности и раздавать их лично каждому. Поэтому обязательна регистрация, для этого нужно заполнить вот такую форму: https://forms.gle/pC5dLSUagJ4CEhFA9.

Инфраструктура под это мероприятие любезно предоставлена компанией TimeWeb. Качеством, возможностями и ценами этой платформы я был приятно удивлен.

System Design & Highload (Alexey Rybak)

01 November 2023 10:51

Отзывы на модуль “M2. Производительность”

Давно уже собрал, но не публиковал отзывы участников буткемпа после обучения в модуле “Производительность”. Исправляюсь. Это - реальные отзывы ребят, безо всякой литературной обработки, причем именно этой группе выпала самая “сырая" подача этого модуля, сейчас он стал несколько проще (больше вводных демо и разьяснений по автоматизации). Ребята, большое спасибо вам за отзывы!

Владимир И (10+ лет опыта, Python/uWSGI/MySQL, небольшой опыт системного администрирования, цели: highload, system design):
Модуль был полезен именно порядком цифр, в реальной жизни я никогда не занимался нагрузочным тестированием, и не понимал порядок цифр. Сейчас есть такое понимание, есть понимание, что чистый Python работает в разы быстрее Django, есть понимание, что в принципе может отдать Django, и это позволяет более “научно” подходить к вопросам скейлинга. В этом плане безусловно модуль полезен.

Андрей Л (10+ лет опыта, PHP/PostgreSQL/MySQL, опыт системного администрирования, цель: систематизация знаний):
Работал я с нагруженными системами много, но работал с органическим трафиком. Вот так специально брать тестовую машину, настраивать различные приложения, тюнить их, и уж тем более использовать различные “стрелялки” - никогда этим не занимался, и это было замечательно. Я wrk никогда не использовал, и теперь, если мне что-то нужно будет смотреть под нагрузкой - я понимаю, как это использовать, как эти данные собирать, обобщать, на что смотреть. Так же никогда специально не занимался тюнингом php-fpm, не разбирался, какие есть ручки, а теперь появился некий навык и даже потребность. Вот сейчас хочу протестировать насколько медленнее будет работать в проде php-fpm, если деплоить в контейнерах. Появляются вопросы к самому себе, как, где по работе что-то улучшить, подтюнить, поменять, сделать получше.

Андрей М (5+ лет опыта, Python/PostgreSQL, профессиональный опыт системного администрирования, цель: highload):
Я никогда не занимался таким нагрузочным тестирование на каком-то стенде. И я никогда не понимал даже порядок цифр, сколько можно вытащить RPS. Понятно, что всё это какие-то данные синтетические, далекие от реальности, потому что настоящее приложение будет вести себя по другому, но всё равно было очень интересно понять порядок цифр.

——
devhands.io/ru/ - хайлоад-буткэмп для девелоперов (своя инфра с первого дня, собираете свой стек, нагружаете, тюните, учитесь масштабировать - 6 месяцев онлайн)
@feedmetoo - новости про разработку, статьи, презентации

System Design & Highload (Alexey Rybak)

25 April 2024 14:25

Карьера в хайлоад-проекте: к чему готовиться - II?

Это продолжение прошлого поста, вот - первая часть.

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

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

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

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

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

Мир не очень приветствует погружение под капот - это ж сложно. Современные облака хотят от скрыть от нас детали, предоставляя planet-scale решения с автоматическим масштабированием. В больших проектах развит внутренний тулинг – так что масса вопросов скрыта даже для опытных инженеров, которе выросли в таком проекте. Это не хорошо, и не плохо - это данность. Так что если хотите копать глубоко – просто попасть в крутой проект может оказаться недостаточно, нужно копать самостоятельно, читать чужой код, ресерчить, исследовать, применять новые подходы, пробовать компоненты. А эта область уже чисто исследовательская.

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

Кстати, о тулинге. Самая быстрая и легкая в мире “стрелялка”, wrk2, с 2016-го года особенно не поддерживается, поэтому отличные community-патчи, в том числе критичные, висят годами. Один из участников буткемпа – Даниил Дук - сделал титанический ресерч, в числе прочего найдя критичный патч, которые убирает проблему 100% нагрузки CPU при определенных условиях. Короче, я решил это исправить, и сделал вот такой реп: https://github.com/devhands-io/wrkx, “wrk2 с комьюнити-патчами”. Сделаем 14-го мая вечером митап про нагрузочное тестирование и про wrk и про автоматизацию - stay tuned, ещё напишу про это.

System Design & Highload (Alexey Rybak)

17 April 2024 14:30

Владимир Перепелица (ex-VK, Tarantool) + DevHands.io

Супер-важная новость для нашего образовательного проекта DevHands.io.

Мы стартуем продвинутый образовательный трэк по очередям. Это направление возглавит эксперт по большим проектам, очередям и Tarantool, регулярный спикер и член ПК конференций Highload, создатель S3 в VK Cloud, Mons Anderson aka Владимир Перепелица (ex-VK, Tarantool).

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

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

Асинхронное взаимодействие и очереди - невероятно широкая тема, но абсолютно обязательная к изучению всем, кто интересуется архитектурой. Даже если сузить её до сравнения самых популярных продуктов - Kafka, Rabbit, NATS, Redis - то всё равно получится очень интересно, поскольку все решения чем-то отличаются, и разработчику важно понимать архитектурные особенности, сильные и слабые стороны компонент, на базе которых строится архитектура. Моя мечта, конечно, помимо просто хорошего экспертного образовательного трека сделать уникальный research cloud, где все популярные решения доступны из NoOps-коробки, но как скоро нам удастся к этому приблизиться - вопрос открытый.

Запись на апрельский поток “Системный дизайн” на странице курса. Приходите, будет супер-интересно.

System Design & Highload (Alexey Rybak)

06 April 2024 09:52

О сроках

Есть 10 (два) типа людей.

Одни считают, что если для задачи нарушается 3W1H-принцип (известно what, how, who и самое главное when) - то задача почти гарантировано продолбается.

Вторые считают, что мир настолько изменчив, что попытка ответить на эти вопросы, поставить сроки, зафиксировать обязательства - это стресс. В стрессе невыносимо! Катастрофически падает работоспособность. Стресс приводит к несчастьям. И вообще, вот Гитлер так же сроки ставил и прессовал. Не продолбается! А если продолбается, ну чотакова? И вообще нужна внутренняя мотивация, а не внешняя. Поэтому спрашиваю вас: где моя внутренняя мотивация и что вы для неё делаете?

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

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

(Если что, последние слова пишу лёжа - ну, реально длинный текст, не в ресурсе уже).

System Design & Highload (Alexey Rybak)

16 March 2024 08:57

Пикодата, in-memory data-grid.

Немного выпал и не писал, много проектов. Добрался, наконец, до видео доклада Кости Осипова о Пикодате. Кстати, где был доклад - тоже интересно само по себе. Это была первая встреча нового комьюнити разработчиков СУБД - Database Internals Meetup. Свежая история, дело было в офисе Яндекса, драйвером, как я понимаю, выступили ребята из YDB.

Доклад ретроспективный, несмотря на название. Пикодата - осносительно новый продукт поверх Тарантула. Грубо, для каждой отдельной ноды взяли Тарантул, но поверх натянули “кластерную” обёртку - и всё вместе получилось Пикодата. Про то, как выбирали подходы к работе со схемами данных, как обжигались о Lua, как в новом продукте стали использовать Rust, и какой подход к конфигурации и управлению кластером. Немного про логику “втянуть данные поближе к приложению”, “уволить С++ программистов”, бесперспективность GC-рантаймов для high performance задач.

Видео никто не любит, но на ускоренной промотке до вопросов уложитесь примерно за 20 минут, я проверял. Инжой. Не оставляю надежды сделать пикодатовский ресёрч-клауд в рамках образовательного клауда devhands.io.

https://www.youtube.com/watch?v=_UNok-uXql4

System Design & Highload (Alexey Rybak)

20 February 2024 08:58

Курс по Linux: задарма, “для своих”.

Это предложение “для своих”. У нас есть пилотный курс по Linux, “Управление собственным Linux-сервером”. Он задумывался как курс для бекендеров, которым сложно учиться на буткемпе, потому что на "прокачку" своей инфры дается слишком мало времени (через 2-3 недели после старта народ уже собрал свой стэк, собрал wrk2 и жмёт гашетку на максимум, выжимая свои десятки и сотни тысяч запросов в секунду). Конверсия в прохождение буткемпа понижается, и я сделал дополнительную более “плавную” программу.

Пока не очень понимаю, как его продать более широкой публике, но цели зарабатывать на нём пока нет. Я верю, что курс очень нужный именно в контексте True DevOps - движение в две стороны, Dev+Ops, а для этого девелоперы должны изучать инфру с основ. Поэтому в марте мы этот курс запустим за бесценок – за 5000 рублей. Именно столько будет стоить за 2 месяца виртуалка с 8 ядрами, 12-ю гигами памяти и 100-гиговым NVMe SSD диском, который все слушатели получат для экспериментов в первый же день. Записаться можно - по ссылке ниже, а можно отправить это друзьям. Мест мало (группа уже собрана наполовину). Старт в марте. Записываться тут: https://devhands.io/ru/linux-server-program.html

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

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

Также я стала значительно увереннее чувствовать себя с командной строкой и управлении Linux. Теперь, полгода спустя, мне кажется это тривиальными задачами, но это был очень важный “левел ап”. Это мне позволило писать мейкфайлы, работать с разными утилитами, взять на себя более низкоуровневые задачи.

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

Всё правильно пишет. DevOps – не новое название сисадминов, а культура Dev+Ops. Всё хорошо, что помогает dev и ops общаться на одном языке.

System Design & Highload (Alexey Rybak)

16 February 2024 06:08

freenginx - ответы Максима Дунина

Полная версия опубликована на Хабре (https://habr.com/ru/articles/794096/ - и кстати, полайкайте там, пожалуйста).

Ключевое про CVE и мое мнение (возможно, ошибочное) - ниже. F5 настаивали на внесении CVE и выпуске security-релиза, хотя разработчики договорились исправлять баг и потенциальную уязвимость в обычном порядке. Баг был найден в коде для HTTP/3 (и вообще говоря, это не просто экапериментальный модуль, Очень Важный Экспериментальный Модуль). Неясно, сколько компаний использовало эту экспериментальную фичу. Никаким образом коммерческий код Nginx Plus эта фича задеть не могла. Мне кажется, это достаточно грустный пример хреновой коммуникации и отсутствия транспарентности при обсуждении, а так же накопленных противоречий из-за волонтерского двухлетнего участия Максима в проекте . На YCombinator (ссылка ниже) почти все комментарии представителя F5 выглядят так: у нас полиси.

[АР] На YCombinator пишут, что причиной возникновения freenginx стала какая-то не очень понятная история со внесением в реестр CVE уязвимости в экспериментальном коде. Ты не мог бы рассказать подробнее, что там было, и почему вообще это важно? 

[МД] История, действительно, не очень понятная, в том числе и мне самому. В экспериментальном коде HTTP/3 нашли ошибку, которая приводит к падению рабочего процесса при некотором поведении клиента. Существующая security-политика проекта предполагает, что такие ошибки исправляются как обычные ошибки - потому что в экспериментальном коде бывает всякое, и в документации явно об этом написано. Роман, разработчик, занимавшийся исправлением ошибки, на всякий случай написал о ней в список рассылки проекта для обсуждения security-проблем. Мы обсудили это, и все разработчики согласились с ожидаемым подходом - исправить как обычную ошибку.

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

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

На всякий случай для справки: CVE - или даже CVE® - Common Vulnerabilities and Exposures. Ресерчеры заинтересованы в публикации CVE, и для ряда представителей ИБ это стало в определенном смысле видом спорта. Именно по этой причине теперь решение о публикации уязвимостей в ядре Linux должны пройти утверждение в специальной группе, и есть ряд условий для публикации (например, готовый патч) - спасибо за комментарий Артему Гавриченкову (Servers.com).

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

System Design & Highload (Alexey Rybak)

14 February 2024 10:10

Балансировка нагрузки

Комьюнити-чат образовтельного проекта приносит интересные ссылки и обсуждения.
Началось с обсуждения твита кого-то из Амазона, о том, что обычный алгоритм round robin (последовательно раскидывает нагрузку по всем нодам) даёт сильные “перекосы” в нагрузке. Предлагался альтернативный способ: выбирать случайно пару нод для балансировки, и из этой пары уже выбирать ту ноду, которая нагружена меньше.

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

Тот же Weighted Round-Robin (распределение нагрузки с динамическими весами) даёт отличные результаты, причем конечный результат заметно улучшается даже без реалтайма. Вот на этой уже довольно древней Хайлоад-конфе Юра Насретдинов, на тот момент ещё сотрудник Badoo, рассказывает, как он динамически раз в 15 минут пересобирает веса и регенерит их для LTM - и это даже нормально работало: https://www.youtube.com/watch?v=jHYzy6DDo9c.

А ещё прикольная статья с анимационной иллюстрацией алгоритмов балансировки (RR, WRR, Least connections, Latency-based). В конце страницы отличный “симуляционный” плейграунд на яваскрипте, можно выбрать любой алгоритм, плотность входящих запросов и смотреть, как наполняются очереди (и дропаются заявки от переполнения).
Сама статья здесь: https://samwho.dev/load-balancing/, ссылки изначально нашел Андрей Л, участник буткемпа, вот в этом канале: /channel/ThePr0Ger.

----
https://devhands.io/ru/ - образовательные треки по хайлоаду, системному дизайну, linux и другим advanced темам
/channel/feedmeetoo - интересные статьи, ссылки, презентации

System Design & Highload (Alexey Rybak)

26 January 2024 10:51

Друзья-архитекторы, программисты и к ним примкнувшие, а что вы думаете о модели C4 - хороший ли это подход? Хороший фундамент для создания "надъязыка" коммуникаций между командами, обсуждения архитектуры?

Мой личный опыт говорит, что существует не четыре, а три основных уровня, на которых происходит обсуждение продукта и архитектуры:

1) Бизнес-уровень: роли, сценарии, сценарии использования, истории, cjm и т.д.); это частично покрывается "контекстом", но не совсем: C1 кажется довольно высокоуровневым, но мы можем назвать это "контекстом"

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

3) Модули, библиотеки - довольно очевидно, "код", то же самое, что и в C4; в дискуссиях обычно стоит избегать такого глубокого погружения, поскольку погружает в миллион деталий и жаргонизмов.

Так что я бы ожидал, что модель C4, если она претендует на стандарт, была бы C3.

Что думаете?

----
https://devhands.io/ru/ - образовательные треки по хайлоаду, системному дизайну, основам управления linux-серверами
/channel/feedmeetoo - интересные статьи, ссылки, презентации

System Design & Highload (Alexey Rybak)

22 December 2023 11:43

Манифесто: выводы

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

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

Если кто-то ставит перед собой задачу изучить гибкие методологии, то карта развития будет следующая: манифест как идея, принципы как программа или чеклист, и фреймворки как рецепт. Поправьте меня, если считаете что это не так - я 20 лет назад прошел именно по этому пути (и офигел). Манифест мутноват, принципы противоречивы (огромное количество менеджеров вообще не готово “подписываться” по ними - результаты в конце поста). А фреймворки - Скрам и Канбан и производные - интересны, но на практике у всех что-то другое!

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

Но это ж фигня какая-то с точки зрения обучения. И знаете что: гибкие методологи/консультанты мне кажутся здесь ещё менее гибкими, чем жуткие, процессные, проектые, корпоративные проджекты потому что PMI и PMBOK уже включает рекомендации использовать Agile, появился и ISO21500, и всякие Prince2, PM3express и прочие, а со стороны “True Agile” - я такого движения не наблюдаю.

Подробнее сейчас не распишу, какие принципы наиболее неудачно сформулированы - места не хватит. Я лично голосовал за 6+ принципов.

Ну а теперь смотрите как аккуратно можно было перефразировать все то же самое без высокопарных “люди важнее процессов”, согласитесь, такие формулировки кажутся значительно менее противоречивыми.
Цитирую по книжке ГосАджайл (Да, есть такая! пусть вас не смущает "гос", отвечаю, книжка - очень норм).

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

Ну отлично же! И так же можно было поступить с 12-ю принципами, но нет, имеем что имеем 🙂 И про другую книжку: Олег В. - спасибо ему - напомнил про отличную книжку дяди Боба (Роб Мартин), “Чистый Аджайл”. Если интересно, можете погрузиться в историю развития идей и той встречи 17-ти экспертов - прочитайте, она небольшая, и очень познавательная.

А вот обещанные результаты голосования (сколько пунктов 12-ти принципов не поддерживаете или поддерживаете со значительными оговорками):
* 0 пунктов (всё поддерживаю) - 16%
* 1 - 8%
* 2 - 12%
* 3 - 19%
* 4 - 17%
* 5 - 5%
* 6+ 23%

System Design & Highload (Alexey Rybak)

20 December 2023 15:08

Группа - что это за хреновина, спросите вы? Это не курс и не тренинг в чистом виде. Это больше похоже и на групповой консалтинг, и на группу развития, которая объединена общей целью “повышения эффективности управления ”. У каждого члена группы есть чёткие цели, которые они сами себе поставили, и смысл существования этой группы - в том, чтобы этой цели добиться. Не всегда эти цели сформулированы, поэтому все, кто хочет участвовать, проводят со мной 1:1 на старте, чтобы мы поняли, что это за цели и какие ожидания. У группы есть справочник методик и терминов, которые группа должна изучить - что-то самостоятельно, что-то на лекциях - но самый большой упор делается на практическое применение “в поле” через разбор кейсов на группе. У нас будет 3 месяца и 12 онлайн-сессий + мы зарезервируем время под несколько 1:1 консультаций с каждым участником. Группа будет условно-бесплатной. Участие в пилоте будет стоить абсолютно смешные деньги, но мы делаем пока совсем не ради денег, а чтобы обкатать подход и пользу.

Кто может попасть в группу? Требование одно: нужно иметь хотя бы минимальный управленческий опыт. Продакты, engineering-менеджеры и тим-лиды, которым интересно всё, что я написал выше. Что нужно сделать, чтобы попасть в группу? Просто написать мне сообщение в телегу, после чего мы договоримся с вами об 1:1. Если остались какие-то вопросы или готовы участвовать - пишите мне ЛС на @alexeyrybak.

Группу буду вести я лично. Если мы вдруг с вами не знакомы, то меня зовут Алексей Рыбак, и больше половины своей карьеры я посвятил Badoo/Bumble - сначала это была соц-сеть, а потом приложение для знакомств - продукт с сотнями миллионов пользователей, который вырос из абсолютно гаражного стартапа (я работал со дня основания), и был продан сначала Blackstone по оценке в $3 млрд, а через год вышел на IPO по оценке $8 млрд. За свою карьеру я делал: соц-сети, мобильные и десктопные приложения для разных сегментов (знакомства, такси, рестораны), массовые СМИ и разнообразные edtech-продукты, например, цифровые двойники и роботы-помощники обучению иностранным языкам. Я был программистом, тим-лидом, директором по разработке, вице-президентом, CIO и CTO и даже пару раз выполнял роль CPO. Я работал в маленьких командах, средних командах, больших командах, с аутсорсерами и аутстафферами, аудировался сам и проводил аудиты, заказывал обучение и проводил обучение, участвовал в M&A-стримах с обеих сторон - и продавал, и покупал/интегрировал стартапы. Короче, приходите, уверяю вас, в группе скучно не будет 🙂

System Design & Highload (Alexey Rybak)

19 December 2023 10:46

Аджайл манифесто

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

Мы "посягнём" на святое - на сам Аджайл-манифест. Будет два поста. В первом посте я опубликую 12 принципов Agile из манифеста, и попрошу вас посчитать пункты, с которыми вы либо несогласны, либо согласны, но со значительными оговорками, то есть при просьбе подписаться под этим пунктом, вы бы предпочли, чтобы этот пункт был переработан, либо вовсе исключён. Вторым постом-голосованием я попрошу отметить, какое количество пунктов у вас получилось. Затем в одном или нескольких постах я напишу, что смущает в манифесте конкретно меня - ну и конечно вы сможете откомменировать, если не согласны, или я что-то упустил.

Итак, 12 принципов гибкой разработки, погнали. Пожалуйста, не забывайте считать, со сколькими пунктами вы не согласны либо согласны, но с существенными оговорками.

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

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

3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.

4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.

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

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

7. Работающий продукт — основной показатель прогресса.

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

9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.

10. Простота — искусство минимизации лишней работы — крайне необходима.

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

12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

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

System Design & Highload (Alexey Rybak)

05 December 2023 10:44

Про аутсорсинг, стартапы, и анонс сегодняшней встречи с Горным

Пост для программистов. У Киры Кузьменко в фейсбуке был интересный вопрос: принимать ли оффер, если задачи не выглядят интересными. Ну и Кира пишет, что со стороны всегда сложно понять, насколько задачи интересны или нет, и что хорошему человеку интересных задач обычно приваливает. И что интересность задач – это не самый важный критерий, может быть полно других важных факторов: выход на международный рынок, бренд для cv, компенсация и тд.

Если внимательно посмотреть на первоначальное обращение, то смущает кандидата вот что: компания пишет несложные проекты для зарубежа, “один закончил - начался второй”. Может ли быть такой формат “богатым на достижения”?

Короче. Cитуация простая, очень распространённая. Чувак ищет “достижений”, получил оффер в галеру и подудонился. Да, ему можно аккуратно и корректно рассказать, что и в аутсорсинге может быть миллион плюсов, но давайте быть честными: работа в аутсорсинге может быть полезной, но далеко не для всех.

Есть два мега-минуса:

(1) Финансовая модель таких бизнесов - перепродажа времени сотрудников, причем не мега-дорого (как в бутиковых консалтинг-шопах), а сравнительно дешево (потому что если проекты несложные, то гигантская конкуренция). Это накладывает определенные особенности на культуру в компании. За редкими исключениями, ты там гребец на проекте. Тебе почти ничего не дадут “полировать”, у тебя не будет и той малой доли R&D работы, которая (возможно) будет в продуктовой компании. Иметь влияния на продукт, участвовать в тестировании продуктовых гипотез, анализе данных - всё это возможно будет в продуктовой компании. Возможно - потому что продуктовые компании тоже разные. В очень больших галерах не совсем так, проекты сложнее, и модель от аутсорсинга часто смещается в аутстаффинг.

(2) На рынке есть мнение, что если чел работал в аутсорсинге, то брать его, например, в стартап не нужно. Я лично с этим не совсем согласен, но просто поверьте: такой bias есть, он очень сильный, твое резюме могут отсеять просто на стадии чтения. О, галера? Досвидания. Серьезно. Вероятность устроиться в продуктовую компанию и особенно в стартап после галеры не понижена только если ты в самом начале карьеры.

Поэтому совет очень простой: если ты сомневаешься, идти ли в галеру - не иди.

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

Кстати, про работу в стартапе - сегодня говорим об этом с Сашей Горным на онлайн-встрече в 18:00 мск. Интересно, что он думает про опыт сотрудников в аутсорсинге. Будет стриминг в YouTube тут: AlexeyRybak/streams" rel="nofollow">https://www.youtube.com/@AlexeyRybak/streams. Для участников буткемпа devhands.io зарезервированы места в Zoom (ссылки в комьюнити-чате буткемпа). Саша сделает небольшую презентацию, а затем будут вопросы.

Вот краткий план от автора:
Вы теперь очень крутой эксперт, возможно даже CTO, и одно из возможных направлений развития — работа в стартапе.
1. Чем стартап вообще отличается от корпорации?
2. Почему стоит работать в стартапе, какие есть плюсы? Минусы вам пусть кто-то другой рассказывает 😊
3. Какие бывают стартапы (технологические-продуктовые-промежуточные, российские-международные)
4. Как оценить, стоит ли присоединяться к этому стартапу
5. Какие условия (доли, опционы) реально выторговать в стартапе
6. Что сотруднику надо знать о долях и опционах

Бывшие и будущие стартаперы, приходите, постараемся сделать всё интересно.

System Design & Highload (Alexey Rybak)

20 November 2023 10:05

Стрим с Александром Горным: что бы я хотел знать о стартапах 20 лет назад

5-го декабря 2023 года в 18:00 MSK (GMT+3) в рамках нетворкинг-встреч буткемпа DevHands.io мы проведем стрим c Сашей Горным, сооснователем United Investors, мобильного приложения Мо, и автором блога "Стартап дня". Тема встречи - "Работа в стартапе". Скажу честно, я жду этой встречи сам, и даже подготовил несколько вопросов. У Саши уникальный опыт, причем с разных сторон: и стартапера, и инвестора, и корпоративного офицера. Приходите, будет интересно. Цитируя Сашу, он расскажет о том, что он сам бы хотел знать о стартапах 20 лет назад. Думаю, самое интересное будет про доли, см. программу ниже 😉

Встреча пройдет в формате youtube-стрима (для слушателей буткэмпа будет комната в Zoom).
Программа встречи: презентация и вопросы. Краткое содержание от Александра:
Вы теперь очень крутой эксперт, возможно даже CTO, и одно из возможных направлений развития — работа в стартапе.
1. Чем стартап вообще отличается от корпорации?
2. Почему стоит работать в стартапе, какие есть плюсы? Минусы вам пусть кто-то другой рассказывает 😊
3. Какие бывают стартапы (технологические-продуктовые-промежуточные, российские-международные)
4. Как оценить, стоит ли присоединяться к этому стартапу
5. Какие условия (доли, опционы) реально выторговать в стартапе
6. Что сотруднику надо знать о долях и опционах

Ссылки будут опубликованы здесь, в fb-группе и в комьюнити-чате буткемпа. До встречи!

—
devhands.io/ru/ - хайлоад-буткэмп для девелоперов (своя инфра с первого дня, собираете свой стек, нагружаете, тюните, учитесь масштабировать - 6 месяцев онлайн без отрыва от работы)

System Design & Highload (Alexey Rybak)

05 November 2023 18:14

Современный PostgreSQL заметно обгоняет современный MySQL почти на всх тестах sysbench

Сначала Mark Callaghan аккуратно сравнил перфоманс MySQL и показал на тестах, что с новыми релизами в MySQL с CPU usage становится всё хуже. А затем и вовсе сравнил перфоманс MySQL и PostgreSQL, и вот его выводы:
* На большей части тестов sysbench старые версия MySQL 5.6 и PostgreSQL 11-й версии практически не отличались
* PostgreSQL 16.0 почти во всех тестах дает значительный прирост QPS (queries per second) чем MySQL 8.0.34
* Причина - CPU overhead, который “нарос” в MySQL, а PostgreSQL наоборот его избежал.

Подробности: https://smalldatum.blogspot.com/2023/10/postgres-vs-mysql-impact-of-cpu.html

——
devhands.io/ru/ - хайлоад-буткэмп для девелоперов (своя инфра с первого дня, собираете свой стек, нагружаете, тюните, учитесь масштабировать - 6 месяцев онлайн)
@feedmetoo - новости про разработку, статьи, презентации

System Design & Highload (Alexey Rybak)

30 October 2023 13:10

Fear of truth runs deep

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

Чтобы в этом убедиться, можете посмотреть, например, документ “cacheing strategies”. Он предполагает, например такие паттерны как read/write-thru, но я испытываю искреннюю благодарность: у нас у всех теперь есть +1 вопрос в архитектурной секции интервью: “почему паттерны read/write-thru - фуфло?”.

А сегодня отличный тред начался в LinkedIn, в ответ на пост с рекомендациями для питонистов. Ознакомьтесь, автор Vaughn Vernon - автор монографии по DDD, например.
https://www.linkedin.com/posts/vaughnvernon_dddesign-ugcPost-7124407442628579328-EYTg/

Но старательно, старательно обходят гуру дизайна главный совет, numero uno, “use separate data storage for each microservice”. Чтош, я тепреливо жду, когда же хоть кто-то выйдет и нормально им так всем впеднюрит за инфру, за косты и за по три ненагруженных менеджед-базы на каждый сопливый микросервис: девел, стейджинг и прод.

——
devhands.io/ru/ - хайлоад-буткэмп для девелоперов (своя инфра с первого дня, собираете свой стек, нагружаете, тюните, учитесь масштабировать - 6 месяцев онлайн)
@feedmetoo - новости про разработку, статьи, презентации