DevOps *

Появление ИИ и поиск решения

Мой интерес к системам искусственного интеллекта начался с выхода 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-вариантах есть что сравнить — в ряде моментов конкуренция пошла на пользу.

Многие инженеры теряются в нюансах настройки 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 и с какими проблемами столкнулись — надеемся, это поможет правильно определиться с выбором нужного инструмента для ваших систем.

Методология DevOps сейчас активно используется при создании, внедрении и сопровождении различных ИТ решений. Для того, чтобы эффективно работать с ИТ системами нужна команда, состоящая из множества разных специалистов разработчиков, тестировщиков, инженеров сопровождения и т.д. А у любой команды, как известно, должен быть лидер.

В этой статье мы поговорим о том, кто такой DevOps lead, какие навыки ему требуются и какие проблемы должен уметь решать данный специалист.

В современном ИТ ландшафте множество методологий имеют в своем названии упоминание Ops: DevOps, ChatOps, MLOps и другие. По сути, все они так или иначе являются порождением философии DevOps и сегодня мы поговорим о GitOps — подходе к управлению инфраструктурой и развёртыванием приложений, который использует репозиторий Git в качестве центрального механизма.

GitOps позволяет командам декларативно определять конфигурацию инфраструктуры и приложений, а затем автоматически развёртывать их. Основная идея GitOps заключается в использовании Git как единого источника данных для декларативной инфраструктуры и приложений.

В этой статье мы рассмотрим, те преимущества, которые дает использование GitOps, а также развеем некоторые мифы вокруг GitOps..

Дома и в командировках меня раздражали внезапные «тихие» обрывы Wi‑Fi. Хотелось, чтобы система сама возвращала подключение, но не спорила со мной, если я сознательно нажал «Отключить Wi‑Fi». И чтобы всё было прозрачно: логи, автозапуск, минимум магии.