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

Привет, Хабр! Это вторая часть большой статьи, где мы — Егор Салиев и Николай Пушкарев, DevOps-инженеры Hilbert Team, — рассказываем, как построить GitOps-платформу на Argo CD.

В первой части разобрали базу: познакомились и установили Argo CD, изучили его компоненты и показали установку через Helm и Terraform. В этой — перейдём к практике и ответим на вопрос, что делать, когда команда растёт вместе с количеством приложений и усложняется инфраструктура. Пройдём по сценариям от маленькой команды до большой организации и соберём рабочую GitOps-модель на Argo CD.

Многие компании реализуют GitOps-подход как часть внутренней Developers Platform. Он помогает унифицировать и автоматизировать доставку кода, повысить надёжность деплоя и дать разработчикам удобный интерфейс для работы с инфраструктурой. Один из самых популярных инструментов для этого — Argo CD.

Статья основана на воркшопе Егора Салиева и Николая Пушкарева, DevOps-инженеров Hilbert Team, проведённом на DevOps Conf 2025. В ней мы разберемся, как внедрить Argo CD и его ключевые компоненты, чтобы построить масштабируемую GitOps-платформу.

Материал будет в двух частях. Он будет полезен разработчикам и DevOps-инженерам, которые хотят понять, с чего начать внедрение GitOps в команде, организовать инфраструктуру под разные масштабы, а также всем, кто ищет способы унификации деплоя.

Основной метрикой разработки является time-to-market. На него все молятся как на священную корову: считают дни до релиза, выстраивают CI/CD, внедряют DevOps. А вот про то, как быстро можно начать экономить на инфраструктуре после того, как заметили перерасход, почему-то никто не думает. Будто так и надо. Хотя спустить облачный бюджет можно едва ли не быстрее, чем в кафе на Патриках. Стало быть, если time-to-market для облаков не существует, его надо придумать.

Представьте, что вы написали скрипт, разместили его как serverless-функцию и неожиданно получили счёт на 75 000$ из-за самой простой ошибки обработки исключений. Представить страшно, а ведь это реальная история.

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

Как потратить почти полмиллиона долларов, чтобы собрать в центре Сан-Франциско хранилище данных объёмом 30 петабайт

Мы собрали в центре Сан-Франциско центр для хранения данных с общим дисковым пространством, где хранятся видеоданные общей длительностью 90 миллионов часов. Зачем? Мы предобучаем модели, чтобы разобраться с использованием компьютеров. Дело в том, что видео гораздо крупнее, чем текстовые данные. Например, на обучение такой текстовой БЯМ как LLaMa-405B требуется ~60 ТБ текстовых данных, а на хранение видео нужно в 500 раз больше текстового пространства. За хранение всей этой информации на серверах AWS пришлось бы выложить 12 миллионов долларов в год, поэтому мы пошли другим путём и арендовали пространство в колокационном центре в Сан-Франциско. Так нам удалось снизить эти расходы примерно в 40 раз (до $354 тысяч в год, считая издержки на устаревание).

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

Попробуйте как-нибудь чисто из спортивного интереса объяснить жене, почему в прошлом месяце ваш интернет стоил не 900 рублей, как обычно, а 90 000. Аттракцион, прямо скажем, диковатый, но примерно в таком же положении оказывается ваш ИТ-дир, когда видит счета от всех облачных сервисов одновременно. Что не так? Да примерно все. Каждый провайдер считает по своим правилам, выставляет счет в собственном формате, из-за чего объяснить, за что именно платим, оказывается просто супер-сложно. Но ведь не будешь складывать все яйца в одну корзину. Значит, нужно решать этот вопрос как-то по-другому.

Помните ту историю про дом на песке? С хостингом та же логика.

Три года работы с клиентом. Контент идеальный. Ссылки качественные. Техническая оптимизация безупречная. Но сайт еле ползёт. TTFB — 2300 мс. Google Search Console кричит «Медленная загрузка страниц». Отказы — 72%. И вот Вы понимаете: всё дело в shared-хостинге за 199 рублей, где сервер отвечает как уставший госслужащий в пятницу вечером.

Переезд на VPS за 890 рублей. Месяц — и сайт в топ-5.

Google официально подтверждает: Core Web Vitals влияют на ранжирование с 2021 года (источник: Google Search Central). Это не «может повлиять». Это влияет. Largest Contentful Paint (LCP), Interaction to Next Paint (INP), Cumulative Layout Shift (CLS) — все эти метрики завязаны на то, где и как работает Ваш сайт.

Google использует Core Web Vitals как фактор ранжирования для оценки пользовательского опыта, и сайты с хорошими показателями получают преимущество в поисковой выдаче.

TTFB в 200 миллисекунд или в 1500? Эта разница — пропасть. Для пользователя. Для Google. Для Вашего бизнеса.

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

Хотите лайфхак, как выбесить финдира? Забудьте про задержки в релизах, падения продакшена и критические баги. Все это мелочи. Если хотите по-настоящему вывести его из себя, возьмите за правило никогда не отключать на выходные тестовые инстансы, разверните staging-среду на том же железе, что и продакшен, и настройте автобэкапы сразу в 2-3 региона. А когда получите счет за облако на 800 тысяч вместо 300, надменно спросите – “А при чем тут я?”. Звучит как вольный пересказ “Вредных советов” Г. Остера, согласен. Да и мы с вами не в третьем классе, а значит, вредительско-инфантильный подход к работе просто не допустим. Поэтому в команде надо с самого начала развивать культуру разумного потребления облачных ресурсов, чтобы и код писать с удовольствием, и финансистов до нервного срыва не доводить.

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

