Forwarded from 🚀🐳 Летит Кит: SRE и не только
Не тот open API. Когда вы не управляете клиентами.
Очередной раз вижу в чате клич "Ребята, отзовитесь, кто пользуется API нашего сервиса X?".
Кажется, что за ерунда? Это же все наши внутренние сервисы -- посмотри по логам, по трейсам откуда запросы идут...
Но там может этого не быть. Например, ваши же сервисы не отправляют User-Agent со своим именем и версией в вызове, или нет трейсов. Всё - у вас просто куча логов об обращении на какой то endpoint вашего API.
Но проблема глубже - в этой ситуации у вас нет инструмента контроля нагрузки, вы не знаете вытянет ли ваш сервис. Да можно сказать - мы провели нагрузочное тестирование и он вытянет еще x10. Но ты не знаешь сколько придет, хотя можешь это сделать.
О чем я говорю - о способе который видел впервые у Amazon.
Как это работает:
1) Вы даете доступ в API только по индивидуальным ApiKey, каждому потребителю свой
2) Каждый потребитель запрашивает у вас ApiKey и обязан принести сразу число - сколько нагрузки он будет вам давать (rps, ops)
3) Вы смотрите в показатели своего сервиса и принимаете решение. Если хватает мощности, то сразу выдаете ApiKey, иначе вы можете сказать "Ребята, у нас не хватит производительности вас обслужить - берем задачу на подумать как повысить производительность", и когда повысили - выдаем ApiKey.
4) Конечно хоршо бы вести базу какой ApiKey на какой сервис выдали, чтобы найти ответственных если что.
5) И также по ApiKey вы можете легко выставлять Rate-Limit, что позволит не завалить весь сервис, если один из клиентов сошел с ума.
А у вас пользуется подобными способами?
Встроено это в процесс подключения новых потребителей API?
Очередной раз вижу в чате клич "Ребята, отзовитесь, кто пользуется API нашего сервиса X?".
Кажется, что за ерунда? Это же все наши внутренние сервисы -- посмотри по логам, по трейсам откуда запросы идут...
Но там может этого не быть. Например, ваши же сервисы не отправляют User-Agent со своим именем и версией в вызове, или нет трейсов. Всё - у вас просто куча логов об обращении на какой то endpoint вашего API.
Но проблема глубже - в этой ситуации у вас нет инструмента контроля нагрузки, вы не знаете вытянет ли ваш сервис. Да можно сказать - мы провели нагрузочное тестирование и он вытянет еще x10. Но ты не знаешь сколько придет, хотя можешь это сделать.
О чем я говорю - о способе который видел впервые у Amazon.
Как это работает:
1) Вы даете доступ в API только по индивидуальным ApiKey, каждому потребителю свой
2) Каждый потребитель запрашивает у вас ApiKey и обязан принести сразу число - сколько нагрузки он будет вам давать (rps, ops)
3) Вы смотрите в показатели своего сервиса и принимаете решение. Если хватает мощности, то сразу выдаете ApiKey, иначе вы можете сказать "Ребята, у нас не хватит производительности вас обслужить - берем задачу на подумать как повысить производительность", и когда повысили - выдаем ApiKey.
4) Конечно хоршо бы вести базу какой ApiKey на какой сервис выдали, чтобы найти ответственных если что.
5) И также по ApiKey вы можете легко выставлять Rate-Limit, что позволит не завалить весь сервис, если один из клиентов сошел с ума.
А у вас пользуется подобными способами?
Встроено это в процесс подключения новых потребителей API?
Forwarded from Про руководство разработкой и продуктом | Олег Мохов
1x1 от Рэндса [1/2]
Я был уверен, что у меня в блоге уже есть пост про 1x1: что это за встречи, как я их провожу и зачем они нужны. Оказалось — нет.
И тут в книге «Как управлять интеллектуалами» я встретил почти один в один тот подход, которым пользуюсь сам. Поэтому решил им поделиться и немного дополнить своими мыслями.
Встречи 1х1 — это регулярные встречи один на один руководителя и его подопечного.
И, в начале я напишу самое важное: цель тет-а-тет встреч — говорить о сути работы и состоянии человека и команды, а не просто обмениваться статусами.
Правила хорошего тет-а-тета:
1. Выделите конкретный день и конкретное время — и проводите встречу регулярно.
Лучше всего — еженедельно.
Для людей, которые работают бок о бок в офисе, я бы сказал, что можно чуть реже — например, раз в две недели. Более редкую частоту частично компенсирует возможность ad hoc-коммуникации в течение рабочей недели.
2. Никогда не отменяйте тет-а-тет.
Даже если вы ужасно заняты. Даже если вам кажется, что обсудить нечего. Тут я с Рэндсом согласен на 100%.
3. Выделяйте на тет-а-тет не меньше 30 минут.
Меньше — уже слишком легко скатиться в короткий статус-колл вместо нормального разговора.
Это базовые правила. Теперь давайте поймём, о чём вообще говорить на тет-а-тетах.
Рэндс, как и многие другие, и я в том числе, начинает 1x1 с банального вопроса: «Как дела?»
Дальше он делит беседы на три типа:
— Сводка текущих событий — всё в порядке
— Жалоба — что-то случилось
— Катастрофа
Самый частый тип — это, конечно, сводка. Когда человек просто перечисляет, что делал.
Рэндс даёт тут очень классный совет: относитесь к такому, иногда довольно нудному, рассказу как кладоискатель в поисках самородка.
Очевидно, что если человек за первые две минуты не сказал, что у него всё плохо, то вряд ли на восьмой минуте тон рассказа сменится и выяснится что у нас катастрофа. И это не значит, что встреча бесполезна. Это значит, что вам нужно слушать не только содержание, но и искать зацепки, за которые можно развить разговор.
«Дальше я писал е2е тесты»...
О, а расскажи как сейчас вообще это делают, а то давно не писал, интересно что поменялось.
«Потом была встреча с HR, хотели чтобы мы взяли в работу задачи по оптимизации найма»...
О, а расскажи какие там гипотезы и идеи, а ты в них сам веришь?
«Дальше я рисовала макет формы авторизации»... О, а расскажи как сейчас работа со стандартными компонентами устроена в Figma
Смысл тут в том, что даже из рутинного пересказа можно вытащить разговор, который на самом деле что-то проясняет: про интересы человека, его сомнения, взгляд на процессы, отношение к происходящему.
Если же за первые 15 минут найти самородок не получается, то Рэндс переключает тему и делая одно из трех:
— Три заранее подготовленные темы
Это могут быть любые содержательные вопросы, которые тебе хотелось бы обсудить с человеком. Тут очень помогают заметки с прошлых встреч.
— Мини-анализ продуктивности
Да-да, поговорить про то как делать работу иначе. «Я вижу что у тебя всё ок в текущем, давай поговорим о том что можно поменять чтобы стало ещё лучше». То есть поговорить не о текущем статусе, а о том, как человек вообще организует свою работу.
— Собственная актуальная катастрофа
То есть подумать с человеком над своей проблемой. Не в формате «пожаловаться начальнику вниз», а в формате нормального совместного размышления.
В целом это тактика, которой действительно можно придерживаться в большинстве 1x1, потому что именно так они чаще всего и проходят.
И, наверное, в этом и есть главное: хороший тет-а-тет — это не про контроль, а про внимание к человеку.
Я был уверен, что у меня в блоге уже есть пост про 1x1: что это за встречи, как я их провожу и зачем они нужны. Оказалось — нет.
И тут в книге «Как управлять интеллектуалами» я встретил почти один в один тот подход, которым пользуюсь сам. Поэтому решил им поделиться и немного дополнить своими мыслями.
Встречи 1х1 — это регулярные встречи один на один руководителя и его подопечного.
И, в начале я напишу самое важное: цель тет-а-тет встреч — говорить о сути работы и состоянии человека и команды, а не просто обмениваться статусами.
Правила хорошего тет-а-тета:
1. Выделите конкретный день и конкретное время — и проводите встречу регулярно.
Лучше всего — еженедельно.
Для людей, которые работают бок о бок в офисе, я бы сказал, что можно чуть реже — например, раз в две недели. Более редкую частоту частично компенсирует возможность ad hoc-коммуникации в течение рабочей недели.
2. Никогда не отменяйте тет-а-тет.
Даже если вы ужасно заняты. Даже если вам кажется, что обсудить нечего. Тут я с Рэндсом согласен на 100%.
3. Выделяйте на тет-а-тет не меньше 30 минут.
Меньше — уже слишком легко скатиться в короткий статус-колл вместо нормального разговора.
Это базовые правила. Теперь давайте поймём, о чём вообще говорить на тет-а-тетах.
Рэндс, как и многие другие, и я в том числе, начинает 1x1 с банального вопроса: «Как дела?»
Дальше он делит беседы на три типа:
— Сводка текущих событий — всё в порядке
— Жалоба — что-то случилось
— Катастрофа
Самый частый тип — это, конечно, сводка. Когда человек просто перечисляет, что делал.
Рэндс даёт тут очень классный совет: относитесь к такому, иногда довольно нудному, рассказу как кладоискатель в поисках самородка.
Очевидно, что если человек за первые две минуты не сказал, что у него всё плохо, то вряд ли на восьмой минуте тон рассказа сменится и выяснится что у нас катастрофа. И это не значит, что встреча бесполезна. Это значит, что вам нужно слушать не только содержание, но и искать зацепки, за которые можно развить разговор.
«Дальше я писал е2е тесты»...
О, а расскажи как сейчас вообще это делают, а то давно не писал, интересно что поменялось.
«Потом была встреча с HR, хотели чтобы мы взяли в работу задачи по оптимизации найма»...
О, а расскажи какие там гипотезы и идеи, а ты в них сам веришь?
«Дальше я рисовала макет формы авторизации»... О, а расскажи как сейчас работа со стандартными компонентами устроена в Figma
Смысл тут в том, что даже из рутинного пересказа можно вытащить разговор, который на самом деле что-то проясняет: про интересы человека, его сомнения, взгляд на процессы, отношение к происходящему.
Если же за первые 15 минут найти самородок не получается, то Рэндс переключает тему и делая одно из трех:
— Три заранее подготовленные темы
Это могут быть любые содержательные вопросы, которые тебе хотелось бы обсудить с человеком. Тут очень помогают заметки с прошлых встреч.
— Мини-анализ продуктивности
Да-да, поговорить про то как делать работу иначе. «Я вижу что у тебя всё ок в текущем, давай поговорим о том что можно поменять чтобы стало ещё лучше». То есть поговорить не о текущем статусе, а о том, как человек вообще организует свою работу.
— Собственная актуальная катастрофа
То есть подумать с человеком над своей проблемой. Не в формате «пожаловаться начальнику вниз», а в формате нормального совместного размышления.
В целом это тактика, которой действительно можно придерживаться в большинстве 1x1, потому что именно так они чаще всего и проходят.
И, наверное, в этом и есть главное: хороший тет-а-тет — это не про контроль, а про внимание к человеку.
👍4🔥2
Forwarded from Machinelearning
NVIDIA обучила семейство моделей Nemotron-Terminal для автономной работы в терминале Linux: устанавливать зависимости, писать и запускать код, отлаживать окружения и выполнять сквозные инженерные задачи без участия человека.
Семейство построено на базе Qwen3 и специально собранном датасете Terminal-Corpus. И фишка не в архитектуре, а в данных.
Первый адаптирует готовые датасеты по математике, коду и SWE-задачам под терминальный формат (без участия LLM в процессе адаптации).
Второй генерирует синтетику 2 методами: seed-based (LLM создает новые задачи на основе существующих задач из смежных областей) и skill-based (LLM комбинирует до пяти примитивных навыков из таксономии по 9 доменам: Security, Data Science, System Administration и другим).
Terminal-Corpus: около 366K траекторий выполнения задач, разбитых на два потока: ~226K адаптированных примеров из Math/Code/SWE и ~140K синтетических задач на основе skill-таксономии.
Synthetic-Tasks: задачи в стандартизированном формате: инструкция, Docker-окружение из 9 преднастроенных образов и верификационный набор на pytest.
На Terminal-Bench 2.0 все 3 модели показали кратный рост относительно базовой Qwen3: 8B - с 2.5% до 13%, 14B - с 4% до 20.2%, 32B - с 3.4% до 27.4%.
Для сравнения: Qwen3-Coder на 480B параметров набирает 23.9%, GPT-5-Mini - 24.0%, Grok 4 - 23.1%. Nemotron-Terminal-32B превосходит или вплотную конкурирует с ними всеми при разнице в размере на порядок.
Фильтрация неудачных траекторий вредит. Модель, обученная на всех траекториях включая ошибочные, набирает 12.4% против 5.06% у варианта только с успешными.
Curriculum learning (сначала простые данные, потом сложные) не дал преимуществ перед простым смешанным обучением.
Увеличение контекстного окна с 32K до 65K токенов также не помогло, длинные траектории оказались шумнее.
@ai_machinelearning_big_data
#AI #ML #LLM #NemotronTerminal #NVIDIA
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3👎1
Как стать DevOps-инженером и какие знания действительно нужны на старте?
25 марта пройдет День открытых дверей онлайн-магистратуры ИТМО «DevOps-инженер облачных сервисов» в партнёрстве с Яндекс Практикумом.
Ждём вас 25 марта в 19:00 мск.
→ Зарегистрироваться на ДОД
25 марта пройдет День открытых дверей онлайн-магистратуры ИТМО «DevOps-инженер облачных сервисов» в партнёрстве с Яндекс Практикумом.
На встрече обсудим:
🔵 что ждут работодатели от DevOps-инженеров в 2026 году
🔵 какая главная сложность входа в профессию DevOps
🔵 как устроено обучение и вступительные экзамены
Расскажем, как проходит обучение, какие навыки получают студенты магистратуры и как совмещать учёбу с работой. А ещё сможете задать вопросы команде программы.
Ждём вас 25 марта в 19:00 мск.
→ Зарегистрироваться на ДОД
❤2👍1👎1🔥1
Forwarded from Про руководство разработкой и продуктом | Олег Мохов
1x1 от Рэндса [2/2]
«Нам надо поговорить» — примерно так начинаются те редкие 1x1, которые отличаются от обычных.
В книге «Как управлять интеллектуалами» такие встречи делятся на два типа: жалобы и катастрофы.
Главное правило таких 1x1 — да и, наверное, вообще хорошего руководителя — заткнуться и слушать.
И только когда человек выговорился, можно переходить к следующему этапу: не предлагать готовый ответ, а понять, чего он сам хочет.
«Ок, я слышу, что тебя это очень триггерит. Как я могу тебе помочь?»
Это важный момент. Даже если вам кажется, что решение уже очевидно, лучше не навязывать его (сразу). Есть риск, что человеку вообще не было нужно «исправление ситуации». Возможно, всё, что ему было нужно, — это пространство, в котором можно безопасно проговорить проблему. А решение он уже сам знает и успешно внедряет.
Катастрофу Рэндс отделяет от жалобы довольно просто: если жалоба похожа на доклад, то катастрофа похожа на атаку.
Например, на вас.
На команду.
На решение, которое вы приняли.
И вот тут у руководителя почти автоматически включается защита. Очень хочется немедленно:
— объяснить, что человек всё понял неправильно,
— защитить своё решение,
— начать задавать жёсткие уточняющие вопросы,
— вернуть разговор под контроль.
«Вася, ты принял очень дерьмовое решение по поводу библиотеки X, это путь в никуда...».
И если в этот момент начать отвечать в духе:
Почему ты так думаешь?
Почему ты сомневаешься в моём выборе?
Ты вообще понимаешь контекст?
то сотрудник очень быстро отступит.
Не потому, что он был не прав.
А потому, что он и так с трудом набрался смелости это сказать. И если в ответ на такую смелость он получает пассивную агрессию, давление или защиту статуса, то дальше он, скорее всего, просто перестанет быть честным. А в худшем случае — уйдёт.
Именно поэтому многие даже опытные руководители потом искренне удивляются:
Я же слушал. Я же был открыт. Почему человек всё равно уволился?
Но, ребят, формально слушать и создавать безопасное пространство для несогласия — это не одно и то же.
Я бы сказал: о, интересная точка зрения, расскажешь подробнее? Но можно и просто немного выдержать паузу, скорее всего человек сам начнет выкладывать свои аргументы.
И жалобы, и катастрофы в итоге полезно сводить к конкретике:
— Что человек хочет от вас?
— Нужна ли ему помощь?
— Нужно ли действие?
— Если да, то какое именно?
Важно не угадывать и не додумывать за него. Не «я понял, тебе надо вот это».
А «правильно ли я понимаю, что ты хочешь вот этого?»
И последнее (but not the least)
В конце такого разговора всегда нужно говорить спасибо.
Потому что если у сотрудника есть смелость сказать вам, что вы не правы, что команда идёт не туда или что его что-то по-настоящему задевает, — это вообще-то хороший признак.
Значит, у вас ещё не сломалось доверие.
Значит, человек пока верит, что с вами можно разговаривать честно.
А это для руководителя одна из самых ценных вещей, которые вообще можно построить в команде.
В конце вопрос к вам на счет этих двух постов про 1х1:
🔥 — круто, узнал новое
❤️ — в целом так и провожу
⚡️ — пиши ещё такие посты
☃️ — слишком очевидно, не интересно
«Нам надо поговорить» — примерно так начинаются те редкие 1x1, которые отличаются от обычных.
В книге «Как управлять интеллектуалами» такие встречи делятся на два типа: жалобы и катастрофы.
Главное правило таких 1x1 — да и, наверное, вообще хорошего руководителя — заткнуться и слушать.
Вначале вы можете спутать Жалобу с обычным разговором. Но это не обычный разговор! Это ментальный спусковой клапан, и ваша работа состоит в том, чтобы слушать столько, сколько потребуется. Не пытайтесь решить проблему! Не пытайтесь отвлечь! Не пытайтесь успокоить! Еще рано! Ваш сотрудник делает ментальную уборку в своей голове, и прервать
ее значит упустить суть. Сейчас ему не нужно решение проблемы; он просто хочет быть услышанным.
И только когда человек выговорился, можно переходить к следующему этапу: не предлагать готовый ответ, а понять, чего он сам хочет.
«Ок, я слышу, что тебя это очень триггерит. Как я могу тебе помочь?»
Это важный момент. Даже если вам кажется, что решение уже очевидно, лучше не навязывать его (сразу). Есть риск, что человеку вообще не было нужно «исправление ситуации». Возможно, всё, что ему было нужно, — это пространство, в котором можно безопасно проговорить проблему. А решение он уже сам знает и успешно внедряет.
Катастрофу Рэндс отделяет от жалобы довольно просто: если жалоба похожа на доклад, то катастрофа похожа на атаку.
Например, на вас.
На команду.
На решение, которое вы приняли.
И вот тут у руководителя почти автоматически включается защита. Очень хочется немедленно:
— объяснить, что человек всё понял неправильно,
— защитить своё решение,
— начать задавать жёсткие уточняющие вопросы,
— вернуть разговор под контроль.
«Вася, ты принял очень дерьмовое решение по поводу библиотеки X, это путь в никуда...».
И если в этот момент начать отвечать в духе:
Почему ты так думаешь?
Почему ты сомневаешься в моём выборе?
Ты вообще понимаешь контекст?
то сотрудник очень быстро отступит.
Не потому, что он был не прав.
А потому, что он и так с трудом набрался смелости это сказать. И если в ответ на такую смелость он получает пассивную агрессию, давление или защиту статуса, то дальше он, скорее всего, просто перестанет быть честным. А в худшем случае — уйдёт.
Именно поэтому многие даже опытные руководители потом искренне удивляются:
Я же слушал. Я же был открыт. Почему человек всё равно уволился?
Но, ребят, формально слушать и создавать безопасное пространство для несогласия — это не одно и то же.
Я бы сказал: о, интересная точка зрения, расскажешь подробнее? Но можно и просто немного выдержать паузу, скорее всего человек сам начнет выкладывать свои аргументы.
И жалобы, и катастрофы в итоге полезно сводить к конкретике:
— Что человек хочет от вас?
— Нужна ли ему помощь?
— Нужно ли действие?
— Если да, то какое именно?
Важно не угадывать и не додумывать за него. Не «я понял, тебе надо вот это».
А «правильно ли я понимаю, что ты хочешь вот этого?»
И последнее (but not the least)
В конце такого разговора всегда нужно говорить спасибо.
Потому что если у сотрудника есть смелость сказать вам, что вы не правы, что команда идёт не туда или что его что-то по-настоящему задевает, — это вообще-то хороший признак.
Значит, у вас ещё не сломалось доверие.
Значит, человек пока верит, что с вами можно разговаривать честно.
А это для руководителя одна из самых ценных вещей, которые вообще можно построить в команде.
В конце вопрос к вам на счет этих двух постов про 1х1:
🔥 — круто, узнал новое
❤️ — в целом так и провожу
⚡️ — пиши ещё такие посты
☃️ — слишком очевидно, не интересно
❤5🔥2👎1
Forwarded from /usr/bin
Каждый баг, который я когда-либо исправлял, начинал иметь смысл только после того, как я понял эти 7 уровней
Интересный подход для дебага приложений на основе 7 уровней модели OSI.
@usr_bin_linux
Спустя три года работы я потратил две недели на отладку причин, по которым наш API случайным образом возвращал ошибки 502. Логи были чистыми. Приложение работало исправно. Все указывало на то, что проблем нет.
Затем мимо проходил сетевой инженер и спросил: «А ты проверял, совпадает ли таймаут keepalive у балансировщика нагрузки с таймаутом сервера приложения?»
Интересный подход для дебага приложений на основе 7 уровней модели OSI.
@usr_bin_linux
🔥3
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
Метрики? Метрики! Метрики...Или введение в Prometheus и Monitoring
Ох уж это волшебное слово которое я слышу чуть ли не каждый день. Всем нужно что-то считать, оценивать. Визуализировать и оценивать реальность во всех ее проявлениях. Кто-то считает заработанные денежки, кто-то потраченные, кто-то и то и другое. В общем считать это нужное и полезное занятие.
В том числе это нужно и нам - разработчикам. Для поддержки высокого уровня сервиса и построения надежных системм важно понимать как функционирует написанный нами код и железка на которой мы его развернули. А понимание можно извлечь только собирая информацию и вариантов у нас обычно 3 - логи, метрики, трейсы. Если с логами все интуитивно понятно - это фиксация фактов / событий в нашей системе. Их легко начать собирать и пользоваться ими, то с метриками дела обстоят веселее и стартануть в их сборе также быстро как с логами не получится, про трейсы вообще молчу.
Но вернемся к метрикам. Я мог бы написать целое полотно, о том как это всё работает, но считаю что лучше будет поделиться с вами материалами которые помогли лично мне разобраться с тем как работает сбор метрик, их хранение и визуализация. Возможно они будут вам полезны и помогут сделать тот самый первый шаг к изучению предмета.
📖Шаг №1 - Нескучная теория
Первым делом я советую прочитать цикл статей "Человеческим языком про метрики". Это настоящее сокровище, ничего лучше на русском языке мне не встречалось. Очень доходчиво, с примерами. Покрывается все - мат.аппарат, технические детали работы Prometheus, визуализация. Не разобраться в предмете не получится
👨🔬Шаг №2 - Закрепляем теорию
Закрепить изученное в статье на практике можно с помочью https://demo.promlens.com. Это интерактивный визуализатор метрик по запросу. С возможностью разобрать запрос на этапы выполнения и получить пояснения. Можно засунуть в него свой эндпоинт для работы с метриками, а можно работать с источником по умолчанию https://demo.promlens.com/metrics
Примеры метрик которые можно быстро засунуть в него и посмотреть результат доступен в шпаргалке https://promlabs.com/promql-cheat-sheet/
🔬Шаг №3 - Экспериментируем на своей машине
После быстрого освоения построения визуализаций и готовых метрик в браузере можно переходить поближе к коду и практическому применению. Как пример - можно взять репозиторий https://github.com/ContainerSolutions/k8s-deployment-strategies и посмотреть как работают в связке K8s + Prometheus + Grafana. Как происходит экспорт метрик, увидеть на графиках разницу стратегий деплоя приложения.
Задача со звездочкой - добавить в свое приложение сбор стандартных runtime метрик. Гайд для Golang.
🤔Шаг №4 - А какие метрики мне нужны?
После того как мы овладели инструментом может возникнуть соблазн начать собирать все что только можно. Или наоборот ступор от того что все ещё непонятно - а что собирать то? И у сообщества есть ответ на этот вопрос:
- R.E.D. Metrics: Rate, Errors, and Duration
- U.S.E. Metrics: Utilization, Saturation, and Errors
- The “Four Golden Signals” Metrics: Latency, Traffic, Errors, and Saturation
Эти метрики станут надежным фундаментом для вашей системы мониторинга.
------
На этом у меня всё, пишите в комментариях как вы осваивали метрики, что для вас было наиболее сложным в понимании. Ну или расскажите какую нибудь историю с ними связанную😅
Ох уж это волшебное слово которое я слышу чуть ли не каждый день. Всем нужно что-то считать, оценивать. Визуализировать и оценивать реальность во всех ее проявлениях. Кто-то считает заработанные денежки, кто-то потраченные, кто-то и то и другое. В общем считать это нужное и полезное занятие.
В том числе это нужно и нам - разработчикам. Для поддержки высокого уровня сервиса и построения надежных системм важно понимать как функционирует написанный нами код и железка на которой мы его развернули. А понимание можно извлечь только собирая информацию и вариантов у нас обычно 3 - логи, метрики, трейсы. Если с логами все интуитивно понятно - это фиксация фактов / событий в нашей системе. Их легко начать собирать и пользоваться ими, то с метриками дела обстоят веселее и стартануть в их сборе также быстро как с логами не получится, про трейсы вообще молчу.
Но вернемся к метрикам. Я мог бы написать целое полотно, о том как это всё работает, но считаю что лучше будет поделиться с вами материалами которые помогли лично мне разобраться с тем как работает сбор метрик, их хранение и визуализация. Возможно они будут вам полезны и помогут сделать тот самый первый шаг к изучению предмета.
📖Шаг №1 - Нескучная теория
Первым делом я советую прочитать цикл статей "Человеческим языком про метрики". Это настоящее сокровище, ничего лучше на русском языке мне не встречалось. Очень доходчиво, с примерами. Покрывается все - мат.аппарат, технические детали работы Prometheus, визуализация. Не разобраться в предмете не получится
👨🔬Шаг №2 - Закрепляем теорию
Закрепить изученное в статье на практике можно с помочью https://demo.promlens.com. Это интерактивный визуализатор метрик по запросу. С возможностью разобрать запрос на этапы выполнения и получить пояснения. Можно засунуть в него свой эндпоинт для работы с метриками, а можно работать с источником по умолчанию https://demo.promlens.com/metrics
Примеры метрик которые можно быстро засунуть в него и посмотреть результат доступен в шпаргалке https://promlabs.com/promql-cheat-sheet/
🔬Шаг №3 - Экспериментируем на своей машине
После быстрого освоения построения визуализаций и готовых метрик в браузере можно переходить поближе к коду и практическому применению. Как пример - можно взять репозиторий https://github.com/ContainerSolutions/k8s-deployment-strategies и посмотреть как работают в связке K8s + Prometheus + Grafana. Как происходит экспорт метрик, увидеть на графиках разницу стратегий деплоя приложения.
Задача со звездочкой - добавить в свое приложение сбор стандартных runtime метрик. Гайд для Golang.
🤔Шаг №4 - А какие метрики мне нужны?
После того как мы овладели инструментом может возникнуть соблазн начать собирать все что только можно. Или наоборот ступор от того что все ещё непонятно - а что собирать то? И у сообщества есть ответ на этот вопрос:
- R.E.D. Metrics: Rate, Errors, and Duration
- U.S.E. Metrics: Utilization, Saturation, and Errors
- The “Four Golden Signals” Metrics: Latency, Traffic, Errors, and Saturation
Эти метрики станут надежным фундаментом для вашей системы мониторинга.
------
На этом у меня всё, пишите в комментариях как вы осваивали метрики, что для вас было наиболее сложным в понимании. Ну или расскажите какую нибудь историю с ними связанную😅
Хабр
Человеческим языком про метрики 1: Потерянное введение
Однажды мне понадобилось внедрить метрики в сервисы своей команды. С самого начала я не понимал, что именно хочу получить: одно дело — прикрутить библиотеку и нарисовать графики, другое дело —...
❤6👍3🔥1
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
Road to Highload
Сегодня пост посвящен материалам команды Яндекс 360 о том как развивались их системы со временем и какие челленджи были на пути к желаемому всеми инженерами Highload.
Из прошлых постов вы наверняка заметили, что мне обычно интересно не только читать про классные алгоритмы и модные штучки, но и искать ответы на вопросы "Зачем? Почему именно так?" Ребята декларируют намерение поделиться собственным опытом и дать те самые ответы, а не только "навалить базы". Поэтому я решил посмотреть, что же там внутри.
В проекте 5 выпусков. Покрывают фундамент классического серверного приложения, а именно:
- Сбор требований и его влияние на архитектуру системы, ее надежность и масштабируемость.
- Проектирование API. Почему это важно, и чем чреваты ошибки. Мне этот выпуск отдельно запал в сердечко, потому что в нем было и про breaking changes и обратную совместимость, вещи с которыми я намучался😁
- Визуализация верхнеуровневой архитектуры как инструмент коммуникации и способ storytelling'a о системе.
- Как справляться с ростом объема данных. Индексы, согласованность. Разбор трейдоффов.
- Интеграции. Как подключать к своей системе внешние источники данных, челленжи и разбор популярных проблем.
Я отсмотрел проект целиком и могу сказать - материал достойный. Все о чем ребята рассказали это не что-то на эльфийском, а то что имеет место быть в больших системах. В общем - рекомендую к просмотру. Для начинающих прям 100%.
Расскажите в комментариях ваши впечатления от просмотра, а также делитесь своими любимыми материалами😊
Сегодня пост посвящен материалам команды Яндекс 360 о том как развивались их системы со временем и какие челленджи были на пути к желаемому всеми инженерами Highload.
Из прошлых постов вы наверняка заметили, что мне обычно интересно не только читать про классные алгоритмы и модные штучки, но и искать ответы на вопросы "Зачем? Почему именно так?" Ребята декларируют намерение поделиться собственным опытом и дать те самые ответы, а не только "навалить базы". Поэтому я решил посмотреть, что же там внутри.
В проекте 5 выпусков. Покрывают фундамент классического серверного приложения, а именно:
- Сбор требований и его влияние на архитектуру системы, ее надежность и масштабируемость.
- Проектирование API. Почему это важно, и чем чреваты ошибки. Мне этот выпуск отдельно запал в сердечко, потому что в нем было и про breaking changes и обратную совместимость, вещи с которыми я намучался😁
- Визуализация верхнеуровневой архитектуры как инструмент коммуникации и способ storytelling'a о системе.
- Как справляться с ростом объема данных. Индексы, согласованность. Разбор трейдоффов.
- Интеграции. Как подключать к своей системе внешние источники данных, челленжи и разбор популярных проблем.
Я отсмотрел проект целиком и могу сказать - материал достойный. Все о чем ребята рассказали это не что-то на эльфийском, а то что имеет место быть в больших системах. В общем - рекомендую к просмотру. Для начинающих прям 100%.
Расскажите в комментариях ваши впечатления от просмотра, а также делитесь своими любимыми материалами😊
Яндекс 360. Road to Highload — проект о проектировании сервисов
Рассказываем, как создаём одни из самых крупных облачных сервисов
👎3❤1🔥1
Forwarded from Безумный кот
Всем доброй ночи 🙃 .
По статистике этого канала посты чаще всего выходят ближе к ночи — и этот не исключение.
Прошел уже целый год с момента публикации моей первой статьи Kubernetes The Hard Way🤪 :
Статья получила много хорошего фидбека, но почти сразу появился один вопрос, который мне задавали весь этот год:
«А как добавлять worker-ноды?»
Наконец-то готов ответить на него новой статьей:
Kubernetes The Hard Way: Workers😈
Статья получилась небольшой, но полезной — поможет освежить в памяти хорошо забытое старое и, возможно, узнать что-то новое.
Так что устраивайтесь поудобнее — будет интересно😎
Лучшая ваша похвала — это:🤪
• Вопросы по теме
• Поиск неточностей
• Советы, как сделать лучше
• И, конечно, ⭐️ на GitHub
*Бонусом, мы перевели весь контент на английский, теперь будет публиковаться сразу на двух языках и не только в РФ)
По статистике этого канала посты чаще всего выходят ближе к ночи — и этот не исключение.
Прошел уже целый год с момента публикации моей первой статьи Kubernetes The Hard Way
Статья получила много хорошего фидбека, но почти сразу появился один вопрос, который мне задавали весь этот год:
«А как добавлять worker-ноды?»
Наконец-то готов ответить на него новой статьей:
Kubernetes The Hard Way: Workers
Статья получилась небольшой, но полезной — поможет освежить в памяти хорошо забытое старое и, возможно, узнать что-то новое.
Так что устраивайтесь поудобнее — будет интересно
Лучшая ваша похвала — это:
• Вопросы по теме
• Поиск неточностей
• Советы, как сделать лучше
• И, конечно, ⭐️ на GitHub
*Бонусом, мы перевели весь контент на английский, теперь будет публиковаться сразу на двух языках и не только в РФ)
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
Forwarded from Downtime Bar&Grill
Пока рунет кипит новостями про блокировки, наш корабль идет своим курсом по бушующему морю под названием "новая реальность". Представляем первого спикера нашей майской конференци!
Почему кризисы это сложное, но важное время для роста компаний?
⚡️ Василий Латышев, директор всея IT группы компаний "Читай-город - Буквоед" расскажет о том, как они три раза пересобирали IT за последние годы, не останавливая бизнес.
Что это были за пересборки и каким образом они смогли пережить ковид и кризисы Василий расскажет на конференции Тех.Диалог 22 мая в Москве.
Билеты на сайте и на таймпаде.
https://techdialogos.ru/#speakers
https://techdialogos.ru/#speakers
https://techdialogos.ru/#speakers
На первые 60 билетов для фанатов SRE трека очень хорошая скидка. Кто успел, тот не опоздал:
https://fournines.timepad.ru/event/3829663/
https://fournines.timepad.ru/event/3829663/
https://fournines.timepad.ru/event/3829663/
Скоро увидимся!
@downtime_bar #CTO #кризисы_роста #ТехДиалог
Почему кризисы это сложное, но важное время для роста компаний?
⚡️ Василий Латышев, директор всея IT группы компаний "Читай-город - Буквоед" расскажет о том, как они три раза пересобирали IT за последние годы, не останавливая бизнес.
Что это были за пересборки и каким образом они смогли пережить ковид и кризисы Василий расскажет на конференции Тех.Диалог 22 мая в Москве.
Билеты на сайте и на таймпаде.
https://techdialogos.ru/#speakers
https://techdialogos.ru/#speakers
https://techdialogos.ru/#speakers
На первые 60 билетов для фанатов SRE трека очень хорошая скидка. Кто успел, тот не опоздал:
https://fournines.timepad.ru/event/3829663/
https://fournines.timepad.ru/event/3829663/
https://fournines.timepad.ru/event/3829663/
Скоро увидимся!
@downtime_bar #CTO #кризисы_роста #ТехДиалог
👎3
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
🚀 Demystifying memory management in modern programming languages
Хочу с вами поделиться циклом статей, который мне пригодился во времена переката из Ruby в Go. Мне требовалось заново вспоминать всякие low level детали из-за специфики проекта и высокой нагрузки.
Цикл о том как происходит управление памятью в языках программирования. Первый пост разбирает основы и дает ответы на общие вопросы - RAM, Stack, Heap, Malloc / Realloc. Дальше автор начинает разбирать популярные рантаймы (JVM, V8) и ЯП (Golang, Rust).
Я такое люблю - когда коротко и понятным языком рассказывают базу.
https://deepu.tech/memory-management-in-programming/
Хочу с вами поделиться циклом статей, который мне пригодился во времена переката из Ruby в Go. Мне требовалось заново вспоминать всякие low level детали из-за специфики проекта и высокой нагрузки.
Цикл о том как происходит управление памятью в языках программирования. Первый пост разбирает основы и дает ответы на общие вопросы - RAM, Stack, Heap, Malloc / Realloc. Дальше автор начинает разбирать популярные рантаймы (JVM, V8) и ЯП (Golang, Rust).
Я такое люблю - когда коротко и понятным языком рассказывают базу.
https://deepu.tech/memory-management-in-programming/
Technorage
🚀 Demystifying memory management in modern programming languages
Let us take a look at how modern programming languages manage memory.
👍1
Forwarded from DevOps
🚨 Kubernetes v1.36 официально выходит 22 апреля 2026 года.
Вот 6 ключевых обновлений, к которым стоит подготовить свои кластеры: 👇
1⃣ HPA Scale-to-Zero (включено по умолчанию)
- Функция HPAScaleToZero выходит из alpha после того, как находилась там с версии v1.16.
- Теперь можно безопасно указывать minReplicas: 0.
- Это серьёзно снижает расходы для неактивных staging-окружений и batch-пайплайнов.
2⃣ Эфемерные Service Account токены для pull образов
- Заменяют долгоживущие статические секреты для доступа к приватным registry.
- Используются краткоживущие токены Service Account с автоматической ротацией.
- Учетные данные теперь привязаны к идентичности конкретного pod, что значительно снижает риск утечек.
3⃣ Более умный выбор pod’ов в HPA
- Исправлена проблема, когда HPA считал метрики устаревших или orphan-pod’ов.
- Новая логика учитывает только pod’ы, управляемые целевой workload.
- Автоскейлинг становится более предсказуемым и стабильным.
4⃣ Удаление режима kube-proxy IPVS
- Режим IPVS был deprecated в v1.35 и теперь будет полностью удалён.
- Пора переходить на iptables (backend nftables) или eBPF-proxy (например Cilium).
- Лучше запланировать миграцию заранее, чтобы обновление не сломало сетевой стек.
5⃣ Завершение эпохи Ingress NGINX и переход на Gateway API
- Сообщество постепенно отказывается от Ingress NGINX.
- Gateway API становится новым стандартом управления трафиком.
- Появляется нативная маршрутизация между namespace без набора кастомных annotations.
6⃣ Переход на containerd 2.x
- Версия v1.36, вероятно, станет последней, поддерживающей старые версии containerd (например **1.6.x**).
- Экосистема Kubernetes полностью выравнивается под containerd 2.x.
- Обновите runtime заранее, чтобы избежать breaking changes в следующих релизах.
Вот 6 ключевых обновлений, к которым стоит подготовить свои кластеры: 👇
1⃣ HPA Scale-to-Zero (включено по умолчанию)
- Функция HPAScaleToZero выходит из alpha после того, как находилась там с версии v1.16.
- Теперь можно безопасно указывать minReplicas: 0.
- Это серьёзно снижает расходы для неактивных staging-окружений и batch-пайплайнов.
2⃣ Эфемерные Service Account токены для pull образов
- Заменяют долгоживущие статические секреты для доступа к приватным registry.
- Используются краткоживущие токены Service Account с автоматической ротацией.
- Учетные данные теперь привязаны к идентичности конкретного pod, что значительно снижает риск утечек.
3⃣ Более умный выбор pod’ов в HPA
- Исправлена проблема, когда HPA считал метрики устаревших или orphan-pod’ов.
- Новая логика учитывает только pod’ы, управляемые целевой workload.
- Автоскейлинг становится более предсказуемым и стабильным.
4⃣ Удаление режима kube-proxy IPVS
- Режим IPVS был deprecated в v1.35 и теперь будет полностью удалён.
- Пора переходить на iptables (backend nftables) или eBPF-proxy (например Cilium).
- Лучше запланировать миграцию заранее, чтобы обновление не сломало сетевой стек.
5⃣ Завершение эпохи Ingress NGINX и переход на Gateway API
- Сообщество постепенно отказывается от Ingress NGINX.
- Gateway API становится новым стандартом управления трафиком.
- Появляется нативная маршрутизация между namespace без набора кастомных annotations.
6⃣ Переход на containerd 2.x
- Версия v1.36, вероятно, станет последней, поддерживающей старые версии containerd (например **1.6.x**).
- Экосистема Kubernetes полностью выравнивается под containerd 2.x.
- Обновите runtime заранее, чтобы избежать breaking changes в следующих релизах.
🔥4❤1👎1
https://habr.com/ru/news/1010702/ да что же это такое! Еще и ИИ нам работу увеличил! Доколе!
Хабр
Исследование: ИИ увеличивает время на каждую задачу до 346%
Аналитики ActivTrak Productivity Lab провели исследование с использованием данных пользователей после внедрения ИИ-сервисов в рабочие процессы. Они сравнили активность 10 584 сотрудников за 180 дней...
Если серьезно, то я не уверен что в эти проценты не входит adoption, но тут надо, конечно, глубоко погружаться в методику исследования
Forwarded from Avito SREда
This media is not supported in your browser
VIEW IN TELEGRAM
Это пост в СРЕду про новый выпуск Авито SREды 🎧
➡️ В новом выпуске ищем баланс между двумя командами, а также разбираемся, где именно безопасность встраивается в процессы и как это влияет на работу инженерных команд.
Встречаемся, как и всегда, по любой удобной ссылке:
📺 YouTube
🔵 VK
💻 Rutube
🛫 На любимой платформе
#sre
Дальше обещаем без каламбуров, потому что тема в этот раз прям серьёзная — про SRE и ИБ🔥
Встречаемся, как и всегда, по любой удобной ссылке:
#sre
Please open Telegram to view this post
VIEW IN TELEGRAM
👎4
Проверяем навыки DevOps-инженеров. Проверим ваши?
Привет, это KTS. Мы создаем цифровые продукты и ведём блог на Хабре, где делимся практикой из проектов. Блогу исполнилось 5 лет, и мы решили отметить эту дату челленджем для девопсов. Победителям дарим футболки с нашим фирменным принтом — Котзиллой (как Годзилла, только кот).
В чем суть головоломки: вы получите доступ к тестовому стенду с Kubernetes-кластером, ArgoCD и GitLab с Helm-чартом. В ArgoCD добавлено приложение, но оно не деплоится.
Ваша задача — разобраться, что пошло не так, исправить конфигурацию и довести деплой до зелёного статуса.
Десять самых быстрых участников получат футболки. Прям СДЭКом отправим 📦
Начать можно по ссылке.
Итоги через неделю, 26 марта в 19:00.
Привет, это KTS. Мы создаем цифровые продукты и ведём блог на Хабре, где делимся практикой из проектов. Блогу исполнилось 5 лет, и мы решили отметить эту дату челленджем для девопсов. Победителям дарим футболки с нашим фирменным принтом — Котзиллой (как Годзилла, только кот).
В чем суть головоломки: вы получите доступ к тестовому стенду с Kubernetes-кластером, ArgoCD и GitLab с Helm-чартом. В ArgoCD добавлено приложение, но оно не деплоится.
Ваша задача — разобраться, что пошло не так, исправить конфигурацию и довести деплой до зелёного статуса.
Десять самых быстрых участников получат футболки. Прям СДЭКом отправим 📦
Начать можно по ссылке.
Итоги через неделю, 26 марта в 19:00.
👎4
Forwarded from DevOps&SRE Library
Hidden Kubernetes Bad Practices Learned the Hard Way During Incidents
https://hackernoon.com/hidden-kubernetes-bad-practices-learned-the-hard-way-during-incidents
This article distills incident-driven lessons on troubleshooting, configuration mistakes, and operational habits that make Kubernetes outages worse.
https://hackernoon.com/hidden-kubernetes-bad-practices-learned-the-hard-way-during-incidents
👍2