Знали ли вы про такую команду в linux как - «yes»?

Команда yes служит для вывода в стандартный поток (stdout) строки «y» или любой другой строки. Если ее запустить по умолчанию, команда будет бесконечно сыпать строку «y».

Например, есть у вас консольная команда, которая во время своей работы будет запрашивать подтверждение: а вы точно уверены, что удаляете тестовую базу данных? Вот на такие случаи и нужна команда «yes», чтобы не руками вводить подтверждение, а делегировать это действие.

Полезно для пайплайнов. Бывает такое, что у программы нет ключей типа apt -y install, а подтверждать как-то в автоматическом режиме нужно.

Синтаксис проброса стандартный, через систему пайпов:

yes | apt install nginx

В примере выше, когда пакетный менеджер попросит нажать Y, команда «yes» автоматически это сделает и начнется процесс установки.

Не забываем, про передачу аргументов, если внешняя программа например хочет чтобы вы ввели слово: «hello» делаем так:

yes hello | apt install nginx

Но обычно на практике, в 99% случаев команда «yes» запускается без аргументов, так как большинство запрашивает именно Yes.

Если есть команда «yes», значит должна быть и «no». Но увы 😁. Так вот если нужно отменить, передайте в «yes» аргументом строку «no».

Что-то может запросить простого нажатия Enter, например когда в репозиторий добавляется gpg ключ. Как послать Enter? А вот так:

yes "" | <твоя команда>

Это сработает как Enter потому, что команда «yes» выводит в stdout не просто сроку Y, но еще и завершает ее в конце символом Enter. Вот именно поэтому при запуске чистого «yes», строчки на экране будут идти столбиком.

8 стратегий деплоя в Kubernetes и как они работают

🔹Деплой с полным пересозданием

🔹Поэтапный деплой

🔹Деплой по схеме "синяя/зелёная" среда

🔹Канареечный деплой

🔹Деплой с A/B-тестированием

🔹Теневой деплой

🔹Управляемый деплой по принципу "по возможности"

🔹Медленный градуальный деплой

https://www.groundcover.com/blog/kubernetes-deployment-strategies

Ночной подгон от Anthropic — парни выпустили собственные бесплатные курсы! 😳

Внутри десятки лекций, тесты и даже сертификаты по различным темам: от Anthropic API до MCP и лучших практик Claude Code. Всё с реальными примерами от разработчиков.

Забираем годноту здесь.

Создание качественных контейнерных образов — это не ракетостроение

Применяя всего два подхода, можно сократить размер образа и количество CVE на 50–80%:

🔹Использование multi-stage сборки

🔹Выбор базового образа подходящего размера

Учиться можно на практике: https://labs.iximiuz.com/skill-paths/build-container-images

Если вы инженер DevOps и ещё не слышали о метриках DORA — пора это исправить.

DORA расшифровывается как DevOps Research and Assessment (исследование и оценка практик DevOps).

Эта команда стоит за отчётом State of DevOps — ключевым источником информации о том, что действительно отличает высокоэффективные инженерные команды.

Но как метрики DORA применяются в реальных командах?

Вот как их можно отслеживать и даже создавать дашборды для визуализации:

🔹Частота деплоев (Deployment Frequency):
Отслеживайте количество деплоев через вашу CI/CD-платформу (GitHub Actions, GitLab, Jenkins и т.д.). Отправляйте данные о деплоях в систему метрик, такую как Prometheus, Datadog или даже Google Sheets через webhook.

🔹Время выполнения изменений (Lead Time for Changes):
Используйте временные метки Git-коммитов и событий деплоя в прод. Интегрируйте инструменты вроде Jira с GitHub или GitLab. Данные можно визуализировать в Grafana или Looker.

🔹Процент неудачных изменений (Change Failure Rate):
Интегрируйте инструменты управления инцидентами (PagerDuty, Opsgenie и т.д.) с логами деплоя. Коррелируйте инциденты с последними релизами. Это можно отслеживать в Grafana, Datadog или даже в Excel (для небольших команд).

🔹Время восстановления сервиса (Time to Restore Service):
Используйте системы алёртов, такие как Prometheus Alertmanager, Splunk или New Relic. Измеряйте время от срабатывания алёрта до полного устранения инцидента. Визуализируйте тренды на дашборде для контроля MTTR (среднего времени восстановления).

🔹Надёжность (Reliability):
Определите SLO (например, аптайм 99.9%) и отслеживайте их с помощью мониторинга SLI/SLO в Prometheus, Datadog или Nobl9. Визуализируйте бюджеты ошибок и аптайм во времени.

Инструменты вроде Grafana, Looker, Power BI или Tableau отлично подходят для создания кастомных дашбордов.

Не обязательно внедрять всё сразу.

Выберите одну метрику, постройте простой дашборд и постепенно улучшайте подход.

Важная новость! ⚠️
Работа над MVP все еще идет. Прошу прощения за перенос сроков, но мы хотим сделать реально классный продукт, поэтому нужно еще время

А пока время идет, я завтра в 15-00 раздам очередной курс. Очень хороший, поможет въехать в сети быстро 😊