Сентябрь — месяц фундаментальной работы. Пока природа меняет краски, мы закладываем основу для будущей мощности наших ЦОДов в Марфино и Мытищах. Если только присоединяетесь к нашей стройке — добро пожаловать в предыдущие выпуски: раз, два, три, четыре, пять, шесть, семь.

Пусть плюнет в меня IT-директор той компании, который ни разу не задумывался о переходе в облако. Ну, а что? С одной стороны, это должно быть выгодно. Конечно, есть кое-какие вопросики к безопасности, но ведь люди пользуются – и ничего. С другой стороны, переход на облачную инфраструктуру вроде как требует пересмотреть модель бюджетирования. А так не хочется. Да и надо ли? В общем, вопросов, ответы на которые формируются на основе слухов или давно неактуальных данных, хватает. Поэтому мы собрали 10 самых распространенных мифов об облаке, чтобы выяснить, где правда, а где домыслы, не имеющие ничего общего с реальностью.

Выпуск 446

Сильная поляризация импульсов долгопериодического радиотранзиента с белым карликом.

Открыт новый долгопериодический радиотранзиент. Период 841 секунда. Открытие сделано на LOFAR. Также источник виден и в УФ, что может говорить о том, что это белый карлик. Тогда он должен быть в двойной, но компаньон не виден, так что, видимо, это маломассивный красный карлик.

Интересно, что источник выдает импульсы, у некоторых из которых 100-процентная круговая поляриация, а у некоторых - линейная. Импульсы узкие - не более 10 секунд, - около 1% от периода и меньше.

Есть интересная квазипериодичность в приходе импульсов, что авторы связывают с тем, что источник находится в двойной системе.

Также источник обнаружен на CHIME, arxiv:2507.05139. В этой статье также указывается на раскрутуку источника. Т.е., период уменьшается. Авторы предполагают такие идеи: или есть аккреция, раскручивающая объект, или это орбитальный период, и тогда "виноваты" гравитационные волны. В принципе, можно добавить еще одну идею: молодой сжимающийся белый карлик (вроде того, что мы идентифицировали раньше: arxiv:1711.02449). Тогда это должен быть молодой (не старше примерно 100 000 лет) объект.

В мире баз данных, где каждая миллисекунда на счету, а объемы информации растут как на дрожжах, выход PostgreSQL 18 стал настоящим подарком для разработчиков и администраторов. Это не просто косметический апгрейд, а глубокая перестройка подкапотных механизмов, от облачных хранилищ до высоконагруженных OLAP-систем. Давайте разберемся, что там в этом релизе появилось и/или изменилось.

Привет, Хабр! На связи Тимур Парфёнов, директор департамента эксплуатации Рунити. Сегодня поговорим о Kubernetes. Точнее — о том, почему он стал стандартом де-факто для оркестрации контейнеров и зачем большинству проектов нужен Kubernetes как сервис (KaaS). Статья будет особенно интересна тем, кто еще не знаком с K8s или только планирует его использовать в разработке. Ну, а старичков приглашаю тоже — присоединиться к обсуждению болей и радостей этой технологии.

По данным рыночных исследований, только треть организаций точно знает, на что тратится их облачный бюджет. Остальные 80%+ косплеят лося, несущегося по горящему лесу — их ведет судьба. В конце месяца они получают счет за облако, но разобраться, кто и на что потратился, у них не получается. Да и как тут разобраться, если одни команды экономят и оптимизируют, другие боятся пожертвовать ресурсоемкими экспериментами, а третьи просто забывают выключить тестовые среды?

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

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

Облачный рынок в России растет очень стремительно. Только в 2024 году он достиг 392 миллиардов рублей, увеличившись на 26% год к году. Впечатляет, правда? Значит, все больше компаний предпочитают облако. Но чем популярнее оно становится, тем сильнее проявляется проблема перерасхода финансов. Исследования показывают, что 67% организаций тратят на обслуживание облачной инфраструктуры больше, чем было запланировано. То есть с одной стороны все получили гибкость, масштабируемость и отсутствие головной боли с апгрейдом и обслуживанием. А с другой — непредсказуемость расходов, потому что старые методы финпланирования в облачной среде работают примерно как Tesla на дровах. И с этим надо что‑то делать.

Выпуск 445

Обзор arxiv:2506.20436 Нуклеосинтез и химическое обогащение галактик (Nucleosynthesis and the chemical enrichment of galaxies)Authors: Chiaki KobayashiComments: 34 pages, 29 figures/videos. This is a pre-print of a book chapter for the Encyclopedia of Astrophysics (edited by I. Mandel, section editor F.R.N. Schneider) to be published by Elsevier as a Reference Module 

Большой обзор по химической эволюции галактик. Рассмотрен вклад разных механизмов обогащения межзвездной среды тяжелыми элементами (сверхновые разных типов, проэволюционировавшие звезды, слияния нейтронных звезд и т. д.). Разве что нет свежей идеи о синтезе элементов при вспышках магнитаров. 

Много полезных рисунков. Очень хорошо для использования в разных лекциях.

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

Прямо сейчас российская ИТ-сфера переживает довольно противоречивый период. С одной стороны, объем облачного рынка достиг 165 млрд рублей в 2024 году, прибавив за предшествующие 12 месяцев почти четверть. С другой, мы видим отчетливую тенденцию на строительство собственных дата-центров, к которой присоединяется все больше компаний, в том числе весьма крупных. Они вкладывают миллиарды в создание железной инфраструктуры. То есть фактически речь идет о двух разнонаправленных трендах, развивающихся параллельно друг другу. Вопрос только в том, кто же прав?

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