Техподдержка бывает разная. Где-то это «попробуйте перезагрузить» или «проверьте провод», а где-то — сложные инженерные задачи, которым не жалко посвятить хоть всю жизнь. Какой вариант в поддержке Postgres Professional и кого/чего больше в этой сфере — людей или технологий, — разбираемся со старшим инженером технической поддержки Postgres Professional Камилем Каримовым.

Техническая поддержка нашла меня сама

Поработав несколько лет в направлении Х, я понял, что мне не хватает развития, и захотел освоить PostgreSQL. Цели попасть в техническую поддержку у меня не было: я просто искал что-то связанное с этой СУБД. Более того, как и многие, я представлял работу в техподдержке как простые отписки вроде «нажмите», «перезагрузите» и пр. 

Тогда я увидел вакансию младшего инженера технической поддержки в Postgres Professional. Среди задач были консультации по PostgreSQL и Postgres Pro, решение проблем при эксплуатации СУБД и выполнение технических работ.

Мне это показалось интересным. И главное — я понимал, что это поможет мне погрузиться в PostgreSQL, с которой я на тот момент никогда не работал (да, так можно было).

Чем занимается инженер технической поддержки 

Бо́льшая часть работы в нашей поддержке — это настоящие инженерные задачи. К нам обращаются с вопросами от установки пакетов до «почему-то приложение падает, похоже на data corruption».

Сначала всегда нужно собрать диагностику, определить, в чём проблема и в какой системе она возникает. 

Выбор инструмента зависит от кейса. Если что-то с производительностью или процесс застрял, подойдёт GDB или perf. Иногда помогает сбор системных представлений в самом Postgres. 

Из инструментов Postgres Professional мы пользуемся pgpro_stats в связке с pgpro_pwr. Например, с его помощью можно сформировать отчёт за период, в котором произошёл инцидент, а потом детально сравнивать полученные данные с эталонной нагрузкой, когда всё работало. 

Главное — глубоко знать продукт: этого может быть достаточно, чтобы локализовать область исследования.

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

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

Мы работаем с заявками через специальный портал. Это гораздо удобнее, чем, например, с почтой, где сложно следить за статусами и заявки могут просто теряться. 

Кейс на 6 ТБ

У клиента не выполнялся стандартный чек-пойнт — обслуживающий процесс. За 4 часа размер директории pg_wal вырос до 6ТБ, и она заняла всё свободное дисковое пространство.

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

При анализе кода мы обнаружили, что определённый код начинает выполняться при включении параметра archive_timeout. Это был неочевидный кейс, так как мы всегда предполагали, что archive_timeout не выполняется без включённого основного параметра archive_mode. Отключили параметр и решили проблему. Было интересно такое раскопать.

Кто к нам обращается

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

Идеальный клиент поддержки: 

• детально описывает проблему;

• делится хронологией событий, которые предшествовали проблеме;

• прикладывает необходимую диагностику, в идеальном случае — воспроизводимый кейс.

Но бывает и не так. Иногда к нам обращаются студенты, они просят помочь с курсовыми и дипломными. Этим мы не занимаемся: отвечаем, что всегда лучше разобраться самому и чему-то научиться в процессе. 

Ещё бывает, что клиент просит рассудить спор разработчика с администратором баз данных. Допустим, прикладной разработчик подозревает проблему в неправильной работе VACUUM, а админ считает, что команда «процедура» выполняется штатно. С таким обязательно поможем.

Некоторые фразы сразу настораживают. Например, «мы посмотрели в интернете и сделали, но не помогло». Обычно это означает, что стало ещё хуже.

Какие знания нужны в техподдержке Postgres Professional

В нашей работе одинаково важны и хардскилы, и софтскилы. 

Главное с технической стороны:

• знать СУБД Postgres Pro: её архитектуру, особенности, фичи и экосистему;

• разбираться в операционных системах, уметь их администрировать и траблшутить;

• разбираться в сетях и иметь представление о серверах; 

• иметь навыки программирования или хотя бы чтения кода.

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

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

Как развиваться в техподдержке и за её пределами

Всё зависит от компании. Мне кажется, в нашей техподдержке можно развиваться бесконечно. Каждый релиз — это новые функции, кейсы, баги, которые заставляют тебя постоянно исследовать кодовую базу PostgreSQL и совершенствоваться.

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

Всем, кому интересна эта сфера, рекомендую книгу Брендана Грегга «Производительность систем». Там хорошо описаны случаи вроде «у нас ничего не работает, помогите». А для прокачки в Postgres полезно слушать доклады с конференций, например PGConf.Russia, и читать любые материалы по теме на Хабре. 

Техподдержка будущего — это…

Всё более сложные кейсы — потому что становится больше фич и уровней абстракции. Такую динамику я вижу и за последние три года.

В несложных рутинных задачах вырастет доля ИИ. Сейчас я использую его как более умный поисковик, а также для формирования DDL. 

Мудрость опытного инженера 

• Если с утра прилетает задача первого приоритета, то день будет весёлый.

• Пятница — день заявок: клиенты всю неделю боролись с проблемами сами, и всё, с чем не справились, в пятницу торжественно несут нам. 

• Не стройте больших планов на вечер пятницы: клиенты это чувствуют и обязательно придут с задачей. Работает и в обратную сторону.

• Старайтесь отвлекаться: можно заняться личными делами, пройтись, сходить на тренировку. Без отдыха не будет продуктивной работы.

• Если вы только пришли в поддержку, беритесь за любые задачи, это самый быстрый способ прокачать навыки.