Денис Хориков: Техдолг. Управляемый процесс или скрытая угроза?

Логотип компании
Технологический долг — неизбежная часть развития ИТ-систем, но его неконтролируемый рост может обернуться серьезными проблемами. В интервью IT Manager Денис Хориков, директор Технического департамента SMART technologies, объяснил, как контролировать накопление техдолга, когда временные решения оправданы, а когда превращаются в проблему, и какие инструменты помогают компаниям держать ИТ-инфраструктуру в порядке.

Какие факторы приводят к накоплению технологического долга на разных этапах жизненного цикла ИТ-систем?

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

Можно распространить понятие техдолга и на процесс внедрения. Проиллюстрирую примером крупной многопользовательской государственной системы, требующей разграничения прав по категориям пользователей. Если в тестовый период не отладить все процессы, то на момент эксплуатации это сделать уже затруднительно. Например, переконфигурация DMZ (Demilitarized Zone — демилитаризованная зона) — сегмента сети, содержащего общедоступные сервисы и отделяющего их от частных, аналогична рефакторингу кода в разработке.

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

Legacy и «костыли»: когда это рабочая необходимость, а когда мина замедленного действия?

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

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

С какими legacy-системами чаще всего приходится возиться и почему от них так сложно избавиться?

Если системы построены вокруг ядра, не подлежащего модернизации, то рано или поздно они переходят в разряд legacy-систем. Они встречаются среди банковских, производственных, транспортных, CRM-cистем — за долгие годы эксплуатации компании настолько дополнили и адаптировали их под себя, что перейти на что-то новое, обладающее тем же функционалом, достаточно сложно. Компаниям приходится содержать избыточный штат ИТ-персонала: специалистов для обслуживания legacy-систем и сотрудников, владеющих современными технологиями, — для работы с добавляемыми современными приложениями. К примеру, банковские учреждения США страдают из-за большого объема программных продуктов, написанных на языке COBOL. В России эта проблема менее выражена за счет более поздней цифровизации отрасли.

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

Как превратить управление техдолгом в рабочий процесс, а не в хаос? Какие методологии и инструменты помогают держать его под контролем?

Управление технологическим долгом — это бизнес-процесс, и для него хороши традиционные ПО для управления проектами: Jira, Microsoft Project, отечественные Сфера (Т1), RedMine, open source-решение OpenProject и другие. Различные методологии позволяют рассчитать, какого объема может достигать техдолг от текущего пайплайна, и в идеале техдолг должен снижаться с течением времени.

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

Стратегия борьбы с технологическим долгом

Еще один частый источник наращивания техдолга — пренебрежительное отношение к технической документации: форсирование сроков разработки вкупе с обещанием когда-то в будущем задокументировать ход работ. Меньше чем через год восстановить детали разработки, настройки и взаимодействия сетей и инфраструктуры может быть весьма затруднительно. Как этого избежать? Существуют единые платформы разработки документов, унифицированные стандарты. Кстати, в понимании важности документирования и связи с процессом разработки была одна из причин популярности продуктов Atlassian — Confluence (единое документированное пространство общения) и Jira или «Сфера» (для управления проектами разработки, в которой в том числе рассчитывались техдолги, учитывались вносимые изменения, исправления и т. д.). Для грамотного разработчика это как воздух, которым он дышит, — то, что само собой разумеется. Но это действительно важно.

Как не превратить техдолг в снежный ком? Какие методы помогают его сдерживать?

Для того чтобы предотвратить накопление техдолга в разработке, полезно прописать правила. Например, приостановка работ над полезными функциями через три спринта на каждый четвертый спринт, с выделением его только для выплаты техдолга. Или же резервирование фиксированного процента рабочего времени в рамках каждого спринта на закрытие техдолга. Или выделение сотрудников на выплату техдолга. В парадигме Waterflow-разработки, как это ни странно, когда не знаешь, что дальше делать, может помочь сориентироваться ГОСТ. Несмотря на известные шутки и нелюбовь к нему, ГОСТ создавался не для того, чтобы мешать, а чтобы нормализовать и помогать работать в будущем. Он дает ответы на многие вопросы, о которых нужно задумываться в самом начале проектирования, а не «тяп-ляп — и в продакшн».

Повышенное внимание следует уделять архитектуре проектируемых систем, закладывая большой запас с учетом развития технологий, мощностей. Классический пример — операционная система Z/OS, к разработке которой IBM приступила в конце 1960-х годов, и архитектура которой не претерпела изменений в течение 30 лет. Проработка архитектуры вкупе с модульным подходом позволяет системе дольше оставаться на плаву. Модульный подход (системы контейнеризации являются наиболее ярким и упоминаемым представителем этого подхода) позволяют оперативно менять «обвес» системы, не внося изменений в архитектуру — это также обеспечивает снижение техдолга за счет замены устаревающих модулей без затрат на закрытие техдолга по ним.

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

В целом инфраструктура, системный софт с точки зрения архитектуры менее подвержен изменениям, более стабилен и консервативен, чем разработка прикладных систем и Middleware, где очень часто все меняется. Те же самые сети можно построить по консервативному методу и по инновационному, но глобальных отличий (кроме удобства и т. п.) на средних объемах вы не увидите — решение будет рабочим долгое время. Например, OpenShift не так быстро меняет архитектуру, как разработка в КХД. Универсального правила, кроме мониторинга ситуации и оперативного принятия решений по его результатам, не существует.

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

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

Можно ли дорабатывать неподдерживаемые зарубежные ИТ-системы или это путь в никуда?

Эти системы можно сравнить с неким хосписом, который нельзя трогать, иначе они могут сломаться. Их нужно застабилизировать, можно пытаться дорабатывать внешними модулями. Возьмите для примера базу данных Oracle, обновлять ее нельзя, только заморозить и использовать. Естественно, новые обновления давали бы новые возможности и исправляли бы технические долги разработчика, но они не доступны. Что в результате? Техдолг будет накапливаться. И в определенный момент они станут хосписом, который нельзя развивать. И даже open source становится более инновационным, чем замороженные системы.

Поэтому сейчас многие стараются уходить от legacy-систем, смотрят в сторону того же open source, так как им требуется развитие, они понимают, что есть техдолги, которые надо исправлять, а вендоры не готовы оказывать поддержку. Кто-то дорабатывает замороженные системы, включая low-код, в частности есть крупные заказчики, которые, например, выкупали у производителя коды для самостоятельных доработок. Более того, сейчас достаточно много проектов не только по миграции, когда приходится с нуля разрабатывать аналог legacy-системы.

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

Как избежать ситуации, когда техдолг начинает тормозить бизнес и какие экономические последствия это может иметь?

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

Стратегии снижения технического долга без ущерба бизнесу

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

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

Насколько критична вовлеченность руководства в управление техдолгом и к чему приводит ее отсутствие?

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

Как бизнесу удавалось снизить техдолг? Есть ли примеры из вашей практики?

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

Еще пример. В одном крупном интеграторе при банке есть практика взаимодействия команд разработки «по подписке». Как есть Internet of Things, использующий определенные протоколы для взаимодействия устройств и центральной системы, так и близкая по идее концепция подписочной модели в разработке, event-driven architecture: в такой архитектуре компоненты отвечают на изменения статуса данных, что делает нагрузку на модули системы или источники данных более стабильной, а систему —- масштабируемой. Здесь речь идет как о разработке, так и о доработке продуктов. И основная цель — снизить количество ошибок и, соответственно, доработок.

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

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

Опубликовано 05.02.2025

Похожие статьи