KVM + QEMU — виртуализация на Linux

KVM (Kernel-based Virtual Machine) — модуль ядра, обеспечивающий аппаратную виртуализацию.

QEMU — эмулятор, который с KVM превращается в полноценный гипервизор. Вместе они позволяют запускать VM быстро и эффективно, без overhead, как в VirtualBox или VMware.

Полезно для тестирования, разработки.

🟢 Пример 1

Создание VM одной командой (через QEMU)

qemu-system-x86_64 \
  -enable-kvm \
  -m 1G \
  -cpu host \
  -drive file=focal-server-cloudimg-amd64-disk-kvm.img,format=qcow2 \
  -netdev user,id=net0 \
  -device virtio-net-pci,netdev=net0 \
  -nographic

Где:
-enable-kvm — используем аппаратное ускорение
-m 1G — выделяем 1 ГБ памяти
-cpu host — пробрасываем CPU хоста без эмуляции
-nographic — запускаем без GUI (для серверов)

Преимущество
Максимально быстро и минималистично, но без персистентности — закрыли терминал = ВМ остановилась.

🟢 Пример 2

Создание управляемой ВМ одной командой (через libvirt)

virt-install \
  --name vm \
  --ram 2048 \
  --vcpu 2 \
  --disk my_disk.qcow2,size=8 \
  --cdrom ubuntu-24.04.3-live-server-amd64.iso

✅ Что это дает

— Автоматическая регистрация ВМ в libvirt
— Управление через virsh
— Сетевые мосты "из коробки"
— Персистентность конфигурации

Управление такими виртуальными машины происходит через утилиту virsh.

Основные команды:

virsh list --all           # список всех ВМ
virsh start vm             # запуск ВМ
virsh shutdown vm          # штатная остановка
virsh destroy vm           # принудительное завершение
virsh edit vm              # редактирование конфигурации
virsh undefine vm          # удаление ВМ (но не дисков)

📍 Первый пример с qemu-system-x86_64 — ваш выбор для быстрого тестирования образов и экспериментов, когда нужно запустить ВМ буквально одной командой.

📍 Второй подход через virt-install + virsh идеален, когда требуется полноценное управление виртуальными машинами — здесь на помощь приходит libvirt с его персистентностью и удобным CLI.

Оба способа отлично дополняют друг друга в арсенале инженера.

#линуксятина

🤓 Mastering KVM Virtualization

Практическое руководство по KVM, QEMU и libvirt

🔎 Рассматривается:
— архитектура и внутреннее устройство KVM/QEMU, работа libvirt;
— установка окружения и создание ВМ (virt-manager, virt-install, PXE);
— виртуальные сети и хранилища: Linux bridge, NAT/ routed/ isolated сети, MacVTap, iSCSI, LVM;
— управление жизненным циклом ВМ: консоли (VNC/SPICE), агенты гостя, live-миграция;
— шаблоны и снапшоты, форматы дисков, клонирование/тонкое развёртывание;
— Kimchi: веб-управление KVM/libvirt;
— SDN для KVM: Open vSwitch, туннели (VXLAN), OpenDaylight;
— интеграция с OpenStack и устранение неполадок виртуализации;
— производительность и best practices: VirtIO, CPU/memory/NUMA, I/O, тайм-кипинг;
— инструменты V2V/P2V (virt-v2v) и конвертация гостевых систем.

Авторы:
Humble Devassy Chirammal, Prasad Mukhedkar, Anil Vettathu.
Издательство:
Packt Publishing, 2016.

#книги

💎 Виртуализация vs Контейнеризация

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

➡️ Время запуска:

ВМ — минуты / контейнеры — секунды

➡️ Диск:

ВМ занимают больше / контейнеры легче

➡️ Портативность:

ВМ сложнее переносить / контейнеры проще

➡️ Эффективность:
у контейнеров выше

➡️ ОС и ядро:

ВМ используют собственную ОС / контейнеры — общее ядро

#полезное

⬆️ Кейс: Частное облако и российская виртуализация для энергокомпании

