Наша рубрика «Где работать в ИТ» — это интервью с интересными айти-компаниями, в которых они делятся подробностями о процессах своей работы. Представители индустрии отвечают на вопросы о найме, условиях, командах и технологиях. В этом выпуске мы расскажем вам о компании Selectel — провайдере IT-инфраструктуры и облачных решений.

А ещё в выпусках мы рассказываем об оценках компаний на Хабр Карьере, чтобы вы были в курсе, за что их любят (или нет?) сотрудники. Кстати, если вы тоже оцените своего работодателя, то это поможет тем, кто ищет работу в ИТ.

→ оценить работодателя

Кто отвечал на вопросы

Обо всех процессах в Selectel нам подробно рассказали:

О компании

Selectel — это провайдер ИТ‑инфраструктуры, предлагающий серверы в дата‑центрах и в облаке, гибридные решения, облачное хранилище и удобные инструменты для управления инфраструктурой. В компании действует 6 дата‑центров: в Москве, Санкт‑Петербурге и Ленинградской области; среди клиентов — крупные компании, такие как 2ГИС, ПИК, Amediateka, ВКонтакте и другие.

Публичная оценка компании на Хабр Карьере в 2025 году — 4,67 из пяти. Сотрудники особенно ценят Selectel за комфортные условия труда, интересные задачи и за то, что компания делает мир лучше. Посмотреть оценку в деталях и почитать комменты сотрудников можно в профиле Selectel на Хабр Карьере.

Об условиях работы. Рассказывает Денис Кириллов

Какой в вашей компании сложился рабочий график и какое отношение к переработкам?

У нас несколько видов графика в зависимости от роли. У специалистов техподдержки и инженеров дата-центров график сменный, у офис-менеджеров фиксированный (с 9:30 до 18:30), у большинства остальных команд гибкий с одним правилом — с 12 до 17 быть в офисе или на связи, если работаешь удалённо. Оставшаяся часть рабочего дня — на усмотрение сотрудника: можно поработать с утра, а можно вечером, если так удобнее. К внезапным и срочным задачам мы подходим, руководствуясь здравым смыслом, а поощрения рассчитываются индивидуально.

Переработки мы не приветствуем, наоборот, уделяем много внимания work-life balance. 2025 год был в Selectel Годом баланса: весь год мы проводили мероприятия с громкими хедлайнерами (например, с доктором биологических наук Вячеславом Дубыниным и автором книги «Адекватность» Сергеем Калиничевым) и полезными практиками на тему работы со стрессом и поиска того самого баланса. 

Какие бытовые условия ждут нового сотрудника на рабочем месте? 

У нас пять собственных офисов — три в Санкт-Петербурге, один в Ленинградской области и один в Москве. Также мы арендуем дополнительный офис неподалёку от питерских.

За сотрудниками, которые посещают офис от трёх дней в неделю, закреплены рабочие места. Сотрудникам, которые посещают офис меньше трёх дней в неделю, доступна услуга онлайн-бронирования рабочего места на день. Про технику: каждому сотруднику на выбор предоставляем MacBook или ноутбук с Windows или Linux.

Пространства в офисах разные: как небольшие кабинеты на 4-5 человек, так и опенспейсы на 10-15 человек. Всё зависит от размеров команды: стараемся, чтобы в каждом помещении были сосредоточены один отдел или близкие команды. 

Во всех офисах есть переговорки и шумоизоляционные кабинки на 1-2 человека; кофе-поинты и кухни (в одном даже есть небольшая станция со свежей микрозеленью); стандартные пространства типа конференц-зала и митап-холла для проведения внутренних и внешних мероприятий и зоны отдыха с кикером, настольным теннисом и «плойкой». В Санкт-Петербурге сотрудникам также доступен полноценный спортзал, где можно потренироваться как самостоятельно, так и на групповой тренировке с тренером. 

Есть и более необычные «плюшки» вроде капсул сна, массажных кресел, баланс-бордов, холодильников с мороженым и сырками, офисного душа. А в теплое время года открывается любимое место сотрудников — чиллаут-зона на крыше. Там можно как провести ивент, так и просто поработать на солнышке.

