🖥 ip / iproute2 — стандарт для управления сетью в современном Linux.

Пришёл на смену устаревшему net-tools (ifconfig, route, arp), которые давно не входят в базовую установку большинства дистрибутивов. Всё, что раньше делалось десятком разных утилит, теперь собрано в одной команде с единым синтаксисом.

🟣 Как устроено?

Команда ip работает по схеме:

ip [объект] [команда]

Где объект — это то, чем управляем (link, addr, route, neigh и т.д.), а команда — действие над ним (show, add, del, set).

🟣 Основные объекты

link — сетевые интерфейсы (физические и виртуальные)
address (a) — IP-адреса на интерфейсах
route (r) — таблица маршрутизации
neighbour (n) — ARP/NDP-таблица (соседи)
rule — правила policy routing
netns — сетевые неймспейсы

🟣 Примеры команд

Посмотреть список всех интерфейсов:

ip link show

Поднять/выключить интерфейс:

sudo ip link set eth0 up
sudo ip link set eth0 down

Посмотреть адреса на интерфейсах:

ip addr show

1: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
    inet 192.168.1.10/24 brd 192.168.1.255 scope global eth0

Добавить маршрут:

sudo ip route add 10.0.0.0/24 via 192.168.1.1 dev eth0

Добавить маршрут по умолчанию:

sudo ip route add default via 192.168.1.1

Удалить маршрут:

sudo ip route del 10.0.0.0/24

✔️ iproute2 — это единый интерфейс ко всему сетевому стеку ядра: линки, адреса, маршруты, правила, туннели, неймспейсы. Знание ip вместо разрозненных legacy-утилит экономит время.

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

💻 PV, PVC и StorageClass: как под получает диск в Kubernetes

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

🔺Persistent Volume (PV)

— Объект кластера, описывающий конкретный кусок хранилища: диск в облаке, LUN, NFS-шару или локальный volume.
— Существует независимо от пода — создаётся и удаляется отдельно, имеет свой жизненный цикл.
— Содержит параметры реального хранилища: размер, режим доступа, драйвер, точки монтирования.

🔺Persistent Volume Claim (PVC)

— Запрос приложения на хранилище: «нужно 10Gi с доступом ReadWriteOnce».
— PVC не знает, где физически лежат данные — это уровень абстракции для разработчика.
— Kubernetes сопоставляет PVC с подходящим PV (bind), и только после этого том можно смонтировать в под.

🔺 StorageClass

— Описывает «класс» хранилища и параметры его создания: тип диска, зону, файловую систему, политику удаления.
— Позволяет не создавать PV вручную — при появлении PVC с указанным StorageClass том создаётся автоматически.
— Именно StorageClass связывает Kubernetes с конкретным драйвером хранилища через CSI.

🔺 CSI (Container Storage Interface)

— Стандартизированный API, через который Kubernetes общается с системами хранения без встроенной поддержки в ядре kubelet.
— Каждый провайдер (Ceph, облачный диск, NFS и т.д.) поставляет свой CSI-драйвер как набор подов в кластере.
— Драйвер отвечает за создание, подключение (attach) и монтирование (mount) томов по запросу Kubernetes.

Как это работает вместе (динамическое провижининг)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-pvc
spec:
  storageClassName: fast-ssd
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

— Приложение создаёт PVC с указанием StorageClass.
— Контроллер провижининга (часть CSI-драйвера) видит PVC без привязанного PV и создаёт новый PV через API стораджа.
— Kubernetes связывает созданный PV с PVC (bind).
— Под с этим PVC планируется на узел, kubelet через CSI-драйвер выполняет монитрование тома.

Без CSI и динамического провижининга администратору пришлось бы вручную создавать PV под каждый запрос приложения. Эта связка убирает ручной шаг и делает хранилище таким же декларативным ресурсом, как Deployment или Service.

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

⚙️ jq и yq — два похожих инструмента для работы со структурированными данными прямо в терминале: jq для JSON, yq для YAML.

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

