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
Автоматический бэкап etcd в S3 создаёт опасную иллюзию защищенности, которая рушится при первом реальном инциденте в HA-кластере K3s. Когда вы запускаете процедуру восстановления на одном из мастеров, встроенный etcd пытается накатить снепшот поверх текущей структуры Raft. Если остальные управляющие узлы продолжают работать или сохранили старые данные в локальном хранилище, кластер мгновенно рассинхронизируется и блокирует операции записи. Рабочий регламент аварийного восстановления требует жесткой технической последовательности: - Полная остановка службы k3s на всех control-plane узлах кластера. - Очистка каталога /var/lib/rancher/k3s/server/db/etcd на всех ведомых мастерах для уничтожения старого состояния Raft. - Запуск процедуры cluster-reset на первичном узле с флагами --etcd-s3-enabled, --etcd-s3-bucket и указанием конкретного файла через --cluster-reset-restore-path или --etcd-s3-snapshot-name. - Проверка запуска одиночного кворума и последовательное переприсоединение остальных ...
Автоматический бэкап etcd в S3 создаёт опасную иллюзию защищенности, которая рушится при первом реальном инциденте в HA-кластере K3s. Когда вы запускаете процедуру восстановления на одном из мастеров, встроенный etcd пытается накатить снепшот поверх текущей структуры Raft. Если остальные управляющие узлы продолжают работать или сохранили старые данные в локальном хранилище, кластер мгновенно рассинхронизируется и блокирует операции записи. Рабочий регламент аварийного восстановления требует жесткой технической последовательности: - Полная остановка службы k3s на всех control-plane узлах кластера. - Очистка каталога /var/lib/rancher/k3s/server/db/etcd на всех ведомых мастерах для уничтожения старого состояния Raft. - Запуск процедуры cluster-reset на первичном узле с флагами --etcd-s3-enabled, --etcd-s3-bucket и указанием конкретного файла через --cluster-reset-restore-path или --etcd-s3-snapshot-name. - Проверка запуска одиночного кворума и последовательное переприсоединение остальных серверов через сброс их локальной базы. Отдельная точка отказа — учетные данные S3 и node-token. Если восстановление выполняется на с нуля развернутый нод, K3s не сможет прочитать настройки S3 из неинициализированной базы. Все ключи доступа, эндпоинты и параметры bucket должны быть явно прописаны в файле конфигурации config.yaml до момента выполнения команды сброса, иначе старт завершится ошибкой авторизации API. Разборы сетевых инцидентов, регламенты сборки отказоустойчивых bare-metal инфраструктур и сценарии DR регулярно выходят в проекте https://ftops.space.
Гиперскейлеры продают гигагерцы и гигабайты, но умалчивают про реальную структуру сетевых задержек. В пулах EKS или GKE межзональный трафик проходит через слои виртуализации vNIC, фильтры гипервизора и оверлейные сети. Результат — устойчивый p99 latency между нодами на уровне 1.8–3.2 миллисекунд. В K3s-кластере на голом железе с прямым 10GbE/100GbE L2-фабриком и eBPF-маршрутизацией без оверлея межнодовая задержка падает до 80–150 микросекунд. Для транзакционных баз данных и распределенного кэша это разница между падением пропускной способности и стабильной работой под пиковой нагрузкой. Финансовая модель облака окончательно ломается на блочных хранилищах и межзональном egress. Гарантированные 30 000 IOPS на io2 или gp3 с высоким лимитом операций обходятся в месяц дороже, чем разовый закуп двух корпоративных U.3 NVMe накопителей с ресурсом 3 DWPD. K3s на bare-metal позволяет отдавать подам сырые диски через Local Path Provisioner или собирать распределенное хранилище на Rook-Ceph с прям...
Гиперскейлеры продают гигагерцы и гигабайты, но умалчивают про реальную структуру сетевых задержек. В пулах EKS или GKE межзональный трафик проходит через слои виртуализации vNIC, фильтры гипервизора и оверлейные сети. Результат — устойчивый p99 latency между нодами на уровне 1.8–3.2 миллисекунд. В K3s-кластере на голом железе с прямым 10GbE/100GbE L2-фабриком и eBPF-маршрутизацией без оверлея межнодовая задержка падает до 80–150 микросекунд. Для транзакционных баз данных и распределенного кэша это разница между падением пропускной способности и стабильной работой под пиковой нагрузкой. Финансовая модель облака окончательно ломается на блочных хранилищах и межзональном egress. Гарантированные 30 000 IOPS на io2 или gp3 с высоким лимитом операций обходятся в месяц дороже, чем разовый закуп двух корпоративных U.3 NVMe накопителей с ресурсом 3 DWPD. K3s на bare-metal позволяет отдавать подам сырые диски через Local Path Provisioner или собирать распределенное хранилище на Rook-Ceph с прямой PCI-пропускной способностью. Вы убираете из бюджета наценку гиперскейлера за эмуляцию дискового контроллера и плату за внутренний сетевой трафик. Переход на bare-metal K3s требует инженерной зрелости: вы сами отвечаете за драйверы, жизненный цикл ядра Linux (включая своевременный патчинг уязвимостей масштаба Pedit COW), тюнинг sysctl и настройку WireGuard mesh для связывания площадок. Но в обмен вы получаете точное планирование ресурсов без эффекта noisy neighbors, полный контроль над NUMA-топологией процессора и предсказуемую юнит-экономику без внезапных счетов за облачный трафик. Практические схемы сборки bare-metal узлов, регламенты оптимизации сетевого стека ядра и архитектуру K3s для высоконагруженных систем мы регулярно публиуем на https://ftops.space.
Дефолтные настройки ImageGC в Kubernetes рассчитаны на гиперскейлеры и ноды с сотнями гигабайт памяти. На небольших VPS с диском 20-40 ГБ стандартный параметр imageGCHighThresholdPercent=85 выставляет смертельную ловушку: сборка мусора начинается только тогда, когда на диске остается 3-5 ГБ. В условиях интенсивного деплоя или роста ephemeral-storage локальная файловая система забивается быстрее, чем kubelet успевает запустить цикл очистки containerd. При достижении порога нода мгновенно получает taint DiskPressure. Kubelet начинает хаотично эвиктить поды, ломая консенсус K3s и переводя файловую систему бюджетного VPS в read-only из-за I/O-ограничений провайдера. Проблема усугубляется тем, что сборщик не трогает образы, созданные меньше чем imageMinimumGCAge назад (по умолчанию 2 минуты), а старые логи контейнеров не входят в зону ответственности ImageGC. Для стабильной работы мелких узлов дисковую гигиену нужно переводить в жесткий режим через конфигурацию K3s (/etc/rancher/k3s/config....
Дефолтные настройки ImageGC в Kubernetes рассчитаны на гиперскейлеры и ноды с сотнями гигабайт памяти. На небольших VPS с диском 20-40 ГБ стандартный параметр imageGCHighThresholdPercent=85 выставляет смертельную ловушку: сборка мусора начинается только тогда, когда на диске остается 3-5 ГБ. В условиях интенсивного деплоя или роста ephemeral-storage локальная файловая система забивается быстрее, чем kubelet успевает запустить цикл очистки containerd. При достижении порога нода мгновенно получает taint DiskPressure. Kubelet начинает хаотично эвиктить поды, ломая консенсус K3s и переводя файловую систему бюджетного VPS в read-only из-за I/O-ограничений провайдера. Проблема усугубляется тем, что сборщик не трогает образы, созданные меньше чем imageMinimumGCAge назад (по умолчанию 2 минуты), а старые логи контейнеров не входят в зону ответственности ImageGC. Для стабильной работы мелких узлов дисковую гигиену нужно переводить в жесткий режим через конфигурацию K3s (/etc/rancher/k3s/config.yaml): kubelet-arg: - image-gc-high-threshold=60 - image-gc-low-threshold=45 - image-minimum-gc-age=1m - eviction-hard=nodefs.available<10%,nodefs.inodesFree<5% Дополнительно зафиксируйте SystemMaxUse=1G в journald.conf и ограничьте размер логов контейнеров через max-size в containerd. На малых объемах управление памятью строится не от пиковых нагрузок, а от физической скорости выедания диска. Разбор оптимизации Bare-Metal и K3s стека читайте на https://ftops.space.
На сетевых интерфейсах 10G+ при высокоинтенсивном трафике классическая проблема фильтрации заключается не только в скорости прохождения пакета по цепочке, но и в поведении подсистемы при динамическом изменении правил. Когда автоматизированные системы защиты, IPS или сетевые контроллеры пытаются оперативно заблокировать атаки или обновить адреса, legacy-стек iptables блокирует весь пайплайн. Каждое изменение в iptables требует полного копирования монолитного массива правил из пространства пользователя в ядро через iptables mutex. На мультигигабитных каналах это приводит к сбросу кешей процессора, cache line bouncing между NUMA-узлами и микроскопическим задержкам, вызывающим потерю пакетов в сетевых очередях NIC. Архитектура nftables решает эту проблему за счет переноса логики в специализированную виртуальную машину ядра (nftvm) и применения нативных структур данных: - Атомарные транзакции: обновления передаются через netlink-сообщения коммитом конкретных элементов, без перезагрузки вс...