Библиотека девопса | DevOps, SRE, Sysadmin

☁️☁️☁️☁️☁️☁️☁️ 24 сентября Yandex Cloud проведёт Yandex Scale 2026 — флагманскую технологическую конференцию, посвящённую облачным технологиям, инфраструктуре и искусственному интеллекту. 🎨🎨🎨🎨🎨🎨🎨🎨🎨🎨 🎨🎨🎨🎨🎨🎨🎨🎨🎨🎨 🎨🎨🎨🎨🎨🎨🎨🎨🎨 В программе четыре продуктовых трека — AI, Data, Security и Hybrid Infrastructure & DevOps, — и отдельный углублённый технологический трек DeepTech, который пройдёт только онлайн. В треке Hybrid Infrastructure & DevOps откроем программу рассказом про главные инфраструктурные анонсы и новинки 2026 года. На примере Stackland расскажем, как построить свою внутреннюю платформу по методологии Platform Engineering и ускорить time to market. Разберём, зачем бизнесу кластеры Yandex Managed Service for Kubernetes на тысячи нод — на реальном продакшн-кейсе Mindbox. Расскажем, как получить предсказуемую и безопасную ИИ‑разработку с ИИ‑командой на платформе SourceCraft и максимизировать возврат инвестиций от ИИ. Разберём возможности построения реальной гибридной инфраструктуры на базе единой технологической платформы и то, как полноценно объединить локальную и облачную среды, включая выделенные серверы BareMetal. И на примере крупного банка рассмотрим, как создать полноценный гибрид, соблюдая требования безопасности, регуляторов и бизнеса одновременно. 🎨🎨🎨🎨🎨🎨🎨🎨🎨🎨 🎨🎨🎨🎨🎨🎨🎨🎨🎨🎨 🎨🎨🎨🎨🎨🎨🎨🎨🎨 Отдельно пройдут воркшопы по Hybrid Infrastructure & DevOps. Смоделируем аварию на физическом сервере и проверим, как гибридная архитектура на облаке и BareMetal держит отказоустойчивость. Научим разворачивать корпоративную ИИ-систему с RAG-сценарием на Yandex BareMetal и Stackland — чтобы модель работала с внутренней документацией и базами знаний. Разберём, как эффективно делить GPU-ресурсы Yandex Managed Service for Kubernetes между параллельными задачами обучения моделей. И покажем, как команда ИИ-агентов SourceCraft проходит путь от бизнес-требований до безопасного релиза — с проверкой на уязвимости на каждом шаге. 🎨🎨🎨🎨🎨🎨🎨🎨🎨🎨 🎨🎨🎨🎨🎨🎨🎨🎨🎨🎨 На конференции будут не только треки —… Читать полностью →

Планы на 3 октября — прийти на RWB Infra x Security Meetup Мы направим прожекторы на инфраструктуру и информационную безопасность — туда, где за привычными решениями скрываются сложные инженерные задачи, компромиссы и неочевидные риски. Будем разбирать реальные кейсы, искать узкие места, обсуждать и показывать решения, которые помогают инфраструктуре и безопасности выдерживать рост. Когда: суббота, 3 октября, старт в 13:00 Где: Москва + онлайн В программе 8 докладов, разделенных по двум тематическим трекам Трек Infra: • Тюнинг Gitlab CE как реакция на быстрый рост нагрузки • Путь баланса и компромиссов в DCIM • Единая инфраструктура доверия: PKI на базе Vault • Kubernetes vs Bare Metal: что может пойти не так Трек Security: • DevSecOps: от сканирования в пайплайне к платформе — и обратно • Почти эффективный VM: как мы боролись с хаосом в инфраструктуре и сократили время обработки уязвимостей • Как защищать данные, когда единого периметра больше нет • От заявки до доступа за 90 секунд: как шесть инженеров управляет доступом в тысяче систем Регистрация уже открыта — не откладывайте заявку и приглашайте коллег (количество мест на площадке ограничено)! Подробнее о программе — на сайте.