🟢 jq — Принимает JSON на входе, применяет фильтр-выражение, отдаёт результат — тоже JSON (или текст).

Базовый синтаксис:

команда | jq 'фильтр'

Пример исходных данных (response.json):

{
  "status": "ok",
  "pods": [
    {"name": "nginx-1", "ready": true, "restarts": 0},
    {"name": "nginx-2", "ready": false, "restarts": 5}
  ]
}

Достать конкретное поле:

cat response.json | jq '.status'

"ok:"

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

cat response.json | jq '.pods[].name'

"nginx-1"
"nginx-2"

Фильтрация по условию:

cat response.json | jq '.pods[] | select(.ready == false)'

{
  "name": "nginx-2",
  "ready": false,
  "restarts": 5
}

🟢 yq — по духу — тот же jq, только для YAML синтаксис фильтров почти идентичен jq.

Пример файла (deployment.yaml):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: nginx
          image: nginx:1.25

Достать значение:

yq '.spec.replicas' deployment.yaml

3

Сменить образ контейнера:

yq -i '.spec.template.spec.containers[0].image = "nginx:1.27"' deployment.yaml

🟢 jq и yq — база для любого, кто работает с API, Kubernetes или CI/CD: они превращают ручной разбор JSON/YAML в одну команду, которую легко засунуть в скрипт.

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

💻 HPA: автоскейлинг по метрикам

Horizontal Pod Autoscaler (HPA) — встроенный контроллер Kubernetes, который автоматически изменяет количество реплик Deployment, StatefulSet или ReplicaSet в зависимости от текущей нагрузки. Задача HPA — держать нагрузку на под в заданных рамках, не привлекая к этому человека.

🔺 HPA работает в цикле (по умолчанию — раз в 15 секунд):
— Получает текущие метрики из metrics-server (или внешнего адаптера метрик, если используются custom/external metrics)
— Сравнивает текущее значение метрики со значением, заданным в спецификации HPA
— Вычисляет желаемое количество реплик по формуле:

desiredReplicas = ceil(currentReplicas * (currentMetricValue / desiredMetricValue))

— Обновляет поле replicas у целевого объекта (Deployment/StatefulSet)

Контроллер не действует резко: изменения сглаживаются, а между операциями масштабирования выдерживается пауза (stabilization window), чтобы избежать «дребезга» — постоянных колебаний числа реплик туда-обратно.

🔺 Источники метрик

— Resource metrics — CPU и память пода, собираются через metrics-server. Базовый и самый распространённый вариант.
— Custom metrics — метрики приложения (например, число запросов в очереди), поставляются через Prometheus или аналогичный адаптер.
— External metrics — метрики внешних систем, не привязанные к объектам Kubernetes

Минимальная настройка

Предполагается, что для пода заданы resources.requests.cpu — без них HPA не сможет посчитать процент утилизации.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Частые ошибки

— Отсутствие requests у контейнеров — метрика Utilization считается относительно запроса ресурсов, без него HPA не сработает
— Слишком узкий диапазон minReplicas–maxReplicas — контроллеру физически негде масштабироваться
— Игнорирование stabilization window при настройке — резкие пики нагрузки могут вызывать частые колебания без её корректной настройки в behavior
— Использование HPA и VPA на одних и тех же метриках ресурсов одновременно — контроллеры начинают конфликтовать между собой

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

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

🐧 nftables — современный фреймворк для фильтрации пакетов и NAT в Linux, пришедший на смену связке iptables/ip6tables/arptables/ebtables.

Зачем менять iptables на nftables

— Единый синтаксис для IPv4, IPv6, ARP и Ethernet-фреймов вместо четырёх отдельных утилит
— Правила применяются атомарно — нет промежуточного состояния с частично применённым набором
— Встроенные структуры данных (sets, maps) вместо десятков однотипных правил
— Меньше накладных расходов на большом количестве правил за счёт более эффективной модели обработки в ядре

