Поскольку компания со страшной силы использует 1С, то сложились некие неизменные традиции, одна из которых – это веб-публикации 1С. Плодятся они примерно так: 1 ИБ (информационная база) + например несколько ИБ с тем же смыслом = 1 отдельный web(iis)-сервер, а таких конструкций полно. Получается, что помимо лицензий, мы тратим кучу ресурсов просто на веб-доступ. Поступила идея, что пора экономить (а заодно отказоустойчивость). Пока на этапе экспериментов/тестов.
Долгоживущие программные системы, как и живые организмы, склонны к старению. Эта статья — глубокое техническое исследование закономерностей деградации сложного ПО: от утечек абстракций до архитектурной энтропии. Разберём реальные примеры, редкие баги, системное гниение и последствия спагетти-рефакторинга. Код, хаос и человеческий фактор — всё как мы любим.
Если вы когда-нибудь открывали 10-летний Java-монолит и пытались понять, зачем в середине пайплайна логин-прослойки вызывается System.gc() — поздравляю, вы соприкоснулись с инженерией деградации. Это неофициальный, но абсолютно реальный раздел знаний: как сложные программные системы со временем превращаются в фрактальную кашу из решений, компромиссов и технического долга.
И, что важнее — почему это нормально.
В этой статье речь пойдёт не о багфиксах, CI/CD или микросервисах. Мы копнём глубже. Здесь — история о том, как со временем ломается не просто код, а сама логика, архитектура и даже социальные связи внутри проекта. С примерами, кодом, болью и странным юмором.
JDK Flight Recorder (JFR) — это диагностическая подсистема, встроенная в JVM. В основе JFR лежит очень простая идея, но вокруг нее выросла разнообразная экосистема решений, позволяющих решать широкий спектр задач.
В данной статье я хочу сфокусироваться на одном аспекте технологии JFR — потоковой обработке событий. Потоковая обработка появилась в JDK 14 в виде Flight Recorder Event Streaming API и позволяет прикладному коду обрабатывать события JFR с минимальной задержкой.
Всем привет, меня зовут Кирилл и я Android-разработчик в Scanny.
Это первая часть из серии статей про CI/CD для Android-проекта. В рамках данной серии статей я расскажу как настраивать GitLab CI/CD, который покроет базовые потребности в Unit и Android-тестировании, сборке приложения, публикации в Play Market и многом другом.
Дополнительно я разберу работу с разными инструментами для Android-тестирования в лице Marathon Labs и Firebase Test Lab. Аналогично разберу работу с Gradle Play Publisher и Fastlane для публикации приложения в Play Market.
Киберугрозы растут, уязвимости в коде дороже, чем когда-либо, а традиционные подходы к безопасности терпят крах. Почему компании теряют миллионы, игнорируя безопасность до финального этапа разработки? Как DevSecOps меняет правила игры, превращая защиту данных в часть повседневной работы разработчиков? В этой статье вы узнаете:
Почему «последняя миля» в тестировании безопасности — это провал: статистика OWASP и NIST о том, как 97% приложений содержат уязвимости, а исправление ошибок после релиза обходится в 6 раз дороже.
Как DevSecOps убирает барьеры между командами: интеграция безопасности в CI/CD, автоматизация проверок и сдвиг «влево» (Shift Left) — от теории к реальным кейсам Microsoft, Netflix и Capital One.
Почему успех DevSecOps зависит не от инструментов, а от культуры: как руководство может создать среду, где безопасность становится общей ответственностью, а не «чужой заботой».
Вызовы внедрения и пути их преодоления: от сопротивления изменениям до обучения разработчиков — шаги, которые сделают вашу команду готовой к цифровым угрозам будущего.
Статья подойдёт для разработчиков, руководителей IT-команд, специалистов по кибербезопасности и всем, кто хочет превратить уязвимости в прошлое.
Всем приветы! Меня зовут Антон, я Tech Lead DevSecOps в местной биг-тех компании. Хочу начать с кратенького предисловия, почему я решил написать что-нибудь про DevSecOps. Я довольно-таки часто сталкиваюсь с непониманием, что же автоматизируют и для чего нужны DevSecOps инженеры, где их место в компании и в современном ИБ. Да и что далеко ходить, многие коллеги DevOps, сами считают, что с добавлением trivy или sonarqube в пайплайны, ты уже носишь гордое звание DevSecOps.
Поэтому в этой статье поговорим о том, как должны выглядеть DevSecOps пайплайны, чтобы они трансформировались во что-то зрелое. В Security Gate!
18 июня будет два года как я создал сообщество "Код на салфетке". Сразу оговорюсь, что это некоммерческая история и возникло оно как решение важной для меня проблемы: "недостаток информации для начинающего разработчика". В процессе моего обучения и развития я сталкивался с различными нюансами, которые решались достаточно просто, но найти "комплексный ответ" зачастую было очень трудной задачей.
Каждый четверг я выпускал новые публикации, потом эту идею подхватили мои товарищи и мы начали чередовать наши статьи. За эти два года на телеграм канал "Код на салфетке" подписалось больше тысячи человек и я решил, что в качестве благодарности за внимание - устрою честный розыгрыш 9-ти книг по программированию. Подробности конкурса опубликую немного позже, но поучаствовать может кто угодно.
За эти два года мне в личку и в чат Telegram-канала довольно часто пишут новички и их вопросы можно разделить на две категории:
Довольно давно занимаюсь вопросами связанными с инфраструктурой и построением платформ для разработчиков.
Не один раз слышал от коллег и читал про такое понятие как Infrastructure as Data(IaD). Но я не смог найти внятного и короткого объяснения, что же это такое и чем полезно, потому решил попробовать рассказать свою версию.
Sealos Cloud столкнулась с критическими проблемами при работе с Nginx Ingress в кластерах с большим числом пользователей. В статье — подробный рассказ о поиске нового, более подходящего API-шлюза.
Все мы с этим сталкивались: вроде бы сервис работает, графики зелёные, ресурсы свободны — а пользователи всё равно жалуются. Открываешь мониторинг — CPU в порядке, память не забита, места на диске полно. А люди продолжают писать: «У вас тормозит». Знакомо?
Давайте разберёмся, как настроить мониторинг так, чтобы проблемы ловились сразу — ещё до того, как начнут ломиться сообщения в поддержку.
Хабр, привет! На связи Владимир, DevOps-инженер компании Совкомбанк Технологии. В этой статье расскажу о компонентах GitLab, способах их применения и том, как они помогли нам с настройкой CI/CD на проектах.
В этом руководстве рассматривается современный подход к безопасности — Zero Trust Network Access (ZTNA) — и показано, как его реализовать с помощью SPIFFE/SPIRE и OpenID Connect (OIDC). Материала много, по этому я предоставлю его в сухой форме.
В основе ZTNA лежит принцип «никогда не доверяй, всегда проверяй»: каждый запрос на доступ считается потенциально небезопасным и проходит обязательную аутентификацию и авторизацию. По сравнению с классическими VPN-сетями решения ZTNA на базе SPIFFE/SPIRE и OIDC: Ускоряют процедуру аутентификации в 20–80 раз, Повышают производительность на 46–64 %, В облаках AWS и Google Cloud позволяют снизить задержки до 50–100 мс вместо привычных 2–4 с.
Привет, Хабр! Когда релизы выходят раз в две недели, это кажется нормой. Пока не замечаешь, что задачи копятся, а срочные правки превращаются в борьбу с бюрократией. Разработчики привыкают к долгому циклу ожидания, и низкий TTM становится фоном, на который уже никто не обращает внимания.
Мы решили, что так больше продолжаться не может. Вопрос был не просто в скорости — нужно было изменить сам подход. Автоматизировать, упростить, убрать ненужные этапы и сделать так, чтобы код попадал в продакшен быстро, прогнозируемо и без хаоса.
Меня зовут Павел Лиморенко, и сегодня я расскажу вам, как мы к этому пришли, какие проблемы пришлось решать и как нам удалось ускорить релизный процесс API Почты.
Если ты пишешь Dockerfile, скорее всего, он работает. Но вопрос не в том, работает ли. Вопрос в другом: будет ли он работать через неделю, на другом сервере, в CI/CD, на чужом железе — и будет ли это безопасно?
Итак вам надо клонировать репозиторий с компанейского репозитория и git просит какие-то непонятные пароли.
Знакома ситуация?
В этой заметке я написал как настроить ssh ключи.
Автор статьи — мобильный разработчик, который сам поднял инфраструктуру для стартапа на одной небольшой виртуалке. Вы узнаете, как он выбрал и внедрил werf, какие проблемы решал с помощью SOPS, как организовал хранение и шифрование секретов, и почему GitOps стал для него спасением.
Переезд с облака на свои сервера — это не просто техническая миграция, а настоящая проверка на прочность для всей команды и бизнеса в целом. В статье я постараюсь объяснить, опираясь на свой опыт, почему облачные решения не всегда оказываются универсальным спасением, с какими неожиданными сложностями мы столкнулись и какие компромиссы пришлось принимать. Это история не только про железо и Hard‑скиллы, но и про людей, процессы и принятие решений в условиях ограниченного бюджета и рисков.
Привет, друзья!
В этой серии статей я делюсь с вами своим опытом решения различных задач из области веб-разработки и не только.
В этой статье мы научимся разворачивать Angular+Java веб-приложение на виртуальном сервере Ubuntu Linux с помощью Ansible.
Интересно? Тогда прошу под кат.
Привет! Меня зовут Алексей Федулаев, я руковожу направлением Cloud Native Security в MWS Cloud Platform. Вместе с Андреем Моисеевым мы в этой статье подробно разбираем, как устроены атаки на CI/CD, и почему автоматизация без должной защиты может обернуться серьёзными инцидентами.
Мы покажем, как злоумышленник может получить секреты из пайплайна, обойти security-джобы через конфигурации, скомпрометировать Docker Registry и внедрить вредоносный образ в продакшн. Также разберём, почему даже подпись артефактов не всегда спасает, если есть доступ к раннерам и окружению сборки.
Предупреждён — значит вооружён.
Данная статья открывает серию из трёх материалов, каждый из которых представляет отдельный уровень изучения Kafka.
Если у тебя уже есть практический опыт работы с Kafka — первый уровень, скорее всего, не для тебя. Он предназначен для новичков, которые хотят понять, зачем вообще нужен Kafka и где он используется. На втором уровне ты углубишься в технологию — и этого уже будет достаточно, чтобы уверенно использовать Kafka в профессиональной работе. Третий уровень — это джедайский уровень. Не обязателен, но если ты его освоишь — будет круто. Серьёзно.