Какой социальный пакет получают сотрудники?
Соцпакет у нас широкий, и мы им гордимся, начиная с ДМС со стоматологией, ежегодными чекапами, ведением беременности и даже удалением родинок до компенсации обедов по системам наЛанч и Обед.ру. 

Кстати, мы продвигаем доказательную медицину: 2024 год объявили Годом докмеда в компании, чтобы внедрить научный подход к здоровью среди сотрудников — чтобы каждый сотрудник больше знал о своем здоровье и выбирал врачей и медицинские услуги, основываясь на фактах. Именно поэтому среди доступных для сотрудников медицинских учреждений в программе ДМС много докмед-клиник. 

Мы также заботимся о досуге сотрудников. Недавно посчитали — у нас проходит более 40 внутренних ивентов в год! Это и тематические вечеринки, и офисные тусовки, совместные походы в кино, музеи и на экскурсии. Кстати, у нас в Selectel 2 собственные музыкальные группы из сотрудников, поэтому на тусовках мы наслаждаемся выступлениями наших талантливых коллег. Конечно, у нас есть и собственная репточка, чтобы ребятам было комфортно репетировать. 

Ну, и без спорта никуда, у нас есть 17 внутренних сообществ по разным видам спорта — от стандартного бега до яхтинга. А еще мы организуем коллегам участие в турнирах (например, в Гонке героев), йогу и тренировки в офисе и поддерживаем собственные команды по волейболу, футболу, баскетболу и т. д. А еще ежегодно устраиваем горнолыжные выезды, забеги и велозаезды.

Какие бонусы, премии и компенсации предусмотрены в компании?

У нас есть несколько систем премирования: у некоторых отделов ежемесячная премия по KPI, а у некоторых — годовой бонус по результатам ревью.

Компенсаций у нас много: от консультаций психолога и занятиями английским до фитнес-абонементов и спортивных секций. Мы также поощряем здоровый образ жизни, поэтому у нас есть премия «за некурение» — до 7000 рублей в месяц. 

Кроме этого есть премии ко дню рождения, рождению ребенка (по этому случаю дарим еще и милейшие брендированные ползунки). На новый год дети сотрудников получают подарки — полезные вещи вроде пазлов, раскрасок, кормушек для птиц, рюкзаков. Также мы помогаем материально в трудных жизненных ситуациях. 

А ещё в компании есть Selectel Game — внутренняя игра, в которой сотрудники получают друг от друга бейджи и «Спасибо», конвертируют их в селекоины (наша внутренняя валюта) и тратят на мерч, сертификаты, технику и т. д. Еще селекоины можно отдать на благотворительность. Так, по итогам 2025 года наши коллеги пожертвовали в разные фонды 486 тысяч рублей.

Какие есть перспективы для образования и личного развития у сотрудников?

В конце года сотрудники и руководители встречаются на ревью и обмениваются подробным фидбэком по системе с чёткими критериями. Также проходят регулярные 1:1 встречи с руководителем и упрощенные промежуточные ревью в апреле и августе. 

У сотрудников есть возможность проходить обучение и участвовать в профильных конференциях за счёт компании. Есть и внутренние образовательные инструменты: ежемесячные Lightning — серия блиц-докладов, и Thunder talks — выступления на 30-40 минут. В LMS можно найти курсы для онбординга разных команд, материалы о продуктах компании и даже курс о том, как создать свой курс. Всем сотрудникам доступна библиотека Alpina Digital, а в офисах есть книжные полки с сотнями книг.

Один из наших новых инструментов развития — платформа Selectel Grow, где можно простроить индивидуальный карьерный трек и моментально получить полезные материалы для развития.

В компании также работают шесть внутренних технических сообществ: AI, Backend (Go + Python), Admin/DevOps, Security, Frontend и Гильдия проектного менеджмента. Коллеги обмениваются опытом и переиспользуют лучшие практики, что помогает развивать инженерную культуру.

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

