DevOps *

В этой статье разберем, как данные iiko становятся входом для WFM TARGControl: как забирать из POS почасовую выручку и количество чеков, превращать их во временные ряды, использовать для прогноза нагрузки и дальше — для планирования смен и аналитики.

Прежде чем перейти к API и эндпоинтам, ответим на вопрос «зачем вообще тащить POS в планирование». В HoReCa расписание проверяется не отчетом в конце недели, а кассой и залом в ближайшие 1–2 часа: спрос распределен неравномерно по времени, каналам (зал/доставка/навынос) и дням недели. Поэтому устойчивое планирование начинается не с «графика в таблице», а с измеримых драйверов спроса, которые можно регулярно обновлять автоматически.

Меня зовут Сергей Игнатенко. В прошлой жизни — девлид, 20+ лет в разработке, от C# до Kafka. Сейчас — фаундер. Эта статья про то, как первое привело ко второму.

Последний год я активно работал в Cursor — IDE с ИИ-ассистентом. И в какой-то момент меня начало подбешивать.

Cursor переименовал режим «Code» в «Agent». Звучит красиво, но по факту — это тот же автокомплит на стероидах. Никакой автономности. Никакого планирования. Ты по-прежнему сидишь в IDE, по-прежнему руками переключаешь файлы, по-прежнему сам решаешь что делать дальше. Какой же это «агент»?

Тогда я решил попробовать Claude Code — инструмент от Anthropic, о котором в тот момент восторженно писал весь Twitter. Установил, столкнулся с блокировками (я в России, привыкли), пошёл к Claude с просьбой помочь обойти защиту. Claude сказал категорическое «нет» и добавил фразу, которая засела в голове:

Прим: Дополняет мою статью "Скрипт полной миграции из GitLab на свой сервер".

После успешной миграции

А что делать со старым репозиторием?
Было бы логично использовать GitLab и другие хостинги в качестве вторичных (запасных).

Но как это делать? И еще не вручную?
Для синхронизации с remotes одновременно на свой Gogs и на все GitLab, GitHub, Bitbucket, ... remotes, об этом и других "хаках" ниже:

В прошлой статье я рассказывал, как мы оживили техрадар: научили систему автоматически обходить git репозитории, определять стек технологий, находить устаревшие зависимости и визуализировать технологический ландшафт компании.

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

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

Как масштабироваться, если новых нод не подвезут? Представьте, что вы управляете огромным высоконагруженным проектом, но находитесь не в облаке, а в on-premise. Никаких «запросить ещё одну ноду», никаких облачных щедрот — только то, что стоит в вашем серверном зале, и бюджет, который уже освоен. В таких условиях масштабироваться — всё равно что играть в «Тетрис» на харде: ресурсы ограничены, фигуры падают быстро и места всё меньше.

В этой статье мы — Илья Семёнов @ilc6 и Алексей Игнатов @AViIgnatov из Сбера, — расскажем, как мы построили собственный автоскейлер, который не запрашивает новые ресурсы, а перераспределяет существующие. Обойдёмся без магии облака, только логика, метрики и симуляция — и да, на DevOps Conf это вызвало оживлённые дискуссии.

Наша экспертиза — от разработки до архитектуры, в том числе высоконагруженных бэкендов, интеграционных, архитектурных и платформенных решений. Эта статья написана по мотивам доклада на DevOps Conf. Расскажем про наш собственный автоскейлер, который применяем к on-premise с инсталляцией, и какие решения для этого придумали.

Итак, поехали!

В материале мы разберемся, чем на практике занимается DevSecOps, какие инструменты используются в повседневной работе. Поговорим об SSDLC и откуда в этой аббревиатуре появилось слово «Security», а также в какой момент проекту стоит задуматься о внедрении безопасного жизненного цикла разработки. Отдельно остановимся на том, как внедрять SSDLC без вреда для проекта и обсудим чек-лист оценки зрелости. Погрузимся в облако тегов DevSecOps, разберем ключевые практики и инструменты, а также поговорим о том, что делать после того, как все эти процессы уже внедрены.

Есть ощущение, что мы сейчас живём в странный период: LLM-агенты уже умеют “делать работу”, но ещё не умеют быть предсказуемыми.

На демке всё выглядит идеально:

• один агент пишет код,
• второй — тесты,
• третий — делает ревью,
• четвёртый — собирает артефакты и отчёт,
• пятый — «оператор», который всё это оркестрирует.

Первые пару запусков ты сидишь и думаешь: «Ну всё. Завтра индустрия будет другой». На третьем запуске агент уверенно сообщает: «Я исправил проблему», и одновременно:

В какой-то момент почти в каждом Kubernetes-кластере наступает день, когда kubeconfig с правами cluster-admin перестаёт быть временным решением и внезапно становится: так исторически сложилось. Пользователей становится больше, доступы плодятся, а вопрос: кто и зачем может удалить namespace в проде? повисает в воздухе без логичного ответа.

