Мифы поддержки Майкрософт: 24x7 – реальный опыт

Все кто работает в ИТ более трех лет сталкивались с необходимостью перевода ПО, работающего в производственной системе на новую версию. Три года – примерно тот срок, который требуется производителю для внесения критической массы декларируемых полезных изменений в функциональность продукта, которые в итоге подталкивают организацию к смене версии.

Не секрет, что абсолютно безошибочных продуктов не бывает, а учитывая современную гонку под  лозунгами быстрее и дешевле некоторое  количество критичных ошибок остается и в финальной (релизной) версии.

Именно для их устранения на этапе внедрения казалось бы и должна быть «заточена» служба поддержки. Но можно ли на нее надеется на этапе внедрения? Оправдает ли служба поддержки возложенные на нее ожидания? Выяснять это мне пришлось в ходе реального взаимодействия со службой поддержки Майкрософт. Возможно, мой опыт поможет сберечь вам немного нервных клеток, а развенчивание сложившихся исключительно в моей голове мифов позволит сберечь время.

Эпизод 1.

Так получилось, что наша организация решила перейти на Microsoft Exchange 2010 в числе первых (уж слишком много «вкусного»  было обещано в функциональности) и буквально спустя несколько месяцев после выхода продукта мы решились на переход. У профессионалов, работающих с продуктами Майкрософт продолжительное время , конечно, бытует мнение, что до появления первого сервис пака (а лучше второго сервис пака) продукт является еще сырым и торопиться не стоит. Но выбор был сделан и время вроде бы выбрано подходящее – длинные новогодние выходные.

Ничто не предвещало опасности – ведь никто не сомневается, что Майкрософт уже провел внедрение в собственной (в тысячи раз большей, чем наша) организации. У нас есть контракт, в котором прописана включенная в Software Assurance Benefits (право перехода на новые версии без дополнительной оплаты) поддержка 24x7 и даже что-то написано про Premium Support.

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

Наступает Новый, 2010 год. Под бой курантов в узком семейном кругу или в шумной компании уходит старый и приходит Новый год.
Миграция идет по плану (тут надо заметить, что единственный способ миграции с 2007 на 2010 это перенос почтовых ящиков встроенными средствами Exchange).

И тут ...

Один из пользователей обнаруживает, что в его мейлбоксе не работает доступ по IMAP4 – базовая функциональность, существующая в Exchange с незапамятных времен и имеющая от силы три настройки на уровне сервера.

Рис.1 настройки IMAP4 в Exchange 2010 – настраивать нечего

Как видно из скриншота - настраивать нечего.

Пользователь, обнаруживший проблему,  использует данную функциональность не для баловства – так он синхронизирует свое не Windows Mobile устройство к которому привык и это позволяет ему эффективно работать (по роду деятельности он проводит большую часть времени вне офиса).

Дальнейшее исследование показывает, что аналогичная «беда» приключилась и с POP3, а на эту функциональность завязано функционирование некоторых старых внутренних приложений.

Рис.2 настройки POP3 в Exchange 2010 – настраивать тоже нечего

Как видно из скриншота про POP3 тут также нечего настраивать.

Майкрософт Support нам поможет – решает команда и мы пытаемся получить 24x7 в период новогодних праздников – ведь он же круглосуточный и праздников у него быть не должно.

Сайт русскоговорящего суппорта извещает нас, что в период праздников он не работает (к сожалению, в то время было не до скриншотов).

Ок – мы и по английски общаться умеем – начнем с веб суппорта.

Идем на соответствующий сайт, выбираем продукт, заполняем контактную информацию, вводим SA ID (номер контракта поддержки) и ... получаем сообщение, что данная версия/продукт не входит в наш контракт. Повторяем процедуру еще раз – тот же результат.

Рис 3. выбор способа поддержки – пришлось выбрать платную

Ок – регистрируем инцидент в платном суппорте (pay per incident) – сумма действительно небольшая, но заплатить ее можно только карточкой – нам повезло, у нас была корпоративная и все получилось (в смысле с оплатой).

