#машины_aws #машины_разное

Все-таки удивительно, насколько история повторяет себя. Стоит какому-то крупному продукту сделать очередной рефакторинг, так астрологи объявляют неделю трендов.

Стоило Netflix'у рассказать о своем космическом изобретении, как многие из русскоязычной ИТ-тусовочки стали снова писать про Serverless.

Ну, чем бы дитя не тешилось.

Что по сути сделал известный стриминг провайдер? Асинхронную оркестрацию бизнес-логики с использованием AWS Lambda в качестве вычислительного движка, прикрутив к ней свой внутренний инструментарий (трассировка, мониторинг, интеграции и т.д.).

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

Ну или имплементация неочень. :)

Раз колесо Сансары делает очередной оборот, вопрос дорогой аудитории: надо ЕЩЕ РАЗ рассказывать про Serverless? Или лучше про то, как автор открыл для себя TCP window и qdisc?

#машины_разное

Я вас обожаю! Уже который по счету опрос, и оба варианта почти одинаково набирают по процентам.

Про TCP, а конкретно про ту часть, про которую я раньше не слышал, я обязательно напишу на следующей неделе, как и про serverless (несколько позже).

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

В ней все, что я люблю: ИТ-стоицизм, принятие неизбежного, черные лебеди, known unknowns и unknown unknowns... Словом, все, с чего начинается и чем заканчивается мой рабочий день.

#машины_разное

Неплохо так бомбануло вчера, да? Честное слово, еще одна авария из-за регулярок (я все еще помню историю с Cloudflare), и я всерьез задумаюсь о выходе из профессии.

Обещанное про TCP и его возможности. Я уверен, вы догадались, что речь пойдет не о рукопожатиях (вы их и без меня знаете, а если не знаете, то срочно идите знать), но про TCP backlog, window, qdisc и прочие прелести, о которых я узнал вот буквально в этом году.

Век живи.

Узнал я про них не абы откуда, а из второго издания Systems Performance Брендана Грегга (которого вы знаете как парня, любящего покричать на диски). Производительность сети вообще несправедливо игнорируемая тема: новое поколение инженеров предпочитает закидывать проблему ресурсами, старое поколение винит во всем сетевиков, либо знает, что сеть можно тюнить на уровне сетевой подсистемы Linux Kernel (эти ребята штучный товар и сидят конечно же в FAANG’ах).

У TCP есть backlog - очередь из сегментов на обработку, каждому порту назначается своя очередь, если эта очередь забивается (tcp congestion), то пакеты начинают теряться. Для управления перегрузкой используются так называемые “алгоритмы избежания сетевой перегрузки” (их много). Сама подсистема использует всякие трюки в виде congestion windows и slow start.

Но управление очередью это еще полбеды. Каждое соединение требует рукопожатия, что на больших объемах негативно влияет на пропускную способность сети. Если сетка у нас уморительно стабильна и каждое соединение успешно “рукопожимается”, то накрутить оборотов можно с помощью TCP initial/receive window. Эти два подхода позволяют добавить небольшой асинхронности сетевой передаче, отправляя и принимая часть сегментов прежде, чем ответить ACK’ом. В довесок к этому есть еще SACK и TCP timestamps - результат схожий, принцип работы несколько другой.

Что еще есть прикольного в этой вашей сетке? TCP/Generic Segment Offloading. Ядро генерирует super packet размером до 64 Кб, который затем нарезается на сегменты непосредственно перед отправкой на сетевой устройство (GSO). Современные сетевые карты могут делать это сами (TSO), так что ядро даже этим не заморачивается.

Ну и напоследок - queueing discipline или qdisc. Qdisc работает на L2-L3 и является планировщиком отправки пакетов/кадров. По умолчанию используется FIFO, но возможностей там гораздо больше, даже есть Token bucket.

В книге Грегга, кстати, есть старый кусок сетевой конфигурации, которая раньше использовалась в Netflix.

#анонсы #машины_aws

Я почти закончил работу над статьей про Serverless.

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

#машины_aws

Должен признать, писать блоги по-русски становится все сложнее и сложнее.

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

#люди

В очередной раз прочитав очередной пост на Хабре про очередное (неудачное?) собеседование в очередную Большую Техническую Компанию, а также комментарии к ней, где люди в очередной раз заявляют о преимуществе простого и понятного кода со сложностью O(n^2) над сложным кодом со сложностью O(logn), я думаю пора поговорить о такой важной в нашей индустрии теме как дальновидность.

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

