Облачные сервисы *

Привет, я Виталий Ранн, занимаюсь в Cloud.ru всем, что связано с брокерами и кешами. Сегодня я хочу закопаться в вопрос о том, в каких случаях self-hosted Redis — это нужно, правильно и неизбежно, а в каких — это победа мастерства над здравым смыслом. Те, с кем мы виделись на конференции GoCloud, уже знают, о чем пойдет речь, а если вы пропустили, знакомьтесь. Вас ждет история DevOps’a Алексея, который столкнулся с проблемой падения Redis в своей компании. Наш герой виртуозно использовал StatefulSet, Redis Sentinel, Helm-чарты Bitnami и другие инструменты, что позволило ему сократить время деплоя и снизить количество сбоев на 70%. Но захочется ли повторить его путь другим — большой вопрос. 

Статья будет особенно полезна тем, кто только пробует Redis на вкус и еще не определился, в каком формате с ним стоит взаимодействовать: self-hosted или managed PaaS.

Если вы работаете с базами данных, то вам определенно стоит иметь понимание о производительности кластера СУБД. Для этого можно использовать базовые метрики. А можно — метрики от DBaaS в сочетании с Grafana. Они позволяют строить кастомные графики, которые могут быть полезны в той или иной ситуации.

Привет! Меня зовут Рамиль Адильбеков, я DevOps-инженер в Selectel. В этой статье покажу, как можно настроить базовый стек Prometheus/Grafana, подключить метрики от кластера облачных баз данных и загрузить дашборд.

Наша команда добавила к себе в список доступных для установки новую OS — Talos Linux. В этой статье мы постараемся рассказать, что такое Talos Linux, и в чем его удобство перед остальными OS для кластера Kubernetes. Дополнительно мы развернем тестовый кластер, на который задеплоим наше первое приложение.

С развитием облаков, появлением гибридных инфраструктур и мультиоблачных сред изменился взгляд ИБ на то, что важно защищать: от безопасности периметра фокус сместился к безопасности учётных записей. Злоумышленники меньше занимаются фишингом и перебором паролей, а всё чаще охотятся на забытые API-ключи и неверно сконфигурированные сервисные аккаунты. По данным Google Cloud Threat Horizons Report, эксплуатация злоумышленниками таких непользовательских сущностей (или non‑human identities, NHI) остаётся в топе угроз, при этом тактики атак постоянно усложняются.

В ответ на это некоммерческая организация OWASP в 2025 году выпустила отдельный рейтинг по топ-10 атак для NHI: OWASP Non‑Human Identities Top 10.

Меня зовут Дмитрий Лютов, я занимаюсь продуктами безопасности в Yandex Cloud и в этой статье я пройдусь по основным угрозам из рейтинга OWASP. Покажу, каким образом владельцы облаков могут позаботиться о безопасности инфраструктуры.

Привет, Хабр! Меня зовут Павел Кишеня, я тимлид группы системных администраторов IT-инфраструктур в группе Рунити. Зачастую к нам приходят заказчики с довольно высоконагруженными проектами, хранящими большой объем информации — всё это потребляет много места. Наша задача не только хранить эти данные, но и эффективно их использовать.

В этой статье поговорю о том, как компании выбирают системы хранения данных. Кто-то строит IT-инфраструктуру на классических аппаратных СХД, а кто-то уходит в кластерные решения на базе Ceph и других open-source решений. Сравню подходы и покажу, в чем плюсы и минусы каждого из них. Также поделюсь практическими кейсами переноса кластеров SSD на гибрид и добавления Ceph смешанного пула. 

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

Подготовил для вас roadmap, что важно в 2025 году знать успешному DevOps-инженеру. Пригодится как джуну, так и спецу с опытом, чтобы валидировать свои навыки.

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

На связи Роман Дерунец и Иван Бондаренко (@bond005) — научные сотрудники лаборатории прикладных цифровых технологий механико-математического факультета НГУ. В статье поделимся опытом разработки нашего университетского чат-бота: расскажем, зачем он понадобился НГУ, почему мы решили создать его с нуля и что важно знать тем, кто хочет такой же. А еще — поделимся инструкцией, как запустить похожее решение в облаке.

Со временем в каждой крупной IT-компании накапливается критическая масса однотипных решений для рутинных задач, а также сервисы и библиотеки, написанные на разных языках. Сначала кажется, что это круто: каждый волен выбирать инструменты под себя и свою задачу. А потом становится очевидно, что разнообразие — это хорошо, но не для поддержки и развития десятков, а то и сотен продакшен-сервисов. Мы ВКонтакте остро ощутили это сейчас, когда масштабно перестраиваемся и переходим к сервисной архитектуре. 

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

