Как правильно прочесть SLA на поддержку российского ПО и не поставить под вопрос успех перехода на него

Представьте ситуацию: в госорганизации закончился «пилот» ИТ-проекта по внедрению импортонезависимого ПО, прошло тиражирование – например, на 1 500 рабочих мест.

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

Но говорить об успехе проекта пока рано. В этой, на первый взгляд, благополучной ситуации, имеется опасный подводный камень. Он-то и может поставить под вопрос успех внедрения почти любого российского или свободного ПО. «Камень» этот – качество оказываемой технической поддержки. Причем, не одного продукта, а целого комплекса связанного между собой ПО (таков характер импортозамещения в ИТ – один продукт заменяется сразу на целый стек).

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

Проверять то, как в реальности работает вендорская техподдержка, обычно приходится на реальных инцидентах. Это долго, тяжело. К счастью для заказчиков, есть и гораздо более простой и быстрый, но при этом достаточно точный способ заранее разобраться в качестве услуги. Нужно внимательно прочесть SLA, обратив внимание на некоторые важные нюансы, которым зачастую не уделяют достаточного внимания или вообще считают их непроработанность “стандартной практикой”.

Что же это за пять параметров

Главное: если в соглашениях об уровне сервиса зафиксированы пять основных параметров, о которых я расскажу ниже, причем их значения находятся в правильном диапазоне, то за качество поддержки отечественного ПО (и, соответственно, за успех всего ИТ-проекта), можно не опасаться. Если же этого нет, это верный признак того, что обещанная вендорская техподдержка — лишь ширма, скрывающая за лакированными маркетинговыми фразами, слабость технологии (например, неумение компании-разработчика наладить масштабируемую систему линий техподдержки, правильно распределить их функции и подготовить персонал; или в интересах заказчика взаимодействовать с разработчиками другого ПО и сервисными компаниями). То есть, признак некомпетентности тех, кто взялся поддерживать новое, импортонезависимое ПО.

Часики тикают: не только время реакции, но и время решения ИТ-проблемы

Время реакции на ИТ-инцидент указано в SLA большинства разработчиков российского ПО – от 15 минут до 2 часов, в зависимости от инцидента. А вместо времени решения часто приводится только обтекаемая формулировка: «по согласованию с заказчиком». Это закамуфлированное предложение «употреблять программный продукт как есть». И документальное подтверждение того, что недостатки ПО будут устраняться неделями или месяцами… А менее весомые запросы (например, на дополнительную информацию о продукте или на его улучшение) могут не решаться вообще, так как вес запроса маловат! Причем, совершенно легитимно, если SLA подписал заказчик… Постарайтесь не допускать гладких и неясных формулировок в пункте «время решения проблемы». Там должно стоять точное значение (например, 1 час или 1 сутки) или временная вилка (например, от 4 до 8 часов).

Отслеживайте, чтобы время решения соответствовало приоритету инцидента. Не может ИТ-инцидент с высоким приоритетом, создающий существенные риски для основной деятельности или репутации организации, закрываться неделю. Один-два часа – максимум. Если времени требуется больше, техподдержка должна предоставить организации-пользователю приемлемое обходное решение (workaround, «костыли»). Получив его, сотрудники заказчика смогут спокойно работать, техподдержка уложится в SLA, а разработчик получит возможность как следует разобраться в проблеме, найти и проверить окончательное решение и выпустить его в виде патча для всех клиентов.

В то же время, время решения не надо устанавливать неоправданно малым. Ненужная срочность повысит издержки и увеличит число “костылей”.

Лекарство от перефутболивания: единый сервисный контракт на поддержку

Ясно, что заказчику ПО сразу нужно решение, которое с помощью определенного набора продуктов решает все поставленные задачи (например, поддерживает определенные бизнес-процессы или управление предприятием, обеспечивает инфраструктурные сервисы или обеспечивает менеджмент на основе данных). Представим, что он получил такое решение. И каждый вошедший в него продукт покрывается контрактом на вендорскую поддержку. Заказчик спокоен, а зря! Это совсем не означает, что проблемы с операционной системой (ОС), СУБД, СЭД, коммуникационной платформой и прикладным ПО будут решаться быстро. Потому что в подавляющем большинстве случаев (и во всех сложных!) ИТ-специалисты заказчика не понимают, какой именно компонент системы «сбоит». Они могут сделать по-инструкции абсолютно все, но СЭД все равно будет работать медленно и нестабильно.

Приходится писать разработчику: «СЭД не работает так, как заявлено в инструкции». Разработчик отрабатывает заявку в точном соответствии с SLA (полдня на реакцию, день на изучение проблемы). И выясняет, что причина проблемы кроется не в его софте, а, скажем, на уровне СУБД. Заказчику приходится забирать свою заявку и направлять ее к разработчику СУБД. Еще полдня на реакцию, день на изучение проблемы. После чего становится ясно, что проблема не в СУБД, а предположительно в ОС. Еще цикл, и через 1-2 дня заказчика могут отправить к производителю аппаратного обеспечения («вам неправильно собрали и настроили дисковую подсистему») или программно управляемой сетевой инфраструктуры. И, вроде, никто не виноват, ведь каждая служба техподдержки отработала свою часть так, как должна – по SLA. А заказчик несчастен. Время идёт, его информационная система уже неделю (если не больше) работает их рук вон плохо. Страдают все. Но ясности так и нет.