До определённого масштаба это ещё можно терпеть: сертификаты, статические токены, ручная раздача доступов. Но как только в кластере появляются: несколько команд, требования по аудитам, SSO или просто здравый смысл, становится ясно — Kubernetes нужно подключать к нормальной системе аутентификации.

Kubernetes из коробки умеет работать с OIDC (OpenID Connect), и это, пожалуй, самый адекватный способ интегрировать его с внешним Identity Provider. В роли такого провайдера часто выступает Keycloak: open-source, self-hosted, с поддержкой групп, ролей и интеграцией с LDAP/AD. В общем, всё, что обычно уже есть в инфраструктуре, либо планируется к появлению.

Привет, Хабр! Меня зовут Михаил Пушкарёв, в команде РСХБ.Цифра я отвечаю за развитие систем класса ECM и OCR. В РСХБ технологии OCR применяются начиная с 2010 года и развиваются до сих пор. Технология направлена, в первую очередь, на ускорение и обслуживание клиентов банка. Сформированная конструкция контуров и наличие локальных установок делали процесс развития и обновления системы не просто сложным, а очень сложным. Помимо этого, на горизонте всё более явно начинал «маячить» процесс переходов на отечественные ОС, что привело бы к невозможности работы со всеми программными комплексами из-за того, что толстые клиенты предусматривали работу только с ОС Windows.

Конечно же, непосредственный уход с рынка Abbyy накладывал свой отпечаток на данные процесс. К моменту ухода Abbyy мы уже сформировали собственную компетенцию, которая позволяла нам в полной мере заниматься развитием проекта (добавлять новые шаблоны) или решать какие-либо проблемы. Но так как ПО не является свободно распространяемым, по сути мы лишились обновлений комплекса.

Все факторы в совокупности, а также желание навести порядок в архитектуре решений и избавиться нескольких разных решений с разными принципами работы, подвели нас к тому, что проект импортозамещения стал актуальным и нужным для реализации. Первый вопрос, который волновал всех: «А на что собственно меняем?!».

Инциденты копятся годами, постмортемы пылятся в архивах, а стратегические выводы растворяются в операционной рутине. В Zalando решили проверить, можно ли превратить этот массив опыта в инструмент для принятия инженерных решений – с помощью LLM и многоэтапного анализа.

В статье – практический разбор пайплайна, ограничений моделей и того, как связка SRE и ИИ помогает техническому руководителю видеть системные риски раньше, чем они снова выйдут в прод.

В современных облаках есть много задач, связанных с проблемами производительности и масштабируемости виртуальных сетей. Кроме этого, есть ряд задач, требующих интеграции с аппаратными сетевыми устройствами. Чтобы преодолеть этот барьер, в собственном SDN (Software Defined Network, программно-определяемая сеть) мы реализовали поддержку технологии EVPN. За это отвечает специальный компонент — EVPN-connector. Он использует OpenVSwitch для передачи данных и GoBGP для передачи информации и позволяет строить распределенные сети с поддержкой L2- и L3-режимов, а также обеспечивает интеграцию с аппаратными устройствами. В этой статье мы, команда IaaS Network в VK Cloud, расскажем о EVPN-connector в деталях.

Привет, Хабр! На связи команда «Гравитон». В этой небольшой статье мы собрали подборку практических приемов для эффективной работы с bash, которые помогут упростить интерактивное взаимодействие, а также повысить надежность и читаемость скриптов.

У компаний, которые работают в облаке, каждый новый месяц начинается с сюрприза. Его преподносят счета, которые почему-то всегда оказываются процентов на 30-40 больше прогноза. И тут начинается. Финдир смотрит на тимлида. Тимлид — на команду. Команда — в логи. А в логах — тишина. Ничего же не меняли. Или меняли?

В прошлой статье мы собрали типовые сцены из жизни. Помните наших героев?

Последние месяцы я вижу одну и ту же сцену.

Кто-то начинает активно применять нейросети в разработке — и первые недели ощущение кайфовое:
код появляется быстрее, задач закрывается больше, “как будто полетели”.

А потом начинаются знакомые фразы:

Привет, Хабр! Если интересно проанализировать недостатки инструмента inotify с позиции решения ИБ-задачи контроля целостности (именно самого инструмента в его первозданном виде), то добро пожаловать под кат!

Введение

Давайте поговорим о такой задаче информационной безопасности, как контроль целостности объектов файловой системы.

Какие инструменты контроля целостности в Linux приходят сразу на ум?

AIDE (Advanced Intrusion Detection Environment)
AFICK (Another File Integrity Checker)
tripwire
wazuh
OSSEC

