Текст книги "Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях"

Не будем тратить время на попытки преобразований в более консервативных группах, особенно на начальных этапах. Вместо этого направим энергию на создание успеха у групп с меньшими рисками и сформируем базу, опираясь на них (этот процесс будет рассмотрен в следующем разделе). Даже если имеется поддержка со стороны высокого руководства, будем избегать революционного подхода – «большого шока» (то есть новации сразу и повсюду). Вместо этого сосредоточим усилия в нескольких областях деятельности организации, обеспечив тем самым успех инициатив и возможность расширения успеха[43]43
  Преобразования сверху вниз в стиле «большой шок» возможны, примером служит динамичная трансформация компании PayPal в 2012 г., которую возглавлял ее вице-президент по технологиям, Кирстен Волберг. Однако, как и в случае с любым устойчивым и успешным преобразованием, для этого требуется наивысший уровень поддержки со стороны руководства и постоянная концентрация на движении к необходимым результатам. Прим. авт.


[Закрыть].

Распространение DevOps на всю организацию

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

Генерируя успехи, мы получаем право расширить масштабы инициативы DevOps. Мы хотим продвигаться по безопасной последовательности, повышающей уровень доверия к нам, степень нашего влияния и получаемой поддержки. Приведенный ниже список позаимствован из курса лекций доктора Роберто Фернандеса, адаптированного Уильямом Паундсом, профессором менеджмента Массачусетского технологического института. Здесь описаны идеальные фазы, применяемые, чтобы побуждать ответственных лиц создавать и расширять коалиции и обеспечивать базу поддержки преобразований.

1. Найдите новаторов и первопроходцев. Поначалу мы сосредоточиваем усилия на командах, действительно желающих помочь, – это родственные души и друзья по путешествию, и они первыми добровольно захотят пойти в страну DevOps. В идеале это специалисты, пользующиеся уважением и имеющие большое влияние на остальную часть организации, что повышает доверие к нашей инициативе.

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

3. Выявите уклоняющихся. «Уклоняющиеся» – высококлассные и авторитетные специалисты, но они будут, скорее всего, противостоять нашим усилиям (возможно, даже саботировать их). В целом мы обращаемся к этой группе только после того, как привлекли на свою сторону молчаливое большинство, когда в достаточной степени достигли успеха и можем хорошо выступить в защиту нашей инициативы.

Расширение DevOps на всю организацию – непростая задача. Оно может вызвать нежелательные последствия для отдельных сотрудников, отделов и даже для организации в целом. Но, как говорит Рон Ван Кеменад, директор по информационным технологиям компании ING, преобразовавший свою компанию в одну из наиболее популярных организаций в области технологий, «лидерство в изменениях требует мужества, особенно в корпоративных средах, где сотрудники боятся изменений и будут противостоять им. Но если вы начнете с малого, то вам действительно нечего бояться. Любой лидер должен быть достаточно смел, чтобы выделить команды на решение задач, связанных с риском, хотя и предусмотренным».

Заключение

Питер Друкер, лидер в области разработки методов обучения менеджменту, отмечал: «Маленькая рыбка учится быть крупной в маленьких прудах». Тщательно выбирая, где и как начать, мы смогли определить в организации участки, создающие продукт и не затрагивающие при этом деятельность остальных частей организации. Поступая таким образом, мы создаем себе базу поддержки, зарабатываем право расширить использование DevOps и получаем признание и благодарность заинтересованных лиц (сотрудников, клиентов и т. п.).

Глава 6. Основные сведения о работе в потоке создания ценности, превращении его в прозрачный и расширении на всю организацию

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

В предыдущей главе мы рассказали о проведенных компанией Nordstrom преобразованиях DevOps под руководством Кортни Кисслер и ее группы. В процессе многолетней работы они выяснили: один из наиболее эффективных способов начать улучшение любого потока создания ценности – провести рабочее совещание с основными заинтересованными сторонами и выполнить упражнения по отображению потока создания ценности. Этот процесс описан в данной главе. Он поможет зафиксировать все шаги создания ценности.

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

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

Кисслер объясняла:

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

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

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

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

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

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

Определение всех команд, обеспечивающих поток создания ценности

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

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

• владелец продукта. Представитель компании, определяющий набор функциональности в следующей версии продукта;

• разработчики. Команда, ответственная за разработку функциональности продукта;

