Человек и машина

2021-02-24 18:02:13 #машины_разное

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

Я делаю глубокий вдох и прошу человека по ту сторону выполнить команду 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, хоть перезагружайте сервер - интервьюер будет направлять вас оттуда сюда и отсюда туда, лишь бы успеть покрыть как можно больше за ограниченное время. Открыть/Комментировать

2021-02-22 12:00:46 #машины_разное

В продолжение 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. Это вообще отдельная песня, если наберется больше ста больших пальцев - расскажу. Открыть/Комментировать

2021-02-19 14:55:45 #пятничное

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

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

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

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

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

2021-02-16 18:50:08 #машины_разное #люди

Время от времени я провожу 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). По мере роста архитектуры будут добавляться все новые и новые требования, и одно из них может выбить из колеи, потому что нивелирует все остальные.

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

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

2021-02-10 14:02:54 #анонсы 10-ого февраля для сообщества AWS Казахстан я и мои коллеги предоставим интересный контент про всякое! 1. Талгат Нурлыбаев, МУИТ расскажет про академическую программу Amazon AWS в МУИТ и Казахстане. 2. Анатолий Макеев, RedPad Games - про личный… Открыть/Комментировать

2021-02-01 16:29:53 #анонсы

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 по Москве. Открыть/Комментировать

2021-01-27 12:48:20 #машины_разное

Python: Beautiful is better than ugly
Also Python: https://twitter.com/gvanrossum/status/1354305179244392453 Открыть/Комментировать

2021-01-25 22:50:08 #машины_aws

Мой “контент-план” по блогам на Январь 2021 официально выполнен!

Вниманию моих читателей - финальная (на данный момент) глава по DynamoDB.
Моделирование данных, лучшие практики, Single-Table Design… И разумеется, полезные ссылки для страждущих! Открыть/Комментировать

2021-01-23 13:34:09 Знаете, что мне больше всего нравится в этом видео?

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

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

2021-01-23 13:32:09 #жиза Открыть/Комментировать