Джин Ким - Руководство по DevOps

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

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

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

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

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

Мы будем активно управлять техническим долгом, расходуя по меньшей мере 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 демонстрирует интересное тематическое исследование, свидетельствующее, что необходимость выплачивать технический долг — часть повседневной деятельности. Спустя шесть месяцев после успешного проведения 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.