🤔 Что касается безопасности где хранить переменные секреты?

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

🟠Использование специализированных хранилищ секретов
HashiCorp Vault:
Это инструмент для управления секретами и защиты данных. Он позволяет централизованно хранить, доступ к которым строго контролируется, и динамически создавать секреты.
Преимущества: Поддержка динамических секретов, интеграция с большинством сред и технологий, высокий уровень безопасности.
AWS Secrets Manager и Azure Key Vault:
Эти облачные сервисы предоставляют управляемые решения для безопасного хранения и управления доступом к секретным данным, включая автоматическое обновление секретов.
Преимущества: Интеграция с облачными сервисами, упрощение ротации секретов, мониторинг и логирование доступа.

🟠Инкапсуляция секретов в среде выполнения
Docker Secrets и Kubernetes Secrets:
Предлагают встроенные механизмы для безопасного хранения секретов, которые используются контейнерами во время выполнения.
Преимущества: Локальная интеграция с системами оркестрации контейнеров, базовое шифрование на диске и управление доступом.

🟠Секреты в контролируемом CI/CD
Платформы CI/CD, такие как GitLab и GitHub, предоставляют возможности для безопасного хранения переменных среды и секретов, которые могут быть использованы в процессах автоматизации без разглашения.
Преимущества: Простота использования, интеграция с процессами разработки, защита от внешнего доступа.

🟠Шифрование секретов
Инструменты шифрования: Использование инструментов, таких как GnuPG (GPG), для шифрования секретов перед их сохранением в системах контроля версий или конфигурационных файлах.
Преимущества: Высокий уровень безопасности, контроль доступа к секретам на уровне пользователя.

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

🤔 Если удалить terraform.tfstate, а потом сделать terraform init — что будет?

- terraform init не восстановит state.
- Terraform не будет знать, что уже развернуто, и при следующем apply может создать ресурсы заново.
- Лучше использовать terraform state pull/push или хранить state в remote backend (S3, GitLab, etc).

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

🤔 Зачем нужен стейт в Terraform?

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

🟠Отслеживание ресурсов
Terraform использует tfstate, чтобы сопоставлять код с реальными ресурсами.
В коде создаем виртуальную машину

hcl  
   resource "aws_instance" "example" {  
     ami           = "ami-123456"  
     instance_type = "t2.micro"  
   }  

Запускаем terraform apply, создается сервер в AWS
В terraform.tfstate записывается информация об этом ресурсе
При следующем terraform apply Terraform сверяет tfstate с реальными ресурсами и вносит только изменения

🟠Управление зависимостями
Когда ресурсы связаны (например, сервер и security group), Terraform понимает связи через tfstate и удаляет ресурсы в правильном порядке

🟠Работа в команде (`remote state`)
Когда несколько разработчиков работают с Terraform, tfstate должен храниться в общем месте, например
- S3 + DynamoDB (AWS)
- Terraform Cloud
- GCS + Firestore (GCP)
- Azure Storage + CosmosDB (Azure)

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

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

🤔 Какой будет ID в Podman?

Podman использует тот же механизм контейнеризации, что и Docker, но без демона. Если запустить контейнер в Podman, он получит свой уникальный контейнерный ID, аналогично Docker. Это будет хеш, состоящий из символов, идентифицирующих контейнер.

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

🤔 Что сделать если зависает ssh?

Если SSH завис, не стоит сразу закрывать терминал. Есть несколько причин и решений.

🚩Проверить, можно ли выйти без разрыва сессии
Если SSH завис, но сессия не разорвана, попробуйте выйти без закрытия терминала:

~.

Переключение в режим управления SSH

~Ctrl+Z

🚩Проверить соединение с сервером

Если SSH завис, причина может быть в разрыве соединения. Проверьте:

Работает ли пинг до сервера:

ping server_ip

🔹 Открыт ли SSH-порт (22):

nc -zv server_ip 22

🚩Перезапустить SSH-клиент

Если только один SSH-клиент завис, попробуйте:

pkill -9 ssh

или

killall -9 ssh

