Меня зовут Андрей Никольский, я Head of Platform в Банки.ру. Сегодня хочу обсудить не самую приятную, но важную тему: технический долг и как с ним работать.
Любой разработчик или руководитель неизбежно сталкивается с техдолгом: либо устраняет его, либо создает. Чаще всего — и то, и другое одновременно. Год назад я решил глубже разобраться в этом вопросе и начал изучать, что происходит в индустрии: как компании работают с техдолгом в теории и на практике, какие подходы применяют и с какими проблемами сталкиваются. Потом я структурировал, что есть по этой теме у нас в Банки.ру и решил написать статью. Будет много ссылок на англо- и русскоязычные статьи и доклады, рекомендую изучить каждую ссылку для полноты понимания.
Содержание статьи:
Классификация техдолгов
Мы привыкли к тому, что технический долг – это просто нечто, что надо отрефакторить. Но если почитать индустриальный опыт, обработанный опытными инженерами (рекомендую всю статью), то понятие технического долга можно классифицировать по категориям:
Code debt. Собственно код, который требует рефакторинга. Я характеризую это как проблемы, которые можно найти статическим анализом кода.
Defect debt. Долг, при котором копятся нерешенные баги. Другими словами, это бэклог с мелкими проблемами, до которых не доходят руки. Очень похож на предыдущий, но статическим анализом не находится.
Design debt. Долг, связанный с внутренней архитектурой приложения. В частности, он охватывает взаимодействия между модулями, а также структуру, паттерны и их использование. Я в дальнейшем возьму на себя смелость переопределить эту категорию.
Documentation debt. Вид долга, при котором документация отстает от кода. Наверное, это один из самых популярных технических долгов.
Testing debt. Отсутствие юнит-тестов и слабое покрытие приложения тестами.
Automation debt. Нехватка автоматизации, ситуация, когда нам приходится много работать руками.
Compliance debt. Долг в области соблюдения регуляторных требований, которые мы должны выполнять для работы в рамках законодательства. В частности, это соблюдение законов о персональных данных, банковской деятельности, KYC и так далее.
Architectural debt. Проблемы архитектуры, вроде отсутствия слоя кэширования перед приложением или только немасштабируемый монолит, который приходится закидывать ресурсами вертикально.
People/resource debt. Долг, представляющий собой нехватку экспертизы в команде или компании.
Также технические долги можно классифицировать по влиянию – точка зрения Мэтта Гринберга и Кейи Патель.
Maintenance debt. Долг сопровождения. Характеризуется постепенным увеличением времени выхода фич и/или устранения багов. Усложняет и удорожает сопровождение 1-й и 2-й линий: нечитаемые/обильные логи, поток багов или ошибок, который нужно кому-то разбирать.
Developer efficiency debt. Долг эффективности разработки. Например, разработчик каждый спринт может тратить все меньше времени на продуктовые фичи и вынужден заниматься задачами, которые на продукт непосредственно не влияют, или, наоборот, каждая продуктовая фича требует всё больше усилий (и времени). Этот долг влияет на TTM (time to market), фокус-фактор, точность оценки. Если точность оценки начала падать, значит, нас начали настигать проценты этих долгов.
Stability debt. Долг стабильности. Приложение часто падает. Влияет на SLA/RTO.
Security debt. Безопасность/защита. Прежде всего, конечно, это инциденты ИБ. А также, например, число уязвимостей, которые найдутся при пентесте.
Technical product debt. Долг логики/поведения продукта. Появляется, когда разработчики что-то где-то не доделали, не реализовали некие фичи, которые не влезли нам в спринты. Влияет на продуктовые метрики. Может также моментально переполнить долг сопровождения.
Decision debt. Этот долг вынуждает нас принимать не самые оптимальные решения. К примеру, мы хотим сделать просто и понятно, но не можем этого сделать из-за того, что выбрали не тот стек технологий. Например, выбрали какой-то кровавый энтерпрайзный софт с поддержкой, и вендор выкручивает вам руки.
Происхождение
Согласно разным источникам, классификация происхождения долга немного разнится, рассмотрим две основные.
1 вариант
Классическая картинка “происхождение техдолга” по Мартину Фаулеру.
На ней технические долги разделены на 4 ячейки – предумышленный/непредумышленный и безрассудный/благоразумный.
Давайте попробуем разобраться, как это выглядит на практике. Уверен, что каждый разработчик узнает немало примеров таких “источников”.
1) Предумышленный и Безрассудный — появляется, когда команда принимает решения на ходу, не особо задумываясь о будущем. Код пишется так, как пишется, а разбираться с последствиями планируется когда-нибудь потом (привлечем раунд инвестиций, закроем квартал, запустим MVP). Неправильно мотивированная команда (сдаем проект за три месяца, и отдыхать), слишком спешащий руководитель, сжатые сроки, регуляторные ограничения, суровый заказчик и так далее.
2) Предумышленный и Благоразумный — это долг, который закладывается осознанно. Разработчики понимают, что-то нужно будет доработать, и оставляют себе пометки в коде. Например, в Банки.ру мы недавно пытались понять, почему не работает одна фича, и обнаружили в логичном и правильном месте для её реализации комментарий «TODO: сделаем потом». Конечно же, «потом» наступил в самый неподходящий момент и сорвал нам сроки релиза другой фичи. Подход все же лучше, чем игнорирование проблем, но помните, что выплата по таким долгам почти всегда требуется внезапно.
3) Непредумышленный и Безрассудный — самый сложный вид долга, потому что его нелегко предсказать и предотвратить. Разработчики могут быть уверены, что делают все правильно, но позже выясняется, что выбранные подходы оказались неудачными и привели к накоплению проблем в коде или системе.
4) Непредумышленный и Благоразумный — возникает из-за недостатка знаний и опыта. Разработчики делают все возможное, но, например, могут не знать лучших практик или специфики предметной области. “Зеленый” тимлид зашивается и зависает при принятии решений, команда джунов пишут как умеют с помощью нейросетей.
2 вариант
Второй вариант происхождения техдолгов выглядит немного иначе (источник). Здесь выделены два варианта: предумышленный и непредумышленный долг. Но каждый их них еще разделен на две подкатегории: технические причины и организационные. Отдельной причиной стоит легаси. Рассмотрим подробнее.
1) По этой классификации у нас бывает предумышленный техдолг с организационными причинами. Классическая история смены требований посередине проекта, появление новых ограничений и/или вброс фич от руководства сверху, внезапные бюджетные ограничения (мы не можем купить эту лицензию, поэтому выбирайте другой стек).
2) Если рассматривать предумышленный долг с техническими причинами, то, думаю, что он также знаком большинству команд. Мы где-то срезаем углы, принимаем на самые оптимальные решения, когда на нас давит бизнес и, соответственно, все надо сделать (слишком) быстро. Все хорошо знают, как оно бывает: руководители закоммитились под какие-то дедлайны или, того хуже, получили их сверху (например, лендинг или спецпроект под мероприятие).
3) Говоря о непредумышленный техническом долге с организационными причинами можно вспомнить, что все мы люди. Ошиблись в оценке, не разобрались в технологии, случился конфликт внутри команды, кто-то уволился посередине проекта или заболел.
4) И еще есть непредумышленный технический долг. Он случается, когда фичи делаются копипастом или с помощью нейросетей без ревью и понимания, что и зачем в коде делается. Иногда его причина – некомпетентность. Иногда – просто недостаток опыта или когнитивные искажения при проектировании.
Особняком стоит причина технического долга, о которой часто забывают — легаси. Оно неизбежно догоняет нас, когда поддержка старых систем прекращается. Например, у нас была долгосрочная стратегия по обновлению операционных систем на виртуальных серверах. Когда-то мы устанавливали Ubuntu 16 LTS, но сейчас уже 2025 год, и она устарела. Та же история с приложениями: появляются новые уязвимости, а наша версия уже снята с поддержки. Жизнь фронтенда вообще похожа на жизнь серийного должника, потому что Nodejs всё время обновляется, не успел переехать на прошлую мажорную версию, как уже две новых зарелизили.
Влияние на разработку
Мы работаем в самом большом финансовом маркетплейсе России и прекрасно знаем, что такое кредиты и проценты по ним (ха-ха-ха). Соответственно, для нас естественно сравнивать техдолги с займами.
Далее буду цитировать Анну Мелехову и её доклад с TechLead Conf 2021. Вот график, нарастающая кривая: первый спринт — техдолг небольшой, второй — чуть больше, и так далее, пока к пятому спринту он не начинает затмевать все новые фичи. В какой-то момент долг становится настолько критичным, что мешает нормальной разработке.
Если команда адекватно оценивает свои спринты и ведет бэклог, можно отслеживать, как растет число задач, которые «не влезли» в спринт. Если цифра постоянно увеличивается, это тревожный сигнал. В конце концов, команда либо сама организует технический спринт, чтобы разгрести накопившиеся проблемы, либо техдолг начнет сказываться на стабильности, скорости разработки и качестве продукта. И, например, невыплаченный осознанный техдолг начинает генерить неосознанный.
Со временем команда тратит на разработку фич времени всё меньше, а на борьбу со сложностью – всё больше. В итоге к какому-то моменту наступает коллапс: вместо того чтобы делать новые фичи, команда тратит только и разбирает старые проблем (то есть платит проценты без выплаты тела долга).
Product Owner в этот момент может искренне удивляться, почему разработка вдруг замедлилась. А причина проста — накопленный техдолг. Если его не учитывать и не планировать на него время, он все равно найдет способ забрать свое, но, конечно, в самый неудобный момент.
Последствия технического долга
Технический долг — это не просто абстрактная проблема, о которой говорят только разработчики. Он напрямую влияет на бизнес, продукт и пользователей. Если не решать эти проблемы в срок, со временем они накапливаются и превращаются в серьёзные препятствия. Опрос разработчиков на BrainHub.eu показал, насколько сильно технический долг влияет на их работу:
Еще раз пройдемся по основным последствиям технического долга, которые могут быть заметны для бизнес-заказчика.
Баги
Одна из самых очевидных проблем. Чем больше накопленного технического долга, тем сложнее и дороже поддерживать систему, и больше вероятность, что новые фичи сломают что-нибудь еще.
Увеличение стоимости разработки
Когда кодовая база перегружена устаревшими решениями, любое изменение требует больше времени и ресурсов. Разработчики вынуждены разбираться со старыми зависимостями, обходить костыли и поддерживать несовместимые версии библиотек. Скорость падает, а затраты растут.
Проблемы с безопасностью
Старый код — это не только про неудобство, но и про уязвимости. Устаревшие библиотеки и неподдерживаемые версии ПО создают ситуации, которыми могут воспользоваться злоумышленники. Если вовремя не обновлять систему, риски утечек данных и атак значительно увеличиваются. А это штрафы, плохой PR, потеря лояльности, а при самом плохом сценарии и ликвидация компании.
Плохой пользовательский опыт
Когда продукт работает медленно, нестабильно или с ошибками, пользователи это замечают. Особенно это критично для мобильных приложений — лаги, вылеты и долгие загрузки приводят к низким оценкам в сторах и оттоку аудитории. А также ведут к увеличению затрат на работу с плохим фидбеком.
Потеря мотивации команды
52% разработчиков признались, что технический долг снижает их мотивацию. Вместо создания новых фич и работы над улучшением продукта им приходится разбираться с устаревшими зависимостями, латать баги и бороться с последствиями плохих архитектурных решений. Постоянная работа в таком режиме быстро приводит к выгоранию, а демотивированная команда перестает приносить пользу бизнесу.
Таким образом, можно аргументированно утверждать, что технический долг — это не просто неприятная мелочь, а серьёзный фактор, влияющий на бизнес, разработку и пользователей. Если его игнорировать, последствия будут накапливаться, снижая качество продукта, увеличивая затраты и приводя к выгоранию команды. Решать эти проблемы нужно системно и вовремя, иначе однажды они могут просто остановить развитие компании.
Что делать?
Самые основные шаги, которые позволят разобраться с техдолгом и начать жить:
Идентификация и фиксация. Врага надо знать в лицо.
Оценка объёма. Дата-драйвен подходы требуют метрик и цифр.
Приоритизация. Кредиты с высокой ставкой гасите первыми.
«Выплата» технического долга. Just do it, bro.
Снова вернемся к опыту Анны Мелеховой и пройдемся по рекомендациям.
1/4 – Идентификация и фиксация технического долга
Первый шаг — это поиск технического долга. Он может скрываться в коде, зависимостях, процессах сборки и даже в устаревших инструментах. Один из эффективных способов его выявления — расследование инцидентов.
В нашей компании многие инциденты фиксируются и закрываются автоматически, но некоторые приходится разбирать вручную. В каждом случае можно найти корневую причину — от роста трафика до багов во фреймворке.
При этом важно не просто устранять инциденты, а разбираться, почему они произошли. Можно ли было предотвратить проблему на этапе тестирования? К примеру, стоило ли написать автотесты, который не позволили бы такого класса багу попасть в продакшн? Такие вопросы помогают не только фиксить ошибки, но и снижать уровень технического долга в будущем.
Если баги регулярно приводят к инцидентам, это признак проблем в архитектуре или качестве кода. Такой технический долг со временем накапливается и усложняет поддержку продукта.
Расследование инцидентов требует вовлечения людей, а это всегда дорого. Если разбором проблемы занимаются 5 специалистов по 2 часа, это уже 10 человеко-часов, потраченных на один инцидент. Чем больше таких случаев, тем больше времени команда тратит не на разработку, а на устранение последствий.
В качестве методики преодоления можно рассмотреть разные подходы: разработать способы решения инцидентов или внедрить инструменты, которые помогут предсказывать и предотвращать проблемы заранее – и найти больше единиц техдолга, которые могут вызвать похожие инциденты.
Каждый инцидент — это потеря денег. Если инцидент вызван багом, мы можем посчитать, сколько таких случаев произошло, и определить финансовые потери. Это позволяет оценить в деньгах каждый баг и, соответственно, “продать” его исправление бизнесу.
Один из самых недооцененных источников техдолга — комментарии в коде. Разработчики часто оставляют заметки FIXME или TODO, фиксируя проблемы, которые нужно решить позже. Просто подсчитав такие пометки в кодовой базе, можно получить базовую оценку накопленного долга.
Некоторые инструменты, такие как SonarQube, могут автоматически выявлять нарушения кодовых паттернов, недостаточное покрытие тестами, FIXME-заметки и другие потенциальные проблемы.
Версии компонентов тоже могут быть источником техдолга. Это особенно актуально для фронтенда, где новые версии NodeJS выходят несколько раз в год. По мере обновления экосистемы устаревшие версии становятся устаревшими, требуя обновления зависимостей. Тот самый “легаси” техдолг, который возникает сам по себе.
Если процессы CI/CD занимают слишком много времени, это тоже сигнал о техническом долге. Разумная скорость сборки и поставки важна для эффективного тестирования и быстрых релизов изменений. Это, кстати, тоже хороший способ “продавать” техдолг бизнесу. При 100 релизах в неделю экономия 6 минут на ожидании готовности к тесту превращается в 1,5 рабочего дня QA.
Анализ кодовой базы может также показать количество коммитов в файлах. Если какой-то файл сильно выделяется по количеству изменений – или где-то есть фрагмент кода, где постоянно возникают конфликты, то есть возможные проблемы с внутренней архитектурой приложения. В таком случае стоит подумать о декомпозиции и рефакторинге – и зафиксировать техдолг.
Как пример болезненной выплаты процентов по техдолгу можно вспомнить про dependency hell: одно обновление может потребовать цепочки других обновлений, что приводит к сбоям. В результате может оказаться, что нужно обновить сотни пакетов, а в процессе всплывают уязвимости, несовместимости и конфликты с пайплайнами.
2/4 – Оценка
Итак, с идентификацией разобрались, позже я еще расскажу про другие источники, но сейчас мы хотим оценить “инициденты техдолга” и посчитать, какой процент от общего числа они занимают. И, если еще не успели сделать это на предыдущем этапе, можно посчитать экономический эффект от каждого инцидента — сколько денег можно перестать терять?
Эта методика достаточно простая, но не всегда и не для всех инцидентов подходит.
Если на предыдущем этапе нашлись проблемы, которые еще не привели к инцидентам, то их приходится оценивать скорее интуитивно: не всегда можно точно подсчитать, сколько часов работы это сэкономит. Хотя и это тоже можно оценить по косвенным признакам – вроде оценки задач и количества тикетов, которые не влезают в спринт.
3/4 – Приоритезация
Когда я изучал тему, мне понравилась табличка от Ильи Царева из Яндекс Go (доклад “Как работать с техдолгом и техническими задачами в продуктовой команде” с того же TechLead Conf 2021), с помощью которой можно классифицировать инциденты. Это, по сути, модификация модели ICE. В этой таблице есть сложность инцидента и критерии, по которым мы его оцениваем.
Не буду спойлерить, как в реальности работает эта табличка, доклад хороший, стоит его посмотреть. Мы у себя, кстати, по похожей модели оцениваем большие фичи из бэклогов команд, чтобы понимать, что делать в первую очередь, а что оставить на потом.
Главное преимущество такого плана таблиц — это понятный и эффективный способ общения на одном языке с бизнесом. Можно “продать” выплату самых серьезных долгов, да и для себя понимать аргументированные приоритеты полезно.
4/4 – Выплата технического долга
Анна Мелехова собрала и рассмотрела почти все возможные стратегии выплаты техдолга. В каждой из них свои плюсы и минусы для компании и разработчиков.
Квота на техдолг
Одна из самых популярных стратегий, у нас уже много лет зафиксировано правило, что 20-25% времени команды может быть направлено на архитектурные задачи и выплату техдолга. Конечно, бизнес всегда стремится ужать эту квоту в пользу продуктовых задач, поэтому поэтому приходится иногда спорить, тут очень помогают рассмотренные выше методики оценки.
Выделенные люди
Можно выделить отдельную группу специалистов, которые будут заниматься только техдолгом. Мы в Банки.ру пробовали так делать – я сам начинал работать в команде оперативной разработки, которая как раз и должна была делать то, до чего у продуктовых команд не доходят руки. Неожиданно выявился педагогический минус. Одни люди создают техдолг, другие его выплачивают. В итоге у создающих нет мотивации писать “чистый” и поддерживаемый код, в итоге и продукт получается так себе. А еще это сильно влияет на атмосферу между командами, я рассказывал о собственной токсичности на секретном Fail Meetup’е во время Saint Highload в 22-м году.
Выделенный спринт
Как правило, невозможно согласовать с бизнесом технический спринт, пока ситуация не станет критической и баги не начнут прямо влиять на прибыль продукта – с перспективой его остановки. Это те самые внезапные “проценты” по долгам, которые возникают при системном игнорировании работы с техдолгом.
Подполье
Это когда команда опытных инженеров не хочет расстраивать Product Owner, поэтому немного завышает квоты на техдолг при оценке задач. Так, тихо и незаметно, они успевают забрать несколько задач в спринте на выплату техдолга или что-то пофиксить в рамках продуктовых.
Налог на фичу
Это когда на каждую новую фичу сознательно добавляют, например, плюс 2 сторипоинта или какую-то задачу на техдолг в нагрузку. Это похоже на "подполье", но честнее и прозрачнее, потому что менеджер знает, сколько стоит каждая фича.
Владелец техдолга
Артем Каличкин на конференции DevOpsConf 2020 поделился своим опытом касательно “продажи” техдолга. Ключевой элемент: у техдолга должен быть конкретный владелец.
Кроме того, у каждого программного компонента, сервиса или модуля в компании есть свой техлид компонент. Таким образом, для всего техдолга, связанный с конкретным компонентом, автоматически можно назначить владельца. Этот подход позволяет привнести элемент личной ответственности в управление техдолгом.
Опыт коллег говорит о том, что такой подход к управлению техдолгом оказывается достаточно успешным. Правда, порой бывает сложно найти хозяина техдолга, например, если у вас есть “сервисы-сироты”.
Применяем классификацию на конкретных примерах
Я экспериментировал с классификацией техдолга и попробовал применить это на конкретных примерах. В левой колонке — типы техдолга, сверху — последствия, на которые он влияет, и объекты, с которыми этот техдолг связан – а на пересечении примеры случившихся или потенциальных проблем, причин инцидентов, артефактов техдолга и поломанных метрик.
Отмечу, что в классификации из первой главы я изменил значение Design Debt. Для нашей структуры команд удобно проблемы с интерфейсами (не путать с проблемами логики продукта) считать “Дизайн-долгом”, а проблемы дизайном приложений отнести к “Архитектурным долгам”.
Итак, первым идут Docs debt.
Долгий онбординг сотрудников. Например, новенький получает доступ к репозиториям 40 сервисам и теряется. Разработчики могут хотя бы почитать код, а тестировщики, приходя, не знают, как тестировать, потому что нет тест-кейсов и четких инструкций.
Инциденты. При сбое начинается путаница: сервис не работает, звоним тимлиду, он говорит, что сервис в порядке, просто не работает что-то другое. В итоге, инцидент чиним 4 часа, за это время теряем несколько миллионов, хотя нормальная инструкция позволила бы решить его за 30 минут.
Продуктовые метрики. Новый менеджер не может разобраться, как работает продукт, и команда не всегда может объяснить, что происходит. А решения по изменениям принимаются “по ощущениям”, а не на основе данных.
Стратегические решения. «Белое пятно» в понимании нашего архитектурного ландшафта создаёт долгосрочные проблемы. Например, при принятии решений проще чего-то не учесть, если нет актуальной схемы “AS IS”, в итоге новый сервис не работает, вокруг него возникает забор из костылей, а вытаскивать их приходится годами.
Compliance.
Соответствие законам и стандартам – ГОСТы, федеральные законы или подзаконные акты. Например, недавние изменения в закон “О рекламе” обязали всех дописывать к рекламе erid и регистрировать договора в ОРД – и для многих компаний на рынке это было сложно, долго и дорого. Сразу и Design, и Security, и Developer Efficiencу Debts (DED).
По требованиям законов о Персональных данных базы продакшена нельзя просто так взять и выдать разработчикам для тестирования фич – тоже страдает Developer Efficiency, приходится строить пайплайны поставки структур данных, которые, в свою очередь, тянут за собой Maintenance Debt.
Пен-тесты и безопасность (Security Debt). Иногда проблемы возникают из-за автоматических пен-тестов, которые требуется периодически проводить по закону. Например, в Банки.ру был случай, когда сканер нашел незащищенную админку, “прокликал” все ссылки и удалил данные, которые потом восстанавливали из бекапа.
Design Debt
Непродуманный интерфейс не только влияет на работу поддержки, перегружая ее (Maintenance Debt), но и на атмосферу в команде. Потому что мы выгораем, разрабатывая продукт, который нам самим не нравится – привет, DED.
Архитектура
Когда возникают проблемы с архитектурой приложений или систем, например, неопределённые связи между сервисами, это затрудняет диагностику и решение инцидентов. Также могут быть скрытые угрозы безопасности, о которых мы не знаем. И, хотя архитектурные проблемы редко напрямую не влияют на продуктовые метрики, они всё равно сказываются на производительности и стабильности.
Инфраструктура
Нехватка ресурсов, например, места на базах данных или в системах логирования, также является техдолгом. Старые прошивки частенько содержат баги и уязвимости. А еще часто забывается, что в микросервисной архитектуре количество сервисов за пару лет может вырасти вдвое, а деньги на облако или серверы не заложены в бюджете. К тому же закупка оборудования в современных реалиях длится 3 месяца.
Идем дальше, категории техдолга еще не кончились. Если вы устали – прогуляйтесь, выпейте чашечку кофе :)
Код
Это, наверное, самая понятная категория. Код-стайл, уязвимости, юнит-тесты, ошибки на первой линии — разработчикам сложно разобраться в паттернах (“Джо, я паттернов проектирования в проекте не чувствую” – “Это потому что их там нет, муахахаха!”), добавление фичи требует длительного погружения в кодовую базу. На стабильность частенько влияют утечки памяти. Обычно продактам не важно, насколько быстро и стабильно работает приложение, хотя это это напрямую влияет на их метрики (если их собирать, конечно).
Дефекты – они же баги и ошибки
Печальная правда жизни — разработчики не любят чинить баги, им больше нравится работать над новыми фичами. Самая легко и быстро считаемая категория техдолгов. В первую очередь влетает в поддержку, потом влияет на стабильность. Мы торопимся, зарелизили новую фичу быстро, но сломали что-то важное в другом месте – в итоге пострадал продукт.
Тестирование
Плохо/мало/олдскульно тестируем – баги часто приходят от пользователей на первую линию, и сразу попадают разработчикам. Которые, в свою очередь, ждут тестирования по несколько дней, а потом релизят нестабильные фичи. Бывают фатальные отличия между стендами, когда проблемы в продакшене не всегда воспроизводятся на тестовых окружениях – специфический, но дорогой в решении долг.
И хорошо бы у QA хватало времени на изучение, воспроизведение и превращение в понятную задачу отчетов об уязвимостях, которые исправно рассылают департаменты ИБ.
Автоматизация
“У меня нет времени точить топор, нужно рубить лес”. Одна из моих любимых категорий техдолгов. Мы тестируем руками, потому что не хотим писать автотесты. Выкладываем руками, потому что не хотим настраивать CI/CD. При этом отсутствие автоматизации добавляет во все этапы продуктового ощутимую вероятность человеческой ошибки.
Эта категория хороша тем, что довольно легко считается. Например, когда количество отзывов персональных данных (оно же удаление учеток) начало создавать ощутимую нагрузку на поддержку, мы полность автоматизировали этот процесс – и сейчас экономим более 2 миллионов человеко-минут в год. При этом снизили вероятность ошибок, улучшили метрики по продукту и закрыли Compliance Debt.
Люди
И я отношу к этой категории устаревшие технологии. Когда теряется экспертиза – или бас-фактор равен единице – это тоже разновидность техдолга. Влияет на стабильность, на стратегические решения и даже на безопасность. Бывает, что не запланировали найм сотрудников, и в итоге некому выполнять часть работы или поддерживать сервисы. Или приходится поддерживать чужие, сильно теряя в мотивации и эффективности команды. В итоге “долг недостатка людей” в качестве процентов может нагенерить очень много легаси в сервисах, которые долго не обновлялись, в свою очередь мешая нанимать новых людей – порочный круг.
Еще раз, как делать-то?
Надеюсь, с примерами стало понятнее, как именно работает сетка классификации, теперь хочу рассказать о том, как мы (и вы) можете выявить и измерить объем долгов, и как его правильно выплачивать.
Документация
У нас есть 1-2-я линии поддержки, от которых можно собрать фидбек о том, чего им не хватает. Мы можем либо автоматизировать какие-то операции (как в примере выше с удалением профилей), либо задокументировать их. Для API-сервисов существуют утилиты вроде Swagger, которые снимают вопрос с документацией. Чтобы всё было в одном месте, мы создали у себя “Реестр сервисов”, который также выступает неким “Техрадаром”. Организовать такое можно даже в простой табличке, и это уже сильно помогает в большинстве случаев.
Compliance
Сложная категория, потому что обычно такие долги выявляются аудитом. Аудит выдает задачи на исправление, которые затем нужно оценить и запланировать – и не дать им умереть в бэклогах. С пентестами аналогично: находим уязвимости, заводим задачи по исправлению, а затем начинаем их решать по плану.
Дизайн
У нас есть различные метрики, например, page metrics, которая показывает, как быстро или медленно работает система – и показать, не возникло ли каких-то проблем в клиентских интерфейсах.
Архитектура
Как правило, здесь требуется анализ инцидентов и внутренний аудит. Например, микросервисы могут общаться между собой не напрямую, а через третий балансировщик, который ставился “временно, для переключения трафика”, и так и остался. Для выявления таких проблем также можно использовать инструменты Observability вроде Coroot или Jaeger, которые позволяют отслеживать и оптимизировать взаимодействие сервисов.
Железо
Основной инструмент – мониторинг. Если утилизация гипервизоров (дисков, сети) превышает 70%, нужно бить тревогу. И, понятное дело, проводить регулярный аудит использования выделенных командам сред и окружений
Код
По коду есть несколько важных моментов. У нас есть инструменты статического анализа, и важное правило — соблюдать стандарты. Нужно следить за объемом методов и классов, что, например, SonarQube может подсветить. Эти инструменты работают в пулл-реквестах в Git, плюс в некоторых местах мы используем Trivy, который показывает возможные проблемы. Также наш “Реестр сервисов” помогает отслеживать устаревшие библиотеки. Ну, а юнит-тесты и % покрытия позволяет контролировать “здоровье” кодовой базы.
Дефекты
Тут в первую очередь анализ запросов с первой линии и инцидентов. А еще хорошая метрика – error rate, например, в Sentry. Если какой-то сервис генерирует 30% ошибок на продакшене, это явный сигнал, что есть “горящий” техдолг, может, даже сразу устроить технический спринт.
Тестирование
Мы используем SonarQube – метрика Code Coverage помогает следить за юнитами по сервисам. Также есть ТестОпс, которые позволяет понимать проникновение автотестов и долю ручных. Также мы выгружаем на дашборды метрики из таск-трекера по “времени в статусе”, чтобы смотреть, в каких командах, например, задача слишком долго висит в “готово к тесту”.
Люди
С людьм, как всегда, всё сложно. Мы строим звездные карты, проводим “оценки 360”, чтобы понять, кто в чем разбирается. Также в “Реестре сервисов” по каждому сервису выставляется “админ и хозяин” – и пустые поля выносятся в отдельный “сиротский” отчет, визуализируя техдолг.
Работа с техдолгом в Банки.ру
Выше я уже привел довольно много примеров по работе с техдолгом из жизни нашего Техотдела. Добавлю еще немного деталей.
Идентификация и фиксация
Мы расследуем инциденты, мониторим логи, заводим задачи по алертам и даже написали специальный сервис для учета инцидентов – чтобы ничто не прошло мимо. Правда, не всегда по итогам инцидента появляется проблема, и не всегда доходят руки до тех проблем, что уже есть.
Также используется SonarQube (статический анализ кода), пока в рекомендательном ключе, зато более чем в 95% сервисов.
Всё найденное должно быть зафиксировано в виде тикетов. Для этого мы используем лейблы: "техдолг" и "technical debt". Пока что не все команды используют, но мы активно работаем над тем, чтобы это стало корпоративным стандартом.
Оценка
Задачи-долги мы группируем по эпикам. Либо это эпик по продукту и/или результатам аудита, либо по какому-то классу проблем (вроде кривого взаимодействия сервисов между собой, которое мы выявили при помощи Coroot). И вот уже эпики мы оцениваем по ICE-подобной системе, приоритезируем и пушим в команды.
Выплата
Мы активно работаем с техдолгом, но делаем это по-разному. В частности, то самое соблюдение квоты на 20% иногда “откладывается на следующий спринт”. Зато мы научились автоматически делать задачи по некоторым категориям “легаси” долгов – например, обновлять зависимости в сервисах в один клик + столько кликов сколько у нас сервисов (что гораздо быстрее, чем вручную).
Иногда, правда, мы объявляем частичный “дефолт” по долгам – переписываем какой-то слишком “задолжавший” сервис заново на другом стеке технологий.
Вывод
Техдолг — это неизбежная часть разработки, результат постоянного поиска компромисса в процессе обмена времени на деньги и обратно. Он влияет на стабильность и безопасность, но, если с ним работать правильно, можно минимизировать риски и повысить производительность. Круто, что есть возможность обменяться опытом и поучиться на чужих ошибках, надеюсь, и наш опыт будет вам полезен.
В Банки.ру мы выстроили неплохой конвейер по работе с техдолгом, обучаем и воспитываем команды, подталкивая их к более зрелому подходу. Несмотря на сложности, такие шаги помогают лучше контролировать ситуацию держать “проценты” на здоровом уровне.
В комментариях к статье интересно было бы прочитать, как обстоят дела в вашей компании и какие варианты вы видите наиболее эффективными.
