🤔 Как выбрать ИТ-инфраструктуру: сервер, облако или гибридная модель

🔥 ТОП полезных статей

— 99,9% времени без перебоев. Как обеспечить надёжную работу IT-систем и не разориться

— Пять признаков, что вашей ИТ-инфраструктуре пора в облако

— Публичное, частное, гибридное облако — в чем разница и какое подходит бизнесу?

— Частное облако за 10 минут — что такое Private Cloud и как оно работает

— Облако или свой сервер — где лучше спрятать чувствительные данные

— 5 типичных ошибок при переходе на облачную инфраструктуру и как их избежать

— Конец эпохи VMware: как российскому бизнесу избежать штрафов и простоев

— Как VDI решает проблему с нехваткой кадров в инженерных компаниях

#полезное

💻 Kube-proxy — компонент kubernetes, работающий на каждой ноде кластера.

Он отвечает за реализацию сервисов (Service) и обеспечивает перенаправление трафика на поды.

➡️ Основные задачи

— Обеспечивает работу сервисов типов ClusterIP, NodePort, LoadBalancer
— Преобразует виртуальный IP сервиса в IP-адреса целевых подов
— Выполняет балансировку нагрузки на уровне L4 (TCP/UDP/SCTP)
— Отслеживает изменения сервисов и эндпоинтов через Kubernetes API

➡️ Принцип работы

Kube-proxy следит за API-сервером. При создании, удалении или изменении сервиса он обновляет правила маршрутизации на ноде. Трафик, приходящий на IP сервиса, перенаправляется на один из подов согласно настроенному режиму.

➡️ Режимы работы

🔵 iptables (режим по умолчанию)
— Генерирует цепочки правил в iptables
— Пакеты перенаправляются напрямую на поды без дополнительных переходов
— Балансировка реализована через случайный выбор правила
— Подходит для большинства кластеров среднего размера

🔵 ipvs (рекомендуется для крупных кластеров)
— Использует встроенный балансировщик ядра Linux IPVS
— Выдерживает десятки тысяч сервисов без деградации
— Обеспечивает session affinity (persistence) на уровне ядра

🔵 userspace (устаревший)
— Прокси работает в пространстве пользователя
— Каждое соединение проходит через kube-proxy
— Используется только в legacy-кластерах

🔵 Ключевые особенности
— Работает независимо от container runtime (containerd, CRI-O)
— Запускается на каждой ноде как DaemonSet (или системный сервис)
— Взаимодействует только с сетевым стеком ноды, не влияет на сами поды
— Обновления правил применяются атомарно, без прерывания существующих соединений

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

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

🐙 Kube-router объединяет функции CNI, kube-proxy и контроллера сетевых политик в одном агенте, работающем на каждой ноде.

Это упрощает сетевую архитектуру кластера и повышает производительность за счёт прямого взаимодействия с ядром Linux через BGP и iptables/ipvs.

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

— CNI (Container Network Interface) — назначает подам IP-адреса из указанного пула, настраивает маршрутизацию между нодами.
— Замена kube-proxy — обеспечивает реализацию сервисов (ClusterIP, NodePort, LoadBalancer) через iptables или ipvs с возможностью session affinity.
— Сетевые политики — реализует NetworkPolicy (L3/L4) с помощью iptables, не требуя дополнительных контроллеров.
— BGP-маршрутизация — анонсирует IP-адреса подов и сервисов в сеть дата-центра, позволяя внешним маршрутизаторам напрямую направлять трафик на ноды (без наложения overlay).

➡️ Ключевые особенности:

— Единый агент — один процесс вместо трёх (CNI, kube-proxy, network policy controller), снижающий потребление ресурсов и сложность эксплуатации.
— Гибкая конфигурация — выбор режима работы: только CNI, только kube-proxy, только политики или всё вместе.
— Высокая производительность — работает напрямую с iptables/ipvs и BGP без промежуточных прослоек.
— Поддержка IPv6 и dual-stack.

Kube-router особенно полезен в сценариях, где нужна простота (замена нескольких компонентов одним), интеграция с существующей BGP-инфраструктурой или работа в bare-metal окружениях без overlay.

👉 Git
#полезное

