Наша рубрика «Где работать в ИТ» — это интервью с интересными айти-компаниями, в которых они делятся подробностями о процессах своей работы. Представители индустрии отвечают на вопросы о найме, условиях, командах и технологиях.
В этом выпуске мы расскажем вам о компании Selectel — провайдере облачной инфраструктуры и услуг дата-центров.
А ещё в выпусках мы рассказываем об оценках компаний на Хабр Карьере, чтобы вы были в курсе, за что их любят (или нет?) сотрудники. Кстати, если вы тоже оцените своего работодателя, то это поможет тем, кто ищет работу в ИТ.
Кто отвечал на вопросы
Обо всех процессах в Selectel нам подробно рассказали:
Андрей Болгов
Директор по облачной разработке
Денис Кириллов
HR BP департамента разработки
О компании
Selectel — провайдер ИТ-инфраструктуры. Продукты компании — серверы в дата-центрах и облаке, гибридные решения, облачное хранилище и инструменты гибкого управления инфраструктурой. У Selectel 6 дата-центров в Москве, Санкт-Петербурге и Ленинградской области, а среди клиентов — 2ГИС, ПИК, Amediateka, ВКонтакте и многие другие.
Публичная оценка компании на Хабр Карьере в 2021 году — 4,74 из пяти. Сотрудники особенно ценят Selectel за профессиональный рост, комфортные условия труда, социальный пакет, отношения с коллегами, карьерный рост, а также за то, что компания делает мир лучше. Посмотреть оценку в деталях и почитать комменты сотрудников можно в профиле Selectel на Хабр Карьере.
Об условиях работы
Какой в вашей компании сложился рабочий график и какое отношение к переработкам?
Денис Кириллов: У нас в компании есть несколько видов графика. Например, инженеры в дата-центре и техподдержка работают по сменному графику, ведь эта функция должна быть доступна 24/7 для клиентов. Есть и фиксированный график — так, офис-менеджеры работают с 9:30 до 18:30.
Но если мы говорим про команду разработки, маркетинг, HR и т.д., то здесь царствует гибкий график. Если работаешь из офиса, то обязательные часы присутствия — с 12 до 17. Если удаленно, эти часы становятся временем, когда ты должен быть на связи. Нужно отлучиться — не проблема, только предупреди команду. И руководители, и сами сотрудники ориентируются на выполненные задачи, так что «высиживание» рабочих часов — это не наша тема.
О переработках
Денис Кириллов: Не наша тема и переработки. Мы поощряем work-life баланс. Тут важно понять, что сотрудники, ценящие баланс рабочей и личной жизни, на самом деле наиболее продуктивные: ведь они упаковывают скоуп задач в свои рабочие часы, а не размазывают их на бесконечный рабочий день. Конечно, у всех случаются внезапные и срочные задачи. Но все же редко. В таком случае мы руководствуемся здравым смыслом и к поощрению подходим индивидуально.
Какие бытовые условия ждут нового сотрудника на рабочем месте?
Денис Кириллов: У нас есть собственные два офиса в Петербурге на улице Цветочной, где сосредоточена разработка. Рядом строится третий, на это время мы арендуем офис в бизнес-центре неподалеку. Мы также есть и в Москве — в этом офисе, в основном, работают инженеры и менеджеры по продажам.
Само собой, у каждого сотрудника есть выделенное рабочее место — стол, стул и нужная техника. Обычно выдаем макбук, но зависит от пожеланий. У нас много растений в кабинетах, для ухода за ними есть флорист. Можно заказать свой «личный» цветок!
Пространства есть разные: как небольшие кабинеты на 4-5 человек, так и опенспейсы на 10-15 человек. Кстати, далеко не каждый предпочитает уединение в небольшом кабинете, так что опенспейсы — это не абсолютное зло. Все зависит от размеров команды: стараемся, чтобы в каждом помещении были сосредоточены один отдел или близкие команды. В каждом пространстве есть окна, так что недостатка в естественном освещении нет (если о нем вообще можно серьезно говорить в Питере).
В наших офисах есть стандартные для айтишки места типа кофе-поинтов и кухонь, митап-зала, кикера, настольного тенниса и плойки. Также есть и более необычные «плюшки» вроде массажных кресел, баланс-бордов, холодильника с мороженым и сырками, офисного душа. Вовсю готовимся к открытию тренажерного зала. В новом офисе на Цветочной из нововведений будут чилл-аут зона на крыше и шаренные места, поскольку высокий процент людей у нас на удаленке, и многим не принципиально иметь собственное рабочее место.
Есть ли возможность удаленной работы?
Денис Кириллов: Ковид стал серьезным пинком к внедрению удаленки, до этого у нас были лишь единичные удаленщики. Важно понимать, что у нас не каждый может позволить себе удаленку — например, есть инженеры, чье фактическое присутствие в дата-центрах просто необходимо.
В самом начале “удаленного” пути мы провели специальное обучение для руководителей по менеджменту дистанционных сотрудников: от правильного онбординга до проведения 1:1. Сейчас у нас 10% на полной удаленке, еще около 40% — используют гибридный формат. А многих по-прежнему можно назвать настоящими фанатами офиса.
Из-за последних событий у нас также появились сотрудники, которые работают с нами из других стран. Пока за 2 месяца лишь 3% из почти 700 коллег выразили желание временно релоцироваться за пределы РФ — в таких случаях мы принимаем все решения индивидуально.
Какой социальный пакет получают сотрудники?
Денис Кириллов: Не будем скромничать, соцпакет у нас широкий. И мы постоянно держим руку на пульсе. Например, в связи с недавними событиями мы существенно проиндексировали зарплату сотрудникам и увеличили некоторые компенсации: на обеды и консультации психологов.
Возвращаясь к соцпакету, начнем с дефолтного: это официальное трудоустройство, белая зарплата. Выдаем карточку наЛанч или Обед.ру, средства на которой можно тратить на обеды в кафе, доставку или блюда в венгингах. На кофепоинтах всегда полно фруктов, сладостей. С первого дня доступен ДМС со стоматологией. Коллеги в Петербурге также могут посещать офисного врача.
В довесок к соцпакету и бонусам, мы заботимся о досуге сотрудников. Масштабные корпоративы, офисные тусовки, совместные походы в кино и музеи, разнообразные лекции про искусство и науку. Ну, и без спорта никуда — участие в турнирах, йога в офисе и собственные команды по волейболу, футболу, баскетболу.
Какие бонусы, премии и компенсации предусмотрены в компании?
Денис Кириллов: У большинства коллег — годовой бонус. Он составляет до 15% от суммарного оклада за 12 месяцев. В некоторых командах предусмотрена месячная система премирования — например, в продажах или технической поддержке. Ежемесячно сотрудники получают надбавку за некурение в размере 5% от зарплаты.
Мы много чего компенсируем:
консультации с психологами онлайн, в офисе или кабинете психолога,
от 50 до 100% занятия английским в зависимости от итоговой успеваемости,
50% занятия испанским,
50% компенсация фитнес-абонемента и других спортивных секций.
Кроме этого есть премии ко дню рождения, рождению ребенка (по этому случаю дарим еще и милейшие брендированные ползунки). На новый год дети сотрудников получают подарки — это не сладости, как принято во многих компаниях, а полезные вещи вроде пазлов, раскрасок, кормушек для птиц, рюкзаков. Также мы помогаем материально в трудных жизненных ситуациях.
Есть и «околоматериальные» бонусы благодаря нашей Selectel Game. Если кратко, то сотрудники получают друг от друга ачивки и «Спасибо», которые конвертируются в селекоины (это наша внутренняя валюта). Ежегодно открывается магазин, где можно их потратить. Товаров там много: толстовки, сертификаты, техника и т.д. Еще можно отдать селекоины на благотворительность. Так, в этом году наши коллеги пожертвовали больше 160 000 рублей в разные фонды.
Какие есть перспективы для образования и личного развития у сотрудников?
Денис Кириллов: В конце года сотрудники и руководители встречаются на ревью и обмениваются подробным фидбэком — для этого у нас реализована удобная система с четкими критериями. Так коллеги трекают свой прогресс и понимают, в каком направлении двигаться. Безусловно, фидбэк ожидает всех намного чаще — на тех же регулярных 1:1 встречах с руководителем — но ревью — дело обстоятельное и проводится во всей компании. Так что хочешь-не хочешь, а сядешь и оценишь себя и коллег как следует.
У каждого сотрудника есть возможность проходить обучение и участвовать в профильных конференциях за счет компании. Но чтобы учиться, не обязательно проходить внешнее обучение, у нас есть ежемесячные внутренние обмены знаниями: Lightning (серия блиц-докладов) и Thunder talks (доклады на 30-40 минут). Есть и целые внутренние школы: в этом году, например, мы запустили Admin Bootcamp — лекции и практики от системных администраторов. Много знаний сосредоточены в LMS: в системе можно найти курсы для онбординга разных команд, про продукты компании или курс о том, как создать свой курс! Кроме этого, всем сотрудникам доступна библиотека Alpina Digital, а в офисе на Цветочной есть книжная полка с сотней книг.
Есть еще пара интересных карьерных инструментов: ротация и менторство. В последнем случае сотрудник может выбрать себе наставника среди топ-менеджеров и опытных руководителей. Вместе они определяют цели менторства и достигают их, регулярно встречаясь. Ротация — это возможность поработать в другой команде пару недель. Цели могут быть разные: разобраться в том или ином продукте, поделиться знаниями или потенциально перейти в «принимающую» команду.
Особое внимание мы уделяем публичным выступлениям и поощряем коллег-спикеров. У нас есть целая команда амбассадоров, в рамках которой каждый сотрудник может:
найти комфортный формат выступления (конференция, подкаст и т.д.),
подготовиться к звездному часу с внутренними и внешними экспертами,
само собой, получить за это крутой мерч!
Отдельно команда маркетинга поощряет написание статей в наших блогах на разных площадках — коллеги помогают с замыслом и редактурой и выплачивают премию авторам.
О найме
Во сколько этапов проходит наём, и что на них ожидает соискателя?
Денис Кириллов: Наша цель — за минимальное количество времени максимально эффективно познакомиться с кандидатами. Поэтому, как правило, наибольшее количество этапов собеседований — три: встреча-знакомство (первичное понимание опыта и технических скиллов, рассказ о вакансии и ответы на вопросы), тестовое задание и встреча по результатам тестового задания, чтобы более подробно обсудить впечатления кандидата и погрузиться в технические моменты.
P.S. Для актуальной повестки: мы не останавливаем набор новых сотрудников и даже готовы нанимать больше, чем запланировали на 2022 год, если на рынке окажутся ключевые для Selectel эксперты. Вот наши вакансии на Хабр Карьере, еще больше вы можете найти на нашем сайте.
Даете ли вы тестовое задание кандидатам? Как оно устроено?
Денис Кириллов: Мы часто даем тестовые задания на технические вакансии уровня миддл и выше. Задания составляются таким образом, чтобы они были похожи на рабочие кейсы. Например, это может быть уже когда-то решенная нами проблема или задача. Это позволяет не только нам видеть технические скиллы соискателя, но и самому кандидату знакомиться с потенциальными задачами не просто со слов на собеседовании, а на деле.
Задания составляются так, чтобы длительность их выполнения составляла 1-4 часа чистой работы. Сами мы не ставим кандидатам никаких дедлайнов, понимая, что у каждого есть своя жизнь и запланированные дела. Кандидат вправе сам оценить, сколько времени потребуется для его выполнения и обозначить сроки и условия. (Секретик: так еще и проверяется ответственность и умение в тайм-менеджмент).
Как отличается подход к найму в зависимости от позиции и стека?
Денис Кириллов: Радикальных отличий в подходе к найму нет. Все отличия заключаются в нюансах: чем выше уровень позиции, тем больше участников собеседования может быть на нём. Кандидатам на junior-вакансии мы можем предложить тестовое задание до первой встречи, поскольку поток резюме очень большой.
На некоторые позиции тестовое задание может быть заменено обсуждением кейсов или знакомством с командой. Например, кандидатам на позиции системных администраторов ТЗ чаще всего не даем. Все из-за затратной подготовки: нужно подготовить инфраструктуру и придумать уникальные задачи. В этом случае ограничиваемся кейс-методами: например, узнаем как бы кандидат дебажил конкретную проблему.
Какая фраза от кандидата на собеседовании точно заставит вас выкинуть его резюме?
Денис Кириллов: У нас исключены такие ситуации, мы ведем себя уважительно с любым кандидатом. Но, действительно, есть red flags, которые заставят нас закончить встречу быстрее. Например:
кандидат считает, что ему больше нечему учиться,
мы слышим неискренние ответы про слабые стороны и фейлы,
происходит поиск виноватых во всех проблемах и сложностях,
кандидат не понимает, куда он пришел и зачем,
слышим неконструктивный негатив в сторону бывших работодателей,
сталкиваемся с провокациями: «Ну хорошо, а ИНТЕРЕСНЫЕ задачи у вас есть?..».
Мы не спешим сразу расставаться с кандидатами и понимаем, что если сейчас мы не подошли друг другу, всегда есть шанс, что мы можем сработаться в будущем. Или если мы видим, что человек потенциально подойдет на открытую вакансию в другую команду, предлагаем ему рассмотреть ее.
Как происходит онбординг нового сотрудника?
Денис Кириллов: Приходить в новую команду бывает (ну, хотя бы чуть-чуть) волнительно. Мы стараемся все сделать так, чтобы человек понимал, что именно его тут очень и очень ждали. Вот несколько важных моментов:
1. Welcome Pack. Что может быть приятнее мерча в первый день? В паке есть персональный плюшевый Тирекс (наш маскот), исчерпывающая памятка нового сотрудника, стикерпак и блокнот. А еще выдаем набор одежды: футболка и свитшот или толстовка на выбор. И все это в удобном шоппере.
2. Рабочее место и техника. Все готовим заранее, поэтому новичок получает всю технику, канцелярию и удобное рабочее место в первый день.
3. Документы. Вопросы с ними решаем еще до выхода, поэтому все вопросы с бумагами заканчиваются в первые 30-40 минут первого рабочего дня. Бумагу заменили электронным документооборотом.
4. Курс нового сотрудника в LMS, чтобы быстрее освоиться на новом месте и понять, как и что работает.
5. Архив лекций и база знаний. Все, что поднакопилось, складываем в Confluence: технические и нетехнические ликбезы, выступления коллег — все можно посмотреть там, чтобы быстрее включиться в курс дела.
6. Детальный план адаптации. Там мы описываем задачи, которые нужно завершить к концу испытательного срока, проставляем даты и прописываем ожидания. Так появляется четкое понимание того, куда двигаться.
7. Бадди. Это ваш коллега в Selectel, который помогает новичку: рассказывает, что где находится, где взять канцелярию, где заказать еду, к кому обратиться с вопросами, «как правильно, и как принято» в нашей компании и многое другое.
8. Экскурсия по офису и дата-центру в Питере, Дубровке и Москве. Показываем IT-инфраструктуру, благодаря которой работают проекты клиентов.
9. Welcome-встреча. Топ-менеджеры и руководители рассказывают про историю и продукты компании, ценности, главные процессы. А еще знакомимся с новыми коллегами.
О команде
Какая методология разработки у вас используется и почему?
Андрей Болгов: Весь процесс построен по гибким методологиям (Agile) и опирается на концепцию "доставки максимум полезного для наших пользователей в понятные сроки". Каждая команда может сама определять, каким образом она будет встраиваться в этот общий поток создания ценности для клиентов, но мы даем общие рекомендации и принципы, благодаря которым это сделать будет проще:
Не изобретать велосипед. Когда нужно решить какую-то задачу, сначала команда ищет готовые решения и оценивает необходимые доработки. Например, для облака используется доработанный OpenStack, а не самописная система.
Делать быстро и минимально необходимое. В Selectel продукт делают короткими итерациями по 1—3 месяца. В итерацию берут только тот необходимый минимум, который нужен клиентам. Разработка экономная и за счёт этого эффективная.
Специализация. Над каждым направлением работает группа, которая обладает нужной экспертизой. Например, в группе биллинга важен опыт работы с платежными шлюзами и различными валютами, а в группе виртуальных машин — опыт работы с виртуализацией, образами и операционными системами.
Плотное общение в нужное время. Команда сама определяет частоту и наполнение встреч для себя: нужна ли им детальная проработка задач в бэклоге в виде встречи или можно решить асинхронно в оффлайне, или хотят ли участники команды продемонстрировать результаты своей работы ребятам из соседнего отдела. Однако команда отвечает за выбранный процесс, способ коммуникации и самое главное — за полученные результаты. В команде развития облака нет менеджеров, которые занимаются синхронизацией команд — команды синхронизируются сами.
Тесты, доки, два ствола. Каждый спринт включает в себя не только сам код, но и тесты, деплой на боевые сервера, рассылку по сотрудникам отдела продаж, обучение сотрудников поддержки и создание документации. Это в Selectel попадает под Definition of Done — то есть «Что мы считаем сделанной работой».
Все видят всё. Вся работа ведётся в общих системах Jira и Confluence. Можно задать вопрос любому коллеге, пригласить его для консультации, показать свои результаты или обменяться мнениями.
Каковы размеры и структуры команд?
Денис Кириллов: Прямо сейчас процесс разработки продуктов в компании сложно описать какой-то одной структурой. В рамках департамента разработки можно встретить как кроссфункциональные команды, так и монофункциональные. К первым относятся проектные группы, отвечающие за конкретный продукт. Каждая такая команда состоит из менеджера продукта, руководителя отдела, аналитиков, проектировщиков интерфейсов, разработчиков бэк- и фронтенда, администраторов и тестировщиков. За счет этого мы снижаем затраты на передачу информации между ребятами, работающими над разными сторонами одной и той же услуги.
Монофункциональные команды — кластеры специалистов, которые занимаются конкретной функцией. Например, в одном кабинете собираются админы команды Cloud Observability. Они занимаются развитием системы мониторинга облачной платформы: сбор, доставка, хранение и визуализация метрик, алертинг и участие в работе над воркфлоу обработки инцидентов в качестве инженеров. Задачи подобных команд — разработка общих сервисов и обеспечение работы инфраструктуры услуг.
По каким критериям вы разбиваете разработчиков на джунов, мидлов и синьоров?
Андрей Болгов: В целом, отличия в уровнях можно выделить такие:
1. Умение писать простой и понятный код. Джуны обычно пытаются решить задачи очень нетривиальным путем, используя весь набор знаний. Из-за небольшого объема знаний и опыта, решения требуют особого внимания на ревью. Мидлы стараются писать так, чтобы любой, кто прочитает код, смог его понять и отдебажить. А сеньоры стараются код вообще не писать, там где можно решить задачу иным путем.
2. Веер решений. Мидлы могут предоставить больше 2-х решений для одной и той же задачи, оценив преимущества (profit) и недостатки (trade-off) каждого решения. Джуны обычно пользуются тем способом, которым они владеют. Сеньоры обычно могут еще и собрать «на коленке» несколько простых прототипов для обоснования выбора.
3. Детализация задач. Чем выше скилл разработчика, тем на более абстрактных тезисах может быть поставлена задача. Джуну необходимо детально расписывать ТЗ. Конечно, нужно не забывать, что цель должна быть понятной и измеримой, вне зависимости от уровня разработчика.
4. Зоны ответственности. Джуны обычно решают задачи из разных областей разных сервисов, чтобы получить опыт и знания. Мидлы стремятся овладеть конкретным сервисами на уровне эксперта. Сеньоры обычно управляют высокоуровневыми потоками данных целых продуктов и связанных систем.
5. Объяснять сложное простым языком. Мидлы могут объяснить сложные процессы и особенности инструментов простыми терминами. Джуны чаще всего не имеют опыта и глубокого понимания работы сложных штук, про которые они читали, но еще не успели изучить их «подкапотное» пространство. Сеньоры могут погрузить в мир аналогий и рассказать сложнейшую специфику продукта на «кошках».
Кто чаще возглавляет команды — продуктовый специалист или технический?
Денис Кириллов: Команды возглавляются тимлидами. Чаще всего, это человек с большим техническим опытом, способный и координировать работу команды, и задавать вектор технического развития отдела.
Если мы говорим про продуктовые команды, то за продуктовое развитие отвечает директор или менеджер продукта, определяя вектор развития продукта/фичи и приоритеты разработки, а саму команду разработки возглавляет тимлид, в зоне ответственности которого — вся работа с командой и техническая реализация роадмапа.
Как часто люди меняют команды?
Денис Кириллов: У нас есть практика ротации. Это когда сотрудник переезжает работать на 1-2 недели в другой отдел. С появлением ротации сотрудники все чаще решаются на горизонтальный рост внутри компании. Пара недель тест-драйва — и ты понимаешь, хочешь ли ты расти дальше в этой команде. Если не понравилось, ты без проблем продолжишь работу в прежнем отделе. Но попасть в другую команду можно и без ротации, а через обычное интервью с командой.
В месяц мы организовываем от 7 переходов в зависимости от «сезона». Тут стоит отметить, что большая часть из них — это кейсы, когда коллеги из саппорта или инженерно-технического отдела проходят собеседования, решают ТЗ и переводятся в направления разработки, администрирования, тестирования или клиентского сопровождения.
Что важнее, софт-скиллы или хард-скиллы?
Денис Кириллов: Банально, но: и то и другое важно. А вот акценты могут быть разные. Есть команды, которые в конкретный момент времени готовы уделять достаточно времени для обучения начинающих. Для них софт-скиллы и тяга к знаниям будут чуть в большем приоритете, чем хард-скиллы. Но есть команды, где ведется быстрая и сложная разработка высоконагруженных инфраструктурных продуктов. В таких командах, логично, делается значительный упор при поиске на хард-скиллы и готовность быстро адаптироваться в новой должности.
Как много собраний у вас проводится? Есть ли особые подходы к ним?
Денис Кириллов: Каждая команда самостоятельно определяет частоту встреч — это могут быть ежемесячные ретро, так и еженедельные синки. Некоторые проводят и дэйлики (стендапы на 15 минут). В случае с продолжительными встречами мы проповедуем важность meeting notes, фиксирование договоренностей и определенный тайминг.
Есть встречи и всей компанией:
QA-сессии с генеральным директором и топами. Коллеги рассказывают об успехах компании за прошедший квартал и отвечают на все вопросы. Задать можно любой вопрос — мы заранее собираем их в анонимной форме. В моменты неопределенности (как недавние события) мы проводим такие встречи чаще: раз в неделю или две.
Product Sync. Тут все просто: если хочешь знать, что происходит в наших продуктах, посещай ежемесячную встречу-апдейт от продакт-менеджеров.
Demo Day. На Demo Day коллеги из департамента маркетинга и департамента разработки и эксплуатации продуктов показывают видимые нашим клиентам изменениях в продуктах, сайте, рекламе и внешних коммуникациях, которые произошли за последние полгода.
Как вы боретесь с выгоранием сотрудников?
Денис Кириллов: Мы в Selectel стараемся делать так, чтобы руководитель и сотрудник могли искренне поговорить о том, что происходит. В том числе, если есть подозрение на выгорание. Как только такое подозрение появилось, мы советуем нашим руководителям и лидам сделать следующее:
Поставить встречу 1-1 (объяснить цель встречи, задать дружелюбный тон, гарантировать полную конфиденциальность).
Обозначить ситуацию: опираться на факты, поделиться переживаниями и наблюдениями (например: «Я заметил, что в последнее время ты стал меньше общаться с коллегами»).
Задавать открытые вопросы и слушать.
Быть готовым к тому, что с первого раза может не получиться откровенного разговора.
Стоит попытаться найти решение вместе: выслушать предложения сотрудника, наметить план.
Со своей стороны мы можем предложить следующее:
другие задачи в рамках своей должности (расширение/сужение круга задач и т.п.),
другая должность или команда,
другой формат работы (гибрид, полная удалёнка),
отпуск (в том числе длительный),
профессиональная психологическая помощь (часть нашего соцпакета),
помощь ментора, ротация в другой отдел,
спланировать карьерный трек с новыми вводными.
Случаи выгорания, у нас, к счастью, редки. Но предупрежден — значит вооружен. Именно для этого мы проводим обязательное обучение руководителей на эту тему.
О технологиях
Какие языки, фреймворки и библиотеки используются на проекте?
Андрей Болгов: Python и Go — наши основные языки разработки на бэкэнде. Мы написали на них тысячи строк кода и сформировали удобную для нас экосистему из популярных фреймворков и библиотек. На python это чаще всего flask, aiohttp, fast-api, sqlalchemy, а на Go — gin, gorm.
Linux — это основная операционная система, которую мы используем при разработке и доставке наших сервисов. Docker используется как основная система для дистрибуции приложений.
Язык фронтенд-разработки — JS. В качестве основы своих проектов мы используем фреймворки Angular и Vue. Мы также используем несколько дизайн-систем: ibm-carbon, ant-design, material. На их основе построены библиотеки ui-kit, c помощью которых мы и разрабатываем наши интерфейсы.
Что вы можете рассказать об архитектуре проектов?
Андрей Болгов: Архитектура строится, исходя из критериев к продукту, его функциональных и нефункциональных требований. Мы строим дата-центры и разрабатываем облако, наши основные акценты — это как раз отказоустойчивость, масштабируемость, безопасность.
Мы строим наше облако по подходу построения облачных решений — knative. Резервируется все, что возможно: на физическом уровне — от хостов до сетевого оборудования, интернет-провайдеры, электрические вводы и дизельные генераторы. Аналогично и на уровне программных решений: никакой сервис не работает в единственном экземпляре, все запускается кластерно. Данные реплицируются на нижнем уровне инфраструктуры (используем кластеры Ceph) и на уровне приложений (делаем бэкапы).
Плюсом ко всему, у нас четко настроены реакции на инциденты и сбои. Мониторится все, данные о метриках дублируются, и есть специальные команды, которые готовят инфраструктуру мониторинга и реагируют на сбои. Таким образом, каждый сервис запускается в нескольких экземплярах, умеет работать с реплицированными данными и выдавать наружу свои актуальные состояния.
Какая у вас принята политика код-ревью?
Андрей Болгов: Во время код-ревью происходит обмен знаниями. Это особенно полезно командам разработки Облака, так как мы отходим от проектной специализации.
Полезно не начинать с кода, а сначала обсуждать дизайн решения в команде, чтобы ревьюер был заранее готов и понимал, о чём идёт речь. Предпочтительный вариант — совместный анализ спецификации, планирующей и обосновывающей изменения.
Код, который проходит ревью, должен сопровождаться тестами, документацией и подробными комментариями. Это упрощает для ревьюера работу, даёт ему контекст.
Изменение должно быть небольшим. Иначе задача становится слишком сложной для читающего, возникает сопротивление, и, скорее всего, нормального анализа не получится.
Нужно понимать, что сабмит кода — это начало разговора, а ревью — это коллаборативный процесс улучшения кода. В связи с этим не стоит реагировать собственнически на отзывы, спорить по каждому поводу без причины и обижаться.
Участвовать в ревью могут все: старшие программисты, младшие программисты и т.д. Даже если навыков для полноценного ревью не хватает, надо помнить, что единственный способ стать достаточно квалифицированным — проводить ревью и мотать на ус комментарии других ревьюеров, смотреть изменения.
Нужно автоматизировать как можно больше. Тут многое зависит от инструментов, которые доступны разработчикам. В идеале при отсутствии должного покрытия тестами мердж реквест автоматически должен отзываться. Имперсонификация в этом месте не даёт программисту лишний раз обидеться или потревожить коллег неготовым кодом.
Рекомендуется не проводить несколько ревью подряд, это создаёт для последующих ревью неправильный психологический фон и обычно приводит к перекосу в оценках.
На нормальную критику нужно реагировать словами или комментом. Чтобы у критикующего не оставалось ощущения, что он перегнул палку или что-то сделал не так. Ревьюер должен правильно формулировать предложения: вместо «почему ты не используешь такую-то библиотеку здесь?» можно написать «могли бы мы в этом месте воспользоваться тем-то?» и так далее. Эти детали не дают автору изменений забыть, что Code Review — это процесс совместного улучшения кода.
Как тестируется код?
Андрей Болгов: Описать то, как у нас это происходит, легче всего через такую концепцию как «пирамида тестирования». Этот метод позволяет делать тестирование экономным, при этом не теряя в качестве продукта.
Кратко, суть концепции в том, что, если представить тестирование как пирамиду, наверху будет ручное, исследовательское и end-to-end тестирование. На этом уровне мы тестируем клиентскую веб-панель — этим занимаются тестировщики в продуктовых командах. Это самый дорогой во всех смыслах вариант:много ресурсов тратится на воспроизведение среды клиента, сценариев использования, особенностей браузера и отрисовки отдельных компонентов. Кроме того, любое изменение в продукте задействует в первую очередь «верхушку» пирамиды, она наименее устойчивая — поэтому end-to-end тесты сложнее и дороже поддерживать.
Далее по уровню находится уровень интеграционных, системных тестов. В нашем случае это делается ребятами, которых мы зовем разработчиками в тестировании. Это все еще достаточно низкоуровневое тестирование: тестируются виртуалки, бэкапы на уровне их логического представления.
Наконец, функциональное и юнит-тестирование кода — то, что является основой пирамиды тестирования. При спуске с уровня тестирования «глазами клиента» до глубокого кода количество тестов увеличивается. Тестов, имитирующих поведение пользователя, значительно меньше чем тех, которые ближе всего к коду: здесь можно протестировать метод, функцию, класс, модуль на питоне. Юнит-тесты делают сами разработчики.
Таким образом, мы стараемся покрывать все уровни тестирования. Признаться честно, пирамида у нас сейчас слегка «кривовата»: больше всего ресурсов пока отдается верхушке. Но мы работаем над этим.
Как устроен процесс документации и ведения базы знаний на проектах?
Андрей Болгов: Мы используем различные модификации подхода Architectural Decision Record (ADR). Документацию такого уровня создают архитекторы, техлиды, сеньоры.
Документация также важна для описания итогового результата: что получилось, как это работает, какие есть у решения эндпойнты, какие данные они возвращают. Для этого есть различные автоматические способы генерации документации (Open API).
Есть сопровождающая документация о том, как использовать продукт — она важна OPS-командам (саппорт или сисадмины, работающие близко к железу). Им нужен набор инструкций, как их действия влияют на программный компонент. Разработчики описывают эту модель: за какую «ручку» дернуть и что получить, за какую последовательность ручек нужно дернуть, чтобы получить нужный эффект от какого-то сценария использования. Если сопровождающей документации нет, то в первую очередь страдает сам же разработчик, ведь к этим моментам при обслуживании возвращаются вновь и вновь.
Клиентскую базу знаний, где продукт описывается понятным языком, создают продакты, аналитики, UX и технические писатели команды знаний. Разработчики лишь валидируют написанное.
Есть и внутренняя база знаний: в ней описывается опыт использования технологий, часто решаемых проблем и т.д. То есть знания, полученные из решения реальных задач. В эту базу знаний контрибьютят все сотрудники компаний. Прямо сейчас у нас открыта вакансия для человека, который поможет нам развивать культуру документации и внимательно следить за всеми артефактами знаний.
Каков процент легаси-кода на проекте, и как часто разработчики занимаются его рефакторингом?
Андрей Болгов: Если суммировать все проекты — легаси у нас процентов 40. Но легаси-код — вещь философская. Приходя в компанию с запущенными продуктами, написанными не вчера, вы столкнетесь с легаси. Но что считают разработчики легаси-кодом?
Кто-то считает, что это код, написанный на несовременном языке, стеке. Если спросить у нас, сколько кодовой базы написано на модном Rust-e, то 0. Но это не значит, что у нас 100% легаси. Кто-то спросит, мол, ну, ладно, а хотя бы на Go? Процентов 25. Все остальное — как будто бы уже не самый популярный, «мохнатый» питон.
А вот «бывалых» разработчиков уже интересует, сколько кода, который в моменте развивается. Наш ответ — 80%. То есть «неприкасаемого» процентов 20. Работает — не трогай, как говорится. Из этих 80% процентов 30 — это новые продукты.
В общем, бОльшая часть кода постоянно переосмысливается. Чаще всего это происходит в рамках плановых работ. Например, из актуального — реализация новой дизайн-системы для нашей веб-панели, которая поможет сделать мощный шаг в сторону ухода от легаси-решений в фронтенде.
