Почему я пишу инструменты для поддержки сам

Половина работы в поддержке — это одни и те же действия, повторённые в сотый раз. В какой-то момент дешевле потратить выходные и написать инструмент, чем продолжать.

Правило, к которому я пришёл: если действие повторяется еженедельно и занимает больше десяти минут — оно стоит автоматизации. Ниже — две задачи, прошедшие этот порог.

Задача первая: собрать диагностику у пользователя

Пользователь говорит «кнопка не работает». Чтобы это разобрать, нужны консоль, сетевые запросы и последовательность действий.

Как это выглядело раньше:

Объяснить, как открыть DevTools. По телефону. Человеку, который про них не слышал.
Объяснить, где вкладка Console и как сделать скриншот.
Объяснить, что такое вкладка Network и как сохранить HAR.
Получить HAR и обнаружить в нём куки и токены авторизации.
Не иметь права приложить такой файл к тикету.

Пятый пункт — главный. HAR-файл содержит всё: заголовки, куки, тела запросов и ответов. Это готовая сессия пользователя, которую можно переиспользовать.

Отсюда BugCapture — расширение, которое делает три вещи:

записывает происходящее по нажатию одной кнопки: консоль, сеть, действия;
вырезает чувствительное до выгрузки — заголовки Authorization и Cookie, поля с токенами и паролями в телах запросов;
отдаёт один файл, который можно приложить к тикету не задумываясь.

Ключевое здесь — второй пункт. Не «собрать диагностику», а «собрать диагностику, которую безопасно передавать». Первое умеет и сам браузер.

Инструкция для пользователя сократилась до одной строки: «нажми на иконку, воспроизведи проблему, нажми ещё раз, пришли файл».

Задача вторая: секреты в REST-клиенте

Вторая история — про то, как проверяют API.

Проверка запроса требует токена. Токен попадает в коллекцию запросов. Коллекция сохраняется в файл. Файл коммитится в репозиторий.

Дальше варианты: либо токен уезжает в git и живёт там в истории вечно, либо коллекция не коммитится вообще и существует у каждого своя.

Оба варианта плохие. Первый — утечка, второй — «а у меня работает».

Отсюда ReqVault с простым разделением:

Что	Где лежит	Коммитится
Запросы, эндпоинты, заголовки, тела	Файлы на диске, открытый текст	Да
Токены, пароли, ключи	Системное хранилище ключей ОС	Нет, физически не может

Коллекция ссылается на секрет по имени, а не по значению. В файле лежит {{api_token}}, само значение — в keychain операционной системы.

Локальный, потому что REST-клиент, отправляющий рабочие запросы через чужое облако, — это ровно та проблема, от которой я и уходил.

Где граница

Не всё стоит писать самому. Мои критерии:

Стоит писать, когда:

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

Не стоит, когда:

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

Последний пункт недооценивают. Инструмент — это обязательство. Через год ты либо будешь его чинить, либо объяснять коллегам, почему он больше не работает.

Побочный эффект

Неожиданное следствие: написав инструмент, начинаешь лучше понимать саму задачу.

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

Это не главная причина писать инструменты, но приятная.

Что дальше

Обе штуки открыты, лежат на GitHub, лицензии свободные. Если решают твою задачу — бери. Если решают её не так, как надо тебе — форкай, там немного кода.