🔍 Формируем 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

👩‍💻 Произошел всемирный сбой систем Windows. Из-за него нарушена работа аэропортов, больниц, СМИ, фондовых бирж, платёжных систем и сотовых операторов США, Германии, Великобритании, Японии, Австралии и других стран.

Причина — последнее обновление от поставщика кибербезопасности CrowdStrike. Устройства и серверы, на которых оно установлено, «отключаются от сети и переходят в бесконечный цикл перезагрузки».

CrowdStrike осведомлен о сообщениях о сбоях на хостах Windows, связанных с программой Falcon. Симптомы включают в себя хосты, на которых возникает ошибка bugcheck\blue screen, связанная с датчиком Falcon

— сообщила CrowdStrike.

Сообщения о сбоях в работе российских аэропортов пока в Минцифры РФ не поступали. Сбой также не коснулся российских АЭС и РЖД.

UPD: Глава CrowdStrike Джордж Куртц сообщил, что проблема с их софтом, которая привела к глобальному сбою Windows, выявлена, «изолирована» и скоро будет решена. Тем временем Microsoft уже восстановила работу некоторых сервисов.

👩‍💻 nxs-marketplace-terraform: люби и пользуйся

Как упростить развёртывание инфраструктуры в облаке? С помощью проверенных Terraform-модулей из репозитория nxs-marketplace-terraform. О них и пойдёт речь в новой статье Данила.

На примере развертывания S3-бакета и Managed Kubernetes с worker-нодами вы увидите, как готовые Terraform-модули от Nixys помогают ускорить работу и сократить вероятность ошибок. А ещё вы узнаете, зачем использовать динамические блоки в Terraform и почему файлы tfstate лучше хранить в S3.

Кликните сюда, чтобы начать читать.

#Хабр #статья_Nixys

💻 5 SQL-запросов, которые должен знать каждый инженер-программист.

INNER JOIN: возвращает только те записи, которые имеют совпадающие значения в левой и правой таблицах.

LEFT JOIN: возвращает все записи из левой таблицы и совпадающие записи из правой. Если совпадений не найдено, для столбцов правой таблицы возвращаются значения NULL.

RIGHT JOIN: возвращает все записи из правой таблицы и совпадающие записи из левой. Если совпадения не найдено, для столбцов левой таблицы возвращаются значения NULL.

FULL JOIN: извлекает все записи из левой и правой таблиц, показывая совпадающие записи, где это возможно. Для несовпадающих записей в столбцы из таблицы возвращаются NULL-значения.

CROSS JOIN: каждая строка одной таблицы соединяется с каждой строкой второй таблицы, давая тем самым в результате все возможные сочетания строк двух таблиц.


✔️ INNER JOIN идеально подходит для получения совпадающих данных из обеих таблиц, а LEFT JOIN гарантирует, что все записи из левой таблицы будут включены, даже если в правой таблице нет совпадений.

📎 Совет: убедитесь, что столбцы, используемые в условиях команды, правильно проиндексированы. Это может значительно повысить производительность ваших запросов, позволяя базе данных быстро находить и извлекать совпадающие строки.

#DevOps #SQL

👩‍💻 Это — дерево решений для выбора между инструкциями RUN, CMD и ENTRYPOINT Dockerfile.

Эту и другую полезную информацию вы найдёте в новом переводе статьи от Docker, в которой автор показывает различия этих инструкций в форматах shell и exec.

Читать перевод — на Хабре.

#DevOps #Docker

❔ Всем средовый DevOps! Сегодня — маленький опрос о том, откуда вы узнаете новости из сферы IT. В комментариях можете поделиться, какие площадки или СМИ читаете и кому доверяете.

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

👩‍💻 Truffle Security обнаружила потенциальную уязвимость, которая позволяет извлекать данные из удалённых форков и приватных репозиториев на GitHub. Её назвали Cross Fork Object Reference (CFOR).

Этот недостаток в системе безопасности является частью архитектуры GitHub. Аналогичные особенности, которые могут привести к случайному раскрытию конфиденциальных данных, можно найти и в архитектурах многих других систем контроля версий.

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

