#машины_разное
Во время своего выступления Дор Лаор, СЕО Scylla анонсировал новый проект Circe, который в корне меняет структуру консенсуса ScyllaDB.
Взамен Paxos в ядро этого немалоизвестного конкурента Cassandra и DynamoDB будет использоваться Raft, что по словам Дора сделано в угоду консистентности и позволяет быстрее синхронизировать новые узлы в кластере.
Интересно попробовать собрать POSIX FS over Scylla... когда-нибудь.
Во время своего выступления Дор Лаор, СЕО Scylla анонсировал новый проект Circe, который в корне меняет структуру консенсуса ScyllaDB.
Взамен Paxos в ядро этого немалоизвестного конкурента Cassandra и DynamoDB будет использоваться Raft, что по словам Дора сделано в угоду консистентности и позволяет быстрее синхронизировать новые узлы в кластере.
Интересно попробовать собрать POSIX FS over Scylla... когда-нибудь.
ScyllaDB
Making ScyllaDB a Monstrous Database: Introducing Project Circe - ScyllaDB
Project Circe is a year-long initiative to make ScyllaDB even more of a monstrous database, improving performance, scalability and elasticity.
Всем зашла статья про олдов? Василия знаю лично, и получаю удовольствие не только когда слушаю его, но и когда читаю.
Комментировать статью я не буду, потому что в этом нет необходимости. Расскажу две истории из жизни.
Первый за долгое время пост по тегу #жиза. 🙂
---
Будучи системным инженером на заводе Рено, я отвечал за IP телефонию и автоматизированные контакт-центры на базе Cisco UCCX. Все это чудо чудное было на поддержке от одного крупного оператора связи в России, поэтому ко мне часто командировали одного очень крутого инженера. Как сейчас помню, Серега Лавров. Очень умный и в очках.
Так вот, под монотонный бубнеж записи из IVR, Серега сказал, что пора бы ему менять профиль деятельности и идти в менеджмент. А все потому что я за полгода, что с ним работал, с нуля выучил, как алгоритмы в UCCX делать, да что это за SIP транки непонятные - дескать молодежь технические навыки быстрее обретает, конкурентоспособной становится.
Серега, если ты это видишь - надеюсь у тебя все получилось!
---
На очередном звонке мой шеф делился отзывами о моей скромной деятельности - и одно замечание мне очень понравилось.
По своей гиперактивной природе, я стремлюсь любое изменение дотащить до продукта как можно скорее. Fail fast, fail cheap, trial-and-error, вот это все. Ну и как результат, нарываюсь на преграды, которые надо обходить, а обходить бы не пришлось, будь я несколько предусмотрительней, да и проговори идею с парой-тройкой архитекторов. Всего-то несколько десятков писем, с десяток часовых созвонов по Webex - кого волнуют эти человеко-дни вообще?
Шеф же сказал, что ошибки эти я совершаю, потому что раньше их не совершал - не попадалось такое, и внутренняя база знаний о подобном сценарии не знает. Эти самые осознанность и предусмотрительность приходят как раз вместе с опытом и без этого опыта, добываемого через ошибки, нужные навыки не приобрести.
Комментировать статью я не буду, потому что в этом нет необходимости. Расскажу две истории из жизни.
Первый за долгое время пост по тегу #жиза. 🙂
---
Будучи системным инженером на заводе Рено, я отвечал за IP телефонию и автоматизированные контакт-центры на базе Cisco UCCX. Все это чудо чудное было на поддержке от одного крупного оператора связи в России, поэтому ко мне часто командировали одного очень крутого инженера. Как сейчас помню, Серега Лавров. Очень умный и в очках.
Так вот, под монотонный бубнеж записи из IVR, Серега сказал, что пора бы ему менять профиль деятельности и идти в менеджмент. А все потому что я за полгода, что с ним работал, с нуля выучил, как алгоритмы в UCCX делать, да что это за SIP транки непонятные - дескать молодежь технические навыки быстрее обретает, конкурентоспособной становится.
Серега, если ты это видишь - надеюсь у тебя все получилось!
---
На очередном звонке мой шеф делился отзывами о моей скромной деятельности - и одно замечание мне очень понравилось.
По своей гиперактивной природе, я стремлюсь любое изменение дотащить до продукта как можно скорее. Fail fast, fail cheap, trial-and-error, вот это все. Ну и как результат, нарываюсь на преграды, которые надо обходить, а обходить бы не пришлось, будь я несколько предусмотрительней, да и проговори идею с парой-тройкой архитекторов. Всего-то несколько десятков писем, с десяток часовых созвонов по Webex - кого волнуют эти человеко-дни вообще?
Шеф же сказал, что ошибки эти я совершаю, потому что раньше их не совершал - не попадалось такое, и внутренняя база знаний о подобном сценарии не знает. Эти самые осознанность и предусмотрительность приходят как раз вместе с опытом и без этого опыта, добываемого через ошибки, нужные навыки не приобрести.
Хабр
Олды в ИТ
Когда ты молод, ты «бессмертен» и не задумываешься о старости. Есть просто уверенность, что если много и хорошо работать, то твоя карьера и доходы будут неуклонно расти. Следуя этой стратегии, ты...
#машины_разное
Просто потрясающий lightning доклад про интересные особенности двух небезызвестных языков.
За ссылку спасибо @zn11ch, орал как лама.
Просто потрясающий lightning доклад про интересные особенности двух небезызвестных языков.
За ссылку спасибо @zn11ch, орал как лама.
Знаете, что мне больше всего нравится в этом видео?
Цепочка открытых вкладок! Видно, что сначала человек пытался быстро решить проблему по верхней выборке StackOverflow, затем полез в документацию и архитектуру.
Квинтэссенцией было бы читать исходники того, что он так усердно пытался заставить работать.
Цепочка открытых вкладок! Видно, что сначала человек пытался быстро решить проблему по верхней выборке StackOverflow, затем полез в документацию и архитектуру.
Квинтэссенцией было бы читать исходники того, что он так усердно пытался заставить работать.
#машины_aws
Мой “контент-план” по блогам на Январь 2021 официально выполнен!
Вниманию моих читателей - финальная (на данный момент) глава по DynamoDB.
Моделирование данных, лучшие практики, Single-Table Design… И разумеется, полезные ссылки для страждущих!
Мой “контент-план” по блогам на Январь 2021 официально выполнен!
Вниманию моих читателей - финальная (на данный момент) глава по DynamoDB.
Моделирование данных, лучшие практики, Single-Table Design… И разумеется, полезные ссылки для страждущих!
Medium
Amazon DynamoDB Deep Dive. Chapter 4: Data Modeling, Best Practices, What’s next
The story of one of the world’s fastest database in a human-friendly format
#машины_разное
Python: Beautiful is better than ugly
Also Python: https://twitter.com/gvanrossum/status/1354305179244392453
Python: Beautiful is better than ugly
Also Python: https://twitter.com/gvanrossum/status/1354305179244392453
Twitter
Guido van Rossum
What does this print? x = 0 y = 0 def f(): x = 1 y = 1 class C: print(x, y) # What does this print? x = 2 f() From blog.kevmod.com/2014/06/what-d… (@kevmod) Still in Python 3.9!
#анонсы
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 по Москве.
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 по Москве.
Twitch
AWSPoRusski - Twitch
Бесплатные Twitch стримы для обсуждения новинок и анонсов конференции re:Invent
#машины_разное #люди
Время от времени я провожу 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). По мере роста архитектуры будут добавляться все новые и новые требования, и одно из них может выбить из колеи, потому что нивелирует все остальные.
Неопытный кандидат в таком случае начинает нервничать - ведь есть где-то “правильный” ответ, который все аспекты учитывает! И ищет собеседуемый серебряную пулю, да не найдет - нет ее. Ваш покорный, кстати, не исключение.
Достаточно сказать: “Да, можно сделать. Но”. И далее списком откупы.
Время от времени я провожу 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. Мужичок, по совместительству профессиональный дворецкий, приезжает в старинный особняк навестить своих престарелых родителей. По приезду он обнаруживает, что дом в крайне обветшалом состоянии, родители хотят его продать, поскольку обслуживать его уже нет ни сил, ни ресурсов. Наш батлер не из робкого десятка и категорически против сдавать родовое поместье с молотка.
Игра по сути обычная головоломка, и с каждым решением проходим дальше по сюжетным квестам: починили лестницу, заменили пол, исправили водопровод, установили новую кухню. Откуда у дворецкого ресурс - неважно. Все-таки личный дворец могут себе позволить немногие, а значит у семейства все хорошо с финансами.
К чему это я? Буквально на днях, Земфира выпустила… "коллаб" с разработчиками игры, где зрителю предлагается взглянуть на эту историю совсем под другим углом - страх за умирающих в одиночестве родителей, тонущих в жиже из дерьма и масла; тайная любовь, растворяющаяся буквально в руках героя; чувство вины; родной дом и атрибуты детства, разрушающиеся под ударами аукционного молотка.
Весь этот гротеск и мрак снится нашему лысеющему чувачку, пока он не просыпается в своей кровати, и по его уставшему лицу я понимаю, что этот кошмар навещает его не в первый раз.
Когда соединяешь квадратики одинакового цвета, в голову лезут разные мысли… но точно не такие.
Есть такая мобильная игра Homescapes. Мужичок, по совместительству профессиональный дворецкий, приезжает в старинный особняк навестить своих престарелых родителей. По приезду он обнаруживает, что дом в крайне обветшалом состоянии, родители хотят его продать, поскольку обслуживать его уже нет ни сил, ни ресурсов. Наш батлер не из робкого десятка и категорически против сдавать родовое поместье с молотка.
Игра по сути обычная головоломка, и с каждым решением проходим дальше по сюжетным квестам: починили лестницу, заменили пол, исправили водопровод, установили новую кухню. Откуда у дворецкого ресурс - неважно. Все-таки личный дворец могут себе позволить немногие, а значит у семейства все хорошо с финансами.
К чему это я? Буквально на днях, Земфира выпустила… "коллаб" с разработчиками игры, где зрителю предлагается взглянуть на эту историю совсем под другим углом - страх за умирающих в одиночестве родителей, тонущих в жиже из дерьма и масла; тайная любовь, растворяющаяся буквально в руках героя; чувство вины; родной дом и атрибуты детства, разрушающиеся под ударами аукционного молотка.
Весь этот гротеск и мрак снится нашему лысеющему чувачку, пока он не просыпается в своей кровати, и по его уставшему лицу я понимаю, что этот кошмар навещает его не в первый раз.
Когда соединяешь квадратики одинакового цвета, в голову лезут разные мысли… но точно не такие.
YouTube
земфира — остин
земфира — музыка, слова, вокал, программирование, продюсирование
дмитрий емельянов — клавишные, гитара, программирование, продюсирование, сведение
дэн маринкин — барабаны
jolyon thomas — сведение
george shilling — мастеринг
koshta — продакшн-студия
petrick…
дмитрий емельянов — клавишные, гитара, программирование, продюсирование, сведение
дэн маринкин — барабаны
jolyon thomas — сведение
george shilling — мастеринг
koshta — продакшн-студия
petrick…
#машины_разное
В продолжение https://t.iss.one/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. Это вообще отдельная песня, если наберется больше ста больших пальцев - расскажу.
В продолжение https://t.iss.one/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. Это вообще отдельная песня, если наберется больше ста больших пальцев - расскажу.
Telegram
Человек и машина
#машины_разное #люди
Время от времени я провожу system design интервью, которые в простонародье известны как архитектурные. Многим моим читателям такой вид собеседования должен быть знаком: предлагается спроектировать что-то, и у вас 45 минут чтобы собрать…
Время от времени я провожу system design интервью, которые в простонародье известны как архитектурные. Многим моим читателям такой вид собеседования должен быть знаком: предлагается спроектировать что-то, и у вас 45 минут чтобы собрать…
#машины_разное
Я сижу перед экраном своего компьютера, на лбу начинает выступать испарина. “Как это - нет мониторинга сервиса?!” - я возмущаюсь про себя. - “Метрики с сервиса собираете, а мониторинга самого процесса нет?! Что за бред???”
Я делаю глубокий вдох и прошу человека по ту сторону выполнить команду
“И что мне это даст?” - гаденько интересуется мой собеседник. Я игнорирую его мерзкий прищур и уточняю версию дистрибутива. Убедившись, что это именно 7-ой CentOS, я говорю, что вывод этой команды покажет состояние демона и последние несколько строк лога.
“Подождите секунду.” - человек по ту сторону экрана печатает на импровизированной клавиатуре, смотрит на экран и говорит: “Я вижу там ошибку.”
- И что в ней?
- Unknown Symbol.
- Мне нужен доступ к терминалу, сама ошибка мне ни о чем не говорит.
———————————————
Интервьюер, притворяющийся коллегой, пришедшим с проблемой, с довольным видом откидывается в кресле. Мы достаточно далеко продвинулись, чтобы он получил нужные сигналы, чтобы продолжить общение со мной.
Предыдущие 30 минут я занимался тем, что “чинил сломавшийся доступ по SSH” в условиях нулевой видимости. Задача говорила, что инженерная группа выкатила мажорный релиз, в котором было очень много изменений, и с тех пор пропал доступ к машинам. Интервьюер помогал мне двигаться к корню проблемы, а я строил гипотезы - от лежащего SSH демона до изменения MTU.
В основном интервью-секция troubleshooting представляет собой неабстрактную несуществующую проблему, которую кандидату предлагается решить. Под проблемой может быть что угодно - вырос response time, отвалился и не стартует процесс, регулярно происходит split brain. Проще говоря - все, что придет на ум интервьюера.
Так, например, за всю карьеру мне попадалось следующее:
- Сломался сервер, подписывающий сертификаты для SSH
- Случайным образом на кластере скачет response time
- Из-за незакрытого файла сломалась СУБД
- Увеличился вдвое объем входящего трафика, что делать (spoiler alert- ничего)
Само собеседование все еще представляет собой reverse bullshit bingo, но уже в обратную сторону. Теперь нужно не угадывать нужные ключевые слова, но и подробно разъяснять каждое свое действие, принцип работы и уточнять поведенческие детали.
При этом абстрагированный масштаб проблемы позволяет разгуляться на полную катушку вплоть до того, чтобы похвастаться прочитанной статьей про связь NUMA и OOM Killer. Но в целом этот вид интервью - чистое сисадминство с неограниченной фантазией. В вашем арсенале все, что вы понимаете и с чем умеете работать. Хоть пройдитесь по коду профайлером, хоть запускайте
Я сижу перед экраном своего компьютера, на лбу начинает выступать испарина. “Как это - нет мониторинга сервиса?!” - я возмущаюсь про себя. - “Метрики с сервиса собираете, а мониторинга самого процесса нет?! Что за бред???”
Я делаю глубокий вдох и прошу человека по ту сторону выполнить команду
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, хоть перезагружайте сервер - интервьюер будет направлять вас оттуда сюда и отсюда туда, лишь бы успеть покрыть как можно больше за ограниченное время.#машины_aws #машины_разное
Все-таки удивительно, насколько история повторяет себя. Стоит какому-то крупному продукту сделать очередной рефакторинг, так астрологи объявляют неделю трендов.
Стоило Netflix'у рассказать о своем космическом изобретении, как многие из русскоязычной ИТ-тусовочки стали снова писать про Serverless.
Ну, чем бы дитя не тешилось.
Что по сути сделал известный стриминг провайдер? Асинхронную оркестрацию бизнес-логики с использованием AWS Lambda в качестве вычислительного движка, прикрутив к ней свой внутренний инструментарий (трассировка, мониторинг, интеграции и т.д.).
Не скажу, что делал что-то подобное раньше, но бизнес-логику на FaaS имплементировал, и аплодисментов не слышал. Наверное авторитета не хватает, или масштабы не те.
Ну или имплементация неочень. :)
Раз колесо Сансары делает очередной оборот, вопрос дорогой аудитории: надо ЕЩЕ РАЗ рассказывать про Serverless? Или лучше про то, как автор открыл для себя TCP window и qdisc?
Все-таки удивительно, насколько история повторяет себя. Стоит какому-то крупному продукту сделать очередной рефакторинг, так астрологи объявляют неделю трендов.
Стоило Netflix'у рассказать о своем космическом изобретении, как многие из русскоязычной ИТ-тусовочки стали снова писать про Serverless.
Ну, чем бы дитя не тешилось.
Что по сути сделал известный стриминг провайдер? Асинхронную оркестрацию бизнес-логики с использованием AWS Lambda в качестве вычислительного движка, прикрутив к ней свой внутренний инструментарий (трассировка, мониторинг, интеграции и т.д.).
Не скажу, что делал что-то подобное раньше, но бизнес-логику на FaaS имплементировал, и аплодисментов не слышал. Наверное авторитета не хватает, или масштабы не те.
Ну или имплементация неочень. :)
Раз колесо Сансары делает очередной оборот, вопрос дорогой аудитории: надо ЕЩЕ РАЗ рассказывать про Serverless? Или лучше про то, как автор открыл для себя TCP window и qdisc?
Medium
The Netflix Cosmos Platform
Orchestrated Functions as a Microservice
#машины_разное
Я вас обожаю! Уже который по счету опрос, и оба варианта почти одинаково набирают по процентам.
Про TCP, а конкретно про ту часть, про которую я раньше не слышал, я обязательно напишу на следующей неделе, как и про serverless (несколько позже).
А пока ваше выходное чтиво, прекрасная статья про наш прекрасный несовершенный мир.
В ней все, что я люблю: ИТ-стоицизм, принятие неизбежного, черные лебеди, known unknowns и unknown unknowns... Словом, все, с чего начинается и чем заканчивается мой рабочий день.
Я вас обожаю! Уже который по счету опрос, и оба варианта почти одинаково набирают по процентам.
Про TCP, а конкретно про ту часть, про которую я раньше не слышал, я обязательно напишу на следующей неделе, как и про serverless (несколько позже).
А пока ваше выходное чтиво, прекрасная статья про наш прекрасный несовершенный мир.
В ней все, что я люблю: ИТ-стоицизм, принятие неизбежного, черные лебеди, known unknowns и unknown unknowns... Словом, все, с чего начинается и чем заканчивается мой рабочий день.
Increment
Everything is broken, and it’s okay
Accepting that imperfect things still work is fundamental to preventing failures from becoming catastrophes.
#машины_разное
Неплохо так бомбануло вчера, да? Честное слово, еще одна авария из-за регулярок (я все еще помню историю с 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.
Неплохо так бомбануло вчера, да? Честное слово, еще одна авария из-за регулярок (я все еще помню историю с 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.
Я почти закончил работу над статьей про Serverless.
Между прочим, на следующей неделе у одного никому неизвестного облачного провайдера юбилей - в связи с чем все желающие приглашаются на серию сессий, посвященных самому старому сервису Amazon S3.
#машины_aws
Должен признать, писать блоги по-русски становится все сложнее и сложнее.
Пока хайпожоры и прочие евангелисты не забили ваши мозги всякими глупостями - идите скорей читать про Serverless.
Должен признать, писать блоги по-русски становится все сложнее и сложнее.
Пока хайпожоры и прочие евангелисты не забили ваши мозги всякими глупостями - идите скорей читать про Serverless.
Хабр
И еще разок про Serverless
Логотип AWS Lambda (ну или Half Life, я так и не понял)С публичного релиза AWS Lambda прошло ни много ни мало 6 с лишним лет. Реактивные функции, реагирующие на...