Через какое-то время нам перезванивает первая линия поддержки (из Индии). Все чудесно и по ITIL, инцидент регистрируется, собираются сведения о версии установленного ПО, о влиянии инцидента на нашу организацию и т.д. Проверяются установки настроек IMAP/POP3, доступные через GUI (как мы разобрались раньше  – настроить или поломать тут практически ничего нельзя).

Так в общении по телефону проходит примерно 4  часа (сумма, потраченная поддержкой на общении по телефону (международный звонок) уже давно в разы перекрыла оплаченную нами на этапе регистрации инцидента). И тут у инженера поддержки заканчивается смена (мы в разных часовых поясах) и он сообщает, что наш инцидент продолжит разбирать другой инженер из новой смены и он ему все передаст. Действительно, другой инженер нам весьма оперативно перезванивает, но процедура поиска неисправности начинается буквально сначала.

Терпение инженера с нашей стороны на исходе – представьте себе с одной стороны внутренние пользователи, ждущие чуда – изменение настроек и восстановления отлично работавшей в Exchange всех предыдущих версий функциональности, с другой стороны служба поддержки, инженер которой по кругу повторяет то, что уже проделывалось его коллегой с предыдущей смены.
Применяем свои знания о том, как устроена многоуровневая служба поддержки и эскалируем. Нам долго объясняют, что эскалация займет сутки (Sic!) и уговаривают продолжить решение проблемы на текущем уровне. Мы не соглашаемся и выбираем эскалацию.

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

На воспроизводство окружения уходит еще ... неделя.

Понятно, что бизнес пользователи не очень счастливы и команда изобретает, тестирует и применяет всяческие воркараунды – экспортировать с помощью клиента почтовый ящик, пересоздать майлбокс – помогает, но очень трудоемко. Передвинуть майлбокс обратно на 2007 сервер – тоже работает, но ввиду немалого размера майлбоксов тоже занимает время, да и поддерживать два окружения в течении длительного времени (например, выполнять резервное копирование) можно неделю, две но не длительное время.

Подключаем Гугл поиск (на самом деле это делалось постоянно с момента обнаружения проблемы)  и ищем, единственные ли мы, кто столкнулся с такой проблемой. На форумах поддержки МС находим, что не единственные, и более того, проблема была озвучена еще на момент существования RC1, но так и не была исправлена перед выпуском продукта.

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

Наконец, где-то в середине февраля инженер со стороны Майкрософт предлагает найденный кем-то из его коллег, работающих над аналогичной ситуацией у другого заказчика менее трудоемкий и воплощаемый на уровне пользователя воркараунд: в проблемном мейлбоксе сделать папку – переместить в нее все сообщения, переместить их обратно в Inbox – IMAP/POP3 работает.

К концу марта Майкрософт выпускает Exchange 2010 Rollup 1 в котором проблема недоступности содержимого майлбоксов по IMAP после миграции с 2007 на 2010 решена. Нам это уже не помогает (мы в начале марта закрыли наш инцидент, поскольку все кому надо применили воркараунд).

К сожалению, это оказалось не последней проблемой в Exchange 2010 и нам пришлось еще несколько раз пообщаться со службой поддержки.

Эпизод 2.

Весна, менее критическая проблема – затронуто 10 пользователей. Специфическая проблема отправки сервером отправителя письма без указания кодировки приводит к проблемам с его получением.

Наш инженер регистрирует инцидент по телефону в рамках Software Assurance Benefits 24x7. Получает номер инцидента. Проходит три дня (Sic!) – никто не отзванивается. Звоним в службу поддержки – оказывается оператор первой линии ошибся с регистрацией телефона/email и с нами не могли связаться. Но, простите, ведь зарегистрирован номер SA ID – по нему однозначно вычисляется организация, оплатившая контракт и технический администратор этого контракта, у которого в системе есть имя, фамилия, емайл, телефон. Нет – никаких попыток связи выполнено не было.

Эпизод 3.