🤖 ИИ-агенту теперь можно поставить задачу прямо в GitLab — и не расписывать каждый следующий шаг В SourceCraft появились автономные агенты, которые работают как отдельные участники команды. Разработчик ставит задачу в обсуждении, агент выполняет её и передаёт результат на проверку. Если по дороге ему не хватает данных или нужно согласование, он сам возвращается к команде с запросом. При этом можно подключать не только готовых агентов, но и собственных — в том числе созданных с помощью Yandex AI Studio. Например, под конкретные задачи разработки или проверки безопасности кода. Получается workflow, где ИИ может самостоятельно проходить целую цепочку действий, а не просто выполнять отдельную команду по запросу разработчика.

Для тех, кто работает с Kubernetes и облачной инфраструктурой, в октябре намечается отличный повод выбраться из рабочих чатов и встретиться офлайн 👀 Обсудим: – как пройти путь от бизнес-требования к ядру Linux – как дать агенту управление кластером вашей инфраструктуры  – как в MWS Cloud Platform доставляют системный софт в managed K8s – мультитенантность в Kubernetes-платформе — «Проект вместо namespace» – как работает LLM-диагностика инцидентов в Kubernetes и OpenStack Не обойдётся и без дискуссий: на круглых столах разберём, действительно ли Kubernetes победил и что делать, если из-за ИИ нас всех уволят. В течение дня вас ждут доклады, общение с коллегами и активности от партнеров. Будет возможность обсудить кейсы, обменяться опытом и познакомиться с коллегами из индустрии. После конференции вас ждет афтепати, где можно будет пообщаться с единомышленниками в более неформальной обстановке. 📍 Москва, 5-й Донской проезд, 17, Connect 📅 22 октября, 10:00–21:00 👉 Программу, билеты и подробности сможете найти на сайте Kuber Conf от АОТ!

SRE-инженеры, общий сбор 21 октября Т-Банк проведет онлайн-встречу «SRE-техтолк». Приглашают SRE и DevOps-инженеров. На техтолке расскажут: Какие подходы к надежности работают в Т-Банке. Как в бигтехе отслеживают бизнес-операции и автоматизируют дежурства. Какие решения можно адаптировать под свои задачи. Приходите слушать доклады экспертов из разных команд Т-Банка, обсуждать реальные кейсы и проверенные инструменты. Встреча пройдет онлайн, а для инженеров из Екатеринбурга и Новосибирска Т-Банк организует трансляцию в ИТ-хабах. Участие бесплатное. А регистрация тут!

Где развернуть свои сервисы, когда инфраструктура под угрозой? Коллеги, партнеры, друзья! Ситуация с инфраструктурой сложилась напряжённая. Многие столкнулись с последствиями отказа серверов: сбоями в работе сервисов и приложений, репутационными потерями. Мы рядом и готовы вам помочь! Оперативно развернем вашу инфраструктуру. У нас все работает штатно. Разместите у нас ваши приложения, критичные сервисы или бэкап всей инфраструктуры. Мы можем быть как основной площадкой, так и резервной. Готовы принять вас в следующих локациях: 🇷🇺Москва, Санкт-Петербург, Екатеринбург 🇺🇿🇰🇿 Ташкент, Алматы Пишите нам на горячую линию OXYGEN Или на почту [email protected] Отработаем запрос приоритетно. Disaster Recovery Бэкапы СХД Основная площадка или резерв

Лишние поля логов можно убрать до экспорта Cloudflare добавила Transformers в Logpush. Это SQL-запрос для конкретного набора логов: WHERE убирает неподходящие записи, SELECT выбирает поля и меняет их содержимое. Отфильтрованный результат уходит в хранилище уже в NDJSON. Например, можно исключить health-check трафик, привести схему к формату других CDN и замаскировать часть IP. Внутри преобразование выполняет DataFusion на Arrow-батчах, прямо в сервисе доставки. Отдельного сетевого вызова в горячем пути нет. Но маска IP ещё не делает весь лог анонимным: идентификаторы могут остаться в URL и других полях. Сначала посмотреть preview, затем привязать версию Transformer к совместимому Logpush job с тем же dataset. Устройство и пример преобразования #арсенал_инженера