🟡 Структура: таблицы → цепочки → правила

— Таблица (table) — контейнер верхнего уровня, привязан к семейству адресов: ip, ip6, inet (сразу для v4 и v6), arp, bridge, netdev
— Цепочка (chain) — набор правил внутри таблицы. Бывает базовой (base chain, подключена к хукам ядра) или обычной
— Правило (rule) — конкретное условие + действие (accept, drop, jump, counter и т.д.)

Хуки для базовых цепочек: prerouting, input, forward, output, postrouting — те же точки, что и в iptables, но привязка задаётся явно при создании цепочки.

🟡 Базовая структура набора правил

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        ct state established,related accept
        iifname "lo" accept
        tcp dport 22 accept
    }
}

— table inet filter — таблица для v4/v6 с именем filter
— chain input — базовая цепочка на хуке input, приоритет 0, политика по умолчанию — drop
— ct state established,related accept — разрешить пакеты уже установленных соединений
— tcp dport 22 accept — разрешить входящий SSH

🟡 Пример: NAT для проброса порта (DNAT)

table ip nat {
    chain prerouting {
        type nat hook prerouting priority -100;
        tcp dport 8443 dnat to 10.0.0.5:443
    }
    chain postrouting {
        type nat hook postrouting priority 100;
        oifname "eth0" masquerade
    }
}

Входящий трафик на порт 8443 перенаправляется на внутренний сервер 10.0.0.5:443, а masquerade подменяет исходящий адрес для трафика, уходящего через eth0 — типичная схема для VPS с внутренними сервисами за одним внешним IP.

🟡 Полезные команды

nft list ruleset
nft -f /etc/nftables.conf
nft add table inet filter
nft flush ruleset

nftables — не косметическая замена iptables, а другая модель работы с пакетным фильтром: декларативная, атомарная и заметно менее многословная на нетривиальных наборах правил.

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

⚠️ Что делать после категорирования объекта КИИ

После присвоения категории объект становится частью живого контура: его нужно не только описать в документах, но и постоянно контролировать в эксплуатации.

Важно понимать:

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

👉 Что меняется после категорирования объекта КИИ и какие требования 187-ФЗ важно учесть дальше — разобрали в новом материале.

#статья

🖥 smartctl — утилита из пакета smartmontools для чтения диагностических данных накопителя через S.M.A.R.T.

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

S.M.A.R.T. — это встроенная в накопитель система диагностики. Она собирает данные о его состоянии, а smartctl выводит их в понятном виде

➡️ Основные команды

# Общая информация
sudo smartctl -i /dev/sda

# Краткая оценка состояния
sudo smartctl -H /dev/sda

# Таблица показателей
sudo smartctl -A /dev/sda

# Полный отчёт
sudo smartctl -a /dev/sda

# Запуск короткого самотеста
sudo smartctl -t short /dev/sda

# Результаты самотестов
sudo smartctl -l selftest /dev/sda

➡️ На что смотреть у HDD

— Reallocated_Sector_Ct — переназначенные секторы. Рост значения — повод менять диск;
— Current_Pending_Sector — секторы, которые не читаются, но ещё не переназначены;
— Offline_Uncorrectable — неисправимые ошибки;
— UDMA_CRC_Error_Count — ошибки передачи данных. Причина может быть в кабеле или дисковой корзине;
— Power_On_Hours — наработка;
— Temperature_Celsius — температура.

➡️ У SSD дополнительно проверяют

— Wear_Leveling_Count — износ ячеек;
— Media_Wearout_Indicator — износ памяти NAND;
— Total_LBAs_Written — общий объём записанных данных.

➡️ У NVMe основные показатели

— percentage_used — израсходованный ресурс;
— available_spare — резерв запасных блоков;
— media_errors — ошибки носителя;
— critical_warning — критические предупреждения.

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

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

