CI/CD без боли: оптимизация пайплайнов на GitHub Actions 🚀

GitHub Actions — мощный инструмент, но без оптимизации ваш пайплайн легко превратится в тормозную мясорубку. Разбираемся, как выжать максимум из CI/CD на GitHub.


Почему это важно:
Быстрые и надёжные пайплайны — ключ к высокой скорости доставки. Медленные сборки = потеря времени, нервов и денег.


1. Кэшируй разумно
Используй actions/cache для ускорения зависимостей, но не кэшируй всё подряд. Пример для Node.js:

- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-node-

⚠️ Ключ должен быть завязан на lock-файлы, иначе можно словить конфликты версий.


2. Делай job-ы параллельными
Разделяй пайплайн на независимые шаги — unit-тесты, линтеры, сборка. Добавляй needs: там, где реально нужно, а не везде.


3. Matrix strategy — must-have
Хочешь тестировать на разных версиях языка/ОС? Используй matrix:

strategy:
  matrix:
    node-version: [16, 18, 20]

Это масштабирует проверку без дублирования кода.


4. Отключи ненужные события
Не запускай воркфлоу на каждом чихе. Используй on: грамотно:

on:
  push:
    branches:
      - main
  pull_request:
    paths:
      - 'src/**'

Это поможет не перегружать runners.


5. Используй workflow_dispatch для ручных запусков
Иногда надо протестить пайплайн руками — не бойся добавить ручной триггер:

on:
  workflow_dispatch:

6. Логи и таймауты — твои друзья
Добавляй timeout-minutes к job-ам и выводи ключевые логи через ::group:: и ::endgroup::, чтобы не утонуть в консоли.


Вывод:
Грамотно настроенный GitHub Actions экономит время и снижает головную боль. Избегай монолитных пайплайнов, кэшируй умно и тестируй только то, что нужно. Автоматизация — это про контроль, а не хаос.


#devops #девопс

🛠 25+ FTP-вопросов для собеседований: разбор с ответами

Если ты DevOps-инженер, системный администратор или сетевой специалист, то протокол FTP (File Transfer Protocol) тебе наверняка знаком. На собеседованиях часто задают вопросы по его устройству, безопасности и конфигурации. Команда Tecmint собрала ключевые FTP-вопросы с ответами, которые стоит выучить. Вот основные из них:

🔹 Что такое FTP?
File Transfer Protocol — это стандартный сетевой протокол, используемый для передачи файлов между клиентом и сервером по TCP/IP.

🔹 На каких портах работает FTP?
По умолчанию:
• Порт 21 — управляющее соединение
• Порт 20 — передача данных (в активном режиме)

🔹 Чем отличается активный и пассивный режим FTP?
В активном режиме сервер инициирует соединение для передачи данных, в пассивном — клиент сам подключается к случайному порту сервера.
💡 Пассивный режим чаще используют за NAT/фаерволами.

🔹 Что такое анонимный FTP?
Это доступ к FTP-серверу без пароля (обычно используется anonymous или ftp в качестве логина). Часто применяется для публичных загрузок.

🔹 Какие популярные FTP-серверы в Linux?
• vsftpd
• proftpd
• Pure-FTPd

🔹 Как обеспечить безопасность FTP?
Обычный FTP передаёт данные в незашифрованном виде. Для защиты используют:
• FTPS (FTP over SSL/TLS)
• SFTP (через SSH) — это вообще другой протокол
Также: ограничение по IP, chroot jail, шифрование паролей, запрет анонимного доступа.

🔹 Различия между FTP и SFTP?
• SFTP работает через SSH (порт 22)
• Обеспечивает полное шифрование
• Безопаснее, но несовместим с обычными FTP-клиентами

🔹 Какие команды FTP стоит знать?
• get, put — загрузка и выгрузка
• ls, cd, pwd, mget, mput
• passive / active — переключение режима

🔹 Как ограничить пользователя FTP в своём каталоге?
Через chroot jail: chroot_local_user=YES в vsftpd.conf

🔹 Как протестировать FTP-сервер?
Можно использовать:
• ftp (CLI)
• lftp — продвинутый CLI
• GUI-клиенты: FileZilla, WinSCP