Для простой admission-проверки webhook может быть лишним Нужно проверить обязательную метку или ограничить число реплик? Прежде чем поднимать отдельный webhook-сервер, посмотрите на CEL-политики Kubernetes. ValidatingAdmissionPolicy выполняет проверку внутри API-сервера, без сетевого обращения к вашему сервису. Эта возможность стабильна с Kubernetes 1.30. Webhook остаётся полезным для сложной логики, например вызова внешнего API. Но к нему добавляются доступность сервера, тайм-ауты и задержка admission. Mutating webhooks вызываются последовательно, иногда повторно. Validating webhooks работают параллельно. Для CustomResource базовую валидацию и значения по умолчанию лучше задавать в самой CRD. Выбирать механизм стоит по задаче и версии кластера, а не по привычному шаблону с ещё одним Deployment. Рекомендации Kubernetes #архитектура_на_салфетке

PodDisruptionBudget не запретит kubectl delete Три Ready-реплики, minAvailable: 2. При добровольном выселении через Eviction API бюджет не позволит опустить число доступных Pod ниже двух. На этом механизме основан и обычный kubectl drain. А прямое удаление Pod или Deployment обходит PDB. Если удалить две реплики вручную, бюджет не превратит этот запрос в отказ. PDB также не предотвращает аппаратный сбой: он ограничивает определённые добровольные disruption, а не гарантирует доступность приложения. При обслуживании проверяйте не только YAML с minAvailable, но и путь, которым инструмент убирает Pod. Eviction и DELETE похожи по результату, но разные по защите. Контроллер восстановит реплики, однако это не означает, что перерыва не было. Какие disruption учитывает Kubernetes #архитектура_на_салфетке

Команда DevCrowd* запустила новое исследование инженеров, которые отвечают за надёжность: SRE, DevOps, платформенных инженеров и всех, кто держит прод в строю. В этом году главный сюжет — как меняется роль в эпоху AI. Смотрят на то, что уже автоматизируется, а что, наоборот, дорожает: пускают ли AI действовать в проде и где проходит граница доверия, добавляет ли сгенерированный код новых инцидентов, и что остается исключительно работой человека, когда рутину забирает машина. Отдельный блок про soft skills: какие навыки SRE-специалисты считают важными, в каких проседают и что не заменит AI. Не обошли и человеческую цену надежности: сколько стоят дежурства по времени, деньгам и здоровью и на ком в команде реально концентрируется нагрузка. Часть вопросов повторяет прошлогодний опрос, так что по грейдам, зонам ответственности и рынку будет видна динамика, а не разовый срез. Опрос анонимный на 10–12 минут. Отчет со всеми разрезами опубликуют в начале декабря. Пройти опрос: https://survey.devcrowd.ru/sre-2026

Почему memory_limiter ставят перед batch В OpenTelemetry Collector порядок processors влияет на то, куда вернётся отказ при нехватке памяти. README рекомендует memory_limiter первым, чтобы backpressure дошёл до receiver. Фрагмент списка processors в своём pipeline: processors: [memory_limiter, batch] Оба processor нужно отдельно объявить в конфигурации. Проверьте их наличие в своей версии и сборке Collector. При превышении soft limit limiter отказывает новым данным с повторяемой, non-permanent ошибкой. Выше hard limit дополнительно вызывает GC. Soft limit = limit_mib − spike_limit_mib. Например, 4000 − 800 = 3200 MiB. Это пример из README, а не размер для любого контейнера. Receiver должен корректно повторить отправку. Без retry данные теряются, а бесконечно повторять он тоже не сможет. Между проверками память успевает вырасти, поэтому limiter не гарантирует защиту от OOM. Memory Limiter Processor #архитектура_на_салфетке