⏳ systemd .timer — штатный планировщик задач в systemd, альтернатива cron.

Таймер активирует полноценный .service. Каждый запуск попадает в journald, получает свой cgroup, лимиты по памяти и CPU, а также зависимости — задачу можно привязать к готовности сети или базы.

➡️ Пример

/etc/systemd/system/backup.service:
[Unit]
Description=Backup job

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

/etc/systemd/system/backup.timer
[Unit]
Description=Run backup daily

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer

Включается таймер, а не сервис.

➡️ Расписание
Календарное, через OnCalendar= — формат DayOfWeek Year-Month-Day Hour:Minute:Second:
— *-*-* 03:00:00 — ежедневно в 3 ночи
— Mon..Fri 09:00 — по будням
— *:0/15 — каждые 15 минут
— daily, weekly, hourly — сокращения

➡️ Монотонное, от событий
— OnBootSec= — через N после загрузки
— OnUnitActiveSec= — через N после прошлого запуска

Связка OnBootSec=5min + OnUnitActiveSec=1h даёт запуск через пять минут после старта и дальше каждый час.

➡️ Полезные директивы
— Persistent=true — пропущенный запуск (машина была выключена) отработает после загрузки. В cron такого нет
— RandomizedDelaySec=300 — случайный разброс, спасает от одновременного старта на сотне нод
— AccuracySec=1s — точность, по умолчанию минута
— Unit= — запустить юнит с другим именем

Для разовой мелочи cron по-прежнему быстрее.
Там, где нужны логи, лимиты ресурсов и порядок запуска, таймеры выигрывают.

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

💻 QoS-классы в Kubernetes: как определяется приоритет подов

Каждый под в кластере получает класс качества обслуживания — QoS class.
kubelet вычисляет его сам, исходя из того, как в поде описаны requests и limits.

QoS-класс влияет на приоритет вытеснения подов при нехватке памяти на ноде.

👑 Guaranteed

Самый высокий приоритет.

— У каждого контейнера в поде заданы requests и limits для CPU и памяти
— Для каждого ресурса requests равны limits
— Правило распространяется и на init-контейнеры

resources:
  requests:
    cpu: "1"
    memory: "1Gi"
  limits:
    cpu: "1"
    memory: "1Gi"

Такие поды вытесняются последними и получают oom_score_adj: -997 — ядро убивает их процессы в самую последнюю очередь.

Подходит для БД, брокеров очередей и всего, что нельзя терять при скачке нагрузки на соседей.

🥈 Burstable

Промежуточный класс.

Хотя бы у одного контейнера должен быть задан request или limit по CPU или памяти, но до критериев Guaranteed под не дотягивает.

resources:
  requests:
    cpu: "200m"
    memory: "256Mi"
  limits:
    memory: "1Gi"

Под может забирать ресурсы сверх requests, пока они свободны на ноде. Но при нехватке памяти он попадает под вытеснение раньше Guaranteed. Внутри класса порядок тоже не случайный: первыми уходят поды, которые потребляют больше, чем запросили.

Самый частый класс в реальных кластерах и разумный выбор по умолчанию для stateless-приложений.

🎭 BestEffort

Ни у одного контейнера в поде не указано ни одного request или limit.

# resources не задан вовсе

Такой под планируется куда угодно и потребляет всё, до чего дотянется. При нехватке памяти на ноде он уходит первым, а его oom_score_adj равен 1000 — максимальный приоритет для OOM Killer.

Годится для разовых задач, где потеря пода ничего не стоит, и категорически не годится для продакшн-сервисов.

➡️ Важные нюансы

— QoS-класс вычисляется один раз при создании пода и меняется только вместе с пересозданием
— Классы влияют на вытеснение по памяти; CPU при превышении лимита не убивает под, а троттлит его
— Guaranteed не защищает от аппаратного сбоя ноды и от вытеснения по нехватке места на диске
— Один контейнер без resources внутри многоконтейнерного пода опускает весь под до Burstable

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