Отдельно отмечу программу Leaders Camp. Она рассчитана на развитие руководителей и сотрудников с высоким потенциалом. Благодаря программе компания развивает лидерские и менеджерские навыки у тех, кто может вырасти до управленческих позиций. В 2024 году 74% руководящих позиций были закрыты внутренними кандидатами, а в 2025 году — 75%!

О найме. Рассказывает Софья Вовненко

Во сколько этапов проходит наём и что на них ожидает соискателя?

У нас есть несколько типов интервью в зависимости от вакансий: систем дизайн, хард скиллс и софт/менеджмент скиллс, а для некоторых вакансий могут быть кейсовые интервью и тестовые задания. Поэтому наш процесс собеседований обычно включает от двух до четырех этапов. Мы стремимся за минимальное время максимально эффективно познакомиться с кандидатами.

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

Третий этап — встреча по результатам технической оценки, чтобы подробнее обсудить впечатления кандидата и технические моменты. Также оцениваем,  как кандидат подходит к работе: планирует задачи, взаимодействует с командой и лидерами, выстраивает процессы.

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

Даете ли вы тестовое задание кандидатам? Как оно устроено?

Да, мы можем предложить тестовое задание при большом количестве кандидатов на вакансию или для тех направлений, где важно глубже понять, как кандидат подходит к задаче. Сам кандидат с помощью тестового сможет оценить реальные задачи, с которыми он может столкнуться в работе, и понять, насколько они ему интересны. Задания похожи на рабочие кейсы, можем взять и когда-то решённую нами проблему. 

Если в ходе выполнения тестового задания кандидат использует ИИ, идеально выполненное задание для нас — не цель. В таких случаях нас интересуют структура решения, способ объяснения, какие инструменты выбирает кандидат, и как умеет в тайм-менеджмент.

Как отличается подход к найму в зависимости от позиции и стека?

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

Какая фраза от кандидата на собеседовании точно заставит вас выкинуть его резюме?

Мы не выкидываем резюме, для нас важно быть уважительными к любому кандидату. Но бывают ситуации, когда видно: сейчас, возможно, не тот момент. Например, если кандидат считает, что ему больше нечему учиться; даёт неискренние ответы про слабые стороны и фейлы; во всём ищет виноватых; не понимает, куда пришёл и зачем; говорит неконструктивно о бывших работодателях; провоцирует вопросами вроде «а ИНТЕРЕСНЫЕ задачи у вас есть?», или если данные в резюме не совпадают с реальным опытом.

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

Как происходит онбординг нового сотрудника?

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

1. Велком-пак. В первый день новичка ждут зелёный плюшевый Тирекс, стикерпак, фирменные футболка и зипка — всё в шоппере. А в Confluence для него подготовлена памятка нового сотрудника.

2. Рабочее место и технику готовим заранее, поэтому рабочее место со всеми доступами уже ждёт в первый день.

3. Оформление. Большинство документов оформляем до выхода, а в первый день это занимает 30-40 минут.

4. Курс новичка в LMS помогает быстрее освоиться и включает базовые материалы о ценностях, миссии, стратегии, культуре, процессах, а также курсы по продуктам, охране труда, ИБ, Confluence и Jira.

5. Архив лекций и база знаний. Все нужные материалы хранятся в Confluence: от технических до нетехнических материалов и выступлений коллег.

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

7. Бадди. Это коллега, который подсказывает, где что находится, к кому обратиться и как в компании принято решать вопросы. Часто он помогает и с задачами.

8. Экскурсия по офису и дата-центрам в Петербурге, Дубровке и Москве показывает инфраструктуру, на которой работают проекты более 33 000 клиентов.

9. Топовая встреча. Это welcome-встреча для всех новых сотрудников, где руководители рассказывают об истории, продуктах, ценностях и процессах компании.

Про ИТ-команды. Рассказывает Максим Овчаров

Какая методология разработки у вас используется и почему?

Большинство наших команд работает по Scrum — это гибкий подход к разработке, при котором работа делится на короткие итерации (спринты) по 1–2 недели. Такой формат помогает регулярно показывать результат и быстро реагировать на изменения.