🔐 Высокий score systemd — повод открыть настройки сервиса У systemd-analyze есть проверка sandboxing-настроек unit. Для Linux с systemd и установленным nginx: systemd-analyze security --no-pager nginx.service Подставьте свой service unit и проверьте поддержку команды в установленной версии. Она читает конфигурацию, ничего не меняет. Нужен доступ к system manager. В ответе будет таблица ограничений и overall exposure от 0.0 до 10.0. Высокое число означает, что применено мало учитываемых ограничений. Но это не сканер уязвимостей. Оценка не учитывает всю защиту приложения и, например, не даёт полного анализа доступа через IPC. Плохой score не доказывает уязвимость, хороший не доказывает безопасность. Не включайте все ограничения ради красивого числа. Сначала выясните, какие файлы, сеть и привилегии действительно нужны сервису, затем проверяйте выбранные настройки. Документация systemd-analyze #root_prompt

Lockfile с ноутбука может не покрывать Linux runner Если provider впервые установили из mirror, в .terraform.lock.hcl могут остаться checksums только текущей платформы. На другой архитектуре проверка пакета тогда не сойдётся. Это возможный сценарий, не обязательный сбой любого macOS → Linux. В каталоге корневого модуля Terraform 0.14+ можно заранее добавить суммы для целевых платформ: terraform providers lock \ -platform=linux_amd64 \ -platform=linux_arm64 Нужны сеть до исходного registry и право записи lockfile. Выберите платформы, которые поддерживает ваш provider. Команда получает и проверяет пакеты, обновляет локальный файл, инфраструктуру не меняет. Проверьте источник подписей, signer и diff, затем сохраните lockfile в Git. Удалять его ради исчезновения ошибки checksum — плохое лечение. Этот файл фиксирует зависимости providers. Версии remote modules и state в нём не хранятся. Dependency lock file #арсенал_инженера

Pod уже удаляется, а serving всё ещё true У endpoint в EndpointSlice есть три условия: serving, terminating и ready. Для Pod поле serving отражает его Ready. Значение terminating становится true, когда Pod получает deletion timestamp, обычно ещё до остановки контейнеров. Поэтому сочетание serving=true, terminating=true возможно. Значение ready при этом false: оно означает «обслуживает и не завершается». Исключение — Service с publishNotReadyAddresses=true, у него ready всегда true. Service-прокси обычно исключают завершающиеся endpoints. Если все доступные endpoints завершаются, они могут направлять трафик на те, у которых serving=true. Поведение зависит от потребителя EndpointSlice. Эти флаги сами по себе не гарантируют бесшовный drain. Условия EndpointSlice #архитектура_на_салфетке 📍 Вакансии • Задачи • Собесы Библиотека devops'a

Проверяем HTTPS на другом IP curl --resolve подменяет адрес только для заданной пары hostname:port. Имя из URL остаётся в SNI и используется для проверки сертификата. Одного заголовка Host для этого недостаточно. Локальный стенд на карточке: TLS-сервер на 127.0.0.1:8443, сертификат с SAN app.test, тестовый CA в ca.pem. Команда выполнена в zsh на macOS с curl 8.7.1. Сервер получил SNI app.test и Host app.test:8443. Запрос к IP с Host: app.test завершился ошибкой сертификата, код 60. --noproxy отключает прокси в этом примере, --cacert указывает файл тестового CA. Проверка сертификата включена. Для обычного HTTPS без явного порта в URL пара в --resolve должна содержать 443. Everything curl #root_prompt 📍 Вакансии • Задачи • Собесы Библиотека devops'a

Куда положить pod name в Loki Имена Pod и process ID дают много уникальных значений. Если сделать их индексными labels в Loki, растёт кардинальность индекса. Structured metadata позволяет прикрепить такие поля к записи без индексации и без добавления в текст лога. Поля возвращаются с результатами запроса, по ним можно фильтровать. Для этого нужны индекс tsdb, schema ≥13, chunk format V4 и включённый allow_structured_metadata. Старый boltdb-shipper не поддерживается. Объём metadata учитывается в ingestion rate limit. Есть отдельные ограничения на размер и число полей у записи. Перенос из labels не делает хранение и обработку бесплатными. Structured metadata в Loki #архитектура_на_салфетке 📍 Вакансии • Задачи • Собесы Библиотека devops'a