📹 ВЕБИНАР: Аудит процессов обработки ПДн

📆 17 сентября в 11:00 по Мск встречаемся в эфире с Вероникой Нечаевой!

Разберём, как проверить реальные процессы обработки ПДн и сопоставить их с тем, что зафиксировано в документах.

Пройдём аудит по шагам:
🔵 как определить периметр и выбрать процессы для проверки;
🔵 как собирать достоверную информацию о фактической обработке ПДн;
🔵 как проследить движение данных между сотрудниками, ИТ-системами и подрядчиками;
🔵 как сопоставить фактическую обработку с политикой, уведомлением Роскомнадзора, согласиями и договорами;
🔵 как фиксировать расхождения и оценивать их значимость;
🔵 как понять, что можно проверить своими силами, а где уже нужна профильная экспертиза.

На примере одного процесса покажем, как проходит аудит и на какие детали обращает внимание эксперт при проверке.

☝️Отдельно обсудим, когда для ведения процессов достаточно внутренних ресурсов и Excel, а когда уже нужны специализированные инструменты.

P.S. 🎁 А еще Вероника расскажет, как получить доступ к записи вебинара «Модель угроз» ❤️

➡️ РЕГИСТРАЦИЯ

#вебинар

🔎 Зачем нужен аудит ПДн?

Даже выстроенный процесс со временем может накапливать ошибки и расхождения, которые не видны в повседневной работе.

Аудит помогает посмотреть на работу с ПДн целиком и понять:

🔵 где есть ошибки в документах;
🔵 какие требования выполняются не полностью;
🔵 где появляются риски;
🔵 что стоит исправить в первую очередь.

📹 А уже 17 сентября в 11:00 по Мск на вебинаре «Аудит процессов обработки ПДн» Вероника расскажет, как проводить такую проверку последовательно и на что смотреть в первую очередь.

📝 Чтобы попасть на эфир и получить запись — нужна регистрация по ссылке

P.S. 👆 В видео к посту рассказали, как регулярный аудит ПДн помогает вовремя находить нарушения и снижать риск штрафов Роскомнадзора.

P.P.S. 👇 Если вы ещё не были на вебинарах Вероники, загляните в записи прошлых эфиров — там много конкретики, практических примеров и понятных разборов без лишней теории, про работу с ПДн и не только.

YouTube
VK Видео
RuTube

#вебинар #видео

👩‍💻 Работа с ПДн это непрерывный процесс.

Компания меняется — появляются новые сервисы, подрядчики, процессы.

И эти изменения важно вовремя отражать в документах по ПДн.

👀 Собрали подборку из нашего блога для сверки:

— Согласия, уведомления, политики: вопрос-ответ по документам ПДн
— Вопросы про уведомления о персональных данных в РКН
— Персональные данные на сайте компании: главные правила
— Как провести аудит защиты персональных данных: пошаговая инструкция

📹 А уже завтра 17 сентября в 11:00 по Мск продолжим эту тему на вебинаре «Аудит процессов обработки ПДн».

🔴Разберём, как следить за реальными процессами обработки ПДн, сверять их с документами и вовремя замечать, что изменилось.
🔴Отдельно обсудим, когда достаточно внутренних ресурсов и Excel, а когда уже нужны специализированные инструменты и помощь эксперта.

👉 РЕГИСТРАЦИЯ

#вебинар

🛡 ДА! У НАС ЦЕЛАЯ ЧЕРЕДА ПОЛЕЗНЫХ ЭФИРОВ ПРО ИБ!

🎙 Уже 24 сентября Вероника Нечаева, выступит на IV ежегодной онлайн-конференции «IT. Право. Безопасность. Online 2026» с докладом «Практика законной обработки персональных данных в облаках».

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

Помимо персональных данных, эксперты обсудят актуальные вопросы ИБ, проверки Роскомнадзора, использование ИИ в IT-командах и другие темы на стыке технологий и права.

