При планировании репликации, аварийного восстановления, резервного копирования и восстановления данных мы выбираем из нескольких стратегий — в зависимости от требований к уровню SLA по восстановлению данных и приложений. Ключевые факторы при выборе включают в себя целевое время восстановления (RTO) и целевую точку восстановления (RPO). Синхронная репликация дает минимальную RPO, что означает невозможность потери данных. Ceph может реализовать синхронную репликацию между локациями, «растянув» свой кластер на несколько дата-центров.  

Асинхронная репликация по своей сути подразумевает ненулевое значение RPO. В Ceph асинхронная multi-site репликация подразумевает репликацию данных в другой кластер Ceph. Каждый метод доступа к хранилищу (объект, блок и файл) обладает собственным методом асинхронной репликации, реализованным на уровне конкретного компонента Ceph.

Облако — большой и сложный продукт, поэтому и процесс тестирования может растянуться… Всем привет! На связи Галина Чупрова, главный инженер по тестированию Облака Рег.ру. В какой-то момент мы с командой поняли, что чем раньше начать тестирование — тем меньше багов получим на выходе. В статье расскажу про этапы, которые помогут устранить «узкие горлышки» в процессе проверки качества продукта и подключить команду с первых шагов проекта. Будет полезно тем, кто начинает путь в тестировании или хочет по-новому взглянуть на процессы в своих командах. Поехали проходить этот квест!

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

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

Привет, Хабр! Меня зовут Владимир Раду, я Backend-разработчик в Рунити. Однажды мы с командой встали перед дилеммой: как навести порядок внутри монолита. Админка одного из сайтов нашей группы компаний — большой и довольно возрастной проект. Он охватывает множество задач и сценариев: от управления ценами до редактирования контента. Со временем стало очевидно, что нужно снижать связанность компонентов и разводить бизнес-части. Так появилась идея перейти к модульной архитектуре.

Внутри о том, что у нас получилось из рефакторинга легаси, как мы выстраивали работу с модулями и объединяли в логичную структуру разрозненные части системы. Будет полезно разработчикам, которые работают с легаси и хотят встать на путь оптимизации проекта — без переписывания с нуля.

Вопрос: Можно ли за пару минут «на коленке» создать свою криптографическую хеш-функцию? Чтобы в результате было не подобрать входную строку? Ответ: Можно!

Привет, Хабр! На связи Игорь Батулин — руководитель группы разработки виртуального хостинга в Рунити. Когда-то с удовольствием прочитав книгу «Грокаем алгоритмы» Адитья Бхаргавы, с удивлением обнаружил, что автор не привел пример криптографической хеш-функции. Но стиль подачи материала очень напомнил мне то, как я рассказывал об этом студентам-экономистам во времена преподавания в вузе — просто и наглядно.

В этой статье поделюсь одной из моих алгоритмических практик, упражнениями-загадками и взломом коллизии.

Привет, Хабр! Меня зовут Никита Ли, я Frontend-разработчик в группе Рунити. Так тяжело бывает удержаться от того, чтобы не усложнить себе жизнь, не так ли? Все любят смотреть на чистый и понятный код, но не все его таким пишут. Сделать его таким помогают наши друзья — форматировщики и линтеры. О них и пойдет речь в этой статье, а конкретно о ESLint Stylistic.

Любой автор хочет, чтобы его кто-то читал, даже на JavaScript, но просматривать читателю хочется грамотный и красивый текст. ESLint анализирует код, выявляя ошибки, чтобы программы выходили из под клавиатуры чистыми и без ошибок. Prettier, в свою очередь, как инструмент форматирования делает текст исходного кода программ единообразным. Оба этих инструмента являются практически стандартом, когда речь заходит о качестве кода. Думаю, что многие сталкивались в проектах с их одновременным применением, что в целом логично — форматирование != линтинг. Однако это решение не всегда обосновано, а зачастую излишне. В качестве альтернативы я предлагаю рассмотреть ESLint Stylistic. В этой статье разберемся, что это, откуда появился инструмент и почему с ним стоит познакомиться.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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