Systemd-journald — компонент, который пришёл на смену традиционной syslog. Он собирает сообщения от ядра, служб, пользовательских процессов и хранит их в структурированном бинарном формате с индексацией, в система с systemd

💬 Основные команды journalctl

✅ Просмотр логов

journalctl                     # все логи
journalctl -u nginx            # логи конкретной службы
journalctl -u nginx -u sshd    # нескольких служб

✅ Фильтрация по времени

journalctl --since "2026-03-26 08:00:00"
journalctl --since "1 hour ago"
journalctl --since yesterday --until now

✅ Фильтрация по приоритету

journalctl -p err              # ошибки и выше (0-3)
journalctl -p warning          # предупреждения и выше

✅ Логи загрузки

journalctl -b                  # текущая загрузка
journalctl -b -1               # предыдущая загрузка
journalctl --list-boots        # список всех загрузок

💬 Диагностика и очистка

journalctl --disk-usage          # занимаемое место
sudo journalctl --rotate         # принудительная ротация
sudo journalctl --vacuum-size=1G # оставить 1 ГБ
sudo journalctl --vacuum-time=2d # логи не старше 2 дней

journald даёт быстрый доступ к логам через единый интерфейс с удобной фильтрацией — без необходимости парсить текстовые файлы.

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

🤑 Сколько денег теряет бизнес за один час простоя ?

Во многих компаниях настроены бэкапы, согласованны RTO и RPO и даже есть план аварийного восстановления.

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

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

#статья

📝 Шпаргалка по балансировке трафика между серверами.

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

🔫 Алгоритмы балансировки

— Round Robin
Запросы отправляются по очереди на разные серверы. Подходит, если узлы одинаковые по мощности, а нагрузка примерно равномерная.

— Weighted Round Robin
Похож на Round Robin, но с учётом веса сервера. Более мощные узлы получают больше запросов, слабые — меньше.

— Least Connections
Новый запрос идёт на сервер с наименьшим числом активных соединений. Полезно, когда нагрузка неравномерная и запросы живут разное время.

— Least Response Time
Трафик направляется туда, где сервер отвечает быстрее. Помогает распределять нагрузку с учётом текущего состояния системы, а не только количества соединений.

— IP Hash
Запросы от одного и того же клиента направляются на один и тот же сервер. Удобно, если важна привязка к сессии.

🔫 Как понять, что балансировка работает нормально
Важно смотреть, как система ведёт себя под нагрузкой.

Для этого обычно ориентируются на следующие метрики:
➡️задержка;
➡️время ответа;
➡️количество активных соединений;
➡️число запросов на сервер;
➡️ошибки 5xx;
➡️процент недоступных бэкендов.

#полезное

💿 С Днем резервного копирования, друзья!

🔥 ТОП полезных статей

— Как настроить резервное копирование и работать без перебоев

— Иллюзия безопасности: почему бэкапы не спасают бизнес

— Сколько стоит час простоя: строим стратегию восстановления данных

— Как избежать потерь: стратегии Disaster Recovery для бизнеса

— Репликация данных в различных СУБД

— Бэкап (backup): как сделать резервное копирование надёжным

— Опыт организации резервного ЦОД для непрерывной работы критичных сервисов

#полезное

⬇️ Замена kube-proxy с помощью CNI Cilium (kube-proxy replacement)

kube-proxy — компонент Kubernetes, который на каждой ноде реализует сервисы (Service), балансировку нагрузки и перенаправление трафика на поды через режимы iptables, ipvs или userspace.

Cilium — мощный CNI-плагин на базе eBPF и его Network Policies для L3/L4/L7-фильтрации.

🧑‍💻 Соединим их вместе

Cilium способен полностью заменить kube-proxy, взяв на себя всю обработку Kubernetes-сервисов (ClusterIP, NodePort, LoadBalancer, externalIPs, hostPort) напрямую в ядре Linux.

🤓 Как это работает под капотом

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

— Вместо генерации тысяч правил в iptables (линейный просмотр) или даже IPVS Cilium хранит маппинги сервисов и эндпоинтов в BPF hash-таблицах;
— При создании/изменении Service Cilium-агент обновляет BPF-мапы. Трафик к ClusterIP мгновенно транслируется в IP пода с балансировкой.
— Direct Server Return (DSR) для снижения latency (ответы идут напрямую от пода к клиенту, минуя лишние хопы)