Мы в K2 Cloud не всегда были такими. Наш путь начался более 15 лет назад, и сначала мы были просто провайдером. Но время, опыт и сотни проектов изменили всё: мы прошли путь от первого ЦОДа до облачной платформы собственной разработки с партнёрскими услугами под любой запрос бизнеса. И сегодня я расскажу, как это было — без маркетингового шума, просто как есть.

Меня зовут Кирилл Бойко, я технический директор K2 Cloud, и в облаках (в хорошем смысле) — давно.

Разработали облачное решение? Теперь главный вызов — защитить вашу интеллектуальную собственность от копипастеров и недобросовестных конкурентов.

Меня зовут Юрий Горбачев. Я — специалист по интеллектуальной собственности. Забудьте теорию. Давайте о практике: какие механизмы (патенты, авторское право, коммерческая тайна) и договоры реально защитят ваш код, данные и интерфейсы.

Мой коллега, Андрей Квапил, недавно в своей статье «Эволюция платформ виртуализации: как мы пришли к миру managed‑сервисов и как сервис‑провайдерам конкурировать с AWS» выдвинул тезис, что AWS, GCP и Azure предоставляют своим пользователям удобные API.

Компания Linx — сервис-провайдер с дата-центрами в Москве и Санкт-Петербурге. Мы развиваем свою облачную платформу и недавно запустили Kubernetes as a Service на базе Deckhouse Kubernetes Platform (DKP).

DKP (№27871 в Едином реестре российского ПО) автоматизирует процессы администрирования и эксплуатации K8s-кластеров, связанные с аутентификацией и управлением доступом, мониторингом и логированием, работой с сертификатами и настройкой отказоустойчивости. В этой статье мы рассмотрим ключевые возможности решения и покажем интерфейс платформы. Будет полезно, если вы задумываетесь о том, чтобы попробовать Kubernetes как сервис из облака и хотите узнать больше о доступных на отечественном рынке вариантах.

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

Когда я начинал писать Node.js-сервис, который должен был интегрироваться с LLM-моделью, я уже понимал, что доступ к некоторым зарубежным API из России может быть проблемой. Именно поэтому моим первоначальным выбором была модель от Yandex Cloud — Yandex GPT.

Но после того как я и мои товарищи немного пообщались с ней, стало ясно, что Yandex GPT нам не подходит. Её ответы были слишком неестественными, «нечеловеческими» — особенно это было заметно в нашем конкретном кейсе. Поэтому пришлось искать альтернативу среди зарубежных моделей. Вариант обучать собственную модель отпал сразу — опыта у меня в этом не было, а искать кого-то, кто сможет это сделать, не было времени, так как хотелось быстро запустить. Так выбор пал на Gemini API от Google, о котором было много позитивных отзывов.

Однако это означало, что нужно было как-то решить проблему доступа из России, ведь мой сервис размещён именно в Yandex Cloud.

Вы разработчик, проект растет, код пишется легко. И вот уже готово приложение, и вы хотите поскорее показать его заказчику, коллегам или пользователям. Но вместо этого приходится копаться в Kubernetes, настройках кластеров и балансировщиков. Знакомо?

Я Никита Корольков из Cloud.ru, и сегодня покажу, как без лишних сложностей и запуска виртуальных машин развернуть проект в облаке с помощью Evolution Container Apps и при этом не потерять данные, даже если вы не DevOps.

Продолжаем серию статей о растянутом кластере Ceph. В первой части мы представили концепции, лежащие в основе стратегий репликации Ceph и подчеркнули преимущества растянутого кластера для достижения нулевой потери данных (RPO=0).

Во второй части мы сосредоточимся на практических шагах — развертывании растянутого кластера на двух локациях + монитора в качестве tie-breaker с использованием cephadm.

Ранее в блоге beeline cloud мы рассказывали про веб-приложения компаний: почему они часто становятся целями злоумышленников и что способны им противопоставить решения WAF — Web Application Firewall. Сегодня рассмотрим несколько инструментов такого класса от разработчиков из Китая, Франции и Италии.

Сайты, годами занимавшие первые строки поисковой выдачи, теряют посетителей: это явление уже окрестили «нейросетевым сайтокалипсисом». Виновники «торжества» — нейросети, как сами по себе, так и в виде модулей поисковых систем. Давайте разбираться, что происходит, как ИИ-модели влияют на сайты и можно ли с этим что-то сделать.

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

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

Чем лучше разработчик, тем хуже он делает аналитику. Просто потому, что для этого требуется разный технологический стек.

Системы, которые пишут разрабы, шикарно записывают и хранят данные. Но попытка прочесть большой объём данных сразу роняет всю систему, так как она плохо для этого предназначена. 

В этой статье я расскажу про 2 ключевых подхода к хранению и обработке данных, какой мы выбрали для аналитики в Saas-платформе и к чему это привело.