Forwarded from DevOps FM
📚 Пятничное чтиво на канале DevOps FM.
Миграция на Kubernetes прошла успешно… почти. А потом каждый миллионный запрос начал рабоатть в 100 раз медленнее. Звучит как довольно редкий баг, но команде Pinterest посчастливилось его поймать.
Инженеры долго искали виновника: проверяли ноды, копались в
Дело в том, что
Желаем всем, кто отдыхает, хороших выходных, а тем, кто дежурит — спокойных смен без серьёзных алертов!
#devops #пятничное_чтиво #debugging
Миграция на 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: кто применил
🔄 Принцип работы
SPO использует системные источники данных — например,
🔓 Как включить Security Profiles Operator?
- Установите cert-manager
Он нужен для автоматического управления сертификатами, используемыми SPO.
- Разверните Security Profiles Operator
Используйте официальный манифест из подборки репозиториев.
- Настройте хранение логов
SPO может сохранять логи: локально на узле (по умолчанию в
- Включите JSON Enricher
Он обогащает события дополнительной информацией о процессе.
- Настройте seccomp-профиль для отслеживания системных вызовов
Он фиксирует вызовы вроде
📎Репозитории с инструкциями по установке:
audit-logging-guide — описывает, как включить аудит действий внутри pod’ов и узлов через Security Profiles Operator.
installation-usage — показывает, как установить Security Profiles Operator и применить seccomp-профили к pod’ам.
С SPO вы поймете, что произошло, почему и кем было сделано — без лишней нагрузки и сложных интеграций.
#devops #kubernetes #spo
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-запрос → контейнер → процесс → результат- Установите 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
👍3❤1
Forwarded from DevOps FM
mypy в Python: типизация и контроль скриптов
👩💻 Сегодня обсудим, как встроить ad-hoc скрипты из ~/bin в предсказуемую и проверяемую автоматизацию. В статье Simple Thread Джо Понд дал руководство по снижению риска ошибок.
В чем кроется проблема?
• Скрипт удобен, но непредсказуем: ошибки типов проявляются только во время выполнения.
• Без явных контрактов функций рефакторинг становится рискованным, растёт технический долг.
• Чем больше людей правят код, тем выше риск регресса и скрытых багов в проде.
Какие решения?
Пошаговое улучшение надежности кода: добавьте статическую типизацию через mypy, управляйте зависимостями через Poetry и запускайте проверки в CI. Так, вы постепенно укрепляете код и минимизируете риски, когда проект расширяется и подключаются новые разработчики.
Как внедрить?
Проверка типов на старте — один файл за раз
• Добавьте в dev-dependencies:
• Запустите проверку для конкретного файла:
Так, вы находите баги до запуска и спокойно приступаете к следующему шагу.
Добавьте mypy в CI/CD
• Создайте окружение через Poetry и проверьте проект mypy
Типы проверяются в пайплайне: ошибки останавливают merge и защищают main branch от багов.
Мигрируйте постепенно
• Переносите типизацию модуль за модулем, начинайте с ключевых утилит и точек входа.
• Нет необходимости переписывать весь проект сразу — можно внедрять статическую проверку там, где она реально нужна.
Для желающих узнать историю развития Python рекомендуем прочесть статью здесь👈
Делимся подборкой репозиториев:
👩💻 python/mypy — анализирует типы для Python, реализует PEP 484. Нужен как эталонный инструмент для проверки контрактов и постепенной типизации кода.
👩💻 tsuyoshicho/action-mypy — готовая GitHub Action для запуска mypy в CI; поддерживает вывод в формате JSON, удобно для интеграции с reviewdog и системами агрегации ошибок
#devops #python #mypy
В чем кроется проблема?
• Скрипт удобен, но непредсказуем: ошибки типов проявляются только во время выполнения.
• Без явных контрактов функций рефакторинг становится рискованным, растёт технический долг.
• Чем больше людей правят код, тем выше риск регресса и скрытых багов в проде.
Какие решения?
Пошаговое улучшение надежности кода: добавьте статическую типизацию через 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 рекомендуем прочесть статью здесь
Делимся подборкой репозиториев:
#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) DevOps → edx.org/learn/devops
6) Docker → docker-curriculum.com
7) Kubernetes → kubernetes.io
Фундамент DevOps = Linux + Shell + облака + контейнеры + оркестрация.
Начни с базиса — дальше всё соберётся.
#linux #devops #cloud #docker #kubernetes
1) Bash → blog.sysxplore.com
2) Linux → linuxopsys.com
3) AWS → explore.skillbuilder.aws
4) Azure → learn.microsoft.com
5) DevOps → edx.org/learn/devops
6) Docker → docker-curriculum.com
7) Kubernetes → kubernetes.io
Фундамент DevOps = Linux + Shell + облака + контейнеры + оркестрация.
Начни с базиса — дальше всё соберётся.
#linux #devops #cloud #docker #kubernetes
edX
DevOps courses online | edX
Learn DevOps from top universities on edX. Master CI/CD, cloud computing, and agile to advance your software engineering career.
👎6
Forwarded from DevOps FM
От values-файлов к управлению вариантами конфигураций в ConfigHub: как перестать рендерить вслепую
В этот понедельник поговорим о переходе от классического Helm-подхода с values.yaml к модели Configuration as Data, которая реализует себя в ConfigHub. Если вы всё ещё храните values.yaml для разных сред, при аварийных запросах запускаете
Как внедрить подход?
⏺ Развертывание базового окружения (Infra Space)
1. Добавляем репозиторий Helm:
2. Разворачиваем базовое окружение для инфраструктуры:
3. Устанавливаем Helm-чарт через ConfigHub:
• ConfigHub использует движок Helm для однократного рендеринга чарта.
• Результат сохраняется как материализованный, версионируемый и индексируемый артефакт (Config Unit).
⏺ Создание пространств для окружений (Spaces)
1. Создаем пространства для каждого целевого окружения:
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
Prod
Получаем готовый YAML, а не шаблон или переменную.
⏺ Решение сценариев «Fire Drill»
1. Так как конфигурации сохранены как данные, можно выполнять поиск и анализ без повторного рендеринга:
Поиск уязвимых образов
Поиск образов
👀 Подводные камни и что делать:
• Нативные зависимости и 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
В этот понедельник поговорим о переходе от классического Helm-подхода с values.yaml к модели Configuration as Data, которая реализует себя в ConfigHub. Если вы всё ещё храните values.yaml для разных сред, при аварийных запросах запускаете
helm template и парсите YAML – рекомендуем сменить подход. В ConfigHub реализуется модель «конфигурация как данные»: вместо того чтобы каждый раз генерировать YAML из шаблонов по запросу, вы создаёте готовый манифест один раз.Как внедрить подход?
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).
1. Создаем пространства для каждого целевого окружения:
cub space create dev
cub space create prod2. В качестве альтернативы – создаем пространства через UI ConfigHub, используем кнопку [Add] на странице списка Spaces.
3. Каждое пространство будет содержать копии базовых конфигураций для конкретного окружения.
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, а не шаблон или переменную.
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 #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 по альтернативам – чуть выше, а полный тред – здесь.
Реакцию пользователей на новость можно уместить в один комментарий:
⏺ Теперь перейдем к решениям, инженеры разделились на два лагеря: первый не обновляется, т.к. не видит смысла в «лишней» работе:
⏺ Второй – использует Gateway API и дает рекомендации по альтернативам:
👀 Из интересного, Кэт Косгров (K8s Steering Committee) и Табита Сэйбл (SIG Security) в подкасте предположили, что не все инженеры в курсе, поддерживаются ли их кластеры Ingress NGINX, на что пользователи справедливо отметили:
💬 Что думаете об альтернативах, уже перешли на Gateway API? Делитесь опытом в комментариях.
#devops #reddit #k8s #ingress-nginx
Реакцию пользователей на новость можно уместить в один комментарий:
Kubrador
kubectl apply -f divorce.yaml
ах да, классическая смерть open source: «пожалуйста помогите нам» в течение 4-х лет –> «ладно, с нас хватит» –> «стоп, почему никто не помогает 🙁 » в то время, как 50% кластеров k8s внезапно понимают, что они живут в доме, построенном на фундаменте надежд и молитв.
32b1b46b6befce6ab149
Да ну конечно, люди используют Ingress NGINX. Я тоже не обновляюсь.
На данный момент никакого аналога с прежним функционалом нет и миграция займет много времени.
Полностью переехать на Gateway API нельзя, многие public чарты всё ещё используют Ingress. Лично я не нашёл такого аналога, чтобы точь-в-точь (если он вообще есть, потому что даже у nginx-ingress немного другие аннотации), поэтому пользуюсь тем, что есть.
Плюс, не вижу смысла, нельзя мигрировать без прерывания трафика.
Rahomka
Всё равно на проблему вообще, мы не обновляемся
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. Управление входящим трафиком стало заметно лучше, пока доволен.
Kabrandon
Не так легко узнать, работаете ли вы с Ingress NGINX? Может, вы не мейнтейнер? Если работаете с кластерами напрямую, вы по-любому знаете, на каком ingress контролере. Сомневаюсь, что вы работаете в таком случае.
Uncommon_senze
Легко понять, используете ли вы его, он не развертывается и не настраивается сам. Но да, проблема большая.
#devops #reddit #k8s #ingress-nginx
Please open Telegram to view this post
VIEW IN TELEGRAM
👎7👍2❤1
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 #пятница
В эту пятницу отправляемся в приключение! На GitHub вышел K8sQuest для тех, кто устал читать доки и хочет разобраться, как дебажить в проде на практике. В игре представлены 5 миров и 50 уровней, где предстоит разбираться с реальными проблемами внутри кластера:
На 50-м уровне воцарится хаос: море ошибок, шторм неопределённости :) Будет интересно новичкам и опытным инженерам.
#devops #k8s #пятница
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
Forwarded from Мишка на сервере (Mikhail Savin)
Почему 1 КБ может замедлить загрузку сайта?
Привет,
Когда браузер подключается к серверу, они сначала делают "рукопожатие" (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
Привет,
%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
14Kbclub
14KB Club | 14kbclub.com
An exclusive membership club of websites that do not exceed 14kb of size.
👍10❤1
Forwarded from Мишка на сервере (Mikhail Savin)
Как не сойти с ума, чиня прод – практические заметки SRE
Практические заметки SRE: принципы вместо героизма, DIS и graceful degradation, мониторинг по абсолюту и трендам, нагрузочные тесты и учения, GitOps, фичатогглы, процессы и психология дежурств. Как строить надёжную эксплуатацию и спокойно восстанавливаться из инцидентов.
https://jtprog.ru/sre-recipes-summary/
На написание этой статьи меня сподвигла книга “SRE. Рецепты выживания в продакшне для инженера по надежности” за авторством Натальи Савенковой.
#DevOps #SRE #Postmortem #Observability #incidentManagement #ChaosEngineering #post
Практические заметки 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
Привет,
Что произошло по факту?
- В середине декабря один из 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
Привет,
%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
Привет,
1. Daily note как центр дня
Идея простая: весь операционный шум летит в daily note через CLI — без переключения в GUI.
Что можно делать:
- Открывать/создавать daily одной командой (`obsidian daily`) — удобно повесить на alias
- Быстро кидать задачи во время деплоя:
- Логировать инциденты и алерты:
- Автоматически собирать standup-лог в файл
В итоге daily note становится твоей операционной консолью: все мелочи дня в одном месте, без «ой, потом занесу в Obsidian».
2. Инциденты и постмортемы по шаблону
Во время инцидента нет времени тыкаться в UI, а вот дернуть скрипт — норм.
- Шаблон
-
- Параллельно CLI дописывает в daily note TODO «Написать постмортем по INC-…» — чтобы не потерять хвост.
Так ты выстраиваешь повторяемый workflow: инцидент → карточка → постмортем, всё создаётся автоматически.
3. Быстрый capture из терминала
Obsidian CLI можно сделать конечной точкой для всего текстового шума.
- Идеи для статей:
- Логи команд:
Получается единая точка правды: что запускал, что упало, какие идеи родились.
4. Поиск и быстрый доступ к знаниям
CLI даёт нормальный текстовый поиск по vault — идеально под скрипты.
- Найти всё про SLO/error budget:
- Вытащить все инциденты по конкретному сервису:
- Посмотреть задачи на сегодня (если CLI умеет задачи):
Дальше это можно встраивать в свои тулзы: от вывода списка заметок в fzf до автосборки обзоров.
А теперь к тебе:
- Используешь ли ты Obsidian (или другой PKM) в связке с терминалом и Git?
- Какие команды/хуки ты бы первым делом завёл через Obsidian CLI под свой SRE/DevOps workflow?
- Интересно ли тебе разобрать отдельно готовые bash-скрипты/alias’ы под daily, инциденты и mentoring-заметки?
Пиши в комментариях свой стек и layout vault — можно собрать под это конкретные примеры скриптов.
#Obsidian #PKM #SRE #DevOps #Automation #CLI #KnowledgeBase
Привет,
%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
Obsidian Help
Obsidian CLI - Obsidian Help
Anything you can do in Obsidian can be done from the command line.
❤5👍3👎2
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 Мишка на сервере (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 Мишка на сервере (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 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 #девопс
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
И тут он прав. Для одного хоста и пары сервисов Kubernetes - это из пушки по воробьям. Бесшовно перекатить контейнер умеет и nginx, никакой оркестратор для этого не нужен.
Только это подмена тезиса. В k8s идут не за zero-downtime деплоем - за ним и так все умеют. Идут за другим.
Первое - пул машин. Compose заперт в пределах одного хоста. В комментах это сразу и поймали: «тысячи проверок в минуту - это вообще немного, спокойно живёт на одной железке. Kubernetes берут, когда надо выйти за её пределы». Вот и весь спор.
Второе - стандарт. k3s ставится за пять минут, и ты получаешь готовую вселенную типового тулинга. Новый человек приходит с любого облака и сразу в теме. А не разбирает полгода твой самодельный оркестратор из bash'а и скотча.
Лучший коммент в треде - вообще не про технику. Человек честно признался: «взяли инструмент попроще, проект взлетел - и все эти "сложные" фичи k8s внезапно стали нужны. Зря не взяли сразу». Знакомо до боли. 🤡🤡
Короче. «Не нужен Kubernetes» - честный заголовок. Просто допишите в конце: «пока у тебя один хост». А на втором десятке нод поговорим заново.
#kubernetes #docker #devops
StatusDude
Zero-Downtime Deployments with Docker Compose — No Kubernetes Required | StatusDude
We tried Traefik for zero-downtime deploys. It dropped requests, returned 404s, and couldn't retry on a different backend. HAProxy fixed everything in 60 lines of config.
👍4❤1👎1
Forwarded from DevOps FM
Как Codex обнаружил регрессию в Kubernetes
👩💻 Начинаем рабочую неделю с фотоотчёта DevOps Lab и рабочего кейса портала HeyOnCall.
После обновления Kubernetes до версии 1.36 Майк Роббинс заметил проблему на небольшом тестовом кластере.
Проблема возникла из-за небольшого регресса в коде
🔵 В статье о том, как найти утечку памяти в
➡️ А здесь мы оставили фото участников лабы, делимся атмосферой. Отмечайте @DevOps_FM в соц.сетях и расскажите о своих впечатлениях – тут 💙
#kubernetes #devops #kubelet #никсис
После обновления Kubernetes до версии 1.36 Майк Роббинс заметил проблему на небольшом тестовом кластере.
kubelet постепенно «съедал» всю память. Поды работали нормально, но pprof обнаружил миллион объектов контекста. Проблема возникла из-за небольшого регресса в коде
startPodSync, и при каждом цикле синхронизации создавался новый context.WithCancel(), а старый никогда не освобождался. С Codex Роббинс быстро обнаружил проблемный коммит, подготовил исправление, прошёл ревью и добился включения патча в основную ветку и бэкпорта для релиза 1.36.3.kubelet с Go pprof и сократить потребление с 1 ГБ до 110 МБ, почему подобные ошибки сложно поймать на тестировании и какая строка кода может привести к утечке сотен мегабайт памяти на каждой ноде. #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 при обмене ключами. Усилили безопасность и устранили уязвимости в
⏺ С релизом 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
Также в отчёте разобрали атаки от 8 июня на Tchap с кражей 13,5 ГБ данных, и от 11 июня с выводом 1,3 ТБ данных. В первом случае в открытый доступ попали email-адреса и сведения об организациях более 73 тыс. из 600 тыс. учетных записей. Детали отчёта – здесь.
ssh(1), sshd(8), scp(1) и sftp(1). Подробнее об улучшениях – тут.На примере Kind-кластера он показывает, почему традиционные политики безопасности, не работают в динамической среде Kubernetes, а также объясняет, как Cilium реализует аутентификацию (mTLS) без Sidecar. Демо – тут.
Внутренняя платформа 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 в проде - это для вас
- НОВОЕ
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
Если готовитесь к экзамену 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
GitHub
cks/tasks/ica/course at master · ViktorUJ/cks
Open-source Platform for learning kubernetes and aws eks and preparation for for Certified Kubernetes exams (CKA ,CKS , CKAD, ICA) - ViktorUJ/cks
👍3❤1
Forwarded from Мишка на сервере (Mikhail Savin)
SRE Mind map
Просто оставлю это тут:
https://jtprogru.github.io/The-Way-of-SRE/mindmap/
Заходи, знакомься и накидывай PR/issues с полезностями!
#TheWayofSRE #TWoSRE #Github #SRE #DevOps
Просто оставлю это тут:
https://jtprogru.github.io/The-Way-of-SRE/mindmap/
Заходи, знакомься и накидывай PR/issues с полезностями!
#TheWayofSRE #TWoSRE #Github #SRE #DevOps
🔥4