Наш сооснователь и CPO Максим Хатов взял интервью у нашего технического директора и сооснователя Владислава Кобазева. Вот что из этого вышло.
Расскажи, чем ты занимался до запуска Hard Practice?
До HardPractice я учился в университете МИСиС на C#-разработчика. Но довольно быстро обучение начало разочаровывать. Программирования было крайне мало — буквально несколько лекций за семестр. В основном это были физика, математический анализ, линейная алгебра и аналитическая геометрия. В какой-то момент я столкнулся с первым серьёзным кризисом отношения к IT. Возникло ощущение, что всё это не имеет большого смысла, и даже появилась мысль всё бросить и пойти работать барменом. Особенно демотивировали непрофильные предметы. Кроме того, тогда я совершенно не понимал, как устроена индустрия. Были студенты, которые уже пришли с опытом, и для них всё происходящее выглядело как разминка. И были такие, как я — без базы. Не хватало «среднего уровня», из-за чего казалось, что IT — это что-то для избранных.
Как ты попал в индустрию?
Переломный момент произошёл, когда я попал на стажировку в МТС. Интересно, что на собеседовании я не смог ответить почти ни на один вопрос — я даже не знал, что такое Linux. Тем не менее, тогда активно набирали стажёров, и меня всё-таки взяли. Причём сразу на DevOps-направление, хотя на тот момент я даже не понимал, что это такое. Сам термин я впервые услышал прямо на собеседовании. Первые недели были довольно тяжёлыми. Я быстро понял, что нужно срочно догонять базу. В итоге полностью пересобрал свой режим: днём работал по восемь часов, а вечером ещё столько же учился, разбирая всё, с чем сталкивался на работе. Именно тогда я познакомился с ключевыми вещами, такими как Docker, сборка приложений, CI/CD на базе GitLab, Jenkins, базы данных и серверная инфраструктура. Постепенно стало приходить понимание, как всё устроено, и вместе с этим вернулся интерес к IT.
Когда ты почувствовал, что начал «вкатываться»?
Достаточно быстро. За счёт интенсивного погружения я прошёл стажировку за четыре месяца вместо полугода и перешёл в штат на позицию junior DevOps-инженера. После этого я продолжил работать и получил первый серьёзный опыт. В частности, я вёл проект по объединению двух крупных команд, которые занимались парсингом данных. Одна команда работала на Python, другая — на Java, и нужно было объединить их инфраструктуру. Это был один из самых сложных проектов в моей практике на тот момент. Сроки были жёсткие, и всё нужно было закончить к декабрю. Я хорошо помню последний рабочий день перед Новым годом: офис уже пустой, все разошлись, а я заканчиваю свою часть работы около десяти вечера. Когда всё удалось закрыть в срок и я отписал лиду и продукту, это было первое сильное чувство профессионального удовлетворения — понимание, что ты действительно справился с задачей и довёл её до конца.
Почему ты решил сменить работу?
Уже в январе я начал искать новую работу и в итоге перешёл в Т1. Причина была довольно прагматичной. Я понимал, что в крупной компании вроде МТС многие процессы уже выстроены. Те технологии, с которыми мне хотелось глубже работать, такие как Kubernetes, Kafka или кластеризация PostgreSQL, чаще всего уже были развёрнуты и поддерживались отдельными командами. В итоге роль DevOps-инженера часто сводилась к тому, чтобы запросить доступ или ресурсы, а не строить систему с нуля. Мне же хотелось быстрее нарастить практический опыт и глубже разобраться в технологиях. Поскольку у меня не было собственной лаборатории и ресурсов для самостоятельных экспериментов, я решил искать работу, где смогу получить этот опыт в реальных условиях.
Что изменилось, когда ты перешёл в Т1?
В Т1 я уже гораздо глубже погрузился в практическую работу. Это компания-интегратор, и я попал в команду внедрения, где мы разворачивали решения на стороне заказчиков с разными требованиями и инфраструктурой. Именно там я начал системно изучать Kubernetes с нуля через практику. Я занимался развертыванием кластеров, их администрированием, настройкой хранилищ и интеграцией сервисов. Также подключал инструменты вроде Vault для управления секретами. Параллельно приходилось выстраивать инфраструктуру под конкретные проекты, писать CI/CD-пайплайны, поднимать кластеры Kafka и PostgreSQL и продумывать архитектуру решений с нуля. Одним из самых значимых проектов стала разработка полностью автономного решения для заказчиков с изолированной инфраструктурой. Речь шла о средах без доступа к интернету, например в банковском секторе. Я разработал собственный инсталлятор, который позволял развернуть всю инфраструктуру одним скриптом. В него входили GitLab, хранилище артефактов, базы данных, брокеры сообщений, Redis для кэширования и Kubernetes-кластер. Все зависимости подтягивались локально, без внешнего доступа. В результате заказчик получал полностью автономную систему, которой мог управлять независимо. С технической точки зрения это был один из самых масштабных и сложных проектов в моей практике. В Т1 я проработал около двух лет. Это был очень интенсивный этап, который дал мне сильную практическую базу. Именно там у меня сформировалось понимание того, как в реальности строится инфраструктура под разные требования и в разных условиях. После этого я решил двигаться дальше и попробовать себя в роли ведущего специалиста.
Почему ты выбрал X5? И чем там занимался?
Я перешёл в X5 Group, потому что хотел не только внедрять готовые решения, но и создавать собственные. Хотелось больше свободы в том, чтобы развивать внутренние инструменты и пробовать новые подходы. В X5 я сосредоточился на разработке и внедрении внутренних инженерных решений. В частности, я начал работать с инструментами на базе LLM и пробовать интегрировать их в инфраструктурные процессы. Например, я сделал интеграцию Kubernetes с K8sGPT — это инструмент, который анализирует состояние кластера и формирует человекочитаемый отчёт о проблемах. Также я разработал «умный» CI/CD-пайплайн на базе GitLab. Он анализировал структуру репозитория и автоматически подключал нужные шаблоны сборки. Под капотом это работало так: система определяла, какие файлы есть в проекте, какой стек используется, и на основе этого формировала базовый пайплайн. Это особенно хорошо подходило для новых или типовых проектов. В более сложных случаях требовалась дополнительная настройка. Полностью довести это решение до универсального инструмента я не успел, но даже в базовом виде оно уже использовалось внутри команды. Это был переход от роли исполнителя к роли человека, который начинает создавать собственные решения и делиться ими с другими. Именно этот опыт в итоге стал фундаментом для запуска HardPractice.
Насколько задания в HardPractice связаны с твоим реальным опытом?
Напрямую! Многие задания основаны на моём личном опыте и опыте коллег. Конечно, это не буквальное воспроизведение конкретных кейсов. Мы создавали задания по памяти, спустя время. Но ключевые паттерны, ошибки и ситуации, с которыми я сталкивался, в них сохранены довольно точно. Хороший пример — задания, связанные с Docker и Docker Compose. Они во многом выросли из моего опыта работы в МТС. Там было много проектов, особенно связанных с парсингом данных, которые разворачивались через Compose. Внутри одной системы могло быть много контейнеров, связанных между собой сетью, и всё это требовало аккуратной настройки. Очень часто возникали простые, но критичные ошибки. Например, связанные с сетью или с конфигурацией окружений. Одно из заданий на платформе как раз построено вокруг неправильно настроенной Docker-сети. Это отражает реальные ситуации, когда разработчики используют разные конфигурации для разных сред или переопределяют настройки через override-файлы. Опыт моих друзей из индустрии тоже пригодился. Например, задания, связанные с GitLab и раннерами, во многом вдохновлены реальной ситуацией, которую я разбирал вместе с коллегой из Т1. Мы несколько часов пытались понять, почему раннеры не работают на стороне заказчика. В итоге нашли причину, и такие типовые, но неочевидные проблемы легли в основу заданий.
Насколько задания близки к реальности?
Мы стараемся держать баланс. С одной стороны, задания основаны на реальных кейсах и повторяют типичные ошибки и паттерны мышления. С другой — мы не воспроизводим ситуации один в один и не раскрываем все детали, чтобы не превращать задания в спойлеры. Но в целом ключевые практики и реальные сценарии в них сохранены.
Подходит ли HardPractice новичкам?
Когда я задумывал HardPractice, я делал его в первую очередь для себя. Мне нужна была платформа, на которой можно быстро воспроизводить реальные кейсы. При этом ко мне часто приходили знакомые, не связанные с IT, которые хотели начать. И я заметил, что классические курсы, несмотря на хорошую структуру, часто не дают понимания причинно-следственных связей. Ты изучаешь теорию, но не всегда понимаешь, как одно действие приводит к другому и как это складывается в результат. Мне бы хотелось предложить альтернативный подход, вдохновленный моим опытом. Проще, наверное пояснить на примере. Один из ключевых моментов был в первый день работы в МТС, когда мне показали, как запустить обучалку по Docker через контейнер. Я просто скопировал команду, вставил её и сразу увидел результат. Я не до конца понимал, что происходит, но увидел связь между действием и результатом. И именно это вызвало интерес. Сначала ты что-то делаешь, потом видишь результат, а уже потом хочешь понять, как это работает. Ну и про теорию, само собой, забывать тоже нельзя.
Как это реализовано в HardPractice?
В основе платформы лежит ситуация, в которой что-то сломано или не доведено до конца. У пользователя есть задача, есть проблема, которую нужно исправить. При этом нет одного правильного пути. Можно прийти к результату разными способами. Важно не то, как именно ты пришёл, а то, что ты получил результат. При этом пользователь получает мгновенную обратную связь. Даже если ты сделал что-то не до конца понимая, сам факт того, что получилось, становится точкой опоры. После этого уже проще углубляться — в каждом задании есть ссылки на полезную инфу по теме. Кроме того, такой формат лучше соответствует тому, как люди сегодня воспринимают информацию. Долгие теоретические блоки воспринимаются тяжело, и к ним нужно приходить постепенно.
Какую роль играет формат заданий?
Задания короткие и сфокусированные. Обычно выполнение занимает около 15 минут, за которые ты делаешь действие и видишь результат. При этом можно решать задачу по-разному, можно пойти глубже и попробовать разные подходы.
Кому это подходит?
Не только новичкам. Этот подход работает на любом уровне. У всех есть зоны, которые хочется разобрать глубже. Я, кстати, не исключение — сам часто ловил себя на мысли, что читаю что-то интересное и хочу попробовать это руками. HardPractice даёт мне такую возможность.
Какие у сервиса планы по развитию?
Сейчас мы хотим максимально покрыть реальные инфраструктурные сценарии. Активно работаем над заданиями с полноценными Kubernetes-кластерами, с разделением ролей, сетями, хранилищами и всей сопутствующей инфраструктурой. Нам важно не использовать упрощённые решения, а воспроизводить реальные условия, максимально приближённые к тем, что есть в крупных компаниях.
Будет ли расширяться стек технологий?
Да, это важное направление. Мы планируем добавлять задания, связанные с мониторингом и логированием. В первую очередь это ELK, а также связки Prometheus и Grafana вместе с Loki. Кроме того, смотрим в сторону таких инструментов, как Vector, особенно в контексте задач по поиску и разбору проблем. Отдельный фокус такэе на современных open-source решениях и их альтернативах. Рынок сейчас быстро меняется, появляются новые инструменты, и нам важно отражать это в заданиях. Ну и есть в планах адаптировать продукт под потребность других специальностей — будем стремиться создать аналогичные решения для разработчиков, тестировщиков и других членов современных IT-команд. Cамо собой, про улучшение пользовательского опыта тоже не забываем. В планах: дать юзерам возможность создавать собственные задания, добавлять заметки и делиться своими кейсами. Есть ощущение, что HardPractice мог бы стать важной точкой сбора сообщества.
Круто! И последний вопрос: что бы ты хотел сказать пользователям HardPractice?
Оставайтесь с нами — дальше будет только лучше!