Затем переподключитесь

ssh user@server_ip

🚩Проверить SSH-сервер

Если сервер доступен, но SSH зависает, войдите через консоль или другой метод (например, VNC, IPMI).

Если SSH не отвечает, перезапустите его:

sudo systemctl restart ssh

или

service ssh restart

🚩Отключить TCP KeepAlive или изменить таймауты

Иногда SSH зависает из-за разрыва соединения на роутере или файрволе.

Добавьте в ~/.ssh/config на клиенте

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 5

Или в /etc/ssh/sshd_config на сервере

ClientAliveInterval 60
ClientAliveCountMax 5

Затем перезапустите SSH

sudo systemctl restart ssh

🚩Убить зависшую SSH-сессию на сервере

Если осталось зависшее подключение, найдите его и завершите:

who  # Показывает активные пользователи
ps aux | grep ssh  # Показывает процессы SSH
pkill -9 -u username  # Завершает все сессии пользователя

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

🤔 В чём причина, если мы запускаем сервисы с ReplicaSet, меняем версию nginx, и поды не перезапущены?

Причина:
- Selector не изменился, а PodTemplate тоже не изменился.
- ReplicaSet не обновляет поды сам при изменении образа.
Нужно использовать Deployment, который пересоздаёт поды при изменении spec.template.

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

🤔 Как и где посмотреть логи какого-нибудь сервиса?

Обычно хранятся в каталоге /var/log. Также многие современные дистрибутивы используют систему журналирования systemd для управления и просмотра логов.

🚩Способы просмотра

🟠Просмотр логов в /var/log
Каталог /var/log содержит логи большинства системных сервисов и приложений.

Логи системных сообщений
/var/log/syslog: Содержит общие системные логи. /var/log/messages: Содержит общие системные сообщения (не во всех дистрибутивах).

cat /var/log/syslog
less /var/log/syslog
tail -f /var/log/syslog

Логи конкретных сервисов
Apache: /var/log/apache2/ или /var/log/httpd/ Логи доступа: /var/log/apache2/access.log или /var/log/httpd/access_log Логи ошибок: /var/log/apache2/error.log или /var/log/httpd/error_log

tail -f /var/log/apache2/access.log
tail -f /var/log/apache2/error.log  

Nginx: /var/log/nginx/ Логи доступа: /var/log/nginx/access.log Логи ошибок: /var/log/nginx/error.log

tail -f /var/log/nginx/access.log
tail -f /var/log/nginx/error.log 

MySQL: /var/log/mysql/ или /var/log/mysqld.log

tail -f /var/log/mysql/error.log 

SSH: /var/log/auth.log или /var/log/secure

tail -f /var/log/auth.log 

🟠Использование `journalctl` для системных логов
journalctl — это утилита для просмотра и управления журналами systemd. Она позволяет фильтровать логи по различным критериям, таким как время, сервис и уровень логирования.

Основные команды journalctl
Просмотр всех журналов

journalctl  

Логов конкретного сервиса

journalctl -u nginx.service  

Последних логов и продолжение просмотра в реальном времени

journalctl -f
journalctl -u nginx.service -f

Логов за определённый период

journalctl --since "2024-07-25 12:00:00" --until "2024-07-25 13:00:00" 

Логов с определённым уровнем логирования

journalctl -p err
journalctl -p warning  

🚩Примеры использования

🟠Просмотр логов Apache
Логи доступа

tail -f /var/log/apache2/access.log  

Логи ошибок

tail -f /var/log/apache2/error.log 

🟠Просмотр логов Nginx
Логи доступа

tail -f /var/log/nginx/access.log

Логи ошибок

tail -f /var/log/nginx/error.log  

🟠Использование `journalctl` для просмотра логов Nginx
Все логи Nginx

journalctl -u nginx.service  

Последние логи Nginx в реальном времени

journalctl -u nginx.service -f

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

🤔 Как описать исполняемый файл как демон?