При этом команды не следуют фреймворку формально: они сами выбирают, какие встречи им действительно полезны и как лучше организовать рабочий процесс. Роль Scrum-мастера чаще всего берет на себя тимлид.

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

На планировании спринта команда старается брать такой объем задач, чтобы по итогам двух недель получался готовый и полезный результат — небольшой, но законченный шаг вперед в развитии продукта или проекта.

Для понимания стабильности процессов используем Jira — в ней есть удобные дашборды, например, графики выполнения задач в спринте, скорость команды и распределение задач по этапам. Хороший ориентир для нас — когда примерно 80% запланированных задач выполняются в 80% спринтов. 

Каковы размеры и структуры команд?

Сегодня у Selectel уже больше 50 продуктов. Над ними работают не только разработчики, но и команды эксплуатации, надежности и инфраструктуры. Если говорить именно о разработке, чаще всего это кросс-функциональные команды, которые отвечают за продукт полностью — от идеи до поддержки. Внутри команды есть все необходимые роли: backend- и frontend-разработчики, UX, QA и администраторы.

Размер таких команд обычно небольшой — до 9-10 инженеров. Это позволяет сохранять скорость принятия решений и при этом делить ответственность. Внутри команды могут быть инженеры разных уровней, от стажёров до ведущих, а тимлид сам определяет оптимальный состав. Компания также активно работает со студентами: в командах регулярно появляются практиканты, а в этом году запустили полноценную стажерскую программу, которая усилила более 10 команд.

По каким критериям вы разбиваете разработчиков на джунов, мидлов и синьоров?

Уровень разработчика в первую очередь определяется сложностью задач, с которыми он способен работать. Чем выше неопределённость задачи и чем больше самостоятельности требуется для её решения, тем выше грейд инженера.

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

Мидлы — это костяк команды. Это уже почти полностью автономные инженеры, которые могут брать задачи со средней степенью неопределённости и доводить их до результата. Обычно речь идёт о задачах, которые занимают от нескольких недель до пары месяцев разработки: спроектировать новый сервисный компонент, доработать архитектуру, реализовать крупную функциональность.

Сеньор — это, как правило, эксперт в своей области: виртуализация, сети, базы данных, Kubernetes, AI или другие инфраструктурные домены. Если в команде появляется сеньор, это обычно означает наличие задач с высоким уровнем неопределённости, которые могут занимать квартал или даже год разработки. Это могут быть новые архитектурные решения, большие инфраструктурные изменения или запуск принципиально новых возможностей платформы. Часто такие задачи выходят за рамки одной команды: сеньоры участвуют в архитектурных обсуждениях, помогают другим командам и формируют технические подходы, которыми потом пользуется вся компания.

Для развития сотрудник может использовать инструмент Skills Set — модель компетенций. С помощью нее каждый в компании может найти свое направление и узнать, какие навыки ему нужны для развития и продвижения, оценить свой уровень скиллов и найти подсказки и инструменты для саморазвития.

Кто чаще возглавляет команды — продуктовый специалист или технический?

Раньше командами чаще руководили Product Owner’ы, что давало чёткий фокус на продукте, приоритетах и бюджете и позволяло быстро принимать продуктовые решения. Но в таком формате иногда терялся долгосрочный взгляд на техническое развитие: сложнее было развивать архитектуру, внедрять новые практики и двигаться к сложным инженерным задачам, а также растить инженерные компетенции.

Сейчас командами разработчиков в основном руководят тимлиды — технические руководители. В кросс‑функциональных командах TL в 90% случаев — бывший backend‑разработчик, который стал T‑shaped‑специалистом: глубоко понимает свою область и ориентируется в смежных ролях. При этом роль Product Owner остаётся: он отвечает за продуктовое направление и приоритеты.

Как часто люди меняют команды?

Для нас смена команд внутри компании — вполне нормальная практика. В Selectel можно переходить между командами, если текущий продукт перестал драйвить или хочется попробовать новую роль. Переходы бывают как внутри разработки, так и между направлениями, например, инженеры из ИТО со временем переходят в продуктовые или инфраструктурные команды как junior‑администраторы. 