Как вы догадались, эти две ипостаси на работе друг с другом не пересекаются. И слава Богу.

Режим “…, …, и в продакшон” - это этакий кризисный режим работы в условиях цейтнот: катиться надо сейчас, времени думать нет, time to market, impact assessment, blast radius, workaround, и много других прикольных словообразований. А все потому что тут принимается решение: сделать плохо, но запуститься, либо сделать хорошо, но никогда. И бизнес (собственно ваш - вы же мамкин предприниматель) не готов ждать.

И никогда не будет, так уж он устроен. Другое дело, когда вы оказываетесь погруженным в масштаб… Нет, не так.

В МАСШТАБ.

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

Как сказал мой шеф: “Мы проектируем крышу без дома. В нашей профессии так можно, если мы все правильно предусмотрим.”

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

Мне с ними еще интегрироваться потом.

Причем здесь сложность алгоритма? Ну вот пример: вы, внезапно - фронтендер. Запуск вашей компании планируется в понедельник, сейчас пятница, бекендеры не успевают выкатить для вас GraphQL, который эффективно и дешево выдаст нужные данные. У вас два пути - отложить релиз, или воспользоваться уже legacy REST, выкидывая с десяток запросов с клиента при загрузке страницы.

Очевидно, вы пойдете на тот самый архитектурный tradeoff и пожертвуете производительностью продукта в угоду time to market. Заводите себе задачу на рефакторинг, планируете к ней вернуться, когда завезут GraphQL Спойлер - вы скорее уволитесь, чем отрефакторите, но это неважно, потому что когда это станет проблемой (если когда-то и станет), ваша голова будет болеть совсем о другом.

А другой пример и того скучный: для красоты и чистоты и личного удовлетворения, или просто по незнанию прошлись по массиву 4 раза. И все было ничего, пока массив стал не 20 элементов, а 20 миллионов. Масштаб пришел откуда не ждали.

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

#пятничное

Нет ничего прикольнее, чем смотреть, как нудит дед.

Особенно, когда нудит по делу.

#машины_aws

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

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

Что я и сделал.

А у меня тут еще один флешмоб!

Friendly Asked Questions #1 — про уникального эксперта

Я руководитель команды из 10 человек. Когда мой разработчик Алексей уходит в отпуск, куча вопросов "встаёт" до его возвращения, нет никого, кто был бы настолько же в курсе отдельных частей проекта. Разработчику это похоже очень нравится, на моё предложение, чтобы он кого-то научил, передал свои знания реагирует агрессивно. Что делать? Если будут проблемы — всех собак повесят на меня.

Ответы дали авторы каналов Уютный Адочек, Человек и машина и Scrum Master Notes
А мы ждём ваших вопросов в: https://forms.gle/sKyaEuqQMMyFJBxJ8

@scrummasters — Василий Зорин

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

@manandthemachine — Карен Товмасян

Ох уж эти Всезнающие Алексеи!
Позволю предположить, что Алексей в конторе был задолго до %username%, иначе непонятно, как подчиненный смог выстроить такую политическую игру.
Не стоит просить кого-то заняться обучением других, это должно быть не просьбой, а задачей.
Если же человек не хочет выполнить такое поручение, то стоит задаться вопросом, не боится ли этот человек потерять ценность для команды и проекта/продукта? Я уверен, нормальная встреча 1-1 приоткроет завесу тайны.
Но предположим, что Леха-карьерист таким образом решил кого-то (вас) подсидеть, и поэтому контакт не налаживается. Решение в таком случае жесткое: уволить и принять удар.
Да, с собаками придется повозиться, но я не слышал ни об одном предприятии, которое закрылось из-за ухода ключевого сотрудника.

@lovely_it_hell — Цупко Игорь

Многое зависит от того, сколько у вас времени на решение этой проблемы и какие есть доп. ресурсы. Когда они есть – можно либо вникнуть самому, либо попробовать организовать каким-то образом вытаскивание информации из Алексея (даже при наличии сопротивления).
Сложнее — если ресурсов нет.
Мне бы в первую очередь хотелось поговорить с Алексеем, чтобы, а) показать ему, что его job security в порядке и будет таковым; б) его ценят и любят за его экспертность и это так и останется даже если он будет делиться знаниями; в) понять его мотивы и попробовать придумать, как в них (и возможно ли) в них встроить идею о передаче знаний.
Если удастся договориться с Алексеем, то вытаскивание и распространение знаний станет уже его осознанной и прямой задачей и останется только помогать ему методологически и ресурсно. А если не удастся — надо попробовать найти способ аккуратно разойтись.