Чтобы сделать программу демоном (службой):
1. Обеспечить фоновый запуск, отсоединение от терминала.
2. Обеспечить логирование, PID-файл, работу в фоне.
3. Зарегистрировать как systemd unit или использовать init.d.
При этом важно, чтобы демон:
- Не блокировал терминал.
- Обрабатывал сигналы (например, SIGTERM).
- Логировал свою работу.

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

🤔 Как сделать rebase на main branch?

Выполнить rebase на main в Git означает "перенести" ваши изменения поверх актуального состояния основной ветки (main).

🟠Переключаемся на вашу текущую ветку
Допустим, вы работаете в ветке feature-branch:

git checkout feature-branch

🟠Выполняем rebase на `main`
Сначала убедимся, что main обновлена:

git checkout main
git pull origin main

Теперь выполняем сам rebase:

git checkout feature-branch
git rebase main

🟠Разрешение конфликтов (если есть)
Если у вас есть конфликты, Git остановит процесс и попросит их решить.
Откройте файлы с конфликтами, исправьте их.
Добавьте исправленные файлы:

   git add <файл>
   

Продолжите rebase:

   git rebase --continue
   

🟠Обновление удалённого репозитория
Если rebase прошёл успешно, вам нужно форсированно обновить удалённую ветку (так как история изменилась):

git push origin feature-branch --force

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

🤔 Почему при проверке командой, ранее заполненный, но после очищенный раздел, все равно выглядит, как заполненный?

Операционные системы не всегда сразу удаляют данные с диска, а только помечают их как доступные для перезаписи. Причины:
- Журналирование (EXT4, XFS) – данные могут оставаться в журнале.
- TRIM для SSD не выполнен – стирание на SSD происходит не сразу.
- Блоки файловой системы не очищены – команда rm удаляет ссылки, но не сами данные.
- Кеширование и lazy-write – система может отложить освобождение пространства.

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

🤔 На каких принципах работает докер?

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

🚩Основные принципы

🟠Контейнеризация
Контейнеризация позволяет запускать приложения и их зависимости в изолированных окружениях. Контейнеры предоставляют легкие и эффективные среды, которые включают все необходимое для запуска приложений.
Контейнеры: Легковесные, изолированные окружения, которые работают поверх ядра хостовой операционной системы.
Namespace: Механизм ядра Linux, обеспечивающий изоляцию процессов, сети, PID, пользовательских идентификаторов и монтирования файловых систем.
Cgroups: Контрольные группы в Linux, которые ограничивают и отслеживают использование ресурсов контейнерами, включая процессорное время, память и I/O.

🟠Использование образов
Образы Docker являются шаблонами для создания контейнеров. Образ включает в себя все необходимые компоненты, такие как код приложения, библиотеки, зависимости и конфигурационные файлы.
Dockerfile: Скрипт, содержащий инструкции по созданию образа. Используется для автоматизации создания образов.
Слойность: Каждый образ состоит из нескольких слоев, которые кэшируются и могут использоваться повторно, что ускоряет процесс сборки и уменьшает использование ресурсов.

🟠Изоляция и безопасность
Docker обеспечивает изоляцию приложений, что позволяет запускать несколько контейнеров на одном хосте без взаимного влияния.
Изоляция процессов: Каждый контейнер имеет свой собственный процессорный контекст, что исключает конфликты между приложениями.
Изоляция файловой системы: Контейнеры имеют свои собственные файловые системы, изолированные от файловой системы хостовой операционной системы.
Безопасность: Docker использует механизмы, такие как AppArmor, SELinux и seccomp, для обеспечения безопасности контейнеров.

🟠Управление сетями
Docker предоставляет гибкие возможности управления сетями для контейнеров, включая создание изолированных сетей и подключение контейнеров к различным сетям.
Bridge Network: Создает изолированную сеть для контейнеров на одном хосте.
Host Network: Контейнер использует сетевые интерфейсы хостовой операционной системы.
Overlay Network: Позволяет контейнерам на разных хостах взаимодействовать друг с другом.
Macvlan Network: Контейнеры получают собственные MAC-адреса и ведут себя как физические устройства в сети.