Запрет на использование иностранных ПАКов на объектах КИИ и растущие требования к отказоустойчивости заставляют критическую инфраструктуру искать быстрые и надёжные решения.

📞 Задача

Крупная энергокомпания — объект КИИ, обеспечивающий энергоснабжение в Сибири, обратилась с запросом:
— быстро нарастить ресурсы и повысить устойчивость ИТ-систем;
— перейти на российскую виртуализацию.

🖲️ Решение

Базой проекта стала платформа частного облака CORTEL с использованием отечественной системы виртуализации zVirt.

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

⭐️ Этапы внедрения

— Анализ требований КИИ и проектирование архитектуры.
— Развёртывание частного облака на базе zVirt в ЦОДе заказчика.
— Интеграция с существующей ИТ-инфраструктурой.
— Настройка политики доступа и мониторинга.
— Проверка производительности и переход в эксплуатацию.

🚩 Результат

— Развёртывание за 2 дня.
— SLA 99,95% (максимум ~4 часа недоступности в год).
— Соответствие требованиям КИИ.
— Отсутствие затрат на долгий цикл закупок оборудования.

«Подрядчик взял всё на себя — оборудование, мощности и отечественную виртуализацию. Мы получили удобный интерфейс, гарантии и специалистов на связи, отвечающих за работоспособность и администрирование кластера.»
— отметил ИТ-директор заказчика.

О нюансах проекта читайте здесь

Чем заменить VMware ➡️ здесь

#изПрактики

🛡 КИИ: Новости и материалы.

Если вы занялись вопросом недавно, вот памятка для ответственных и заинтересованных по теме КИИ, с ответами на основные вопросы.

Про актуальные изменения за первое полугодие 2025 года тут

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

Из последних новостей за второе полугодие:

Сроки миграции перенесли до 1 января 2028 и 1 декабря 2030.
Переход значимых объектов КИИ на российское ПО официально сдвинут.
Минцифры 19 сентября 2025 представило проект ПП о сроках и правилах перехода на отечественное ПО: предельная дата — 1 января 2028; при объективной невозможности и решении Президиума Правкомиссии срок может быть продлён, но не далее 1 декабря 2030.

Появился стандарт по ПАК для КИИ ПНСТ 1007-2025
В конце июня 2025 утверждён предварительный национальный стандарт, который классифицирует программно-аппаратные комплексы по назначению и задаёт основу для их признания «доверенными» для применения на объектах КИИ. Полный текст опубликован на портале Росстандарта.

Сформированы «Типовые отраслевые объекты КИИ»
ФСТЭК опубликовала проект постановления с перечнями типовых отраслевых объектов КИИ

#ИТиЗАКОН

👋 make-argocd-fly — генератор ArgoCD Applications.

Превращает шаблоны на базе Helm, Kustomize и Jinja2 в Kubernetes-манифесты, а также автоматически создает ресурсы Argo CD Application, адаптированные для разных окружений (например, dev, stage, prod).

Основной функционал:

✅Рендерит Helm-чарты и Kustomize-оверлеи в детерминированный YAML — видно, что именно будет применено в кластер.

✅Генерирует ресурсы Application для Argo CD на основе ваших шаблонов.

✅Поддерживает шаблоны на Jinja2 (переменные, логика, частичные шаблоны).

✅Работает с несколькими окружениями (dev/stage/prod) и раскладывает вывод по понятной структуре каталогов: output/<env>/<app>/…

✅Упрощает код-ревью: идентичные шаблоны всегда генерируют одинаковые манифесты, поэтому в Pull Request видно только смысловые изменения.

✅Установка:

pip install make-argocd-fly   # требуется Python ≥ 3.11

👉 Git
#полезное

Terraform — инструмент от HashiCorp для декларативного описания инфраструктуры через код (IaC).

Вы описываете желаемое состояние, а Terraform сам понимает, как его достичь.

⏰ Зачем

Упрощает управление инфраструктурой — нет ручных кликов в консолях. Обеспечивает повторяемость, аудит и коллаборацию. Идеально для DevOps: деплоите VPC, EC2 или K8s кластер одним apply.

