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

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

До этого я сравнивал интересные мне хостинги примерно раз в год — не видел смысла делать это чаще. После недавнего сравнения российских VPS/VDS-хостингов прошло не так много времени, но появился повод вновь вернуться к этой теме. А именно, в комментариях вполне ожидаемо спросили «а где остальные крупные игроки?», да и в личку написало несколько представителей компаний с предложением протестировать их услуги. Поэтому пока старые цифры не остыли, по просьбам трудящихся решил добавить к результатам тестов ещё несколько компаний, которые мне показались интересными. 

Под катом — результаты тестирования уже 9 серверов от следующих компаний: трёх новых (FirstVDS, AdminVPS, Рег.ру) и 6 старых (Timeweb, RUVDS, CLO, AEZA, VDSina и Selectel). Теперь, когда результатов стало больше, можно не только посмотреть на новичков, но и оценить, насколько они меняют в целом общую картинку.

Я маркетолог и до этого проекта не писала код. Но с помощью GPT собрала рабочую систему сбора, обработки и аналитики отзывов для ресторанной сети: 16 500 отзывов в одном контуре, более 9 500 записей в собственном хранилище, четыре XML-фида, мониторинг, автоответы и 130+ страниц документации. Все это обходится в 8,5К в месяц.

Это кейс не только про AI-assisted development, но и про вполне прикладную пользу для бизнеса: меньше ручной работы, меньше пропусков и ошибок, единая аналитика и понятная стоимость эксплуатации. А заодно – честный разбор того, где AI действительно снижает порог входа в разработку, а где без человеческого контроля быстро начинает моросить.

Привет, Хабр! Меня зовут Илья Гуляев, я работаю в команде Рег.облака над облачными решениями. А в свободное время ковыряю MCP — Model Context Protocol, про него и будет текст. Про сам протокол на Хабре уже написано много, а вот про то, что начинается, когда MCP-серверов в инфраструктуре становится десяток, пока почти ничего.

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

В материале — ключевые практики для 2026 года: задавать requests и limits для каждого контейнера, изолировать нагрузки через namespaces и NetworkPolicy, автоматизировать health checks и еще много всего. Приглашаю под кат.

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

Меня зовут Алексей Свиридов, в InfoWatch я уже 12 лет, начинал как инженер, теперь отвечаю за проекты внедрения на территории СЗФО. В этой статье расскажу о том, как Immich помогает мне в работе с корпоративным фото/видеоархивом. 

Мануалов по установке не будет, но расскажу про пару технических приёмов, которые лично мне показались интересными. Возможно, пригодятся и вам.

При чём тут вообще фотоархив? 

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

Так вот, про фото. После любого такого события появляется пара сотен фотографий. А иногда и тысяч, если фотограф попался выносливый, а мероприятие было масштабным. Немного спойлерну — сейчас в архиве компании насчитывается более 50 000 фотографий и 1000+ видеороликов.

Само собой, когда мероприятие проходит, фотограф присылает внутрикомам все фотографии, которые они затем и размещают на внутренних ресурсах. А потом присылают ссылку в рабочий чат — мол, спасибо всем, кто пришёл, вот тут ваши фото.

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

Как руководителю понять, чем занята ИТ-команда: сколько ресурсов уходит на поддержку, какие работы относятся к проектной нагрузке, где задачи остаются без оценки, а где назначены исполнители, но работа не движется?

В компании «Первого Бита» для этого внедрили единый управленческий контур EvaTeam, поверх системы настроили аналитический HTML-дашборд. Через API он собирает данные, помогает находить слепые зоны и принимать управленческие решения на основе фактической загрузки команды.

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

Эта история началась не с продуктовой сессии, не с исследования рынка и даже не с запроса заказчиков. Отправной точкой стала встреча с коммерческой командой.

Коллеги из отдела продаж искали способ быстрее оценивать внешний периметр потенциальных заказчиков перед демонстрацией MULTISTATUS — сервиса геораспределённого мониторинга доступности веб-ресурсов.

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

Гений, миллиардер, плейбой, филантроп — цитата из «Железного человека», которую знают все. И полетать в железном костюме, конечно, тоже все хотели. Но раз уж собрать его на коленке в гараже не получится (а попытки были), можно начать с малого — настроить умного помощника, который управлял мастерской, да и этой броней.

Команда из Стэнфорда как раз выпустила OpenJarvis — открытый фреймворк для создания персональных ИИ-агентов. Давайте посмотрим, как его развернуть на собственной инфраструктуре и действительно ли проект оправдывает свое название.

