Привет, Хабр! На связи Александр Ткач, руководитель группы идентификации, и Татьяна Устинова, ведущий инженер-программист в группе Рунити. Наша команда отвечает за сервисы, через которые проходит каждый пользователь: регистрация, авторизация, верификация личных данных и жизненный цикл договора пользователя.
Perl принято хоронить примерно с 2010 года. В феврале 2026-го TIOBE вернул его в топ-10 — и это немного всколыхнуло профессиональное сообщество. В группе компаний Рунити на Perl работает 25–30% продакшн-сервисов: биллинг, авторизация, очереди, ядро платформы. Расскажем, почему так вышло, что происходит, когда мы пытаемся это переписать, и почему нам за это не стыдно.
Навигация по тексту:
Сколько Perl в продакшне и зачем
Ещё в 2017–2021 годах доля Perl в сервисах группы компаний превышала 50%. Сейчас — около 25–30%: мы планомерно переводим сервисы на Python и Go, но процесс небыстрый. Дальше объясним почему. На Perl у нас реализованы:
Платформа — низкоуровневая логика работы с хранилищами, конфигами, логированием
Биллинг — ядро системы контроля и учета жизненного цикла услуг и платежей в Рег.ру и Руцентре
Жизненный цикл договора (аккаунта пользователя) — от момента регистрации до архивации
Очереди
Идентификация — сервис сверки персональных данных клиентов и предоставления привилегий по итогу прохождения идентификации
Крон-скрипты — служебная автоматизация
Справочная система и тикеты поддержки
Бэк-офис — внутренний интерфейс сотрудников
Отправка почты — для Руцентра (в процессе переписывания)
Взаимодействие с РКН
Магазин доменов — часть логики выбора домена
Двухфакторная аутентификация
Отправка SMS — используется в 2FA, напоминаниях и других сценариях
Иногда мы пишем новые сервисы на Perl — не из идеологических соображений, а из прагматичных. Жесткого запрета на язык в компании нет: при прочих равных новый сервис скорее уйдет на Python, но если команда загружена, а задача не требует тяжелого решения — пишем на Perl. Единственное условие: сервис должен отвечать общим архитектурным практикам.
Perl-экосистема предлагает Rex — инструмент автоматизации на базе Perl. Мы его не используем: к тому моменту, когда вопрос встал, уже перешли на более зрелые решения. Для тестовых сред — Ansible и docker-compose, для стейджинга и прода — Kubernetes.
Почему мы снижаем долю Perl
Дело не в недостатках языка. Просто рынок труда для Python и Go больше: проще нанять, шире поддержка сообщества, больше готовых библиотек — не нужно изобретать велосипеды.
Входной порог у Perl чуть выше, чем у Python. Большинство курсов и вузов начинают с Python, поэтому молодых специалистов с Perl-опытом мало. Те, кто знает язык глубоко, часто имеют большой опыт и на понижение в грейде не идут. С 2022 года дефицит усугубился: часть перловиков уехала или перешла в иностранные компании, где Perl востребован больше.
Еще один фактор — обновления библиотек на Perl приходят позже, чем для Python или Go. Это ощутимо, когда нужна свежая функциональность или быстрый патч безопасности.
Когда мы переписываем и что из этого выходит
Переписывание — это параллельный процесс: поддержка существующей базы идет одновременно с постепенным выносом логики в новые микросервисы. Вот несколько наших кейсов — разных по исходу.
Авторизация: получилось
Изначально авторизация на сайте Рег.ру работала на Perl с использованием фреймворка Catalyst. Старая реализация не позволяла переиспользовать компоненты авторизации нигде, кроме этого фреймворка.
Когда появился новый личный кабинет и мастера заказа, мы написали новый компонент на Python. Он работает посредником между ядровым хранилищем данных пользователя на Perl и новыми фронтенд-сервисами на JavaScript. Перловый монолит остался, но логика авторизации из него вышла.
Домены Рег.ру: получилось, но не до конца
За последние годы мы реализовали три самостоятельных сервиса на Python, которые взяли на себя значительную часть низкоуровневой регистраторской логики. Это была осознанная работа, а не просто переписывание ради переписывания. Но вынести из монолита всю доменную логику целиком — отвязать от биллинга и других частей платформы — пока не вышло.
Команда решила не выносить куски существующего кода итеративно, а сразу написать новую систему с нуля — «идеальную», на все случаи жизни. Это классическая ловушка: академически спроектированная система хорошо выглядит на бумаге, но реальные проблемы вылезают только в продакшне, и никакое моделирование их не предсказывает. Чтобы довести такое решение до состояния «можно запускать», понадобились бы еще годы — параллельно с поддержкой живого Perl-кода. Объем работ недооценили, и в какой-то момент стало очевидно, что игра не стоит свеч.
Снимки HTML: доработали вместо замены
Catalyst не обеспечивал нужную скорость открытия динамических страниц. Вместо миграции мы написали утилиту поверх него: она собирает из динамических страниц статический HTML-кэш и отдаёт его через nginx. Задача решена без переписывания.
Как устроена разработка на Perl у нас
Требования к сервисам — те же, что для Python и Go
У нас нет языковых ограничений. Сервис должен соответствовать принципам SOLID, иметь настроенный мониторинг и деплоиться в Kubernetes. Это одинаково для всех языков.
Зависимости
В Рег.ру мы ведем собственный репозиторий Perl-модулей на базе Pinto, где фиксируем нужные версии. Зависимости попадают во внутренний репозиторий только после проверки отделом безопасности — ничего не скачиваем напрямую из CPAN. В Руцентре принято собирать RPM-пакеты: установка библиотек при сборке Docker-образа происходит быстрее.
Безопасность зависимостей
Проверку на уязвимости запускаем по событию — когда в базовый образ добавляются новые пакеты. Если обнаруживается уязвимость, заводим задачу в команду разработки.
Линтинг и код-стайл
Perl::Critic мы не внедрили во всех командах — его стандарт не полностью совпадает с нашим код-стайлом. В сервисе идентификации Perl::Critic используется в CI. А в других сервисах — нет, там ручная проверка на соответствие внутреннему стандарту. Наш код-стайл для Perl можете посмотреть по ссылке, для нового кода мы стараемся придерживаться тех же правил.
Тесты
Практически все наши сервисы покрыты тестами, включая перловые. Тесты — это самодокументирующийся код: по ним можно понять, как работает компонент, даже без знания языка.
Фреймворк Test::Spec, который мы используем для юнит-тестирования на Perl, значительно упрощает написание тестов и делает их читаемее. Он опубликован на MetaCPAN, пользуйтесь! Библиотеки, которые мы разработали внутри компании, тоже лежат в открытом доступе.
Прямая речь разработчиков Рунити: что нам самим нравится в Perl
И еще один аргумент для тех, кто говорит, что Perl умер: он входит почти во все UNIX-подобные операционные системы из коробки — устанавливать отдельно не нужно. Язык, встроенный в инфраструктуру на уровне ОС, никуда не денется просто по факту своего присутствия везде.
Также Perl позволяет преобразовывать типы без явных объявлений, конвертировать хэш в массив или объект любого класса в одну операцию. Для задач обработки текста, строк и регулярных выражений это даёт скорость написания кода, которую Python воспроизводит за большее число строк. Чтение содержимого файла в массив — одна строка. Поиск и замена подстроки — тоже одна строка. Для системных скриптов это практично.
Коллеги добавляют:
«Сейчас Perl не самый популярный язык. Но если нужно работать с регулярными выражениями, он подходит как мало что другое: одной строкой делаешь то, на что в других языках уходит не один десяток. При этом это довольно естественный язык — немного разобравшись с синтаксисом, код можно читать почти как текст. Учить Perl специально для старта в разработке я бы не советовал: есть вещи, которые на современных языках делаются проще и быстрее. Но как инструмент для конкретных задач — надежный и живой»,
— Иван Клянников, разработчик Рег.ру.
«Для меня главный прикол Perl — в его гибкости: можно написать однострочник, скрипт или большую программу на десятки тысяч строк. Независимо от того, вырастет ли его популярность снова, наши компетенции останутся востребованными, а опыт пригодится при работе с другими языками. Честно скажу: при первом погружении было сложно — много непонятных символов ($, @, %) и какой-то магии. Но чем глубже изучаешь, тем больше нравится. Главный плюс сейчас — приятный и понятный синтаксис, если соблюдать хороший код-стайл. Главный минус — нет современных платформ и курсов для изучения»,
— Илья Тещин, разработчик Рег.ру.
Как попадают на Perl-разработку
Сейчас в нашей группе компаний около 30 Perl-разработчиков — по меркам рынка это немало. Пополняем двумя путями.
Наём извне — сложный. Молодых специалистов с Perl мало, опытные часто не готовы к смене грейда. Поэтому всё активнее растим своих.
Переход внутри — рабочая история. Например, Татьяна пришла в компанию питонистом и два года писала на Python. А когда ее проект завершился, перешла в команду, где основная часть задач — на Perl:
«С самим языком я познакомилась ещё на Python-проекте — нам нужно было переписывать код с Perl на Python, так что сначала только читала. Когда перешла в новую команду, нужно было уже писать. Но гораздо сложнее оказалось не выучить язык, а погрузиться в логику проекта — она намного сложнее самого языка».
В 2025 году мы провели внутреннюю стажировку по Perl. Из 20 участников отобрали троих — они сейчас работают Perl-разработчиками в наших командах.
Онбординг строится на документации и тестах: почти каждый сервис покрыт описанием архитектуры и бизнес-требованиями. Если что-то непонятно — идут к тимлиду с конкретным вопросом.
Идентификация: актуальный кейс
Наш сервис идентификации написан на Perl. Он верифицирует персональные данные пользователей.
Например, сейчас в разделе «Настройки» личного кабинета Рег.ру клиент может пройти идентификацию через ЕСИА: заполнить контактные данные владельца аккаунта автоматически, без загрузки документов и ручной проверки. Данные передаются по защищенному соединению, доступ только к разрешенным законом сведениям. Есть и функция актуализации — она позволяет в пару кликов получить обновленные данные от Госуслуг, если что-то изменилось.
Сейчас функционал доступен для физических лиц, в перспективе — расширение на юридические лица и ИП. В декабре 2025 года в законодательство внесли изменения: с сентября 2026 года идентификация через Госуслуги станет обязательной для администраторов доменов при операциях с доменами. Инфраструктура для этого у нас уже готова — и написана на Perl.
Если остались вопросы про наш Perl, архитектуру или процессы переписывания — пишите в комментарии, постараемся ответить.