⏰ Как используется

Пишем конфиг, запускаем terraform init (инициализация), terraform plan (превью изменений), terraform apply (применение). Для разрушения — terraform destroy. Поддерживает state-файлы для отслеживания изменений.

⏰ Модульность

Terraform поддерживает модули — переиспользуемые блоки кода.
Создайте модуль для VPC, и используйте его в разных проектах. Это как Lego: собирайте инфраструктуру из готовых частей, меняя переменные.

⏰ Универсальность языка HCL

HCL (HashiCorp Configuration Language) — декларативный язык Terraform.

Синтаксис одинаковый для всех облаков: ресурсы описываются блоками resource "aws_instance" {} или resource "google_compute_instance" {}. Разница только в провайдерах — плагинах для конкретных облаков (AWS, GCP). Один код — разные среды, легко мигрировать между провайдерами.

🔵 Terraform превращает ручное создание инфраструктуры в предсказуемый и повторяемый процесс. Один раз настроил — используешь везде.

#заметкиИнженера

💎 Terragrunt — тонкая обёртка над Terraform, которая устраняет повторяющийся код и упрощает управление сложной инфраструктурой.

🤔 Основной функционал

— Автоматическое управление зависимостями между модулями (dependencies)
— Поддержка нескольких окружений (dev/stage/prod) с общими настройками
— Интеграция с remote state для хранения состояния Terraform
— Hooks для выполнения скриптов до/после Terraform-операций
— Автоматизация команд Terraform (init, plan, apply) для всей инфраструктуры

🤔 Ключевые особенности

— Универсальность HCL: синтаксис Terraform (HCL) остаётся неизменным, Terragrunt добавляет надстройку для конфигураций
— Провайдер-независимость: работает с любыми облаками, отличия только в провайдерах, а код — единый
— Упрощение CI/CD: легко интегрируется в пайплайны для автоматизированного IaC

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

👉 Git
#полезное

⚙️ Cloud-init — стандартная система инициализации для облачных экземпляров, которая выполняет начальную настройку при первом запуске ВМ. Поддерживается всеми major-облаками и гипервизорами.

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

1. Образ ОС содержит cloud-init пакет
2. При старте ВМ cloud-init ищет данные конфигурации
3. Выполняет инструкции (пользователи, пакеты, скрипты)
4. Сохраняет логи в /var/log/cloud-init-output.log

✅ Основные возможности:
— Создание пользователей и настройка SSH-ключей
— Установка пакетов и обновление системы
— Настройка сетевых интерфейсов
— Выполнение custom-скриптов
— Монтирование дисков и настройка swap

🚪 Пример конфигурации:

#cloud-config
# Конфигурация пользователя 
users:
  - name: admin
    passwd: $6$rounds=4096$xyz$...  # хэш пароля
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    shell: /bin/bash

# Обновление пакетов
package_update: true
package_upgrade: true

# Установка сurl, htop, git
packages:
  - curl
  - htop
  - git

🤓 Cистема изначально разрабатывалась для Ubuntu, но стала де-факто стандартом и теперь поддерживается всеми major-дистрибутивами, включая CentOS, Debian и даже FreeBSD.

Cloud-init превращает создание новых серверов из рутины в автоматизированный процесс — один раз настроил конфиг и получаешь готовые к работе ВМ в любом облаке.

#линуксятина

🦎 Terraform: инфраструктура на уровне кода. 3-е межд. изд.

Практическое руководство по проектированию, развёртыванию и сопровождению облачной инфраструктуры с помощью Terraform.

🔎 Рассматривается:

— основы Terraform: синтаксис HCL, state-файлы, провайдеры;
— создание модулей, их тестирование и версионирование;
— управление состоянием в команде, блокировки и бэкенды;
— шаблоны проектирования и лучшие практики для продакшна;
— CI/CD для инфраструктурного кода.

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

Автор:
Yevgeniy Brikman.
Издательство:
O’Reilly, 3-е межд. изд., 2022.

#книги