Такая мобильность помогает и сотрудникам, и компании: люди приходят в новые команды уже с пониманием инфраструктуры и процессов.

Отдельно отмечу одну вещь, которая лично для меня многое говорит о компании. Я работаю здесь уже больше трех лет — и при этом все еще считаюсь относительно «молодым» сотрудником. Вокруг много коллег, которые работают 6, 9, а иногда и 17 лет.

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

При этом компания не превращается в «закрытый клуб старожилов». Наоборот, новые сотрудники регулярно привносят свежие идеи и подходы — и это заметно влияет на культуру команд.

Что важнее, софт-скиллы или хард-скиллы?

И то и другое. Без сильной технической базы невозможно стать ведущим разработчиком в Selectel, поэтому начнем с того, что мы понимаем под hard skills. Это профессиональные навыки, которые позволяют инженеру решать задачи разной сложности и степени неопределенности. Это также внимание к качеству кода, работа с техническим долгом, участие в развитии архитектуры, привнесение новых технологий и решений. Проще говоря, хороший инженер не просто реализует задачу, а улучшает систему вокруг себя.

Под soft skills мы в первую очередь понимаем то, как человек работает с другими людьми и внутри команды. Во многом это связано с ценностями компании: клиент (за любым техническим решением в итоге стоит пользователь продукта); команда и коллаборация (инженеры активно участвуют в жизни команды и компании); инициатива и ответственность и открытый диалог.

Если коротко

• Hard skills определяют, какие задачи инженер может решать.

• Soft skills определяют, как он это делает внутри команды.

А на высоких уровнях эти две вещи уже почти невозможно разделить: чем сложнее задачи, тем больше приходится объяснять решения, договариваться, влиять на архитектуру и помогать расти другим инженерам.

Как много собраний у вас проводится? Есть ли особые подходы к ним?

Количество встреч в команде зависит от многих факторов: работает ли команда из офиса или удаленно, сколько в ней людей, насколько сложный продукт она делает и, конечно, насколько уже «созрели» процессы внутри команды. Если говорить о «максимальном» наборе встреч в зрелой команде, то это будет около 6,5 часов встреч в неделю — меньше 20% от стандартной 40-часовой недели. И это, повторюсь, максимально насыщенный вариант.

При этом мы стараемся придерживаться простого принципа: если человеку не нужно присутствовать на встрече — он на нее не идет. Никаких «посиди на всякий случай». Еще важный момент — группировать встречи так, чтобы команда меньше страдала от переключения контекста.

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

Как вы боретесь с выгоранием сотрудников?

У выгорания почти всегда есть ранние сигналы, вопрос в том, замечаем ли мы их вовремя.

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

Есть фраза, которая мне очень откликается как руководителю: «Сотрудник приходит в компанию, а уходит от руководителя». Если человек выгорел и решил уйти, значит, где-то я недосмотрел: не заметил сигналов, не помог вовремя, не снял лишнюю нагрузку. Поэтому здесь важно работать на опережение, а не тушить пожар, когда уже поздно.

У нас есть инструмент, который помогает отслеживать состояние сотрудников — Stay-интервью. Это встреча 1:1 HR BP и сотрудника в формате «Как дела?». Цель встречи — узнать как сейчас дела у сотрудника, все ли ему нравится, нет ли у него признаков выгорания.

На уровне компании это тоже системная работа. В Selectel каждый год проходит опрос, который помогает оценить вовлеченность, лояльность, удовлетворенность и желание рекомендовать Selectel как работодателя (eNPS). Его результаты помогают понять общее настроение сотрудников, уровень нагрузки и вовлеченности. Есть и более практичные вещи, в том числе консультации психолога в рамках ДМС, компенсация занятий спортом, разные клубы по интересам, активности и встречи команд.

Если коротко: мы стараемся не «лечить выгорание», а создавать среду, в которой до него реже доходит.

Про технологии

Какие языки, фреймворки и библиотеки используются на проекте?

