При масштабировании инфраструктуры вчерашние рабочие процессы часто превращаются в архитектурные. Линейный рост затрат на хранение, проблемы консистентности СУБД при восстановлении из снапшотов и зависимость от закрытых API — это реальность, в которой живут многие команды. Ситуация усложняется, когда бэкапы становятся целью для атак, а стандартного контроля доступа оказывается недостаточно. В релизе Хайстекс Акура 4.5 мы собрали инструменты, которые делают инфраструктуру по-настоящему автономной и защищенной. Под катом — подробнее о каждом из них.  

Как только очередной вендор обещает «убить нативные тулзы PostgreSQL», где-то устало вздыхает DBA. Попытка сделать бэкап PostgreSQL «лучше самого PostgreSQL» — это изначально неверная постановка задачи. 

Универсальный файловый агент не притворяется глубоко PostgreSQL-aware решением. Его задача в другом: взять нативные механизмы СУБД и превратить их в управляемый и наблюдаемый процесс на уровне всей инфраструктуры.

Вокруг такого подхода обычно сразу возникают неприятные, но правильные вопросы. Кто отвечает за консистентность? Где на самом деле живет PITR? Что будет, если потеряется WAL-сегмент? Можно ли восстановить одну таблицу, а не весь инстанс? И зачем вообще нужен внешний слой поверх pg_probackup, если у PostgreSQL уже есть свои зрелые инструменты?

Под катом — честный разговор о границах ответственности между PostgreSQL и внешней платформой.

Представьте: вы прыгаете с парашютом, дергаете кольцо, а из ранца вместо купола вылетает записка: «404: Not Found». В ИТ-инфраструктуре бэкап — именно такой парашют. И проблема в том, что 90% инженеров уверены: раз ранец за спиной висит, значит, гравитация им не страшна. Мало кто проверяет его «укладку» (валидацию) и тренирует само приземление (DR). Чаще всего процесс строится либо на слепой вере в собственную память, либо на тотальном доверии древним скриптам, которые DevOps-археолог написал еще пять лет назад. В момент свободного падения времени на исправление конфигов этих скриптов уже не будет. Поэтому под катом — краткая инструкция по «укладке парашюта»: быстро и без воды про классические ошибки и как их обойти.

Классическая бытовая дилемма: после ужина в раковине лежат две тарелки. Загружать посудомойку кажется избыточным оверхедом — быстрее сполоснуть руками. Но если вы только что приняли званный ужин на 10+ персон, ручная мойка уже покажется более утомительной.

В инфраструктурных задачах этот «парадокс посудомойки» преследует нас постоянно. Когда нужно мигрировать пару виртуальных машин, инженеру проще и быстрее сделать всё руками, чем настраивать сложные паплайны. Но сегодня, на фоне массового импортозамещения, смены гипервизоров (привет, VMware!) и курса на построение гибридных сред, масштаб задач изменился. В условиях миграции сотен ВМ привычка полагаться на ручной труд становится непозволительной роскошью.

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

Привет, Хабр! Я Виктор, в Хайстекс руковожу отделом разработки. Сегодня расскажу про фичу, которая снимает ложную дилемму «API или универсальность», потому что оба сценария можно применять параллельно.

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

Под катом — как сделать целевую сторону миграции воспроизводимой без зависимости от API конкретного облака и без ожидания поддержки со стороны платформы.

Привет Хабр! Если вам тоже доводилось разбирать незнакомый проект, сопровождать прод или помогать QA, вы знаете, как быстро начинаешь ненавидеть однообразные команды etcdctl: копировать ключ, вбивать get, ловить в терминале многострочные значения, скроллить историю… Особенно если ключей сотни, а половина из них — конфиги или JSON’ы на несколько экранов.

Мне хотелось чего-то попроще: запустил один бинарь в терминале и спокойно ходишь по дереву ключей etcd, как по файловой системе, подобно mc.

Без браузера, без копипаста, с нормальным просмотром и редактированием многострочных значений. Так появился etcd-walker.

Под катом расскажу, как он устроен, почему в etcd v2 внезапно пропадают ключи, которые начинаются с подчеркивания, как их всё-таки увидеть, зачем понадобилась “инъекция” узлов, и как решить боль с большими многострочными ключами, например JSON или yaml. А также покажу, как этот инструмент помогает разбираться с локами, которые создает python библиотека для работы c etcd.

Если вы хоть раз пробовали разгрести чужое хранилище в etcd, то поймёте, почему без подобного инструмента жить уже не хочется.

Привет Хабр! Я Иван, QA в Хайстекс. Уже несколько лет занимаюсь тестированием и внедрением решения Акура.

Этот материал родился из практики. Внутри компании мы регулярно поднимаем решения в OpenStack для тестов, пилотов и внедрений, и часто сталкиваемся с одними и теми же вопросами. Где-то не тот порт, где-то нестандартный эндпоинт, где-то сеть устроена чуть иначе, чем ожидаешь. Мелочи, которые на старте могут съедать часы.