💊 Кейс: миграция фармацевтической торговой сети в Public Cloud

Цель — повысить доступность ИТ-систем и снизить стоимость владения.

📞 Задача

— Обеспечить непрерывность работы ИТ-систем и устранить периодические недоступности критичных сервисов.

— Масштабировать ресурсы без длительных внутренних проектов.

— Провести миграцию в облако с минимальным влиянием на бизнес.

⭐️ Этапы реализации

— Собрали совместную рабочую группу и план миграции.

— Провели тесты и подготовили план миграции.

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

— Перенос проводили в ночные окна для минимизации влияния на пользователей.

— Проверка работоспособности и ввод в эксплуатацию.

— Настройка поддержки и регламентов взаимодействия 24×7.
CORTEL

🚩 Результат

— ТСО ↓ в 12 раз в первый год обслуживания за счёт перехода в облако.

— ROI +32% за трёхлетний период по сравнению с владением своей инфраструктурой.

— SLA 99,95% на облачной инфраструктуре.

— Масштабирование «по запросу» (например, оперативное добавление ядер/диска); CAPEX трансформирован в OPEX.

— Круглосуточная поддержка и прямое взаимодействие инженерных команд

«Сервис позволил сократить операционные затраты и сосредоточиться на развитии бизнеса; миграция ночью прошла по плану с ожидаемым результатом», — Чингис Юндунов,
ИТ-директор «СИБИНТЕРФАРМ».

Подробнее о проекте читайте здесь

Все про Public Cloud — здесь

#изПрактики

🏓 Как добиться 100% SLA более чем на 90 дней

❕ Мы начали с метрик.
Зафиксировали SLI и SLO: аптайм, потери пакетов, конвергенция BGP, MTTR. На каждую метрику — пороги и автоматические действия. Если что-то уходит за границы — система реагирует раньше людей.

🔎 Сеть
Несколько независимых аплинков, приходящих на независимые взаиморезервируемые маршрутизаторы. BGP с community для инженерии трафика и blackhole. Мониторим префиксы, xFlow, задержки на магистралях. Роутинговые «что если» прогоняем заранее.

💻 Кластера
Только HA. Хранилища настроены под сценарий: синхронно для критичных RPO, асинхронно между площадками для DR. Регулярно проверяем репликацию и отработку аварий.

🛡 Прод
Любое изменение — через тестовые среды и поэтапный выпуск. Rate limiting и load shedding включаются до того, как пользователи заметят деградацию. Окна обслуживания — только в периоды минимальной активности и так, чтобы клиенты это "не почуствовали".

⚙️ Операции
Runbook’и подробные и точные: кто, что, за сколько минут. Проводим тестовые испытания: искусственные отказы, секундомер, разбор полётов. Ошибочный бюджет не «тратим» — предотвращаем инциденты раньше.

🗂 Прозрачность
Важные метрики — публичны.
За последние 90 дней:
0 инцидентов с влиянием на сервисы
0 минут простоя
100.000% аптайма.

Это видно здесь

Как говорит наш ДИТ:

«В нашем деле хорошо — это когда никто ничего не заметил. И вот уже 90 дней подряд мы ничем не удивляем.
100%. Ровно. Скучно. Красиво»

⚙️ Must-Have Cloud-Native утилиты

⚙️ K9s
— терминальный UI для управления Kubernetes кластерами с возможностью мониторинга ресурсов, диагностики и оперативного управления подами.

⚙️ Lens
— полнофункциональная IDE для Kubernetes с визуализацией кластера, встроенным терминалом и поддержкой расширений.

⚙️ Alertmanager
— компонент экосистемы Prometheus для обработки, группировки и маршрутизации оповещений с поддержкой различных каналов уведомлений.

⚙️ VictoriaMetrics
— высокопроизводительная и экономичная система мониторинга и хранения временных рядов, совместимая с Prometheus.

⚙️ Cert-manager
— автоматическое управление TLS-сертификатами в Kubernetes, включая выпуск, обновление и продление от Let's Encrypt и других CA.

#полезное