📚 Все 25+ вопросов с ответами ты найдёшь тут → https://www.tecmint.com/ftp-interview-questions-and-answers/

⚙️ Отличный чеклист для подготовки к собеседованию или аудиту инфраструктуры!

#FTP #DevOps #Linux #Собеседование #Sysadmin #SFTP #Безопасность


@devopsitsec

🧩 DevOps-задача с подвохом: всё работает, но тормозит

У вас в Kubernetes кластере работает микросервис orders. Всё "зелёное":
- ✅ нет ошибок 5xx
- ✅ логи чистые
- ✅ CPU и RAM в норме
- ✅ Pod'ы не рестартятся
- ✅ HPA не срабатывает

Но пользователи жалуются: ⚠️ заказы проходят с задержкой до 1.5 сек.

🔍 Что под капотом:
- 3 реплики orders
- Зависимость: inventory (всего 1 реплика)
- Один из `orders`-подов иногда теряет сетевое соединение на ~30 сек
- Readiness-проба — /healthz, всегда 200 OK
- HPA срабатывает только по CPU > 80%
- Есть метрика queue_size, но она нигде не используется


🎯 Что происходит?
Kubernetes считает проблемный под "живым", потому что /healthz отвечает.
Но этот под не может достучаться до inventory.
Часть трафика уходит в никуда и тормозит.

CPU низкий, ошибок нет — HPA не срабатывает.
Проблема остаётся невидимой, пока пользователи страдают.


✅ Как починить:

1. ✂️ **Проверять зависимости в Readiness:**
```yaml
readinessProbe:
exec:
command: ["sh", "-c", "curl -sf http://inventory/healthz || exit 1"]
```

2. 📈 **Добавить алерты на latency, queue size и gRPC ошибки**

3. ⚖️ **Настроить HPA по бизнес-метрикам:**
```yaml
type: External
metric:
name: queue_size
```

4. 🧬 **Добавить 2+ реплики в `inventory`** — избавляемся от SPOF

5. 🧠 **Включить tracing (например, Jaeger)** для отслеживания зависаний

💡 **Урок:** Даже без ошибок система может работать нестабильно.
DevOps-инженер должен уметь **видеть деградацию до того, как её заметит пользователь.**

#DevOps #Kubernetes #SRE #Monitoring #CI_CD #HPA

Полезная таблица инструментов DevSecOps

Если ты учишься с нуля, устраняешь пробелы или заменяешь существующие инструменты, начни с Периодической таблицы, чтобы подобрать оптимальные решения для своей DevOps-пайплайна.

#devops #девопс

@devopsitsec

🚀 Sneak Peek: Что нового в Kubernetes v1.34

Официальный блог уже поделился предварительным обзором релиза!
Что ждать от Kubernetes 1.34?

🔹 Новый API для runtime класса (RuntimeClass v1 GA)
🔹 Оптимизация pod scheduling и NUMA-архитектуры
🔹 Стабилизация нескольких ключевых фич
🔹 Улучшения в kubelet и kube-proxy
🔹 Больше прозрачности в контроллерах

🛠️ Полный обзор от команды Kubernetes:
https://kubernetes.io/blog/2025/07/28/kubernetes-v1-34-sneak-peek/

#Kubernetes #DevOps #CloudNative

💡 Продвинутый совет для Linux-админов:
Хочешь узнать, какие процессы используют больше всего памяти (включая shared libraries, кэш и swap) — но не по PID, а по исполняемому бинарнику?

Вот способ сгруппировать потребление памяти по программам, а не по процессам.

sudo ps -e -o pid,comm --no-headers | while read pid cmd; do  
  grep -q "^Name:\s\+$cmd$" /proc/$pid/status 2>/dev/null &&  
  awk '/^RssAnon:/ {rss+=$2} END {if (rss) printf "%s %d MiB\n", "'$cmd'", rss/1024}' /proc/$pid/status  
done | sort -k2 -nr | uniq  

📊 Использование RAM по исполняемым программам (не PID)

📌 Отлично подходит для выявления прожорливых демонов, особенно если у вас десятки fork-процессов одного сервиса.

#linux #memory #admin #devops #monitoring

💡 Ещё один продвинутый совет для Linux-админов:
Проверь, какие процессы активно используют swap — даже если в системе вроде бы хватает RAM.

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

