DevOps *

На проде что‑то сломалось — такова суровая реальность, случается с лучшими из нас, увы. Что часто происходит в подобных случаях: ловим алерты, бежим смотреть графики и логи, вызваниваем из отпуска разработчика, который занимался этой функциональностью, выкатываем фикс, проводим пост‑мортем. Это реакция на уровне здравого смысла, классика.

Но когда речь заходит о недозаработанных из‑за инцидента деньгах, расстроенных пользователях — любое улучшение, даже небольшое, на доли процента — может принести ощутимый результат.

Давайте поговорим, как подойти к вопросу мониторинга методологически — задействовать инструментарий инцидент‑менеджмента. Обсудим, как оценивать критичность сервисов и какие системы могут быть полезны для отслеживания проблем.

Статья ориентирована в первую очередь на тех, кто прямо сейчас занимается мониторингом на уровне общей инженерной грамотности, но пока не использует в явном виде инцидент‑менеджмент как подход.

Привет! Меня зовут Михаил Синельников. Я DevSecOps TeamLead в РСХБ‑Интех. Тружусь в ИТ‑сфере уже 25 лет, немалую часть из которых — на руководящих должностях. Сегодня расскажу, как я ищу специалистов к себе в команду DevSecOps и AppSec, на что обращаю внимание и как общаюсь с соискателями, которые на собеседовании пытаются приукрасить собственные достижения.

Компания у нас на full-remote, поэтому заседание кружка параноиков мы проводим как-то так. Иногда под банджо в углу.

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

Насчет бобров, я, кстати, не шутил. В Канаде они перегрызли кабель и оставили целый район Tumbler Ridge без оптоволоконной связи. Причем, животные, как мне кажется, делают все для того, чтобы внезапно лишить вас доступа к вашим ресурсам:

Макаки жуют провода. Цикады принимают кабели за ветки, и расковыривают их, чтобы отложить внутрь яйца. Акулы жуют трансатлантические кабели Google. А в топе источника проблем для крупной телекоммуникационной компании Level 3 Communications вообще были белки.

Короче, рано или поздно, кто-то обязательно что-то сломает, уронит, или зальет неверный конфиг в самый неподходящий момент. И вот тут появляется то, что отличает компании, которые успешно переживают фатальную аварию от тех, кто бегает кругами и пытается восстановить рассыпавшуюся инфраструктуру - DRP. Вот о том, как правильно написать Disaster Recovery Plan я сегодня вам и расскажу.

Привет всем! В предыдущей статье мы подробно рассмотрели реализацию непрерывной интеграции Continuous Integration (CI) на базе Gitea/Forgejo в CI/CD платформе Gitorion. В данной статье предлагаем вашему вниманию подробнее познакомиться с внедрением непрерывной доставки Continuous Delivery (CD) в CI/CD платформу Gitorion на базе Jenkins.

Привет, Хабр! 

Последние несколько лет мы активно строили зонтичный мониторинг и здорово в этом преуспели. Теперь у нас новая задача – построить лучший комплексный мониторинг на рынке РФ. С версией 8.0 Monq становится all-in-one мониторингом, который покроет максимум мониторинговых задач в крупных компаниях. Это самый крупный релиз за последнее время. Рассказываем, какими теперь возможностями обладает платформа.

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

Шарился я тут в по Интернету в поисках видео событий 15-летний давности и нашел что-то вроде искомого, но никак не смог посмотреть - требовался Adobe Flash. Погуглил я как мне открыть это видео, но рабочих вариантов не нашел. "Ладно" - подумал я: "Challenge accepted". А нам с читателем лишняя возможность потренироваться в создании Docker-контейнеров.

Дисклеймер: использование устаревших версий браузера и самого Flash-плагина несёт потенциальную угрозу безопасности. Используйте этот метод на свой страх и риск.

Итак, начнём с того, что поддержка Flash-плагина была выпилена в Chromium начиная с версии 89. То есть нам нужно что-то где есть более ранняя версия. Это что-то - это Ubuntu 18.04 - там 65я версия, если без апдейтов,а с апдейтами 112-я. В какой-то момент должна была быть и 88-ая, но не нашел где её добыть - если читатель подскажет, буду безмерно благодарен. И так, поехали - создаём Dockerfile

В феврале 2024 года группа исследователей уязвимостей Rapid7 выявила уязвимость, затрагивающую сервер JetBrains TeamCity CI/CD и представляющую собой обход аутентификации в веб-компоненте TeamCity.

Уязвимость получила идентификатор CVE-2024-27198 и балл CVSS равный 9,8 (критический).