🙂 Преимущества замены

✔️ Производительность — ниже latency, выше пропускная способность, значительно меньше потребление CPU (в крупных кластерах экономия 25–40 % на сетевой обработке). Не деградирует при росте количества сервисов.
✔️ Масштабируемость — тысячи сервисов без проблем с длинными цепочками правил.
✔️ Упрощение стека — можно полностью удалить kube-proxy (или не устанавливать его при развертывании кластера). Меньше компонентов — проще отладка и меньше точек отказа.
✔️ Интеграция с возможностями Cilium — политики безопасности, Hubble-мониторинг и L7-фильтрация работают в едином eBPF-пространстве.

Это особенно выгодно в production-кластерах с высокой сетевой нагрузкой или большим количеством микросервисов.

Как включить kube-proxy replacement

При установке Cilium через Helm:

kubeProxyReplacement: true
k8sServiceHost: <IP API-сервера>
k8sServicePort: <порт API-сервера>
# Дополнительно для полного функционала:
nodePort:
  enabled: true
externalIPs:
  enabled: true
hostPort:
  enabled: true
bpf:
  masquerade: true

Замена kube-proxy на eBPF-реализацию в Cilium — это логичный шаг для тех, кто уже использует Cilium как CNI. Кластер становится быстрее, проще и современнее: меньше оверхеда, лучше наблюдаемость и единый механизм для сети и безопасности.

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

🖥 Rsync — утилита для быстрого инкрементального копирования и синхронизации данных.

🟢 Главный плюс: передаются только изменившиеся части файлов, а не целиком. Это экономит трафик и время.

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

— Разбивает файлы на блоки фиксированного размера.
— Вычисляет контрольные суммы (rolling checksum + хэш).
— Сравнивает блоки источника и назначения.
— Передаёт только отличающиеся блоки.
— Работает локально, через SSH или собственный rsync-демон.

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

rsync [параметры] источник назначение

💬 Основные параметры

— -a — архивный режим: сохраняет права, симлинки, таймстампы, рекурсивность. Почти всегда нужен.
— -v — подробный вывод (verbose): показывает, какие файлы копируются.
— -z — сжатие при передаче (полезно по медленным каналам).
— -h — человеко-читаемые размеры (K, M, G).
— -P — комбинация --partial (докачка) и --progress (прогресс-бар).
— --delete — удаляет файлы в назначении, которых нет в источнике. Делает синхронизацию зеркалом.
— -n / --dry-run — тестовый прогон: показывает, что будет сделано, без реальных изменений.
— --exclude — исключает файлы/папки по шаблону (можно несколько).
— -e — указывает удалённую оболочку, например -e ssh.

💬 Примеры

Локальное копирование папки

rsync -avh /home/user/data/ /backup/data/

Отправка на удалённый сервер (push)

rsync -avz -e ssh /local/folder/ user@server:/remote/folder/

Загрузка с сервера (pull)

rsync -avz -e ssh user@server:/remote/folder/ /local/folder/

Тестовый прогон зеркалирование с удалением лишнего

rsync -avn --delete /source/ /dest/

Rsync — незаменимый инструмент в арсенале любого администратора. Быстрый, надёжный, работает везде, где есть Linux (и не только).

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

💸 Почему ИТ- департамент не получает бюджет?

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

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

📰 В новом материале разобрали, как связать SLA, RTO, RPO и TCO в одну систему аргументов для бизнеса, почему считать нужно не только инфраструктуру, но и стоимость риска, и какие метрики помогают ДИТу говорить с руководством на одном языке и обосновывать вложения.

#статья

💬 6 принципов отказоустойчивой системы

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

✅ Replication
— создание нескольких копий данных или сервисов.

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

✅ Redundancy
— резервирование критичных компонентов.

У важных узлов должен быть запасной вариант. Иначе один отказ может стать причиной остановки всей системы.

✅ Load Balancing
— распределение нагрузки между несколькими серверами.

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