В основном мы используем Python и Go. Причем новые сервисы стараемся писать именно на Go — там, где у команды хватает опыта и это действительно оправдано. Если же задачам уже тесно в рамках Python и Go, то в отдельных командах, например в Selectel OS, для системного программирования используют C и Rust.

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

С фреймворками история довольно спокойная: жесткого списка «разрешенного» у нас нет. Обычно команды выбирают то, что уже хорошо себя показало в других проектах или лучше подходит под конкретную задачу. С одной стороны, это дает свободу и гибкость. С другой — иногда приводит к появлению локальных «велосипедов», когда похожие вещи в разных командах решаются по-разному.

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

Что вы можете рассказать об архитектуре проектов?

Чтобы объяснить архитектуру наших проектов, сначала нужно дать немного контекста про сам Selectel и то, как устроены наши продукты.

Selectel — инфраструктурный провайдер с продуктами от выделенных серверов до облака (IaaS) и платформенных сервисов, таких как DBaaS, Managed Kubernetes и балансировщики нагрузки. Каждый уровень опирается на предыдущий: платформенные сервисы используют облачный слой, а тот — инфраструктурную базу.

Важно разделять два слоя системы. Control Plane — это слой управления, отвечающий за создание, настройку и контроль клиентских ресурсов, например, виртуальных машин, сетей, дисков и образов. Data Plane — это слой, где работают сами клиентские ресурсы: виртуальные машины, базы данных, узлы Kubernetes и другие нагрузки.

Такое разделение даёт практические преимущества:

• масштабируемость: слой управления и слой исполнения можно развивать независимо друг от друга;

• отказоустойчивость: даже если с Control Plane что-то пошло не так, клиентские ресурсы в Data Plane обычно продолжают работать, пусть и с определенными ограничениями;

• безопасность: централизованное управление упрощает аудит, контроль политик доступа и использование многофакторной аутентификации;

• гибкость в размещении: Control Plane можно строить централизованно или геораспределенно, а Data Plane — размещать в разных локациях. Для нас это особенно актуально, потому что у Selectel 6 геораспределенных регионов присутствия и сеть дата-центров.

Если говорить про инженерную сторону, то здесь нет какой-то одной «магической» архитектуры. Мы используем набор хорошо известных подходов и инструментов, которые подходят под конкретные задачи: синхронное взаимодействие по HTTP и gRPC, асинхронное взаимодействие через очереди и события, сервисный и микросервисный подходы, брокеры сообщений вроде RabbitMQ, Kafka и NATS, разные типы баз данных — PostgreSQL, MySQL, ClickHouse, MongoDB, а также слои кэширования на Redis и Memcached.

Если хочется посмотреть глубже не на абстрактную схему, а на реальный боевой пример, можно изучить архитектуру Nova Compute — одного из ключевых компонентов OpenStack, который отвечает за виртуализацию в облаке. На таких системах особенно хорошо видно, как теория архитектуры проверяется практикой.

Какая у вас принята политика код-ревью?

Код-ревью у нас — нормальная часть инженерной работы. В большинстве команд действует правило: чтобы изменения попали в основную ветку, нужно получить как минимум два одобрения.

На ревью мы обычно смотрим не только на то, «работает или нет». Важно и то, как реализовано решение. Например, обращаем внимание на стилистику кода в тех местах, где этого уже не покрывают линтеры и автоформатирование. Смотрим на корректность самой логики, хотя здесь, конечно, основная ответственность всё равно остается за автором изменений.

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

Еще один важный критерий — тесты. Для нас наличие юнит- или интеграционных тестов — это не приятный бонус, а нормальное ожидание от изменений, которые идут в кодовую базу.

Поскольку наши продукты проходят сертификацию по PCI DSS, ГОСТ и ISO, вопросы информационной безопасности встроены в процесс разработки на всех этапах. Код-ревью здесь не исключение: мы внимательно смотрим на изменения с точки зрения рисков, а в чувствительных случаях можем подключать к проверке коллег из отдела информационной безопасности.

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

Как тестируется код?