💻 Cloud Controller Manager в Kubernetes: интеграция с облаками

Компонент Kubernetes, который абстрагирует работу с API облачных провайдеров.

💬 Как работает

Изначально облачная логика была внутри kube-controller-manager. Начиная с Kubernetes 1.6, CCM выделен в отдельный процесс/Deployment и берёт на себя задачи, связанные с облаком: создание LoadBalancer, управление нодами, маршрутизация и пр.

💬 Из чего состоит

CCM включает контроллеры (node, route, service), которые отслеживают состояние кластера и вызывают облачные API для синхронизации. Например, при создании Service типа LoadBalancer CCM запрашивает у провайдера балансировщик. Это позволяет использовать Kubernetes в мультивендорных средах без «вшивания» логики конкретного облака в ядро.

💬 Что это даёт

✅ Абстракция от вендора. Кластер не привязан к одному облаку: меняете провайдера — меняете реализацию CCM.

✅ Динамическое управление ресурсами. Автоматическое создание и удаление объектов (LB, маршрутов, узлов) по мере необходимости.

✅ Гибкость и масштабирование. Поддержка частных облаков и on-prem через кастомные реализации CCM.

Примечание: для хранилищ сейчас обычно используются CSI-драйверы; исторически облачные диски интегрировались через провайдер в Kubernetes.

💬 Что может CCM

✅ LoadBalancer
Автоматически создаёт облачный балансировщик для Service.

✅ Node Management
Добавляет/удаляет ноды, выставляет providerID и метки (например, зона доступности).

✅ Маршруты/сети
Настраивает маршрутизацию между нодами, если это требуется конкретным провайдером.

✅ Автоскейлинг
CCM предоставляет интерфейс для Cluster Autoscaler, чтобы динамически добавлять/удалять ноды в облаке при изменении нагрузки. Без CCM автоскейлинг ограничен локальными кластерами; с ним — полноценно работает в облаке.

#полезное

☯️CCM: проблема «курица и яйцо» в Kubernetes

В официальном блоге Kubernetes есть статья о классической проблеме инициализации Cloud Controller Manager после выноса cloud-provider из ядра.

💬 Что не так с CCM?

— Зависимость от нод.
При старте kubelet с --cloud-provider=external получают запрещающую метку (taint)
node.cloudprovider.kubernetes.io/uninitialized:NoSchedule.

CCM должен снять эту запрещающую метку и добавить облачные сведения (адреса, метки). Если CCM развёрнут как Deployment/DaemonSet без необходимых допусков (tolerations), он может не запуститься на таких нодах.

— Каскадный эффект. Неинициализированные узлы блокируют запуск CCM, тот — снятие запрещающей метки. Параллельно CNI может ждать IP от CCM, узлы получают node.kubernetes.io/not-ready, и система зацикливается.

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

💬 Как исправить?

— hostNetwork: true.

Чтобы CCM использовал сетевой стек хоста и имел доступ к конечным точкам (endpoints) и API провайдера.

— Deployment/DaemonSet + механизм leader-election.

Разворачивайте как управляемый ресурс и включайте --leader-elect=true при нескольких репликах, чтобы избежать гонок.

— Размещение на control plane.

Задайте nodeSelector: { node-role.kubernetes.io/control-plane: "" } и добавьте podAntiAffinity, чтобы реплики не оказывались на одном хосте.

— Явные допуски (tolerations).

🟢Для старта на неинициализированных узлах:
node.cloudprovider.kubernetes.io/uninitialized:NoSchedule

🟢Для размещения на control plane:
node-role.kubernetes.io/control-plane:NoSchedule и/или node-role.kubernetes.io/master:NoSchedule

🟢Для устойчивости при инициализации:
node.kubernetes.io/not-ready:NoExecute и node.kubernetes.io/unreachable:NoExecute (иногда может потребоваться и NoSchedule).

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

💬 Если CCM работает вне управляемого им кластера (например, в hosted control plane), применимость советов зависит от конкретной топологии и ограничений среды. Это не «упрощённый» случай — проверяйте требования вашей архитектуры.