#пятничное

Да, я добавил комменты!

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

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

#машины_разное

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

Это не я, это все пандемия ваша дурацкая!

По рекомендации приятеля вступил в клуб Вастрика, а раз я несу кому-то деньги (целый доллар!), то хочу их отбить (целый доллар!!!). Вот так я и прочитал Ту Самую Статью Про Квантовые Компьютеры, увидел словосочетание "Отрицательная Вероятность", и теперь это словосочетание не дает мне покоя.

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

И я сейчас не про known unknowns, я осведомлен, что есть машинное обучение, микрофронтенды, Rust и даже C++ - словом, все, что я и так не знаю и могу сесть изучать, но это "не то".

Интерес именно в unknown unknowns, особенно когда те перестают быть unknown. До отрицательной вероятности меня так взбудоражило только внутреннее устройство индустрии телевещания. Одни только digital assets с метаданными чего стоят.

#машины_разное

По долгу (уже новой) службы мне приходится иметь дело с PCI-DSS - набором регуляторных требований к программным продуктам, которые хранят и/или обрабатывают информацию с платежных карт.

У PCI есть одно интересное требование, которое в упрощенной форме гласит: "разработчики не могут разворачивать свой код в production". Это очень интересное требование, потому что под "разработчика" может попасть каждый, кто вносит изменения в кодовую базу, попадающую под PCI.

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

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

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

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

Friendly Asked Questions #3 — про уровень зарплат

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

Ответы дали авторы каналов Уютный Адочек, DocOps, Человек и Машина, Евгений Потапов
А мы ждём ваших вопросов в: https://forms.gle/sKyaEuqQMMyFJBxJ8

Евгений Потапов (канал @eapotapov_channel)

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

Карен Товмасян (канал @manandthemachine)

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

Поэтому даже приехав из уездного города N, где зарплата была 30к, в Первопрестольную, то ценник сразу обретает нолик с конца, что работает и в обратную сторону. Не вы первый задаетесь этим вопросом, кстати. 😉

Ник Волынкин (канал @docops)

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

Цупко Игорь (канал @lovely_it_hell)

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

#машины_разное

Гвидо ван Россум, отец Python и вернувшийся из пенсии в Microsoft инженер, поставил перед собой очень амбициозную цель, а именно - увеличить производительность своего детища аж в два раза.

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

Впрочем, мой интерес чисто технический, что именно собираются сделать для увеличения производительности? Поэтому я открыл PEP-554, автор которого отдельно отмечает, что не намерен решать проблему GIL (но мы-то с вами все понимаем).

Способов обойти GIL и так хватает: от использования multiprocessing до других движков, например PyPy.

PEP-554 интересен тем, что предлагает по-новому взглянуть на sub-интерпретаторы и (пере)изобрести конкурентное программирование. Причем пользоваться эти можно будет донельзя легко. Вот кусок кода, прямиком из PEP:

interp = interpreters.create()
print('before')
interp.run('print("during")')
print('after’)

Но не это самое “вкусное”. Если пройти дальше по предложению до раздела “About Subinterpreters”, то можно увидеть слово, которое очень знакомо разработчикам на Golang - каналы! По словам автора Предложения, каналы будут единственным объектом, доступным всем интерпретаторам, а обмен объектов будут проходить через них.

Подытожим: в версии 3.11 собираются ускорить CPython, и поможет нам в этом новый модуль interpreters, который имплементирует конкурентное программирование, схожее с Golang.

Вот что скучная пенсия с людьми делает!

#машины_разное

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

Оно и очевидно, observability попала в “тренды” незадолго после появления eBPF, и к кому бы не сходить за ее определением, как к одному из пионеров индустрии… Однако, получаем больше вопросов, чем ответов.

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

Отличий как таковых и нет - наблюдаемость дополняет мониторинг. Если мониторинг опирается на определенные метрики, глядя на которые можно понять, как чувствует себя программный продукт, в инструментарий observability еще входят обработка логов и отслеживание запросов (tracing).

Что позволяет “наблюдать” не только за одной системой, но и ее связкой с остальными.

Спорим, это снова Cloudflare?

UPD: Ан нет, на этот раз возможно Fastly.

#машины_разное

Прекрасный повод в очередной раз поделиться одним из моих любимых докладов.