Раз в неделю падает один и тот же сервис. Админ его перезапускает, пользователи возвращаются к работе, инцидент закрывают. Через несколько месяцев авария превращается рутину, и так продолжается годами. Управление проблемами — problem management — начинается в тот момент, когда кто-то все-таки спрашивает: «Почему это повторяется?». Для сервисного провайдера это логичное продолжение управления инцидентами. Обычно мы сами инициируем разбор, как только серия однотипных происшествий перестает выглядеть случайностью. Но если ты аутсорсер, то найти root cause — это только полдела. Дальше нужно понять, что с ней делать. Причина может оказаться в продукте вендора, легаси заказчика или системе другого подрядчика — то есть там, где инженер внешней техподдержки не может просто взять и исправить ее. Но и тогда можно попробовать договориться и исправить ее. Об этом сегодня и пойдет речь.
Меня зовут Наталия Сляднева, и я руковожу Центром экспертизы по комплексному сервису К2Тех. Под катом — два расследования с разными финалами и третий случай, в котором проблему осознанно не стали решать. Иногда это самый рациональный вариант.
«Чистите базу, и все пройдет»
Один из наших заказчиков, крупный облачный провайдер, предоставляет клиентам резервное копирование как услугу (BaaS, Backup as a Service) на базе Veeam. У них есть своя опытная команда, мы же подключаемся к сложным случаям, так как глубоко знаем продукт. У нас даже работают выходцы из самого Veeam.
Инфраструктура заказчика обслуживает тысячи клиентов и включает десятки инсталляций. В одном тенанте число точек восстановления доходит до сотен тысяч. На таком масштабе Veeam Service Provider Console начала сдавать: консоль загружалась все дольше, периодически падала, и ситуация постепенно ухудшалась. Администраторы резервного копирования практически остались без рабочего инструмента: ни проверить, что копии создались, ни убедиться, что сервис работает штатно.
По логам мы увидели, что очистка накопившихся сессий оживит интерфейс, но до следующего заполнения базы.Чтобы найти нормальное решение, нужно было понять, почему падает производительность.
Такой повторяющийся сбой — типовая точка входа в problem management. Тут мы сразу воспользовались преимуществом крупного сервисного интегратора — в компании всегда найдутся коллеги с нужной специализацией. Veeam хранит данные в Microsoft SQL Server, поэтому мы попросили помочь наших разработчиков, которые проектируют решения на этой СУБД.
Узкое место нашлось в схеме БД. Оказалось, что в таблице [dbo].[C.BObjects] не хватало некластеризованного индекса по полю id с включенным столбцом viobject_type. Без него запросы каждый раз сканировали всю таблицу объектов резервного копирования. Данных становилось больше, запросы выполнялись все дольше — пока интерфейс не зависал окончательно.
Мы создали индекс на уровне СУБД, заказчик добавил его в БД. Консоль снова заработала нормально, повторные сбои прекратились, и больше не нужно было чистить базу вручную. Формально причина находилась в зоне ответственности вендора, но заказчику не пришлось ждать фикс в следующей версии продукта.
«Вам же выгодно, чтобы все ломалось!»
В одной статье на Хабре прямо предположили: подрядчику выгодны постоянные сбои. Логика понятна: больше заявок — больше оплачиваемой работы. На практике при такой постановке вопроса не учитывается устройство сервисных контрактов. Если бы они работали именно по такой логике, то внешней сервисной поддержки не существовало бы, заказчикам она была бы просто невыгодна.
По сути, есть две основные модели контрактования. Первая — Time & Material: заказчик покупает определенный объем часов, например 500 в год, и расходует их на нужные работы. Это могут быть RCA (Root Cause Analysis), аудиты, внедрения, настройки или другие задачи, которые возникают по ходу эксплуатации. Часто стороны договариваются заранее, что делать если вдруг к концу контракта останется пул неиспользованных часов. К этому моменту сервисная команда уже достаточно глубоко погружается в ИТ-ландшафт и может предлагать работы, которые имеет смысл выполнить.
Такая модель подходит, когда объем и состав работ трудно предсказать заранее, например, при внедрении, миграции или разовом обследовании. Она хороша, если компании нужен постоянный доступ к экспертизе, но пока неясно, какие именно задачи появятся в течение года. Почасовая отчетность в таком случае позволяет понять, на что уходят ресурсы, и как меняются приоритеты.
Вторая модель — fixed-price, или абонентская плата. Здесь сервисная команда берет на себя поддержку отдельного участка инфраструктуры: парка виртуальных машин, почтовой инфраструктуры и т. п. Границы контракта задаются составом контура (количеством хостов и систем на поддержке) и перечнем работ, который команда по ним выполняет, будь то обработка инцидентов, регламентные задачи или консультации. В результате компания платит не за каждое обращение, а за готовность команды поддерживать работоспособность инфраструктуры и сервисов в рамках согласованного SLA.
Fixed-price обычно выбирают, когда важно заранее зафиксировать бюджет, а инфраструктура давно устоялась и не меняется. Причем чем дольше команда работает, тем лучше узнает особенности контура, планирование затрат при продлении договора опирается на накопленную статистику, что позволяет со временем оптимизировать затраты.
Поэтому для сервисного подрядчика постоянные сбои не становятся источником выгоды сами по себе. В фиксированной модели повторяющиеся инциденты требуют все больше времени инженеров и линий поддержки, но не создают дополнительной выручки, а в Time & Material они расходуют уже купленный пул часов, который мог бы пойти на аудит, оптимизацию или развитие. Поэтому RCA здесь не противоречит коммерческой логике, а помогает убрать повторяющуюся работу, точнее планировать ресурс и сделать поддержку предсказуемее для обеих сторон.
RCA часто выносят в отдельную услугу, и в фиксированном договоре ее границы важно прописать отдельно, чтобы не смешивать восстановление сервиса и изменения, которые затрагивают архитектуру, настройки или смежные системы. В Time & Material RCA, наоборот, может расходовать значительную часть купленного пула часов. Отдельная услуга позволяет заранее избежать этого и прозрачно расписать, где RCA нужно, а где — нет.
«Стоп, почему это повторяется?»
В нашем процессе проблему обычно регистрируют по одному из трех сигналов:
серьезный инцидент закрыли обходным решением. Если сервис восстановлен, но причина неизвестна, мы в вместе с техническим менеджером и заказчиком решаем, запускать ли отдельное расследование;
в отчетности регулярно появляются однотипные обращения или алерты;
заказчик прямо просит: «Разберитесь, почему это происходит».
Для самых тяжелых случаев обсуждение не требуется: если бизнес понес или мог понести серьезный ущерб — например, остановился конвейер, — расследование запускается автоматически.
Здесь важно не смешивать incident и problem management. Первый возвращает сервис в строй в пределах SLA, а вот problem management нужен чтобы устранить причину уже после восстановления. Если делать все одновременно, инженеры могут увлечься расследованием, в то время как сервисы заказчика еще не восстановлены.
Кто первым заметит повторяющиеся инциденты и откроет проблему, зависит от модели поддержки. Если мы ведем весь поток заявок и готовим отчетность, то и повторы обычно замечаем первыми. А когда у заказчика есть собственная команда, то мы выступаем экспертной поддержкой, а инициатором чаще становится он.
Полноценный problem management пока редко прописан в договоре с первого дня, но мы не ждем у моря погоды. Это логичное продолжение процесса менеджмента инцидентов, так что обычно мы инициализируем этот процесс сами, как только повторяющиеся инциденты перестают выглядеть случайностью.
Дело о потерянных письмах
Другой заказчик, крупный холдинг с площадками по всей стране, переносил корпоративную почту из Microsoft Exchange в VK WorkMail. Во время миграции системы работали параллельно: сотрудники оставались в Outlook, а их ящики реплицировались в VK WorkMail по IMAP. Сначала планировалось перенести архив, а затем досинхронизировать новые письма.
Вот только некоторые письма не переносились. Exchange отвечал ошибками на часть IMAP-операций, а в логах некоторых сессий команды и ответы шли вразнобой. Причем сегодня ящик мог синхронизироваться без ошибок, завтра те же операции срывали перенос, а на третий день все снова было окей.
Мы сопровождали миграцию и обе почтовые системы, поэтому собрали общую группу из специалистов по Exchange и VK WorkMail. Команда сняла трассировки IMAP-трафика и пошагово восстановила историю действий, которая приводила к проблемам.
Мы сравнили хронологию с эталонной работой протокола и увидели, что в части сессий IMAP-клиент VK WorkMail отправлял следующую команду, не дождавшись тегированного ответа на предыдущую. Само по себе это еще не проблема: RFC 3501 допускает отправку нескольких команд до получения ответов, пока между ними не возникает неоднозначности.Но мы нашли воспроизводимую последовательность, при которой Exchange возвращал ошибки и часть писем не переносилась.
Причина оказалась в логике IMAP-клиента VK WorkMail. В отличие от случая с индексом, здесь мы не могли исправить все на своей стороне, код клиента мог поменять только его разработчик. Поэтому мы передали вендору готовый воспроизводимый кейс с трассировками, последовательностью команд и сценарием сбоя. Коллеги это оценили. После этого кейса мы стали работать с командой VK WorkMail заметно плотнее.
До выпуска исправления проблема остается в трекере как known error. Она не закрыта, но команда знает причину и условия сбоя, а значит может управлять риском во время миграции.
Пять возможных финалов
В обоих кейсах причина оказалась в продукте вендора. В первом мы внедрили решение сами, во втором — собрали доказательства и передали дефект разработчику. Оба исхода рабочие: конкретный путь зависит от полномочий, рисков и цены изменений.
В нашем процессе у проблемы может быть пять основных исходов:
Исправить проблему своими силами.
Передать ее команде, отвечающей за систему или продукт, и добиться исправления.
Оформить запрос на изменение, если нужно серьезно вмешаться в систему.
Выделить модернизацию в отдельный проект.
Описать обходное решение, присвоить статус known error и принять остаточный риск.
«Будет ломаться — восстанавливайте»
Исход выбирают, сравнивая, что будет дороже — смириться с проблемой или ее решить. Все зависит от ущерба от для бизнеса и пользователей. Если из-за инцидента страдает производство, то даже 30 минут простоя в квартал оборачиваются миллионными убытками, и никто не пожалеет время на расследование.
Другое дело, если из-за инцидента падает внутренний сервис, которым почти никто не пользуется, а на расследование потребуется около 80 часов работы инженеров. Тогда условные 30 минут восстановления раз в квартал не так уж чувствительны. Получается, что рациональнее оставить все как есть, особенно, если система, как в следующем кейсе, доживает последние месяцы.
У одного заказчика часть инфраструктуры работала на VMware 6.7 и устаревших серверах. И хотя сбои повторялись, мы не могли обновить платформу без замены железа, новые версии ПО его уже не поддерживали. Все хорошо понимали в чем дело, и осознавали, что пора модернизировать платформу, но заказчик собирался вывести сервера из эксплуатации в конце года. В итоге заказчик осознанно принял риск сохранения текущей конфигурации. Да, это не самый эффектный финал расследования, зато экономически оправданный. Кроме того, в подобных случаях мы иногда предоставляем подменное оборудование из собственного резерва. Это не устраняет причину проблем, но снижает частоту сбоев до модернизации или вывода системы из эксплуатации.
Такой результат можно назвать поражением problem management, но только в первом приближении. Все таки осознанно принять риск — не то же самое, что замести проблему под ковер. Мы документально зафиксировали решение: прописали владельца риска, стоимость повторного инцидента, порядок восстановления и условия пересмотра (перенос срока вывода системы из эксплуатации), следовательно сделали ситуацию контролируемой.
Чек-лист: вы управляете проблемами?
На практике problem management начинается с простого вопроса: «Почему это повторяется?», а завершается оформлением отдельной проблемы с владельцем, сроком и согласованным исходом. Это может быть индекс в базе, баг-репорт вендору и даже простое понимание «оставляем все как есть». Главное, чтобы единственным объяснением не оставалось: «Да оно всегда так падало».
Problem management непрост в постоянной реализации, но проверить свою службу поддержки или подрядчика можно за несколько минут при помощи ряда несложных вопросов:
Можно ли выгрузить повторяющиеся инциденты, например, топ однотипных обращений за квартал или за год? Порог повторяемости дело индивидуальное, но важно иметь саму возможность получить такую аналитику из системы заявок.
У каждой проблемы есть конкретный владелец, или за ними стоит безликая «вторая линия»?
Связаны ли в тикет-системе инцидент, проблема и изменение? Можно ли пройти всю цепочку от сбоя до внедренного решения?
Зафиксированы ли случаи, когда решено ничего не менять? Кто принял риск, когда и почему?
Если на большинство вопросов ответ «нет», служба поддержки может исправно выдерживать SLA, но сбои все равно будут возвращаться. Сервис из начала статьи продолжит падать по расписанию, ведь причины его регулярных сбоев никто не расследует.
Знакомая ситуация? Если у вас есть такой проблемный сервис, расскажите в комментариях, почему его до сих пор не оформили как проблему? Наверняка на то есть уважительная причина. Есть же?
