Какие шаги предпринять при общении с пользователем для решения технической задачи
Что проверяют
Умеете ли вы превратить жалобу «ничего не работает» в понятную задачу и держать человека в курсе, пока её решаете. В DevOps пользователь чаще всего разработчик или соседняя команда, и интервьюер проверяет, не уходите ли вы чинить молча. Следом часто просят пример, когда проблема оказалась не там, где на неё жаловались.
Как отвечать
Рабочий порядок:
- собрать факты: что именно не работает, с какого момента, у всех или у одного, точный текст ошибки, ссылка на упавший пайплайн, коммит, namespace, время с часовым поясом;
- спросить, что менялось: новый деплой, обновление зависимостей, смена прав доступа;
- оценить влияние: блокирует ли это релиз или одного разработчика, от этого зависит приоритет;
- договориться об ожиданиях: кто занимается и когда будет следующее обновление, даже если решения ещё нет;
- проверить по данным: логи в Loki или ELK, метрики в Grafana, события Kubernetes, а не только слова пользователя;
- предложить обходной путь: если починка долгая, дать временное решение вроде перезапуска на другом раннере или временного доступа;
- закрыть с подтверждением: пользователь проверил, что всё работает, причина записана в тикете, а повторяющийся случай превращён в инструкцию или автоматизацию.
Отвечать лучше историей из своего опыта по этому каркасу: какой был запрос, где нашлась реальная причина, сколько времени ушло. Детали и цифры нужны свои. Если опыта поддержки не было, опишите, как помогали коллеге с упавшей сборкой или доступом, это тот же навык.
Где спотыкаются
Бросаются чинить по первой фразе пользователя и тратят час не на ту проблему.
Пропадают на время работы. Для пользователя тишина выглядит как игнор, даже если вы уже нашли причину.
Закрывают тикет без подтверждения и без записи причины, и через неделю тот же вопрос приходит снова.