🛠 4 утилиты для работы с текстом в терминале

Когда работаешь с логами в ход обычно идут grep и awk. Но есть и другие инструменты, которые спасают не меньше:

• tr — заменяет или убирает символы:

cat names.txt | tr '[:lower:]' '[:upper:]'

Команда превратит весь текст в CAPS LOCK.

• sort — сортирует строки:

cat errors.log | sort

Хаос превращается в аккуратный список.

• uniq — убирает дубликаты:

cat users.txt | sort | uniq

• nl — нумерует строки:

cat config.yaml | nl

Удобно искать по номерам, а не на глаз.

Вместе они превращают любой текстовый файл в данные, с которыми приятно работать.

Например:

cat access.log | cut -d' ' -f1 | sort | uniq -c | sort -nr | nl | head

Топ-10 IP-адресов по количеству запросов, с нумерацией.

🐸Библиотека devops'a

#арсенал_инженера

🔄 Как перестать тратить ресурсы CI/CD впустую

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

В GitHub Actions удобно использовать стандартные триггеры или dorny/paths-filter: он проверяет diff и включает лишь нужные джобы. Меняли api/ — запускается сборка API. Вносили правки в web/ — прогоняются тесты фронтенда. Тронули infra/** — стартует деплой инфраструктуры. Всё остальное CI просто пропускает.

Пример:

# .github/workflows/ci.yaml
name: CI

on:
  pull_request:
    paths:
      - "api/**"
      - "web/**"
      - "infra/**"
  push:
    branches: [ main ]
    paths:
      - "api/**"
      - "web/**"
      - "infra/**"

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: echo "Собираем, потому что изменились файлы из paths"

В GitLab этот механизм встроен в rules:changes. Можно настроить как отдельные jobs, так и дочерние пайплайны для разных модулей. Например, API живёт своей жизнью, фронтенд — своей, а объединяет их только Merge Request.

Пример:

stages: [build, test, deploy]

build_api:
  stage: build
  rules:
    - changes:
        - api/** 
        - package.json   # глобальный файл, влияющий на сборку API
      when: on_success
    - when: never
  script:
    - echo "Build API"; # ваши шаги

test_web:
  stage: test
  rules:
    - changes:
        - web/**
        - package.json
      when: on_success
    - when: never
  script:
    - echo "Test Web"

deploy_infra:
  stage: deploy
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      changes:
        - infra/**
        - .gitlab-ci.yml
      when: on_success
    - when: never
  script:
    - echo "Deploy Infra"

Не забывайте добавлять в фильтры и глобальные файлы — вроде package-lock.json или .gitlab-ci.yml. Они влияют на весь проект, и пропускать их опасно.

🐸Библиотека devops'a

#арсенал_инженера

😏 Быстрое переключение контекстов в Kubernetes

Когда работаете с Kubernetes, всегда приходится переключаться между кластерами — dev, staging, test, pre-prod, prod.
И каждый раз вводить длинное kubectl config use-context ... не только утомительно, но и чревато опечатками. За день такие мелочи могут отнять много времени.

Решение — небольшая утилита kubectx. Она делает переключение контекстов быстрым и удобным:

kubectx staging
kubectx prod
kubectx -

В паре с ней идёт kubens — тот же принцип, но для неймспейсов.

Итог: меньше рутины, выше скорость и меньше шансов ошибиться на боевых окружениях.

➡️ Переключить контекст

🐸Библиотека devops'a

#арсенал_инженера

🚦 Ускоряем GitLab CI/CD

Обычный пайплайн в GitLab идёт «ступеньками»: сначала build, потом test, потом deploy. Даже если задачи никак не связаны, они будут терпеливо ждать друг друга. В итоге лишние минуты и часы простаивания.

Вместо жёстких стадий можно описать зависимости между стадиями. В GitLab CI это называется DAG — Directed Acyclic Graphs.

Например:

— линтер может запуститься сразу, не дожидаясь сборки,
— тесты стартуют сразу после билда,
— деплой уходит в бой, как только готовы нужные джобы.

Выглядит это так:

unit-tests:
  stage: test
  needs: [ "build-job" ]
  script: make test

lint:
  stage: test
  script: make lint

deploy:
  stage: deploy
  needs: [ "unit-tests", "lint" ]
  script: make deploy

DAG превращает ваш CI/CD из очереди в автомагистраль. Если у вас много джобов — самое время пересмотреть пайплайн.

🐸Библиотека devops'a

#арсенал_инженера

📎 Как дебажить distroless-контейнеры в Kubernetes

Distroless-образы стали популярны благодаря минимализму: внутри только ваше приложение и рантайм: Java, Go, Node.js. Никакого bash, curl или apt. Это повышает безопасность, ускоряет скачивание и снижает поверхность атаки.

Но у такого подхода есть обратная сторона — как отлаживать контейнер без шелла и утилит?

В обычном контейнере вы просто делаете kubectl exec -it pod -- bash и изучаете логи, процессы, сетевые соединения. В distroless — так не получится: шелла и инструментов там нет.

Kubernetes позволяет «прикреплять» временные контейнеры к работающему Pod без его рестарта. Вы можете подключить образ с нужными утилитами и дебажить приложение вживую:

kubectl debug pod/<имя-пода> -it --image=busybox --target=<контейнер>

Эфемерный контейнер делит тот же namespace, что и приложение, поэтому вы получаете доступ к файловой системе, процессам и сети. После завершения отладки контейнер исчезает.

🐸Библиотека devops'a

#арсенал_инженера

⚙️ Зачем нужен Control Plane в Kubernetes

Когда говорят о Kubernetes, чаще всего представляют себе кластер из множества узлов, где запускаются контейнеры. Но вся эта система работает не сама по себе — ей нужен мозг, управляющий всеми процессами. Этим мозгом и является Control Plane.

Control Plane — это набор компонентов, которые принимают решения о том, что, где и как должно выполняться в кластере. Если рабочие узлы можно сравнить с мускулами, то Control Plane — это нервная система и голова.

В состав Control Plane входят:

• kube-apiserver — главный вход в кластер. Все команды kubectl и взаимодействия с API проходят через него. Он обеспечивает проверку запросов, аутентификацию и валидацию.

• etcd — распределённое хранилище, где держится всё состояние кластера. По сути, это “база данных” Kubernetes, в которой записано, какие ресурсы есть, какое у них состояние и какие должны быть цели.

• kube-scheduler — отвечает за то, на какой рабочий узел попадут новые поды. Он анализирует доступные ресурсы, ограничения, правила и принимает решение.

• kube-controller-manager — набор контроллеров, которые следят, чтобы желаемое состояние совпадало с фактическим. Например, если вы сказали, что должно быть три пода, а осталось два, контроллер поднимет третий.

• cloud-controller-manager (опционально) — компонент для интеграции с облаками (AWS, Azure, GCP и др.), который умеет управлять балансировщиками, дисками и сетями в зависимости от платформы.

Главная сила Control Plane в том, что он реализует декларативную модель управления. Вы описываете в манифесте YAML, что «хочу три реплики приложения», а Control Plane сам добивается этого состояния: запускает поды, следит за их здоровьем и пересоздаёт при сбоях.

Любое действие с кластером — от деплоя приложения до масштабирования или обновления — в конечном счёте проходит через Control Plane. И если он работает стабильно, то и весь кластер предсказуемо выполняет ваши инструкции.

🐸Библиотека devops'a

#Арсенал_инженера

⚙️ Как получить середину файла в Bash

Команды head и tail отлично показывают начало и конец файла.
Но иногда нужно не первое и не последнее — а что-то из середины: фрагмент лога, центр дампа или середину отчёта.

body специально создан для того, чтобы показать центральные строки файла — с настройками контекста, подсветкой, номерами строк и именами файлов.

Пример:

body -C5 app.log

Скрипт найдёт середину файла

🐸Библиотека devops'a

#арсенал_инженера

🧑‍💻 Используем NGINX как AI-прокси

За последние годы мир AI расширился до множества провайдеров моделей (LLM), каждый со своими API.
Чтобы упростить интеграцию, маршрутизацию и безопасность между приложениями и этими моделями, NGINX предлагает себя как лёгкий AI-прокси: он принимает запросы, трансформирует их (если нужно), маршрутизует, логирует и управляет отказами.

Как это работает:

• Если клиент шлёт запрос в формате OpenAI, но конечная модель — Anthropic, прокси с помощью NJS-скрипта преобразует вход («OpenAI → Anthropic») и выход обратно.

• В конфигурации хранится JSON с правами пользователей: модель A доступна одному, модель B — другому. Прокси проверяет, есть ли у пользователя доступ к запрашиваемой модели.

• Если запрос к основной модели неудачен, например, лимит или сбой API, прокси перенаправит на резервную модель по настройкам.

• После получения ответа прокси извлекает статистику токенов: prompt, completion, total и записывает её в логи NGINX.

Фрагмент конфига:

js_import /etc/njs/aiproxy.js;

server {
    listen 4242;
    default_type application/json;

    location /v1/chat/completions {
        set $aiproxy_user $http_x_user;
        js_content aiproxy.route;
    }

    location /openai {
        internal;
        rewrite ^ /v1/chat/completions;
        proxy_set_header Authorization 'Bearer ${OPENAI_API_KEY}';
        proxy_pass https://api.openai.com;
    }
    location /anthropic {
        internal;
        rewrite ^ /v1/messages;
        proxy_set_header x-api-key ${ANTHROPIC_API_KEY};
        proxy_pass https://api.anthropic.com;
    }
}

Прокси может подгружать права доступа из файла rbac.json, использовать настройки failover и преобразовывать запросы и ответы.

➡️ Блог NGINX

🐸Библиотека devops'a

#арсенал_инженера

🐳 Что такое Dockerfile

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

Всё строится из простых инструкций:

FROM golang:1.22-alpine   # базовый образ
WORKDIR /app              # рабочая директория
COPY . .                  # копируем файлы
RUN go build -o main .    # собираем проект
CMD ["./main"]            # команда запуска

• FROM — задаёт базовый слой (например, ubuntu, node, golang)
• WORKDIR — где выполняются команды
• COPY / ADD — добавляют файлы внутрь контейнера
• RUN — выполняет команды во время сборки
• CMD / ENTRYPOINT — определяют, что запустится при старте контейнера
• EXPOSE — сообщает, какие порты слушает контейнер
• ENV — задаёт переменные окружения

1. Docker читает Dockerfile построчно.
2. Каждая команда создаёт слой в образе.
3. Эти слои кэшируются — поэтому повторная сборка идёт быстрее.
4. Готовый образ можно запускать как контейнер, передавая параметры и окружение.

Что такое слой

Каждый слой — это snapshot изменений файловой системы.

На нашем примере:

1️⃣ FROM golang:1.22-alpine

Docker берёт готовый базовый образ с Golang и Alpine Linux.
Это уже несколько слоёв, собранных кем-то раньше:

• минимальная система (Alpine)
• системные библиотеки
• установленный Go-компилятор

Эти слои загружаются из Docker Hub и кэшируются локально.
Все они read-only — вы их не меняете, просто используете как основу.

2️⃣ WORKDIR /app

Создаётся новый слой, где внутри файловой системы появляется папка /app.
Теперь все последующие команды будут выполняться именно в ней.

Даже если она пуста, Docker фиксирует это изменение файловой структуры как отдельный слой.

3️⃣ COPY . .

Docker копирует все файлы из текущей директории (build context) в /app контейнера.
Результат — ещё один слой, где лежат исходники вашего проекта.

Важно: если вы измените хоть один файл —
хэш слоя поменяется, и этот шаг, а также все следующие пересоберутся заново.

4️⃣ RUN go build -o main .

Docker запускает внутри контейнера команду go build.
Она создаёт бинарник main прямо в /app.

После завершения — создаётся новый слой,
в котором лежит тот самый скомпилированный файл.
Предыдущие слои (с исходниками, библиотеками и т.д.) остаются неизменными.

5️⃣ CMD ["./main"]

Это не создаёт новый слой.
CMD добавляет метаданные — какую команду Docker должен запустить,
когда контейнер стартует docker run image_name.

Dockerfile — это сердце контейнеризации. Без него не было бы reproducible-сборок, dev/test окружений и того самого works on my machine.

🐸 Библиотека devops'a

#арсенал_инженера

🖥 JSON Crack — визуализируйте данные

JSON Crack — это сервис сразу превращает данные в наглядное дерево: можно раскрывать узлы, искать нужные поля и экспортировать схему как изображение. Всё работает прямо в браузере — без отправки данных на сервер.

Кроме JSON поддерживаются YAML, XML, CSV и TOML. Есть валидатор, конвертер и генератор типов для TypeScript и Go. Отличный инструмент, если нужно быстро разобраться в структуре API или объяснить коллегам, как устроен ответ сервера.

➡️ Визуализировать свой JSON

🐸 Библиотека devops'a

#арсенал_инженера

🔥 Держим приложение всегда готовым к запросам

Холодный старт — это когда платформа создаёт новый контейнер для вашей функции с нуля. Надо загрузить код, поднять рантайм, инициализировать библиотеки, открыть соединения. Всё это может занять от 500 мс до нескольких секунд.

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

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

Настройка в Kubernetes

Базовый Deployment с фиксированным числом реплик:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
spec:
  replicas: 3  # всегда 3 пода
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
      - name: api
        image: registry.example.com/api:latest

С автомасштабированием, но с минимумом подов:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-service
  minReplicas: 3      # минимум всегда тёплых
  maxReplicas: 20     # максимум при нагрузке

K8s держит указанное количество подов всегда запущенными. Если приходит больше запросов — HPA создаёт дополнительные поды. Но первые запросы всегда попадут в прогретые.

Сколько реплик держать

• 2-3 реплики — если у вас стабильный трафик
• 5-10 реплик — для критичных API с непредсказуемыми всплесками
• По реплике на availability zone — если распределяете нагрузку по зонам

Не держите 50 реплик на всякий случай. Смотрите в метрики:

kubectl top pods -l app=api

Тёплый пул — это способ сделать так, чтобы пользователи не замечали холодные старты.

🐸 Библиотека devops'a

#арсенал_инженера

👀 Смотреть на весь файл сразу

Tino — простая CLI-тулза, которая показывает весь текстовый файл целиком в одном окне терминала, разбивая его на колонки.

Чтобы её использовать нужно лишь написать в терминале:

tino имя_вашего_файла

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

➡️ Попробовать Tino

🐸 Библиотека devops'a

#арсенал_инженера

🖥 Как задеплоить Elasticsearch

Elasticsearch — движок для поиска и аналитики в реальном времени. Разбираемся, как быстро развернуть его для логов, метрик и мониторинга.

Быстрый старт с Docker Compose

Самый простой способ поднять Elasticsearch локально или в dev-окружении — Docker Compose:

version: '3.8'

services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:8.11.0
    container_name: elasticsearch
    environment:
      - discovery.type=single-node
      - xpack.security.enabled=false
      - "ES_JAVA_OPTS=-Xms2g -Xmx2g"
    ports:
      - "9200:9200"
      - "9300:9300"
    volumes:
      - esdata:/usr/share/elasticsearch/data
    ulimits:
      memlock:
        soft: -1
        hard: -1

  kibana:
    image: docker.elastic.co/kibana/kibana:8.11.0
    container_name: kibana
    environment:
      - ELASTICSEARCH_HOSTS=http://elasticsearch:9200
    ports:
      - "5601:5601"
    depends_on:
      - elasticsearch

volumes:
  esdata:
    driver: local

Production-ready deployment

Для прода нужны дополнительные настройки, как минимум мультинодовый кластер:

services:
  es01:
    image: docker.elastic.co/elasticsearch/elasticsearch:8.11.0
    environment:
      - node.name=es01
      - cluster.name=prod-cluster
      - discovery.seed_hosts=es02,es03
      - cluster.initial_master_nodes=es01,es02,es03
      - xpack.security.enabled=true
      - "ES_JAVA_OPTS=-Xms4g -Xmx4g"
    volumes:
      - esdata01:/usr/share/elasticsearch/data

  es02:
    image: docker.elastic.co/elasticsearch/elasticsearch:8.11.0
    environment:
      - node.name=es02
      - cluster.name=prod-cluster
      - discovery.seed_hosts=es01,es03
      - cluster.initial_master_nodes=es01,es02,es03
      - xpack.security.enabled=true
    volumes:
      - esdata02:/usr/share/elasticsearch/data

  es03:
    image: docker.elastic.co/elasticsearch/elasticsearch:8.11.0
    environment:
      - node.name=es03
      - cluster.name=prod-cluster
      - discovery.seed_hosts=es01,es02
      - cluster.initial_master_nodes=es01,es02,es03
      - xpack.security.enabled=true
    volumes:
      - esdata03:/usr/share/elasticsearch/data

Частые проблемы и решения

Out of memory:

• Проверьте настройки heap: не более 50% RAM
• Используйте ulimit -l unlimited для memlock

Медленные запросы:

• Оптимизируйте маппинги индексов
• Используйте index lifecycle management
• Настройте правильное количество шардов

Проблемы с дисковым пространством:

• Включите ILM для автоматической ротации индексов
• Настройте retention policy для старых данных
• Используйте _forcemerge для оптимизации

🐸 Библиотека devops'a

#арсенал_инженера

👨‍💻 AI-агенты меняют подход к анализу логов в DevOps

Приложение упало в продакшене. Вы открываете Kibana, ищете ошибки вручную, переключаетесь между сервисами. Уходит 30-40 минут, иногда больше.

Скрипты находят только то, что вы в них прописали. Elasticsearch и Splunk не умеют автоматически связывать события из разных сервисов. AI-агент анализирует логи сам, находит корреляции и объясняет: «Утечка памяти в payment-сервисе привела к каскадным падениям. Такое уже было 15 сентября».

Внутри — разбор шести компонентов AI-агента: роль, задачи, инструменты для запросов, память для паттернов, ограничители безопасности. Плюс пример, как агент находит проблему с индексом в базе за несколько минут вместо получаса.

➡️ Прочитать статью

🐸 Библиотека devops'a

#арсенал_инженера

0️⃣ Калькулятор для сравнения облака и собственной инфраструктуры

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

InfraWise — открытый инструмент, который считает полную стоимость владения (TCO) для облачной и on-premise инфраструктуры.

Он учитывает больше 80 параметров: от стоимости электроэнергии и GPU до затрат на compliance: SOC 2, HIPAA, GDPR и человеческие ресурсы.

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

➡️ Посчитать затраты

С нашим курсом по Python не нужно считать затраты, потому что он со скидкой в 40% до конца октября!

🐸 Библиотека devops'a

#арсенал_инженера

🆚 /etc/hosts или /etc/resolv.conf

Оба отвечают за преобразование имён в IP-адреса, но работают по-разному.

/etc/hosts — локальная таблица

Это обычный текстовый файл со списком соответствий IP → имя хоста. Система проверяет его первой, ещё до обращения к DNS-серверам.

Формат:

127.0.0.1       localhost
192.168.1.10    myserver.local myserver
10.0.0.5        database.prod

Когда использовать:
- Нужно быстро переопределить адрес, например, направить домен на локальный сервер для тестирования
- Заблокировать нежелательный сайт через 127.0.0.1 ads.example.com
- В небольших сетях без DNS-сервера

Изменения применяются мгновенно, без перезапуска сервисов.

/etc/resolv.conf — настройки DNS

Этот файл указывает системе, к каким DNS-серверам обращаться для разрешения имён, которых нет в /etc/hosts.

Формат:

nameserver 8.8.8.8
nameserver 1.1.1.1
search company.local

Параметры:

nameserver — адрес DNS-сервера (можно указать несколько)
search — домен для автоподстановки, например, запрос server превратится в server.company.local
options — дополнительные настройки вроде таймаутов

Важно: многие современные системы генерируют этот файл автоматически через NetworkManager или systemd-resolved. Ручные правки могут быть перезаписаны.

🐸 Библиотека devops'a

#арсенал_инженера

🧹 Kubernetes housekeeping

Kubernetes по умолчанию не удаляет завершённые поды автоматически. И это имеет смысл — логи можно посмотреть, причину падения изучить, отладить проблему.

Но когда таких подов сотни или тысячи, кластер превращается в свалку:

$ kubectl get pods -A | grep -E 'Completed|Error|Evicted' | wc -l
847

Как почистить кластер

Удалить все Completed поды:

kubectl get pods -A --field-selector=status.phase==Succeeded \
  -o json | jq -r '.items[] | "\(.metadata.namespace) \(.metadata.name)"' \
  | xargs -n2 bash -c 'kubectl delete pod -n $0 $1'

Или проще, если у вас kubectl 1.24+:

kubectl delete pods --all-namespaces \
  --field-selector=status.phase==Succeeded

Удалить все Failed поды:

kubectl delete pods --all-namespaces \
  --field-selector=status.phase==Failed

Удалить Evicted поды
Тут хитрее, потому что Evicted — это не phase, а reason:

kubectl get pods -A -o json | \
  jq -r '.items[] | select(.status.reason=="Evicted") | "\(.metadata.namespace) \(.metadata.name)"' | \
  xargs -n2 bash -c 'kubectl delete pod -n $0 $1'

Удалить всё разом:

kubectl get pods -A -o json | \
  jq -r '.items[] | 
    select(.status.phase=="Succeeded" or .status.phase=="Failed" or .status.reason=="Evicted") | 
    "\(.metadata.namespace) \(.metadata.name)"' | \
  xargs -n2 bash -c 'kubectl delete pod -n $0 $1 --ignore-not-found=true'

Чистый кластер — счастливый кластер.

🐸 Библиотека devops'a

#арсенал_инженера

🐋 Отладка Docker-сборок в Visual Studio Code

Теперь вы можете отлаживать Dockerfile прямо в VS Code, как обычный код.

Что умеет новый отладчик

• Ставьте брейкпоинты на любую инструкцию RUN в Dockerfile и останавливайте сборку именно в этом месте.

• Смотрите все переменные окружения, аргументы сборки, рабочую директорию и другие параметры прямо в панели Variables.

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

• Когда сборка приостановлена на брейкпоинте, введите команду exec в Debug Console — и вы получите живой shell внутри образа, который сейчас собирается.

➡️ Попробовать фишки

🐸 Библиотека devops'a

#арсенал_инженера

📎 Запустил и забыл

screen — это программа, которая не даёт вашим командам на сервере прерваться, если интернет пропал или вы закрыли терминал.

Как пользоваться

Создать новую сессию:

screen -S my-task

Теперь вы внутри screen. Запускайте команды как обычно.

Выйти из сессии (она продолжит работать):
Нажмите Ctrl+A, отпустите, потом нажмите D

Посмотреть все запущенные сессии:

screen -ls

Вернуться в сессию:

screen -r my-task

Открыть ещё одну вкладку внутри screen:
Ctrl+A, потом C

Переключаться между вкладками:

Ctrl+A, потом N — следующая вкладка
Ctrl+A, потом P — предыдущая вкладка
Ctrl+A, потом цифра (0, 1, 2...) — конкретная вкладка

Убить конкретную сессию:

screen -X -S 12345 quit

Лайфхак: всегда давайте сессиям понятные имена (-S backup, -S deploy), а не оставляйте автоматические номера — так проще найти нужную.

🐸 Библиотека devops'a

#арсенал_инженера