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

Привет, Хабр! Меня зовут Игорь Шишкин, я руковожу командой R&D в облачном направлении Рег.ру и являюсь архитектором наших сервисов — в этой статье расскажу, как мы создавали бэкапы в облаке. Далее о том, как выбирали инструменты для реализации, строили архитектуру и что мы делаем, когда пользователи устраивают тот еще квест — дружно решают забэкапиться в одно время.

Привет, Хабр! Меня зовут Анатолий Усов, я инженер дата-центра Рег.ру. В этой статье расскажу, чем обычно занимается инженер в ЦОДе в течение смены, с какими сложностями сталкиваемся и как устроена работа внутри нашего дата-центра.

Привет, Хабр! Мы в Рунити верим, что собеседование — не гонка за правильными ответами, а диалог на равных. В этом интервью расскажем, как мы нанимаем DevOps-инженеров в команду. Внутри о том, что мы предлагаем кандидатам вместо стресс-интервью, замысловатых тестовых и бесконечных этапов отбора. От нас — внимание к глубине опыта и интерес к подходам кандидата. 

Эксперты Рунити — Анна Попова, рекрутмент-партнер, и Тимур Парфенов, директор департамента эксплуатации, поделятся тем, как мы оцениваем инженеров, на что смотрим в резюме и какие навыки стоит подсветить. Приятного «разворачивания» статьи! 

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

С каждым новым спринтом кажется, что ты просто двигаешь тикеты по доске?
Не только тебе. Когда задачи теряют смысл, проект буксует, а мотивация тает где-то между дейликом и очередными «небольшими изменениями — вот здесь, здесь и здесь», возникает закономерный вопрос: где же те самые большие задачи, в которых хочется быть? Где простор для роста, свободы и влияния?

Если честно, мы знаем ответ. Но ведь так неинтересно! Поэтому мы нарисовали комикс о том, как карьерный тупик трёх IT-специалистов — разработчика, аналитика и DevOps-инженера — внезапно превращается в портал, за которым их ждут испытания: Legacy-Хаос, техдолг и поток данных, грозящий поглотить всё живое. Чтобы пройти их, героям понадобятся не суперсилы, а кое-что куда важнее: автоматизация, гибкие подходы и возможность делать то, что имеет значение. Погружаемся в комикс — и проверим, что будет, если карьерным мечтам действительно дать пространство для развития.

Привет, Хабр! В этом материале мы не расскажем о рабочих кейсах, технических решениях и привычных темах для нашего блога. Лучше — мы покажем немного всего этого и поделимся впечатлениями о первом Demo Day облачной команды Рег.ру. Внутри: краткое ревью докладов, анонсы новых облачных релизов, которые мы планируем к запуску, и немного фото. Полетели!

Привет, Хабр! Меня зовут Игорь Батулин, я руководитель группы разработки виртуального хостинга в Рунити. Эта статья — не просто рассказ о том, как я люблю рогейн, а пример того, как можно за несколько итераций и в условиях ограниченных ресурсов создать полезный инструмент, действительно помогающий команде принимать решения. Мой рассказ также подскажет, как можно применять Agile-подходы в реальных задачах.

Привет, Хабр! На связи Игорь Шишкин, я руковожу командой R&D в облачном направлении Рег.ру и являюсь архитектором наших сервисов. В статье расскажу, как в целом работать с S3-совместимыми хранилищами, зачем их использовать, какие бывают базовые паттерны и что с этим делать. Поехали!

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

В предыдущей статье мы начали обсуждать, что компании (всё еще) хотят разделить монолиты на микросервисы. Если спросить их, что они этим изменят — услышите, что с микросервисами рассчитывают решить проблему «большого комка грязи» или сократить time-to-market.

Далее мы обсудили, что изменения в монолитном приложении не решат вопрос «большого комка грязи», потому что реальные проблемы кроются в организации, процессах и людях, но не в технологии.  Во второй статье мы рассмотрим вопрос  time-to-market, а затем подведем итоги.

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

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

Я нахожу этот подход озадачивающим — по моему опыту, микросервисы редко решают проблемы, которые, по мнению большинства, они должны разрешить. Особенно, если внедрять их без других изменений. Я написал серию постов, в которых обсуждаю распространенные заблуждения о микросервисах. В этой серии разберем, какие проблемы не решают микросервисы, а какие — могут решить (если всё сделать правильно). А также, что мы можем сделать, если микросервисы — это не то, что нам нужно.

