Когда-то я был обычным разработчиком в одной небольшой компании, и поддержка пользователей была одной из моих постоянных болей. Большинство обращений разбирала служба поддержки. Если самостоятельно решить проблему не получалось и требовалось понимание устройства системы, тикет приходил разработчикам. На словах всё звучало вполне логично: сложные технические проблемы должны разбирать люди, которые хорошо знают систему. Кроме того, участие в поддержке помогало новым разработчикам лучше понимать продукт.
На практике разработчики довольно быстро начали вручную исправлять некорректные состояния данных и выполнять операции, которых не хватало во внутренних инструментах. Они разбирали инциденты, искали причины проблем по логам и писали на скорую руку небольшие внутренние скрипты. Иногда это действительно была разработческая задача, но довольно часто разработчик просто становился очень дорогой админкой.
«Поправь клиенту данные СРОЧНО, он простаивает»
Типичный тикет мог выглядеть примерно так:
У клиента неправильное состояние аккаунта. Нужно поправить. Приоритет.
Дальше разработчик разбирается в состоянии данных и вручную выполняет необходимые изменения. Проблема решена, клиент доволен, тикет закрыт. На первый взгляд всё хорошо. Но если одно и то же действие приходится регулярно выполнять вручную, это уже не исключительная ситуация, а часть бизнес-процесса, для которой не сделали нормальный инструмент.
Особенно опасно, когда такие операции выполняются напрямую в production. Постепенно ручные операции становятся обычным способом решать проблемы, но в отличие от нормального внутреннего инструмента здесь гораздо проще ошибиться. Проверка корректности часто сводится к одной мысли:
Я вроде всё перепроверил, должно быть нормально.
Поддержка постепенно съедает разработку
Главная проблема для меня была даже не в самих тикетах, а в количестве переключений. Ты занимаешься своей задачей, погрузился в код и держишь в голове контекст. Приходит тикет — нужно посмотреть. Изучаешь логи и состояние системы, читаешь чужой код и восстанавливаешь историю проблемы. После решения тикет возвращается в поддержку. Если клиенту помогло, он к тебе больше не приходит, но иногда начинался настоящий пинг-понг между клиентом, поддержкой и разработчиком.
Возвращаешься к своей задаче и заново вспоминаешь, чем вообще занимался. Если таких обращений несколько за день, нормальной разработки почти не остаётся. В какие-то периоды на поддержку уходила заметная часть рабочей недели: время разработчика тратилось не на развитие продукта, а на ручное обслуживание уже существующей системы. Особенно жарко становилось во время отпусков. Если процессы поддержки хорошо знало лишь несколько человек и один из них уходил отдыхать, нагрузка на остальных резко возрастала. Если одновременно происходил какой-нибудь инцидент, рабочий день очень быстро превращался в бесконечный поток:
тикет → разбор проблемы → решение → тикет → инцидент → снова разбор.
И в этот момент становится заметна ещё одна проблема: знания о поддержке часто находятся не в системе, а в головах конкретных разработчиков. Чтобы поддерживать внутреннюю документацию актуальной, нужна дисциплина, а она обновлялась не всегда вовремя. Выполняешь действие из документа, но увы, клиенту это не помогает, а иногда делает только хуже.
Такая работа очень быстро выматывает
От такой работы устаёшь не только потому, что задач становится больше. Сильнее выматывает постоянное напряжение. Когда ты работаешь с production вручную, практически каждое действие приходится перепроверять: тот ли клиент, правильно ли я понял состояние данных, не навредит ли изменение другим.
В обычной разработке ошибка чаще всего заканчивается упавшим тестом, неудачным code review или багом, который ещё можно поймать до production. При ручной работе ошибка может сразу затронуть реального клиента. Иногда достаточно одного неправильного действия. Из-за этого даже простая операция начинает требовать повышенной концентрации. Когда таких операций много, ты постепенно начинаешь нервничать даже перед привычными действиями, особенно после того, как однажды уже ошибся.
Вместо:
Сейчас быстро поправлю данные.
в голове уже появляется:
А точно я ничего сейчас не сломаю?
Постоянно работать в таком режиме тяжело. Ты одновременно пишешь продуктовый код, отвечаешь на тикеты, разбираешь инциденты, работаешь с production и понимаешь, что одна невнимательность может создать новую проблему вместо решения старой. Усталость накапливается, а если человек при этом ещё отвечает за команду, помогает другим разработчикам и остаётся главным экспертом по сложным тикетам, нагрузка становится ещё выше. В какой-то момент это уже не просто «много работы», а прямой путь к выгоранию.
Иногда тикетов прилетало столько, что хотелось, как в фильме «Брюс Всемогущий», просто ответить всем «да» и закрыть их. Более того, я чувствовал, что не делаю ничего полезного и не развиваюсь: моя работа сводилась к просмотру логов и поиску причин, а если разобраться не получалось — к просьбам о помощи у более опытных коллег. Я же хотел развиваться в архитектуре приложений, а не тратить столько времени на поддержку.
Мой самый неприятный фейл
Это было много лет назад. Я только начал регулярно подключаться к поддержке и ещё не успел хорошо разобраться в проекте. Однажды мне нужно было удалить неактуальный аккаунт клиента. Такие операции мы тоже выполняли вручную.
Параллельно шло несколько обращений, меня отвлекли, а когда я вернулся к исходной задаче, то ошибся с контекстом операции. Вместо того чтобы выполнить операцию там, где планировал, я удалил не тот клиентский аккаунт. Практически сразу я понял, что что-то не так, но было уже поздно.
Дальше началась гораздо более интересная часть рабочего дня — восстановление. Нужно было понять масштаб изменений, вернуть данные и проверить связанные сущности. С такой проблемой я столкнулся впервые и продолжал седеть на глазах, но в итоге аккаунт удалось восстановить. Это была весёлая пятница, а тот, кто меня менторил, оставался абсолютно спокоен, как будто ничего необычного не произошло. Проблема была не только в моей ошибке: сам процесс позволял одной человеческой ошибке превратить обычный тикет поддержки в полноценный инцидент.
«Будь внимательнее» — плохое решение
После подобных историй самое простое решение звучит так:
Нужно просто внимательнее работать с production.
Можно добавить ещё правила, наподобие:
Перед потенциально опасным действием ещё раз проверь объект и последствия операции.
Всё это полезно, но человек всё равно может ошибиться — особенно когда параллельно разбирает несколько тикетов, переключается между окружениями, устал или выполнял похожую операцию уже десятки раз. Спешка тоже мешает: разработчик понимает, что проблема блокирует работу клиента, и хочет помочь как можно быстрее. Требовать от человека бесконечной внимательности бесполезно. Безопаснее должна становиться сама операция.
Что стоило сделать вместо ручного удаления
В случае с клиентскими аккаунтами решение довольно простое. Не нужно было оставлять потенциально опасную операцию полностью ручной. Нужен был безопасный административный интерфейс.
Например:
сотрудник находит аккаунт;
нажимает «Архивировать»;
система показывает, что именно произойдёт;
операция логируется;
аккаунт сначала переводится в архив;
существует возможность восстановления;
окончательное удаление происходит позже.
К этому можно добавить подтверждение, права доступа, аудит и отложенное удаление. Тогда ошибка:
Я удалил не того клиента.
превращается в:
Я случайно архивировал не того клиента и через минуту восстановил его обратно.
Это совершенно разные классы проблем: в первом случае начинается инцидент, а во втором штатный механизм позволяет быстро отменить ошибочное действие.
Админка была. Но этого оказалось недостаточно
Важно уточнить: админка у нас была. Проблема заключалась в другом — в ней не хватало многих регулярно требовавшихся операций. Часть действий можно было сделать через интерфейс, а остальные по-прежнему требовали ручного вмешательства разработчика. Причём админка развивалась не так быстро, как появлялись новые сценарии поддержки.
Иногда мы начинали её активно улучшать: добавляли новые возможности, убирали часть ручных операций. Потом внимание переключалось на продуктовые задачи, процесс постепенно затихал. Через какое-то время количество ручной работы снова накапливалось, и кто-нибудь вспоминал:
А давайте всё-таки улучшим админку.
Мы снова что-то делали, потом процесс опять останавливался — и так по кругу. На мой взгляд, в этом и была одна из ключевых ошибок: инструменты поддержки нельзя один раз сделать и считать задачу закрытой. Продукт меняется → появляются новые фичи → меняются данные → возникают новые проблемы → поддержке приходится адаптироваться. Внутренние инструменты стареют быстрее, чем кажется, и разработчики снова начинают компенсировать недостающий функционал руками.
Поддержку нужно постоянно переосмысливать
Я бы сейчас относился к участию разработчиков в поддержке как к отдельному процессу, который нужно регулярно улучшать. Недостаточно просто разбирать тикеты — необходимо понимать, какие обращения повторяются чаще всего, какие операции всё ещё выполняются руками и почему в них вообще требуется разработчик. Нужно искать задачи, которые можно передать поддержке или автоматизировать, и замечать недостающие возможности админки.
Отдельного внимания требуют опасные операции, постоянный поиск одних и тех же данных и знания, которые существуют только в головах отдельных людей. Такой анализ показывает не только текущие проблемы, но и точки, в которых систему можно сделать устойчивее. Поэтому задача разработчиков — не только решить текущий тикет. Нужно ещё спросить:
Что сделать, чтобы следующий такой тикет разбирался быстрее или вообще не дошёл до разработчика?
У внутренних инструментов тоже должен быть ресурс
Есть ещё одна проблема, которую легко недооценить. Все понимают, зачем бизнесу нужны разработчики для создания новых продуктовых возможностей. Гораздо сложнее объяснить, зачем тратить ресурсы на улучшение инструментов поддержки и автоматизацию внутренних процессов.
Со стороны бизнеса это может выглядеть примерно так:
Админка уже есть. Зачем нам ещё один разработчик?
Но наличие админки ещё не означает, что она решает реальные проблемы поддержки. Если команда регулярно тратит значительную часть времени на ручные операции, это время уже оплачивается бизнесом. Вместо разработки нормальных инструментов бизнес платит за постоянное ручное выполнение одной и той же работы. Здесь появляется отдельная управленческая задача: стоимость текущего процесса нужно показать бизнесу в цифрах и объяснить, почему внутренним инструментам тоже нужна разработка.
Иногда для этого достаточно выделить часть времени существующей команды, но если продукт большой, количество обращений растёт, а админка сама становится отдельным продуктом, может понадобиться дополнительный разработчик или даже отдельная команда со своим аналитиком и QA.
Важно не допустить ситуации, когда один человек одновременно отвечает за продуктовый функционал, развивает админку, разбирает обращения пользователей, тушит инциденты, помогает другим разработчикам и при этом ещё управляет командой. На бумаге кажется, что у него просто много зон ответственности, а на практике это несколько параллельных работ, каждая из которых требует внимания и считается срочной.
Какое-то время это может работать, особенно если проект небольшой, — обычно за счёт того, что человек начинает компенсировать нехватку ресурсов собственным временем и нервами. Но это плохая долгосрочная стратегия. Если устойчивость процесса зависит от того, насколько долго один человек сможет жить в постоянном напряжении, процесс уже сломан.
Задача здесь не в том, чтобы самостоятельно закрывать все дыры, а в том, чтобы сделать проблему видимой. Для этого нужно измерить время команды на поддержку и понять, сколько продуктовой разработки из-за неё теряется. Стоит отдельно учитывать повторяющиеся операции, риски ручной работы, зависимость от отдельных людей и количество специалистов, которое действительно требуется для нормальной работы процесса.
Разработчик должен разрабатывать
Подключать разработчиков к сложным проблемам пользователей нормально, но когда ручное обслуживание production начинает регулярно занимать заметную часть рабочей недели, это уже проблема. Это не бесплатная работа. Каждый её час — время, когда продукт не развивается, технический долг не уменьшается, а инструменты, которые могли бы убрать эти же тикеты в будущем, не создаются. Более того, разработчик ощущает себя героем фильма «День сурка»: каждое дежурство происходит одно и то же.
Возникает неприятный замкнутый круг: у разработчиков много поддержки → нет времени автоматизировать поддержку → поддержка остаётся ручной → тикетов становится больше → у разработчиков ещё меньше времени. Сложные тикеты постепенно концентрируются у самых опытных разработчиков. Если менее опытный человек не может разобраться с проблемой, она всё равно возвращается к тем же нескольким специалистам. В итоге они одновременно делают свою работу и помогают закрывать то, с чем не справились остальные.
Постоянное ощущение, что одно неправильное действие может создать серьёзную проблему, только ускоряет накопление усталости. Это уже не признак незаменимости сотрудника, а признак того, что система слишком сильно от него зависит: зависимость от отдельных людей растёт, а bus factor команды снижается. Один из способов разорвать этот цикл — смотреть на поддержку не только как на поток отдельных проблем, но и как на источник информации о том, чего не хватает системе и внутренним инструментам.
Если разработчик один раз вручную исправил данные, возможно, это исключение. Если он сделал это десять раз, нужен инструмент. Если каждую неделю разработчику приходится вручную выполнять рискованные операции с production, проблема уже точно не в отдельных тикетах. Проблема в процессе, который сделал ручную и рискованную работу нормой.
Оригинал статьи опубликован в Telegram-канале @tsymbaldev.
