Пятничный деплой
4.75K subscribers
1.52K photos
35 videos
167 files
7.96K links
Подборка ссылок, статей и постов из мира DevOps\SRE\разработки. Если вы хотите прислать фидбек, интересную статью или просто поболтать пишите @count0ru https://xn--r1a.website/s/count0_digest
Download Telegram
Forwarded from DevOps FM
📚 Пятничное чтиво на канале DevOps FM.

Миграция на Kubernetes прошла успешно… почти. А потом каждый миллионный запрос начал рабоатть в 100 раз медленнее. Звучит как довольно редкий баг, но команде Pinterest посчастливилось его поймать.

Инженеры долго искали виновника: проверяли ноды, копались в cgroups и безрезультатно отключали CPU pinning. Только глубокое расследование вывело их на виновника — cAdvisor, компонент мониторинга Kubernetes.

Дело в том, что cAdvisor запускал метрику container_referenced_bytes, которая принудительно сбрасывала accessed-биты в памяти. Это вызывало TLB-флеши и тормозила поисковый движок Pinterest. Историю, полную боли, багов и отладки на грани отчаяния можно прочитать по ссылке.

Желаем всем, кто отдыхает, хороших выходных, а тем, кто дежурит — спокойных смен без серьёзных алертов!

#devops #пятничное_чтиво #debugging
🔥6👍2
Forwarded from DevOps FM
Kubernetes под микроскопом: как SPO видит действия пользователей

👩‍💻Всем DevOps! Сегодня поговорим о том, как отслеживать, что происходит внутри контейнеров в Kubernetes. В стандартной конфигурации Kubernetes аудит фиксирует только действия на уровне API: кто применил kubectl exec или kubectl debug. Что именно происходило внутри pod’а после входа в контейнер увидеть нельзя. Эту проблему решает Security Profiles Operator (SPO) — отслеживайте действия пользователей и процессов внутри pod’ов и на узлах.

🔄Принцип работы
SPO использует системные источники данных — например, /var/log/audit/audit.log и /proc/<pid>. Каждое событие записывается в JSON-формате, а JSON Enricher связывает его с соответствующим API-запросом через request UID. Это позволяет восстановить полную цепочку: API-запрос → контейнер → процесс → результат

🔓Как включить Security Profiles Operator?
- Установите cert-manager
Он нужен для автоматического управления сертификатами, используемыми SPO.
- Разверните Security Profiles Operator
Используйте официальный манифест из подборки репозиториев.
- Настройте хранение логов
SPO может сохранять логи: локально на узле (по умолчанию в /var/log/security-profiles-operator/ ), в общем томе (PVC), или выводить в stdout — удобно для интеграции с системами сбора логов вроде Loki или Elasticsearch;
- Включите JSON Enricher
Он обогащает события дополнительной информацией о процессе.
- Настройте seccomp-профиль для отслеживания системных вызовов
Он фиксирует вызовы вроде execve и clone, а объект ProfileBinding применяет профиль ко всем pod’ам в выбранном пространстве имён ( namespace ).

📎Репозитории с инструкциями по установке:
audit-logging-guide — описывает, как включить аудит действий внутри pod’ов и узлов через Security Profiles Operator.
installation-usage — показывает, как установить Security Profiles Operator и применить seccomp-профили к pod’ам.

С SPO вы поймете, что произошло, почему и кем было сделано — без лишней нагрузки и сложных интеграций.

#devops #kubernetes #spo
Please open Telegram to view this post
VIEW IN TELEGRAM
👍31
Forwarded from DevOps FM
mypy в Python: типизация и контроль скриптов

👩‍💻Сегодня обсудим, как встроить ad-hoc скрипты из ~/bin в предсказуемую и проверяемую автоматизацию. В статье Simple Thread Джо Понд дал руководство по снижению риска ошибок.

В чем кроется проблема?
• Скрипт удобен, но непредсказуем: ошибки типов проявляются только во время выполнения.
• Без явных контрактов функций рефакторинг становится рискованным, растёт технический долг.
• Чем больше людей правят код, тем выше риск регресса и скрытых багов в проде.