📅 24 сентября, начало конференции в 10:00 Мск.

💫 Участие бесплатное, необходима предварительная регистрация.

👉 ЗАРЕГИСТРИРОВАТЬСЯ

💻 kubectl diff: обработка изменений в CI/CD

kubectl diff сравнивает текущую конфигурацию объекта Kubernetes с предполагаемым результатом применения манифеста.

kubectl diff -f deployment.yaml

Команда использует server-side dry-run: учитываются серверная валидация, значения по умолчанию и совместимые admission-механизмы. Изменения в кластер не сохраняются.

💬 Результат выполнения команды отражается в коде завершения:

0 — различий нет;
1 — изменения обнаружены;
>1 — ошибка выполнения.

При использовании set -e код 1 может остановить пайплайн, хотя обнаружение изменений — штатный результат.

💬 Обработка в CI/CD:

rc=0
kubectl diff -f deployment.yaml || rc=$?

case $rc in
0) echo "Изменений нет" ;;
1) echo "Обнаружены изменения" ;;
*) echo "Ошибка kubectl diff"; exit "$rc" ;;
esac

Скрипт продолжает выполнение при обнаружении различий и останавливает пайплайн при ошибке.

kubectl diff не гарантирует успешного обновления приложения. Фактическое состояние проверяется отдельно после применения изменений.

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

😎 Когнитивная РАЗгрузка

За неделю с горящими дедлайнами, часовыми ВКС и постоянным переключением между задачами мозг получает почти космическую нагрузку 🗿

🕐 Разгрузить голову помогает простой принцип из GTD Дэвида Аллена: всё выписать и для каждой задачи определить следующий шаг.

💎 Правила простые:

— Выгрузить все открытые задачи в один список.
— Разделить их на три группы: сделать сегодня / зависит от других / можно перенести.
— Для каждой задачи на сегодня определить одно следующее действие.

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

📖 Как может выглядеть список:

Задача: подготовить коммерческое предложение.
Действие: открыть расчёт и проверить итоговую стоимость.

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

Задача: ответить клиенту по срокам.
Действие: уточнить дату у инженера.

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

И к выходным остаются силы на любимый сериальчик 🫰

#MentalDebug

🖥 РАЗНИЦА Block, File и Object Storage

🧑‍🎓Повторение — мать учения.

Для разных задач подходят разные типы хранения.
Важно видеть как организованы данные и как система должна к ним обращаться.

✅ Block Storage

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

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

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

✅ File Storage

Здесь данные уже организованы в привычную структуру файлов и каталогов.

Доступ обычно идёт по NFS или SMB. Одно хранилище при этом могут использовать несколько серверов или пользователей.

Типичные сценарии:
— общие сетевые папки;
— документы;
— медиаданные;
— рабочие каталоги.

✅ Object Storage

Данные хранятся как отдельные объекты вместе с метаданными. Доступ к ним обычно идёт через API.

Такой формат хорошо подходит для:
— резервных копий;
— архивов;
— логов;
— статических файлов;
— больших объёмов данных.

💬 Коротко:

Block➡️сервер получает диск
File➡️система работает с файлами и каталогами
Object➡️приложение работает с объектами через API

💬 На практике:

🟢нужен диск для ВМ или базы данных — используем Block Storage
🟢нескольким пользователям или серверам нужны одни и те же файлы — подойдёт File Storage
🟢нужно хранить бэкапы, архивы, логи или много файлов — в ход идёт Object Storage

При этом одна инфраструктура вполне может использовать все три варианта одновременно.

❗️Если хранилище выбирать без учёта нагрузки, способа доступа к данным и того, как с ними работает приложение, можно получить лишнюю задержку, неудобный доступ к данным, ограничения при масштабировании или просто переплачивать за характеристики, которые этой задаче не нужны.

#полезное

🖥 sed — потоковый редактор текста в Linux