Привет, Хабр! Когда на сайте что-то пошло не так, все знают, что в логах можно найти причину и узнать детали происшествия. В этой статье мы разберем три примера, когда помогут логи: если сайт атакует бот, ухудшилась производительность или есть ошибка в базе данных. Если вы начинающий веб-мастер, то этот краткий гайд поможет понять, где искать информацию и как она может быть представлена. 

Привет, Хабр! Сегодня мы решили вспомнить, как раньше веб-мастера обходили ограничения разметки. История веб-разработки полна креативных находок — технологии не всегда успевали за фантазией пользователей. На заре девяностых, чтобы выделиться на фоне конкурентов, веб-разработчики искали творческие решения. Собрали подборку из 7 популярных приемов и подходов, которые использовали веб-мастера, чтобы выйти за пределы ограничений HTML.

Привет, Хабр! С вами Ксения Бычкова и Ольга Султанова из отдела тестирования Рунити. В этой статье расскажем про пирамиду тестирования и как мы внедряли эту best practice в нашей компании.

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

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

Пандемия породила удаленку, а удаленка — работу без перерывов. Когда сидишь дома, а тебе прилетают задачки, очень легко засидеться с ними до 21:00. В итоге ложишься спать в полночь, а на утро по-новой: встал — и к ноуту, кофе вместо обеда, красные глаза и ещё более сутулая спина, чем в офисе. Да, конечно, больше не надо ездить на работу: потеть в транспорте или стоять в пробке. И кажется, что вместо поездок в офис будешь качать пресс в спортзале или просто подольше спать. В реальности делаешь только одно: работаешь нон-стоп. В итоге становишься нервным, перестаешь понимать ТЗ и начинаешь спорить с коллегами по мелочам. При таком раскладе work-life balance звучит как насмешка, а работа допоздна становится частью жизни.

А что если представить ежедневную переработку в виде персонажа? Каким он будет, как будет себя вести с работниками и главное — как его одолеть? Мы вдохновились образом босса из популярной игры Dark Souls и нарисовали такого персонажа. Знакомьтесь, это босс Переработа. Он постоянно нарушает границы сотрудников и заставляет всех, кто попадется ему на глаза, работать...и перерабатывать.

Привет, Хабр! В этой статье расскажем о гиперконвергенции и как ее можно реализовать разными путями в облаке. А также просто разберемся, чем она отличается от виртуализации с контейнерами. Для начала дадим определение гиперконвергенции, далее поговорим про OpenStack и VMware и затем перейдем к деталям реализации. 

Привет, Хабр! Я — Игорь Шишкин, руководитель R&D-направления облачных сервисов Рег.ру в группе компаний Рунити. В Рунити мы прошли долгий путь от SSL-сертификатов, доменов и виртуального хостинга к VDS и VPS, а затем к собственной IaaS-платформе на базе OpenStack и Ceph. 

Сегодня я расскажу, как мы вообще выбирали SDS (Software Defined Storage), как устроена конфигурация в самом Ceph, приподниму завесу о наших процессах R&D, а также как мы тестируем решения на базе Ceph и как доставляем конфигурацию до production-окружений. Эта статья написана по мотивам моего доклада с HighLoad++ 2024, читайте подробности под катом.

OpenStack широко используется в качестве платформы IaaS с открытым исходным кодом. Служба идентификации OpenStack представляет собой компонент, основанный на централизованном подходе с использованием токенов. Она включает Memcached — KV-хранилище в памяти, которое используется для кэширования. Запросы на проверку концентрируются на централизованном сервере по мере увеличения количества токенов, зашифрованных различными способами. В этой статье мы предлагаем сервис идентификации для OpenStack, основанный на алгоритме Practical Byzantine Fault Tolerance (PBFT), который может улучшить производительность и снизить число уявимостей за счет применения подхода с использованием PBFT блокчейна.

В ходе эксперимента, проведенного с использованием Apache JMeter, было установлено, что задержка в сервисе идентификации OpenStack на блокчейне PBFT меньше аналогичных показателей стандартного сервиса идентификации OpenStack более чем на 33,99% и 72,57% соответственно при использовании 500 и 1000 различных зашифрованных токенов.