🔍 Формируем SLO: пять советов от команды Google SRE

SLO (цель уровня обслуживания) — это соглашение в рамках SLA о конкретном показателе, который определяет качество обслуживания, предоставляемого конкретным сервисом или системой. Соглашения SLO формируют ожидания клиента и показывают команде DevOps, на какие показатели она должна ориентироваться и каких целей нужно достичь. Например, SLO может определять минимальное время доступности сервиса или максимальное время ответа на запрос.

1. Не выбирайте цель, основываясь только на текущих показателях

Да, понимание достоинств и пределов системы имеет важное значение. Но бездумная адаптация показателей может привести к тому, что вам придётся поддерживать систему, способную достигнуть целей только благодаря вашим чрезмерным героическим усилиям. Во многих случаях требует реорганизация.

2. Будьте проще

Сложные расчёты SLI могут скрыть изменения в производительности системы и усложнят поиск причины возникшей проблемы.

3. Избегайте абсолюта

Заманчиво иметь систему, которая может принимать неограниченно растущую нагрузку без увеличения задержки. Но это требование нереально. Система, которая стремится к таким идеалам, вероятно, потребует много времени и ресурсов на проектирование и создание, будет дорогой в эксплуатации… и, скорее всего, окажется неоправданно лучше той, которую пользователи уже были бы рады иметь.

4. Используйте как можно меньше SLO

Выберите достаточное количество SLO, чтобы обеспечить хорошее покрытие атрибутов системы. Защищайте выбранные вами SLO: если вы никогда не можете выиграть спор о приоритете конкретной SLO, вероятно, не стоит рассматривать эту SLO. Однако не все атрибуты системы можно преобразовать в SLO: трудно подсчитать, например, уровень "user delight" с помощью SLO.

5. Не торопитесь достичь совершенства

Лучше начать с плавающей цели, которую со временем можно сделать более точной, чем выбрать слишком строгую цель, а потом её ослабить в случае, если вы обнаружите, что она не достижима. Уточните SLO тогда, когда ваша команда узнает больше о поведении системы под нагрузкой.

#DevOps #SRE #Google

👩‍💻 tmux — это консольная утилита-мультиплексор, которая представляет собой современную копию GNU Screen под лицензией BSD. Первый выпуск tmux состоялся аж в 2007 году, а последнюю версию 3.4 выпустили в феврале 2024.

Статья Петра на Medium поможет познакомиться с tmux поближе. Вы узнаете о главных плюсах этого терминального мультиплексора и получите парочку советов по работе с ним.

#devops #tmux

Стартуем эту неделю с интересным проектом от подписчика!

💻 LazyJournal — удобный TUI для утилиты journalctl и тех, кто работает с логами в файловой системе и контейнерами Docker и Podman.

Проект написан на Go с использованием библиотеки gocui. 
Ментейнер вдохновлялся работами Jesse Duffield, по этому интерфейс будет знаком всем тем, кто уже использует LazyDocker и LazyGit.

Основные фичи:

1) Вывод выбранного журнала в режиме реального времени;

2) Поддержка динамических фильтров вывода и нечёткого поиска с подсветкой найденных слов;

3) Возможность просматривать все доступные лог-файлы из каталога /var/log с сортировкой по дате изменения (например, для Apache, Nginx или СУБД), включая доступ на чтение архивных логов.

Этот TUI избавит системных администраторов от бесконечных grep’ов и ручного поиска журналов. Попробуйте, оцените и обязательно дайте обратную связь автору!

Если у вас тоже есть интересные open-source проекты — делитесь в комментариях 👇

🤩 Кстати, ловите полезные инструменты и от нас:

• nxs-backup — инструмент резервного копирования для создания и доставки бэкапов, совместимый с дистрибутивами GNU/Linux.

• nxs-data-anonymizer — инструмент для анонимизации дампа различных баз данных PostgreSQL и MySQL/MariaDB/Percona.

#open_source #devops #ваши_инструменты

👩‍💻 В этот понедельник разбираемся, как Kubernetes API Server Proxy может стать слабым звеном в безопасности вашего кластера.

В своем блоге Рори опубликовал разбор, где наглядно показал механизм работы и скрытые подводные камни. Как сервер Kubernetes API может выступать в качестве HTTP-прокси-сервера? Есть ли ограничения использования и лазейки для атак?