Подход к тестированию в Selectel сочетает ручную и автоматизированную проверку. Баланс между ними команды выбирают сами исходя из зрелости продукта, скорости релизов и ресурсов. Большинство команд кросс‑функциональные: где‑то есть выделенный QA‑инженер, а где‑то команда обходится без отдельной роли тестировщика. Финальная ответственность за результат остаётся у разработчика.

Команды начинают писать интеграционные тесты параллельно с разработкой, заранее договариваясь о контрактах между сервисами. Это помогает раньше находить нестыковки и сокращает доработки. Вводится практика 3 Amigos: разработчик, заказчик и QA обсуждают критерии приемки, требования и тестовые сценарии до старта разработки, часть из них сразу идёт в автотесты, часть проверяется вручную.

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

Как устроен процесс документации и ведения базы знаний на проектах?

У нас есть подробная публичная документация, с которой работают и внешние пользователи, и наши собственные команды. Есть и внутренняя база знаний в корпоративной wiki.

Обычно внутренняя документация делится на несколько разделов:

• продуктовая часть — все, что связано с исследованиями, проработкой новых возможностей и аналитикой;

• командные процессы — внутренние договоренности, формат встреч, правила онбординга и другие организационные вещи;

• техническая документация — карточки сервисов, архитектурные решения, исследования и инженерные заметки;

• инфраструктурный блок — все, что касается CI/CD, деплоя, схем и других прикладных деталей эксплуатации.

При этом главная проблема документации вполне классическая: она очень быстро устаревает. Поэтому мы стараемся смотреть на ее обновление не как на факультативную активность «если останется время», а как на часть завершения задачи. Иначе даже хорошо написанная документация довольно быстро превращается в архив, которому никто уже не доверяет.

Каков процент легаси-кода на проекте и как часто разработчики занимаются его рефакторингом?

Лучший способ бороться с техническим долгом — не создавать его, но в реальной разработке без него обойтись не получается. Важнее не «процент легаси», а то, насколько код мешает двигаться дальше и как команда с этим работает.

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

Небольшой долг исправляют в рамках рабочих задач по правилу бойскаута: оставлять код чуть чище, но не превращать ошибку или фичу в бесконечный рефакторинг. Средний долг выносят в отдельные задачи спринта, обычно выделяя около 30% времени. Крупный долг становится частью общего плана на квартал или год, обсуждается с бизнесом как инвестиция: ускорение разработки, уменьшение инцидентов, улучшение стабильности.

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

Как реагируете на сообщения пользователей о багах и просьбы по улучшению сервисов/продуктов?

Мы стараемся смотреть на такие обращения не как на жалобы, а как на важный источник обратной связи о качестве продукта. Здесь работа строится сразу в двух плоскостях — реактивной (разбор обращений, исправление багов, устранение инцидентов и восстановление нормальной работы сервиса) и проактивной (работа с причинами: почему проблема вообще возникла, что можно изменить в требованиях, архитектуре, тестировании или процессах, чтобы похожие ситуации не повторялись).

Для клиентских обращений есть несколько уровней поддержки и эскалации:

• на L2 находятся специалисты поддержки, которые напрямую общаются с клиентами. Они обрабатывают основной поток обращений и решают типовые кейсы по понятным инструкциям и сценариям.

• на L3 подключаются более опытные администраторы, которые дежурят круглосуточно. Они разбирают более сложные ситуации, участвуют в плановых работах и часто первыми глубже погружаются в проблему во время инцидента.

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

В таком процессе очень важно не только технически решить проблему, но и соблюдать SLA по реакции и аккуратно управлять ожиданиями клиента: что происходит, на каком этапе находится работа и когда можно ожидать результат. Для инфраструктурных сервисов это особенно важно — тишина в ответ на проблему обычно воспринимается почти так же болезненно, как и сама проблема.

На уровне команд разработки баги тоже не живут по принципу «разберемся потом». Мы используем подходы к их приоритизации и даем понятные ориентиры по срокам исправления в зависимости от важности проблемы. В некоторых командах для этого применяется подход Zero Bug Policy — когда накопление дефектов не считается нормой, а работа с ними становится частью регулярного инженерного процесса, а не отдельной кампанией по разгребанию хвостов.