До недавнего времени это был единственный сценарий. Но в нашей стране появилось решение, полностью избавляющее заказчиков от «футбола» при техподдержке комплексов российского ПО. Это открытая шина техподдержки российского ПО и ПО Open Source. В основе данного решения лежит принципиально иной принцип организации вендорской техподдержки ПО: заказчик или интегратор получает эту функцию, заключив единый сервисный контракт, в котором сроки реагирования и устранения проблем распространяются на весь комплекс ПО. Взаимодействие с разработчиками отдельных продуктов сохраняется, но заказчика оно не касается, т.к. координатором является сервисная ИТ-компания – оператор открытой шины техподдержки. При этом с каждым вендором она работает по жестким внутренним соглашениям (т.н. OLA). Эффективность взаимодействия оказывается очень высокой, ведь оно происходит практически постоянно – во время общих проектов. Кроме того, умеют взаимодействовать и центры компетенций сервисной компании и вендоров.

Обслуживание всего комплекса программного и аппаратного обеспечения “из одного окна” избавляет организацию-заказчика и от попыток самостоятельной диагностики, и от трудного «хождения по вендорам».

От Москвы до Севастополя: одинаково качественная техподдержка

В стране, занимающей 1/9 часть суши, филиалы, дочерние и зависимые предприятия практически каждой крупной организации расположены не только в Москве или Питере, но и в регионах. Соответственно, вендорская техподдержка должна предоставляться не по хорошо знакомому интеграторам принципу «в каком регионе ресурсов больше, там и качество лучше», а покрывать всю страну. При этом заказчики должны получать единый уровень сервиса — вне зависимости от региона, его технологической зрелости, удаленности от столицы и т.д.

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

Правильно выстроенная и постоянно обучаемая партнерская сеть в регионах России также позволяет не раздувать контракты по техподдержке за счет командировок сотрудников – что выгодно для клиентов. Региональные ИТ-партнеры, привлекаемые к обслуживанию федеральных заказчиков головной компании партнерской сети, действуют (должны действовать!) в единых с ней стандартах, регламентах и ИТ-процессах. Это и гарантирует единый с «центром», стабильный уровень SLA по всей стране, вне зависимости от региона.

Ничто не забыто: качественная поддержка «безвендорного» ПО Open Source

ПО Open Source сегодня стало частью практически любого современного ИТ-решения, а многие продукты (nginx, puppet, ansible и др.) стали весьма популярны. Каждый такой продукт на добровольной основе развивает более или менее масштабное международное сообщество. Правила взаимодействия с такими сообществами в корне отличаются от работы с коммерческими поставщиками ПО, более того, многие сообщества имеют свои особенности, в которых надо разбираться. Более того, желательно иметь определенный авторитет, основанный на переданных сообществу исправлениях и доработках продукта. Российские компании-заказчики редко имеют такие компетенции, да и само желание так работать, что создает неудобства и риски.

Но оператор открытой шины техподдержки (см. выше) имеет как собственный центр компетенции по ряду продуктов Open Source (и многолетний опыт их использования как основы бизнеса), так и отработанную технологию взаимодействия с сообществами как со своеобразным аналогом «третьей» линии техподдержки для соответствующего свободного ПО. Что позволяет интегрировать его в общую схему техподдержки на основе SLA. Время реагирования на проблему или ошибку не отличается от обычного ПО и задается также четко (например, 2 часа), как и время предоставления обходного решения (например, 1 день, Next Business Day и др.). Но по вполне очевидным причинам такой SLA не может фиксировать сроки устранения на уровне постоянного решения, так как сообщества не берут на себя таких обязательств.

Подчеркну: мягкий SLA на решение ИТ-проблемы совсем не означает, что сервисная компания не решит ИТ-инцидент с «безвендорным» ПО вообще. Она будет взаимодействовать с сообществом, чтобы это произошло как можно быстрее. Но не может гарантировать жесткого времени отработки.

Принцип работы поддержки и новый рынок: предсказуемое устранение любых ИТ-проблем и ошибок ПО

Качественная вендорская теподдержка не должна работать по принципу, навязанному заказчикам западными ИТ-компаниями: «устранять проблему будем, только если для нас это экономически целесообразно» (например, запрос на решение стал массовым или организация-клиент купила премиальную поддержку). Этот принцип выгоден разработчику, но не заказчику, который не может быть уверен в своей информационной системе. Открытая шина вендорской техподдержки выгодна именно заказчику, так как снижает его риски, устанавливает жесткие рамки для устранения всех ошибок и ИТ-инцидентов, даже самых сложных (на стыках программных продуктов или софта и “железа”, в глубоких слоях Windows- и Linux-инфраструктур). И при этом сводит к минимуму участие пользователей в устранении проблем. В этом российские ИТ-компании превзошли западные.

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