• служба качества. Команда, ответственная за работу петель обратной связи и обеспечивающая, чтобы продукт функционировал так, как задумано;

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

• отдел информационной безопасности. Команда, отвечающая за обеспечение безопасности систем и данных;

• менеджеры релиза. Специалисты, ответственные за управление и координацию развертывания в производство и процессы релиза;

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

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

Определив членов потока создания ценности, сделаем следующий шаг – получим конкретное понимание, как выполняется то, что задокументировано в виде карты потока создания ценности. В потоке создания ценности деятельность начинается с владельца продукта – он либо предоставляет запрос от клиента, либо предлагает новую бизнес-гипотезу. Некоторое время спустя она будет передана разработчикам, они воплотят функции в код и внесут код в хранилище контроля версий. Затем сборки кода будут интегрированы, протестированы в среде, близкой к производственной, и, наконец, развернуты в производство, где они (в идеале) начнут создавать продукт для клиентов.

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

Наша цель не документировать каждый шаг до мельчайших подробностей, а понять, какие именно области потока создания ценности ставят под угрозу наши цели – быстрый ход потока, короткое время выполнения заказов и получение результатов клиентами. В идеальном случае мы должны собрать исполнителей, обладающих полномочиями изменить поток создания ценности[44]44
  Это особенно важно, поскольку мы ограничиваем уровень детализации собираемой информации – ведь время каждого из нас ценно и невосполнимо. Прим. авт.


[Закрыть].

Деймон Эдвардс, соведущий подкаста DevOps Cafе, отмечал: «По моему опыту, упражнения по составлению карт потоков создания ценности всегда открывают людям глаза. Нередко они при этом впервые обращают внимание, как много надо сделать и насколько чрезмерные усилия приложить, чтобы доставить продукт клиенту. Может оказаться, что отдел эксплуатации в первый раз видит последствия того, что разработчики не имеют доступа к правильно настроенной среде, и это создает еще более сумасшедшие условия во время развертывания кода. Отдел разработки может впервые увидеть, какие чудовищные усилия приходится прикладывать тестировщикам и отделу эксплуатации для развертывания их кода в производстве: им приходится еще долго заниматься им после того, как некоторая функция помечена флажком “выполнено”».

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

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

• Места, где производятся повторная работа или переделка либо возникает потребность в них.

На первом этапе документирования потока создания ценности должны рассматриваться только блоки высокого уровня. Обычно даже для сложных потоков создания ценности группы могут сформировать схему с числом блоков от 5 до 15 в течение нескольких часов. Каждый блок процесса должен включать в себя время выполнения заказа и время производства элемента, над которым ведется работа, а также показатель %C/A, измеренный на уровне конечных клиентов[45]45
  И наоборот, существует много примеров использования инструментов таким образом, который обеспечивает отсутствие изменения поведения. Например, организация переходит к использованию инструмента планирования Agile, но затем настраивает его на процесс каскада, тем самым сохраняя статус-кво. Прим. авт.


[Закрыть].

Мы используем количественные показатели из карты потока создания ценности, чтобы верно направить усилия по улучшению потока. В компании Nordstrom, например, внимание было сосредоточено на низком показателе %C/A в форме запроса, отправляемого менеджерами без указания табельного номера. В других случаях это может быть длительное время выполнения заказа или низкое значение %C/A при предоставлении командам разработчиков правильно настроенных тестовых сред. Или это может быть связано с длительным периодом выполнения регрессионного тестирования перед релизом новой версии программного обеспечения.

Рис. 10. Пример карты потока создания ценности (источник: Humble, Molesky, and O’Reilly, Lean Enterprise, 139)

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

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

Создание команды преобразований

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

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

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

В своей книге The Other Side of Innovation: Solving the Execution Challenge, Виджей Говиндараджан и Крис Тримбл, преподаватели Такской школы бизнеса в Дартмутском колледже, описали тематические исследования по вопросу, как вводить инновации без разрушений, несмотря на мощную инерцию повседневной деятельности. Они документально фиксировали, как автомобильные страховки по методу «продвижение клиента» были успешно разработаны и продавались компанией Allstate, как прибыльный цифровой издательский бизнес был создан газетой Wall Street Journal, как модифицировались невиданные кроссовки для бега по пересеченной местности, разработанные компанией Timberland, и как развивался первый электромобиль компании BMW.

