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

Привет, Хабр! Меня зовут Павел Кишеня, я тимлид группы системных администраторов 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-платформе и к чему это привело.

Перевели для вас цикл статей об эволюции технологической платформы Mercado Libre — от монолитной архитектуры начала 2000-х к современной мультиоблачной платформе Fury, которая обеспечивает разработчикам удобную, масштабируемую и безопасную среду для создания, развёртывания и управления приложениями. В этой первой части описывается переход компании от единой базы и медленных релизов к микросервисам и облачным технологиям, что позволило значительно ускорить разработку и повысить надежность систем.

Привет, Хабр! Меня зовут Игорь Анохин, я руковожу платформенной разработкой K2 Cloud. В общении с друзьями и коллегами мне периодически приходится пояснять, что я разработчик, а не DevOps-инженер. Когда я рассказываю, как мы поднимаем платформенные сервисы (PaaS), например, базы данных, Kubernetes и другие, «разработчик» — это последнее, что приходит людям в голову. 

Поэтому в статье я расскажу, что такое PaaS и как он работает. Опишу его жизненный цикл от создания до мониторинга и решения проблем с кластером, поделюсь планами развития.

Привет, Хабр! На связи вновь Кирилл Савин, архитектор SDN в Облаке Рег.ру. Недавно мы с командой взвесили все риски и приняли волевое решение — переехать на OVN. В процессе думали над архитектурой, решали возникающие вопросы и набивали шишки. Я решил поделиться нашим опытом и подходами.

В первой статье рассказали, как устроен OVN изнутри, рассмотрели особенности архитектуры. Теперь готовы перейти к практике! Во второй части опишу ручной подход для миграции облака с сетевым даунтаймом для перестроения сети, но без миграции, собственно, виртуальных машин. Для «переезда» я осознанно выбрал ручной подход — объясню, почему и что из этого получилось. Внутри — по шагам рассказываю о переезде и делюсь полезными конфигурациями, которые делают это возможным.

FinOps — это не просто модный термин. Это ответ на боль тысяч компаний, которые внедрили облака, а потом с ужасом смотрят на счета. Главная проблема — не только в размере итоговой суммы, но и в отсутствии прозрачности. Вы видите огромный счет, но не понимаете почему столько и за что именно платите. 

FinOps помогает ИТ-директору не только обосновать необходимость инвестиций через бизнес-результаты, но и, что особенно важно на начальных этапах, объяснить текущий объем расходов. Если завтра CEO спросит: «Почему мы платим столько за облако?» — вы хотя бы сможете показать, куда уходят деньги и за что именно платит компания. На низком уровне зрелости FinOps речь идет не об окупаемости, а о базовой прозрачности и возможности не выглядеть некомпетентным перед финансовым директором (CFO). FinOps — это ваш новый must have, если вы хотите выйти из режима «платим непонятно за что» и взять расходы под контроль.

В статье собрали ключевые тезисы из практики управления FinOps для ИТ-руководителей. При подготовке статьи опиралась на свой опыт в ITSM, материалы по FinOps фреймворк, исследования Gartner и McKinsey и практический опыт практиков FinOps.