Какие решения?
Пошаговое улучшение надежности кода: добавьте статическую типизацию через mypy, управляйте зависимостями через Poetry и запускайте проверки в CI. Так, вы постепенно укрепляете код и минимизируете риски, когда проект расширяется и подключаются новые разработчики.

Как внедрить?
Проверка типов на старте — один файл за раз
• Добавьте в dev-dependencies:
poetry add --group dev mypy

• Запустите проверку для конкретного файла:
poetry run mypy main.py

Так, вы находите баги до запуска и спокойно приступаете к следующему шагу.

Добавьте mypy в CI/CD
• Создайте окружение через Poetry и проверьте проект mypy
poetry run mypy .

Типы проверяются в пайплайне: ошибки останавливают merge и защищают main branch от багов.

Мигрируйте постепенно
• Переносите типизацию модуль за модулем, начинайте с ключевых утилит и точек входа.
• Нет необходимости переписывать весь проект сразу — можно внедрять статическую проверку там, где она реально нужна.

Для желающих узнать историю развития Python рекомендуем прочесть статью здесь 👈

Делимся подборкой репозиториев:
👩‍💻python/mypy — анализирует типы для Python, реализует PEP 484. Нужен как эталонный инструмент для проверки контрактов и постепенной типизации кода.
👩‍💻 tsuyoshicho/action-mypy — готовая GitHub Action для запуска mypy в CI; поддерживает вывод в формате JSON, удобно для интеграции с reviewdog и системами агрегации ошибок

#devops #python #mypy
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
Forwarded from DevOps
7 бесплатных ресурсов, чтобы прокачаться в Linux и DevOps 👇

1) Bash → blog.sysxplore.com
2) Linux → linuxopsys.com
3) AWS → explore.skillbuilder.aws
4) Azure → learn.microsoft.com
5) DevOpsedx.org/learn/devops
6) Docker → docker-curriculum.com
7) Kubernetes → kubernetes.io

Фундамент DevOps = Linux + Shell + облака + контейнеры + оркестрация.
Начни с базиса — дальше всё соберётся.

#linux #devops #cloud #docker #kubernetes
👎6
Forwarded from DevOps FM
От values-файлов к управлению вариантами конфигураций в ConfigHub: как перестать рендерить вслепую

В этот понедельник поговорим о переходе от классического Helm-подхода с values.yaml к модели Configuration as Data, которая реализует себя в ConfigHub. Если вы всё ещё храните values.yaml для разных сред, при аварийных запросах запускаете helm template и парсите YAML – рекомендуем сменить подход. В ConfigHub реализуется модель «конфигурация как данные»: вместо того чтобы каждый раз генерировать YAML из шаблонов по запросу, вы создаёте готовый манифест один раз.

Как внедрить подход?
Развертывание базового окружения (Infra Space)

1. Добавляем репозиторий Helm:

helm repo update


2. Разворачиваем базовое окружение для инфраструктуры:
cub space create infra


3. Устанавливаем Helm-чарт через ConfigHub:


cub helm install --space infra \
--use-placeholder=false \
--namespace monitoring \
prometheus prometheus-community/kube-prometheus-stack \
--version 79.6.1


• ConfigHub использует движок Helm для однократного рендеринга чарта.
• Результат сохраняется как материализованный, версионируемый и индексируемый артефакт (Config Unit).

Создание пространств для окружений (Spaces)
1. Создаем пространства для каждого целевого окружения:
cub space create dev
cub space create prod

2. В качестве альтернативы – создаем пространства через UI ConfigHub, используем кнопку [Add] на странице списка Spaces.
3. Каждое пространство будет содержать копии базовых конфигураций для конкретного окружения.

Клонирование и создание Вариантов (Variants)
Variant – это копия Config Unit, которая создается через операцию Clone.

1. Создаем Dev Variant из базового окружения:
2. Выбираем чарты в infra space.
3. Выбираем dev space как цель.
4. Нажимаем [Clone Units].
5. Создаем Prod Variant из Dev Variant аналогично.

