#анонсы

10-ого февраля для сообщества AWS Казахстан я и мои коллеги предоставим интересный контент про всякое!

1. Талгат Нурлыбаев, МУИТ расскажет про академическую программу Amazon AWS в МУИТ и Казахстане.
2. Анатолий Макеев, RedPad Games - про личный опыт использования AWS в GameDev с использованием managed services.
3. Карен Товмасян, EPAM - про тоску смертную под названием Compliance и как с помощью AWS Config и SSM обеспечить полный контроль над состоянием своей инфраструктуры.
4. Непревзойденный Василий Пантюхин, AWS расскажет про конкурентный доступ к файлам и как готовить Amazon EFS.

Выступление будет транслироваться в Twitch.
Время проведения мероприятия: 15.00-17.00 по Москве.

Начинаем через час!

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

Время от времени я провожу system design интервью, которые в простонародье известны как архитектурные. Многим моим читателям такой вид собеседования должен быть знаком: предлагается спроектировать что-то, и у вас 45 минут чтобы собрать все минимальные требования, набросать высокоуровневый дизайн, в нужных местах опускаясь ниже и адресуя ряд пунктов.

Очевидное отличие этого интервью от других (например от алгоритмов) - отсутствие одного правильного ответа и какого-то логического конца. Напротив, здесь идет игра против времени и нужно “успеть” покрыть максимум тем.

Поэтому к такому интервью нужно относиться как к reverse bullshit bingo: чем больше ключевых слов вы успеете назвать (CDN, LB, Cache, Queue, DB, NoSQL, SQL, Read/Write API, Sharding, Consensus, CAP, и т.д.) - тем лучше. Интервьюер, cпускаясь в нужных местах пониже, проверяет вашу эрудицию.

Дескать, сказал “балансировщик” - накинь базовые алгоритмы балансировки. Кеширование - caching algorithms и eviction policies. Базы данных - ну расскажи про индексы и какие бывают разновидности. Тут можно помнить, что не все удастся знать наизусть, да и интервьюер не дурак - будет лезть туда, где сам разбирается.

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

Неопытный кандидат в таком случае начинает нервничать - ведь есть где-то “правильный” ответ, который все аспекты учитывает! И ищет собеседуемый серебряную пулю, да не найдет - нет ее. Ваш покорный, кстати, не исключение.

Достаточно сказать: “Да, можно сделать. Но”. И далее списком откупы.

#пятничное

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

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

К чему это я? Буквально на днях, Земфира выпустила… "коллаб" с разработчиками игры, где зрителю предлагается взглянуть на эту историю совсем под другим углом - страх за умирающих в одиночестве родителей, тонущих в жиже из дерьма и масла; тайная любовь, растворяющаяся буквально в руках героя; чувство вины; родной дом и атрибуты детства, разрушающиеся под ударами аукционного молотка.

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

Когда соединяешь квадратики одинакового цвета, в голову лезут разные мысли… но точно не такие.

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

В продолжение https://t.me/manandthemachine/650

Олег очень правильное замечание сделал. Есть "классический" system design, а есть NALSD - Non-Abstract Large System Design.

Иными словами, эскалаторы в ТЦ - это NALSD. Запили мне Инстаграм - это SD.

NALSD очень любят FAANG, потому что к FAANG'у ваши знания кубов и авсов неприменимы - у них свои системы, и учиться работать с ними придется по новой. Там от вас просят набросать некий дизайн, а потом наскоро посчитать сколько и какого размера узлов надо, чтобы обработать входящий трафик с объемом 3.57 Гбит/с.

В обычном дизайне подход более прагматичный и приближенный к обыденности. Он, повторюсь, ожидает от вас reverse bullshit bingo ("назови так много ключевых слов, сколько успеешь") и готовность утонуть там с интервьюером.

Состоит оно из 4 шагов:
1. Сбор требований
2. Высокоуровневый дизайн
3. Низкоуровневый дизайн в некоторых частях
4. Обоснование решения

Что SD, что NALSD, кстати, проверяют умение кандидата ориентироваться в ограниченном пространстве и с минимальным набором требований.

Так, например, у меня был диалог, где я проектировал систему сбора метрик. Как ожидается, я спросил по объемам трафика.

- Ну сам как думаешь?
- Ну у меня порядка 2000 тысяч продюсеров, каждый будет слать метрики раз в минуту. Одна метрика будет висеть.. ну максимум 4 кб. Я могу предположить, что одновременно метрик будет отправляться 10? Или может больше?
- Может больше.
- 100?
- Может и 100, а может и больше.
- Ну тогда два стула: либо я буду начинаю с 10 и делаю throttling, либо считаем ресурсы из расчета 1000 метрик с индивидуального продюсера в секунду. Но это будет неоправданно дорого.

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

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

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

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

Я сижу перед экраном своего компьютера, на лбу начинает выступать испарина. “Как это - нет мониторинга сервиса?!” - я возмущаюсь про себя. - “Метрики с сервиса собираете, а мониторинга самого процесса нет?! Что за бред???”

Я делаю глубокий вдох и прошу человека по ту сторону выполнить команду systemctl status $service_name.

“И что мне это даст?” - гаденько интересуется мой собеседник. Я игнорирую его мерзкий прищур и уточняю версию дистрибутива. Убедившись, что это именно 7-ой CentOS, я говорю, что вывод этой команды покажет состояние демона и последние несколько строк лога.

“Подождите секунду.” - человек по ту сторону экрана печатает на импровизированной клавиатуре, смотрит на экран и говорит: “Я вижу там ошибку.”

- И что в ней?
- Unknown Symbol.
- Мне нужен доступ к терминалу, сама ошибка мне ни о чем не говорит.

———————————————

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

Предыдущие 30 минут я занимался тем, что “чинил сломавшийся доступ по SSH” в условиях нулевой видимости. Задача говорила, что инженерная группа выкатила мажорный релиз, в котором было очень много изменений, и с тех пор пропал доступ к машинам. Интервьюер помогал мне двигаться к корню проблемы, а я строил гипотезы - от лежащего SSH демона до изменения MTU.

В основном интервью-секция troubleshooting представляет собой неабстрактную несуществующую проблему, которую кандидату предлагается решить. Под проблемой может быть что угодно - вырос response time, отвалился и не стартует процесс, регулярно происходит split brain. Проще говоря - все, что придет на ум интервьюера.

Так, например, за всю карьеру мне попадалось следующее:
- Сломался сервер, подписывающий сертификаты для SSH
- Случайным образом на кластере скачет response time
- Из-за незакрытого файла сломалась СУБД
- Увеличился вдвое объем входящего трафика, что делать (spoiler alert- ничего)

Само собеседование все еще представляет собой reverse bullshit bingo, но уже в обратную сторону. Теперь нужно не угадывать нужные ключевые слова, но и подробно разъяснять каждое свое действие, принцип работы и уточнять поведенческие детали.

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

Ирония в том, что Пол Викси - один из создателей DNS. :)

#машины_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 в порядке и будет таковым; б) его ценят и любят за его экспертность и это так и останется даже если он будет делиться знаниями; в) понять его мотивы и попробовать придумать, как в них (и возможно ли) в них встроить идею о передаче знаний.
Если удастся договориться с Алексеем, то вытаскивание и распространение знаний станет уже его осознанной и прямой задачей и останется только помогать ему методологически и ресурсно. А если не удастся — надо попробовать найти способ аккуратно разойтись.

#пятничное

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

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

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