🤔 Сервис типа кластер P со значением nan, что это значит?

Если в системе мониторинга или логах кластерный сервис (Cluster P) показывает значение NaN (Not a Number), это означает, что данные недоступны или не определены.

🚩Возможные причины NaN в кластере

🟠Нет данных от сервиса (сбой мониторинга)
Метрика не обновляется из-за сбоя Prometheus, Zabbix или Grafana.
Датчики или агенты не отправляют данные.
Посмотреть логи агента

  journalctl -u node_exporter --no-pager | tail -20
  

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

  curl -s http://service-ip:port/metrics
  

🟠Ошибка в коде (деление на 0, пустой запрос)
Если метрика рассчитывается (X / Y), но Y = 0, результат будет NaN.
SQL-запрос возвращает пустой результат. Если используется PromQL, попробуйте запросить сырые данные:

  rate(http_requests_total[5m])
  

Проверить SQL-запрос, если данные идут из базы:

  SELECT AVG(value) FROM metrics WHERE time > now() - interval '1 hour';
  

🟠Проблема с кластером (узлы не отвечают)
Один или несколько узлов в кластере недоступны. DNS или балансировщик не может найти сервис.
Посмотреть статус узлов:

  kubectl get nodes
  

Проверить доступность сервиса в кластере:

  kubectl get pods -n monitoring
  

🟠Проблема с сетью (файрвол, маршрутизация)
Запросы блокируются файрволом (iptables, firewalld). Метрика приходит с другого узла, но между ними нет связи.
Проверить сетевые правила:

  iptables -L -n | grep DROP
  

Проверить соединение между узлами:

  nc -zv service-ip port
  

Ставь 👍 и забирай 📚 Базу знаний

🤔 Насколько глубоко приходилось работать с отладкой из консоли на Linux?

Глубина работы зависит от задач:
- Мониторинг процессов (top, htop, ps, strace).
- Анализ сетевого трафика (netstat, tcpdump, iftop).
- Отладка ошибок в логах (journalctl, dmesg, grep, awk).
- Диагностика дискового пространства (df, du, lsof).
- Анализ зависания системы (vmstat, iostat, free, sar).

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Что слышали про rancher kubernetes?

Это платформа для управления Kubernetes-кластерами. Она позволяет развертывать, настраивать, мониторить и управлять несколькими кластерами Kubernetes из единой панели управления. Rancher упрощает работу с Kubernetes, предоставляя удобный UI, API и инструменты автоматизации.

🚩Зачем нужен Rancher?

🟠Управление несколькими кластерами
Rancher позволяет управлять кластерами Kubernetes, развернутыми в различных облаках (AWS, GCP, Azure) и на локальной инфраструктуре.
🟠Упрощенная установка и настройка
С помощью Rancher можно быстро развернуть Kubernetes-кластеры с минимальными усилиями.
🟠Безопасность и контроль доступа
Поддерживает аутентификацию через LDAP, Active Directory, GitHub и другие методы.
🟠Мониторинг и логирование
Встроенная поддержка Prometheus, Grafana и Fluentd для мониторинга и логов.
🟠Развертывание приложений
Поддерживает Helm-чарты и стандартные манифесты Kubernetes.

🚩Как работает Rancher?

🟠Rancher Server
центральный компонент, управляющий кластерами и предоставляющий UI/API.
🟠Kubernetes-кластеры
могут быть развернуты с помощью Rancher (RKE, RKE2) или добавлены вручную (например, EKS, AKS, GKE).
🟠Rancher Agents
агенты, установленные в кластерах для обеспечения связи с сервером Rancher.

🚩Пример развертывания Rancher

Для развертывания Rancher можно использовать Docker

docker run -d --name=rancher --restart=unless-stopped \
  -p 80:80 -p 443:443 \
  rancher/rancher:latest

Ставь 👍 и забирай 📚 Базу знаний

🤔 Чем симлинк отличается от хардлинка?