✅ Failover
— автоматическое переключение на резервный компонент при сбое основного.

При сбое основного узла резервный вступает в дело без ручного вмешательства.

✅ Graceful Degradation
— сохранение основной функции системы при частичном отказе.

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

✅ Monitoring and Alerting
— постоянный контроль за состоянием системы и уведомления о проблемах.

Помогает быстро замечать сбои, перегрузки и деградацию, чтобы реагировать до серьёзного инцидента.

#полезное

⚠️ DDoS 2026

И снова в центре внимания новости про DDoS-инциденты.

Если раньше атака часто сводилась к объёму мусорного трафика, то сейчас всё чаще используются многоуровневые сценарии: комбинации разных векторов, имитация поведения реальных пользователей, атаки на API, точечная перегрузка отдельных сервисов.

Поэтому DDoS всё сложнее распознать сразу.
Проблема становится заметной уже на этапе деградации сервиса: замедляется работа сайта, растёт нагрузка на приложения, пользователи сталкиваются с отказами.

➡️ Этапы атаки

сначала — анализ инфраструктуры и разведка,
затем — многоуровневая атака: на приложения (L7), API и одновременно на сетевой уровень (L3/L4).

В результате страдает не только доступность ресурса, но и устойчивость всей ИТ-среды.
Для бизнеса это означает простой, потерю обращений, рост нагрузки на команды эксплуатации и ИБ.

➡️ Какая защита нужна

Для защиты требуется выстроенная схема фильтрации трафика, которая включает несколько уровней:

— очистку трафика до его попадания в инфраструктуру;
— сокрытие реального IP-адреса ресурса;
— анализ штатного поведения сервиса;
— автоматическое выявление аномалий;
— пропуск к ресурсу только легитимного трафика.

Такой подход позволяет снижать нагрузку на инфраструктуру и поддерживать доступность сервисов даже при сложных сценариях атак.

При выборе защиты важно, чтобы решение работало не только против объёмных атак, но и против более сложных сценариев: на уровне приложений, API и пользовательских сессий.

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

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

#проИБ

💻 kube-apiserver: мозг и шлюз Kubernetes-кластера

В Kubernetes всё крутится вокруг API.
Центральный компонент control plane, с которым общаются все остальные — kubectl, kubelet, scheduler, контроллеры и внешние системы — это kube-apiserver.

👀 Что он делает?

— Единая точка входа
Все операции (создание, чтение, обновление, удаление ресурсов) проходят через API-сервер. Другие компоненты не общаются друг с другом напрямую.

— Аутентификация и авторизация
Проверяет, кто делает запрос (сертификат, токен, OIDC) и имеет ли он права.

— Валидация и мутация
При создании или изменении ресурса API-сервер проверяет корректность манифеста и может изменять его через admission webhooks.

— Хранение состояния
Единственный компонент, который общается с etcd — распределённым хранилищем кластера. API-сервер кэширует данные и обеспечивает согласованность.

— Механизм watch
Клиенты могут подписаться на изменения ресурсов через long polling. Это позволяет мгновенно реагировать на события без постоянных опросов.

⚙️ Как это работает?

➡️ Пользователь выполняет kubectl create deployment nginx --image=nginx
➡️ kubectl преобразует команду в HTTP-запрос (JSON) и отправляет его на kube-apiserver.
➡️ API-сервер аутентифицирует пользователя (например, по сертификату из kubeconfig).
➡️ Проверяет права через RBAC: есть ли разрешение на создание deployment в указанном namespace.
➡️ Запускается цепочка admission controllers: валидация (нет ли синтаксических ошибок), мутация (применяются политики по умолчанию).
➡️ API-сервер сериализует объект в Protobuf/JSON и записывает в etcd.
➡️ Возвращает клиенту успешный ответ.
➡️ Событие о создании deployment’а через watch-механизм получает kube-controller-manager, который создаёт ReplicaSet, а тот — поды. Scheduler назначает поды на ноды, а kubelet их запускает.

Пример

kubectl get pods -v=8

В выводе будут видны HTTP-запросы к /api/v1/namespaces/default/pods. API-сервер аутентифицирует запрос, проверяет RBAC, затем загружает данные из etcd (или из своего cache), сериализует в JSON и возвращает.