🟠Хранение данных
Docker поддерживает различные механизмы хранения данных для обеспечения сохранности и доступности данных контейнеров.
Volumes: Независимые от контейнеров хранилища данных, которые могут быть подключены к одному или нескольким контейнерам.
Bind Mounts: Позволяют монтировать директории хостовой файловой системы в контейнеры.
Tmpfs: Использует память хоста для хранения данных контейнера, что полезно для временных данных.

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

🤔 Как покрываете Ansible тестами?

Для тестирования Ansible используют инструменты, такие как Molecule, который позволяет создавать тестовые сценарии, запускать плейбуки и проверять их результаты. Также используются статические анализаторы, такие как ansible-lint, для проверки кода на соответствие стандартам. Кроме того, можно применять интеграционные тесты с помощью Docker или виртуальных машин.

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

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

Касается подходов к управлению релизами в системах контроля версий, таких как Git, и их интеграции с процессами CI/CD. Ответ зависит от структуры разработки и процесса релиза в конкретной команде или компании. Однако, в общем, деплой из релизных веток обычно идет на тестовые, стейджинговые или продакшн-окружения. Давайте разберем этот процесс подробнее.

🚩Что такое релизные ветки?

Это ветки, которые создаются на этапе, когда функционал и исправления, готовые к выпуску, отделяются от основной ветки разработки (например, main или develop). Они позволяют:
Заморозить текущий набор изменений для подготовки к релизу.
Отделить доработки и исправления релиза от активной разработки.
Упростить процесс тестирования и последующего деплоя.

🚩Куда обычно идет деплой из релизных веток?

🟠Тестовое окружение (QA environment)
На тестовое окружение деплой из релизной ветки осуществляется для прохождения проверок качества: Автоматизированное и ручное тестирование.
Проверка производительности, безопасности и других аспектов.

stages:
  - test