- Симлинк (Symbolic link) – создаёт ссылку на файл или каталог, указывая его путь.
- Хардлинк (Hard link) – создаёт другой файловый дескриптор для того же инода, оба файла равнозначны.
- Разница: если удалить оригинальный файл, симлинк сломается, а хардлинк сохранит данные.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Какая может быть проблема если вы подключаетесь к серверу через ssh а вам приходят тикеты, что другие пользователи не могут подключиться по ssh по одной и той же учётной записи

Если вы можете подключиться к серверу по SSH, но другие пользователи, использующие ту же учетную запись, не могут, возможны следующие причины:

🟠Проблема с ограничением количества подключений
В файле конфигурации SSH (/etc/ssh/sshd_config) могут быть ограничения на число одновременных подключений.
Открываем конфигурацию SSH

sudo nano /etc/ssh/sshd_config

Проверяем параметры

MaxSessions 1
MaxStartups 10:30:60

Решение
Увеличьте MaxSessions, например:

MaxSessions 10

Перезапустите SSH:

sudo systemctl restart sshd

🟠Файл .ssh/authorized_keys имеет неверные права
Если у вас ключевая авторизация, возможно, права на файлы .ssh/authorized_keys нарушены.
На сервере выполните:

ls -l ~/.ssh/authorized_keys

Если права не 600, исправьте

chmod 600 ~/.ssh/authorized_keys

🟠Ограничение по IP (DenyUsers, AllowUsers, TCP Wrappers)
Конфигурация SSH может блокировать подключения для определенных IP или пользователей.
Откройте /etc/ssh/sshd_config и проверьте параметры

DenyUsers user1
AllowUsers admin

Проверьте /etc/hosts.deny и /etc/hosts.allow

cat /etc/hosts.deny
cat /etc/hosts.allow

🟠Закончились доступные PTY (псевдотерминалы)
Если исчерпан лимит доступных PTY, новые сессии не смогут открываться.
Запустите

ls /dev/pts

Если там слишком много открытых сессий, попробуйте очистить:

pkill -u user

или увеличьте лимит в /etc/security/limits.conf

* hard nproc 1024
* soft nproc 1024

Ставь 👍 и забирай 📚 Базу знаний

🤔 Места нет, находим большой файл (5 Гб), удаляем его, но места всё равно нет. В чём причина?

Файл может быть открыт процессом, и пока он используется, его место на диске не освобождается.
Решение:
1. Проверить открытые файлы: lsof | grep deleted.
2. Найти процессы, держащие файл: fuser -v /путь/к/файлу.
3. Перезапустить процесс: systemctl restart <service> или kill -9 <PID>.
4. Альтернатива – очистить файл без удаления: > /путь/к/файлу.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Как осуществить версионирование кода инфраструктуры?

Версионирование инфраструктурного кода (Infrastructure as Code, IaC) позволяет отслеживать изменения, управлять конфигурациями и обеспечивать повторяемость развертываний. Основные инструменты: Git, Terraform, Ansible, Pulumi и другие.

🚩Версионирование в Terraform
Terraform — один из ключевых инструментов IaC, позволяет управлять инфраструктурой декларативно.
В versions.tf указываем конкретную версию Terraform и провайдеров:

terraform {
  required_version = ">= 1.3.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.0"
    }
  }
}

Хранение состояния в S3 или Terraform Cloud
Чтобы избежать конфликтов при одновременной работе, храните состояние в общем месте:

terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-lock"
  }
}

🟠Версионирование с Ansible
В requirements.yml фиксируем версии ролей:

roles:
  - name: geerlingguy.nginx
    version: "3.1.0"

Применяем роли

ansible-galaxy install -r requirements.yml

🟠Автоматизация версионирования через CI/CD
Подключаем GitHub Actions, GitLab CI, Jenkins или Terraform Cloud.

name: Terraform CI
on:
  push:
    branches:
      - main
jobs:
  terraform:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v1
        with:
          terraform_version: 1.3.0

      - name: Terraform Init
        run: terraform init

      - name: Terraform Plan
        run: terraform plan

Ставь 👍 и забирай 📚 Базу знаний

🤔 На одном сервере top показывает LA=20, на другом LA=2. Где ситуация лучше?

