IT в быстрорастущей компании: хайп vs здравый смысл

8 минут

За несколько лет IT-инфраструктура компании может кардинально измениться. Как переживают эти изменения разработчики и менеджеры? Почему технологический прогресс важен с точки зрения HR? И вообще: новые IT-технологии — это хайп или необходимость? Ищем ответы на эти вопросы, опираясь на опыт сервиса онлайн-планирования путешествий Booking.com.

Статья на основе подкаста «Завтра облачно». Гости выпуска – Иван Круглов (principal developer Booking.com) и Дмитрий Лазаренко (руководитель PaaS-направления Mail.Ru Cloud Solutions).

Послушать: ВКонтакте, iTunes, Google Podcasts, Яндекс.Музыка, SoundCloud

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

Сначала польза, потом хайп: пример роста Booking.com от одной базы данных до нескольких тысяч разработчиков

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

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

В конце 90-х в российском офисе Booking.com был один компьютер с одной базой, написанной на ASP, потом компания перешла на Perl. Сначала эта база переросла в отдельный сервер, затем разместилась на нескольких серверах. Появились отдельные базы узкого назначения: для систем отелей, для бронирования.

Когда эти системы переросли в отдельные машины, пришлось масштабироваться. В Booking.com в течение года есть два высоких сезона: лето и новогодние/рождественские каникулы. Из года в год у компании одна задача: чтобы система пережила эти пики. Каждый раз они достигают новых величин, и задача усложняется.

IT-инфраструктура компании масштабировалась до тех пор, пока не был исчерпан потенциал роста в конкретных технологиях. Весь код был написан на Perl, в какой-то момент стало понятно: дальнейшее развитие на этих рельсах невозможно. Чтобы выйти на новый уровень, пришлось с нуля перестроить систему компании, после чего процедура вытаскивания данных пошла в десятки и сотни раз быстрее. При этом не только повысилась производительность, но и улучшилось качество.

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

Kubernetes самодостаточен, в нем есть все нужные инструменты, и процесс внедрения прост, если систему компании сразу строить на нем. Но в Booking.com уже была своя система баз данных, кешей, мониторинга. Kubernetes пришлось внедрять в готовую инфраструктуру, некоторые ее механизмы продолжили работать отдельно.

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

В 2013 году в Booking.com было несколько сотен разработчиков, сейчас их около 2 000, система масштабируется, добавляются новые возможности.

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

Мода на технологии: to be or not to be?

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

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

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

Например, Kubernetes некоторые используют только потому, что это модно и популярно у разработчиков, компания становится привлекательнее, как работодатель. И это пример не только про Kubernetes — скоро что-то похожее будет происходить с Lambda или Service mesh. Пока это сырые технологии, но к 2020 году они могут раскрутиться и стать хайповыми.

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

Когда компании нужны новые технологии

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

Компания может встать на путь технологических изменений по четырем причинам:

  1. Растут нагрузки. У любой IT-системы есть определенная количественная нагрузка: число транзакций в секунду, число запросов, объем данных, которые она может хранить. Обычно с ростом компании требования к системе увеличиваются. Если ресурсов не хватает, на помощь приходят новые технологии
  2. Нужны качественные изменения. Одно дело — увеличить количество клиентов в полтора-два раза, другое — выйти на новые рынки, предложить новые продукты. Это качественные изменения, и если существующая система их не обеспечивает, ее надо менять.
  3. Инициатива сотрудников. Иногда двигателями прогресса выступают сотрудники, понимающие потребности бизнеса. Бывает, что низкоуровневые доработки кода, всевозможные «допиливания» системы кажутся компании третьестепенными, но на самом деле влияют на конечный продукт и пользовательский опыт клиентов.
  4. Пример конкурентов. Многие компании внедряют то, что успешно используют конкуренты. Нужно учитывать, что бизнесу иногда кажется, будто у конкурентов дела идут лучше, поэтому нужно срочно менять свою инфраструктуру. Желание слепо подражать другим участникам рынка стоит тормозить, ориентироваться на реальные потребности компании. Полезен и негативный опыт конкурентов, хотя о нем стараются не распространяться публично. Знание о чужих (и собственных) ошибках может сэкономить массу усилий и подтолкнуть к поиску других вариантов решения задачи.

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

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

Внедряем хайповые технологии, не забывая про здравый смысл

  1. Переход на новые технологии — кардинальное изменение, которое должно помочь решить новые задачи. Модный инструмент сам по себе ничего не стоит, но если он приносит пользу бизнесу, значит, все было не зря.
  2. HR-менеджеры могут продвигать хайповые технологии для привлечения кадров. Компания, которая находится на пике нового, привлекательнее, как работодатель. Иногда внедрять новые инструменты приходится из-за того, что на рынке становится меньше специалистов, способных поддерживать старые системы
  3. Внедрение новых технологий может идти четырьмя путями: растет нагрузка на существующую инфраструктуру; нужны качественные изменения для выхода на новый рынок; сотрудники понимают, что нововведения улучшат бизнес-процессы; прогресс двигает конкуренция на рынке.
Group 40Group 44Group 43Group 46Group 41Group 27Group 42Group 39