⬆️Так, мы получаем цепочку конфигураций:
[infra's Helm charts] → [dev's Helm charts] → [prod's Helm charts]

Аналогичную концепцию можем использовать в Kustomize. Мы начинаем с базовых ресурсов, а затем добавляем к ним «Dev Overlays».

Мгновенный доступ к конфигурациям
1. После клонирования не требуется повторный рендеринг.
2. Получаем точные манифесты для окружений:

Dev

cub unit get --space dev prometheus --data-only


Prod

cub unit get --space prod prometheus --data-only


Получаем готовый YAML, а не шаблон или переменную.

Решение сценариев «Fire Drill»
1. Так как конфигурации сохранены как данные, можно выполнять поиск и анализ без повторного рендеринга:

Поиск уязвимых образов

cub unit list --space "*" \
--resource-type monitoring.coreos.com/v1/Prometheus \
--where-data "spec.image ~ '.*registry.compromised.com.*'"


Поиск образов

cub unit list --space "*" \
--resource-type monitoring.coreos.com/v1/Prometheus \
--where-data "spec.image ~ '.*quay.io.*'"


👀Подводные камни и что делать:
• Нативные зависимости и postinstall хуки. При рендере учитывайте, что некоторые чарты рассчитывают поведение во время выполнения. Обязательный этап – прогон тестов в staging.
• Избежание версионных конфликтов Helm чартов, за счет фиксирования версий чарта; используйте lock-файлы чарта или helmfile для управления групповыми релизами.

Делимся полезными ресурсами:
⚙️Интеграция ConfigHub-workflow с CI/CD (build → render → store → apply), примеры для GitHub Actions/GitLab CI и рекомендации по кэшированию здесь.
How-to по Variants и GitOps (ArgoCD/Flux) – синхронизация «данных-конфигураций» с Git и кластерами (Kustomize в ArgoCD), подробнее тут.

#confighub #kubernetes #helm #devops
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍2🔥2
Forwarded from DevOps FM
Ingress NGINX: замены нет или миграция возможна?

👤На Reddit-е обсудили прекращение поддержки Ingress NGINX, работу кластеров, которые не получают обновления безопасности, а пользователи поделились своим негодованием и возможностями миграции. Статья CNCF по альтернативам – чуть выше, а полный тред – здесь.

Реакцию пользователей на новость можно уместить в один комментарий:

Kubrador
kubectl apply -f divorce.yaml
ах да, классическая смерть open source: «пожалуйста помогите нам» в течение 4-х лет –> «ладно, с нас хватит» –> «стоп, почему никто не помогает 🙁 » в то время, как 50% кластеров k8s внезапно понимают, что они живут в доме, построенном на фундаменте надежд и молитв.


Теперь перейдем к решениям, инженеры разделились на два лагеря: первый не обновляется, т.к. не видит смысла в «лишней» работе:

32b1b46b6befce6ab149
Да ну конечно, люди используют Ingress NGINX. Я тоже не обновляюсь.
На данный момент никакого аналога с прежним функционалом нет и миграция займет много времени.
Полностью переехать на Gateway API нельзя, многие public чарты всё ещё используют Ingress. Лично я не нашёл такого аналога, чтобы точь-в-точь (если он вообще есть, потому что даже у nginx-ingress немного другие аннотации), поэтому пользуюсь тем, что есть.

Плюс, не вижу смысла, нельзя мигрировать без прерывания трафика.


Rahomka
Всё равно на проблему вообще, мы не обновляемся


Второй – использует Gateway API и дает рекомендации по альтернативам:

mirrax
Вопрос к тем, кто не обновляется, в чем проблема? Что вы такого делаете, что прям зависит от аннотаций NGINX? Вы не сможете разобраться со всем этим у другого провайдера или использовать Gateway?

EpicDan
Вы же не обязаны использовать встроенные Ingress'ы в public чартах, можно для каждого приложения добавить HTTPRoute через Gateway API, работает нормально.

pilchardus_
Мне кажется, больше 50% k8s кластеров на NGINX, лол. Лично я переезжаю на Traefik на этой неделе.


me1337
Я переехал на F5 NGINX Ingress – без проблем, всё завелось.


FluidIdea
Лично мне нравятся Envoy Gateway (EG) или kgateway, по бенчмаркам хороши. Traefik – не единственный вариант.


edeltoaster
Я уже полностью переехал на Gateway API и Envoy Gateway. Плюс собрал свой кастомный образ с расширением Go-native от Coraza. Управление входящим трафиком стало заметно лучше, пока доволен.


👀Из интересного, Кэт Косгров (K8s Steering Committee) и Табита Сэйбл (SIG Security) в подкасте предположили, что не все инженеры в курсе, поддерживаются ли их кластеры Ingress NGINX, на что пользователи справедливо отметили:

Kabrandon
Не так легко узнать, работаете ли вы с Ingress NGINX? Может, вы не мейнтейнер? Если работаете с кластерами напрямую, вы по-любому знаете, на каком ingress контролере. Сомневаюсь, что вы работаете в таком случае.


Uncommon_senze
Легко понять, используете ли вы его, он не развертывается и не настраивается сам. Но да, проблема большая.


💬Что думаете об альтернативах, уже перешли на Gateway API? Делитесь опытом в комментариях.

#devops #reddit #k8s #ingress-nginx
Please open Telegram to view this post
VIEW IN TELEGRAM
👎7👍21
Forwarded from DevOps FM
🔧Чиним кластеры: игра по освоению Kubernetes

В эту пятницу отправляемся в приключение! На GitHub вышел K8sQuest для тех, кто устал читать доки и хочет разобраться, как дебажить в проде на практике. В игре представлены 5 миров и 50 уровней, где предстоит разбираться с реальными проблемами внутри кластера:
Мир 1: CrashLoopBackOff, ImagePullBackOff, pending поды, метки, порты
Мир 2: Deployments, HPA, пробы работспособности и готовности, откаты
Мир 3: Сервисы, DNS, Ingress, Сетевые политики
Мир 4: PVs, PVCs, StatefulSet-ы, ConfigMap-ы, Секреты

На 50-м уровне воцарится хаос: море ошибок, шторм неопределённости :) Будет интересно новичкам и опытным инженерам.

