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
❤5👍2
Forwarded from DevOps&SRE Library
linnix
https://github.com/linnix-os/linnix
eBPF-powered Linux observability with AI incident detection.
https://github.com/linnix-os/linnix
Forwarded from Мониторим ИТ
О чём логи Kubernetes не расскажут вам во время инцидента
Ритуал обработки алерта:
🔴 Срабатывает алерт.
🔴 Вы открываете логи.
🔴 Они выглядят нормально.
🔴 А продакшен всё ещё «горит».
Логи Kubernetes отлично показывают, что, по мнению приложения, произошло. Но они не помогают понять, почему система ведет себя именно так. Именно в этот промежуток времени тратится большая часть времени впустую во время инцидентов.
В статье рассказывают как подняться на уровень выше логов и посмотреть на то, что предшествовало проблеме. Только опыт.
@monitorim_it
Ритуал обработки алерта:
Логи Kubernetes отлично показывают, что, по мнению приложения, произошло. Но они не помогают понять, почему система ведет себя именно так. Именно в этот промежуток времени тратится большая часть времени впустую во время инцидентов.
В статье рассказывают как подняться на уровень выше логов и посмотреть на то, что предшествовало проблеме. Только опыт.
@monitorim_it
Please open Telegram to view this post
VIEW IN TELEGRAM
Teletype
О чём логи Kubernetes не расскажут вам во время инцидента
Это перевод оригинальной статьи What Kubernetes Logs Won’t Tell You During an Incident.
❤3
Чем заняться 9 апреля?
(спойлер: будет 🔥)
В Москве пройдёт Deckhouse Conf 2026. Если для вас импортозамещение — это не просто лозунг, а реально рабочий софт, то намек вам ясен: место встречи — «Главная сцена».
📍Что будет интересного:
—Два трека: о всех кишках Deckhouse и реалистичные кейсы внедрения. Никакой теории из учебников.
—SDN внутри Kubernetes, виртуализация, которая у всех болит, Software-Defined Storage и мониторинг с кастомными дашбордами.
—15 крутых спикеров: не просто текст на слайдах, а настоящие практики, которые знают, что делать, когда все падает.
🎯 Бонусы для любознательных:
——Демозона: можно не только смотреть и слушать, но и трогать. Пощупать стенды и задать вопросы, от которых архитекторам будет весело.
Нетворкинг с людьми, которые тянут K8s на своих плечах в России.
—Участие бесплатное, но есть премодерация заявок. Так что регаемся заранее и занимаем места, пока зал не лопнул.
Надеюсь, вы успеете заглянуть и прокачаться. Регистрация тут.
(спойлер: будет 🔥)
В Москве пройдёт Deckhouse Conf 2026. Если для вас импортозамещение — это не просто лозунг, а реально рабочий софт, то намек вам ясен: место встречи — «Главная сцена».
📍Что будет интересного:
—Два трека: о всех кишках Deckhouse и реалистичные кейсы внедрения. Никакой теории из учебников.
—SDN внутри Kubernetes, виртуализация, которая у всех болит, Software-Defined Storage и мониторинг с кастомными дашбордами.
—15 крутых спикеров: не просто текст на слайдах, а настоящие практики, которые знают, что делать, когда все падает.
🎯 Бонусы для любознательных:
——Демозона: можно не только смотреть и слушать, но и трогать. Пощупать стенды и задать вопросы, от которых архитекторам будет весело.
Нетворкинг с людьми, которые тянут K8s на своих плечах в России.
—Участие бесплатное, но есть премодерация заявок. Так что регаемся заранее и занимаем места, пока зал не лопнул.
Надеюсь, вы успеете заглянуть и прокачаться. Регистрация тут.
👍2👎2
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
🔥7
Forwarded from Мишка на сервере (Mikhail Savin)
gh-dash — твой GitHub прямо в терминале
Привет,
gh-dash — это расширение для GitHub CLI (
Что умеет
- Настраиваемые секции PR-ов и issues — отдельно под каждый репозиторий или запрос;
- Vim-style хоткеи (и возможность их переопределить под себя);
- Кастомные actions — можно вшить свой workflow прямо в интерфейс;
- Полный цикл работы с PR: diff, комментарии, checkout, push, update — всё не выходя из терминала;
- Конфигурация через обычный YAML-файл;
Под капотом —
Установка — одна команда:
Лично мне кажется, что такие инструменты реально меняют DX: вместо того чтобы прыгать между браузером и терминалом, ты остаёшься в своём привычном рабочем контексте и не теряешь фокус.
А как у тебя выстроена работа с GitHub? Используешь CLI-утилиты или всё через браузер/IDE? Есть ли другие расширения для
#GitHub #CLI #DevTools #Terminal #TUI #DevOps #SRE #DeveloperExperience #gh #OpenSource
Привет,
%username%! Если ты проводишь половину рабочего дня в браузере, переключаясь между PR-ами и issues разных репозиториев — есть способ это исправить и не выходить из терминала.gh-dash — это расширение для GitHub CLI (
gh), которое даёт тебе богатый TUI-интерфейс для работы с GitHub. Вся суть в том, что ты настраиваешь нужные тебе секции с PR-ами и issues, и видишь ровно то, что нужно — без лишнего шума.Что умеет
gh-dash:- Настраиваемые секции PR-ов и issues — отдельно под каждый репозиторий или запрос;
- Vim-style хоткеи (и возможность их переопределить под себя);
- Кастомные actions — можно вшить свой workflow прямо в интерфейс;
- Полный цикл работы с PR: diff, комментарии, checkout, push, update — всё не выходя из терминала;
- Конфигурация через обычный YAML-файл;
Под капотом —
bubbletea и lipgloss от Charm (те самые ребята, которые делают красивые TUI-инструменты на Go), delta для просмотра диффов и нативный gh для GitHub API. Проект активно развивается и это не может не радовать.Установка — одна команда:
gh extension install dlvhdr/gh-dash
Лично мне кажется, что такие инструменты реально меняют DX: вместо того чтобы прыгать между браузером и терминалом, ты остаёшься в своём привычном рабочем контексте и не теряешь фокус.
А как у тебя выстроена работа с GitHub? Используешь CLI-утилиты или всё через браузер/IDE? Есть ли другие расширения для
gh, которые зашли в ежедневный workflow — поделись в комментариях!#GitHub #CLI #DevTools #Terminal #TUI #DevOps #SRE #DeveloperExperience #gh #OpenSource
GitHub
GitHub - dlvhdr/gh-dash: A rich terminal UI for GitHub that doesn't break your flow.
A rich terminal UI for GitHub that doesn't break your flow. - dlvhdr/gh-dash
❤1
Forwarded from Про руководство разработкой и продуктом | Олег Мохов
Перегрузка когнитивной памяти
Смотрел доклад «Cognitive Overload: Bogged Down and Burnt Out» и там попалась очень наглядная иллюстрация того, что происходит, если не давать себе передышки и не оставлять место для «полезной» (germane) когнитивной нагрузки.
Идея довольно простая: если не контролировать встроенную (intrinsic) и внешнюю (extraneous) нагрузки, они забивают рабочую память.
А когда она переполняется — вы просто перестаёте учиться и нормально осмыслять происходящее.
Возьмём, например, какую-нибудь простую (по набору обязанностей) профессию — охранника в магазине.
Несмотря на кажущуюся простоту, эта работа даёт колоссальную внешнюю нагрузку: постоянное внимание, наблюдение, переключение. Вечером вы будете без сил, хотя (казалось бы) «мозгом особо и не работали».
Советы из книг про эффективность в итоге сводятся к одной вещи — создавать пространство для полезной нагрузки, лимитируя две оставшихся.
Есть куча историй про CEO (вплоть до Джобса, Гейтса и Безоса), у которых в расписании всегда стоит время «на подумать». И это время нельзя занимать никакими, даже очень важными, встречами.
Что они на самом деле делают?
Они не «магически лучше думают», а освобождают рабочую память, ограничивая объём встроенной и внешней нагрузки в течение дня — чтобы оставить ресурс на осмысление и принятие решений.
В общем, поставьте прямо сегодня в своё расписание блок на «подумать». И думайте... это, как ни странно, тоже ваша работа.
Смотрел доклад «Cognitive Overload: Bogged Down and Burnt Out» и там попалась очень наглядная иллюстрация того, что происходит, если не давать себе передышки и не оставлять место для «полезной» (germane) когнитивной нагрузки.
Идея довольно простая: если не контролировать встроенную (intrinsic) и внешнюю (extraneous) нагрузки, они забивают рабочую память.
А когда она переполняется — вы просто перестаёте учиться и нормально осмыслять происходящее.
Возьмём, например, какую-нибудь простую (по набору обязанностей) профессию — охранника в магазине.
Несмотря на кажущуюся простоту, эта работа даёт колоссальную внешнюю нагрузку: постоянное внимание, наблюдение, переключение. Вечером вы будете без сил, хотя (казалось бы) «мозгом особо и не работали».
Советы из книг про эффективность в итоге сводятся к одной вещи — создавать пространство для полезной нагрузки, лимитируя две оставшихся.
Есть куча историй про CEO (вплоть до Джобса, Гейтса и Безоса), у которых в расписании всегда стоит время «на подумать». И это время нельзя занимать никакими, даже очень важными, встречами.
Что они на самом деле делают?
Они не «магически лучше думают», а освобождают рабочую память, ограничивая объём встроенной и внешней нагрузки в течение дня — чтобы оставить ресурс на осмысление и принятие решений.
В общем, поставьте прямо сегодня в своё расписание блок на «подумать». И думайте... это, как ни странно, тоже ваша работа.
👍1
Forwarded from GitHub Open Sauce
rafska/Awesome-local-LLM
Подборка полезных платформ, инструментов, практик и ресурсов, которые помогают запускать LLM локально
#ai
https://github.com/rafska/Awesome-local-LLM
Больше про программирование на https://kodikapusta.ru
Подборка полезных платформ, инструментов, практик и ресурсов, которые помогают запускать LLM локально
#ai
https://github.com/rafska/Awesome-local-LLM
Больше про программирование на https://kodikapusta.ru
👍4👎1
Forwarded from Код и Капуста
Аллокаторы
Автор продолжает цикл статей про рантайм Go. Теперь на очереде разбор аллокаторов.
Аллокатор, по сути, компонента runtime, который эффективно управляет выделением и освобождением памяти в куче. Вместо того чтобы каждый раз обращаться к операционной системе через медленные системные вызовы, runtime заранее запрашивает у ОС крупные блоки памяти, которые затем делятся на страницы по 8 КБ. Для удовлетворения запросов программы страницы группируются в спаны, каждый из которых предназначен для объектов строго одного размера. Для решения проблемы конкурентного доступа "тысяч горутин" используется трехуровневая иерархия: быстрый и неблокирующий mcache на каждом процессоре, централизованное хранилище спанов mcentral для каждого класса с короткими блокировками и глобальный mheap, управляющий страницами.
Подробнее в статье
#golang
https://kodikapusta.ru/news/856-allokatory
Поддержать проект на boosty: https://boosty.to/kodikapusta
Автор продолжает цикл статей про рантайм Go. Теперь на очереде разбор аллокаторов.
Аллокатор, по сути, компонента runtime, который эффективно управляет выделением и освобождением памяти в куче. Вместо того чтобы каждый раз обращаться к операционной системе через медленные системные вызовы, runtime заранее запрашивает у ОС крупные блоки памяти, которые затем делятся на страницы по 8 КБ. Для удовлетворения запросов программы страницы группируются в спаны, каждый из которых предназначен для объектов строго одного размера. Для решения проблемы конкурентного доступа "тысяч горутин" используется трехуровневая иерархия: быстрый и неблокирующий mcache на каждом процессоре, централизованное хранилище спанов mcentral для каждого класса с короткими блокировками и глобальный mheap, управляющий страницами.
Подробнее в статье
#golang
https://kodikapusta.ru/news/856-allokatory
Поддержать проект на boosty: https://boosty.to/kodikapusta
Forwarded from DevOps&SRE Library
Securing Production Debugging in Kubernetes
https://kubernetes.io/blog/2026/03/18/securing-production-debugging-in-kubernetes
This covers safer Kubernetes debugging with least-privilege RBAC, short-lived identity-bound credentials, and audited SSH-style access paths.
https://kubernetes.io/blog/2026/03/18/securing-production-debugging-in-kubernetes
Forwarded from DevOps FM
Провалы в памяти Kubernetes: 90 секунд задержки
👩💻 Начинаем понедельник с разбора. На портале Dzone Шамшера Хан объясняет, с чем связана задержка в отчётности Kubernetes. Причины оставили ниже, подробности о решениях на примере лабы – в статье.
Задержка в отчетности возникает из-за трёх факторов:
• быстрое удаление событий и метрик
• отсутствие информации об объекте или конфиг в момент сбоя,
• данные из разных систем (метрики, события, логи) не связаны по времени.
Хан приводит 3 предела, в которые упирается диагностика: запрос состояния системы в конкретный момент (состояние пода в 22:32), единый контекст для сравнения метрик и сохранение истории действий контроллеров.
👩💻 Примеры на практике – в kubernetes-diagnostic-primitives repo.
Из очевидных плюсов – Kubernetes быстро восстанавливается, минус – не сохраняет причины падения. Важно фиксировать «следы инцидента», иначе картина сбоя будет неполной и приведет к повторным ошибкам.
Продуктивной недели без инцидентов!
#девопс #k8s
Задержка в отчетности возникает из-за трёх факторов:
• быстрое удаление событий и метрик
• отсутствие информации об объекте или конфиг в момент сбоя,
• данные из разных систем (метрики, события, логи) не связаны по времени.
Хан приводит 3 предела, в которые упирается диагностика: запрос состояния системы в конкретный момент (состояние пода в 22:32), единый контекст для сравнения метрик и сохранение истории действий контроллеров.
Из очевидных плюсов – Kubernetes быстро восстанавливается, минус – не сохраняет причины падения. Важно фиксировать «следы инцидента», иначе картина сбоя будет неполной и приведет к повторным ошибкам.
Продуктивной недели без инцидентов!
#девопс #k8s
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
Forwarded from Мишка на сервере (Mikhail Savin)
Изменил формулу SLI — и сломал историю. Почему это ошибка и что делать вместо этого?
Привет,
Когда меняется формула расчёта SLI, данные до и после этой точки описывают принципиально разные вещи. В статистике это называется structural break — и именно поэтому статистические агентства при смене методологии никогда не правят исторические ряды задним числом, а ведут два ряда параллельно.
В контексте SLO это особенно больно: error budget считается нарастающим итогом за 28–30 дней. Если SLI резко скакнул из-за смены формулы — error budget либо обнулится, либо станет «бесконечным», хотя реальная надёжность сервиса не изменилась ни на байт.
Что делать правильно:
- Aspirational SLO — запускаешь новый SLO параллельно старому без enforcement. Старый работает, новый наблюдается. Никто не "облажался", просто появился более точный взгляд — это паттерн из Google SRE Workbook;
- Новая метрика вместо изменения старой — именно так устроен мир Prometheus/OpenTelemetry: не переименовывай, а создавай новую и deprecate'ни старую по циклу, как это делает Kubernetes;
- Ретроактивная проверка — если меняешь только порог SLO (не формулу SLI!), можно проверить на исторических данных: поймал бы новый SLO реальные инциденты, нет ли false positives;
Важный нюанс: правильная формулировка — не «мы ошиблись», а «мы нашли более точный способ измерять надёжность». Это снимает организационный стресс и конфликт между командами, у каждой из которых теперь своё чистое измерение.
Кратко: изменение математики SLI — это не fix, это создание нового измерения. Старое не удаляй, запускай новое рядом, переходи через согласованный deprecation-цикл с явной датой и документацией.
Делитесь в комментариях — сталкивался ли ты с ситуацией, когда формулу SLI хотелось «подправить»? Как решал? Что больнее — series break в метриках или объяснение stakeholder'ам, почему error budget внезапно изменился?
PS: Еще у нас разгорелся холивар на тему надежность vs доступность — пиши в комментах, если интересны подробности.
#SRE #SLO #SLI #Reliability #ErrorBudget #Observability #DevOps #Metrics #SiteReliabilityEngineering #OnCall
Привет,
%username%! Пока я нахожусь в активном поиске работы, решил расписать подробно один тезис, который внезапно сформировался на прошедшем DevOpsConf 2026. Знакомая ситуация: измерял сервис одним способом, потом понял, что формула кривая, и просто поправил SLI. Кажется — исправил ошибку. На самом деле — создал новую, куда серьёзнее.Когда меняется формула расчёта SLI, данные до и после этой точки описывают принципиально разные вещи. В статистике это называется structural break — и именно поэтому статистические агентства при смене методологии никогда не правят исторические ряды задним числом, а ведут два ряда параллельно.
В контексте SLO это особенно больно: error budget считается нарастающим итогом за 28–30 дней. Если SLI резко скакнул из-за смены формулы — error budget либо обнулится, либо станет «бесконечным», хотя реальная надёжность сервиса не изменилась ни на байт.
Что делать правильно:
- Aspirational SLO — запускаешь новый SLO параллельно старому без enforcement. Старый работает, новый наблюдается. Никто не "облажался", просто появился более точный взгляд — это паттерн из Google SRE Workbook;
- Новая метрика вместо изменения старой — именно так устроен мир Prometheus/OpenTelemetry: не переименовывай, а создавай новую и deprecate'ни старую по циклу, как это делает Kubernetes;
- Ретроактивная проверка — если меняешь только порог SLO (не формулу SLI!), можно проверить на исторических данных: поймал бы новый SLO реальные инциденты, нет ли false positives;
Важный нюанс: правильная формулировка — не «мы ошиблись», а «мы нашли более точный способ измерять надёжность». Это снимает организационный стресс и конфликт между командами, у каждой из которых теперь своё чистое измерение.
Кратко: изменение математики SLI — это не fix, это создание нового измерения. Старое не удаляй, запускай новое рядом, переходи через согласованный deprecation-цикл с явной датой и документацией.
Делитесь в комментариях — сталкивался ли ты с ситуацией, когда формулу SLI хотелось «подправить»? Как решал? Что больнее — series break в метриках или объяснение stakeholder'ам, почему error budget внезапно изменился?
PS: Еще у нас разгорелся холивар на тему надежность vs доступность — пиши в комментах, если интересны подробности.
#SRE #SLO #SLI #Reliability #ErrorBudget #Observability #DevOps #Metrics #SiteReliabilityEngineering #OnCall
❤2👍2
Forwarded from GitHub Open Sauce
QwenLM/qwen-code
Open-source AI-агент, который живёт в вашем терминале.
#ai
https://github.com/QwenLM/qwen-code
Больше про программирование на https://kodikapusta.ru
Open-source AI-агент, который живёт в вашем терминале.
#ai
https://github.com/QwenLM/qwen-code
Больше про программирование на https://kodikapusta.ru
👍3👎1
Forwarded from DevOps
💡McFly - это улучшенная история командной строки с возможностями поиска на основе временной оси, контекста и машинного обучения.
McFly заменяет стандартную историю bash с возможностью быстрого поиска по истории команд с учётом контекста текущего каталога, времени и других факторов. Он написан на Rust и работает в терминале с поддержкой fzf-подобного интерфейса.
• Поддерживает:
- Bash
- Zsh
- Fish
• Возможности:
- Умный поиск по истории команд.
- Учёт текущего каталога и других факторов.
- Простое подключение к вашему shell.
• Установка:
Доступен через Homebrew, AUR, Nix и другие.
https://github.com/cantino/mcfly
#devops #девопс
McFly заменяет стандартную историю bash с возможностью быстрого поиска по истории команд с учётом контекста текущего каталога, времени и других факторов. Он написан на Rust и работает в терминале с поддержкой fzf-подобного интерфейса.
• Поддерживает:
- Bash
- Zsh
- Fish
• Возможности:
- Умный поиск по истории команд.
- Учёт текущего каталога и других факторов.
- Простое подключение к вашему shell.
• Установка:
Доступен через Homebrew, AUR, Nix и другие.
https://github.com/cantino/mcfly
#devops #девопс
23 апреля в 18:30 (мск) пройдёт офлайн-митап MWS Cloud Platform «Под капотом: инфраструктура». Также будет онлайн-трансляция. В программе доклады инженеров, которые ежедневно решают нетривиальные задачи при работе над инфраструктурными сервисами облака.
Из докладов вы узнаете:
— какие возможности открывают быстрые объектные хранилища, в том числе для работы с большими языковыми моделями
— как упростить для пользователя работу с управляемыми сервисами в облаке
— как снизить риски ошибок конфигурации и улучшить наблюдаемость с помощью сервисных агентов
После основной части — нетворкинг и угощения. Регистрируйтесь на митап! Это возможность обсудить нюансы, которые всплывают только в продакшене, и будут полезны на практике.
🗓23 апреля, начало в 18:30
📍Москва, Дом Культур, ул. Сретенка, 25
Вход бесплатный, но требуется регистрация и её подтверждение — количество мест ограничено.
Зарегистрироваться
Из докладов вы узнаете:
— какие возможности открывают быстрые объектные хранилища, в том числе для работы с большими языковыми моделями
— как упростить для пользователя работу с управляемыми сервисами в облаке
— как снизить риски ошибок конфигурации и улучшить наблюдаемость с помощью сервисных агентов
После основной части — нетворкинг и угощения. Регистрируйтесь на митап! Это возможность обсудить нюансы, которые всплывают только в продакшене, и будут полезны на практике.
🗓23 апреля, начало в 18:30
📍Москва, Дом Культур, ул. Сретенка, 25
Вход бесплатный, но требуется регистрация и её подтверждение — количество мест ограничено.
Зарегистрироваться
👎1
Forwarded from Мониторим ИТ
О чём логи Kubernetes не расскажут вам во время инцидента
Ритуал обработки алерта:
🔴 Срабатывает алерт.
🔴 Вы открываете логи.
🔴 Они выглядят нормально.
🔴 А продакшен всё ещё «горит».
Логи Kubernetes отлично показывают, что, по мнению приложения, произошло. Но они не помогают понять, почему система ведет себя именно так. Именно в этот промежуток времени тратится большая часть времени впустую во время инцидентов.
В статье рассказывают как подняться на уровень выше логов и посмотреть на то, что предшествовало проблеме. Только опыт.
@monitorim_it
Ритуал обработки алерта:
Логи Kubernetes отлично показывают, что, по мнению приложения, произошло. Но они не помогают понять, почему система ведет себя именно так. Именно в этот промежуток времени тратится большая часть времени впустую во время инцидентов.
В статье рассказывают как подняться на уровень выше логов и посмотреть на то, что предшествовало проблеме. Только опыт.
@monitorim_it
Please open Telegram to view this post
VIEW IN TELEGRAM
Teletype
О чём логи Kubernetes не расскажут вам во время инцидента
Это перевод оригинальной статьи What Kubernetes Logs Won’t Tell You During an Incident.
Правильное Питание для техники с Systeme Electric
Когда речь идет о стабильном питании для важного оборудования (начиная от серверов и заканчивая домашней электроникой), не просто бесперебойное, но и правильное питание — ключевые факторы. Порой даже кратковременные перебои в питании могут привести к сбоям, потере данных или выходу оборудования из строя. Да что там перебои — помехи и скачки напряжения, даже если «свет не отключали», тоже здоровья технике не добавляют.
Для борьбы со всеми проблемами низкого качества электропитания Systeme Electric разработали первые в мире ПП-ИБП — Правильное Питание для техники.
Systeme Electric — это бывшее российское подразделение Schneider Electric, производителя легендарных бесперебойников APC. «Шнайдер» ушел, а технологии, производство и команда лучших инженеров остались.
ПП-ИБП с онлайн-топологией (нулевым временем переключения на батареи) от Systeme Electric — это:
✔️ Тотальный онлайн-ЗОЖ — онлайн Защита от Отключений Железа.
✔️ Повышенная БЖУ — Бесперебойность Жизненно-важных Устройств. Тянут нагрузку в 150% от номинальной.
✔️ Настоящий суперфуд для оборудования — высочайший КПД 95%.
✔️ Самое полное ПП-меню — поддерживают все возможные интерфейсы и протоколы (EPO, SNMP, RS-485, RS-232, USB, RJ45/RJ11, EMBS).
И еще ряд преимуществ ПП-ИБП:
✔️ Монолитный корпус со встроенными аккумуляторами и продвинутый поворотный LCD-дисплей с русским языком — удобство в управлении.
✔️ Горячая замена АКБ на уровне картриджей — замена батарей происходит мгновенно, без отключения ИБП, оборудование продолжает работать.
✔️ Автоматическое определение внешних АКБ — работа без ручных настроек, все работает сразу.
✔️ Подключение до 10 дополнительных внешних батарейных блоков — время автономной работы при необходимости можно увеличить.
Причем все это — в одном устройстве. А то знаете, как оно бывает: у одного производителя одно хорошо, у другого другое. А вот так, чтобы «все и сразу» — только в ПП-ИБП.
Systeme Electric дают официальную гарантию от производителя аж 3 года. Это рекорд среди всех конкурентов. У APC by Schneider было 2 года (именно было — пока «Шнайдер» из РФ не ушел), у «китайцев» в лучшем случае год, а на серозавезенные APC гарантии, конечно же, нет.
А если что-то будет непонятно, техподдержка круглосуточная: днем — звонки, чат и мессенджеры —24/7. Т. е. даже после 6 — можно!
И никакого дешманского электро-фастфуда. На здоровье техники не экономят!
Больше информации о ПП-ИБП Systeme Electric — здесь.
Когда речь идет о стабильном питании для важного оборудования (начиная от серверов и заканчивая домашней электроникой), не просто бесперебойное, но и правильное питание — ключевые факторы. Порой даже кратковременные перебои в питании могут привести к сбоям, потере данных или выходу оборудования из строя. Да что там перебои — помехи и скачки напряжения, даже если «свет не отключали», тоже здоровья технике не добавляют.
Для борьбы со всеми проблемами низкого качества электропитания Systeme Electric разработали первые в мире ПП-ИБП — Правильное Питание для техники.
Systeme Electric — это бывшее российское подразделение Schneider Electric, производителя легендарных бесперебойников APC. «Шнайдер» ушел, а технологии, производство и команда лучших инженеров остались.
ПП-ИБП с онлайн-топологией (нулевым временем переключения на батареи) от Systeme Electric — это:
✔️ Тотальный онлайн-ЗОЖ — онлайн Защита от Отключений Железа.
✔️ Повышенная БЖУ — Бесперебойность Жизненно-важных Устройств. Тянут нагрузку в 150% от номинальной.
✔️ Настоящий суперфуд для оборудования — высочайший КПД 95%.
✔️ Самое полное ПП-меню — поддерживают все возможные интерфейсы и протоколы (EPO, SNMP, RS-485, RS-232, USB, RJ45/RJ11, EMBS).
И еще ряд преимуществ ПП-ИБП:
✔️ Монолитный корпус со встроенными аккумуляторами и продвинутый поворотный LCD-дисплей с русским языком — удобство в управлении.
✔️ Горячая замена АКБ на уровне картриджей — замена батарей происходит мгновенно, без отключения ИБП, оборудование продолжает работать.
✔️ Автоматическое определение внешних АКБ — работа без ручных настроек, все работает сразу.
✔️ Подключение до 10 дополнительных внешних батарейных блоков — время автономной работы при необходимости можно увеличить.
Причем все это — в одном устройстве. А то знаете, как оно бывает: у одного производителя одно хорошо, у другого другое. А вот так, чтобы «все и сразу» — только в ПП-ИБП.
Systeme Electric дают официальную гарантию от производителя аж 3 года. Это рекорд среди всех конкурентов. У APC by Schneider было 2 года (именно было — пока «Шнайдер» из РФ не ушел), у «китайцев» в лучшем случае год, а на серозавезенные APC гарантии, конечно же, нет.
А если что-то будет непонятно, техподдержка круглосуточная: днем — звонки, чат и мессенджеры —24/7. Т. е. даже после 6 — можно!
И никакого дешманского электро-фастфуда. На здоровье техники не экономят!
Больше информации о ПП-ИБП Systeme Electric — здесь.
👎3❤1👍1🔥1
Forwarded from Мониторим ИТ
Benchmarking Kubernetes Log Collectors: vlagent, Vector, Fluent Bit, OpenTelemetry Collector, and more
В обойме VictoriaMetrics есть vlagent — высокопроизводительный сборщик логов для VictoriaLogs. Для проверки его производительности и корректности в условиях реальной производственной нагрузки был разработан набор бенчмарков и проведены тесты на 8 популярных сборщиках логов. В этой статье описана методология, результаты по производительности, использованию ресурсов и корректности доставки.
@monitorim_it
В обойме VictoriaMetrics есть vlagent — высокопроизводительный сборщик логов для VictoriaLogs. Для проверки его производительности и корректности в условиях реальной производственной нагрузки был разработан набор бенчмарков и проведены тесты на 8 популярных сборщиках логов. В этой статье описана методология, результаты по производительности, использованию ресурсов и корректности доставки.
@monitorim_it
👍4
Forwarded from Находки в опенсорсе
tracecov: считаем покрытие АПИ через спецификацию OpenAPI
Вышла новая версия
И там мы выпустили поддержку
В чем суть? Там мы считаем не "покрытие кода", а намного более важную метрику: "покрытие тестами нашего АПИ". Ну то есть буквально:
• Какие операции были вызваны?
• С какими телами и параметрами?
• Какие ответы получены по статусам?
• Какие схемы возвращены?
• Работают ли примеры из доки?
Так как мы используем очень строгую схему - у нас такой подход хорошо работает.
Мы интегрировали поддержку
Один запуск
В
И тогда тесты будут падать при низком покрытии АПИ. Вот куда можно развиваться, если у вас - как у нас - уже 100% обычного покрытия.
Одной строкой
• Добавили поддержку
• Добавили
• Добавили
• Переработали несколько апишек, стало значительно удобнее. Спасибо первым пользователям за обратную связь!
Обсуждение: Воспользовались бы такой метрикой? И какое покрытие вы считаете оптимальным? И почему 100%?
P.S. Выпустил большую статью про
| Поддержать | YouTube | GitHub | Чат |
Вышла новая версия
0.4.0 https://github.com/wemake-services/django-modern-restИ там мы выпустили поддержку
tracecov. Инструмент новый, такого в других фреймворках я не видел.В чем суть? Там мы считаем не "покрытие кода", а намного более важную метрику: "покрытие тестами нашего АПИ". Ну то есть буквально:
• Какие операции были вызваны?
• С какими телами и параметрами?
• Какие ответы получены по статусам?
• Какие схемы возвращены?
• Работают ли примеры из доки?
Так как мы используем очень строгую схему - у нас такой подход хорошо работает.
Мы интегрировали поддержку
tracecov в наш dmr_client, который используется для всех интеграционных тестов. И schemathesis, который мы используем для property-based тестирования OpenAPI спецификации - тоже поддерживает такое.Один запуск
schemathesis позволяет добиться примерно 85+% покрытия всего АПИ. Вау! То есть: тесты можно почти не писать с таким походом.В
pyproject.toml можно добавить:
# Tracecov:
"--tracecov-format=text,html,markdown",
"--tracecov-fail-under-operations=100",
"--tracecov-fail-under-examples=100",
# TODO: set value to 100
"--tracecov-fail-under-parameters=90",
"--tracecov-fail-under-keywords=90",
"--tracecov-fail-under-responses=50",
И тогда тесты будут падать при низком покрытии АПИ. Вот куда можно развиваться, если у вас - как у нас - уже 100% обычного покрытия.
Одной строкой
• Добавили поддержку
attrs для моделей• Добавили
msgpack как протокол для АПИ, он значительно быстрее json• Добавили
JsonLines для стриминга событий• Переработали несколько апишек, стало значительно удобнее. Спасибо первым пользователям за обратную связь!
Обсуждение: Воспользовались бы такой метрикой? И какое покрытие вы считаете оптимальным? И почему 100%?
P.S. Выпустил большую статью про
django-modern-rest на Хабру: https://habr.com/ru/articles/1017036 Если есть плюсики - буду очень благодарен за помощь в продвижении!| Поддержать | YouTube | GitHub | Чат |
👍1
Forwarded from Мониторим ИТ
pusk
Pusk — self-hosted платформа для алертов и командной координации. Webhook из любого мониторинга, ACK одной кнопкой, push на телефон. Один бинарник, без внешних зависимостей.
Более известные анаологи: KeepHQ, Grafana on-call. PagerDuty, Opsgenie.
Репыч на Гитхаб
📱 Telegram | 📲 MAX
Pusk — self-hosted платформа для алертов и командной координации. Webhook из любого мониторинга, ACK одной кнопкой, push на телефон. Один бинарник, без внешних зависимостей.
Более известные анаологи: KeepHQ, Grafana on-call. PagerDuty, Opsgenie.
Репыч на Гитхаб
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2