LA (Load Average) – среднее число процессов в очереди на выполнение.
- LA=20 – значит, что 20 процессов ждут CPU, что указывает на перегрузку.
- LA=2 – более нормальная нагрузка.
- Оптимальный LA ≈ числу ядер CPU (nproc). Если LA существенно выше количества ядер, сервер перегружен.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 В каких случаях используется multi stage?

Multi-stage (многоэтапная сборка) — это метод создания Docker-образов, позволяющий уменьшить их размер и повысить безопасность.

🚩Когда используется?

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

🚩Пример использования Multi-stage в Docker

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

# Этап 1: сборка
FROM golang:1.20 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp

# Этап 2: минимальный образ для запуска
FROM alpine:latest
WORKDIR /root/
COPY --from=builder /app/myapp .
CMD ["./myapp"]

🚩Использование в React / Angular / Vue

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

# Этап 1: сборка приложения
FROM node:18 AS builder
WORKDIR /app
COPY package.json ./
RUN npm install
COPY . .
RUN npm run build

# Этап 2: деплой на nginx
FROM nginx:alpine
COPY --from=builder /app/dist /usr/share/nginx/html
CMD ["nginx", "-g", "daemon off;"]

Ставь 👍 и забирай 📚 Базу знаний

🤔 Что такое TTL?

Это ограничение времени жизни данных:
- В кэше – указывает, сколько времени кэшированные данные остаются актуальными.
- В DNS – время перед обновлением записи.
- В пакетах сети – ограничивает время существования пакета, после чего он удаляется (ping -t).
- В базах данных – регулирует автоматическое удаление данных (например, в Redis).

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Как поставить отличную версию питона от системного на астре?

В Astra Linux (как и в Debian/Ubuntu) системный Python используется для работы ОС, и его обновление может привести к проблемам. Поэтому лучше устанавливать другую версию Python отдельно**, не заменяя системную.

🟠Установка Python через deadsnakes PPA (для Astra на основе Debian 9/10)
Если Astra Linux основана на Debian 9/10 (например, Astra Smolensk или Orlov), можно использовать PPA

sudo apt update
sudo apt install -y software-properties-common
sudo add-apt-repository ppa:deadsnakes/ppa -y
sudo apt update
sudo apt install -y python3.10  # Устанавливаем нужную версию

После установки можно проверить

python3.10 --version

🟠Компиляция Python из исходников (универсальный способ)
Если нужная версия недоступна в репозитории, компилируем Python вручную.
Устанавливаем зависимости

sudo apt update
sudo apt install -y build-essential libssl-dev \
    libreadline-dev libsqlite3-dev \
    zlib1g-dev libbz2-dev libffi-dev

Скачиваем исходники Python

cd /usr/src
sudo wget https://www.python.org/ftp/python/3.11.6/Python-3.11.6.tgz
sudo tar xvf Python-3.11.6.tgz

Компилируем Python

cd Python-3.11.6
sudo ./configure --enable-optimizations
sudo make -j$(nproc)
sudo make altinstall  # НЕ make install, чтобы не затереть системный Python

Проверяем

python3.11 --version

🟠Использование pyenv (изолированные версии Python)
Если нужно переключаться между разными версиями Python, лучше использовать pyenv.

curl https://pyenv.run | bash

Добавляем в ~/.bashrc или ~/.profile

export PATH="$HOME/.pyenv/bin:$PATH"
eval "$(pyenv init --path)"
eval "$(pyenv virtualenv-init -)"

Активируем изменения

source ~/.bashrc

Устанавливаем новую версию Python

pyenv install 3.10.12
pyenv global 3.10.12  # Делаем версию по умолчанию

Проверяем:

python --version

Ставь 👍 и забирай 📚 Базу знаний

🤔 В чем основные пойнты Git Flow?

