Привет, Хабр! На связи Игорь Шишкин, я руковожу командой 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 различных зашифрованных токенов.
Привет, Хабр! Сегодня мы решили рассказать, как ищем людей в команду облачной платформы Рег.ру. Анна Попова, рекрутмент-партнер Рунити, Игорь Шишкин, руководитель отдела разработки облачной платформы Рег.ру, и Анна Абрамова, руководитель направления разработки облачных решений Рег.ру обсудили, стоит ли предлагать кандидатам тестовое задание, как реагировать на выгорание, и какие ред флаги сигнализируют, что с этим человеком компании не по пути.
Привет, Хабр! Я — Евгений Мартынов, директор по информационным технологиям Рег.ру. В последние пару лет я занимаюсь развитием облачной платформы. Сегодня я расскажу, как мы перезапустили это направление, с какими трудностями столкнулись и какие решения нашли. Дисклеймер: непосредственно грабли начну описывать во второй половине статьи, сначала расскажу, на каких принципах мы изначально строились в надежде избежать ошибок.
Привет, Хабр! Меня зовут Анна Асабина, я занимаюсь тестированием бэкэнда доменного направления в Рунити. В этой статье мы затронем основные понятия Test Management System и поговорим о плюсах и минусах внедрения TMS в проект. Также решим, какие важные черты должны присутствовать в качественной TMS. И, конечно же, расскажу о нашем пути к TestRail: как внедряли и на каких конкретных примерах используем.
Привет, Хабр! Сегодня мы попробуем развернуть простой сервис в Kubernetes на примере KaaS в облачной платформе Рег.ру. В качестве самого сервиса будем использовать imgproxy — минималистичный сервис подготовки изображений для web с предельно простым API.
Этот гайд будет полезен новичкам, которые только начинают работу с Kubernetes. Рассмотрим, как настраивать среду и управлять ей, и освоим принципы работы с контейнерами. Кроме того, развертывание imgproxy в качестве примера поможет научиться обрабатывать изображения с помощью Kubernetes простым и удобным способом.
Привет, Хабр! С вами Сергей Рыжков, руководитель департамента хостинга и профессиональных сервисов Рег.ру, и Александр Михеев, ML-engineer РБК. В этой статье расскажем, как мы автоматизировали процесс тегирования редакционных материалов РБК с помощью нейросети в облаке Рег.ру. О первых результатах нашего эксперимента читайте под катом.
Привет, Хабр! С вами снова Евгений Мартынов, директор по информационным технологиям Рег.ру. Сегодня расскажу, как мы переезжали в онлайн в Петербурге.
Год назад, осенью 2023, мы открыли площадку в Санкт-Петербурге на базе дата-центра оператора ОБИТ. Научились с нуля поднимать всю инфраструктуру облака, организовали новые каналы связи.
Запуск шел не очень гладко, но мы успешно дожали эту задачу и сделали выводы, чтобы не повторять ошибки. За год площадкой воспользовалось несколько тысяч наших клиентов, и на текущий момент мы имеем около 1300 активных услуг в этой локации.
А далее мы запланировали экспансию в другие регионы, и она проходит успешно.
В какой-то момент даже стало казаться, что стройка и переезды скоро закончатся. Но как говорится, хочешь рассмешить Бога, расскажи ему о своих планах. Через неполный год мы узнали о готовящейся застройке территории, где расположена площадка с локацией публичного облака в регионе Санкт-Петербург. Пришлось искать новую.
Привет, Хабр! Меня зовут Дмитрий Виноградов, я руковожу направлением продуктовой разработки в Рунити, а если проще — то разработкой сайтов и витрин компании. Я и моя команда находимся в постоянном поиске удобных подходов к разработке технических решений. В этой статье расскажу о продуктовых практиках в нашей группе компаний, а также подробнее разберемся, как создавать независимые компоненты, чтобы ускорить frontend-разработку.
