Эту статью я решил написать после очередного раунда общения с поддержкой одного крупного поставщика ИТ услуг. Я пришёл с конкретной проблемой: симптомы, версии, логи, репро-кейс — всё на месте. В ответ получил аккуратное, холодное: «Это не на нашей стороне. Обратитесь к вашим местным сетевым инженерам». Иными словами — отфутболили.
Такое случается повсеместно, и всё же именно в тот момент я поймал себя на мысли, что уже видел эту картину раньше — только с другой стороны. Я вспомнил свой путь: от «эникейщика» на госслужбе до Service Delivery Manager в международной компании. Я помню время, когда один человек чинил всё — от розетки до кода. И помню, как в больших организациях между командами вырастают стены: обращения ходят по кругу, метрики выглядят прилично, а сервис по-прежнему стоит.
С тех пор у меня простое убеждение: поддержка XXI века обязана измеряться не количеством уровней поддержки, а скоростью и качеством восстановления, не говоря уже о постоянном улучшении сервиса (Continuous Service Improvement, CSI). Не «чей запрос», а «кто взял на себя ответственность довести до результата». Это и есть главная тема этой статьи — как вернуть поддержке цельность и скорость, не потеряв безопасность и зрелость процессов.
Дальше — о том, что мы потеряли на пути от «человека-оркестра» к узкой специализации, и как вернулась назад универсальность, но уже в версии 2.0.
Когда «айтишник» чинил всё
Конец 90-х, начало 2000-х — время, когда ИТ было ближе к ремеслу, чем к выстроенному процессу. В небольших компаниях от одного человека ждали целиком «закрыть контур»: протянуть витую пару и обжать коннектор, переустановить Windows и поднять домен, настроить бэкап и написать скрипт, починить принтер и выправить отчёт в базе. «Человек-оркестр» — не фигура речи, а способ выживания: меньше согласований, выше скорость, ниже стоимость.
В такой среде вырабатывалась полезная привычка — мыслить целостно. Не было никаких очередей и порталов: если у кладовщика не печатается накладная, ты идёшь по цепочке — есть ли бумага, не зажевало ли её, включён ли принтер, жив ли кабель/порт, виден ли принтер в системе, не зависла ли очередь печати, корректно ли установлен драйвер, доступен ли сервер печати, не упал ли свитч, хватает ли прав в приложении, отвечает ли база. И так — пока накладная не выйдет из принтера. Важно было одно: вернуть работу в строй как можно скорее.
Разумеется, у этой модели были издержки. Надёжность держалась на индивидуальном героизме, знания передавались из рук в руки, а документация жила в голове и в папке с утилитами на флешке (если вообще была). Но именно тогда я приобрёл опыт, которым дорожу до сих пор: если можно вернуть систему к жизни за пять минут — это надо делать; а потом уже разбираться, как оформить решение так, чтобы оно стало штатным. Не зная, что такое Agile, я жил по Agile 😅.
Большая машина и толстые стены специализаций
Затем мне повезло поработать в большой федеральной компании. Там не было отдела ИТ — там был целый ИТ-департамент, около 500 человек. Предсказуемость, роли, процессы, регламенты — всё по рельсам. И вместе с этим выросли толстые стены специализаций на стыках команд. Мне пришлось выбрать специализацию, и я выбрал быть DBA — администратором баз данных, хотя очень любил программировать; но тогда DBA платили больше 💸: бэкапы и восстановление, производительность, HA/DR, патчи, соответствие требованиям — моё новое всё.
Я видел это много раз. Ночью падает производительность, прилетает тикет — у пользователей «висит» форма. Мониторинг БД показывает рост ожиданий ввода-вывода. Я подозреваю диски и переназначаю тикет администраторам систем хранения — через час он возвращается с отпиской «проблем не видим». Кидаю тикет сетевикам — ещё через час он возвращается обратно. Пинг-понг повторяется, а проблема не решается. В итоге SLA «протухает», и виноватым становится тот, на чьих руках тикет застал дедлайн. А через сутки выясняется, что причина — просто крошечная настройка на одном из узлов ERP-системы (за эти серверы я вообще не отвечал).
Специализация — не враг. Она дает глубокую экспертизу и качество. Проблема в другом: нет сквозного владения и прочных «мостов» между командами — кто ведёт запрос до конца и отвечает за результат. Именно здесь я впервые по-настоящему почувствовал, что «правильно» — не всегда «полезно» для сервиса.
«Правильно» — не всегда «полезно»
Я хорошо помню это чувство: ты всё делаешь «по правилам», а сервис стоит. Передаёшь дальше, ждёшь ответа, согласовываешь — а людям нужно, чтобы заработало сейчас.
Однажды ночью встал склад: отгрузка уперлась в баг печатной формы. Формально это не моя зона. Я нашёл форму, реверс-инжинирингом в дамп-редакторе нашёл баг, поправил его — что называется, «херак-херак — и в продакшн». Через пять минут конвейер ожил, и компания не потеряла сотни тысяч долларов. Формально это зона ответственности разработчиков; в ту ночь они спали, и даже разбуди их — решение бы затянулось до утра, ведь они играют только по правилам.
И в этот раз я ещё раз убедился — как и в случае с «человеком-оркестром» — что в поддержке действует принцип «сначала восстановить, потом нормализовать»: правильная последовательность — сначала вернуть работу в строй как можно скорее, параллельно фиксируя сделанные шаги и уведомляя владельцев; а уже утром — оформить изменение, поправить код и документацию, коротко разобрать причины. Так эпизод героизма превращается в улучшение процесса — и в следующий раз решает уже не смелость, а система.
Команда «универсалов 2.0»
Став тимлидом, я сделал ставку на управляемую широту. Не «все делают всё», но каждый способен протащить задачу через стык, не роняя мяч. Разработчик — не DevOps-инженер, но умеет собрать простой пайплайн для новой фичи на Jenkins; позже этот пайплайн перепишет профессиональный DevOps, зато работа не стоит и появляется необходимая взаимозаменяемость. Сотрудник поддержки — не бэкендер, но открывает git-репозиторий, читает логи и на языке кода объясняет разработчику, в чём проблема; а в несложных случаях — сам правит код и формирует аккуратный pull request. DBA — не владелец продукта, но может предложить безопасный обходной путь, чтобы бизнес не стоял.
Чтобы это работало, широту пришлось «закрыть рамками». Любая правка идёт через короткий pull request и review; выкладки — маленькими порциями с возможностью отката (а-ля release management и change management); доступы — по принципу наименьших привилегий. Продукт активно обсуждается всей командой на регулярных встречах — поднимаем и кроссфункциональные темы. Так вся команда в курсе, как устроен продукт целиком.
Главный эффект — исчез лишний бег по кругу. Там, где раньше запрос кочевал между очередями, сегодня он движется по прямой: один человек берёт его в работу, зовёт тех, кто нужен, фиксирует шаги — и доводит до результата. Скорость выросла не за счёт героизма, а за счёт реальной командной работы и привычки смотреть на систему целиком. При этом сохраняется ownership: независимо от того, кто решает проблему в данный момент, всегда есть тот, кто знает полную картину.
Круг замкнулся — но на новом витке
Мы и правда вернулись к широте — только осознанной. «Универсал 2.0» — это не человек, который делает всё один, а тот, кто доводит задачу до результата, понимает соседние части системы и вовремя подключает нужных людей.
Краткий манифест современной поддержки
Владение до результата. Запрос имеет владельца до финала.
Скорость решения, но с контролем качества.
Широта — управляемая. T-shape навыки, guardrails, парные дежурства, кросс-обучение.
Прозрачность и учёба. Blameless RCA, чистые runbook’и, обновления после каждого случая.
Метрики по делу. Оцениваем не «сколько перераспределили», а как быстро и стабильно восстановили сервис.
Читайте мою серию: Усталый Босс
