UUID v4 vs UUID v7 — почему это важно для SRE?

Привет, %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

gh-dash — твой GitHub прямо в терминале

Привет, %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

Изменил формулу SLI — и сломал историю. Почему это ошибка и что делать вместо этого?

Привет, %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