Наличие данного недостатка позволяет полностью скомпрометировать сервер TeamCity, не имея аутентифицированного доступа, включая удаленное исполнение команд.

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

Мы спросили инженеров «Фланта» и экспертов из индустрии, как, по их мнению, будут развиваться Kubernetes, DevOps, Ops и Cloud Native-экосистема в ближайшее десятилетие. Наша задача была спрогнозировать будущее на основе тенденций в настоящем, а не просто «заглянуть в хрустальный шар» и пофантазировать. В результате родилась эта статья. Присоединяйтесь к нам в комментариях — давайте вместе подумаем, как будут выглядеть важные в нашей работе инструменты через 5–10 лет.

Всем привет! Меня зовут Владимир и я тимлид команды по развитию и поддержке продуктов DDoS-Guard, таких как: хостинг, VDS и выделенные серверы. Сегодня я продолжу тему алкоголика инженера @analog_cat про горение, автоматизацию и не только. Расставлю все точки в сетевом вопросе и различных кейсах автоматизации сети для VDS. В этот раз я сосредоточусь на задачах сетевой маршрутизации, которые удалось решить в процессе работы.

Привет всем! В предыдущей статье мы обзорно рассмотрели основные компоненты CI/CD Kubernetes платформы Gitorion. В данной статье подробнее остановимся на реализации хостинга кода, системы управления версиями и непрерывной интеграции Continuous Integration (CI).

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

При работе над сложными проектами обычно вовлечена команда разработчиков и специалистов по обработке данных, у которых сразу возникают вопросы: как управлять проектом, совместно разрабатывать модель машинного обучения (Machine Learning model), проводить ее тестирование, каким образом синхронизировать код и результаты экспериментов? После разработки и оптимизации ML-модели возникает необходимость ее развертывания в промышленной среде. Все эти проблемы могут казаться менее увлекательными, чем решение самой задачи машинного обучения, но они имеют критическое значение для успешной реализации ML-проектов. 

В этой статье мы подробно рассмотрим жизненный цикл ML-сервиса от идеи до разработки и внедрения, а также инструменты и принципы, используемые на каждом этапе. 

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

Казалось бы, про Apache NiFi уже писали не раз. Но если ты только знакомишься с инструментом, разобраться в таких статьях бывает нелегко. Обычно с тобой говорят так, будто ты уже давно в теме, да и задачи чаще решают явно не твои. С официальной документацией тоже все сложно: она есть, но для быстрого погружения явно не подходит.

Вот почему я решил подготовить свой гайд для новичка. Попробуем максимально быстро разобраться с первичной настройкой NiFi и NiFi Registry, подключить авторизацию по LDAP, протестировать работоспособность, рассмотреть возможные ошибки настройки и отдебажить их. 

Опыт и карьера складываются из маленьких кирпичиков. Иногда, только они и формируют движение по пути в профессии. Запрос на «большие» цели или проекты без «работы» по маленьким целям, может быть опасным и иногда недостижимым путем.

Это вторая статья из цикла «Взаимодействие ИТ и ИБ». Первую статью можно прочитать здесь.

Зачем ИБ-шникам ИТ-системы?

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

Часто выходит так, что ИТ и ИБ-подразделения пользуются схожим инструментарием в части ИТ-систем. А иногда и не просто схожим, одинаковым. В результате чего могут возникать непримиримые противоречия и неутихающие споры, нередко заканчивающиеся чем-то вроде холодной войны между департаментами.

Если вам доводилось использовать HAProxy для балансировки трафика, вы наверняка как минимум слышали, что этот продукт умеет отслеживать показатели активности сервиса и пользователей и реагировать на них по предопределённым условиям. Обычно в статьях на эту тему приводится пример ограничения пользователя по исходному IP-адресу, если частота запросов с него превышает некоторый предопределённый заранее лимит. Вот, к примеру, такая статья с сайта разработчиков.

Я бы хотел немного углубиться в тематику использованного механизма stick tables, но поговорить не про пользователей, активно интересующихся вашим сайтом, а про нагрузочную способность, или ёмкость, всего сайта (ну или каких-то его путей). Во-первых, любой сервис ограничен в количестве одновременных запросов, которые возможно обслужить на существующих ресурсах. Во-вторых, чаще всего у сервиса не одна площадка или хотя бы не один экземпляр балансёра. А это значит, что поймать одинокого пользователя — это, конечно, здорово, но хотелось бы решить и другую интересную задачу: защитить сервис от перегрузки в целом и в случае, если балансёров более одного. Бонусом поговорим о проблеме умного перераспределения нагрузки между локациями.