Книга: Руководство по DevOps

Операция InVersion в компании LinkedIn (2011 г.)

Операция InVersion компании LinkedIn демонстрирует интересное тематическое исследование, свидетельствующее, что необходимость выплачивать технический долг — часть повседневной деятельности. Спустя шесть месяцев после успешного проведения IPO в 2011 г. LinkedIn продолжала бороться с проблемами развертывания: оно стало настолько болезненным, что они запустили операцию InVersion, и разработка новых функциональных возможностей и развитие имеющихся были полностью остановлены на два месяца. Все силы были брошены на пересмотр конфигурации вычислительных сред, процедур развертывания и архитектуры.

Компания LinkedIn была создана в 2003 г., чтобы пользователи могли подключаться к сети для улучшения возможностей поиска работы. К концу первой недели существования в ней насчитывалось 2700 участников. Спустя год их число превысило миллион и с тех пор росло экспоненциально. В ноябре 2015 г. в LinkedIn было зарегистрировано свыше 350 миллионов человек, создающих десятки тысяч запросов в секунду, в результате чего на серверы данных LinkedIn каждую секунду поступают миллионы запросов.

Вначале LinkedIn использовала в основном доморощенное приложение Leo, монолитное приложение Java, обслуживавшее каждую страницу с помощью сервлетов и управляемых JDBC соединений с различными внутренними базами данных Oracle. Однако для удовлетворения растущего трафика в первые годы работы компании две важнейшие услуги были отделены от Leo: первая обрабатывала запросы о соединениях участника и делала это полностью в памяти, а вторая — поиск участников — опиралась на первую.

К 2010 г. большинство новых разработок сопровождалось созданием новых служб, и уже почти сто таких служб функционировало за пределами Leo. Проблема заключалась в том, что обновления в Leo развертывались только раз в две недели.

Джон Клемм, старший технический менеджер LinkedIn, пояснил, что к 2010 г. в компании накопилось значительное количество проблем с Leo. Несмотря на вертикальное масштабирование этого приложения путем добавления памяти и процессоров, «Leo часто давал сбои, было трудно найти причину неполадки и восстановить работу, сложно добавить новый код… Нам было ясно, что необходимо “убить Leo” и разделить на много небольших функциональных и не влияющих друг на друга служб».

В 2013 г. журналист Эшли Вэнс из агентства Bloomberg описывал: «Если бы LinkedIn попытался добавить группу новых функций одновременно, сайт рухнул бы и превратился в груду обломков, и инженерам пришлось бы работать ночами, устраняя возникшие проблемы». К концу 2011 г. работа до глубокой ночи была уже не чем-то из ряда вон выходящим, поскольку проблемы приобрели грандиозный масштаб. Некоторые из инженеров верхнего уровня компании, включая Кевина Скотта, пришедшего в LinkedIn на должность технического директора за три месяца до того, как сайт компании начал свою деятельность, решили полностью остановить работу над новыми функциями и перевести весь отдел разработки на укрепление основной инфраструктуры сайта. Они назвали это операцией InVersion.

Скотт начал операцию InVersion как путь к «внедрению зачатка культурного манифеста в инженерную культуру его команды. Никакая новая функция не будет разрабатываться, пока компьютерная архитектура LinkedIn не будет переделана — именно это нужно для бизнеса компании и ее команды».

Скотт так описывал одну из неприятных сторон этого решения: «Вы начали всем видимую деятельность, весь мир смотрит на вас, и тут мы заявляем руководству, что не собираемся делать ничего нового, так как все инженеры будут работать над проектом [InVersion] два следующих месяца. Это пугает».

Однако Вэнс рассказал о значительном положительном результате операции InVersion. «LinkedIn создал целый пакет программного обеспечения и инструментов, помогающих разрабатывать код для его сайта. Вместо того чтобы ждать несколько недель, пока новые функции проделают свой путь на главный сайт LinkedIn, инженеры могли разработать новый сервис, использовать ряд автоматизированных систем изучения кода с целью поиска ошибок в коде и проблем при взаимодействии сервиса с существующими функциями и запустить его прямо на сайте LinkedIn… Инженерная служба LinkedIn теперь выполняет крупные обновления сайта трижды в день». За счет создания более безопасной системы создаваемая продукция обеспечивает меньший объем сверхурочной работы по ночам и большее количество времени для разработки новых, инновационных функций.

Как писал Джош Клемм в статье о масштабировании в LinkedIn, оно «может быть измерено через многочисленные аспекты, в том числе организационные… Операция InVersion позволила всей инженерной организации сосредоточить усилия на улучшении и инструментов, и разворачивания, и инфраструктуры, и производительности труда разработчиков. Она была успешной в деле предоставления инженерам гибкости, в которой мы нуждались для создания масштабируемых новых продуктов, имеющихся у нас сегодня… В 2010 г. мы уже имели более 150 отдельных сервисов. Сегодня у нас есть более 750 сервисов».

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

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

Оглавление книги