deploy:
  stage: test
  script:
    - echo "Deploying release branch to QA"
    - ./deploy.sh qa
  only:
    - release/*

🟠Стейджинговое окружение (Staging)
После успешного прохождения тестов релизную ветку деплоят в стейджинг. Это окружение максимально похоже на продакшн и используется для финального тестирования: Проверка совместимости с продакшн-системами.
Демонстрация функционала заказчикам или заинтересованным сторонам.

stages:
  - staging
deploy:
  stage: staging
  script:
    - echo "Deploying release branch to Staging"
    - ./deploy.sh staging
  only:
    - release/*

🟠Продакшн (Production)
После прохождения всех этапов тестирования изменения из релизной ветки деплоятся в продакшн: Обычно это делается автоматически после финального подтверждения.
В некоторых командах финальный мерж релизной ветки в main инициирует деплой.

stages:
  - production
deploy:
  stage: production
  script:
    - echo "Deploying release branch to Production"
    - ./deploy.sh production
  only:
    - release/*

🚩Зачем это нужно?

🟠Изоляция релиза
Релизные ветки позволяют избежать включения новых, неподготовленных изменений в текущий релиз.
🟠Гибкость
Если в процессе тестирования или релиза найдены баги, их можно исправить прямо в релизной ветке без влияния на разработку.
🟠Управление рисками
Релизные ветки упрощают управление разными стадиями разработки и релиза.

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

1⃣Разработчик создает ветку release/1.0.0 от develop.
2⃣Выполняются тесты на QA окружении.
3⃣Исправляются баги в release/1.0.0, и изменения деплоятся на стейджинг.
4⃣После успешного тестирования ветка мержится в main, и начинается деплой в продакшн.

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

🤔 Шифруется ли state file?

По умолчанию локальный state file не шифруется, если вы не настроили это явно. Если используется удалённое хранилище (например, S3, Azure Blob), можно настроить:
- Шифрование на уровне хранилища (например, AWS KMS).
- Шифрование ключей в backend конфигурации.
- Использование gpg или sops для ручного шифрования, если нужно.
Для чувствительных данных (например, паролей в переменных) рекомендуется использовать sensitive = true.

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

🤔 Как происходит секьюрити тест какой алгоритм под капотом?

Security-тестирование – это процесс проверки системы на уязвимости, угрозы и риски атак. Оно помогает защитить данные и сервисы от хакеров.

🚩Сканеры уязвимостей (Nessus, OpenVAS)

- Загружают базу известных уязвимостей (CVE).
- Проверяют систему на наличие этих уязвимостей.
- Используют сигнатурный анализ (по шаблонам) и эвристический анализ (поведенческий).

🚩SQL-инъекции (SQLmap, Burp Suite)

- Автоматически подставляют вредоносные SQL-запросы (' OR 1=1 --).
- Проверяют, есть ли доступ к базе данных.
- Выполняют дамп данных, если нашли уязвимость.

SELECT * FROM users WHERE username = 'admin' --' AND password = 'password'

🚩Поиск XSS-уязвимостей (DOM-XSS, Stored-XSS, Reflected-XSS)

- Вставляют вредоносный JavaScript-код в форму ввода.
- Если скрипт исполняется в браузере – уязвимость найдена.

<script>alert('XSS!')</script>

🚩Подбор паролей (Brute Force, Dictionary Attack)

- Пробуют тысячи вариантов паролей (rockyou.txt).
- Используют John the Ripper, Hydra, Hashcat.

hydra -l admin -P passwords.txt 192.168.1.1 ssh

🚩Анализ трафика (MITM, Sniffing, Packet Analysis)

Захватывают пакеты сети (tcpdump, Wireshark).
Ищут передаваемые пароли, сессии, токены.

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

🤔 Что такое селектор?

Селектор (label selector) используется для выбора ресурсов по меткам. Например, Deployment использует селектор, чтобы знать, какие Pods ему управлять.

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

🤔 Какой самый большой минус Ansible?

Ansible – мощный инструмент для автоматизации, но у него есть серьезные недостатки, особенно при масштабировании.

🚩Основной минус – Медленная работа на больших инфраструктурах

🟠Нет агентов
каждый раз Ansible подключается по SSH и выполняет задачи без предварительного кеширования
что замедляет процесс.

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

🟠Последовательное выполнение
по умолчанию Ansible выполняет задачи последовательно, что дольше, чем параллельные методы (например, в SaltStack).

yaml  
- name: Установка Nginx  
  hosts: all  
  tasks:  
    - name: Установить Nginx  
      apt:  
        name: nginx  
        state: present  

Запуск задач параллельно (-f 50)

sh  
ansible-playbook playbook.yml -f 50  

🚩Другие минусы Ansible

🟠Высокая нагрузка на управляющий узел
Если 1000+ серверов, главный Ansible-узел может быстро перегрузиться.

🟠Сложное управление зависимостями
Роли могут конфликтовать, если версии не совпадают. Ansible Galaxy не такой удобный, как Terraform Registry

🟠Ограниченная идемпотентность
Некоторые модули (особенно shell и command) не всегда понимают, применялась ли конфигурация раньше.

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

🤔 Как бы вы настроили уведомления для сервисов которые находятся без интернета полностью локализованы закрыты от всего извне?

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

🚩Локальный почтовый сервер (SMTP)

1⃣Установка

sudo apt update
sudo apt install postfix   

2⃣Настройка
Отредактируйте /etc/postfix/main.cf

myhostname = local.example.com
mydomain = example.com
myorigin = $mydomain
inet_interfaces = all
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
relay_domains = $mydestination   

3⃣Перезапуск Postfix

sudo systemctl restart postfix   

4⃣Проверка

echo "Test email" | mail -s "Test Subject" user@example.com

🚩Локальный мессенджер (Mattermost)

1⃣Установка Mattermost
Следуйте [документации](https://docs.mattermost.com/install/self-managed-install.html).

2⃣Настройка
Создайте каналы и пользователей.

3⃣Интеграция с мониторингом
Используйте веб-хуки Mattermost для уведомлений.

🚩Системы управления инцидентами (Zabbix)

1⃣Установка Zabbix
Следуйте [документации](https://www.zabbix.com/download).

2⃣Настройка
Настройте хосты, триггеры и действия.

3⃣Настройка уведомлений
Медиатипы: Настройте Email и SMS. Пользователи: Создайте пользователей и уведомления.

🚩Локальный стек мониторинга (Prometheus, Alertmanager)

1⃣Установка Prometheus

wget https://github.com/prometheus/prometheus/releases/download/v2.26.0/prometheus-2.26.0.linux-amd64.tar.gz
tar xvf prometheus-2.26.0.linux-amd64.tar.gz
cd prometheus-2.26.0.linux-amd64
./prometheus --config.file=prometheus.yml   

2⃣Установка Alertmanager

wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz
tar xvf alertmanager-0.21.0.linux-amd64.tar.gz
cd alertmanager-0.21.0.linux-amd64
./alertmanager --config.file=alertmanager.yml   

3⃣Настройка алертинга в Prometheus

groups:
  - name: example-alerts
    rules:
      - alert: HighCPUUsage
        expr: avg_over_time(node_cpu_seconds_total{mode="idle"}[5m]) < 20
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "High CPU usage detected"
          description: "CPU usage is above 80% for more than 2 minutes"   

4⃣Настройка Alertmanager

global:
  smtp_smarthost: 'localhost:25'
  smtp_from: 'alertmanager@local.example.com'
route:
  receiver: 'email-notifications'
receivers:
  - name: 'email-notifications'
    email_configs:
      - to: 'admin@local.example.com'
        send_resolved: true

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

🤔 SIGKILL можно не обработать, а проигнорировать?

Нет.
SIGKILL (kill -9) — это немаскируемый сигнал.
ОС немедленно завершает процесс без возможности перехвата.
Единственный способ обработать завершение — использовать другие сигналы, например SIGTERM (kill -15), который можно перехватить и обработать.

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

🤔 Как linux выбирает, какой из процессов завершить?

Она использует механизм, известный как OOM Killer (убийца процессов при нехватке памяти), для завершения процессов с целью освобождения памяти. Выбор процесса для завершения базируется на ряде критериев, чтобы минимизировать влияние на работу системы.

🚩Как работает OOM Killer?

🟠Очки OOM (OOM Score)
Каждому процессу присваиваются очки OOM, которые рассчитываются на основе нескольких факторов, таких как: Объем памяти, используемой процессом. Приоритет процесса. Важность процесса для системы (например, системные демоны имеют более низкие очки).

🟠Формула расчета OOM Score
Основной фактор при расчете очков - это объем потребляемой процессом памяти. Чем больше памяти потребляет процесс, тем выше его OOM Score. Операционная система также учитывает приоритет процесса (nice value) и некоторые другие параметры.

🟠Принудительное завершение
Процесс с наибольшим OOM Score считается наименее критичным для системы и завершается первым.

🚩Пример расчета OOM Score

🟠Вот пример того, как может быть рассчитан OOM Score (упрощенный)
Процесс A использует 1 ГБ памяти.
Процесс B использует 2 ГБ памяти.
Процесс C использует 500 МБ памяти, но это критический системный процесс.
🟠OOM Score для этих процессов может выглядеть так
Процесс A: 300
Процесс B: 600
Процесс C: 100 (низкий, так как процесс критический)

🚩Настройка OOM Killer

Администраторы могут влиять на работу OOM Killer, настраивая параметры OOM Score для конкретных процессов с помощью файлов в каталоге /proc. Например, для изменения приоритета процесса:

echo -1000 > /proc/<PID>/oom_score_adj

🚩Логирование и мониторинг

При срабатывании OOM Killer соответствующие сообщения записываются в системный журнал (обычно /var/log/syslog или /var/log/messages), что позволяет администраторам анализировать причины и предпринимать меры по предотвращению в будущем.

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

🔥 Скрытые вакансии с удаленной работой для DevOps, которые нигде больше не публикуются. Напрямую от компаний, с контактами рекрутеров.

🔹 DevOps Jobs | Вакансии

🔸 Все каналы с вакансиями