🚀Делитесь в комментариях, до какого уровня дошли! Желаем хороших выходных, а дежурным – спокойных смен.

#devops #k8s #пятница
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
Forwarded from Мишка на сервере (Mikhail Savin)
Почему 1 КБ может замедлить загрузку сайта?

Привет, %username%! Знал ли ты, что добавив всего 1 КБ данных к своему сайту, ты можешь удвоить время его загрузки? Звучит как магия, но на самом деле все дело в том, как работает TCP Slow Start — механизм, который не дает серверу сразу заливать весь ответ клиенту.

Когда браузер подключается к серверу, они сначала делают "рукопожатие" (TCP Handshake) — обмениваются тремя пакетами (SYN, SYN-ACK, ACK), что занимает один RTT (Round Trip Time — время туда и обратно). Только после этого начинается передача данных, но и тут TCP не торопится.

Вот в чем фишка: TCP начинает с маленького окна перегрузки (Congestion Window), обычно равного 10 MSS (Maximum Segment Size). MSS — это максимальный размер полезных данных в одном TCP-сегменте, обычно около 1460 байт. Умножаем 1460 байт на 10 MSS и получаем примерно 14 600 байт — наши магические 14 КБ!

Что это означает на практике?

- Если твой HTML весит 14 КБ — он полностью влезает в начальное окно и прилетает за один RTT.
- Если твой HTML весит 15 КБ — первые 14 КБ уйдут сразу, но оставшийся 1 КБ TCP не отправит, пока не придет подтверждение (ACK) на первые пакеты. Это уже второй RTT!

Разница всего 1 КБ, но из-за ограничений Slow Start получаем практически вдвое больше задержки по времени.

А что в реальном мире?

В жизни все сложнее: есть DNS-запросы, TLS-рукопожатия (в TLS 1.2 — это еще +2 RTT, в TLS 1.3 — всего +1 RTT, а с 0-RTT вообще можно обойтись без задержек при повторном подключении). HTTP/2 добавляет мультиплексирование, а HTTP/3 на базе QUIC вообще избавляется от классического TCP Slow Start.

Но самое интересное — не все CDN одинаковы! У большинства хостеров (Netlify, Heroku) начальное окно = 10 MSS (14.6 КБ), а вот Cloudflare, Fastly и GitHub Pages используют 30 MSS — это уже ~43 КБ в первой волне! Это значит, что на Cloudflare твоя страница в 15 КБ загрузится так же быстро, как 14 КБ на обычном хостинге.

Полезные выводы

- Чистишь лишнее, сжимаешь контент — каждый байт имеет значение, особенно если ты близок к границе окна перегрузки.
- Существует даже 14KB Club — сообщество сайтов, которые грузятся за один RTT.
- Не забывай про TLS 1.3 и HTTP/3 — они серьезно улучшают производительность.
- Выбор CDN тоже важен — разные провайдеры используют разные настройки initial congestion window.

А ты обращаешь внимание на размер первоначальной загрузки своих сервисов? Может быть, ты уже применяешь какие-то оптимизации или используешь определенные CDN для ускорения? Сталкивался ли ты с проблемами производительности из-за TCP Slow Start? Делись в комментариях — интересно узнать, как ты боришься с задержками и оптимизируешь время загрузки!

#SRE #DevOps #Performance #TCP #SlowStart #WebOptimization #HTTP2 #HTTP3 #CDN #Networking #Latency
👍101
Forwarded from Мишка на сервере (Mikhail Savin)
Как не сойти с ума, чиня прод – практические заметки SRE

Практические заметки SRE: принципы вместо героизма, DIS и graceful degradation, мониторинг по абсолюту и трендам, нагрузочные тесты и учения, GitOps, фичатогглы, процессы и психология дежурств. Как строить надёжную эксплуатацию и спокойно восстанавливаться из инцидентов.

https://jtprog.ru/sre-recipes-summary/

На написание этой статьи меня сподвигла книга “SRE. Рецепты выживания в продакшне для инженера по надежности” за авторством Натальи Савенковой.

#DevOps #SRE #Postmortem #Observability #incidentManagement #ChaosEngineering #post
🔥7
Forwarded from Мишка на сервере (Mikhail Savin)
Когда AI ломает облако: кейс AWS и Kiro AI

Привет, %username%! Тут всплыла интересная история: у AWS в декабре было как минимум два инцидента, в которых ключевую роль сыграли их же собственные AI-инструменты — агент Kiro и другие dev-инструменты на базе AI.

Что произошло по факту?

- В середине декабря один из AI-агентов (Kiro AI для разработчиков) получил доступ на внесение изменений и решил «delete and recreate environment» — фактически снес и пересоздал окружение, от которого зависел клиентский сервис для анализа стоимости использования AWS.
- Это привело к 13-часовому инциденту для клиентов, пользующихся этим сервисом.
- Источники внутри компании говорят, что было как минимум два подобных инцидента за последние месяцы, оба связаны с автономными AI-агентами, которым позволили действовать без человеческой проверки.
- Официальный комментарий AWS: это не «ошибка AI», а «user error» — некорректно настроенные права доступа, которые позволили агенту делать слишком много.

На мой взгляд, тут несколько очень важных уроков для нас с тобой:

- Автономный AI = ещё один супер-сильный и плохо предсказуемый оператор. Если ты даёшь агенту право менять инфраструктуру, он должен проходить те же уровни контроля, что и человек с prod-доступом (RBAC, approvals, change management, audit).
- «Пусть AI сам всё починит» без guardrails быстро превращается в «AI сам всё сломал». Нужны чёткие ограничения: где агент только предлагает actions, а где ему можно выполнять действия автоматически — и при каких SLO/условиях.
- Классические практики SRE никуда не делись: canary/gradual rollout даже для AI-автономии; принцип наименьших привилегий для агентов; чёткие runbook’и и контрольные точки, куда AI не может ступить без человека.
- Коммуникация тоже важна: AWS публично минимизирует масштаб («очень ограниченное событие», один сервис в одном регионе Китая), но 13 часов даунтайма для клиентского сервиса — это совсем не мелочь с точки зрения пострадавших пользователей.

Если смотреть шире — это хороший звоночек для всех, кто сейчас встраивает AI в CI/CD, incident response, remediation и управление инфраструктурой. AI-агенты очень быстро превращаются из «умного помощника» в «root с руками, которые не устают» — и это может быть как благом, так и идеальным источником инцидентов.

Предлагаю обсудить:

- Ходят ли AI-инструменты в твою prod-инфраструктуру сейчас? Что им разрешено: только советовать или уже что-то менять?
- Как бы ты ограничивал агентные системы: отдельные роли, sandbox-окружения, обязательные human approval на destructive actions?
- Считаешь ли ты честным называть такие кейсы «user error, not AI error», или это уже вопрос культуры ответственности и дизайна систем?

Делись опытом и идеями — особенно будет интересно почитать реальные истории, где AI уже помогает (или мешает) в эксплуатации.

@jtprogru_channel
@jtprogru_chat

#SRE #DevOps #AI #AWS #Incidents #Automation #Reliability #OnCall #Observability
3👍2
Forwarded from Мишка на сервере (Mikhail Savin)
Как прокачать Obsidian за счёт CLI, если ты SRE/DevOps

Привет, %username%! Если ты живёшь в терминале, любишь Git и автоматизацию, то Obsidian CLI — это способ превратить твой vault в нормальный рабочий инструмент, а не просто папку с заметками.

1. Daily note как центр дня

Идея простая: весь операционный шум летит в daily note через CLI — без переключения в GUI.

Что можно делать:

- Открывать/создавать daily одной командой (`obsidian daily`) — удобно повесить на alias dn.
- Быстро кидать задачи во время деплоя: obsidian daily:append content="- [ ] Проверить алерты после релиза #sre #deploy".
- Логировать инциденты и алерты: obsidian daily:append content="- [ ] Разобрать алерт по slow queries в prod #incident".
- Автоматически собирать standup-лог в файл YYYY-MM-DD.md через скрипт с obsidian create ... --append.

В итоге daily note становится твоей операционной консолью: все мелочи дня в одном месте, без «ой, потом занесу в Obsidian».

2. Инциденты и постмортемы по шаблону

Во время инцидента нет времени тыкаться в UI, а вот дернуть скрипт — норм.

- Шаблон Incident Template в Obsidian + командa: obsidian create name="$incident_id - $1" template="Incident Template".
- incident_id генеришь по дате/времени, оборачиваешь в new-incident "Kafka lag in prod" и получаешь готовую карточку инцидента.
- Параллельно CLI дописывает в daily note TODO «Написать постмортем по INC-…» — чтобы не потерять хвост.

Так ты выстраиваешь повторяемый workflow: инцидент → карточка → постмортем, всё создаётся автоматически.

3. Быстрый capture из терминала

Obsidian CLI можно сделать конечной точкой для всего текстового шума.

- Идеи для статей: obsidian create name="idea-$(date +%s)" content="# Идея\n- Обзор мониторинга long-running jobs в Kubernetes\n#ideas #blog".
- Логи команд: mycmd 2>&1 | tee /tmp/cmd.log → потом obsidian daily:append content="$(printf '\n\\\bash\n%s\n\\\\n' "$(cat /tmp/cmd.log)")".

Получается единая точка правды: что запускал, что упало, какие идеи родились.

4. Поиск и быстрый доступ к знаниям

CLI даёт нормальный текстовый поиск по vault — идеально под скрипты.

- Найти всё про SLO/error budget: obsidian search query="tag:#sre slo error budget".
- Вытащить все инциденты по конкретному сервису: obsidian search query="tag:#incident \"service:billing\"".
- Посмотреть задачи на сегодня (если CLI умеет задачи): obsidian tasks daily.

Дальше это можно встраивать в свои тулзы: от вывода списка заметок в fzf до автосборки обзоров.

А теперь к тебе:

- Используешь ли ты Obsidian (или другой PKM) в связке с терминалом и Git?
- Какие команды/хуки ты бы первым делом завёл через Obsidian CLI под свой SRE/DevOps workflow?
- Интересно ли тебе разобрать отдельно готовые bash-скрипты/alias’ы под daily, инциденты и mentoring-заметки?

Пиши в комментариях свой стек и layout vault — можно собрать под это конкретные примеры скриптов.

#Obsidian #PKM #SRE #DevOps #Automation #CLI #KnowledgeBase
5👍3👎2
Forwarded from Мишка на сервере (Mikhail Savin)
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
5👍2
Forwarded from Мишка на сервере (Mikhail Savin)
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
1
Forwarded from Мишка на сервере (Mikhail Savin)
Изменил формулу 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
2👍2
Forwarded from DevOps
💡McFly - это улучшенная история командной строки с возможностями поиска на основе временной оси, контекста и машинного обучения.

McFly заменяет стандартную историю bash с возможностью быстрого поиска по истории команд с учётом контекста текущего каталога, времени и других факторов. Он написан на Rust и работает в терминале с поддержкой fzf-подобного интерфейса.

Поддерживает:
- Bash
- Zsh
- Fish

Возможности:
- Умный поиск по истории команд.
- Учёт текущего каталога и других факторов.
- Простое подключение к вашему shell.

Установка:
Доступен через Homebrew, AUR, Nix и другие.

https://github.com/cantino/mcfly

#devops #девопс
Forwarded from ZVLB. Tech (Vladimir Zemtsov)
Наткнулся на очередную статью: «Zero-Downtime Deployments with Docker Compose — No Kubernetes Required». Автор прямо пишет - в индустрии, мол, массовое заблуждение, что для серьёзного прода нужен k8s. Не нужен. Тысячи проверок в минуту, мульти-регион, деплой по нескольку раз в день - и всё на компоузе.
И тут он прав. Для одного хоста и пары сервисов Kubernetes - это из пушки по воробьям. Бесшовно перекатить контейнер умеет и nginx, никакой оркестратор для этого не нужен.

Только это подмена тезиса. В k8s идут не за zero-downtime деплоем - за ним и так все умеют. Идут за другим.
Первое - пул машин. Compose заперт в пределах одного хоста. В комментах это сразу и поймали: «тысячи проверок в минуту - это вообще немного, спокойно живёт на одной железке. Kubernetes берут, когда надо выйти за её пределы». Вот и весь спор.

Второе - стандарт. k3s ставится за пять минут, и ты получаешь готовую вселенную типового тулинга. Новый человек приходит с любого облака и сразу в теме. А не разбирает полгода твой самодельный оркестратор из bash'а и скотча.

Лучший коммент в треде - вообще не про технику. Человек честно признался: «взяли инструмент попроще, проект взлетел - и все эти "сложные" фичи k8s внезапно стали нужны. Зря не взяли сразу». Знакомо до боли. 🤡🤡

Короче. «Не нужен Kubernetes» - честный заголовок. Просто допишите в конце: «пока у тебя один хост». А на втором десятке нод поговорим заново.

#kubernetes #docker #devops
👍41👎1
Forwarded from DevOps FM
Как Codex обнаружил регрессию в Kubernetes

👩‍💻 Начинаем рабочую неделю с фотоотчёта DevOps Lab и рабочего кейса портала HeyOnCall.

После обновления Kubernetes до версии 1.36 Майк Роббинс заметил проблему на небольшом тестовом кластере. kubelet постепенно «съедал» всю память. Поды работали нормально, но pprof обнаружил миллион объектов контекста.

Проблема возникла из-за небольшого регресса в коде startPodSync, и при каждом цикле синхронизации создавался новый context.WithCancel(), а старый никогда не освобождался. С Codex Роббинс быстро обнаружил проблемный коммит, подготовил исправление, прошёл ревью и добился включения патча в основную ветку и бэкпорта для релиза 1.36.3.

🔵В статье о том, как найти утечку памяти в kubelet с Go pprof и сократить потребление с 1 ГБ до 110 МБ, почему подобные ошибки сложно поймать на тестировании и какая строка кода может привести к утечке сотен мегабайт памяти на каждой ноде.

➡️А здесь мы оставили фото участников лабы, делимся атмосферой. Отмечайте @DevOps_FM в соц.сетях и расскажите о своих впечатлениях – тут 💙

#kubernetes #devops #kubelet #никсис
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4👎1
Forwarded from DevOps FM
Новостной дайджест от DevOps FM!

🔔Выходим в эфир с подборкой новостей и практических разборов.

В блоге Sysdig опубликовали отчёт по безопасности. В июне среди причин инцидентов выделили ошибки конфигурации, свободный доступ к открытым ресурсам в облаке.

Также в отчёте разобрали атаки от 8 июня на Tchap с кражей 13,5 ГБ данных, и от 11 июня с выводом 1,3 ТБ данных. В первом случае в открытый доступ попали email-адреса и сведения об организациях более 73 тыс. из 600 тыс. учетных записей. Детали отчёта – здесь.