#заметкиИнженера

🖥 NFS (Network File System) — протокол для совместного доступа к файлам по сети, разработанный Sun Microsystems в 1984 году.

Позволяет монтировать удалённые директории как локальные, делая их доступными для нескольких хостов. Используется в кластерах, NAS и облаках для общего хранилища.

🟡 Как работает

— Архитектура «клиент-сервер»: сервер экспортирует каталоги, клиенты их монтируют
— RPC-протокол: для управления подключениями (порт 111)
— NFS-демоны: nfsd обрабатывает запросы, mountd управляет монтированием
— Версии протокола: NFSv3 (UDP/TCP), NFSv4 (TCP, встроенная аутентификация)

🟡 Базовая настройка на сервере

# Установка пакета
sudo apt install nfs-kernel-server

# Создаём экспортируемый каталог
sudo mkdir /srv/share
sudo chown nobody:nogroup /srv/share

Конфигурация /etc/exports:

/srv/share 192.168.1.0/24(rw,sync,no_subtree_check)

🟡 Ключевые атрибуты /etc/exports

— rw/ro — чтение-запись или только чтение
— sync/async — синхронная/асинхронная запись
— no_subtree_check — отключение проверки поддеревьев
— no_root_squash — доступ root без преобразования
— all_squash — всех пользователей отображать в nobody
— anonuid/anongid — явное указание UID/GID для анонимных пользователей

🟡 Настройка клиента

# Установка пакета
sudo apt install nfs-common

# Монтирование каталога
sudo mount -t nfs server-ip:/srv/share /local/mount

NFS — классика для общих файловых систем в Linux, идеально для кластеров или бэкапов

#линуксятина

☁️ Путь к Cloud-native: как изменилась разработка

От монолита на «железе» и каскада — к микросервисам в контейнерах, облаку и DevOps.

Четыре составляющие подхода:

— Процесс:
Waterfall сменили Agile и DevOps — короткие итерации, автоматизация, CI/CD.

— Архитектура:
от монолита к микросервисам с независимыми релизами.

— Развёртывание:
от серверов в стойках и ВМ к образам Docker и контейнерам.

— Инфраструктура: вместо своих стоек — облако как базовая среда.

#полезное

Кейс: Гибридное облако и DBaaS для поставщика электроэнергии

📞 Задача

⚪️Обеспечить гарантированную доступность ИТ-сервисов.

⚪️Сформировать целевую гибридную архитектуру с учётом территориальных ограничений и пошагового плана миграции.

⚪️Закрыть дефицит компетенций по администрированию СУБД через модель сервиса (DBaaS).

🖲️ Этапы реализации

⚪️Совместная рабочая группа: аудит текущей инфраструктуры, расчёт TCO и выбор сервисной модели.

⚪️Проектирование целевой гибридной архитектуры с размещением в ЦОД Новосибирска; подготовка ТЗ и требований к SLA.

⚪️План миграции с обходными сценариями под технические ограничения и распределённые площадки.

⚪️Перенос критичных сервисов поэтапно с контролем доступности; ввод в промышленную эксплуатацию.

⚪️Подключение DBaaS: обслуживание >200 БД (в т.ч. InterSystems IRIS и MS SQL) силами команды CORTEL.

⚪️Настройка 24×7 поддержки и регламентов взаимодействия по SLA.


🚩 Результат

⚪️Доступность 99,982% в год на новой гибридной архитектуре (ранее — 96,15%).

⚪️100% клиентов перешли на онлайн-сервисы благодаря модернизации и новому качеству обслуживания БД.

⚪️Выгода сервисной модели: −59% к TCO относительно модернизации собственных ЦОД (по расчёту до старта проекта).

⚪️Гарантированный SLA до 99,99% по критичным сервисам и работа 24×7 без зависимости от отпусков и замен в ИТ-штате.

⚪️Быстрое закрытие дефицита компетенций: DBaaS вместо долгого найма редких DBA под кастомные решения.

