Когда я только начинал дежурить, телефон ночью был моим главным врагом: PagerDuty вырывал из сна десятки раз, а инциденты превращались в хаос. Со временем я понял, что on-call можно превратить в предсказуемый процесс — с правильными алертами, runbook-ами и командной культурой. В этой статье расскажу, как я перестал бояться алертов и научился относиться к дежурствам спокойно. Будет личный опыт, фейлы и практические советы
Привет, Хабр! Думаю, многие сталкивались с необходимостью генерации тысячи пользователей. Вручную - не вариант, слишком долго. В данной статье разберу библиотеку Faker. Это генератор реалистичных тестовых данных, который превращает заполнение базы и создание демо-контента из рутины в дело пары строк кода. В статье продемонстрирую, как генерировать тысячи правдоподобных записей на русском, заполнять БД и создавать собственные типы данных для ваших проектов.
Когда я только начинал работать с инфраструктурой, всё выглядело как бесконечный пожар: сотни алертов, ночные звонки, хаотичные релизы и нервы на пределе. Мы гасили инциденты вручную, но проблема возвращалась снова и снова.
Ситуация изменилась, когда я познакомился с практиками SRE: SLO, SLI и error budget. Они помогли превратить хаос в систему и объяснить бизнесу надёжность на понятном языке. Теперь вместо бессмысленного «сервис упал!» мы обсуждаем конкретные цифры: сколько бюджета ошибок потрачено и когда можно катить релиз.
В этой статье расскажу, как мы внедрили наблюдаемость на основе golden signals, научились писать постмортемы без поиска виноватых и встроили задачи по надёжности прямо в бэклог. Всё — из реальной практики инженера, который за год прошёл путь от «тушения пожаров» к спокойной работе с прогнозируемой стабильностью.
Современные платформы для машинного обучения (ML) — это комплексные системы. В их состав входит множество разнообразных инструментов — от средств обработки данных до систем развертывания моделей. А по мере увеличения масштаба и сложности таких платформ на первый план выходит вопрос эффективного управления доступом и безопасностью. Решить его можно, внедрив технологию Single Sign-On (SSO), которая позволяет пользователям получать доступ сразу ко всем компонентам платформы.
Меня зовут Дмитрий Матушкин, я инженер платформы Nova Container Platfrom в Orion soft. В этой статье мы подробно рассмотрим процесс внедрения и настройки StarVault (аналог HashiCorp Vault, но все действия похожи на те, что нужно произвести в Vault) с использованием технологии OpenID Connect (OIDC) в качестве единой точки входа для популярных компонентов ML-платформы: MLflow, Airflow и JupyterHub.
Все данные сервисы будут развернуты в кластере Kubernetes. Для удобства развертывания и настройки ванильного кластера я буду использовать решение Nova Container Platform, которое позволяет получить готовый кластер за 10 минут. Также будем считать, что в StarVault уже создан OIDC provider, например, с названием "some_provider".
В статье рассказываем, как всего за 5 дней собрать современный омниканальный контакт‑центр для фитнес‑клуба на базе open‑source‑платформы Chatwoot и подключить к нему WhatsApp, Telegram и VK с помощью самописных шлюзов на Python (Wasender, Telethon, VK API). Вы узнаете, почему мы отказались от «коробочных» SaaS‑решений, автоматизировали до 84% рутинных сценариев (поздравления, записи, напоминания) и подготовили инфраструктуру под внедрение AI‑ассистентов и аналитики SLA. Приводим архитектурные схемы, технические детали и бизнес‑выгоды — от сокращения ручной работы до сохранения всех коммуникаций с клиентами в едином окне.
Теперь ресурсы контейнеров в Kubernetes можно менять «на лету» — без перезапуска и простоев. В статье рассказываем, как работает in-place resize, где эта функция реально спасает приложения от перегрузки и какие ограничения стоит учитывать на практике.
Привет! Меня зовут Андрей Колесников, я тимлид одной из DevOps-команд Авито. Уже 10 лет я работаю с высоконагруженными и бизнес-критичными системами. В этой статье рассказываю, как мы управляем нашей инфраструктурой с помощью Puppet, и объясняю, почему мы продолжаем его использовать.
Появление ИИ и поиск решения
Мой интерес к системам искусственного интеллекта начался с выхода ChatGPT-3,5. С первых же месяцев я стал активно использовать нейросеть в своей работе: писал посты для сообщества интерната ВКонтакте о событиях и мероприятиях, использовал для консультаций по рабочим и бытовым вопросам.
Со временем я осознал огромный потенциал ИИ как инструмента, способного значительно повысить эффективность повседневной работы. Я счёл важным дать максимальному числу коллег в психоневрологическом интернате доступ к современным ИИ-инструментам.
Сотрудники интерната для общения в локальной сети использовали устаревшую программу Net Speakerphone. Это был подходящий момент не просто заменить её, а значительно расширить функционал. Идеальным решением стало развертывание корпоративного чата Mattermost со встроенным ИИ-ассистентом. Это позволило модернизировать систему коммуникации и дать сотрудникам мощный инструмент для улучшения их работы.
Почему именно Mattermost? Mattermost — это решение с открытым исходным кодом, которое можно развернуть на собственном сервере. Это даёт полный контроль над данными, безопасностью, что критически важно в условиях госучреждения. Наличие приложений для десктопных и мобильных устройств стало дополнительным аргументом в пользу Mattermost.
Кажется, выстраиваешь стартап на доверии, а потом внезапно обнаруживаешь, что главный технический специалист… не оставил тебе даже пароля от GitHub. Ни в шутку, ни в полсилы. Всё, с чем работала команда: домены, серверы, CI/CD, база клиентов, мониторинг - оказалось привязано к личным аккаунтам подрядчика. Контроль потерян. А вернуть всё не факт, что возможно.
И самое болезненное: с юридической точки зрения уязвимы не только основатели, но и инвесторы, заказчики, партнёры. Ни один NDA тут не спасёт, если изначально не были расставлены границы доступа, конкретный перечень информации и ответственности. В этом тексте не морализаторство, а подробный разбор, как такие истории случаются, чем они грозят и что можно сделать заранее, чтобы однажды не зависеть от настроения одного человека.
От ручного ада в большой компании до автоматизированного техрадара с живыми правилами и визуализацией.
Это продолжение цикла, рассказывающего о практике развёртывания небольшого, но вполне производственного кластера Cassandra. В первой и второй частях мы продвинулись вперед вот по такому плану:
1. Анализ рабочей нагрузки и требований
2.Разработка схемы данных
3. Настройка хостовых машин
4. Настройка конфигурации Cassandra
= ВЫ НАХОДИТЕСЬ ЗДЕСЬ =
5. Настройка топологии кластера
6. Подключение Prometheus Cassandra Exporter
7. Подключение Prometheus Node Exporter
8. Вывод всех метрик в Grafana
9. Проведение нагрузочного тестирования
10. Дополнительный тюнинг по результатам теста
Двинемся дальше?
Или «Почему ваш пайплайн больше похож на хромого единорога»
DevOps — это не точка назначения, а путь к более частым и надежным релизам. В лучших проектах DevOps превращается в настоящий «спорткар»: процессы полностью автоматизированы, CI/CD настраивается так, чтобы каждое изменение автоматически собиралось и развертывалось, а мониторинг отлавливает проблемы еще до того, как о них узнают пользователи. Релизы в таких командах, как правило, проходят «как по маслу», а технический долг благодаря автотестам стремительно съедается.
Но… Бывает и обратная ситуация (чаще всего). Такие проекты «пышут» проблемами. Они как телега с квадратными колёсами – релизы с полуживыми скриптами, мониторинг по логам, а автотесты проходят чисто вручную Васьком по пятницам. Знакомо?)
И самое печальное — чаще всего команда даже не понимает, насколько такой расклад дел плох. Потому что «оно же вроде работает»😵
И чтобы лишить вас одной большой проблемы, я решил накатать небольшой тест, который поможет оценить автоматизированность проекта и необходимость в Devops-специалисте. Без долгих размусоливаний, погнали!
Мы привыкли бороться с «мусором» в коде — временными костылями, устаревшими методами, забытыми конфигами. Но что если можно проектировать систему так, чтобы она сама чистилась от ненужного, минимизируя технический долг прямо в процессе работы? В статье попробую показать, что это не миф, а вполне реальная практика, основанная на архитектурных паттернах, «самоочищающихся» механизмов и немного наглой инженерной фантазии.
Любая сеть растёт быстрее, чем ты успеваешь её документировать. Сначала у тебя десяток серверов и пара коммутаторов, можно вести учёт адресов в табличке. Но как только устройств становится сотни, а IP‑адресов тысячи, Excel превращается в минное поле.
Проблемы начинаются банально:
Один инженер раздал IP вручную, второй занял тот же диапазон под тест, подсеть легла. Забыли зафиксировать, кому выдан адрес, и теперь никто не понимает, что за «сервер Х» висит в мониторинге. Конфликт VLAN и вся смена сидит без CRM.
Классика. Если нет централизованного учёта, сеть рано или поздно начнёт «жечь костры».
Именно для этого придумали IPAM (IP Address Management) — системы, которые берут на себя:
Агент с лицензией на ошибку
Как ломают ИИ-агентов. Часть 1: Кейс с Operator ChatGPT
В 2025 году ИИ-агенты стали настоящим медиа-феноменом. Ну а нас больше всего интересует вопрос уязвимости таких систем: у агентов все больше возможностей, а значит и поверхностей атаки. Наша команда работала над отчетом OWASP State of Agentic AI Security and Governance, где был раздел об инцидентах, который не попал в финальную версию отчета. Поэтому несколько инцидентов я хотел бы разобрать в серии статей. Кейс, рассмотренный в этой статье, показывает новый класс угроз, присущих именно автономным ИИ-агентам, и эта проблема носит системный характер, а не является единичным багом.
Команда Spring АйО перевела статью про то, что не так давно, компания Broadcom, которая на данный момент в силу различных M&A сделок косвенно управляет компанией Bitnami, внесла существуенные изменения в политику поддержки docker образов.
Теперь не бесплатно!
Всех приветствую! Я Артём Седых, ведущий разработчик команды банковского сопровождения. Нашему cервису уже 8 лет, 16 разработчиков, бэкенд - монолит на PHP. В данном наборе статей расскажу про наш опыт разработки альтернативы pinba и внедрения гибкой системы мониторинга бэкенда в легаси проекте с возможностью увидеть всю систему как на ладони и понять, почему именно проседают определенные экшены. Узнать о замедлении работы не в письмах и звонках от пользователей, а автоматически и прозрачно. На конкретных примерах дашбордов графаны покажу как обнаружить типичные проблемы экшенов, запланировать оптимизацию и даже предсказать снижение производительности.
Если вам когда-либо приходилось расследовать загадочные проблемы с инфраструктурой, вы наверняка сталкивались с дрейфом. Так почему он доставляет столько неприятностей и как порождает для инженеров ситуации в духе «кто ел из моей миски»?
Своевременное выявление уязвимостей в коде является одной из важнейших задач конвейера CI/CD, ведь чем раньше мы обнаружим ошибку в коде, тем дешевле нам обойдется ее исправление. Для решения этой задачи существует множество различных решений. Но если мы используем конвейер CI/CD то нам необходимо интегрировать наш анализатор в этот процесс. Однако, в GitLab имеется своя функциональность для анализа исходного кода. В этой статье мы настроим GitLab SAST для автоматического анализа исходного кода на наличие уязвимостей.
Когда я писал статью про HAProxy, у меня возникла идея сравнить его с другим популярным proxy-сервером, например с Envoy. Но тогда мне показалось, что простое сравнение в виде таблицы или пары абзацев будет неинформативным — и я решил сделать полноценный разбор в отдельной статье. Если вам интересно — добро пожаловать! Здесь рассмотрены не все возможности каждого решения, но ключевые — те, которые действительно важны на практике.
Сегодня я разберу три популярных прокси, сравню их и расскажу: что, где и когда лучше применять. Под «популярными» я имею в виду те, с которыми работал сам и изучил их устройство «под капотом». Прокси существует гораздо больше, но о других говорить не буду — либо не копал глубоко, либо знаю слишком мало, чтобы включать их в разбор. Отдельно отмечу важность документации: если она запутана или неполна, приходится гадать, что и где настраивать, а это быстро отбивает желание работать с инструментом.
HAProxy 3.3, NGINX 1.29 и Envoy 1.35 — три open source-прокси с разной архитектурой и моделью управления. Enterprise-версии рассматривать не буду — капитализм делает свое дело: серьёзных отличий почти нет, а вот в OSS-вариантах есть что сравнить — в ряде моментов конкуренция пошла на пользу.