В понедельник вышел релиз OpenSSH версии 10.4. Из нового добавили экспериментальную поддержку схемы подписи ML-DSA 44 + Ed25519, включили реализацию на основе NFA и ужесточили требования к протоколу SSH при обмене ключами. Усилили безопасность и устранили уязвимости в ssh(1), sshd(8), scp(1) и sftp(1). Подробнее об улучшениях – тут.

С релизом Docker Desktop 4.81.0 от 6 июля обновили Docker Compose до версии 5.2.0 и Docker Scout CLI v1.22.0. Также внесли исправления для работы с kind-кластерами, улучшили загрузку образов и устранили проблему с остановкой контейнеров. В новой версии Docker Desktop учитывает заданные таймауты вместо принудительного завершения через 1 секунду. Все изменения – здесь.

На портале FreeCodeCamp вышла статья о включении политик нулевого доверия в Kubernetes. Дестини Эрхабор подробно разбирает идентификацию рабочих нагрузок через SPIFFE, SPIRE и Cilium.

На примере Kind-кластера он показывает, почему традиционные политики безопасности, не работают в динамической среде Kubernetes, а также объясняет, как Cilium реализует аутентификацию (mTLS) без Sidecar. Демо – тут.

На Info Q Мэтт Сондерс разобрал архитектуру HubSpot и рассказал, как компания масштабировала платформу семантического поиска до 20 млрд векторов.

Внутренняя платформа Vector as a Service (VaaS) работает поверх Qdrant и обеспечивает контроль доступа, версионирование данных и сбор обратной связи. Сейчас система обслуживает 38+ команд, включает 200+ индексов, 140+ кластеров в пяти регионах и двух окружениях, а пиковая нагрузка достигает 100 тыс. запросов в секунду.

Как HubSpot сократил время запуска кластеров с Kubernetes Operator читайте – здесь.

#новостная_подборка #devops #kubernetes #openssh #zerotrust
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2👍1
Forwarded from AWS Notes (Vik M)
 Вышел релиз 0.33.1 SRE Learning Platform - крупнейшее обновление по Istio за всю историю проекта: полноценный курс для самостоятельного изучения + 4 новые практические лабы.

Если готовитесь к экзамену ICA или эксплуатируете Istio в проде - это для вас


- НОВОЕ:
- курс по Istio для самостоятельного изучения

32 главы, разбитые на две части:
• Часть 1 - подготовка к экзамену ICA
• Часть 2 - лучшие практики для прода

Каждая глава связана с практической лабой - учитесь на деле, а не только на теории. Изучать можно как на русском, так и на английском

- 4 новые лабы по Istio:
• Лаба 32 - gRPC: балансировка нагрузки по запросам, именование портов, ретраи и таймауты
• Лаба 33 - производительность и эксплуатация control plane: discovery selectors, Sidecar scope, golden signals istiod, OPA Gatekeeper
• Лаба 34 - защита и модель угроз: STRICT mTLS, default-deny, контроль egress, RBAC для Istio CRD, NetworkPolicy
• Лаба 35 - мультикластерный mesh: multi-primary, multi-network, общий CA, east-west gateway, межкластерный discovery


⚙️ Улучшения:
ping_pong теперь работает по gRPC (Echo + Health + reflection) со встроенным gRPC-клиентом / генератором нагрузки
• Debug-образы ставят kubectl-k8i через krew с автодополнением в shell; scratch/alpine-образы теперь кросс-компилируются нативно (BuildKit BUILDPLATFORM), а не под QEMU

Платформа бесплатная и с открытым исходным кодом. Ставьте звезду, форкайте и учитесь ⭐️
https://github.com/ViktorUJ/cks

Отличного настроения и пусть ваш прод живёт без падений!

#Istio #ServiceMesh #Kubernetes #SRE #DevOps #CloudNative #ICA #gRPC
👍31
Forwarded from Мишка на сервере (Mikhail Savin)
SRE Mind map

Просто оставлю это тут:

https://jtprogru.github.io/The-Way-of-SRE/mindmap/

Заходи, знакомься и накидывай PR/issues с полезностями!

#TheWayofSRE #TWoSRE #Github #SRE #DevOps
🔥4