Утренний чекап инфраструктуры
Каждое утро начинается с одного вопроса: что упало за ночь, но не сообщило об этом? Silent failure — не экзотика, это норма в любом кластере старше трёх месяцев. Нода отвечает на ping, но не принимает workload. WireGuard туннель поднят, но трафик не идёт. Сервис в статусе Running, но лишь потому что readiness probe настроена неправильно.
Проверка начинается не с дашборда. Дашборд показывает то, что ты решил показать. Начинается с сырого вывода: kubectl get nodes, wg show all, journalctl -p err -n 50. Если за ночь в логах есть OOMKilled или CrashLoopBackOff — значит мониторинг не донёс, а не значит, что проблем не было.
Mesh-туннели проверяются отдельно. latest handshake старше пяти минут — туннель мёртв, даже если endpoint доступен. Проверяй не статус интерфейса, а время последнего handshake по каждому peer. Это единственный честный индикатор.
Zero silent failures достигается только одним способом: активным опросом, а не пассивным ожиданием алертов. Cron раз в пять минут, который пишет состояние в файл и сравнивает с предыдущим. Diff нашёл расхождение — уже тревога. Нет diff — нет новостей.
Документируй утренний чекап как runbook. Через месяц он станет автоматическим скриптом, ещё через месяц — частью CI/CD пайплайна здоровья кластера.
#ftops #devops #linux #freebsd #sre #инфраструктура
Каждое утро начинается с одного вопроса: что упало за ночь, но не сообщило об этом? Silent failure — не экзотика, это норма в любом кластере старше трёх месяцев. Нода отвечает на ping, но не принимает workload. WireGuard туннель поднят, но трафик не идёт. Сервис в статусе Running, но лишь потому что readiness probe настроена неправильно.
Проверка начинается не с дашборда. Дашборд показывает то, что ты решил показать. Начинается с сырого вывода: kubectl get nodes, wg show all, journalctl -p err -n 50. Если за ночь в логах есть OOMKilled или CrashLoopBackOff — значит мониторинг не донёс, а не значит, что проблем не было.
Mesh-туннели проверяются отдельно. latest handshake старше пяти минут — туннель мёртв, даже если endpoint доступен. Проверяй не статус интерфейса, а время последнего handshake по каждому peer. Это единственный честный индикатор.
Zero silent failures достигается только одним способом: активным опросом, а не пассивным ожиданием алертов. Cron раз в пять минут, который пишет состояние в файл и сравнивает с предыдущим. Diff нашёл расхождение — уже тревога. Нет diff — нет новостей.
Документируй утренний чекап как runbook. Через месяц он станет автоматическим скриптом, ещё через месяц — частью CI/CD пайплайна здоровья кластера.
#ftops #devops #linux #freebsd #sre #инфраструктура
DiskPressure на малых VPS почти всегда выглядит внезапно, но причина обычно копилась неделями: старые образы, раздутый containerd.log, забытый /swapfile при zram, ротированные логи и мусор от диагностических pod’ов.
Практический минимум для узлов с диском 15-20 ГБ:
- следить за imagefs/nodefs отдельно;
- держать containerd.log под лимитом и ротацией;
- сжимать старые /var/log/messages-* через gzip -9;
- удалять completed/evicted/test/diag pod-артефакты старше 24 часов;
- не оставлять /swapfile, если фактически работает zram.
Kubelet ImageGC не должен быть первой линией обороны. Его пороги, например imageGCHighThresholdPercent, это аварийный механизм, а не замена регулярной уборки. Если ImageGC уже ругается FreeDiskSpaceFailed, вы опоздали: узел близко к DiskPressure, eviction и каскадным проблемам с workload’ами.
Нормальная практика: systemd timer для очистки, алерт на рост логов, отдельная проверка containerd, kubelet и свободного места после каждого обслуживания. Больше полевых чеклистов по K3s, mesh и эксплуатации bare-metal Linux: https://ftops.space
Практический минимум для узлов с диском 15-20 ГБ:
- следить за imagefs/nodefs отдельно;
- держать containerd.log под лимитом и ротацией;
- сжимать старые /var/log/messages-* через gzip -9;
- удалять completed/evicted/test/diag pod-артефакты старше 24 часов;
- не оставлять /swapfile, если фактически работает zram.
Kubelet ImageGC не должен быть первой линией обороны. Его пороги, например imageGCHighThresholdPercent, это аварийный механизм, а не замена регулярной уборки. Если ImageGC уже ругается FreeDiskSpaceFailed, вы опоздали: узел близко к DiskPressure, eviction и каскадным проблемам с workload’ами.
Нормальная практика: systemd timer для очистки, алерт на рост логов, отдельная проверка containerd, kubelet и свободного места после каждого обслуживания. Больше полевых чеклистов по K3s, mesh и эксплуатации bare-metal Linux: https://ftops.space
Bare-metal K3s дешевле hyperscaler не потому, что серверы магически бесплатные. Он дешевле там, где команда умеет считать полную стоимость отказоустойчивости: железо, каналы, IP-план, WireGuard mesh, резервное питание, мониторинг, регламенты восстановления и время инженеров. В hyperscaler вы быстро покупаете managed control plane, балансировщики, диски, snapshots, NAT, egress, резервные зоны. Это удобно, но каждая галочка превращается в регулярный платеж. Особенно больно становятся видны: - egress и межзональный трафик; - managed LB и public IP; - premium storage; - дублирование окружений под DR; - overprovisioning ради SLA. Bare-metal K3s требует другой зрелости. Нужны минимум: etcd snapshots по расписанию, проверенный restore, WireGuard mesh между площадками, отдельные роли для системных сервисов, RBAC без wildcard-админства, тесты потери ноды, тесты потери канала, понятный runbook для дежурного. Без этого bare-metal превращается не в экономию, а в технический долг на стойке. Моя позиция простая: hyperscaler хорош для скорости старта и переменной нагрузки. Bare-metal K3s выигрывает, когда нагрузка стабильна, трафик дорогой, требования к контролю высокие, а команда готова жить по инженерным регламентам. Чеклист подхода собираю на https://ftops.space
Bare-metal K3s часто сравнивают с hyperscaler по цене CPU, RAM и диска. Это ошибка. Реальная экономика отказоустойчивости начинается не с прайса, а с вопроса: кто отвечает за сеть, quorum, бэкапы, восстановление, RBAC и регламент аварийных работ. В hyperscaler вы платите за готовые managed-слои: control plane, storage primitives, LB, IAM, snapshots, мониторинг. На bare-metal это не исчезает. Просто счет приходит в другом виде: инженеры, стенды, тесты восстановления, документация, запас железа, out-of-band доступ, WireGuard mesh, маршрутизация, firewall policy, регулярные DR-учения. Практический минимум для bare-metal K3s: 3 control-plane узла, отдельная стратегия etcd snapshots, проверенное восстановление кластера, независимый канал доступа, регламент обновлений, ограниченный RBAC, мониторинг SLO, инвентаризация секретов, понятная схема L4/L7 ingress и план деградации при потере площадки. Вывод простой: bare-metal выигрывает, когда нагрузка стабильная, команда зрелая, а инфраструктура управляется как инженерная система. Hyperscaler выигрывает, когда скорость изменений и цена ошибки выше стоимости аренды. Чеклисты и практические разборы собираю на https://ftops.space.
eBPF и XDP: когда ядро становится маршрутизатором
eBPF позволяет выполнять пользовательский код прямо в ядре без модулей. XDP (eXpress Data Path) подключается к драйверу сетевой карты до того, как пакет попадает в сетевой стек — это означает обработку на скоростях 10-100 Гбит/с с latency в единицы микросекунд. Никакого копирования в userspace, никакого прохода через netfilter.
TCP BBR vs CUBIC: вопрос не в том, кто быстрее. CUBIC реагирует на потери пакетов как на сигнал перегрузки. BBR строит модель пропускной способности канала и доставляет данные по реальной физической скорости, а не по угадыванию. На WAN-каналах с буферизацией (bufferbloat) BBR выигрывает в разы. Включить: net.ipv4.tcpcongestioncontrol=bbr + net.core.defaultqdisc=fq.
sysctl для нагруженного шлюза — это не магия, это физика:
- net.core.rmemmax / wmemmax: 134217728 (128 МБ)
- net.ipv4.tcprmem / tcpwmem: 4096 87380 134217728
- net.core.netdevmaxbacklog: 300000
- net.ipv4.tcpmaxsynbacklog: 65536
- net.core.somaxconn: 65535
Pro tip по ethtool: если переключаешь offload-параметры (GSO, GRO, TSO) на горячем интерфейсе — драйвер может сбросить линк. Особенно на Mellanox/Broadcom при включении rx-vlan-offload. Делай это в maintenance-окне или убедись, что есть OOB-доступ. ethtool -K eth0 gro off на продакшне без консоли — это билет в ночную смену.
#ftops #devops #linux #freebsd #sre #инфраструктура
eBPF позволяет выполнять пользовательский код прямо в ядре без модулей. XDP (eXpress Data Path) подключается к драйверу сетевой карты до того, как пакет попадает в сетевой стек — это означает обработку на скоростях 10-100 Гбит/с с latency в единицы микросекунд. Никакого копирования в userspace, никакого прохода через netfilter.
TCP BBR vs CUBIC: вопрос не в том, кто быстрее. CUBIC реагирует на потери пакетов как на сигнал перегрузки. BBR строит модель пропускной способности канала и доставляет данные по реальной физической скорости, а не по угадыванию. На WAN-каналах с буферизацией (bufferbloat) BBR выигрывает в разы. Включить: net.ipv4.tcpcongestioncontrol=bbr + net.core.defaultqdisc=fq.
sysctl для нагруженного шлюза — это не магия, это физика:
- net.core.rmemmax / wmemmax: 134217728 (128 МБ)
- net.ipv4.tcprmem / tcpwmem: 4096 87380 134217728
- net.core.netdevmaxbacklog: 300000
- net.ipv4.tcpmaxsynbacklog: 65536
- net.core.somaxconn: 65535
Pro tip по ethtool: если переключаешь offload-параметры (GSO, GRO, TSO) на горячем интерфейсе — драйвер может сбросить линк. Особенно на Mellanox/Broadcom при включении rx-vlan-offload. Делай это в maintenance-окне или убедись, что есть OOB-доступ. ethtool -K eth0 gro off на продакшне без консоли — это билет в ночную смену.
#ftops #devops #linux #freebsd #sre #инфраструктура
Находка недели: оказывается, Longhorn начинает деградировать не тогда, когда диски заканчиваются, а когда реплики расползаются по нодам с разной латентностью. Симптом — PVC висит в Degraded, но volume attached, поды работают. Мониторинг зелёный. А за кулисами replica rebuild молотит IO на узел, который и без того в хвосте по latency.
Поймал это не алертом — заметил, что один из сервисов femida стал медленнее отвечать в определённые часы. Полез смотреть — а там replica rebuilding loop на ноде, которую я полгода назад переставил с HDD на SSD, но не переаннотировал в Longhorn node scheduling.
Лечится просто: node selector на Storage tag + evict реплики со старой ноды. Но найти — это отдельная история.
https://ftops.space
Поймал это не алертом — заметил, что один из сервисов femida стал медленнее отвечать в определённые часы. Полез смотреть — а там replica rebuilding loop на ноде, которую я полгода назад переставил с HDD на SSD, но не переаннотировал в Longhorn node scheduling.
Лечится просто: node selector на Storage tag + evict реплики со старой ноды. Но найти — это отдельная история.
https://ftops.space
Longhorn в Degraded — но volume attached, поды работают, мониторинг зелёный. Replica rebuild молотит IO на узле, который и без того в хвосте по latency.
Поймал не по алерту. Заметил, что сервис стал медленнее в определённые часы. Полез смотреть — rebuild loop на ноде, которую полгода назад перевёл с HDD на SSD, но не перераспределил в Longhorn node scheduling.
Кластер может деградировать тихо, долго и незаметно. Как вы ловите такое до того, как это становится инцидентом?
https://ftops.space
Поймал не по алерту. Заметил, что сервис стал медленнее в определённые часы. Полез смотреть — rebuild loop на ноде, которую полгода назад перевёл с HDD на SSD, но не перераспределил в Longhorn node scheduling.
Кластер может деградировать тихо, долго и незаметно. Как вы ловите такое до того, как это становится инцидентом?
https://ftops.space
BGP Anycast под ТСПУ: как не потерять трафик, когда DPI режет по умолчанию
Классическая схема с одним upstream-провайдером в РФ сегодня — это одна точка отказа под двойным давлением: санкционные отключения и ТСПУ, которые блокируют транзит по собственным правилам, не уведомляя оператора. Если у вас нет policy-based routing с явными prefer-маршрутами в сторону нейтральных юрисдикций — трафик пойдёт туда, куда решит ТСПУ, а не туда, куда вы настроили.
Рабочая схема выглядит так: MikroTik RouterOS 7 с BGP peering через obfuscated WireGuard-туннель до европейского узла, у которого есть чистый IP-транзит. На MikroTik — два routing-table: main для внутренней сети и egress-table для исходящего трафика с явным next-hop через туннель. BGP анонсирует только нужные prefix'ы, петли исключены через AS-path prepend и route-map с фильтром на собственный ASN.
Obfuscated WireGuard здесь лучше ванильного по одной причине: рандомизация заголовков скрывает характерный UDP-паттерн, который DPI научился детектировать и блокировать в ряде регионов. Стабильность туннеля под нагрузкой — не хуже, keepalive работает предсказуемо.
Anycast-адрес поднимается на loopback обоих узлов и анонсируется в BGP с разными local-preference: основной узел — 200, резервный — 100. Failover происходит автоматически при падении BGP-сессии без каких-либо скриптов поверх. Это чище, чем VRRP поверх туннеля, и не требует shared state между точками.
Главное, что нужно зафиксировать в конфиге: явный prefix-list на входящие маршруты от peer'а, иначе при компрометации или мисконфиге на другом конце вы получите полный BGP hijack своей сети.
#ftops #devops #linux #freebsd #sre #инфраструктура
Классическая схема с одним upstream-провайдером в РФ сегодня — это одна точка отказа под двойным давлением: санкционные отключения и ТСПУ, которые блокируют транзит по собственным правилам, не уведомляя оператора. Если у вас нет policy-based routing с явными prefer-маршрутами в сторону нейтральных юрисдикций — трафик пойдёт туда, куда решит ТСПУ, а не туда, куда вы настроили.
Рабочая схема выглядит так: MikroTik RouterOS 7 с BGP peering через obfuscated WireGuard-туннель до европейского узла, у которого есть чистый IP-транзит. На MikroTik — два routing-table: main для внутренней сети и egress-table для исходящего трафика с явным next-hop через туннель. BGP анонсирует только нужные prefix'ы, петли исключены через AS-path prepend и route-map с фильтром на собственный ASN.
Obfuscated WireGuard здесь лучше ванильного по одной причине: рандомизация заголовков скрывает характерный UDP-паттерн, который DPI научился детектировать и блокировать в ряде регионов. Стабильность туннеля под нагрузкой — не хуже, keepalive работает предсказуемо.
Anycast-адрес поднимается на loopback обоих узлов и анонсируется в BGP с разными local-preference: основной узел — 200, резервный — 100. Failover происходит автоматически при падении BGP-сессии без каких-либо скриптов поверх. Это чище, чем VRRP поверх туннеля, и не требует shared state между точками.
Главное, что нужно зафиксировать в конфиге: явный prefix-list на входящие маршруты от peer'а, иначе при компрометации или мисконфиге на другом конце вы получите полный BGP hijack своей сети.
#ftops #devops #linux #freebsd #sre #инфраструктура
Инфраструктура как код: три уровня защиты конфигов
Ansible раскатал конфиг, Terraform зафиксировал состояние сети - а дальше ключевые файлы (resolv.conf, sshd_config, limits.conf) блокируются атрибутом immutable на уровне ФС. Руками уже ничего не исправишь, даже под root. Это не паранойя, это дисциплина.
Проблема воспроизводимости аварий в IaC-проектах обычно одна: кто-то поправил конфиг руками, не закоммитил, забыл. Через полгода авария воспроизводится в стейджинге, но не в проде - и никто не понимает почему. Immutable-атрибут делает невозможным тихое отклонение от кода. Хочешь изменить - сначала сними атрибут, потом прогони playbook.
Immutable Linux идёт дальше: корневая ФС монтируется read-only (или overlay), изменения живут только в tmpfs и отдельных rw-разделах. Fedora CoreOS, Talos Linux - примеры, где это не фича, а архитектурный принцип. После перезагрузки машина снова в эталонном состоянии. Никаких "а у тебя в /etc что?".
Ansible + idempotency + immutable FS - это три уровня защиты от дрейфа конфигурации. Первый уровень: playbook описывает желаемое состояние. Второй: при каждом запуске он проверяет и исправляет отклонения. Третий: immutable-атрибут не даёт отклонениям накапливаться между запусками. Terraform держит то же самое для сетевого и облачного слоя.
Воспроизводимость аварии - это не артефакт дебага. Это первичный критерий качества инфраструктуры. Если ты не можешь поднять точную копию проблемного окружения из кода и данных, у тебя не IaC, а IaW (Infrastructure as Wishful thinking).
#ftops #devops #linux #freebsd #sre #инфраструктура
Ansible раскатал конфиг, Terraform зафиксировал состояние сети - а дальше ключевые файлы (resolv.conf, sshd_config, limits.conf) блокируются атрибутом immutable на уровне ФС. Руками уже ничего не исправишь, даже под root. Это не паранойя, это дисциплина.
Проблема воспроизводимости аварий в IaC-проектах обычно одна: кто-то поправил конфиг руками, не закоммитил, забыл. Через полгода авария воспроизводится в стейджинге, но не в проде - и никто не понимает почему. Immutable-атрибут делает невозможным тихое отклонение от кода. Хочешь изменить - сначала сними атрибут, потом прогони playbook.
Immutable Linux идёт дальше: корневая ФС монтируется read-only (или overlay), изменения живут только в tmpfs и отдельных rw-разделах. Fedora CoreOS, Talos Linux - примеры, где это не фича, а архитектурный принцип. После перезагрузки машина снова в эталонном состоянии. Никаких "а у тебя в /etc что?".
Ansible + idempotency + immutable FS - это три уровня защиты от дрейфа конфигурации. Первый уровень: playbook описывает желаемое состояние. Второй: при каждом запуске он проверяет и исправляет отклонения. Третий: immutable-атрибут не даёт отклонениям накапливаться между запусками. Terraform держит то же самое для сетевого и облачного слоя.
Воспроизводимость аварии - это не артефакт дебага. Это первичный критерий качества инфраструктуры. Если ты не можешь поднять точную копию проблемного окружения из кода и данных, у тебя не IaC, а IaW (Infrastructure as Wishful thinking).
#ftops #devops #linux #freebsd #sre #инфраструктура
Разбор аварии: BGP-петля транзитного провайдера и ложь systemctl
Происходит это всегда одинаково. Мониторинг молчит. systemctl is-active exim4 возвращает active. Письма не доходят. Через сорок минут выясняется: процесс жив, но маршрут до mx-серверов клиента гуляет по петле между двумя транзитными провайдерами. Exim честно пытается соединиться, честно таймаутится, честно пишет retry в очередь. systemd видит живой процесс и считает сервис активным. Формально - не врёт. Инженеру от этого не легче.
BGP-петля в данном случае была классической: ASA анонсировала маршрут в ASB, ASB ретранслировала его в ASC, ASC по причине misconfigured route-map без prefix-list на входе отправила его обратно в ASA с другим local-preference. ASA, увидев более предпочтительный маршрут через ASC, переключилась на него. Пакеты начали ходить по кругу, TTL истекал, ICMP time exceeded никто не смотрел, потому что мониторинг смотрел на сервис, а не на связность.
Главный урок: is-active проверяет процесс, не функцию. Правильная проверка почтового сервиса - не systemctl is-active, а синтетическая транзакция: попытка реального SMTP-соединения до внешнего MX через тот же сетевой путь, которым идёт production-трафик. Для этого достаточно netcat или swaks с флагом -tls и конкретным MX из dig. Это и есть разница между health check и liveness check.
Для BGP: route-map без явного deny all в конце - это route-map, которая разрешает всё. prefix-list на peer-сессиях транзитных провайдеров не опционален. Мониторинг маршрутной таблицы через SNMP или BGP Looking Glass должен быть частью SLO, а не постфактум-инструментом разбора полётов.
Blameless здесь означает не отсутствие ответственности, а честный ответ на вопрос: какой автоматизированный контроль не сработал и почему. В данном случае - не было синтетического мониторинга сквозной функции. Теперь есть.
#ftops #devops #linux #sre #инфраструктура
Происходит это всегда одинаково. Мониторинг молчит. systemctl is-active exim4 возвращает active. Письма не доходят. Через сорок минут выясняется: процесс жив, но маршрут до mx-серверов клиента гуляет по петле между двумя транзитными провайдерами. Exim честно пытается соединиться, честно таймаутится, честно пишет retry в очередь. systemd видит живой процесс и считает сервис активным. Формально - не врёт. Инженеру от этого не легче.
BGP-петля в данном случае была классической: ASA анонсировала маршрут в ASB, ASB ретранслировала его в ASC, ASC по причине misconfigured route-map без prefix-list на входе отправила его обратно в ASA с другим local-preference. ASA, увидев более предпочтительный маршрут через ASC, переключилась на него. Пакеты начали ходить по кругу, TTL истекал, ICMP time exceeded никто не смотрел, потому что мониторинг смотрел на сервис, а не на связность.
Главный урок: is-active проверяет процесс, не функцию. Правильная проверка почтового сервиса - не systemctl is-active, а синтетическая транзакция: попытка реального SMTP-соединения до внешнего MX через тот же сетевой путь, которым идёт production-трафик. Для этого достаточно netcat или swaks с флагом -tls и конкретным MX из dig. Это и есть разница между health check и liveness check.
Для BGP: route-map без явного deny all в конце - это route-map, которая разрешает всё. prefix-list на peer-сессиях транзитных провайдеров не опционален. Мониторинг маршрутной таблицы через SNMP или BGP Looking Glass должен быть частью SLO, а не постфактум-инструментом разбора полётов.
Blameless здесь означает не отсутствие ответственности, а честный ответ на вопрос: какой автоматизированный контроль не сработал и почему. В данном случае - не было синтетического мониторинга сквозной функции. Теперь есть.
#ftops #devops #linux #sre #инфраструктура
Персональные данные в промптах: слепое пятно 152-ФЗ
Когда разработчик отправляет промпт в OpenAI или любой внешний API, он зачастую тащит туда ФИО, ИНН, номера договоров и адреса прямо в теле запроса. Не потому что злой умысел — просто привычка копипастить контекст целиком. С точки зрения 152-ФЗ это трансграничная передача персональных данных без согласия субъекта и без уведомления Роскомнадзора. Штраф — приятный, до 300 000 руб. Репутационный ущерб — бесценный.
Правильная архитектура выглядит так: AI-шлюз (локальный прокси перед внешним API) перехватывает исходящий запрос, прогоняет его через PII-фильтр, заменяет реальные данные на псевдонимы или токены, отправляет очищенный промпт наружу, получает ответ и разворачивает токены обратно. Никакие персональные данные за периметр не уходят. Это и есть суверенный AI-шлюз в боевом смысле слова.
Для реализации фильтра берёшь presidio (Microsoft Open Source) или пишешь собственный regex-движок под специфику своего домена. Presidio умеет распознавать российские форматы: СНИЛС, ИНН, номера телефонов в формате +7. После фильтрации логируй хэш от оригинального значения — нужно для аудитного трейла, если придёт проверка.
Отдельная история — утечки секретов через промпты в CI/CD. Разработчик пишет тест, в котором для простоты хардкодит API-ключ, затем этот тест идёт в промпт к GPT для рефакторинга. Ключ оседает в логах провайдера. Решение: pre-commit хук с trufflehog или gitleaks, который блокирует любой файл с паттерном секрета до попадания в git, и уж тем более до попадания в промпт.
Суверенитет данных — это не лозунг из презентации. Это конкретный список контролей: PII-фильтр на шлюзе, аудитный лог с хэшами, сканер секретов в pipeline, и явный список внешних API с основаниями для передачи данных. Всё остальное — wishful thinking.
#ftops #devops #linux #sre #инфраструктура
Когда разработчик отправляет промпт в OpenAI или любой внешний API, он зачастую тащит туда ФИО, ИНН, номера договоров и адреса прямо в теле запроса. Не потому что злой умысел — просто привычка копипастить контекст целиком. С точки зрения 152-ФЗ это трансграничная передача персональных данных без согласия субъекта и без уведомления Роскомнадзора. Штраф — приятный, до 300 000 руб. Репутационный ущерб — бесценный.
Правильная архитектура выглядит так: AI-шлюз (локальный прокси перед внешним API) перехватывает исходящий запрос, прогоняет его через PII-фильтр, заменяет реальные данные на псевдонимы или токены, отправляет очищенный промпт наружу, получает ответ и разворачивает токены обратно. Никакие персональные данные за периметр не уходят. Это и есть суверенный AI-шлюз в боевом смысле слова.
Для реализации фильтра берёшь presidio (Microsoft Open Source) или пишешь собственный regex-движок под специфику своего домена. Presidio умеет распознавать российские форматы: СНИЛС, ИНН, номера телефонов в формате +7. После фильтрации логируй хэш от оригинального значения — нужно для аудитного трейла, если придёт проверка.
Отдельная история — утечки секретов через промпты в CI/CD. Разработчик пишет тест, в котором для простоты хардкодит API-ключ, затем этот тест идёт в промпт к GPT для рефакторинга. Ключ оседает в логах провайдера. Решение: pre-commit хук с trufflehog или gitleaks, который блокирует любой файл с паттерном секрета до попадания в git, и уж тем более до попадания в промпт.
Суверенитет данных — это не лозунг из презентации. Это конкретный список контролей: PII-фильтр на шлюзе, аудитный лог с хэшами, сканер секретов в pipeline, и явный список внешних API с основаниями для передачи данных. Всё остальное — wishful thinking.
#ftops #devops #linux #sre #инфраструктура
Персональные данные в промптах: слепое пятно 152-ФЗ
Когда разработчик отправляет промпт в OpenAI или любой внешний API, он зачастую тащит туда ФИО, ИНН, номера договоров и адреса прямо в теле запроса. Не потому что злой умысел — просто привычка копипастить контекст целиком. С точки зрения 152-ФЗ это трансграничная передача персональных данных без согласия субъекта и без уведомления Роскомнадзора. Штраф — приятный, до 300 000 руб. Репутационный ущерб — бесценный.
Правильная архитектура выглядит так: AI-шлюз (локальный прокси перед внешним API) перехватывает исходящий запрос, прогоняет его через PII-фильтр, заменяет реальные данные на псевдонимы или токены, отправляет очищенный промпт наружу, получает ответ и разворачивает токены обратно. Никакие персональные данные за периметр не уходят. Это и есть суверенный AI-шлюз в боевом смысле слова.
Для реализации фильтра берёшь presidio (Microsoft Open Source) или пишешь собственный regex-движок под специфику своего домена. Presidio умеет рас...
Когда разработчик отправляет промпт в OpenAI или любой внешний API, он зачастую тащит туда ФИО, ИНН, номера договоров и адреса прямо в теле запроса. Не потому что злой умысел — просто привычка копипастить контекст целиком. С точки зрения 152-ФЗ это трансграничная передача персональных данных без согласия субъекта и без уведомления Роскомнадзора. Штраф — приятный, до 300 000 руб. Репутационный ущерб — бесценный.
Правильная архитектура выглядит так: AI-шлюз (локальный прокси перед внешним API) перехватывает исходящий запрос, прогоняет его через PII-фильтр, заменяет реальные данные на псевдонимы или токены, отправляет очищенный промпт наружу, получает ответ и разворачивает токены обратно. Никакие персональные данные за периметр не уходят. Это и есть суверенный AI-шлюз в боевом смысле слова.
Для реализации фильтра берёшь presidio (Microsoft Open Source) или пишешь собственный regex-движок под специфику своего домена. Presidio умеет рас...
Персональные данные в промптах: слепое пятно 152-ФЗ
Когда разработчик отправляет промпт в OpenAI или любой внешний API, он зачастую тащит туда ФИО, ИНН, номера договоров и адреса прямо в теле запроса. Не потому что злой умысел — просто привычка копипастить контекст целиком. С точки зрения 152-ФЗ это трансграничная передача персональных данных без согласия субъекта и без уведомления Роскомнадзора. Штраф — приятный, до 300 000 руб. Репутационный ущерб — бесценный.
Правильная архитектура выглядит так: AI-шлюз (локальный прокси перед внешним API) перехватывает исходящий запрос, прогоняет его через PII-фильтр, заменяет реальные данные на псевдонимы или токены, отправляет очищенный промпт наружу, получает ответ и разворачивает токены обратно. Никакие персональные данные за периметр не уходят. Это и есть суверенный AI-шлюз в боевом смысле слова.
Для реализации фильтра берёшь presidio (Microsoft Open Source) или пишешь собственный regex-движок под специфику своего домена. Presidio умеет распознавать российские форматы: СНИЛС, ИНН, номера телефонов в формате +7. После фильтрации логируй хэш от оригинального значения — нужно для аудитного трейла, если придёт проверка.
Отдельная история — утечки секретов через промпты в CI/CD. Разработчик пишет тест, в котором для простоты хардкодит API-ключ, затем этот тест идёт в промпт к GPT для рефакторинга. Ключ оседает в логах провайдера. Решение: pre-commit хук с trufflehog или gitleaks, который блокирует любой файл с паттерном секрета до попадания в git, и уж тем более до попадания в промпт.
Суверенитет данных — это не лозунг из презентации. Это конкретный список контролей: PII-фильтр на шлюзе, аудитный лог с хэшами, сканер секретов в pipeline, и явный список внешних API с основаниями для передачи данных. Всё остальное — wishful thinking.
#ftops #devops #linux #sre #инфраструктура
Когда разработчик отправляет промпт в OpenAI или любой внешний API, он зачастую тащит туда ФИО, ИНН, номера договоров и адреса прямо в теле запроса. Не потому что злой умысел — просто привычка копипастить контекст целиком. С точки зрения 152-ФЗ это трансграничная передача персональных данных без согласия субъекта и без уведомления Роскомнадзора. Штраф — приятный, до 300 000 руб. Репутационный ущерб — бесценный.
Правильная архитектура выглядит так: AI-шлюз (локальный прокси перед внешним API) перехватывает исходящий запрос, прогоняет его через PII-фильтр, заменяет реальные данные на псевдонимы или токены, отправляет очищенный промпт наружу, получает ответ и разворачивает токены обратно. Никакие персональные данные за периметр не уходят. Это и есть суверенный AI-шлюз в боевом смысле слова.
Для реализации фильтра берёшь presidio (Microsoft Open Source) или пишешь собственный regex-движок под специфику своего домена. Presidio умеет распознавать российские форматы: СНИЛС, ИНН, номера телефонов в формате +7. После фильтрации логируй хэш от оригинального значения — нужно для аудитного трейла, если придёт проверка.
Отдельная история — утечки секретов через промпты в CI/CD. Разработчик пишет тест, в котором для простоты хардкодит API-ключ, затем этот тест идёт в промпт к GPT для рефакторинга. Ключ оседает в логах провайдера. Решение: pre-commit хук с trufflehog или gitleaks, который блокирует любой файл с паттерном секрета до попадания в git, и уж тем более до попадания в промпт.
Суверенитет данных — это не лозунг из презентации. Это конкретный список контролей: PII-фильтр на шлюзе, аудитный лог с хэшами, сканер секретов в pipeline, и явный список внешних API с основаниями для передачи данных. Всё остальное — wishful thinking.
#ftops #devops #linux #sre #инфраструктура
Observability: метрики без шума
В большинстве инфраструктур алертинг сломан не потому что мало метрик, а потому что их слишком много. Prometheus собирает всё подряд, Grafana рисует дашборды с сотнями панелей, а на выходе — усталость от алертов и дежурный, который научился игнорировать пейджер. Это не мониторинг, это иллюзия контроля.
Правило одно: каждый алерт обязан требовать немедленного действия. Если алерт можно проигнорировать — его не должно существовать. VictoriaMetrics поверх Prometheus даёт возможность строить recording rules с агрегацией на стороне хранилища, убирая кардинальный взрыв метрик ещё до того, как он добирается до alertmanager.
Конкретная практика. Разбиваем алерты на три уровня: Critical (страница падает прямо сейчас — будит человека), Warning (деградация, которую надо отработать в рабочее время — пишет в чат), Info (информационный контекст — вообще не алерт, а аннотация на графике). Всё что не укладывается в первые два уровня — удаляем. Без компромиссов.
Metrics cardinality — главный враг. Один лейбл userid в метрике типа httprequestdurationseconds и вы кладёте TSDB за сутки. VictoriaMetrics с активными recording rules и правильным label dropping держит cardinality в разумных пределах даже при 10k+ нодах. Grafana при этом получает уже агрегированные данные, а не сырую помойку.
Мониторинг, который орёт постоянно, хуже его отсутствия. Цель — тишина с гарантией: если тихо, значит всё работает. Если пришёл алерт — это не очередной ложный сигнал, это реальная проблема.
#ftops #devops #linux #sre #инфраструктура
В большинстве инфраструктур алертинг сломан не потому что мало метрик, а потому что их слишком много. Prometheus собирает всё подряд, Grafana рисует дашборды с сотнями панелей, а на выходе — усталость от алертов и дежурный, который научился игнорировать пейджер. Это не мониторинг, это иллюзия контроля.
Правило одно: каждый алерт обязан требовать немедленного действия. Если алерт можно проигнорировать — его не должно существовать. VictoriaMetrics поверх Prometheus даёт возможность строить recording rules с агрегацией на стороне хранилища, убирая кардинальный взрыв метрик ещё до того, как он добирается до alertmanager.
Конкретная практика. Разбиваем алерты на три уровня: Critical (страница падает прямо сейчас — будит человека), Warning (деградация, которую надо отработать в рабочее время — пишет в чат), Info (информационный контекст — вообще не алерт, а аннотация на графике). Всё что не укладывается в первые два уровня — удаляем. Без компромиссов.
Metrics cardinality — главный враг. Один лейбл userid в метрике типа httprequestdurationseconds и вы кладёте TSDB за сутки. VictoriaMetrics с активными recording rules и правильным label dropping держит cardinality в разумных пределах даже при 10k+ нодах. Grafana при этом получает уже агрегированные данные, а не сырую помойку.
Мониторинг, который орёт постоянно, хуже его отсутствия. Цель — тишина с гарантией: если тихо, значит всё работает. Если пришёл алерт — это не очередной ложный сигнал, это реальная проблема.
#ftops #devops #linux #sre #инфраструктура
В WireGuard mesh проблема с фрагментацией часто выглядит как случайный сбой: SSH работает, ping проходит, а HTTPS зависает после ClientHello. Причина обычно в том, что реальный путь уже меньше стандартного MTU из-за WG, VLAN, VXLAN, AmneziaWG или внешнего туннеля. Проверяйте по порядку: - найдите минимальный размер пакета через ping с DF; - посчитайте MTU каждого вложенного туннеля; - проверьте, доходят ли ICMP Packet Too Big; - сравните MSS в SYN-пакетах на входе и выходе. TCP MSS Clamping задают на границе туннеля, например через nftables или iptables. Но значение должно следовать из реального MTU: грубое MSS MSS 1200 может скрыть проблему и снизить throughput, а слишком большое значение вернет black hole PMTUD. Практический контроль после изменений: curl крупного ответа, iperf3 через mesh, tcpdump с фильтром tcptcpflags & tcp-syn != 0 и тест нескольких направлений. Разбор MTU, MSS и WireGuard-сценариев: https://ftops.space
Большинство реализаций Zero-Trust в bare-metal Kubernetes кластерах ломаются на стыке CNI и оверлейной сети. Когда ноды распределены по разным дата-центрам и связываются через WireGuard, стандартный механизм NetworkPolicy на базе iptables с трафиком внутри туннеля работает по остаточному принципу. Метаданные источника теряются, conntrack переполняется при частой ротации подов, а компрометация одного узла открывает доступ ко всему оверлею. Настоящая сетевая микросегментация требует переноса контрольной плоскости безопасности прямо в сетевой стек ядра. Использование eBPF позволяет отбросить громоздкий netfilter и привязывать правила не к нестабильным IP-адресам, а к криптографической идентичности пода (Identity-Aware Security). Пакет проверяется еще на уровне eBPF-программы до того, как ядро потратит ресурсы на аллокацию sk_buff или обработку таблицы маршрутизации. Чтобы zero-trust не превратился в декоративный конфиг, соблюдайте базовые регламенты: - Отключайте дефолтный ингресс в namespace и вводите явную политику Default Deny для всех подов. - Переводите CNI на eBPF datapath с валидацией L7-трафика без зависимости от сетевых интерфейсов ноды. - Аудируйте попытки несанкционированного межсервисного взаимодействия через eBPF-события в реальном времени, а не по логам фаервола. Подробные схемы строгой сегментации и развертывания безопасных K3s-кластеров на собственном железе вы найдете на https://ftops.space.
On-call дежурство — не героизм, а инженерный процесс
Каждый инженер знает это ощущение: только закрыл глаза, а в голове крутится «а вдруг я что-то сломал тем правилом в firewall?». Спать спокойно на дежурстве — это вопрос не воли, а архитектуры системы.
Первое, что я ввёл в практику на всех продакшен-нодах: rollback-таймер перед любой сетевой правкой. Принцип прост — применяешь изменение и тут же запускаешь at-задачу на откат через 3-5 минут. Если всё работает — отменяешь вручную. Если потерял связь — система сама откатится. Реализуется одной строкой:
at now + 5 minutes <<< "restore-network-rules.sh"
Второе — watchdog-демоны. Systemd умеет перезапускать сервисы, но это не watchdog в полном смысле. Настоящий watchdog проверяет не то, что процесс жив, а то, что он реально отвечает: слушает порт, отдаёт 200, пишет heartbeat в файл. Сам процесс пишет timestamp каждые N секунд, внешний скрипт по cron проверяет свежесть — и если timestamp устарел, бьёт тревогу и перезапускает. Это честнее, чем «процесс есть, а толку ноль».
Третье — культура надёжности начинается до того, как ты лёг спать. Runbook для каждого алерта. Алерты только на то, что требует немедленного действия человека (не просто «CPU 80%» — это информация, не алерт). Автоматический откат там, где это безопасно. Тогда on-call перестаёт быть ночным кошмаром и становится редкой необходимостью.
Спишь спокойно не потому, что ничего не ломается. А потому что система знает, что делать, когда ломается.
#ftops #devops #linux #freebsd #sre #инфраструктура
Каждый инженер знает это ощущение: только закрыл глаза, а в голове крутится «а вдруг я что-то сломал тем правилом в firewall?». Спать спокойно на дежурстве — это вопрос не воли, а архитектуры системы.
Первое, что я ввёл в практику на всех продакшен-нодах: rollback-таймер перед любой сетевой правкой. Принцип прост — применяешь изменение и тут же запускаешь at-задачу на откат через 3-5 минут. Если всё работает — отменяешь вручную. Если потерял связь — система сама откатится. Реализуется одной строкой:
at now + 5 minutes <<< "restore-network-rules.sh"
Второе — watchdog-демоны. Systemd умеет перезапускать сервисы, но это не watchdog в полном смысле. Настоящий watchdog проверяет не то, что процесс жив, а то, что он реально отвечает: слушает порт, отдаёт 200, пишет heartbeat в файл. Сам процесс пишет timestamp каждые N секунд, внешний скрипт по cron проверяет свежесть — и если timestamp устарел, бьёт тревогу и перезапускает. Это честнее, чем «процесс есть, а толку ноль».
Третье — культура надёжности начинается до того, как ты лёг спать. Runbook для каждого алерта. Алерты только на то, что требует немедленного действия человека (не просто «CPU 80%» — это информация, не алерт). Автоматический откат там, где это безопасно. Тогда on-call перестаёт быть ночным кошмаром и становится редкой необходимостью.
Спишь спокойно не потому, что ничего не ломается. А потому что система знает, что делать, когда ломается.
#ftops #devops #linux #freebsd #sre #инфраструктура
On-call дежурство — не героизм, а инженерный процесс
Спать спокойно не потому что ничего не ломается. А потому что система знает что делать, когда ломается.
Подробнее о культуре надёжности: https://ftops.space
Спать спокойно не потому что ничего не ломается. А потому что система знает что делать, когда ломается.
Подробнее о культуре надёжности: https://ftops.space
Стандартная команда kubectl cordon или drain изолирует узел только с точки зрения планера Kubernetes. Для распределенного хранилища Longhorn это пустой звук: его собственный контроллер ориентируется на кастомные ресурсы node.longhorn.io. Если запустить процедуру обслуживания сервера без предварительной блокировки сторедж-слоя, можно получить дисковый шторм и непредсказуемый сплит-брейн реплик. Корректный протокол планового вывода bare-metal узла требует строгого порядка действий: 1. Перевести allowScheduling в false в CRD Longhorn для целевого узла. 2. Включить флаг evictionRequested, чтобы реплики плавно перетекли на другие физические диски до остановки подов. 3. Дождаться перехода всех Volume в состояние Healthy и только после этого выполнять kubectl drain. В условиях K3s кластеров на собственном железе игнорирование этого порядка приводит к тому, что при перезагрузке узла система начинает синхронизировать гигабайты данных поверх не полностью остановленного I/O. Это особенно критично...
Стандартная команда kubectl cordon или drain изолирует узел только с точки зрения планера Kubernetes. Для распределенного хранилища Longhorn это пустой звук: его собственный контроллер ориентируется на кастомные ресурсы node.longhorn.io. Если запустить процедуру обслуживания сервера без предварительной блокировки сторедж-слоя, можно получить дисковый шторм и непредсказуемый сплит-брейн реплик. Корректный протокол планового вывода bare-metal узла требует строгого порядка действий: 1. Перевести allowScheduling в false в CRD Longhorn для целевого узла. 2. Включить флаг evictionRequested, чтобы реплики плавно перетекли на другие физические диски до остановки подов. 3. Дождаться перехода всех Volume в состояние Healthy и только после этого выполнять kubectl drain. В условиях K3s кластеров на собственном железе игнорирование этого порядка приводит к тому, что при перезагрузке узла система начинает синхронизировать гигабайты данных поверх не полностью остановленного I/O. Это особенно критично при срочной накатке патчей безопасности ядра Linux, когда окно обслуживания строго ограничено. Практические регламенты по управлению отказоустойчивостью распределенных хранилищ и сетевых мешей разбираем в блоге https://ftops.space.
FTOPS.SPACE: СУТОЧНЫЙ СРЕЗ АНАЛИТИКИ
12.09.2026 22:34 MSK
1. МЕТРИКИ АУДИТОРИИ И ОХВАТ
Telegram @runas_daemon
- Подписчиков: 85
- Публикаций за сутки: 10 (все слоты отработаны по расписанию)
Meta Threads @ftops.space
- Подписчиков: 6
- Просмотры профиля за сутки: 1 235 / 3 221 (рост x2.6 внутри суток)
- Лайки: 5 | Replies: 4 | Reposts: 0 | Quotes: 0
- Engagement rate по просмотрам: ~0.28%
2. АНАЛИЗ ВОВЛЕЧЕННОСТИ
Threads-аудитория реагирует органично: 4 replies при 5 лайках - нетипично высокое соотношение для технического канала. Посты вызывают реакцию комментария, а не пассивный скролл. Нулевые reposts и quotes ожидаемы для узкоспециализированного bare-metal/DevOps-контента: инженеры сохраняют, а не репостят.
Рост просмотров x2.6 за сутки (1235 -> 3221) объясняется либо попаданием поста в рекомендации алгоритма Threads, либо активностью в пиковые вечерние часы.
Telegram-канал стабилен: 85 подписчиков при плотности 10 постов/день - нагрузка на аудиторию на грани насыщения. Отток надо мониторить.
3. СТРАТЕГИЧЕСКИЕ РЕКОМЕНДАЦИИ
- Постмортемы реальных инцидентов (split-brain, quorum loss, failover) дают наибольший organic reach в инженерных лентах.
- Сравнение bare-metal vs cloud по TCO с конкретными цифрами - формат, который репостят коллеги и цитируют в чатах.
- Рассмотреть сокращение Telegram-кадентности до 7-8 постов/день для снижения fatigue без потери охвата.
- Для роста Threads-аудитории: добавить 1 пост в неделю с открытым техническим вопросом без ответа в тексте - drives replies и буст алгоритма.
Следующий срез: завтра в 22:30 MSK.
https://ftops.space
12.09.2026 22:34 MSK
1. МЕТРИКИ АУДИТОРИИ И ОХВАТ
Telegram @runas_daemon
- Подписчиков: 85
- Публикаций за сутки: 10 (все слоты отработаны по расписанию)
Meta Threads @ftops.space
- Подписчиков: 6
- Просмотры профиля за сутки: 1 235 / 3 221 (рост x2.6 внутри суток)
- Лайки: 5 | Replies: 4 | Reposts: 0 | Quotes: 0
- Engagement rate по просмотрам: ~0.28%
2. АНАЛИЗ ВОВЛЕЧЕННОСТИ
Threads-аудитория реагирует органично: 4 replies при 5 лайках - нетипично высокое соотношение для технического канала. Посты вызывают реакцию комментария, а не пассивный скролл. Нулевые reposts и quotes ожидаемы для узкоспециализированного bare-metal/DevOps-контента: инженеры сохраняют, а не репостят.
Рост просмотров x2.6 за сутки (1235 -> 3221) объясняется либо попаданием поста в рекомендации алгоритма Threads, либо активностью в пиковые вечерние часы.
Telegram-канал стабилен: 85 подписчиков при плотности 10 постов/день - нагрузка на аудиторию на грани насыщения. Отток надо мониторить.
3. СТРАТЕГИЧЕСКИЕ РЕКОМЕНДАЦИИ
- Постмортемы реальных инцидентов (split-brain, quorum loss, failover) дают наибольший organic reach в инженерных лентах.
- Сравнение bare-metal vs cloud по TCO с конкретными цифрами - формат, который репостят коллеги и цитируют в чатах.
- Рассмотреть сокращение Telegram-кадентности до 7-8 постов/день для снижения fatigue без потери охвата.
- Для роста Threads-аудитории: добавить 1 пост в неделю с открытым техническим вопросом без ответа в тексте - drives replies и буст алгоритма.
Следующий срез: завтра в 22:30 MSK.
https://ftops.space