🤓 Появился в Bell Labs в 1970-х и до сих пор используется для обработки текста из консоли и shell-скриптов.

sed читает входные данные построчно, применяет заданные команды и выводит результат. Исходный файл не меняется, если не используется -i.

✅ Синтаксис

sed [опции] 'адрес команда' файл

адрес определяет строки, к которым применяется команда. Без адреса обрабатываются все строки.

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

s — замена;
d — удаление;
p — печать;
a / i — добавление после или перед строкой.

Если файл не указан, sed читает stdin, поэтому его можно использовать в пайпах.

✅ Основные опции
-n — выводить только то, что явно запрошено через p
-i — правка на месте; -i.bak сохраняет резервную копию
-E — расширенные регулярные выражения
-e — несколько команд за один вызов

Адресом может быть номер строки, диапазон 10,20, последняя строка $ или регулярное выражение
/error/.

✅ Замена всех вхождений

sed 's/http:/https:/g' config.yaml

— url: http://api.local → url: https://api.local

Флаг g заменяет все совпадения в строке. Без него — только первое. Без -i результат выводится в консоль, а исходный файл остаётся без изменений.

Конфиг без пустых строк и полнострочных комментариев:

sed -E '/^\s*(#|$)/d' /etc/nginx/nginx.conf

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

👀 sed подходит для замен по шаблону, фильтрации конфигов и обработки текстового вывода в shell-скриптах и CI-пайплайнах. Для работы с колонками, полями и вычислениями чаще используется awk.

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

💻Практический вебинар «СТРАТЕГИЯ РЕЗЕРВНОГО КОПИРОВАНИЯ»

📹 15 октября в 11:00 Мск за 90 минут на практике построим реальную стратегию и разберём:

🔹 как определить RPO и RTO для критичных сервисов;
🔹 как защитить бэкапы от шифровальщика;
🔹 как учесть зависимости систем и ресурсы для восстановления;
🔹 как каналы связи влияют на скорость бэкапа и восстановления;
🔹 когда достаточно обычных бэкапов, а когда нужны репликация, Hardened Repository и DRaaS;
🔹 как подготовить план аварийного восстановления и протестировать его.

🧑‍💻 Каждый участник выберет свой критичный сервис и проработает его

🎁 Всем прошедшим практикум передадим методику и пакет документов для реализации стратегии резервного копирования и восстановления:
— Матрица систем и зависимостей
— Таблица определения и согласования RPO / RTO
— Технический runbook аварийного восстановления
— Отчёт о тестовом восстановлении ИТ-сервиса
— Карта готовности одного критичного сервиса к восстановлению
— Рабочая тетрадь «Стратегия восстановления данных и ИТ-сервисов»

👉 Приходите, будет полезно. Регистрация тут

🏪 Сколько времени нужно, чтобы вернуть бизнес к работе?

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

Поэтому важно заранее учесть все этапы восстановления и проверить в реальной работе.

🎬Ссылки на полное видео👇

YouTube | RuTube | VK Видео

➡️ Подборка статей:

• Иллюзия безопасности: почему бэкапы не спасают бизнес
• Как мы объединили ключевые ЦОДы Новосибирска в кольцо 400 Гбит/с
• Как избежать потерь: стратегии Disaster Recovery для бизнеса
• Как настроить резервное копирование и работать без перебоев

📣 Для тех, кто хочет глубже погрузиться в тему, мы подготовили практический вебинар «СТРАТЕГИЯ РЕЗЕРВНОГО КОПИРОВАНИЯ»

— разберём, как выстроить стратегию резервного копирования и восстановления;
— определим RPO/RTO с учетом зависимостей между системами;
— проверим готовность сервисов к сбоям и составим план восстановления.

🗓 Старт 15 октября в 11:00 МСК.

P. S. Каждому участнику передадим методику и пакет документов для реализации стратегии резервного копирования и восстановления.

➡️ Зарегистрироваться