for pid in $(ls /proc | grep -E '^[0-9]+$'); do  
  cmd=$(cat /proc/$pid/comm 2>/dev/null)  
  swap=$(grep VmSwap /proc/$pid/status 2>/dev/null | awk '{print $2}')  
  if [ "$swap" != "" ] && [ "$swap" -gt 0 ]; then  
    echo "$swap KB swap used by $cmd (PID $pid)"  
  fi  
done | sort -nr | head  

🐌 Процессы, активно использующие swap (swap hog detector)

📌 Даже если swap включен "про запас", вы удивитесь, сколько "вроде бы активных" сервисов частично выгружены на диск — отсюда тормоза, задержки в API, медленные реакции.

Решения:
– пересмотреть vm.swappiness
– перезапустить эти процессы
– увеличить RAM или выделить hugepages

#linux #performance #swap #memory #sysadmin #devops

🐧 Быстрый Linux совет

Нужно повторять команду каждые несколько секунд?

Используй:
$ watch -n 2 df -h

Эта команда запускает df -h каждые 2 секунды.
Удобно для контроля за диском, нагрузкой или изменением логов.

Нажми q, чтобы выйти.

#Linux #DevOps #Tips

🚀 Git Pro совет

Хотите быстро узнать, какие файлы или папки в репозитории занимают больше всего места?
Используйте встроенную команду git вместе с rev-list и objects:

# Самые большие файлы в истории репозитория

git rev-list --objects --all | \
  git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | \
  grep '^blob' | \
  sort -k3nr | head -10

💡 Это помогает найти «тяжёлые» файлы, случайно закоммиченные в историю (например, большие датасеты или бинарники).
После нахождения ненужного файла можно использовать git filter-repo или BFG Repo-Cleaner, чтобы очистить историю и уменьшить размер репозитория.

#DevOps #Tips #git

📌 Git Revert vs Git Reset: В чём разница? 🔄

Когда вы делаете ошибку в Git, важно понимать, как правильно её исправить. Два самых популярных способа — git revert и git reset. Но они работают по-разному!

### 🔹 Git Revert
- Создаёт новый коммит, который отменяет изменения из проблемного коммита.
- История сохраняется полностью — всё видно, даже ошибка.
- Безопасный вариант для публичных веток (например, `main`).
- Не удаляет коммиты — просто "откатывает" их эффект.

> 💡 Пример:
> C1 → C2 → C3 (ошибка) → C4: Revert C3
> Результат: ошибка отменена, но история остаётся полной.

🔹 Git Reset
- Удаляет коммит(ы) из истории.
- Изменяет историю репозитория — может быть опасно, если уже был пуш.
- Подходит только для локальных изменений или ещё не опубликованных коммитов.
- Есть три режима: soft, mixed, hard.

> 💡 Пример:
> C1 → C2 → C3 (ошибка) → C3 убрано
> Результат: история обрезана, как будто коммит никогда не был.

💡 Вывод:
revert — безопасный и прозрачный способ отменить изменения.
reset — мощный инструмент, но требует осторожности.

📌 Понимание этих команд — ключ к уверенной работе с Git!

#Git #DevOps #Programming #SoftwareEngineering

📌 20 ключевых навыков для Linux-администратора

Если хочешь уверенно работать с Linux в DevOps/инфраструктуре — вот карта, по которой можно идти:

— Командная строка: cd, ls, ps, top, tmux, ssh
— Права и пользователи: chmod, chown, группы, sudo
— SSH-ключи и безопасность доступа
— Firewall: iptables, ufw
— Резервные копии: rsync, cron
— Bash/Python скриптинг для автоматизации
— Package managers: apt, yum, dnf
— Network troubleshooting: ping, traceroute, netstat, ss, ip
— Процессы: ps, top, systemd
— Диски: df, du, fdisk, LVM
— Git и контроль версий
— Контейнеры: Docker, Podman + основы Kubernetes
— Конфигурационное управление: Ansible, Puppet, Chef
— Облака: AWS/Azure/GCP
— CI/CD: Jenkins, GitLab CI, GitHub Actions
— Мониторинг: Prometheus, Grafana, ELK
— IaC: Terraform, CloudFormation
— Оркестрация: Kubernetes, Docker Swarm
— Сертификации: AWS, RHCE, CKA
— Постоянное обучение и практика