kube-apiserver — это не просто «REST API».
Это центральная нервная система Kubernetes, которая совмещает роль шлюза, диспетчера, хранителя состояния и механизма оповещений.

Понимание его работы помогает диагностировать 80% проблем с кластером: от отказа в доступе до зависших ресурсов.

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

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

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

Iperf работает по схеме «клиент–сервер»:

— На одной стороне запускается сервер (ждёт подключения)
— На другой — клиент (генерирует трафик и меряет скорость)
— Умеет работать по TCP (показывает максимальную полосу с учётом окон и потерь) и по UDP (показывает потери, джиттер, скорость)

После теста выдаёт отчёт: пропускную способность в Mbit/Gbit, объём данных, а для UDP — сколько пакетов потеряно.

💬 Основные аргументы iperf3

🔵 Клиентский режим и серверный:
— -s — запустить в режиме сервера
— -c <адрес> — режим клиента, подключиться к серверу

🔵 Параметры теста:
— -p <порт> — порт (по умолчанию 5201)
— -t <сек> — длительность теста (по умолчанию 10 секунд)
— -i <сек> — интервал вывода промежуточных результатов
— -P <n> — количество параллельных TCP-потоков (нагружает сильнее)

🔵 Полезные опции:
— -R — reverse mode: клиент принимает, сервер отправляет (проверяет обратный канал)
— -f <k/m/g> — формат вывода (Kbits, Mbits, Gbits)
— -J — вывод в JSON (для скриптов и автоматизации)

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

Базовый TCP-тест

Сервер:

iperf3 -s

Клиент:

iperf3 -c 192.168.1.10

Через 10 секунд появиться что-то вроде 940 Mbits/sec — это реальная пропускная способность гигабитной сети.

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

⚖️ Законы для ИТ

📃 Для КИИ опубликован закон о штрафах за нарушение требований.
Вступает в силу 20 апреля 2026 года и вводит отдельную ответственность за несоблюдение правил работы с критической информационной инфраструктурой.

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

📃 Для ИИ всё заметнее формируется отдельный регуляторный трек. Обсуждаются правила применения, распределение ответственности и общие требования к использованию таких систем.

📃 10 апреля 2026 года подписано распоряжение о продолжении федерального финансирования информатизации региональных систем здравоохранения. Это сохраняет спрос на государственные цифровые контуры, интеграции и сопровождение медсистем.

#ИТиЗАКОН

🧬 Каналы по 100 Гбит/с между ЦОДами в Новосибирске

Для регионального ИТ-рынка это важный шаг: отдельные площадки начинают работать как единая инфраструктурная среда.

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

Это основа для резервирования, переноса данных и стабильной работы ИТ-систем без лишних ограничений.

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

📇 Инфраструктура под ПДн: с чего начать

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

Неважно, где размещены системы: в собственном контуре, в ЦОДе или в облаке.
У многих возникает одна и та же проблема: инфраструктура выбрана, договор подписан, данные размещены — а где проходят границы ответственности и какие требования нужно закрывать именно со своей стороны, понимают не до конца.

В вебинаре разбираем:
— что считается ЦОДом по 152-ФЗ;
— чем отличается собственная и сторонняя инфраструктура;
— что должно быть в договоре с провайдером;
— как распределяется ответственность между оператором и поставщиком услуг;
— какие ошибки чаще всего допускают при проектировании защиты ПДн.

Смотреть на любых удобных площадках:
▶️ Rutube
▶️ YouTube
▶️ VK Видео

#полезное

💠 Taints и Tolerations в Kubernetes: отсекаем лишних, пропускаем своих

🟣Taint — это метка на ноде, которая сразу отсекает неподходящие поды при планировании.

Формат taint: key=value:effect

Навесить taint на ноду

kubectl taint nodes node1 gpu=true:NoSchedule

Снять taint (добавить - в конец):

kubectl taint nodes node1 gpu=true:NoSchedule-

Три эффекта (effect)

— NoSchedule — планировщик не будет размещать новые поды без нужного toleration. Уже запущенные поды остаются.

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

— NoExecute — самый жёсткий: новые поды не планируются, а уже запущенные без toleration вытесняются с ноды.

