Есть особый вид спокойствия, который появляется у владельца бизнеса после нескольких лет работы с сайтом. Ты просто знаешь, что лучше ничего не трогать вечером в пятницу. Не потому, что есть какое-то официальное правило, а потому, что однажды уже было. После безобидного обновления перестала работать форма, потом кто-то два часа искал причину, а в понедельник выяснилось, что человек, который знает эту часть системы, как раз уехал за город.
Такие истории редко случаются из-за одного большого провала. Обычно всё происходит гораздо тише. Устаревает библиотека. Скапливаются технические мелочи. Кто-то перестаёт обновлять сервер. Мониторинг настроен давно и уже почти никому не интересен. Резервные копии создаются, но восстановление из них никто не пробовал. Сайт продолжает работать, поэтому проблема откладывается ещё на месяц.
А потом появляется настоящий сбой.
И в этот момент бизнесу нужен не просто человек, который умеет писать код. Нужен тот, кто уже знает систему, понимает, где искать причину, имеет доступы и может спокойно заняться проблемой вместо того, чтобы сначала полдня восстанавливать историю проекта.
В этом и заключается нормальная техническая поддержка. Не сидеть рядом на случай, если вдруг что-то случится, а постоянно держать продукт в состоянии, в котором его не страшно эксплуатировать и развивать.
С чего начинаем
На старте мы разбираемся с тем, что уже есть. Если проект делали не мы, это нормально. Смотрим код, инфраструктуру, зависимости, мониторинг и резервные копии, выясняем, где наиболее вероятны проблемы. Иногда уже на этом этапе обнаруживается что-нибудь вроде старой версии сервера, которая держит важную часть проекта, или резервной копии, которая формально создаётся, но ни разу не проходила проверку восстановлением.
После этого появляется регламент. Что считаем критическим инцидентом, кто его получает, как быстро нужно отреагировать, что происходит дальше. Эти вещи фиксируются заранее, чтобы во время проблемы не пришлось обсуждать в общем чате, кто сегодня дежурит.
Мониторинг смотрит за тем, что трудно контролировать человеку постоянно. Доступность, ошибки, время ответа, состояние инфраструктуры, фоновые задачи. Prometheus и Grafana помогают видеть картину, а Sentry — конкретные ошибки приложения. Когда всё настроено нормально, первый сигнал приходит не от клиента со словами «у вас опять что-то не работает», а от самой системы.
После инцидента
Но мониторинг — только половина истории. Вторая половина начинается после инцидента. Если сервер пришлось перезапустить, это ещё не означает, что проблема решена. Нужно разобраться, почему он упал, можно ли было заметить это раньше и что изменить, чтобы ситуация не повторилась.
Иногда причина оказывается совершенно банальной. Например, какой-нибудь процесс медленно съедал память несколько недель. Пользователь этого почти не замечал, пока однажды вечером сервис не начал отдавать ошибки. Исправить конкретную проблему обычно несложно. Гораздо полезнее сделать так, чтобы в следующий раз система заметила её сама.
Продукт продолжает жить
Параллельно с эксплуатацией должна продолжаться обычная жизнь продукта. Появляются новые функции, меняется каталог, подключаются новые способы оплаты, маркетинг просит новый сценарий, а бизнес внезапно хочет то, чего никто не планировал три месяца назад. Поддержка не должна означать, что разработка остановилась и команда теперь только чинит аварии.
Поэтому часть работы мы оставляем на развитие. Не обязательно брать бесконечный backlog и пытаться выполнить всё сразу. Обычно разумнее иметь понятный список задач и регулярно выбирать из него то, что действительно сейчас нужно бизнесу.
Есть и менее заметная часть работы, о которой вспоминают редко, пока она не становится проблемой. Обновление зависимостей, настройка серверов, проверка сертификатов, обслуживание базы, резервное копирование, контроль доступа. Именно такие задачи обычно откладываются дольше всего, потому что «сейчас же всё работает».
Именно поэтому у поддержки есть ценность даже в спокойные месяцы. Хорошая система не обязана каждую неделю устраивать драму, чтобы оправдать своё существование. Иногда лучший месяц — тот, в котором ничего серьёзного не произошло, зависимости обновились, резервная копия восстановилась на тестовом стенде, а команда спокойно выпустила несколько новых функций.
Про сроки и ожидания
Срок реакции мы фиксируем в SLA. Это важно не потому, что кому-то нравится слово SLA, а потому, что обе стороны заранее понимают, чего ожидать в плохой день. При этом мы не обещаем невозможного: даже хорошо поддерживаемый продукт иногда ломается. Можно обещать внимание, понятный процесс и конкретную реакцию, но не вечную безотказность.
Со временем самое заметное изменение происходит даже не в графиках. Владелец просто перестаёт думать о том, кто сейчас посмотрит сайт, если что-нибудь случится. У команды появляется понятный способ выпускать изменения, у проекта — история и документация, а у бизнеса — люди, которым можно написать, когда действительно возникла проблема.
В этом, пожалуй, и состоит хорошая поддержка: не быть героем, который каждый месяц спасает проект, а сделать так, чтобы спасать его приходилось как можно реже.