Представьте: в вашей организации сотни, а то и тысячи компьютеров под управлением Windows и разных дистрибутивов Linux. Управлять этим зоопарком классическими средствами вроде Microsoft SCCM становится невозможно, особенно с учётом тренда на импортозамещение. Здесь на сцену выходит система для централизованного управления устройствами и приложениями в гетерогенной инфраструктуре из «единого окна» Колибри-АРМ.

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

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

Но в целом миграция идет не лучшим образом (в том числе из-за регулирования). Мы в Beeline Cloud решили посмотреть, получается ли у Европы строить суверенное облако, учитывая, что свою Кремниевую долину создать не вышло.

Почти все сегодня знают про LLM и могут сравнивать модели, спорить о качестве ризонинга, важности контекста и стоимости токенов.

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

Между тем инструменты для этого уже есть, например Evolution Foundation Models. И благодаря широкому пулу моделей помогают сделать продвинутый ИИ доступным для всех, а не только для сценариев разработки. 

Эта статья для тех, кто на практике столкнулся с дефицитом рабочих ИИ-решений для неайтишных сценариев: для аналитиков, продактов, тимлидов и технических лидеров, которым нужно грамотно внедрить LLM в рабочие процессы от маркетинга до бэк-офиса.

Хотите научиться генерировать видео по тексту или аудио, но не знаете, как это сделать? Wan2.2 отлично работает в ComfyIU, но интеграция в собственные проекты затруднительна. К счастью, есть альтернатива: LTX-2 можно легко запустить без дополнительной обвязки.

В этой статье рассмотрим, как запустить модель LTX-2 на своем облачном сервере.

Когда 20 ноября 2025 года из-за ошибки в конфигурации одного коммутатора отказала дисковая подсистема всей платформы, пятьдесят наших клиентов одновременно открыли тикеты. В этот момент выяснилось главное: техническая проблема была одна, а коммуникационных — десятки.

Привет, Хабр! Меня зовут Никита Борзов, я руковожу командами поддержки и внедрения инфраструктур в K2 Cloud. В этой статье из моего доклада на конференции K2 Cloud Conf ’26 я хочу поговорить про то, что поддержка — это не один инженер за терминалом, а система коммуникаций, которая работает параллельно с техническим решением. Именно её архитектура определяет, насколько болезненным будет инцидент для клиента.

В начале 2025 года Volexity опубликовала две статьи, в которых подробно описала новую тенденцию среди российских субъектов угроз: для получения доступа к учётным записям пользователей Microsoft злоумышленники атаковали организации, злоупотребляя сценариями Microsoft 365 OAuth и аутентификации по коду устройства (Device Code). Несмотря на публичное раскрытие этой активности, Volexity продолжает наблюдать, как российские субъекты угроз применяют схожие техники для интенсивных атак как на среды Microsoft, так и на среды Google.

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

В этой статье Volexity рассматривает две новые кампании, в которых злоумышленники использовали сценарии OAuth и Device Code для фишинга данных доступа конечных пользователей. В рамках атак создавались поддельные сайты, маскировавшиеся под реальные международные мероприятия по вопросам безопасности, проходившие в Европе. Цель состояла в том, чтобы убедить зарегистрировавшихся участников предоставить несанкционированный доступ к своим учётным записям. В кампаниях, которые наблюдала Volexity, использовались следующие реальные мероприятия:

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

Что делать, если системный CDN вашей e-commerce платформы внезапно попал под блокировки, саппорт не помогает, а корзина и галерея на сайте умерли? Рассказываю реальный кейс, как с помощью Яндекс CDN за 150 рублей в месяц, пары сниппетов и MutationObserver удалось ускорить загрузку ядра сайта в сотни раз и вернуть интернет-магазин к жизни. Честный разбор костылей, граблей и результатов в цифрах.

Год назад я уже делал обзор на девайс TerraMaster F8 Pro, если интересно то эта статья есть в моем профиле. Это довольно необычный NAS, полностью построенный вокруг NVMe-накопителей. Устройство получилось действительно быстрым, но после публикации обзора многие читатели задали вполне закономерный вопрос:

Стройку видно не по чертежам, а по бетону. У энергоцентра в Марфино появилось то, с чего начинается любая стройка, — фундамент.

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

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

В этой статье мы разберем подход, как можно решить задачу автоматической разметки владельцев ресурсов в Yandex Cloud, используя собственные сервисы платформы без привлечения других команд. Ведь в конечном итоге FinOps-специалистам метки нужны для того, чтобы привязывать данные биллинга к центрам затрат или проектам.

Закрытие периода. Вы открываете инвойс: видите счет за облако и ловите приступ паники от увиденной цифры. Обещали же, что будет меньше, почему так много? 

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

В статье расскажу, почему.