Специалисты Truffle Security опубликовали лишь 3 возможных сценария атаки. Они отмечают, что способов извлечь данные может быть намного больше. Команда настаивает, что единственным способом устранения утечки данных является ротация ключей доступа.

Вообще, трюк, позволяющий получить доступ к коммитам в форках репозитория через ссылку на основной репозиторий, уже давно известен и периодически используется just for lulz. Такие дела.

#уязвимость #GitHub

⚠️ Хакерская группировка USDoD объявила о взломе CrowdStrike. По словам хакеров, в результате атаки была скопирована вся текущая база данных IoC (Indicator of Compromise, индикатор компрометации) компании с более чем 250 млн данных. В качестве доказательства они приложили пример с указанием псевдонима, последней активности, статуса, происхождения, целевых отраслей, стран, типа субъекта и его мотивации.

👩‍💻 Напомним, что из-за инцидента с CrowdStrike 19 июля примерно 8,5 миллиона компьютеров по всему миру вышли из строя. 500 крупнейших американских компаний (за исключением Microsoft) по объёму выручки понесли убытки на сумму около 5,4 миллиарда долларов. Общемировой ущерб на сегодняшний день оценивается как минимум в 10 миллиардов долларов.

UPD: CrowdStrike дали официальный ответ:

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

#взлом #CrowdStrike #новости

🎉 Команда DevOps FM поздравляет с Днём Системного Администратора!

Немного истории. В далёком 2000 году системный администратор Тед Кикатос увидел рекламу новой модели принтера от HP. На журнальной странице был изображен радостный сисадмин, которому благодарные пользователи несут цветы, корзины с фруктами и вино.

Тед вырвал листок и пошёл показывать коллегам. Его переполняли смешанные эмоции: за 20 лет работы никто не отметил его заслуг. В тот же день он вернулся с работы и быстро создал простой сайтик (который, кстати, жив до сих пор). Там он объявил о небольшой корпоративной вечеринке, которая состоялась в пятницу, 28 июля.

Так зародился System Administrator Appreciation Day — День благодарности системному администратору.

Отмечают этот праздник не только сисадмины, но и все IT-специалисты.

🔜 Почитайте древнее, но душевное интервью с самим Тедом Кикатосом.
🔜 А вот здесь посмотрите идеи подарков, одобренные им же.

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

#SysAdminDay

👩‍💻 Знаете ли вы монолит, который во время Чёрной пятницы способен обслужить 1,27 миллиона запросов в секунду?

Shopify — это самая крупная ecommerce-платформа в мире. На сегодняшний день на ней работает более 4 млн магазинов по всему миру.

Архитектура Shopify представляет собой огромный, но эффективный и высокопроизводительный модульный монолит. Основной монолит платформы содержит более 2,8 млн строк кода Ruby и 500 тысяч коммитов.

Здесь вы можете узнать, как реализована монолитная архитектура Shopify.
Тут и там — по какому принципу платформа масштабируется и балансирует нагрузку.
А из треда в бывшем Твиттере — о её производительности в Чёрную пятницу и Киберпонедельник.

❔ А какие высокопроизводительные монолиты знаете вы?

#монолит #DevOps #интересное

📝 Настраиваем approve rules для merge request в бесплатной версии GitLab CE

Автоматизация проверки одобрений merge requests с помощью GitLab CI/CD и GitLab API — это классный способ без лишних затрат оптимизировать процесс управления кодом в команде.

Виктор, DevOps-инженер из Nixys, рассказал, как он смог настроить approve rules для merge request в бесплатной версии GitLab CE.

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

#Хабр #статья_Nixys #GitLab

👩‍💻 Kubernetes v1.31: что известно о будущем релизе

Выпуск будет состоять из 71 улучшения, из которых 34 — это новые фичи, 26 в beta-статусе и 11 будут признаны уже стабильными.

Из интересных обновлений: все интеграции облачных провайдеров окончательно перенесут из основного репозитория k8s.io/kubernetes во внешние плагины, введут возможность ограничений на уровне пода, а ещё добавят поддержку пользовательского профилирования в kubectl debug.

Посмотреть все улучшения можно по этой ссылке.

Новую версию зарезилят уже на следующей неделе, 13 августа. Ждём!

#DevOps #Kubernetes