Основываясь на своих исследованиях, Говиндараджан и Тримбл утверждают: организациям необходимо создать специальную команду преобразований, способную работать без связи с остальными частями организации, несущими ответственность (они называют эти части «выделенная группа» и «двигатель производительности» соответственно).

Прежде всего мы будем возлагать на специализированную группу ответственность за достижение четко определенных и поддающихся измерению результатов на уровне системы (например, уменьшить время развертывания от «код зафиксирован в системе контроля версий» до «код успешно работает в производственной среде» на 50 %). Чтобы реализовать такую инициативу, выполним следующие действия.

• Назначим членов выделенной команды, чья деятельность будет направлена исключительно на усилия по трансформации DevOps (в отличие от распространенной практики вроде «все ваши текущие обязанности сохраняются, но 20 % вашего времени вы должны тратить на эту новую штучку DevOps»).

• Выберем среди членов команды специалистов широкого профиля, имеющих навыки в различных областях.

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

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

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

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

Договориться об общей цели

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

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

• Снизить процентную долю расходов на поддержку продуктов и незапланированные работы на 50 %.

• Обеспечить срок с момента фиксации кода до релиза его в производство не более недели для 95 % изменений.

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

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

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

Продолжать улучшения, планируя на короткие сроки

В любом проекте преобразования DevOps мы должны сохранить горизонты планирования близкими, как если бы речь шла о стартапе, выпускающем продукт или выполняющем разработку для клиента. Инициативы должны быть нацелены на создание измеримых улучшений или получение рабочих данных в течение нескольких недель (в крайнем случае – месяцев).

Продолжая планировать на небольшие интервалы времени и поддерживая короткие итерации, мы достигаем следующего:

• гибкости и способности быстро изменить приоритеты и планы;

• уменьшения интервала между временем, когда были затрачены усилия, и реализацией улучшений, что укрепляет петлю обратной связи и повышает вероятность того, что она упрочит желаемое поведение – когда инициативы по улучшению успешны, это поощряет дополнительные инвестиции;

• более быстрого обучения, начинающегося с первой итерации, что означает более быструю интеграцию выводов на следующем шаге;

• уменьшения усилий, необходимых для создания улучшений;

• более быстрой реализации усовершенствований, значительно влияющих на повседневную деятельность;

• сокращение риска того, что проект погибнет, прежде чем мы сможем получить какие-либо ощутимые результаты.

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

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

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

Мы будем активно управлять техническим долгом, расходуя по меньшей мере 20 % всех усилий в области разработки и управления эксплуатацией на рефакторинг, средства автоматизации, улучшение архитектуры и нефункциональные требования (NFR), такие как сопровождаемость, управляемость, масштабируемость и надежность, пригодность к тестированию и развертыванию, а также безопасность.

Рис. 11. Вкладывайте 20 % времени в создание положительных ценностей, даже если они незаметны для пользователя (источник: запись Machine Learning and Technical Debt with D. Sculley в подкасте Software Engineering Daily, November 17, 2015, http://softwareengineeringdaily.com/2015/11/17/machine-learning-and-technical-debt-with-d-sculley/)

После изучения опыта компании eBay, оказавшейся в конце 1990-х гг. практически на грани исчезновения, Марти Кэган, автор книги Inspired: How To Create Products Customers Love, считающейся наиболее фундаментальным исследованием по конструированию продукции и управлению, пришел к такому выводу.

«Сделка с владельцами и инженерами заключается обычно так: отдел управления производством отнимает у руководителей верхнего звена право распоряжаться примерно 20 % времени инженерной группы и дает ей право тратить его так, как она посчитает нужным. Это время можно использовать, чтобы переписать код заново, перепроектировать систему или выполнить рефакторинг проблемных частей кода… все, что они считают необходимым сделать во избежание появления нужды прийти к команде и признаться: “Мы должны остановиться и переписать весь код”. Если ситуация действительно тяжелая, то на эти цели можно отдать 30 % ресурсов или даже больше. Однако я начинаю нервничать, когда сталкиваюсь с командами, уверенными, будто справятся с подобными задачами, получая гораздо меньше ресурсов, чем 20 %».

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

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

Практический пример

Операция 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 функциональным возможностям. Сделав поиск и устранение проблем частью повседневности, мы управляем техническим долгом, чтобы избежать ситуации, когда вдруг окажемся «на грани исчезновения».

Увеличить прозрачность работы

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