🟣 Toleration — это правило в манифесте пода, которое разрешает ему размещаться на нодах с определённым taint.

Важно понимать: toleration не гарантирует, что под попадёт именно на эту ноду — он лишь снимает запрет.

Чтобы направить под на конкретную ноду, нужен nodeSelector или nodeAffinity.

apiVersion: v1
kind: Pod
metadata:
  name: gpu-app
spec:
  tolerations:
  - key: "gpu"
    operator: "Equal"
    value: "true"
    effect: "NoSchedule"
  containers:
  - name: app
    image: nvidia/cuda:12.0-base

Equal — ключ и значение должны совпасть.
Exists — достаточно наличия ключа, значение не проверяется. Удобно, когда нужно допустить под на ноды с любым значением ключа:

tolerations:
- key: "gpu"
  operator: "Exists"
  effect: "NoSchedule"

Если не указать key совсем — toleration сработает для любого taint на ноде.

Проверить taints на ноде

kubectl describe node node1 | grep Taints

Taints и Tolerations — это способ жёстко сегментировать кластер: выделить ноды под GPU, CI-воркеры, stateful-нагрузки или вообще зарезервировать их для конкретной команды. В паре с nodeAffinity получаем полный контроль над тем, где именно запускаются поды.

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

👩‍💻 Tmux — несколько терминальных сессий в одном окне

Tmux (Terminal multiplexer) — позволяет создавать несколько независимых терминальных сессий внутри одного подключения, разбивать экран на панели и — самое главное — отключаться от сессии, не прерывая запущенные в ней процессы.

Незаменим при работе по SSH: упал коннект — процессы продолжают работать, переподключился — всё на месте.

➡️ Основные концепции

— Session — независимая рабочая сессия. Живёт на сервере даже после отключения клиента.
— Window — вкладка внутри сессии. Аналог вкладки в браузере.
— Pane — панель внутри окна. Окно можно разбить на несколько панелей.

Все команды в tmux начинаются с префикса Ctrl+B (по умолчанию).

➡️ Работа с сессиями

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

# Создать сессию с именем
tmux new -s work

# Показать список сессий
tmux ls

# Подключиться к последней сессии
tmux attach

# Подключиться к конкретной сессии по имени
tmux attach -t work

# Переименовать сессию
tmux rename-session -t work devops

# Завершить сессию
tmux kill-session -t work

Отключиться от сессии (не завершая): Ctrl+B, затем D (detach)

➡️ Работа с окнами

Все комбинации после нажатия Ctrl+B:
c — создать новое окно
, — переименовать текущее окно
n — следующее окно
p — предыдущее окно
0-9 — переключиться на окно по номеру
& — закрыть текущее окно
w — список окон с предпросмотром

➡️ Работа с панелями

Разбить экран на панели — удобно для одновременного просмотра логов и выполнения команд:

% — разбить вертикально (left | right)
" — разбить горизонтально (top / bottom)
←→↑↓ — переключаться между панелями
x — закрыть текущую панель
z — развернуть панель на весь экран / свернуть обратно
{ — переместить панель влево
} — переместить панель вправо

Tmux решает главную боль работы по SSH: потерял соединение — потерял всё. С ним процессы живут независимо от терминала, а рабочее пространство можно разбить под любую задачу — логи, мониторинг, деплой — всё в одном окне.

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

🔒 Базовые технические меры защиты ПДн

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

Поговорили про:
— почему происходят утечки персональных данных;
— что делать с доступами после увольнения;
— чем опасны выгрузки из CRM и 1С;
— как проверять, работают ли бэкапы;
— что можно сделать для защиты данных без больших затрат.

Смотрите подкаст на наших площадках
▶️ YouTube
▶️ VK Видео
▶️ Rutube

#проИБ #инфобез

😵 Тупик масштабирования

❎Кластер виртуализации работает под полной нагрузкой.
❎Запаса вычислительных ресурсов нет.
❎Резерва под N+1 и плановые работы тоже нет.
❎Расширение нужно провести без остановки бизнес-сервисов, но любое изменение в текущей конфигурации повышает риск инцидента.

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

#статья