Под катом – полное, пошаговое руководство по подготовке OpenStack и развертыванию контроллера Акуры. Это не документация в классическом смысле, а рабочий конспект. Поэтому по ходу статьи разберем процесс подготовки OpenStack и покажу, на что стоит обращать внимание при развертывании решений в этом окружении. Попутно затронем особенности платформы, которая остается одним из самых популярных open source облаков.

С 13 по 17 октября Дубай снова стал тех-точкой притяжения. GITEX Global обновил планку: 6800+ компаний, около 2000 стартапов, делегации из 180 стран. 45-й выпуск прошёл под знаком ИИ и киберустойчивости.

Мы с командой Хайстекс провели на площадке два дня. Про первый уже писала тут, а во второй я постаралась сфокусироваться на бэкапе, DR и всём, что касается устойчивости и непрерывности ИТ-инфраструктуры. Под катом про то, куда двигаются лидеры, какие решения показали и что из этого ложится на наш локальный рынок.

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

Инфраструктурные сбои всегда были частью реальности, но теперь стали частыми. Масштабы разные, но вывод один: полагаться только на бэкап — всё равно что держать огнетушитель и верить, что им удастся потушить пожар целого здания. И если бэкап — это огнетушитель, то DR (disaster recovery) — это план эвакуации. Бэкап может «сбить пламя в одной комнате», но если «горит весь этаж» — без плана выбраться из здания шансов мало. Сегодня, когда практически любой бизнес завязан на IT, наличие рабочего плана аварийного восстановления перестало быть «опцией для корпораций». Это обязательный элемент выживания. Вопрос только в том, готова ли ваша инфраструктура к сбою?

Привет, Хабр! Я Саша, в Хайстекс отвечаю за B2B-продажи и давно работаю с облаками и бэкапом. В этой статье хочу рассказать о подходе, который, на мой взгляд, помогает закрыть одну из самых болезненных задач в этой области. 

При работе с облачными сервисами часто приходится идти на компромисс: либо хранить дешево, но восстанавливать долго, либо платить за скорость. Допустим, у одного eCommerce-сервиса внезапно упал гипервизор, с ним ушли в офлайн несколько ВМ. Все бэкапы хранились в S3-объектном хранилище. Чтобы восстановить ВМ придется разворачивать ее из архива. На все в среднем уходит около 40 минут. Все это время система заказов лежит, а бизнес считает убытки. С Double Storage мы сделали так, что время восстановления сократилось до 6-8 минут. Что это за технология, как она работает и почему с ней действительно проще – разберём под катом. Технические подробности можем разобрать в комментариях, если будет интерес.

Перевод статьи Патрика Косса о том, как ИИ, edge-компьютинг, serverless и мультиоблачные стратегии меняют облачную инфраструктуру. Автор подчеркивает, что речь идет не о постепенной эволюции, а о настоящей трансформации, которая уже влияет на стратегию крупнейших компаний и задаёт новые правила игры.

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

Новые данные показывают, что глобальные расходы на публичные облачные сервисы достигнут $723,4 млрд в 2025 году, что составляет рост на 21% по сравнению с $595,7 млрд в 2024 году.

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

Привет, Хабр! Меня зовут Антон, я фронтенд-разработчик в Хайстекс. Это моя первая статья здесь, и, возможно, вы ожидали от новичка что-то более привычное вроде: разбор фреймворка, гайд о том как пропатчить kde под freeBSD или очередную историю «как мы переписали проект на TypeScript». Но я решил начать с другой темы.

Почему? Потому что программирование – это не только про код. Любой, кто работает в IT, знает: можно выучить все нужные библиотеки и паттерны, но если у тебя нет сил вставать по утрам, голова перегружена задачами и ты живешь от дедлайна до дедлайна, то толку от этих знаний мало. И вот тут появляются британские учёные (кто бы сомневался), которые в феврале этого года опубликовали подробный доклад о том, как бразильское джиу-джитсу развивает дисциплину, устойчивость и даже эмоциональный интеллект. Похоже на слишком смелую гипотезу, но эксперимент в моём случае удался.

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

Привет Хабр! Меня зовут Юлия Воробьева, и уже больше 10 лет я занимаюсь тестированием. За это время успела поработать в проектах, связанных с восстановлением, миграцией и резервным копированием данных. Я много занимаюсь облачными технологиями и получаю от этого настоящее удовольствие. Последние 6 лет я работаю в компании Хайстекс, где продукт и задачи позволяют мне не просто тестировать, а прокачивать экспертизу и при этом сохранять интерес к облачным решениям.

В этой статье расскажу, как мы настроили, внедрили и протестировали резервное копирование с решением Хайстекс Акура и S3-хранилищем от Selectel, на основе реальных требований и возможностей компании-клиента. Покажу, как это выглядит на практике глазами QA.

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