5 трюков в bash, которые сделают вас лучшим SRE

Перевод сделан специально для телеграм-канала Мониторим ИТ.

Передовые методы работы в командной оболочке, которые отличают джунов от синьоров

При отладке проблемы в боевой среде каждая секунда на счету. Хотя, большинство инженеров знают основной bash-команды, разница между джуном и синьором SRE часто заключается в знании этих мощных, но малоизвестных bash-функций, которые могут превратить 30-минутный поиск проблемы в 5-минутную легкую прогулку.

Представьте себе: дашборд светится, как новогодняя ёлка. Загрузка процессора резко возрастает в трёх разных средах. Файлы логов растут с каждой минутой. Канал в телеге непрерывно атакуется оповещениями.

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

1. Подстановка процесса: сравнивайте что угодно, где угодно, в режиме реального времени

Большинство инженеров знают о каналах (|) и перенаправлениях (>, <), но подстановка процесса ( <()) является секретным оружием для сравнения систем в реальном времени.

Проблема

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

Решение

# Compare live logs from two servers simultaneously
diff <(ssh server1 "tail -f /var/log/app.log") <(ssh server2 "tail -f /var/log/app.log")

# Monitor multiple Kubernetes pods side-by-side
paste <(kubectl logs -f pod1) <(kubectl logs -f pod2) | column -t
# Compare configuration files across environments instantly
diff <(curl -s https://prod.api.com/config) <(curl -s https://staging.api.com/config)

Почему это гениально

Подстановка процессов обрабатывает вывод команды как файл. Это позволяет использовать любой инструмент, ожидающий файлы (например diff, paste или join), с выводом команды в режиме реального времени. Никаких временных файлов, никакой ручной координации — только мгновенное сравнение всего, что генерируется.

Практический кейс: во время недавнего инцидента, когда API работал нестабильно, было сразу обнаружено, что один из балансировщиков нагрузки перенаправлял трафик на устаревшую версию сервиса. Вместо 20 минут ручной проверки журналов, устранение проблемы заняло 30 секунд.

2. Использование истории команд: суперспособность реагировать на инциденты

Когда во время сбоя каждая секунда на счету, повторный ввод длинных команд неэффективен и можно наделать ошибок. Расширение истории — машина времени.

Важные трюки

# Rerun the last command that contained specific text
!kubectl      # Runs the most recent kubectl command
!grep         # Runs the most recent grep command

# Fix typos instantly without retyping
^tpyo^typo    # Replaces 'tpyo' with 'typo' in the last command
# Add sudo to your previous command
sudo !!       # Reruns last command with sudo
# Reuse arguments from previous commands
cp /var/log/complex-service-name.log !$    # !$ = last argument
rm !^         # !^ = first argument from previous command

Совет профессионала

Установите это в .bashrc для еще большей крутости:

# Enable history expansion with space
bind Space:magic-space

Теперь, когда вы введете команду !kubectl и нажмете пробел, bash расширит ее, чтобы показать вам, какую именно команду она собирается выполнить.

Почему это нравится SRE: в разгар инцидента вы часто выполняете похожие команды с небольшими вариациями. Вместо того, чтобы рисковать опечатками в критически важных командах, вы можете быстро изменить и перезапустить предыдущие.

3. Использование фигурных скобок: упрощение массовых операций

Фигурные скобки — это встроенный в bash способ генерации последовательностей и вариаций, идеально подходящий для пакетных операций в нескольких службах, средах или периодах времени.

Основные шаблоны

# Create multiple backup directories at once
mkdir backup-{db,logs,config}-$(date +%Y%m%d)
# Expands to: mkdir backup-db-20241205 backup-logs-20241205 backup-config-20241205

# Check health across all environments
for env in {prod,staging,dev}; do 
    echo "=== $env ===" 
    curl -s https://$env.api.com/health | jq '.status'
done

# Quick backup with timestamp
cp nginx.conf{,.backup-$(date +%s)}
# Expands to: cp nginx.conf nginx.conf.backup-1701234567

# Download logs from a date range
wget https://logs.example.com/app-2024-{01..12}-{01..31}.log

Расширенное использование

# Mass service restart across multiple hosts
for host in web-{01..05}; do
    ssh $host "sudo systemctl restart nginx"
done

# Create directory structure for new service
mkdir -p service-{api,worker,scheduler}/{config,logs,data}

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

4. Подстановка команд с обработкой ошибок

Подстановка команд ( $()) распространена, но большинство людей не используют ее для динамических операций.

Динамические операции

# Get the running pod name and exec into it immediately
kubectl exec $(kubectl get pods -l app=myapp -o jsonpath='{.items[0].metadata.name}') -- bash

# Alert based on current system state
alert_threshold=$(curl -s http://metrics.com/thresholds | jq .cpu_alert)
current_cpu=$(top -bn1 | grep "Cpu(s)" | awk '{print $2}' | cut -d'%' -f1)
[ ${current_cpu%.*} -gt $alert_threshold ] && \
    slack-notify "🚨 CPU Alert: $current_cpu% (threshold: $alert_threshold%)"
    
# Chain operations with validation
pod_name=$(kubectl get pods --no-headers | grep Running | head -1 | awk '{print $1}') && \
kubectl logs $pod_name --tail=100 | grep ERROR | tail -5

Шаблон обработки ошибок

# Only proceed if the previous command succeeded
if pod_name=$(kubectl get pods -l app=critical --no-headers 2>/dev/null); then
    echo "Found pod: $pod_name"
    kubectl describe pod $pod_name
else
    echo "❌ No pods found - check deployment status"
    kubectl get deployments -l app=critical
fi

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

5. Использование параметров: управление конфигурацией без внешних инструментов

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

Создание интеллектуальных настроек по умолчанию

# Environment variables with fallbacks
DATABASE_URL=${DATABASE_URL:-postgresql://localhost:5432/app}
LOG_LEVEL=${LOG_LEVEL:-INFO}
TIMEOUT=${TIMEOUT:-30}
REPLIAS=${REPLICAS:-3}

# Use in deployment scripts
kubectl create deployment myapp --image=myapp:${VERSION:-latest} \
    --replicas=${REPLICAS} \
    --env="DATABASE_URL=${DATABASE_URL}" \
    --env="LOG_LEVEL=${LOG_LEVEL}"

Магия манипуляции

# Extract information from file paths
config_file="/etc/myapp/prod/database.conf"
filename=${config_file##*/}        # "database.conf"
directory=${config_file%/*}        # "/etc/myapp/prod"
environment=${directory##*/}       # "prod"

# Parse service URLs
service_url="https://api-prod-us-east-1.example.com"
region=${service_url#*-prod-}      # "us-east-1.example.com"
region=${region%%.*}               # "us-east-1"

# Conditional deployments
deploy_to=${1:-staging}            # Use first argument or default to staging
echo "Deploying to: $deploy_to"
kubectl apply -f manifests/${deploy_to}/ --namespace=${deploy_to}

Расширенные шаблоны

# Remove sensitive data from URLs for logging
db_url="postgresql://user:secret@db.example.com:5432/myapp"
safe_url=${db_url//:*@/:xxx@}      # "postgresql://user:xxx@db.example.com:5432/myapp"
echo "Connecting to: $safe_url"

# Validate required environment variables
for var in DATABASE_URL API_KEY SERVICE_NAME; do
    if [[ -z ${!var} ]]; then
        echo "❌ Missing required environment variable: $var"
        exit 1
    fi
done

Преимущество: вы можете обрабатывать сложную логику конфигурации без awk, sed или внешних инструментов. Это делает ваши скрипты более переносимыми и уменьшает количество зависимостей.

Бонус: секретное оружие SRE

Если нужен быстрый обзор системы во время инцидента:

watch -n1 '
echo "=== CPU/MEMORY ==="
top -bn1 | head -5
echo -e "\n=== DISK USAGE ==="
df -h | grep -v tmpfs
echo -e "\n=== NETWORK CONNECTIONS ==="
netstat -tuln | grep LISTEN | head -5
echo -e "\n=== RECENT ERRORS ==="
tail -n3 /var/log/syslog | grep -i error
'

Это дает дашборд состояния системы в реальном времени, которая обновляется каждую секунду.

Почему эти методы важны

В мире SRE инженеры часто работаете под давлением с системами, которые не разрабатывали, в постоянно меняющейся среде. Эти приёмы дают следующие суперспособности:

Скорость — меньше ввода текста, быстрее расследование
Надежность — меньше ручных действий, меньше ошибок
Переносимость — работают на любой системе Unix.
Масштабируемость — одновременная работа с несколькими серверами/сервисами

Практика приводит к совершенству

Попробуйте каждую неделю включать по одному новому приему:

Неделя 1: Используйте замену процесса для любой задачи сравнения
Неделя 2: Начните использовать историю вместо стрелки вверх + редактирования
Неделя 3: Замените все повторяющиеся операции с файлами на раскрытие фигурных скобок
Неделя 4: Сделайте скрипты динамичными с помощью подстановки команд
Неделя 5: Оптимизируйте обработку конфигурации с помощью параметров

Заключение

Это не просто «крутые трюки» — это профессиональные инструменты, которые повысят вашу эффективность как SRE.

Подписывайтесь на телеграм-канал Мониторим ИТ, там еще больше полезной информации!

Источник