Из перечисленных инструментов aide, afick и tripwire работают по принципу «редкого» мониторинга, а wazuh, ossec — постоянного (более подробно эти понятия раскроются дальше).

В этой статье лишь немного затронем тему принципа работы «редкого» мониторинга, в большей степени поговорив о проблемах, возникающих при работе с inotify, который положен в основу постоянного мониторинга wazuh/ossec.

Мы не будем досконально рассматривать сам механизм ядра Linux, хорошего материала на эту тему достаточно, в том числе и на Хабре. Также не станем проводить глубокий анализ работы прекрасных утилит inotify-tools или incron. Речь пойдет именно про сам inotify в его первозданном виде без каких-либо обвязок и библиотек. Нам важно понять, с какими проблемами можно столкнуться в случае проектирования ПО, использующего сам inotify. Что касается inotify-tools, то здесь мы посмотрим на то, закрывают ли утилиты данного пакета описанные проблемы.

Когда команда выбирает LLM для продакшена, «сравнение по бенчмаркам» — это лишь первый фильтр. Для CTO ключевой вопрос звучит иначе: какую комбинацию качества, стоимости, стабильности API, юридических ограничений и интеграций мы получим на реальной нагрузке. Я разобрал популярные модели через призму двух контуров: качество/бенчмарки и инфраструктурная пригодность.

Если тебе платят деньги, значит твоя работа кому-то нужна. Но как понять её ценность, если ты не создаёшь выручку?

У любого бизнеса есть миссия и цель. Миссии бывают разные, цель всегда одна: извлечение прибыли. Если ты маркетолог, или продажник, то напрямую наливаешь деньги в кассу. В этом случае всё понятно: выручка минус расходы == прибыль. 

Но что если ты — технарь? Разработчик пилит фичи, по сути реализует бизнес-процессы, которые также зарабатывают деньги. 

Но если твоя работа на фичи не завязана, или состоит не только в этом? Или ты и вовсе не разработчик, а DevOps, SRE, QA, безопасник и так далее? 

В любом бизнесе все активности можно разделить на два вида: те, что делают выручку и те, что управляют рисками. Нехитрый вывод: если кто-то не генерирует выручку напрямую, значит его наняли чтобы минимизировать какие-то риски.

Привет! Меня зовут Степан и я занимаюсь управлением техническими рисками в онлайн бизнесах. Эта статья — практическое руководство о том, как определить ценность твоей работы, научиться измерять её практическую пользу и управлять целями, если ты не приманиваешь деньги напрямую на расчетный счет.

Есть типичная боль: ты вроде всё сделал правильно — контейнеры поднялись, API отвечает, UI открывается… а потом оказывается, что «не работает». Причём не «сломано в пепел», а именно «почти»: где‑то 404, где‑то таймаут, где‑то UI открывается, но вкладки пустые, где‑то один запрос проходит, другой — молчит.

И самое неприятное: когда начинаешь чинить «по ощущениям», можно потратить часы, а потом выяснить, что причина была не в коде, а в порте, origin, IPv6, миграциях или в том, что UI ходит не туда.

Я перестал спорить с реальностью и сделал себе простой подход evidence-first:

pgAdmin4 - де-факто стандартный GUI для PostgreSQL.
И при этом на Arch Linux его Desktop-версия годами находится в полурабочем состоянии.

Я разобрался, почему pgAdmin4 так плохо ложится на Arch, какие подходы стабильно ломаются,
и какой компромиссный, но реально рабочий вариант в итоге получился.

Если вам тоже надоело чинить pgAdmin после каждого обновления Python или Electron - это для вас.

Привет! Я Дмитрий, инженер и руководитель направления MLOps в Совкомбанке. Специализируюсь на разработке и эксплуатации ML-платформ на базе Kubernetes и GPU.

С 2010 года в ИТ: строю инфраструктуру для машинного обучения, внедряю Kubeflow и GPU-оператор, настраиваю MIG на H100 в корпоративных средах с повышенными требованиями к безопасности и надежности. В последние годы фокусируюсь на оптимизации ML-пайплайнов, повышении утилизации GPU (включая MIG-профили) и интеграции MLOps-практик в процессы продуктовых команд.

В 2022 году в некоторых командах разработки уже существовали проекты с применением ИИ, но как отдельные компоненты, не хватало единой платформы управления. По мере роста количества и сложности бизнес-задач возникла необходимость в создании ML-платформы как сервиса с едиными стандартами авторизации. Мы изучили доступные инструменты, попытались объединить их в одном Kubernetes-кластере, столкнулись с рядом ограничений — и в итоге пришли к архитектуре на базе Kubeflow и GPU-оператора.

В статье рассказываем, какие сложности были в ходе проекта, как выстроили работу с Kubeflow, настраивали H100 с MIG-разделением и что важно учесть, если вы планируете строить ML-платформу на bare-metal-GPU в корпоративной среде.