Немного другой продукт – Forefront for Exchange (кстати, чудный продукт – после его внедрения мы практически забыли о существовании СПАМа в почтовых ящиках). Некая проблема с вложениями. На этот раз все проходит на удивление гладко – регистрация, звонок инженера со стороны Майкрософт, решение путем изменения настроек (оказывается MS Product Team зачем то поменяла  настройки по умолчанию на некорректные значения при выпуске апдейта и их надо вернуть в предыдущее состояние).

Эпизод 4.

Сложная проблема с периодической (примерно раз в день) недоступностью почтового сервера для «толстых» клиентов (Outlook). Лечится перезапуском сервиса паблик фолдеров. Регистрация, признание проблемы, передача в команду разработки продукта, эскалация, эскалация с помощью аккаунт менеджера, назначение Premium Support инженера – исправления и даже воркараунда до сих пор нет – может будет к концу июня.

Эпизод 5.

Наша компания разработало критичное для заказчика ПО обработки данных в реальном времени, использующее встроенный функционал Windows Server 2003. ПО чудесно работает у нас, на тестовой площадке у заказчика, но периодически перестает функционировать на производственной площадке. Пытаемся обратиться в поддержку МС (есть подозрение, что проблема в реализации работы 32 разрядных приложений на 64 битной платформе). Получаем ответ – поддержка (даже партнерская) не занимается проблемами совместимости не Майкрософт приложений – попробуйте написать в форумы МСДН. Команда наших разработчиков нашла воркараунд, но ...

Эпизод 6.

Найдена некая проблема в функционировании приложений Майкрософт. Наивно прочитав информацию на картинке ниже, как возможность использовать Premium Support в рамках существующего контракта звоню в техническую поддержку и прошу открыть Premium Support Incident.

Рис. 4 Premium поддержка – в реальности ее надо приобретать за дополнительные деньги

Мне отвечают, что в нашем контракте его нет и есть человек в российском офисе Майкрософт, который может мне пояснить как это работает. Звоню – сотрудник не доступен. Возвращаюсь в службу поддержки  и начиная нервничать (я то думаю, что могу открыть инцидент). Удивляюсь, как один человек может отвечать за Premium Support во всей России. В итоге, через какое-то время меня связывают с этим сотрудником и я узнаю, что такой сервис стоит дополнительных денег, причем достаточно больших и на его оказание надо заключать отдельный контракт. В эпизоде 4 нам была предоставлена возможность попробовать сервис в действии. К сожалению, волшебства не произошло – не зависимо от уровня поддержки Product Team работает по своему графику. Как нам пояснили, в Premium поддержке есть, конечно, ряд преимуществ – возможность обойти первый уровень поддержки и сразу оказаться на втором, проактивное обследования инфраструктуры и устранение проблем до их появления и т.д. Однако, мы пока не решились заплатить за этот сервис.

В качестве заключения

Наличие технической поддержки, безусловно хорошо, но не следует рассматривать ее сотрдуников как волшебников, которые за считанные часы/дни смогут исправить что-то в коде продукта и восстановить бизнес функционирование критичных систем. В лучшем случае они смогут помочь изменить настройки продуктов или предоставить непубличное исправление , подготовленное для другого заказчика.

Планируя переход на новый продукт на выходные и праздники удостоверьтесь, что поддержка производителя готова вам помочь.
Придумайте себе проблему и попробуйте решить ее с помощью службы поддержки – несомненно узнаете много интересного (надеюсь, что статья не вызовет немедленный шквал звонков в службу поддержки и там меня не проклянут). Попробуйте позвонить на выходных.

Резюме: безопасность это не только брандмауеры, антивирусы и назначение прав на NTFS разделе, но еще и качество внедряемых продуктов и способность поставщика оперативно решать проблемы, возникающие в ходе эксплуатации, а лучше построить процесс разработки и тестирования выпускаемых продуктов так, чтобы в поддержку почти никто не обращался – все работало «из коробки».

Удачных вам переходов!