Это стратегия управления ветками в Git, предназначенная для удобной командной разработки. Основные ветки:
- master – стабильная версия кода, которая всегда готова к релизу.
- develop – основная ветка для разработки, в которую вливаются новые фичи.
- feature/* – ветки для отдельных функций, которые создаются от develop и сливаются обратно после завершения.
- release/* – ветки для подготовки к релизу, после чего код попадает в master.
- hotfix/* – срочные исправления для master, минуя develop.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 В каких случаях удобно использовать kubernetes, а в каких docker-compose?

Оба инструмента управляют контейнерами, но предназначены для разных сценариев.

🚩Когда использовать Docker Compose?

Docker Compose удобен для локальной разработки и небольших проектов.
Разворачиваете приложение на одном сервере.
Нужно быстро поднять несколько сервисов (БД, кэш, бекенд, фронт).
Разработка ведется в команде, и среда должна быть одинаковой.
Нет необходимости в сложном оркестрационном механизме (авто-масштабирование, балансировка нагрузки).
Файл docker-compose.yml для запуска бэкенда и базы данных локально:

version: '3'
services:
  app:
    image: my-backend:latest
    ports:
      - "5000:5000"
    depends_on:
      - db
  db:
    image: postgres:15
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password

Команда запуска:

docker-compose up -d

🚩Когда использовать Kubernetes?

Kubernetes удобен для продакшн-окружений, облаков и сложных приложений.
Нужно масштабирование (автоматическое увеличение/уменьшение количества контейнеров).
Требуется автоисправление (если контейнер падает, он перезапускается).
Используется балансировка нагрузки (Kubernetes распределяет трафик между подами).
Нужна развертка в кластере (несколько машин, облако).
Требуется обновление без простоя (rolling updates).

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-backend:latest
        ports:
        - containerPort: 5000

Разворачиваем в Kubernetes:

kubectl apply -f my-app.yaml

Ставь 👍 и забирай 📚 Базу знаний

🤔 Что такое ACL в Linux?

Это механизм расширенного управления правами доступа к файлам и директориям. В отличие от стандартных POSIX-разрешений (rwx), ACL позволяет задавать индивидуальные права для каждого пользователя или группы. Используется для более гибкого контроля доступа.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Как определить опции запуска пайплайна при редактировании определенных ресурсов в гите?

При работе с CI/CD (GitHub Actions, GitLab CI, Jenkins) часто нужно запускать пайплайн только при изменении определенных файлов. Это помогает оптимизировать сборку, экономить ресурсы и время.

🚩В GitHub Actions (on: push, paths)

В GitHub Actions можно указать файлы, изменения в которых запустят пайплайн.

name: Infra Pipeline
on:
  push:
    paths:
      - 'infra/**'
      - 'k8s/**'
  pull_request:
    paths:
      - 'infra/**'
      - 'k8s/**'
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      - name: Deploy Infrastructure
        run: ./deploy.sh

🚩В GitLab CI/CD (only: changes)

В GitLab можно настроить запуск пайплайна по изменению файлов с помощью only: changes.

stages:
  - deploy

terraform:
  stage: deploy
  script:
    - terraform apply -auto-approve
  only:
    changes:
      - terraform/**

🚩В Jenkins (when { changes })

В Jenkins Declarative Pipeline можно использовать when { changes } для проверки измененных файлов.

pipeline {
    agent any
    stages {
        stage('Deploy Ansible') {
            when { changes path: 'ansible/**' }
            steps {
                sh './deploy_ansible.sh'
            }
        }
        stage('Deploy Helm') {
            when { changes path: 'helm/**' }
            steps {
                sh './deploy_helm.sh'
            }
        }
    }
}

Ставь 👍 и забирай 📚 Базу знаний

🤔 Что такое VPC?

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

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Где бы хранил tfstate если много разрабов?

Файл terraform.tfstate содержит текущее состояние инфраструктуры. Если его неправильно хранить, возможны конфликты и повреждение данных.

🚩Плохие решения

Локально (terraform.tfstate в репозитории)
Потеря данных, если разработчик сменит машину.
Конфликты, если несколько человек применяют terraform apply.
Невозможно откатиться к старому состоянию.
Не поддерживает блокировки (terraform lock).
Возможны проблемы с одновременным доступом.

🚩Лучшие решения для хранения `tfstate`

🟠S3 + DynamoDB (AWS) → Самый популярный способ
S3 хранит tfstate, а DynamoDB предотвращает конфликты.

terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-lock"
  }
}

🟠Terraform Cloud/Enterprise → Официальное SaaS-решение
Terraform Cloud хранит tfstate в облаке HashiCorp.

terraform {
  backend "remote" {
    hostname     = "app.terraform.io"
    organization = "my-org"
    workspaces {
      name = "my-workspace"
    }
  }
}

🟠Google Cloud Storage (GCS) + Firestore (GCP)
Для GCP аналог AWS S3 — это Google Cloud Storage (GCS), а DynamoDB заменяется Firestore.

terraform {
  backend "gcs" {
    bucket  = "my-tfstate-bucket"
    prefix  = "terraform/state"
  }
}

🟠Azure Storage + Azure CosmosDB (Azure)
Для Azure можно использовать Azure Storage и блокировки через Azure CosmosDB.

terraform {
  backend "azurerm" {
    resource_group_name  = "my-rg"
    storage_account_name = "myterraformstate"
    container_name       = "tfstate"
    key                  = "prod.terraform.tfstate"
  }
}

Ставь 👍 и забирай 📚 Базу знаний

🤔 Как осуществляется процесс тестирования кода в pipeline? Делегируете или делаете сами?

Процесс тестирования в CI/CD pipeline может включать:
- Юнит-тесты – проверка отдельных модулей кода.
- Интеграционные тесты – проверка взаимодействия компонентов.
- Линтеры и статический анализ – контроль качества кода.
- Нагрузочные тесты – проверка работы под нагрузкой.
Обычно разработчики пишут тесты, QA проверяют интеграцию, а DevOps настраивают автоматическое тестирование.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Какие процессы убивает long killer?

Это системный механизм в Astra Linux (и некоторых других дистрибутивах на базе Debian), который убивает "долгоиграющие" процессы, потребляющие слишком много ресурсов. Он предотвращает зависания системы и защищает от неэффективного использования вычислительных мощностей.

🚩Какие процессы убивает Long Killer?

Long Killer анализирует процессы и завершает те, которые:
Запущены от обычного пользователя (не root).
Работают слишком долго (по умолчанию >10 минут).
Потребляют много CPU (по умолчанию >90% CPU).
Используют много памяти (если система близка к OOM – Out of Memory).
Не имеют активности (зависли, например, ожидание ввода).

Он не убивает root-процессы.
Системные службы (например, sshd, systemd) остаются нетронутыми.
Если процесс выполняется интерактивно (например, работа в vim или nano), он обычно не трогает его.

🚩Как проверить, что процесс убит Long Killer?

Если подозреваете, что ваш процесс завершился из-за Long Killer, посмотрите логи

journalctl -u long-killer.service --no-pager | tail -n 20

Также можно проверить dmesg

dmesg | grep "killed by Long Killer"

🚩Как отключить или настроить Long Killer?

Файл конфигурации находится здесь

/etc/long-killer.conf

Пример настроек

MAX_CPU_USAGE=90     # Максимальная загрузка CPU (%)
MAX_EXEC_TIME=600    # Максимальное время выполнения (секунды)
EXCLUDE_USERS=root   # Не убивать процессы от root

После изменения перезапустите сервис

systemctl restart long-killer.service

Чтобы полностью отключить Long Killer

systemctl stop long-killer.service
systemctl disable long-killer.service

🚩Как избежать убийства процессов?

Запуск от root (если это безопасно):

sudo my_long_process

Снижение приоритета процесса (nice/renice)

nice -n 10 my_process
renice -n 10 -p <PID>

Использование nohup или screen для фоновых задач

nohup my_script.sh &

Ставь 👍 и забирай 📚 Базу знаний

🤔 Что известно про процесс, каким образом фича доходит до релиза?

1. Разработчик создает feature-ветку от develop, реализует функциональность.
2. Код проходит код-ревью и тестирование (CI/CD pipeline).
3. После успешного тестирования фича вливается в develop.
4. Когда накоплено достаточно изменений, создается release-ветка.
5. Финальное тестирование, исправление багов, деплой на staging.
6. Если все в порядке, release вливается в master, и обновление выкатывается в продакшен.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний