Про антипаттерны алертов.
Макс написал все за меня. Нет, не тот который ловит даже на парковке 😁.
Потому просто заберите себе это в практику — это реально полезно.
Я все эти антиппттерны видел в жизни, и не хочется чтобы вам пришлось будить разработчика ночью лично, только потому что он отключил телефон, а ты живешь по случайности в том же отеле и на том же этаже.
Брать тут https://t.me/youngmaxnotes/103
💫 Как у вас подгорело от "прекрасных" алертов? Расскажите в комментах
#алертинг #антипаттерны #база #репост
Макс написал все за меня. Нет, не тот который ловит даже на парковке 😁.
Потому просто заберите себе это в практику — это реально полезно.
Я все эти антиппттерны видел в жизни, и не хочется чтобы вам пришлось будить разработчика ночью лично, только потому что он отключил телефон, а ты живешь по случайности в том же отеле и на том же этаже.
Брать тут https://t.me/youngmaxnotes/103
💫 Как у вас подгорело от "прекрасных" алертов? Расскажите в комментах
#алертинг #антипаттерны #база #репост
Telegram
A young Max’s notebook
5 антипаттернов алертов
На новом месте работы я заметил, что алерты сливаются в общий чат и это жутко неудобно. Первое же, что я сделал - отключил уведомления :) Значит, что-то явно не так.
Решил собрать антипаттерны и рассказать об этом.
Алертов много…
На новом месте работы я заметил, что алерты сливаются в общий чат и это жутко неудобно. Первое же, что я сделал - отключил уведомления :) Значит, что-то явно не так.
Решил собрать антипаттерны и рассказать об этом.
Алертов много…
👍4❤1
Тренировка по #инцидент_менеджемент
Помню как погружался в работу с инцидентами.
Я начал работать в небольшой компании, у нас был 1 дежурный. Я стал вторым. И оба мы были разработчиками.
Сначала он меня учил на пальцах о системе и взаимодействии компонентов, показывал как чинить часто возникающие проблемы, а я смотрел. Я записывал в доку, потом пытался повторить тоже самое сам под его присмотром. Дальше выдал мне доступ на прод. И вот первое дежурство с потными ручонками... Страшно. Но оно кончилось и ничего не развалилось 😁
Второй раз уже случилось непонятное и пришлось копать логи, запросы и ошибки. Нашли - завели багу, и поняли, что по таким логам "так себе копать".
Освоился и с кубером и Google Cloud. Один падучий сервис будил меня 4 дня подряд в час ночи. Я на 3 день сделал себе консоль прямо на телефоне, чтобы ходить перезагружать тот сбойный под не вставая с кровати 😉 На 5 ночь я проснулся сам в 1 час ночи - но никто не позвонил. Оказалось разработчики починили 👨🔧 вчера.
Пока компания маленькая и растет - можно и получается учиться прямо на проде, т.к. потери не велики.
В большой компании и в зрелом бизнесе такое уже не позволят. Да и до всего прода вы доступ уже не получите.
Тогда как тренироваться?
Вы можете попробовать сделать стенд повторяющий часть прода и там ломать и пробовать чинить - так делают ребята в Яндекс такси (рассказывали в докладе).
Другой способ – попробовать отдельные тренажёры. Вот несколько площадок для тренировок онлайн по Linux и Kubernetes:
- https://labs.iximiuz.com/challenges?author=ivan-velichko&filter=all&category=kubernetes
- https://sadservers.com/
- https://keep-alive.ru - командные траблшутинга
- https://srega.me/ - индивидуальные тренировки в формате Capture the flag
Или
- Оффлайн на своей машине https://github.com/Manoj-engineer/k8squest
А как в работу с инцидентами погружались вы? Как получали опыт troubleshooting?
#troubleshooting #личный_опыт #sre
Помню как погружался в работу с инцидентами.
Я начал работать в небольшой компании, у нас был 1 дежурный. Я стал вторым. И оба мы были разработчиками.
Сначала он меня учил на пальцах о системе и взаимодействии компонентов, показывал как чинить часто возникающие проблемы, а я смотрел. Я записывал в доку, потом пытался повторить тоже самое сам под его присмотром. Дальше выдал мне доступ на прод. И вот первое дежурство с потными ручонками... Страшно. Но оно кончилось и ничего не развалилось 😁
Второй раз уже случилось непонятное и пришлось копать логи, запросы и ошибки. Нашли - завели багу, и поняли, что по таким логам "так себе копать".
Освоился и с кубером и Google Cloud. Один падучий сервис будил меня 4 дня подряд в час ночи. Я на 3 день сделал себе консоль прямо на телефоне, чтобы ходить перезагружать тот сбойный под не вставая с кровати 😉 На 5 ночь я проснулся сам в 1 час ночи - но никто не позвонил. Оказалось разработчики починили 👨🔧 вчера.
Пока компания маленькая и растет - можно и получается учиться прямо на проде, т.к. потери не велики.
В большой компании и в зрелом бизнесе такое уже не позволят. Да и до всего прода вы доступ уже не получите.
Тогда как тренироваться?
Вы можете попробовать сделать стенд повторяющий часть прода и там ломать и пробовать чинить - так делают ребята в Яндекс такси (рассказывали в докладе).
Другой способ – попробовать отдельные тренажёры. Вот несколько площадок для тренировок онлайн по Linux и Kubernetes:
- https://labs.iximiuz.com/challenges?author=ivan-velichko&filter=all&category=kubernetes
- https://sadservers.com/
- https://keep-alive.ru - командные траблшутинга
- https://srega.me/ - индивидуальные тренировки в формате Capture the flag
Или
- Оффлайн на своей машине https://github.com/Manoj-engineer/k8squest
А как в работу с инцидентами погружались вы? Как получали опыт troubleshooting?
#troubleshooting #личный_опыт #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?
🔥6👍1🤔1
Проверка инфраструктуры кодом - иногда и двух пар глаз 👀👀 недостаточно
Бывало у вас так: два инженера посмотрели в пулл-реквест, кивнули, мерджнули, а потом - бац!
Инцидент из-за кривой настройки безопасности или ресурса, улетевшего в продакшн без лимитов?
У нас бывало. И это не вопрос компетенции. Это вопрос того, что человек просто не может держать в голове все 750+ правил безопасной конфигурации.
Тут на помощь приходят инструменты статического анализа для Infrastructure as Code (IaC). Например, попался мне на глаза Checkov - https://www.checkov.io/
Что умеет:
- сканирует Terraform, CloudFormation, ARM, Helm, Kubernetes, Dockerfile и Serverless Framework
- проверяет на 750+ предустановленных политик - от открытых портов до отсутствия шифрования
- позволяет писать свои политики, если у вас специфичные требования
- интегрируется в CI/CD, чтобы ловить проблемы до мерджа
Почему это важно для SRE и DevOps:
- снижает когнитивную нагрузку на ревьюверов
- формализует знания о лучших практиках
- превращает "мы так не делаем" в автоматический чек
- дает артефакт для аудита и постмортема
Альтернативы, которые тоже стоит посмотреть:
- tfsec - легковесный, фокус на Terraform
- Terrascan - поддерживает несколько провайдеров, хорош для политик как код
- KICS от Checkmarx - открытый, с акцентом на безопасность
Внедряешь такую проверку в пайплайн - и количество "а мы не заметили" в ревью падает.
Конечно, инструмент не заменяет инженера, но страхует от банальных промахов.
А вы используете статический анализ для IaC? Какой инструмент выбрали и почему? Сталкивались с инцидентами, которые можно было предотвратить автоматической проверкой?
#SRE #IaC #SAST #Security #DevSecOps #DevOps
Бывало у вас так: два инженера посмотрели в пулл-реквест, кивнули, мерджнули, а потом - бац!
Инцидент из-за кривой настройки безопасности или ресурса, улетевшего в продакшн без лимитов?
У нас бывало. И это не вопрос компетенции. Это вопрос того, что человек просто не может держать в голове все 750+ правил безопасной конфигурации.
Тут на помощь приходят инструменты статического анализа для Infrastructure as Code (IaC). Например, попался мне на глаза Checkov - https://www.checkov.io/
Что умеет:
- сканирует Terraform, CloudFormation, ARM, Helm, Kubernetes, Dockerfile и Serverless Framework
- проверяет на 750+ предустановленных политик - от открытых портов до отсутствия шифрования
- позволяет писать свои политики, если у вас специфичные требования
- интегрируется в CI/CD, чтобы ловить проблемы до мерджа
Почему это важно для SRE и DevOps:
- снижает когнитивную нагрузку на ревьюверов
- формализует знания о лучших практиках
- превращает "мы так не делаем" в автоматический чек
- дает артефакт для аудита и постмортема
Альтернативы, которые тоже стоит посмотреть:
- tfsec - легковесный, фокус на Terraform
- Terrascan - поддерживает несколько провайдеров, хорош для политик как код
- KICS от Checkmarx - открытый, с акцентом на безопасность
Внедряешь такую проверку в пайплайн - и количество "а мы не заметили" в ревью падает.
Конечно, инструмент не заменяет инженера, но страхует от банальных промахов.
А вы используете статический анализ для IaC? Какой инструмент выбрали и почему? Сталкивались с инцидентами, которые можно было предотвратить автоматической проверкой?
#SRE #IaC #SAST #Security #DevSecOps #DevOps
www.checkov.io
Prevent cloud misconfigurations and find vulnerabilities during build-time in infrastructure as code, container images and open source packages with Checkov by Bridgecrew.
Товарищи, SLO использующие, я тут перевозил в новый sloth.dev 0.15 фичу по проверке наличия дубликатов по slo_id.
И в коде заметил новинку - в мастере лежит код UI для SLI/SLO. В нем выводится список сервисов, сами SLO, и показания SLI на графиках, остатки бюджета. При запуске надо указать путь до ручки Prometheus. Поиграться с фейковыми данными можно через
Эдакая мини-Grafana. Или кто может видел - такое было в Pyrra.dev
Есть индикация активны ли ticket/page алерты сейчас. Показывает число алертов по сервису.
Ограничения - график бюджета считает в фиксированных окнах календарных.
Остаток показывает в плавающем окне. Что такое "Current Burning budget" я пока не понял. Пока еще не все "интуитивно" понятно.
Полезно, как минимум для диагностики. Я бы даже командам дал как запасной вариант.
А вы как думаете, полезно это будет? Кому в первую очередь?
#allslo #sloth #slo #tools #инструменты #sre
И в коде заметил новинку - в мастере лежит код UI для SLI/SLO. В нем выводится список сервисов, сами SLO, и показания SLI на графиках, остатки бюджета. При запуске надо указать путь до ручки Prometheus. Поиграться с фейковыми данными можно через
./sloth server --fake-prometheusЭдакая мини-Grafana. Или кто может видел - такое было в Pyrra.dev
Есть индикация активны ли ticket/page алерты сейчас. Показывает число алертов по сервису.
Ограничения - график бюджета считает в фиксированных окнах календарных.
Остаток показывает в плавающем окне. Что такое "Current Burning budget" я пока не понял. Пока еще не все "интуитивно" понятно.
Полезно, как минимум для диагностики. Я бы даже командам дал как запасной вариант.
А вы как думаете, полезно это будет? Кому в первую очередь?
#allslo #sloth #slo #tools #инструменты #sre
🔥2
Друзья и коллеги. Я внезапно обнаружил, что нас уже 150!
Для меня это неожиданно приятно.
Рад, что мои материалы и мысли тебе интересны, а возможно помогли в жизни и работе.
У меня нет конкретного контент-плана на месяцы и годы. Единственное о чем я договорился с собой - писать минимум 2 раза в рабочую неделю. А выходные оставлены под нерабочие заметки, которые ти иногда видишь - рад, что и они тебе интересны бывают.
И что интересно, чаще всего у меня находится о чем написать. А иногда и коллеги закидывают в личку предложения по темам.
Спасибо, тебе - дорогой читатель 🫠
#нерабочее #канал #подписчики
Для меня это неожиданно приятно.
Рад, что мои материалы и мысли тебе интересны, а возможно помогли в жизни и работе.
У меня нет конкретного контент-плана на месяцы и годы. Единственное о чем я договорился с собой - писать минимум 2 раза в рабочую неделю. А выходные оставлены под нерабочие заметки, которые ти иногда видишь - рад, что и они тебе интересны бывают.
И что интересно, чаще всего у меня находится о чем написать. А иногда и коллеги закидывают в личку предложения по темам.
Спасибо, тебе - дорогой читатель 🫠
#нерабочее #канал #подписчики
❤6👍6
Говорит DevOpsConf 2026 Москва: Мы набираем 🙋🙋🏻♀️волонтеров🔥 в команду организаторов
🤓 Обращаюсь к тебе как член Программного комитета DevOpsConf.
2 и 3 апреля в павильоне на ВДНХ соберется очень много инженеров: DevOps, SRE, архитекторы, лиды.
🤝 Ты подходишь, ведь ты из тех, кто хочет:
— увидеть конференцию изнутри 🔬
— стать частью нашего профессионального сообщества 😎
🗓 График волонтеров:
— 1-3 апреля (но готовы согласовать с вами конкретные дни)
— 1 апреля: офлайн инструктаж на площадке ориентировочно с 12:00-16:00
— 2-3 апреля: 08:00-20:00 с перерывами на обед, отдых и участие в афтепати в первый день (по желанию)
↩️ Что даем взамен:
🔸Полный доступ за кулисы. Увидите, как работает "внутренняя кухня" ивента. Спойлер: там веселее, чем в зале.
🗣Живое общение. Познакомитесь с членами Программного комитета, докладчиками и ключевыми ребятами из индустрии не в кулуарах "между делом", а в деле. Такие знакомства - самые крепкие.
💪 Живой опыт. Не вычитанный в книжках, а настоящий: управление живыми процессами, решение нестандартных задач, работа в команде, когда дедлайн горит. Это прокачивает то, что кодом не напишешь.
🍽 Питание для всех волонтеров на площадке.
🏨 Проживание при необходимости для иногородних. Мы поможем вам с логистикой.
Если вы готовы не просто сидеть в первом ряду, а реально помочь нам сделать этот движ - ждем💥
👉 Варианты:
1_ Я в деле — перехожу на анкету за подробностями: https://helpteam.ontico.ru/
2_ Я знаю тех кто давно такого хотел, сейчас им расскажу!
#ontico #волонтеры #devopsconf
🤓 Обращаюсь к тебе как член Программного комитета DevOpsConf.
2 и 3 апреля в павильоне на ВДНХ соберется очень много инженеров: DevOps, SRE, архитекторы, лиды.
🤝 Ты подходишь, ведь ты из тех, кто хочет:
— увидеть конференцию изнутри 🔬
— стать частью нашего профессионального сообщества 😎
🗓 График волонтеров:
— 1-3 апреля (но готовы согласовать с вами конкретные дни)
— 1 апреля: офлайн инструктаж на площадке ориентировочно с 12:00-16:00
— 2-3 апреля: 08:00-20:00 с перерывами на обед, отдых и участие в афтепати в первый день (по желанию)
↩️ Что даем взамен:
🔸Полный доступ за кулисы. Увидите, как работает "внутренняя кухня" ивента. Спойлер: там веселее, чем в зале.
🗣Живое общение. Познакомитесь с членами Программного комитета, докладчиками и ключевыми ребятами из индустрии не в кулуарах "между делом", а в деле. Такие знакомства - самые крепкие.
💪 Живой опыт. Не вычитанный в книжках, а настоящий: управление живыми процессами, решение нестандартных задач, работа в команде, когда дедлайн горит. Это прокачивает то, что кодом не напишешь.
🍽 Питание для всех волонтеров на площадке.
🏨 Проживание при необходимости для иногородних. Мы поможем вам с логистикой.
Если вы готовы не просто сидеть в первом ряду, а реально помочь нам сделать этот движ - ждем💥
👉 Варианты:
1_ Я в деле — перехожу на анкету за подробностями: https://helpteam.ontico.ru/
2_ Я знаю тех кто давно такого хотел, сейчас им расскажу!
#ontico #волонтеры #devopsconf
🔖 Прошла первая Observability Conf в Москве
Я выступил с докладом "Стандартизация логов без боли: Vector + OpenTelemetry + ClickHouse".
Это была компиляция опыта за 3 года, как мы дошли до унификации логов, что сделали и что получили. Вопросов опять было много.
Этот доклад отличается тем, что мы vitech.team выложили (Всеинструменты.ру) в open-source, то что получилось при реализации - зовем мы это Unified Log Pipeline.
🥎 Презентация и материалы к докладу тут https://github.com/vseinstrumentiru/observability-conf-2026
Пробуйте демо "Unified Log Pipeline" тут https://github.com/vseinstrumentiru/unified-log-pipeline/. Код еще будем обновлять, если найдем баги или что-то улучшим.
🤓 Буду рад, если кому-то это поможет быстро решить проблему сбора логов.
🙋 Как думаете стоит ли про это написать отдельную статью с подробностями?
Или лучше просто добавить эти же подробности, как доку в репозиторий с кодом?
Я выступил с докладом "Стандартизация логов без боли: Vector + OpenTelemetry + ClickHouse".
Это была компиляция опыта за 3 года, как мы дошли до унификации логов, что сделали и что получили. Вопросов опять было много.
Этот доклад отличается тем, что мы vitech.team выложили (Всеинструменты.ру) в open-source, то что получилось при реализации - зовем мы это Unified Log Pipeline.
🥎 Презентация и материалы к докладу тут https://github.com/vseinstrumentiru/observability-conf-2026
Пробуйте демо "Unified Log Pipeline" тут https://github.com/vseinstrumentiru/unified-log-pipeline/. Код еще будем обновлять, если найдем баги или что-то улучшим.
🤓 Буду рад, если кому-то это поможет быстро решить проблему сбора логов.
🙋 Как думаете стоит ли про это написать отдельную статью с подробностями?
Или лучше просто добавить эти же подробности, как доку в репозиторий с кодом?
GitHub
GitHub - vseinstrumentiru/observability-conf-2026: Материалы к конференции Observability Conf 2026
Материалы к конференции Observability Conf 2026. Contribute to vseinstrumentiru/observability-conf-2026 development by creating an account on GitHub.
🔥5
🛠 Опубликовали свою реализацию для сбора логов с vector.dev - Unified Log Pipeline
Год назад я рассказывал доклад на DevOpsConf 2025 "Укрощение хаоса логов с помощью модели OpenTelemetry, Vector и ClickHouse. Итоги за два года" (видео). Был план выложить в Open-source реализацию: трансформы vector.dev, Ansible-плейбук, схему БД. Но это заняло значительно больше времени, т.к. проходило проверки внутренние по ИБ и очистку кода от "лишнего". И вот теперь мы опубликовали его.
Реализация стандарта логирования на базе OpenTelemetry Logs Data Model: vector.dev трансформы, Ansible playbook, ClickHouse таблицы
https://github.com/vseinstrumentiru/unified-log-pipeline
🧐 Что скажете? Вы делали у себя что-то подобное? Получилось унифицировать сбор логов?
Год назад я рассказывал доклад на DevOpsConf 2025 "Укрощение хаоса логов с помощью модели OpenTelemetry, Vector и ClickHouse. Итоги за два года" (видео). Был план выложить в Open-source реализацию: трансформы vector.dev, Ansible-плейбук, схему БД. Но это заняло значительно больше времени, т.к. проходило проверки внутренние по ИБ и очистку кода от "лишнего". И вот теперь мы опубликовали его.
Реализация стандарта логирования на базе OpenTelemetry Logs Data Model: vector.dev трансформы, Ansible playbook, ClickHouse таблицы
https://github.com/vseinstrumentiru/unified-log-pipeline
🧐 Что скажете? Вы делали у себя что-то подобное? Получилось унифицировать сбор логов?
vkvideo.ru
ВКонтакте | Добро пожаловать
ВКонтакте – универсальное средство для общения и поиска друзей и одноклассников, которым ежедневно пользуются десятки миллионов человек. Мы хотим, чтобы друзья, однокурсники, одноклассники, соседи и коллеги всегда оставались в контакте.
Небольшой видос с Observability Conf. Про доклады конечно не расскажет, но атмосферу классно передаёт.
#видео #конференции
#видео #конференции
Альтрон зашевелился.
Китайцы создали новую модель открытую - ROME.
Кодит она по бенчмаркам лучше гигантов и сама исправляет свои ошибки. Она требует при этом в 10 раз меньше ресурсов, чем тот же GPT-OSS-120B.
По факту это дообученный Qwen 3, но в новой инфраструктуре и доработками для оптимизаций.
Каково ) Обучали они на GitHub, а сколько там встроенных майнеров - кто знает.
Подробная статья от создателей для поражения в тонкости
🤔 А что у вас в практике такого вытворяли агенты непредсказуемого?
#ai #угрозы #LLM #qwen
Китайцы создали новую модель открытую - ROME.
Кодит она по бенчмаркам лучше гигантов и сама исправляет свои ошибки. Она требует при этом в 10 раз меньше ресурсов, чем тот же GPT-OSS-120B.
По факту это дообученный Qwen 3, но в новой инфраструктуре и доработками для оптимизаций.
Интересный факт, что при обучении модели система мониторинга Alibaba Cloud зафиксировала подозрительную активность, исходящую с тренировочных серверов. После анализа выяснилось, что агент в процессе обучения с подкреплением самостоятельно - без каких-либо инструкций - начал устанавливать обратные SSH-туннели к внешним IP-адресам и несанкционированно использовать GPU-мощности для майнинга криптовалюты.
Каково ) Обучали они на GitHub, а сколько там встроенных майнеров - кто знает.
Подробная статья от создателей для поражения в тонкости
🤔 А что у вас в практике такого вытворяли агенты непредсказуемого?
#ai #угрозы #LLM #qwen
🔥2
Готовлюсь к докладу на DevOpsConf, пробовал рассказать первый раз - и мне не понравилось. Пришлось даже в презентации перестановки сделать.
Но я забыл в этот раз слушателя-дельфинчика посадить, может потому так и вышло. Экрану просто рассказывать - мозг ленится 😂.
Корректор кстати уже проверила презентацию, и нашла мне с 2 десятка пунктов на исправление. Каждый раз это удивление, вроде бы читаешь и все понятно. Но когда другой показал , где и не очень понятно, то это сразу замечаешь. Я думаю, это потому что я не читаю же слайд буквально с экрана, а припоминаю, потому не текст слайда в памяти, а что сказать.
Спасибо корректору!
❓А для чего тебе идти на конференцию? Доклады послушать, поделать руками, нетворкинг, мерча собрать, работу прогулять?
#доклад #спикеру #конференции #devopsconf #devops #sre
Но я забыл в этот раз слушателя-дельфинчика посадить, может потому так и вышло. Экрану просто рассказывать - мозг ленится 😂.
Корректор кстати уже проверила презентацию, и нашла мне с 2 десятка пунктов на исправление. Каждый раз это удивление, вроде бы читаешь и все понятно. Но когда другой показал , где и не очень понятно, то это сразу замечаешь. Я думаю, это потому что я не читаю же слайд буквально с экрана, а припоминаю, потому не текст слайда в памяти, а что сказать.
Спасибо корректору!
P.s. в этот раз конференцию перестроили по формату, потому будет как эксперимент. Станет больше воркшопов и мастер-классов, чтобы унести опыт на пальцах.
❓А для чего тебе идти на конференцию? Доклады послушать, поделать руками, нетворкинг, мерча собрать, работу прогулять?
#доклад #спикеру #конференции #devopsconf #devops #sre
🔥4
Очень отозвался пост про проведение разговоров 1 на 1
https://t.me/teamleading/502
Видел, как 1 на 1 внезапно случался на ретро, но в формате схватки. Руководитель как раз начинал защищаться, не слушать - и это лучше не видеть, напряжно.
Из статьи выше, один из самых главных советов - слушать, не давать сразу решения. Паузы в разговоре - это нормально, даже если это "бесконечные" 10с.
Стремление все решить сразу часто корреллирует с проблемой - боязнь руководителя делегировать, дать команде ошибаться. Руководитель думает: зачем мне им давать делать по своему, если я знаю как правильно. А потом удивляется, что команда не растет ментально. Она просто привыкает к его готовым решениям и не проявляет инициативу уже.
🤔 Как думаете, полезно ли такое тимлидам/руководителям? Могут ли они изменится? Или нужно менять команду?
#тиилид #1to1 #onetoone #психология #коммуникация #teamlead #управление_командой
https://t.me/teamleading/502
Видел, как 1 на 1 внезапно случался на ретро, но в формате схватки. Руководитель как раз начинал защищаться, не слушать - и это лучше не видеть, напряжно.
Из статьи выше, один из самых главных советов - слушать, не давать сразу решения. Паузы в разговоре - это нормально, даже если это "бесконечные" 10с.
Стремление все решить сразу часто корреллирует с проблемой - боязнь руководителя делегировать, дать команде ошибаться. Руководитель думает: зачем мне им давать делать по своему, если я знаю как правильно. А потом удивляется, что команда не растет ментально. Она просто привыкает к его готовым решениям и не проявляет инициативу уже.
🤔 Как думаете, полезно ли такое тимлидам/руководителям? Могут ли они изменится? Или нужно менять команду?
#тиилид #1to1 #onetoone #психология #коммуникация #teamlead #управление_командой
Telegram
Про руководство разработкой и продуктом | Олег Мохов
1x1 от Рэндса [2/2]
«Нам надо поговорить» — примерно так начинаются те редкие 1x1, которые отличаются от обычных.
В книге «Как управлять интеллектуалами» такие встречи делятся на два типа: жалобы и катастрофы.
Главное правило таких 1x1 — да и, наверное…
«Нам надо поговорить» — примерно так начинаются те редкие 1x1, которые отличаются от обычных.
В книге «Как управлять интеллектуалами» такие встречи делятся на два типа: жалобы и катастрофы.
Главное правило таких 1x1 — да и, наверное…
Forwarded from /usr/bin
witr (Why is this running?)
Утилита witr отвечает на один-единственный вопрос:
Почему это запущено?
Когда что-либо работает в системе, будь то процесс, служба или что-то, привязанное к порту, всегда есть причина. Эта причина часто бывает косвенной, неочевидной или распределена по нескольким уровням, таким как контейнеры, службы или оболочки.
Существующие инструменты (ps, top, lsof, ss, systemctl, docker ps) предоставляют доступ к состоянию и метаданным. Они показывают, что запущено, но оставляют пользователю возможность самостоятельно определить причину, вручную сопоставляя результаты работы разных инструментов.
Репыч на Гитхаб
@usr_bin_linux
Утилита witr отвечает на один-единственный вопрос:
Почему это запущено?
Когда что-либо работает в системе, будь то процесс, служба или что-то, привязанное к порту, всегда есть причина. Эта причина часто бывает косвенной, неочевидной или распределена по нескольким уровням, таким как контейнеры, службы или оболочки.
Существующие инструменты (ps, top, lsof, ss, systemctl, docker ps) предоставляют доступ к состоянию и метаданным. Они показывают, что запущено, но оставляют пользователю возможность самостоятельно определить причину, вручную сопоставляя результаты работы разных инструментов.
Репыч на Гитхаб
@usr_bin_linux
🔥1
Пожалуй вот эта утитита при диагностике сбоев в Linux будет очень полезна. Особенно знать, кто это запустил
Какие у тебя на примете утилиты не встроенные базово в Linux, которые ты бы взял в свой "швейцарский нож" для диагностики в Linux?
Какие у тебя на примете утилиты не встроенные базово в Linux, которые ты бы взял в свой "швейцарский нож" для диагностики в Linux?
Это хороший пост от Миши. Но мне он был удивителен, т.к. я лет 5 назад сам перешел на UUID v7 когда еще был Go-разработчиком. Мне просто это уже кажется само-собой разумеющееся.
Но кстати в нашей системе хранения логов нет поля log_id, а хочется сделать. Тогда проще будет одну запись выбрать, но это доп поле и доп место. Надо оценить на наших масштабах к какому приросту это приведёт.
Но кстати в нашей системе хранения логов нет поля log_id, а хочется сделать. Тогда проще будет одну запись выбрать, но это доп поле и доп место. Надо оценить на наших масштабах к какому приросту это приведёт.
Forwarded from Мишка на сервере (Mikhail Savin)
UUID v4 vs UUID v7 — почему это важно для SRE?
Привет,
Что под капотом?
UUID v4 — это 128 бит чистой случайности (122 значимых бита). Красиво, уникально, предсказуемо. Но абсолютно хаотично с точки зрения порядка.
UUID v7 — первые 48 бит это Unix timestamp в миллисекундах, остальное — случайность. Идентификаторы монотонно возрастают, то есть более новые UUID всегда лексикографически больше старых.
Почему это критично для нас с тобой?
Проблема UUID v4 — это то, что происходит с B-tree индексом в твоей БД при вставке:
- Каждый новый UUID случаен → вставки идут в произвольные места индекса;
- Это вызывает page splits (расщепление страниц) и write amplification;
- Фрагментация листовых страниц индекса у v4 достигает ~50%, тогда как у v7 — около 0%;
- Бенчмарки показывают: вставка с UUID v7 до ~34.8% быстрее, чем с v4 на 10 млн строк;
- Запросы (point lookup и range scan) у v7 быстрее за счёт лучшей локальности индекса.
SRE-профит от перехода на v7
-
- При разборе инцидента UUID в логах сразу показывает временной порядок событий — экономит время в постмортеме;
- Меньше фрагментации → меньше нагрузка на autovacuum в PostgreSQL → меньше сюрпризов в VACUUM-графиках;
- Снижается write amplification → меньше нагрузка на диск, особенно актуально для облачных managed БД с billing per I/O.
Когда v4 всё ещё ок?
- Токены сессий, CSRF-токены — там сортировка не нужна, максимальная случайность важнее;
- Системы, где раскрытие временнОго паттерна нежелательно по соображениям безопасности.
Переход с v4 на v7 в новых сервисах — это практически бесплатный перформанс буст. Библиотеки есть во всех основных языках, а PostgreSQL 18 получит нативную поддержку
Делись в комментариях — используешь ли уже UUID v7 в своих системах? Сталкивался ли с фрагментацией индексов из-за v4 в проде? Как решал — автовакуум, партиционирование, или всё-таки миграция на v7?
#SRE #DevOps #Database #PostgreSQL #UUID #Performance #IndexOptimization #BackendEngineering
Привет,
%username%! Сегодня поговорим о вещи, которая на первый взгляд кажется мелкой деталью — выборе версии UUID. Но если ты работаешь с высоконагруженными системами, эта "мелочь" влияет на производительность БД, I/O и даже на читаемость логов во время инцидентов.Что под капотом?
UUID v4 — это 128 бит чистой случайности (122 значимых бита). Красиво, уникально, предсказуемо. Но абсолютно хаотично с точки зрения порядка.
UUID v7 — первые 48 бит это Unix timestamp в миллисекундах, остальное — случайность. Идентификаторы монотонно возрастают, то есть более новые UUID всегда лексикографически больше старых.
Почему это критично для нас с тобой?
Проблема UUID v4 — это то, что происходит с B-tree индексом в твоей БД при вставке:
- Каждый новый UUID случаен → вставки идут в произвольные места индекса;
- Это вызывает page splits (расщепление страниц) и write amplification;
- Фрагментация листовых страниц индекса у v4 достигает ~50%, тогда как у v7 — около 0%;
- Бенчмарки показывают: вставка с UUID v7 до ~34.8% быстрее, чем с v4 на 10 млн строк;
- Запросы (point lookup и range scan) у v7 быстрее за счёт лучшей локальности индекса.
SRE-профит от перехода на v7
-
ORDER BY created_at становится менее актуальным — можно сортировать прямо по PK;- При разборе инцидента UUID в логах сразу показывает временной порядок событий — экономит время в постмортеме;
- Меньше фрагментации → меньше нагрузка на autovacuum в PostgreSQL → меньше сюрпризов в VACUUM-графиках;
- Снижается write amplification → меньше нагрузка на диск, особенно актуально для облачных managed БД с billing per I/O.
Когда v4 всё ещё ок?
- Токены сессий, CSRF-токены — там сортировка не нужна, максимальная случайность важнее;
- Системы, где раскрытие временнОго паттерна нежелательно по соображениям безопасности.
Переход с v4 на v7 в новых сервисах — это практически бесплатный перформанс буст. Библиотеки есть во всех основных языках, а PostgreSQL 18 получит нативную поддержку
uuidv7() из коробки.Делись в комментариях — используешь ли уже UUID v7 в своих системах? Сталкивался ли с фрагментацией индексов из-за v4 в проде? Как решал — автовакуум, партиционирование, или всё-таки миграция на v7?
#SRE #DevOps #Database #PostgreSQL #UUID #Performance #IndexOptimization #BackendEngineering
👍4