Привет! Меня зовут Андрей Колесников, я тимлид одной из 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-специалисте. Без долгих размусоливаний, погнали!
Практически каждый день я читаю и узнаю что-то новое про разработку. Формат "я узнал о... #" - это краткая выжимка идей, заметок и концепций, про которые я прочитал или узнал за неделю. За эту неделю я узнал про FinOps, Obsidian, DevOps фреймворк DORA и шрифт Google Sans. А ещё подумал о спорте и разнице между OLTP и OLAP нагрузкой.
Мы привыкли бороться с «мусором» в коде — временными костылями, устаревшими методами, забытыми конфигами. Но что если можно проектировать систему так, чтобы она сама чистилась от ненужного, минимизируя технический долг прямо в процессе работы? В статье попробую показать, что это не миф, а вполне реальная практика, основанная на архитектурных паттернах, «самоочищающихся» механизмов и немного наглой инженерной фантазии.
Любая сеть растёт быстрее, чем ты успеваешь её документировать. Сначала у тебя десяток серверов и пара коммутаторов, можно вести учёт адресов в табличке. Но как только устройств становится сотни, а 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 образов.
Теперь не бесплатно!
Если вам когда-либо приходилось расследовать загадочные проблемы с инфраструктурой, вы наверняка сталкивались с дрейфом. Так почему он доставляет столько неприятностей и как порождает для инженеров ситуации в духе «кто ел из моей миски»?
Своевременное выявление уязвимостей в коде является одной из важнейших задач конвейера CI/CD, ведь чем раньше мы обнаружим ошибку в коде, тем дешевле нам обойдется ее исправление. Для решения этой задачи существует множество различных решений. Но если мы используем конвейер CI/CD то нам необходимо интегрировать наш анализатор в этот процесс. Однако, в GitLab имеется своя функциональность для анализа исходного кода. В этой статье мы настроим GitLab SAST для автоматического анализа исходного кода на наличие уязвимостей.
Когда я писал статью про HAProxy, у меня возникла идея сравнить его с другим популярным proxy-сервером, например с Envoy. Но тогда мне показалось, что простое сравнение в виде таблицы или пары абзацев будет неинформативным — и я решил сделать полноценный разбор в отдельной статье. Если вам интересно — добро пожаловать! Здесь рассмотрены не все возможности каждого решения, но ключевые — те, которые действительно важны на практике.
Сегодня я разберу три популярных прокси, сравню их и расскажу: что, где и когда лучше применять. Под «популярными» я имею в виду те, с которыми работал сам и изучил их устройство «под капотом». Прокси существует гораздо больше, но о других говорить не буду — либо не копал глубоко, либо знаю слишком мало, чтобы включать их в разбор. Отдельно отмечу важность документации: если она запутана или неполна, приходится гадать, что и где настраивать, а это быстро отбивает желание работать с инструментом.
HAProxy 3.3, NGINX 1.29 и Envoy 1.35 — три open source-прокси с разной архитектурой и моделью управления. Enterprise-версии рассматривать не буду — капитализм делает свое дело: серьёзных отличий почти нет, а вот в OSS-вариантах есть что сравнить — в ряде моментов конкуренция пошла на пользу.
В этой статье разберёмся в нюансах и сравним, как устроены интервью в международные IT-компании: какие этапы вас ждут и сколько времени они занимают, какой формат у каждой корпорации и какие особенности учитывать, если вы метите выше Senior. Как итог: поймёте, как подготовиться к собеседованиям, чтобы сократить путь до желанного оффера.
Собеседования в FAANG-компаниях (или MAANG/MANGA — кому как ближе) давно стали отдельным жанром. Если вы уже пытались попасть в Big Tech — то знаете, насколько сильно отличается их подход: чёткая структура, множество этапов собеседования, критерии оценки кандидатов и даже особенная культура коммуникации. При этом есть схожие моменты, которые вы встретите везде, и уникальные штуки, о которых лучше знать заранее.
Многие инженеры теряются в нюансах настройки allowPrivilegeEscalation в Kubernetes. Автор статьи простым языком объясняет, зачем нужен этот флаг, как он работает и почему его наличие или отсутствие не критично для большинства сценариев. Если хотите понять, как устроена безопасность контейнеров, — эта статья для вас.
Привет, Хабр! Меня зовут Валентин Вертелецкий, я DevOps в СберТехе, занимаюсь развитием Platform V Kintsugi — это графическая консоль для сопровождения Postgres-like СУБД. Наш продукт построен на микросервисной архитектуре и сначала разрабатывался с использованием базовой функциональности Kubernetes — там нет встроенных механизмов аутентификации, авторизации, управления доступом и шифрования трафика. Когда же у нас стало больше сервисов, нам понадобилось повысить защиту и отказоустойчивость, добавить возможности управления доступом.
Мы опираемся на подход Zero Trust: ни одному элементу системы не доверяем по умолчанию. Каждый запрос проверяется, привилегии для администраторов минимальны, трафик валидируется и шифруется. Нам предстояло обеспечить надёжную аутентификацию и авторизацию, а также централизованный контроль и мониторинг запросов. В этом нам помогла технология Service Mesh.
Для управления микросервисами в Kubernetes мы используем Platform V Synapse Service Mesh от СберТеха — это решение на основе платформы Istio. Покажу, как всё работает у нас. Плюс, я подготовил демо-проект для тестирования кейсов (ссылка в конце статьи). Надеюсь, он будет полезен командам, работающим с микросервисами.
Это продолжение нашей истории. Во второй части показываем, как подружить Portainer и Docker Swarm, чтобы деплоить аккуратно и без docker service update. Один шаблон пайплайна, dev/prod окружения, и уведомления в Telegram -- всё максимально просто.
В итоге получается рабочий до безобразия простой CI/CD для маленькой команды. Подойдёт, если для Кубера слишком рано и слишком дорого. В конце ждет ссылка на репозиторий со всем шаблоном.
После первой статьи было выявлено несколько недостатков такой инфры, их мы тоже описали
Привет, друзья!
В этой серии статей я делюсь с вами своим опытом решения различных задач из области веб-разработки и не только.
Другие статьи серии:
DevOps Tutorials — Ansible: разворачиваем веб-приложение на виртуальном сервере
DevOps Tutorials — Terraform: создаем виртуальный сервер в облаке
В предыдущих статьях мы рассмотрели настройку сети и создание виртуального сервера Ubuntu Linux в Yandex Cloud с помощью Terraform и деплой Angular+Java веб-приложения на этом сервере с помощью Ansible. В этой статье мы научимся разворачивать JavaScript+Go веб-приложение в кластере Kubernetes.
Интересно? Тогда прошу под кат.
Быть или не быть? Стоит ли использовать key-value-базы данных в большом продакшне? На связи Иван Храмов, CTO МТС ID, и Николай Диденко, техлид из команды инфраструктуры МТС Web Services. Мы используем Cassandra в МТС ID и за годы эксплуатации познали и сильные, и слабые стороны этого решения.
Главная особенность и одновременно ограничение Cassandra и ScyllaDb — это то, что они строго key-value-хранилища. Именно с этим они справляются отлично — быстрое чтение и запись по ключу, георезервирование и масштабирование. На этом этапе все выглядит радужно.
Но по мере роста проекта возникает необходимость более сложной работы с данными. Например, когда хочется получить информацию в разрезе дат или понять, на каких устройствах какие токены живут. И вот здесь начинают всплывать ограничения архитектуры и типовые грабли, на которые можно наступить (и мы регулярно это делали). В этом материале мы опишем, почему выбрали Cassandra и с какими проблемами столкнулись — надеемся, это поможет правильно определиться с выбором нужного инструмента для ваших систем.