Linux — это фундамент для DevOps, SRE и облачной инфраструктуры.
Освой базу, автоматизируй рутину и прокачивайся каждый день 🚀

#linux #devops #sysadmin #infrastructure #cloud

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

Managed Kubernetes vs полный контроль? Первый вариант экономит ресурсы, гарантирует поддержку провайдера. Второй — дает гибкость тонких настроек, особенно когда кластеры идут в прод с высокими нагрузками.

Timeweb Cloud нашел баланс: запустили собственный оркестратор Kubernetes Toolset Layer. В планах — интеграция с панелью управления, что откроет доступ к настройке компонентов управляющего слоя. Можно будет менять конфиги групп узлов, подключать внешние ноды и делать другие кастомы без потери managed-статуса. Выглядит как крупное обновление.

Что это даст
• Гибкость: например, можно поменять интервалы автоскейлера под свои бизнес-метрики. И тем самым точнее подстроить инфраструктуру под бюджет и требования приложений

• Контроль: в ближайших релизах — мониторинг и логирование на уровне оркестратора, кластеров и их компонентов. В панели будут статусы и история изменений. Это позволит видеть, как часто и насколько масштабируется приложение

• Стабильность: при росте нагрузки на кластеры система автоматически масштабируется как платформа оркестрации. Сервисы будут стабильнее переживать пики нагрузки

Ребята также рассказали, что вместе с оркестратором реализовали интеграцию виртуальных роутеров. Теперь воркер-ноды можно размещать в приватной сети без публичных IP, а внешний доступ организовывать через Ingress или балансировщики. Это повышает безопасность и позволяет экономить на публичных IP.

Итог: провайдер серьезно прокачивает свой Managed Kubernetes. Кажется, это нечастая практика, когда дают доступ к компонентам управляющего слоя без потери managed-статуса. Плюсом — приватная сеть для нод через виртуальный роутер.

Запустить кластер

#Kubernetes #DevOps #TimewebCloud #Security

💡McFly - это улучшенная история командной строки с возможностями поиска на основе временной оси, контекста и машинного обучения.

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

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

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

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

https://github.com/cantino/mcfly

#devops #девопс

🔥 История, которая перевернула безопасность во всём мире и всё из-за одной «невидимой» ошибки

В 1979 году на АЭС Three Mile Island в США произошла одна из самых известных ядерных аварий.

Но самое страшное было не в поломке.

А в том, как люди её интерпретировали.

Операторы видели данные с приборов и сделали, казалось бы, логичный вывод:

👉 система переполнена водой
👉 нужно её уменьшить

Они действовали «по инструкции».

Но реальность была противоположной.

💥 Реальная проблема:
• реактор терял охлаждение

А действия операторов только усугубили ситуацию

Почему это произошло?

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

🧠 Это тот же тип ошибки мышления, что и у Вальда:

**мы доверяем тому, что видим
и игнорируем то, чего не видим**

После аварии провели масштабное расследование.

И выяснилось:

- интерфейсы показывали слишком много лишнего
- ключевые сигналы были «спрятаны»
- операторы не понимали, что действительно важно

⚡️ Что изменилось после этого:

- появилось направление human-centered design в критических системах
- интерфейсы начали проектировать под стрессовые ситуации
- в авиации и энергетике внедрили симуляторы аварий
- появилась концепция:
👉 «если пользователь ошибается — виноват дизайн, а не пользователь»

📊 Интересный факт:

после внедрения новых подходов к интерфейсам и обучению
👉 количество критических ошибок операторов в авиации и энергетике снизилось в разы

💡 Где это встречается сегодня:

- дашборды в аналитике
- мониторинг в DevOps
- алерты в продакшене
- метрики в AI

Ты видишь график — и думаешь, что понимаешь систему.

Но настоящая проблема часто скрыта в том,
чего нет на графике

👉 Главный вывод:

самые опасные ошибки — не в данных
а в том, как ты их интерпретируешь

📌 Параллель с Вальдом:

- там не было данных о погибших самолётах
- здесь не было понимания реального состояния реактора

И в обоих случаях: невидимое оказалось важнее видимого

#thinking #engineering #ai #devops