Как поддерживают IT-инфраструктуру в рекламных нетворках — интервью с CTO TwinRed Денесом Киссем
Это еще один эпизод из серии интервью с командой TwinRed, цель которой — показать во всех аспектах работу рекламного нетворка и познакомить вас с теми, кто стоит за компанией TwinRed. Ведь любой бизнес — это, в первую очередь, люди.
Гостем этого интервью стал Денес Кисс, СТО TwinRed. Денес отвечает за все IT-процессы в компании, а это: работа с программистами, контроль качества и ведение процесса разработки продуктов, управление подготовкой и обслуживанием серверов, а также техподдержка как клиентов, так и внутренних запросов, определение процессов для создания еще более совершенного рабочего процесса.
В этом интервью разберемся с устройством IT инфраструктуры в рекламном нетворке и посмотрим как эффективно управлять командой, распределенной по миру.
Привет, Денес. Расскажи для начала о своей карьере в IT.
Когда мне было 13, я увидел у моего друга книгу «Программирование на языке Turbo Pascal», в этот момент и началась моя карьера. Спустя пару лет в старших классах я даже пытался продать первую написанную мной программу, она должна была обучать слепой печати. Программу никто не купил, но у меня появилась мотивация продолжать изучение программирования и IT. В университете я погрузился в изучение Data центров, так как работал операторам хостинга, тогда я узнал очень многое об операциях в IT от ветеранов индустрии. После множества личных проектов я попал в команду Livejasmin на позицию PHP-разработчика. Там я впервые столкнулся с работой с высоконагруженными системами. Мне повезло, что я участвовал в разных проектах: создавал tube сайты, руководил технической стороной AWE (аффилиат нетворк), и последнее, но не менее важное — создал рекламный нетворк с нуля.
После этих проектов руководство оказало мне доверие взять на себя управление IT-направления нетворка TwinRed. Сейчас я работаю в должности технического директора.
Как ты считаешь, какова твоя основная цель в TwinRed?
Моя основная цель — это обеспечить бесперебойную работу и быструю загрузку настолько, насколько это возможно.
Прежде чем перейти к основным вопросам, я хотел бы спросить, из скольки человек состоит команда, которой ты управляешь?
В команде около 20 человек — разработчики, QA, Product owners и DevOps.
Расскажи как у вас устроена команда?
Как я уже говорил, у нас есть 4 отдела.
1. Продукт овнеры: когда в наш отдел попадает новый запрос, они переводят бизнес запросы на технический язык, описывают edge кейсы, готовят UI макеты и подготавливают еще очень много всего. Также они определяют приоритеты и соотносят релизы с бизнес дедлайнами.
2. Обеспечение качества (QA): как только разработчики завершили свою задачу, она уходит в QA отдел для тестов и обзоров. QA проверяет, все ли работает правильно и соответствуют ли спецификации требованиям, выдвинутыми продукт овнерами. Одна из основных их задач — удостовериться, что новые фичи не выходят из строя и соответствуют существующим.
3. IT-операции (DevOp): это ребята по ту сторону сцены. Они обеспечивают необходимую инфраструктуру для работы, например, предоставляют оборудование для новых функций, поддерживают все в обновленном состоянии, предоставляют доступ к разным системам и тесно работают с разработчиками над некоторыми задачами.
4. Разработчики: это настоящие волшебники. Помимо программирования, они планируют архитектуру проектов и создают документацию, тестируют свои разработки, а также обеспечивают первоклассную поддержку.
Описывая все отделы, я понял, что не воспринимаю их как отдельные части. Мы все одна команда. Как правило, каждый из нас делает больше своих прямых обязанностей. Например, разработчики проводят различные тестирования на протяжении всего процесса своей работы, а DevOps часто занимается программированием и так далее. У нас есть общие цели и мы вместе стараемся достичь их наиболее эффективным способом, помогая друг другу.
Где именно находятся сотрудники команды?
Мы работаем из 3 стран: Америка (Лос Анджелес), Венгрия и Украина.
Как ты контролируешь процесс работы на ежедневной основе?
Мы работает по Scrum, а это подразумевает ежедневную live-синхронизацию. Но так как между нами большая разница во времени, я не могу ежедневно общаться со всеми коллегами лично. Поэтому мы разделили всех на 2 виртуальные команды, одна работает в часовом поясе Лос Анджелеса, а другая в CET. Мы созваниваемся каждую неделю и активно используем Slack для решения актуальных вопросов.
Как ты управляешь процессами и отслеживаешь результаты в целом?
При работе по методологии Scrum можно легко смотреть за ходом выполнения каждой задачи, а еще у нас есть KPI для отслеживания эффективности команды в целом. И мы, конечно, используем Jira для трекинга задач и управления релизами.
Какими инструментами ты пользуешься для эффективной удаленной работы IT-команды?
Самое важное, что должно быть внедрено — простой и понятный канал для коммуникации. Я, насколько это возможно, стараюсь говорить с человеком лично, считаю этот способ наиболее эффективным. Говорить напрямую — всегда лучше. Видеозвонки и чаты — это самое меткое оружие. Также считаю обязательным иметь комфортное рабочее место, удобный рабочий стол и стул.
Ну и последний и не менее важный фактор эффективной работы удаленной команды — это вера в своих сотрудников. Доверяйте всем своим сотрудникам и позволяйте работать им без пристального надзора. Но если честно, мне не легко дается просто отойти в сторону и позволить команде делать свою работу.
Какие сложности ты можешь выделить в управлении командой рассредоточенной по миру?
Самое сложное — это разница во времени, но мы научились с этим справляться при помощи хорошо построенной коммуникации.
Рекламный нетворк — это всегда огромные нагрузки? Верно?
Да, именно так. Мы работаем с огромным объемом трафика. Чтобы было понятнее о чем идет речь, скажу: нам приходят семизначное количество запросов в минуту.
С чем это можно сравнить?
Например, Википедия находится на 13 месте в рейтинге Alexa. Судя по отчету, у Википедии около 300 миллионов просмотров страниц в день. Если посчитать, то это примерно 200K запросов в минуту.
Правильно я понимаю, что с падением может столкнуться совершенно любой нетворк. Можешь сказать, во сколько обходится 1 час падения системы?
Скажу так, один час отказа системы — это очень дорого, но мы тщательно планировали нашу архитектуру и внедрили разные методы, и к счастью, у Twinred таких отказов не было.
Какую систему мониторинга вы применяете для предотвращения подобных последствий?
Тестирование, мониторинг, аппаратное и программное резервирование (redundancy). Мы тщательно тестируем каждую разработку, прежде чем выпустить ее на рынок. И это наше обязательное условие.
Мы просматриваем все. Часто встречается, что компании мониторят только техническую сторону, например, проверяют CPU/использование памяти, время ответа и пр. Мы же мониторим и бизнес процессы. Во время релиза мы отслеживаем любые изменения в трафике, поэтому можем заметить проблему на ранних стадиях.
Резервирование также важно для предотвращения падений системы. Сбои оборудования могут произойти в любое время, поэтому наша система спроектирована таким образом, что автоматические сбои остаются незаметными для наших клиентов.
Последнее, что интересно знать — как вы распределяете нагрузку в системе?
Мы используем несколько балансировщиков нагрузки для распределения трафика по разным серверам. Как я уже сказал балансировка и резервирование — самые важные факторы. Несколько балансировщиков, несколько сетевых провайдеров, несколько копий всего, что используется.
Спасибо, Денес. Где читатели могут найти тебя?
Добавляйтесь в Linkedin. Буду рад знакомству.
Другие интервью с ребятами из TwinRed:
1. Интервью с CEO адалт-сетки TwinRed: отключение попандеров, удаленное руководство и новые возможности для арбитражников
2. «Если Google говорит прыгать, вся индустрия должна прыгать» — интервью с директором по продажам в TwinRed