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

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

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

Сценарий: автоматизированные роботы-доставщики

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

Преднамеренный и разумный технический долг

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

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

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

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

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

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

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

Технический долг в проектах машинного обучения

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

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

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

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

  • Зависимости от данных. Качество и количество данных, от которых зависит проект машинного обучения, могут меняться со временем либо из-за изменений в источнике данных, либо на различных этапах обработки данных, что приводит к необходимости постоянной проверки качества данных и непрерывной обработки данных. мониторинг систем в продакшене (см. лекцию «Тестирование в продакшене»). Например, в идеале мы должны создать схему для данных, отслеживать сдвиг распределения и отслеживать происхождение данных, собранных с робота, чтобы обновления программного обеспечения, изменяющие какой-либо поток данных, или загрязнённый объектив камеры робота не приводили к сбоям. Если очистка и обеспечение качества данных не автоматизированы и не контролируются, незначительные сдвиги могут сломать систему или вызвать ее медленную деградацию с течением времени (см. лекцию о качестве данных).
  • Мониторинг долга: оценить модель на статическом наборе данных несложно, но создание инфраструктуры мониторинга для оценки качества модели в производственной среде (см. главу «Тестирование в производственной среде») требует значительных затрат на раннем этапе. Отказ от создания надежной инфраструктуры мониторинга может привести к большим затратам позже, когда не будет замечено, как ухудшается качество модели или как она плохо обслуживает определенные группы населения. Например, мы можем не заметить, как роботы попадают в необычное количество аварий в дождливую погоду.
  • Низкое качество кода, отсутствие автоматизации конвейера: модели с мощными библиотеками легко разрабатывать на моментальном снимке данных в блокноте и копировать полученную модель в производственную систему. Не построение надежного конвейера, например, автоматизация всех шагов, удаление неработающего кода, мониторинг всех шагов конвейера (см. главу «Качество инфраструктуры») и отказ от написания пригодного для использования и сопровождения кода (например, использование абстракции, документирование кода, избегание клонирования кода) может сэкономить некоторые усилия. изначально, но может значительно увеличить усилия для будущих выпусков и отладки. Например, мы можем запустить роботов на старых и несовместимых версиях моделей, потому что не заметили, что процесс обновления на большинстве из них не прошел.
  • Долг видимости: модели часто изучаются на основе данных из различных источников, и прогнозы модели могут использоваться различными другими компонентами системы. Без четкого контроля версий данных и отслеживания происхождения (см. главу «Происхождение») легко потерять связь с зависимостями, что затруднит развитие системы. Например, мы можем не помнить, что обучающие данные для модуля обнаружения препятствий в роботе были дополнены для повышения надежности модели, и забыть об этом шаге в будущих версиях, что приведет к гораздо более слабым моделям.
  • Запутанность: легко создавать продукты, которые используют несколько моделей с машинным обучением, и некоторые модели потребляют выходные данные других моделей. Однако трудно разделить эффекты этих моделей в проекте и протестировать их модульно. Значительные усилия могут потребоваться для выделения моделей при проектировании системы, а также для тестирования и мониторинга на уровне системы (см. главы «Обеспечение качества»).
  • Циклы обратной связи. Тщательный анализ требований может помочь обнаружить потенциальные циклы обратной связи и внести изменения в проектирование системы до того, как они станут вредными; пропуск такого анализа может привести к проявлению петель обратной связи в производстве, которые наносят ущерб и которые впоследствии будет сложнее исправить (включая серьезные последствия для этики и безопасности с долгосрочным вредом). Например, робот-доставщик, оптимизированный для быстрой доставки, может вести себя рискованно, что приводит к тому, что пешеходы в основном уклоняются от робота, что приводит к еще более высокой скорости и положительному подкреплению для более быстрой доставки, но менее безопасным районам.

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

Управление техническим долгом

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

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

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

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

Резюме

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

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

Дальнейшие чтения