Git in Sky

Продолжаем беседы с нашим техлидом Дмитрием. Сегодня — о том, как взлом одного npm-аккаунта за 3 часа распространил RAT на 174 000 пакетов и почему стандартные инструменты вроде NPM Audit это не поймали. Разбираем инцидент с Axios: механику атаки, слепые пятна в CI/CD и то, что реально работает. 30 марта 2026 года в npm появились две вредоносные версии Axios — 1.14.1 (тег latest) и 0.30.4 (тег legacy). Axios — JavaScript-библиотека для HTTP-запросов с ~100 млн загрузок в неделю и 174 000 зависимых пакетов в npm. Фактически, если проект на Node.js — с высокой вероятностью он тянет Axios транзитивно. Злоумышленник получил доступ к npm-аккаунту jasonsaayman — ведущего мейнтейнера библиотеки. Первый признак компрометации: email аккаунта сменился с jasonsaayman@gmail.com на ifstap@proton.me, а метод публикации изменился — с доверенного OIDC-пайплайна со SLSA-провенансом на прямой CLI-publish. Оба флага автоматически поймала Elastic Security Labs через мониторинг цепочки поставок. Вредоносны

Приятно много просмотров получила статья про рабочий день DevOps-инженера. Это мотивировало сделать фокус еще на некоторых особенностях нашей инженерной работы, поэтому продолжаю разговаривать с Дмитрием, тимлидом DevOps-команды в Git in Sky. Его общий стаж в статусе тимлида — с 2016 года. В отличие от многих коллег по рынку мы не боимся брать джунов. С ними очень легко, потому что мы… любим и умеем их готовить 🙂. Нюанс в том, что для быстрого развития подойдет не любой человек с рынка труда. В этой статье расскажу о том, какие качества соискателя нам важны и как получается, что специалист уверенно развивается без серьезных вложений с нашей стороны. В Git in Sky почти нет ротации в коллективе, и это прекрасно: комфортнее работать в знакомой сыгранной команде. Но мы растем, поэтому неизбежно сталкиваемся с наймом. К примеру, у нас стартует новый пресейл — горячий клиент готов через месяц заключить с нами договор. Под этот проект с нашей стороны необходимо выделить инженеров. Я могу либ

Эволюционируя из рядового сисадмина в DevOps-а, специалисты начинают заботиться о разработке. В среднем разработчики об инфраструктуре знают не очень много: вполне может добавить скрипт, который обрушит кластер. Поэтому наша задача как девопсов сделать систему максимально отказоустойчивой, автоматизировать рутину, выстроить процессы CI/CD, настроить мониторинг и вообще следовать подходу “Инфраструктура как код”. Но это в теории. На практике это возможно, только если в систему никто не вносит никаких изменений, а так не бывает. Поэтому жизнь DevOps - постоянный “День Радио” в отдельно взятой инфраструктуре. “День Радио” — это фильм с сюжетом, что в прямом эфире вот-вот должен стартовать марафон, но за десять минут до начала выясняется, что заранее подготовленная тема перехвачена конкурентами. И начинается суета и множество сюжетных поворотов и проблем 🙂 Я поговорил с Дмитрием, тимлидом DevOps-команды в Git In Sky. Обсудили, как выглядит его типичный рабочий день и какие задачи стоят пе

Привет всем читателям Дзена! Прошу строго не судить, это моя первая статья здесь. Меня зовут Георгий, я системный инженер в компании Git in Sky. Итак, нас попросили настроить мониторинг Apache NiFi и настроить алерты при переполнении очереди по достижении 8000 FlowFiles. Эти метрики относятся к бизнес-метрикам. Статей о том, что такое Apache NiFi, довольно много: Раз, Два, Три. Как настроить сбор метрик в prometheus немного, но есть: Раз, Два. Для начала нам необходимо понять, как работает nifi и какие именно метрики с какими параметрами отвечают за это. Итак, нам необходима метрика nifi_amount_items_queued, и если в prometheus сделать запрос этой метрики, то мы увидим большое количество данных со значениями 0 Если посмотреть в web интерфейс nifi, то там мы увидим все 3 элемента, описанные выше: DataFlow Потоки управления Соединения Да, если вы внимательно посмотрели на последнюю картинку, то там видно, что очереди у нас копятся именно в соединениях success и failure. Соответственно на

