📊 Golden Signals: 4 ключевые операционные метрики распределённых систем от Google
Термин 'golden signals' пришёл из книги Google SRE и стал стандартом индустрии.
В основе — SLI/SLO подход:
SLI (Service Level Indicators) — что измеряем
SLO (Service Level Objectives) — какая цель по этой метрике
Четыре 'golden signals' для распределенных систем:
📊 Latency (p95) — максимальное время выполнения 95% всех запросов (перцентиль p95), показывает реальный опыт большинства пользователей. Также часто меряют p99
🚀 Traffic / Throughput (QPS) — сколько запросов в секунду (queries per second/QPS) обрабатывает система
✅ Availability/Errors — соотношение 5xx к общему числу запросов к системе, показывающий уровень доступности системы
⚙️ Saturation — 'насыщение' ключевых ресурсов системы (CPU, память). Ранний сигнал о приближающихся проблемах.
Термин настолько прижился, что стал частью продуктов observability-платформ. Например, все это есть по умолчанию в том же Datadog: для каждого сервиса видишь его 'golden signal' метрики (requests, errors, duration).
Простой health check / heart beat дает слишком мало информации. Четыре 'golden signals' вместе дают полную картину: работает ли сервис, насколько быстро и корректно, и есть ли запас прочности под увеличение нагрузки.
А что еще вы мониторите в ваших системах/сервисах?
@faangiscalling
Термин 'golden signals' пришёл из книги Google SRE и стал стандартом индустрии.
В основе — SLI/SLO подход:
SLI (Service Level Indicators) — что измеряем
SLO (Service Level Objectives) — какая цель по этой метрике
Четыре 'golden signals' для распределенных систем:
📊 Latency (p95) — максимальное время выполнения 95% всех запросов (перцентиль p95), показывает реальный опыт большинства пользователей. Также часто меряют p99
🚀 Traffic / Throughput (QPS) — сколько запросов в секунду (queries per second/QPS) обрабатывает система
✅ Availability/Errors — соотношение 5xx к общему числу запросов к системе, показывающий уровень доступности системы
⚙️ Saturation — 'насыщение' ключевых ресурсов системы (CPU, память). Ранний сигнал о приближающихся проблемах.
Термин настолько прижился, что стал частью продуктов observability-платформ. Например, все это есть по умолчанию в том же Datadog: для каждого сервиса видишь его 'golden signal' метрики (requests, errors, duration).
Простой health check / heart beat дает слишком мало информации. Четыре 'golden signals' вместе дают полную картину: работает ли сервис, насколько быстро и корректно, и есть ли запас прочности под увеличение нагрузки.
А что еще вы мониторите в ваших системах/сервисах?
@faangiscalling
👍3🔥1
Как я полюбил git CLI 👨🏼💻
В последние несколько месяцев я прямо полюбил git CLI – почувствовал, насколько мощная это штука для ежедневной работы разработчика помимо классических
Для поиска нужных коммитов я использую:
Так же можно быстро понять, входит ли какая-то фича в релиз определенной версии, например v1.1.0:
Если искомый коммит предок (is-ancestor) тега версии, значит он в нее входит. Если он идет после – то не входит.
А вы используете git CLI? Какие у вас любимые команды?
@faangiscalling
В последние несколько месяцев я прямо полюбил git CLI – почувствовал, насколько мощная это штука для ежедневной работы разработчика помимо классических
add/commit/push/pull/branch/merge/rebase для поиска всего и вся.Для поиска нужных коммитов я использую:
git log --oneline | grep 'chunk-of-feature-commit-message'
Так же можно быстро понять, входит ли какая-то фича в релиз определенной версии, например v1.1.0:
# получаем хеш коммита с фичей по куску из коммит-мессаджа
git log --oneline | grep 'chunk-of-feature-commit-message'
# > 342ad22
# проверяем, является ли этот коммит предком коммита с тегом версии
git merge-base --is-ancestor 342ad22 v1.1.0 && echo "commit is included in the version"
Если искомый коммит предок (is-ancestor) тега версии, значит он в нее входит. Если он идет после – то не входит.
А вы используете git CLI? Какие у вас любимые команды?
@faangiscalling
👍1🔥1
Google SRE: чиним Memory leak по-гугловски 👨🔧
Прочитал Google SRE Book. 📘 Очень понравились подходы Google к capacity planning, golden signals и incident management.
Но больше всего запомнилась история про утечку памяти (memory leak).
Чиним Memory leak по-гугловски
Итак, за неделю до запуска продукта обнаружили утечку памяти в одном из сервисов. Команда сервиса не смогла найти причину, позвали 'спецназ'.
1️⃣ Сначала (часы) — сделать так, чтобы всё работало. 'Спецназ' начал системный поиск источника проблемы, root cause. Причину нашли, но только на уровне одного из сервисов – то есть cause, но без 'root' 🙂. Где был 'root' понять не могли. Но запуск скоро, поэтому:
– (!) просто добавили памяти на серверы, чтобы успеть запустить продукт через неделю. То есть – да, знаем, что есть утечка, но сначала не 'затыкаем', а 'увеличиваем резервуар', чтобы все не 'вытекло' при запуске. 'Спецназ' выполнил свою миссию, дальше уже действует команда.
2️⃣ Потом (дни)— сделать правильно. Дальше уже команда сервиса без давления инцидента спокойно разбиралась с root cause: добавила debug-логи, изучила поведение 'текущего' сервиса по шагам, исправила код, вызывавший проблему, протестировала фикс.
Для меня это и есть настоящая инженерия 👨🏼💻 – всегда компромисс (trade off), и никогда – 'хочу все и сразу'.
Эти 2 этапа так же совпадают с 2 этапами из инженерной классики, знаменитой фразы Кента Бека, автора паттернов GoF – Make it work. Make it right. Make it fast.
Что мне с этого?
Если вы не можете найти источник проблемы за пару часов, либо зовите 'спецназ' (помощь), либо локализуйте, чтобы хоть как-то работало, потом чините спокойно.
Узнать больше про Google SRE
И отдельный респект Google за то, что они выложили эту книгу бесплатно — инженерам есть чему у них учиться.
🔗 Читать тут
@faangiscalling
Прочитал Google SRE Book. 📘 Очень понравились подходы Google к capacity planning, golden signals и incident management.
Но больше всего запомнилась история про утечку памяти (memory leak).
Чиним Memory leak по-гугловски
Итак, за неделю до запуска продукта обнаружили утечку памяти в одном из сервисов. Команда сервиса не смогла найти причину, позвали 'спецназ'.
1️⃣ Сначала (часы) — сделать так, чтобы всё работало. 'Спецназ' начал системный поиск источника проблемы, root cause. Причину нашли, но только на уровне одного из сервисов – то есть cause, но без 'root' 🙂. Где был 'root' понять не могли. Но запуск скоро, поэтому:
– (!) просто добавили памяти на серверы, чтобы успеть запустить продукт через неделю. То есть – да, знаем, что есть утечка, но сначала не 'затыкаем', а 'увеличиваем резервуар', чтобы все не 'вытекло' при запуске. 'Спецназ' выполнил свою миссию, дальше уже действует команда.
2️⃣ Потом (дни)— сделать правильно. Дальше уже команда сервиса без давления инцидента спокойно разбиралась с root cause: добавила debug-логи, изучила поведение 'текущего' сервиса по шагам, исправила код, вызывавший проблему, протестировала фикс.
Для меня это и есть настоящая инженерия 👨🏼💻 – всегда компромисс (trade off), и никогда – 'хочу все и сразу'.
Эти 2 этапа так же совпадают с 2 этапами из инженерной классики, знаменитой фразы Кента Бека, автора паттернов GoF – Make it work. Make it right. Make it fast.
Что мне с этого?
Если вы не можете найти источник проблемы за пару часов, либо зовите 'спецназ' (помощь), либо локализуйте, чтобы хоть как-то работало, потом чините спокойно.
Узнать больше про Google SRE
И отдельный респект Google за то, что они выложили эту книгу бесплатно — инженерам есть чему у них учиться.
🔗 Читать тут
@faangiscalling
sre.google
Google SRE - SRE workbook table of content
The site reliability workbook table of contents, navigate key SRE concepts of sre and practical strategies for building reliable, scalable systems.
🔥3👍1🙏1
Как я чуть не выбросил Cracking the Coding Interview 📗
Я периодически перебираю свои книги, смотрю, какие еще актуальны, а какие просто занимают место.
Однажды взял Cracking the Coding Interview и пытался понять, как я ее буду использовать и не нашел такого сценария - зачем мне 189 примеров на Java, когда есть EPIP на Python, который я использую на интервью?
Она еще довольно увесистая, 700 страниц. В общем, попала в список 'на удаление'.
Но на днях взял ее снова и use case нашелся – хорошая книга для комплексного освежения всего – алгоритмов, system design и бихейва.
В книге четверть (190 страниц) – это короткие объяснения основных терминов и концепций. Это удобная шпаргалка, чтобы быстро по всему пробежаться.
А моя любимая часть Solutions позволяет быстро вспомнить merge sort, quick sort, весь DSA так как код решений идет один за одним и идеален для освежения в голове.
Бонусом там еще есть и детальный Tell me about yourself.
Начал все освежать по ней – книга спасена!
@faangiscalling
Я периодически перебираю свои книги, смотрю, какие еще актуальны, а какие просто занимают место.
Однажды взял Cracking the Coding Interview и пытался понять, как я ее буду использовать и не нашел такого сценария - зачем мне 189 примеров на Java, когда есть EPIP на Python, который я использую на интервью?
Она еще довольно увесистая, 700 страниц. В общем, попала в список 'на удаление'.
Но на днях взял ее снова и use case нашелся – хорошая книга для комплексного освежения всего – алгоритмов, system design и бихейва.
В книге четверть (190 страниц) – это короткие объяснения основных терминов и концепций. Это удобная шпаргалка, чтобы быстро по всему пробежаться.
А моя любимая часть Solutions позволяет быстро вспомнить merge sort, quick sort, весь DSA так как код решений идет один за одним и идеален для освежения в голове.
Бонусом там еще есть и детальный Tell me about yourself.
Начал все освежать по ней – книга спасена!
@faangiscalling
👍2🔥2
💸 Рынок зарплат AI инженеров 'exploded' в Лондоне 🇬🇧
Сейчас вижу уже не первую вакансию AI инженера в Лондоне 🇬🇧 с зарплатой в £150-200К в год + equity, почти FAANG уровень, которого просто не было еще год назад.
Вчера разговаривал с HR из одного стартапа в Лондоне и он сам сказал, что этот рынок зарплат просто 'exploded'. Если раньше, по его словам, он обсуждал вилки в £120-140К (я видел то же самое и в вакансиях), то сейчас они готовы обсуждать вилку в £150-250К(!), будучи стартапом с инвестициями.
Возможно сейчас £200К проще получить в таком стартапе, чем в FAANG 🤔
В Париже 🇫🇷 в стартапах тоже бывает до €150-180К, но explosion зарплат еще так явно не случился, а жаль 😀
А в вашем городе как с динамикой зарплат за последний год?
@faangiscalling
Сейчас вижу уже не первую вакансию AI инженера в Лондоне 🇬🇧 с зарплатой в £150-200К в год + equity, почти FAANG уровень, которого просто не было еще год назад.
Вчера разговаривал с HR из одного стартапа в Лондоне и он сам сказал, что этот рынок зарплат просто 'exploded'. Если раньше, по его словам, он обсуждал вилки в £120-140К (я видел то же самое и в вакансиях), то сейчас они готовы обсуждать вилку в £150-250К(!), будучи стартапом с инвестициями.
Возможно сейчас £200К проще получить в таком стартапе, чем в FAANG 🤔
В Париже 🇫🇷 в стартапах тоже бывает до €150-180К, но explosion зарплат еще так явно не случился, а жаль 😀
А в вашем городе как с динамикой зарплат за последний год?
@faangiscalling
🔥3✍1❤1
Как Netflix LLM к рекомендациям прикрутил 📊
Я попробовал LinkedIn для технического поста – и впервые набрал 2К+ просмотров, среди которых очень много FAANG-инженеров.
Делюсь статистикой здесь ☝️.
Сама история trade-offs на их масштабе тоже интересна для всех software engineers, а не только ML/AI. Мы же все знаем, что LLM – это вообще не дешево :-)
В чем сам challenge для Netflix, как они с этим работали, и как LLM теперь делает рекомендации из их каталога по text-based rules – читайте в посте и статье Netflix, по ссылке из поста.
🔗 Читать тут
@faangiscalling
Я попробовал LinkedIn для технического поста – и впервые набрал 2К+ просмотров, среди которых очень много FAANG-инженеров.
Делюсь статистикой здесь ☝️.
Сама история trade-offs на их масштабе тоже интересна для всех software engineers, а не только ML/AI. Мы же все знаем, что LLM – это вообще не дешево :-)
В чем сам challenge для Netflix, как они с этим работали, и как LLM теперь делает рекомендации из их каталога по text-based rules – читайте в посте и статье Netflix, по ссылке из поста.
🔗 Читать тут
@faangiscalling
👍2⚡1🔥1
Сентябрьский апдейт ☀️
Сентябрь был по-летнему солнечным, теплым и насыщенным на события:
• La rentrée (местное первое сентября) – дети в школу, родительские собрания, десятки сообщений в школьной онлайн-системе и вот это вот все ✅
• Пообедал в офисе Гугла в Париже с моим другом, очень понравилась атмосфера там. Вид с руфтопа тоже отличный
• Прошел Google Hiring Assesment тест, который действует 2 года для всех позиций в Гугле
• Сходил на Bits in Bio митап про применение LLM в медицине, где рассказывали интересное сравнение архитектур для прогнозирование взаимодействия белков (PPI – protein-protein interactions)
На следующей неделе поездка в Лондон 🇬🇧, включая митап с Google DeepMind в офисе Революта на Canary Wharf. В ожидании купил себе 2 красивые книги про Лондон и много узнал об этом городе. Теперь очень жду легендарный кофе в WatchHouse ☕️
---
Если какая-то тема из этого дайджеста вам интересна, напишите в комментариях, расскажу о ней подробнее
@faangiscalling
Сентябрь был по-летнему солнечным, теплым и насыщенным на события:
• La rentrée (местное первое сентября) – дети в школу, родительские собрания, десятки сообщений в школьной онлайн-системе и вот это вот все ✅
• Пообедал в офисе Гугла в Париже с моим другом, очень понравилась атмосфера там. Вид с руфтопа тоже отличный
• Прошел Google Hiring Assesment тест, который действует 2 года для всех позиций в Гугле
• Сходил на Bits in Bio митап про применение LLM в медицине, где рассказывали интересное сравнение архитектур для прогнозирование взаимодействия белков (PPI – protein-protein interactions)
На следующей неделе поездка в Лондон 🇬🇧, включая митап с Google DeepMind в офисе Революта на Canary Wharf. В ожидании купил себе 2 красивые книги про Лондон и много узнал об этом городе. Теперь очень жду легендарный кофе в WatchHouse ☕️
---
Если какая-то тема из этого дайджеста вам интересна, напишите в комментариях, расскажу о ней подробнее
@faangiscalling
❤4🔥2👍1
Media is too big
VIEW IN TELEGRAM
🧪Fanout lab: live-демо по system design для Facebook Feed
Facebook Feed / Twitter Feed – это одна из классических задач по system design.
Классическое решение - использовать fanout, то держать кеш с лентами для активных пользователей и писать им в этот кеш при посте тех, на кого они подписаны (кого они фолловят). Так называемый push-fanout. Для звезд/селебрити в больщим количеством подписчиков это будет слишком заьратно, поэтому их посты поттягиваются в момент чтения ленты – так называемый pull-fanout.
Я с Claude сделал демо по дизайну newsfeed из книги Alex Xu для себя и делюсь с вами.
—-
Вы делаете что-то такое для себя, когда разбираете system design?
Прислать вам этот HTML-файл c live-demo? Пишите FANOUT в комментарях
@faangiscalling
Facebook Feed / Twitter Feed – это одна из классических задач по system design.
Классическое решение - использовать fanout, то держать кеш с лентами для активных пользователей и писать им в этот кеш при посте тех, на кого они подписаны (кого они фолловят). Так называемый push-fanout. Для звезд/селебрити в больщим количеством подписчиков это будет слишком заьратно, поэтому их посты поттягиваются в момент чтения ленты – так называемый pull-fanout.
Я с Claude сделал демо по дизайну newsfeed из книги Alex Xu для себя и делюсь с вами.
—-
Вы делаете что-то такое для себя, когда разбираете system design?
Прислать вам этот HTML-файл c live-demo? Пишите FANOUT в комментарях
@faangiscalling
👍3🔥2