«Мы скрупулёзно проработали ТЗ и требования к качеству. На выбранной гибридной архитектуре обеспечили непрерывность работы приложений и предсказуемый SLA; команда CORTEL быстро погрузилась и качественно оказывает сервис».
— директор по ИТ «НовосибирскЭнергоСбыт»

✉️ Подробнее о проекте читайте здесь.

#изПрактики

😎 Дом, офис или гибрид

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

Чтобы не словить минусы удалёнки одиночество и изоляция, размытые границы дня и переработок, расфокус и «залипание» в ленте, а еще проблемы со спиной и лишним весом — нужен режим.

🤷‍♂️ Дисциплина — наше всё.

🥰 Начинать день с одного приоритетного дела.

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

😠 Организовать рабочую точку дома: стол, свет, удобный стул, наушники; фиксированное время начала и завершения; ритуал выхода (закрыт ноутбук — работа окончена).

🤙 Зарезервировать время для созвонов; в остальное время — асинхронные сообщения.

🎧 Поддерживать свой жизненный ресурс: вода под рукой; полноценный обед без встреч и скроллинга ленты.

А еще разминки для тела и глаз 🙃

😄 — дом
👍 — офис
🔥 — гибрид

P.S. Не забудьте закрыть ноутбук на эти два дня, хороших выходных✔️

#MentalDebug

⚠️ Как КИИ соответствовать новым требованиям

С 1 сентября 2025 года внесены изменения: новые сроки, официальный стандарт ПНСТ 1007-2025 и типовые отраслевые объекты.

➡️ Что сделать уже сейчас

🟡 Определить контур: реестр объектов КИИ и уровни значимости.

🟡 Сверить требования: ПНСТ 1007-2025 и типовые объекты/ перечень обязательных мер.

🟡 Составить перечень доработок: что добавить, что заменить, что убрать — с оценкой риска и трудозатрат.

🟡 Составить план до 01.01.2028 и 01.12.2030: приоритеты, сроки, владельцы, бюджет.

🟡 Оформить процессы: регламенты реагирования, журналы, роли, обучение.

🟡 Запустить контроль: метрики, квартальные ревизии, доказательная база для проверок.

👉 Подробнее читайте в новом материале

#статья

💻 Disruption Budget в Kubernetes: как не сломать сервис плановыми работами

PodDisruptionBudget (PDB) - это объект Kubernetes, который ограничивает количество одновременно недоступных подов во время добровольных вытеснений (voluntary disruptions).

🔵 Ключевое отличие:
PDB не защищает от аппаратных сбоев или проблем с нодами. Его задача — сделать плановые работы предсказуемыми и безопасными.

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

Без PDB:
— При drain ноды Kubernetes может одновременно выключить все поды
— Rolling update может убить старые поды до запуска новых
— Обновление кластера = лотерея доступности сервиса

С PDB:
— Гарантируется минимальное количество работающих реплик
— Контролируется максимальное количество одновременно недоступных подов
— Плановые работы перестают влиять на SLO

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

💬 Защищаем критичное приложение

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: payment-service-pdb
spec:
  minAvailable: 2  # Всегда должно быть доступно не менее 2 подов
  selector:
    matchLabels:
      app: payment-service

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

💬 Постепенное обновление stateful-сервиса

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: kafka-pdb
spec:
  maxUnavailable: 1  # Одновременно может быть недоступен только 1 под
  selector:
    matchLabels:
      app: kafka-broker

Можно использовать для stateful-приложений (БД, очереди), где одновременный уход нескольких реплик может нарушить консистентность.

🔵 Как это работает на практике

— При drain ноды kubectl drain node-1 — kubelet проверяет PDB перед каждым вытеснением
— При rolling update — Deployment согласует обновление с ограничениями PDB
— При ручном удалении kubectl delete pod — PDB может заблокировать операцию

PodDisruptionBudget — это не опция, а обязательный инструмент для любого продакшн-сервиса в Kubernetes.

Он превращает потенциально опасные операции в контролируемые процессы и позволяет соблюдать SLO даже во время плановых работ.

#заметкиИнженера