В современном мире технологий, где надёжность и масштабируемость систем становятся ключевыми факторами успеха, практики Site Reliability Engineering (SRE) и DevOps играют решающую роль. Эти методологии не только способствуют улучшению качества предоставляемых услуг, но и обеспечивают их непрерывную доступность и устойчивость. Рассмотрим, как методология DevOps плавно сплетается с практиками SRE для обеспечения надёжности сервисов, выделим основные различия между ними и отметим результаты работы применения связки SRE+DevOps в организации. Для начала определимся, что стоит понимать под надёжностью и чем она отличается от производительности? Надёжность цифрового сервиса характеризуется прежде всего его отказоустойчивостью, а производительность — временем отклика. Компаниям важно, чтобы сервис откликался на действия пользователя за минимальное время. Но также важно (а сегодня порой и важнее), чтобы количество инцидентов в его работе было минимальным, а скорость и качество восстановления с

У российского бизнеса, ведущего разработку своих информационных систем на платформе 1С, появились новые потребности: наряду с увеличением скорости вывода продукта на рынок (Time to Market) требуется сокращение сроков решения проблем, то есть важна скорость нахождения причин инцидентов. Мы расскажем, почему возникла такая необходимость, какие есть сложности в удовлетворении этих бизнес-потребностей и как в этом помогает использование технологических инструментов автоматизации разработки под 1С. С уходом с отечественного рынка и отзывом лицензий зарубежных производителей ERP-систем, таких как SAP, Microsoft Dynamics и других, отечественный бизнес за неимением альтернатив стал чаще использовать платформу 1С. Эта операционная среда тоже позволяет создавать информационные решения для управления процессами в бизнесе и управления предприятием, однако с некоторыми ограничениями. Микро- и малый бизнес вполне удовлетворяет конфигурация решения «из коробки». Средний и крупный бизнес разрабатывают

В этом обновлении команда разработчиков проделала огромную работу! Новая версия включает множество полезных функций и улучшений, которые значительно упростят вашу работу с Git и сделают его использование еще более удобным и эффективным. Теперь Git стал еще более мощным с добавлением нового бэкенда "reftable", который обеспечивает эффективное хранение ссылок на ветки и теги. Этот бэкенд, используя блочное хранилище, как в проекте JGit, оптимизирован для работы с огромным количеством ссылок. Это особенно полезно в репозиториях, где традиционные методы хранения приводят к значительным накладным расходам. Включить новый бэкенд можно с помощью команды: git init --ref-format=reftable /path/to/repo Git делает шаг в будущее, добавляя поддержку для идентификаторов объектов на базе SHA-256 наряду с SHA-1. Новый формат объектов "compatibility" позволяет легко ссылаться на объекты с использованием как основного, так и запасного хэша. Пример инициализации такого репозитория: git init --object-form

Обычная ИТ-инфраструктура для бизнеса состоит из серверных юнитов, структурированных кабельных систем, штата системных администраторов и регулярного решения множества технических проблем. Постоянное обслуживание и возможные неисправности оборудования — частые причины, по которым компании все чаще переходят от традиционной инфраструктуры к облачным решениям. Несмотря на давнее существование облачных технологий, не все до конца понимают, что входит в состав облачной инфраструктуры и какие преимущества она предлагает. Этим вопросам посвящена данная статья. Провайдеры предоставляют доступ к ИТ-инфраструктуре по 3 моделям: Особенность облачных ИТ-решений — отсутствие технических вопросов и капитальных инвестиций, что делает их более привлекательными для бизнеса, особенно малого. Компания оплачивает только подписку по фиксированной цене. Ремонт оборудование, обслуживание ПО и т.д. берет на себя поставщик услуг. Как работает облачная инфраструктура? Облачные технологии основаны на виртуализ