Узнаем все плюсы, минусы и советы по работе — тут.

#devops #kubernetes #безопасность

👩‍💻 Обновление политик Docker Hub

Docker объявили об изменениях после обратной связи от сообщества. Команда Docker пересмотрела свои планы, чтобы улучшить поддержку экосистемы и опыт пользователей.

Смотрим на изменения:

1. Оплата за скачивание образов отменена

Docker отказались от планов по введению платы для всех пользователей. Объяснили это желанием укрепить платформу и предоставить разработчикам возможность создавать, делиться и внедрять инновации без ненужных барьеров.

2. Обновление лимитов на скачивание

Теперь для неаутентифицированных пользователей будет доступно 10 pull-запросов в час. Аутентифицированным пользователям увеличили лимит с 40 до 100 запросов в час. Для пользователей с подпиской ограничений не планируется.

3. Отсрочка платы за хранение

Планы по введению платы за хранение данных на Docker Hub отложены на неопределённый срок. Вместо этого Docker сосредоточится на создании инструментов для управления хранилищем. О любых изменениях в политике будет объявлено за 6 месяцев.

Изменения вступают в силу с 1 апреля этого года.

#DevOps #Docker #DockerHub

📚 Пятничное чтиво на канале DevOps FM.

Вам когда-нибудь приходилось выгонять AWS из вашей кровати? Нет? А вот Дилану Айри пришлось.

Автор статьи делится своим опытом исследования уязвимостей в умной кровати Eight Sleep. Устройство стоимостью $2000 предлагает регулировку температуры, однако для работы кровати требуется интернет, подписка за 19$ и мобильное приложение.

После получения прошивки устройства, которую можно легко скачать, Дилан провел исследование и не был особенно впечатлен тем, что обнаружил:
• бэкдор, который дает компании возможность получить доступ к кровати по SSH, выполнить произвольный код и оттуда исследовать всю сеть пользователя;
• активный ключ AWS, который мог быть использован для передачи данных в Amazon.

Прочитать все подробности и узнать, как автор решил проблему, можно в статье 👈

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

#devops #пятничное_чтиво

👩‍💻 Disaster recovery: пять рекомендаций от Terraform

Disaster recovery — это стратегии и инструменты, которые помогают быстро восстановить инфраструктуру после сбоев и минимизировать простой. Традиционные DR-решения могут стоить сотни тысяч долларов в год. Terraform помогает реализовать эффективные стратегии аварийного восстановления, сокращая время простоя и потери данных, а также уменьшая затраты на инфраструктуру.

4 основных стратегии, которые можно реализовать с Terraform:

1. Backup & Restore

Самая базовая и наименее затратная стратегия. Однако, в зависимости от объема данных и процесса восстановления, может привести к высоким показателям RTO и RPO. Используйте -refresh-only для синхронизации состояния после восстановления из резервной копии, чтобы избежать дрейфа.

2. Pilot Light

Это стратегия, когда минимально необходимая инфраструктура постоянно поддерживается в рабочем состоянии, а при сбое быстро разворачивается полноценная копия. Через условные выражения в Terraform можно разворачивать только минимальный набор ресурсов, а остальные оставить выключенными. С такой стратегией масштабировать инфраструктуру до необходимого состояния быстрее, чем в Backup & Restore.

3. Active/Passive

При выборе данной стратегии, у вас будет два окружения: активное и пассивное, которое стоит в режиме ожидания и включается в случае сбоя основной. Пассивное минимально синхронизируется с активным, но не обслуживает пользователей. В Terraform можно отдельно помечать активный и пассивный стенд в конфигурации через conditionals. А при инциденте менять роли, активируя пассивную инфраструктуру и почти мгновенно масштабируя её до полной.

4. Multi-Region Active/Active

Дорогостоящая, но надёжная стратегия. Полноценные среды развёрнуты в нескольких регионах и одновременно обслуживают пользователей. Если один регион выходит из строя, трафик автоматически перенаправляется в другие работоспособные среды. Здесь модули Terraform могут использоваться для инкапсуляции и повторного использования компонентов инфраструктуры.

#devops #terraform