OPEN SOURCE. Техподдержка СПО – какой она должна быть?::Журнал СА

По данным Gartner, более 95% ИТ-компаний в мире сейчас используют open source-решения. Среди остальных компаний не менее 40% предпочитают в работе свободное ПО, хотя проблемы эксплуатации продуктов с открытым исходным кодом остаются. Одна из них – стоимость и качество поддержки работы решений на базе СПО. Как же создать или получить гарантированную поддержку?

Вопрос 1. Типичные проблемы техподдержки open source-продуктов?

Николай Фатнев

– Главная проблема поддержки open source (и не только!) продуктов связана с растущим дефицитом квалифицированных кадров, и, как следствие, их высокой стоимостью. В последние годы она усугубилась усилившимся оттоком опытных специалистов за рубеж. В этих условиях компании вынуждены открывать корпоративные университеты и самостоятельно растить кадровый резерв. А чтоб готовый специалист не ушел к конкурентам, ему нужно предложить достойную мотивацию, понятную траекторию развития, интересные задачи и проекты.

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

Григорий Сизоненко

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

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

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

Дмитрий Заруднев

– На мой взгляд, наибольшей проблемой поддержки СПО является отсутствие у команды разработки полного понимания логики и архитектуры используемого СПО. Зачастую разработчики изучают код open source-продуктов лишь поверхностно и только в части того функционала, который им требуется. Отсюда сложность поддержки при возникновении проблем. Требуется больше времени на поиск решения, чем если бы это был собственный продукт.

Максим Шалыгин

– Компания «Диджитал Дизайн» разрабатывает решения как с использованием проприетарного ПО, так и программного обеспечения с открытым кодом.

В части оказания техподдержки заказчикам можно выделить следующие проблемы: многомодульность ПО с высоким уровнем кастомизации; подбор, подготовку и удержание квалифицированных ресурсов; выстраивание коммуникации с заказчиком; составление детального и понятного технического задания. В случаях, когда в решениях использованы СПО-продукты, дополнительную сложность при оказании технической поддержки создает невозможность привлечения вендора.

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

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

Алексей Романов

– Если у разработчика отлажены процессы техподдержки, а именно автоматизированная работа над входящими заявками от клиента service desk, то никаких проблем с техподдержкой open source-продуктов не должно возникать.

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

Вадим Сабашный

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

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

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

Михаил Назаров

– Типичные проблемы, с которыми техническая поддержка открытых программных продуктов (open source), может столкнуться:

Ограниченные ресурсы: в связи с тем, что большинство открытых программных проектов имеют ограниченный или недостаточный финансовый ресурс, команда техподдержки может столкнуться с недостатком сотрудников или ограниченными возможностями по предоставлению надлежащего уровня поддержки.
Разнообразие платформ: открытые программные продукты могут быть разработаны для работы на различных операционных системах и платформах. Это может создать сложности в обеспечении поддержки для всех этих платформ, так как требуется наличие экспертов со знанием каждой из них.
Совместимость версий продукта и слабо проработанный процесс Upgrade на следующую версию: каждое обновление требует тщательного тестирования и сопроверки.
Отсутствие коммерческой поддержки: в некоторых случаях у открытых программных продуктов может не быть официальной коммерческой поддержки. Это означает, что пользователи могут оставаться без должной техподдержки, особенно если проблема требует специализированных знаний или решений.
Децентрализация разработки: открытые программные проекты часто совместно разрабатываются и поддерживаются сообществом разработчиков. Это может создавать сложности для технической поддержки, так как ответственность за исправление и поддержку может размазываться между различными участниками сообщества.
Отсутствие документации или документация недостаточного качества: техподдержка может столкнуться с проблемой отсутствия или недостаточного качества документации по открытым программным продуктам. Это может затруднить процесс поддержки и увеличить время, необходимое для решения проблемы.
Языковые барьеры: поскольку открытые программные продукты разрабатываются и используются во всем мире, техподдержка может столкнуться с проблемами языкового барьера. Обеспечение поддержки на различных языках может быть сложной задачей.

Это только некоторые из типичных проблем, с которыми техподдержка open source-продуктов может столкнуться. Конкретные проблемы могут варьироваться в зависимости от конкретного проекта и его сообщества

Сергей Головашов

– Мы считаем, что самые распространенные проблемы, с которыми приходится сталкиваться, следующие:

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

При этом любая организация должна на момент перехода на СПО отдавать себе отчет в том, что ее структура технической поддержки должна быть перестроена, в ней должны присутствовать не просто несколько эникейщиков, но и архитекторы 4-го уровня, DevOps и DevSecOps-инженеры.

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

Некоторые вопросы, которые следует учитывать: открытость и диффузный характер разработки СПО; то, насколько хорошо проприетарное программное обеспечение работает с программным обеспечением с открытым исходным кодом; лицензионные ограничения обоих продуктов.

Максим Ткачев

– Поддержка open source-продуктов существенно отличается от поддержки привычных проприетарных enterprise-продуктов. Например, мы не можем рассчитывать на продуктивную коммуникацию с создателем решения. Часто разработчики не в состоянии протестировать продукт на том же или похожем «железе», на котором работает заказчик.

В свою очередь, подготовка инженера поддержки осложняется отсутствием учебных материалов и основывается только на документации. Разработчики описывают не все случаи, поэтому многие ограничения приходится узнавать опытным путем. При возникновении проблем инженерам поддержки часто приходится заглядывать в код, что подразумевает наличие соответствующих компетенций. В случае с Open Source инженер превращается в «полуразработчика».

Матвей Васильев

– В текущее время проблем у открытого ПО не так уж и много, и, как правило все они связаны с человеческим фактором. Основные проблемы заключаются в документации и качестве релизов. Чем крупнее и «живее» open source-проект, функционал которого используется, тем лучше – соответственно, поддерживать такие решения гораздо проще.

Владимир Суворов

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

Open Source ПО предоставляет возможность для совместного участия и взаимодействия между разработчиками и пользователем, что способствует росту и улучшению проекта благодаря совместным усилиям и обмену знаний и опыта. Благодаря такой открытой и прозрачной среде, все заинтересованные стороны могут внести свой вклад и сделать проект еще более функциональным и надежным.

Типичные проблемы, связанные с технической поддержкой продуктов с открытым исходным кодом (Open Source), включают следующие аспекты:

Неработающая функциональность: когда возникают проблемы с работой определенных функций или компонентов в open source-продуктах, пользователи могут столкнуться с вопросом, кто отвечает за исправление ошибок и как это происходит. В сообществе Open Source разработчики и пользователи часто сотрудничают для обнаружения и устранения проблем путем подачи отчетов об ошибках (баг-репорты) и предложениях изменений (патчи).
Внесение изменений в основной репозиторий (апстрим): если пользователи создают исправления или улучшения в исходном коде open source-продукта, встает вопрос о том, должны ли эти правки быть приняты в официальный репозиторий проекта (апстрим). Принятие изменений зависит от процесса управления проектом, и может потребовать обсуждения и проверки со стороны основных разработчиков.
Обновления: открытый исходный код часто обновляется, чтобы устранять ошибки, добавлять новые функции и обеспечивать безопасность. Однако процесс обновления может вызывать вопросы. Пользователи могут столкнуться с проблемами, связанными с обновлением продуктов и их зависимостей, а также с необходимостью протестировать изменения перед внедрением в рабочей среде.

Решение данных проблем часто зависит от активного участия сообщества разработчиков и пользователей, а также от прозрачности и открытости проектов с открытым исходным кодом. Успешное разрешение технических вопросов обычно поддерживается сообществом и открытым обсуждением, что способствует постоянному совершенствованию продуктов Open Source.

Виталий Рыбалка

– Первая проблема – скорость. Она медленнее (иногда ощутимо) относительно платных продуктов.

Вторая проблема – платность. Зачастую при фактически open source-продукте за поддержку нужно платить.

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

Антон Бондарев

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

При этом, использование СПО имеет два положительных аспекта. Во-первых, в случае недостаточно качественной поддержки заказчику проще сменить компанию-поставщика услуг, чем в случае с проприетарным продуктом.

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

С другой стороны, эти два аспекта имеют свои ограничения. Сменить компанию-поставщика услуг на базе СПО проще, если заказчик – достаточно крупная компания. В этом случае, компания может даже создать специального поставщика или специальный отдел, который обеспечит ей приемлемое качество услуг по поддержке данного продукта или сервиса. Для малого и среднего бизнеса выбор будет сильно ограничен крупными поставщиками.

Популярность проекта СПО, не может являться залогом качества построенных на данном проекте продуктов и услуг. А в некоторых случаях может иметь негативные последствия. Так, в популярный проект труднее вносить изменения в которых заинтересована компания-заказчик, то есть влиять на направления развития. Плюс труднее отслеживать все изменения, и в проект могут попадать вредоносные функции.

Кроме того, необходимо отметить, что стать поставщиком на базе СПО проще и компаниям «однодневкам», которые предоставляют услуги ненадлежащего качества.

Если говорить именно про open source-решения, то для компании-поставщика это прежде всего связано с внесением изменений в upstream, и поддержка актуальных версий продукта (проекта). Наличие изменений, не внесенных в upstream долгое время, требует существенных затрат по сопровождению.

Сергей Марсанов

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

Мария Аверина

– Любой open source-продукт нужно постоянно развивать в соответствии с обновлениями open source-сообщества, регулярно его тестировать на наличие закладок протестного кода и дорабатывать его функциональность. Недостаточно просто взять базовое решение из открытого доступа. И для этого бизнесу необходимо нанимать большое количество высококвалифицированных кадров: разработчиков, аналитиков, QA-инженеров, специалистов по информационной безопасности, руководителей проектов. Это очень дорого, а в условиях текущего кадрового дефицита – еще и крайне сложно. Это одна из основных сложностей на рынке.

Кроме того, в России представлено несколько вендоров, например, Arenadata, для которых развитие open source-решений является основным бизнесом. Конкурировать с ними по качеству продуктов на базе открытого кода и уровню технической поддержки очень тяжело. Бизнес чаще выбирает работу именно с крупными, проверенными годами вендорами – так он может сократить зависимость от человеческого фактора.

Потеряв ключевого разработчика, обладающего компетенциями по open source, заказчик очень рискует. Заручившись вендорской поддержкой с необходимым штатом специалистов, имея задокументированный SLA, он может развивать open source-решение легче и дешевле

Виктор Вьюшков

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

Руслан Белов

– Необходимо провести четкую границу между продуктами, являющиеся «классическими» open source, и решениями, которые безусловно используют open source-модули, но имеют проприетарное ядро управления и большое число самописных модулей.

Чистый open source не применим по отношению к решениям enterprise-класса. Перед разработчиком, работающим с корпоративным сегментом, стоит задача развития продукта в соответствии с запросами заказчика. Этот же принцип касается организации техподдержки: обеспечить работоспособность продукта в целом, а не отдельных open source-модулей.

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

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

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

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

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

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

Николай Молчанов

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

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

Роман Карпов

– Open source-продукты нужно уметь «готовить». Во-первых, нужно признать, что как только разработчик взял что-то из open source и добавил в свою информационную систему, не важно, в виде исходного кода или готового собранного комьюнити блоба (binary linked object – объект двоичной компоновки), с этого момента это – его код и его блоб, и он несет за него ответственность.

Во-вторых, требования к использованию проприетарного и открытого ПО в ландшафте корпоративных ИТ схожи и включают:

Наличие технической поддержки, включая возможность внесения своих исправлений в открытый проект и применения исправлений других разработчиков на своей инфраструктуре.
Разработка уникальных фич.
Выпуск регулярных обновлений.
Четкий жизненный цикл или публичная дорожная карта, то есть обязательства производителя развивать и поддерживать версию продукта какой-то гарантированный срок.
Проверка на безопасность (разработка в концепции SDL (Secure Development Lifecycle).
Сертификация ФСТЭК (важно для критических систем с повышенными требованиями к безопасности).
Совместимость с нужными платформами (процессорные архитектуры и ОС).
Совместимость с нужными приложениями.

В неподдерживаемых open source-продуктах, как правило, это всего нет.

Станислав Сидоров

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

Проблемы с обновлениями и совместимостью: open source-проекты часто быстро развиваются, и новые версии могут содержать значительные изменения, которые способны привести к проблемам совместимости.

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

Неопределенность будущего проекта: open source-проекты могут прекратиться или развиваться в направлении, которое не соответствует нуждам вашей компании.

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

Владислав Билай

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

Алексей Казин

– Отсутствие гарантированной поддержки является одним из недостатков open source-продуктов. В связи с этим возникают следующие проблемы:

Отсутствие ответственности. Техподдержка open source-продуктов обычно несет обязательства только по своей доброй воле, что может привести к несвоевременной или неполной помощи в решении проблемы.
Необходимость самостоятельного решения проблем. Часто пользователи open source-продуктов вынуждены самостоятельно искать решение проблемы в документации, форумах, комьюнити и т.д.
Отсутствие гарантии исправления ошибок. Отсутствие гарантированной поддержки может привести к отсутствию исправления ошибок, которые могут влиять на функциональность продукта.
Необходимость самостоятельного тестирования обновлений. При обновлении open source-продукта могут возникнуть проблемы, которые не затрагивали предыдущую версию продукта, поэтому пользователи должны самостоятельно тестировать новые версии продукта.

Хотя open source-продукты не дают гарантированную поддержку, существуют различные способы получения помощи, такие как форумы, комьюнити, документация и т.д. Кроме того, многие open source-продукты имеют большое сообщество пользователей и разработчиков, которые могут оказать помощь в решении проблемы.

Станислав Мриль

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

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

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

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

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

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

Антон Чураков

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

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

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

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

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

Но для качественной поддержки нужно еще учитывать следующие моменты, например:

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

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

Как правило, в свободном ПО, есть такие моменты, когда документации могут уделять мало времени. А если задавать вопросы – то отвечают люди, которые пользовались или сталкивались с подобными проблемами и сами ответы могут появляться очень долго.

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

Александр Фролов

– Типичные проблемы техподдержки opensource-продуктов могут включать следующее:

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

Вопрос 2. О чем должны договориться «на берегу», до развертывания и эксплуатации решения, компания – разработчик и потенциальный заказчик?

Александр Фролов

– Перед развертыванием и эксплуатацией решения компания-разработчик и потенциальный заказчик должны договориться о следующих аспектах:

Объем и сроки предоставления поддержки.
Уровень гарантированного времени реакции на запросы на поддержку.
Критерии и процедуры оценки качества поддержки.
Механизмы обновления продукта и получения патчей.
Ошибки и проблемы, на которые будет предоставлены бесплатные исправления, а на какие будут предложены платные услуги.

Дмитрий Заруднев

– До этапа развертывания компания-разработчик должна трезво оценить долю использования СПО в своём решении, наличие компетенций для поддержки и сложность используемого СПО.

Далее требуется разделить возможные проблемы на несколько уровней сложности и оценить время для их решения.

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

Максим Шалыгин

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

На начальном этапе необходимо проработать детальное техническое задание, в частности: договориться, требуется ли заказчику первая, вторая или третья линия техподдержки в зависимости от зрелости его ИТ-подразделения; определить уровень услуг (SLA); описать зоны ответственности – за что в работоспособности системы будет отвечать исполнитель и за что заказчик; указать ограничения на версии используемого общесистемного ПО.

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

Алексей Романов

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

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

Вадим Сабашный

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

Сергей Головашов

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

Михаил Назаров

– Необходимо договариваться о сроках поддержки, как будут отрабатываться баг-репорты, как будут проводиться обновления безопасности, и, конечно, как, сколько времени и какими усилиями будет происходить переход на новые версии ПО.

Максим Ткачев

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

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

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

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

Матвей Васильев

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

Владимир Суворов

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

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

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

Таким образом, сотрудничество в рамках проектов с открытым исходным кодом может быть осуществлено с помощью стандартных договоров на разработку ПО, и возможность внесения ценных компонентов в основной проект открывает дополнительные перспективы для расширения функциональности и улучшения open source-решения

Виталий Рыбалка

– На берегу нужно проверить под какой лицензией выпускается open source-продукт – далеко не всегда это укладывается в лицензионную политику компании, которая планирует его использовать.

Второе – кто и в каком объеме осуществляет поддержку, либо получает её. И на каких условиях.

Сергей Марсанов

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

Антон Бондарев

– Продукты и услуги могут быть очень разнообразными и, наверное, до развертывания, можно согласовать только основные принципы взаимодействия, например: иерархию эскалации, наметить контактные лица или группы лиц и назначить «product owner» и так далее. Также необходимо обозначить цели и ожидания и наметить дорожную карту внедрения.

Руслан Белов

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

Заказчику следует до принятия решения о покупке, выяснить из общедоступных источников, как будет обеспечиваться сервисная поддержка: какие сервисные центры, как можно узнать SLA и так далее. Причем получение данной информации не должно превращаться в «интересную и сложную задачу». У серьезных производителей или сервисных центров все необходимое можно найти на сайте. Если этого нет, то, как говориться, обещать можно все что угодно, но если у вендора – это не зафиксировано, то гарантировать, что в итоге вы не получите воздушный замок, никто не будет.

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

Владислав Билай

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

На этапе обсуждения, следует определить:

Объем и уровень поддержки, который будет предоставлен заказчику.
Время реакции на запросы и согласованные сроки предоставления исправлений и обновлений.
Обязанности и ответственность сторон при возникновении проблем и запросов на поддержку.
Процедуры предоставления обновлений и исправлений, а также общение и обратная связь между разработчиком и заказчиком.

Николай Молчанов

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

Роман Карпов

– Самый важный вопрос тут, каким образом будут реализовываться требования к использованию открытого ПО, указанные в первом пункте.

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

Поддержка на коммерческой основе предоставляется в соответствии с дорожной картой техподдержки: доступ к исправлениям ошибок и обновлениям безопасности в течение минимум 8 лет для релизов с долгосрочной поддержкой (LTS), выпуск бинарных файлов одновременно с Oracle Java и OpenJDK для функциональных релизов.

В рамках коммерческого лицензирования осуществляется поддержка специализированных систем, например OpenWebStart (реализация технологии Java Web Start с открытым исходным кодом), и поддержка Java 1.6 и 1.7 (32 и 64 бит для Linux и Windows), OpenJFX (JDK 8, 11, 17).

Артем Каранович

– Необходимо понимать, что Open Source – это решения не для бесплатного пользования. Порой условия использования таких продуктов намного жестче условий в классических вендорских решениях. Например, речь идет об обязательном обнародования всех доработок. На практике мы сталкивались как минимум с десятью видами open source-лицензий (рисунок).

Рисунок. Пример видов и условий лицензий на Open Source для ERP-продуктов

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

В справке должны быть указаны ограничения, которые накладывает на новый продукт его донор. И ответы на вопросы: необходимо ли в последующем открывать код, какие требования есть к удаленному сетевому взаимодействию и другие. Чтобы в будущем избежать неожиданных последствий, этому важно уделять должное внимание, особенно если речь идет о создании коммерческих продуктов.

Алексей Казин

– Перед началом развертывания и эксплуатации продукта на основе открытого исходного кода компания-разработчик и потенциальный заказчик должны договориться о следующих вопросах:

Условия использования продукта
Установка, настройка и интеграция продукта в существующую инфраструктуру заказчика
Обучение пользователей работе с продуктом
Поддержка и обслуживание продукта, включая частоту выпуска обновлений и исправлений ошибок
Управление конфигурацией и изменениями, включая процедуры управления версиями и контроля изменений
Лицензирование продукта и права интеллектуальной собственности
Гарантии и ответственность сторон.

Станислав Мриль

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

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

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

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

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

Виктор Вьюшков

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

Николай Фатнев

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

Также необходимо проговорить ключевые аспекты договора: состав и объем работ, их стоимость, этапы и сроки реализации, чтоб в конечном итоге прийти к единому представлению конечного результата.

Вопрос 3. Что должно быть четко прописано в SLA, чтобы заказчик получал поддержку, соответствующую его бизнес-целям?

Александр Фролов

– В SLA (соглашении об уровне обслуживания) должно быть четко прописано:

Гарантированное время реакции на запросы на поддержку.
Доступность поддержки в течение определенных часов/дней.
Методы связи с технической поддержкой (телефон, электронная почта, онлайн-чат).
Уровень приоритета запросов и сроки решения проблем.
Уровень компенсации, если уровень обслуживания не был соблюден.

Владимир Суворов

– Важно включить следующие аспекты в SLA:

Объем решения и фиксинг багов: определить конкретный объем продукта или услуги, на который будет распространяться поддержка. Также следует указать сроки и процедуры для исправления ошибок (багов).
Сотрудничество с коммьюнити: установить ясные правила по отправке исправлений (патчей) в основную ветку (апстрим) проекта. Это поможет гарантировать, что разработки, внесенные в рамках SLA, будут доступны всем пользователям open source-решения.
Время реакции: установить максимально допустимое время реакции на запросы от заказчика или комментарии разработчиков. Это гарантирует своевременное решение проблем и обеспечивает бесперебойную работу решения.

Виталий Рыбалка

– Да, собственно, что обычно в SLA и прописывается – зоны ответственности, скорость реакции, её объем и стоимость.

Антон Бондарев

– Не могу дать четкого ответа, как и у любого продукта (услуги), параметры SLA должны удовлетворять бизнес-целям компании заказчика и не противоречить производственным процессам компании поставщика.

Сергей Марсанов

– В SLA (договор об уровне обслуживания) должны быть четко прописаны уровни поддержки, которые заказчик получит, включая время ответа на запросы, время восстановления после сбоев и уровень квалификации специалистов подрядчика.

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

Обеим сторонам важно убедиться, что SLA соответствует бизнес-целям заказчика, и что заказчик полностью понимает условия договора.

Руслан Белов

– Есть три основополагающих компонента:

критерии событий с приведенными приоритетами;
сроки и форма реакции на данные события;
форма доступа к инструменту по заведению обращений по поводу инцидента. Это могут быть конкретные телефоны, e-mail, тикет-система и т.п.

Также необходимо обращать внимание на время сервисной поддержки. Допустим у нас есть варианты сервисной поддержки 24/7 и 5/8. При этом 5/8 это по местному времени. Это важно.

Если кто-то предоставляет поддержку 5/8, но по московскому времени, расхождение в графике работы Москвы и регионов может оказаться значительным и в результате заказчик получит помощь не вовремя.

Владислав Билай

– Чтобы заказчик получал поддержку, соответствующую его бизнес-целям, в SLA (Service Level Agreement) должно быть четко прописано:

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

Николай Молчанов

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

Например, заказчики часто указывают, что на решение критического инцидента должно уходить не более четырех часов. Что это означает на практике: происходит сбой, требующий исправления в самом продукте Open Source. Компания, оказывающая услуги поддержки, гарантированно не сможет за такое время обеспечить выпуск пакета исправлений, его тестирование и выпуск в ветку разработки, как и применить это обновление в инфраструктуре заказчика. В результате заказчик вводит в заблуждение сам себя, полагаясь на невыполнимые условия поддержки.

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

Роман Карпов

– Нужно четко прописать все, что касается инцидента (SLA), – порядок действий, временные рамки и ответственность.

Например, в рамках стандартного пакета поддержки наши инженеры предоставляют ответ по запросу в течение 24 часов, 9x5 доступ через портал и email, экстренные патчи, пока не вошедшие в открытый код OpenJDK, квартальные и внеплановые обновления безопасности и патчи, двухчасовую консультацию.

В дополнение к этому в рамках премиум-поддержки клиенты получают 24x7 доступ через портал, email и по телефону, SLA на обновления безопасности – 48 часов, SLA на ответ по запросу – 1 час и выделенного инженера техподдержки.

Алексей Казин

– В SLA должны быть четко определены следующие элементы:

Цели и ожидания заказчика от поддержки
Уровни поддержки, которые предоставляются, их описание и условия
Время отклика на запросы и проблемы, а также способы связи с технической поддержкой
Сроки решения проблем и восстановления сервисов
Обязанности и ответственности заказчика и поставщика услуг
Условия изменения SLA в случае изменения бизнес-потребностей заказчика.

Станислав Мриль

– Составление соглашения об уровне обслуживания (SLA), которое соответствует бизнес-целям заказчика, имеет решающее значение.

Виктор Вьюшков

– В SLA должны быть определены максимальные временные рамки для ответов и разрешения проблем. Оговорены параметры доступности и времени работы поддержки. Особое внимание уделяется исправлению уязвимостей и оперативности реагирования.

Также следует предусмотреть механизмы сбора обратной связи и оценки удовлетворенности клиентов. Желательно дополнительно оговорить сроки получения поддержки через вендора\разработчика продукта

Станислав Сидоров

– В SLA (Service Level Agreement) для поддержки open source-решений следует включить: Уровень доступности, который нужен для вашего бизнеса. Временные рамки для решения проблем и инцидентов. Ответственность за обновления и исправления ошибок. Условия обслуживания и поддержки.

Матвей Васильев

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

Максим Ткачев

– В контексте open source-продуктов рассуждать о классическом понимании SLA некорректно по двум причинам.

Во-первых, SLA, скорее, про реакцию в случае проблемы, чем про время. Такой подход подтверждает недавняя практика с вендорами, которые в случае поломки или аварии не гарантировали время исправления. Более того, в таких ситуациях поиск обходного решения проблемы всегда ложился на плечи интегратора.

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

В данном случае правильнее оперировать новым термином – Service Level Expectation (SLE). В SLE четко прописаны обязательства поддерживающей компании, а при необходимости обращения к разработчику в дело вступают уже сроки ожидания. Такая модель позволяет понять, как и в какие сроки будет решена проблема через обновления/перенастройки или внесены изменения в код.

Тем не менее одного SLE здесь недостаточно. Все-таки залогом уверенности в этом вопросе выступает надежный и проверенный партнер, что становится особенно актуальным в связи с уходом вендоров из России.

Михаил Назаров

– В SLA должны быть прописаны сроки реакции и устранения проблем. Базовые доработки должны быть описаны в деталях и регламентированы по срокам. Отдельным пунктом должны быть регламентированы сроки устранения zero day-уязвимостей. А также необходимо прописывать SLA Write first time (сделано с первого раза без ошибок), чтобы не стать испытательным полигоном для разработчиков.

Вадим Сабашный

– В SLA необходимо прописать не только скорость реакции на инцидент, но и особенности по классификации инцидентов в зависимости от их влияния на бизнес-процессы. Именно от этого стоит отталкиваться при установлении сроков их устранения.

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

Сергей Головашов

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

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

Сама библиотека ITIL в разделе описания процесса управления доступностью приводит следующие метрики оценки качества ИТ-сервиса:

доступность (availability);
производительность (performance);
надежность (reliability);
сопровождаемость (maintainability);
обслуживаемость (serviceability);
безопасность (security).

Однако SLA регламентирует отношения с внешним потребителем, т.е. внутри самой организации. Поэтому требования к качеству сервиса, предписанные внутренним стандартом, обычно выше тех, что указаны в SLA.

Исходя их этого мы делаем вывод, что SLA должен определяться на момент прохождения ПСИ и регламентироваться отдельными внутренними положениями еще до вхождения СПО в промышленную эксплуатацию.

Алексей Романов

– В договоре четко должны быть прописаны следующие пункты:

скорость реакции на входящие задачи и стоимость таких услуг в зависимости от сроков исполнения. Например, если проблема устраняется в течении одного часа – стоимость 3-х, в течении рабочего дня 2-х и в течении нескольких дней х рублей. Заказчик должен понимать какие задачи для него являются первоочередными, а какие могут и подождать;
доступ к ПО, чтобы разработчик приступил к решению задачи, у него должен быть доступ к серверу, где находится ПО;
каналы коммуникации, в этом пункте должно быть прописано как происходит постановка задачи, кто ответственный от заказчика за постановку задачи, кто из специалистов заказчика может отправлять запрос на консультацию;
как происходит приемка работ.

Максим Шалыгин

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

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

Дмитрий Заруднев

– В SLA должен быть четко прописан алгоритм взаимодействия заказчика и исполнителя в случае возникновении проблем. Должны быть указаны все доступные каналы связи, указаны временные рамки осуществления поддержки, время реакции на проблему и на решения, в зависимости от ее сложности. Требуется указать размер штрафа при неисполнении обязательств. Понимание всего процесса поддержки дает заказчику уверенность, что бизнес-процессы не будут нарушены.

Григорий Сизоненко

– В SLA должны быть четко зафиксирован объём и порядок предоставления сервисных услуг. Например, режим поддержки 24/7 или 12/5. Это важно, поскольку объем и сложность услуг напрямую влияют не только на надежность работы ИТ-инфраструктуры заказчика, но и на сумму сервисного контракта.

Николай Фатнев

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

Также в SLA прописывается состав и периодичность проведения регламентных работ, и порядок устранения срочных неполадок.

Вопрос 4. Что в качественной поддержке зависит от разработчиков свободного ПО, а что – от компании-заказчика?

Матвей Васильев

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

Разработчик должен знать свой продукт и уметь оперативно исправлять возникающие проблемы, заказчик должен уметь использовать продукт и понятно объяснять свои проблемы или пожелания.

Николай Фатнев

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

А руководитель проекта должен уметь одинаково корректно донести требования клиентов, выраженные в бизнес-терминах, до всех участников процесса: от тимлида до тестировщика. Тогда достигается желаемый всеми результат.

Антон Бондарев

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

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

Сергей Марсанов

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

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

Виктор Вьюшков

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

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

Руслан Белов

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

А от компании-разработчика зависит, если мы говорим о разработчике решений enterprise-класса, соответствие прописанному SLA.

Николай Молчанов

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

Роман Карпов

– Самое главное тут – знание кода используемого open source-продукта. Разработчик должен хорошо в нем разбираться. Наша команда поддержки сформирована из инженеров-разработчиков OpenJDK, которые знакомы с его структурой на микроуровне и имеют более 25 лет опыта развития Java.

Алексей Казин

– Качественная поддержка свободного ПО может быть обеспечена только при совместных усилиях разработчиков и заказчиков.

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

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

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

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

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

Конечно, разработчики также должны быть заинтересованы в развитии своего ПО и нести ответственность за его качество. Но взаимодействие разработчиков и компаний-заказчиков является ключевым фактором в обеспечении качественной поддержки свободного ПО.

Станислав Сидоров

– Разработчики open source-проекта отвечают за исправление ошибок, обновление программного обеспечения и обеспечение его безопасности.

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

Владислав Билай

– В качественной поддержке свободного ПО зависит от разработчиков предоставление обновлений, исправлений и технической экспертизы по коду, а также поддержки сообщества пользователей.

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

Виталий Рыбалка

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

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

Владимир Суворов

– Качественная поддержка свободного ПО зависит от разделения ролей между разработчиками свободного ПО и компанией-заказчиком или компанией, осуществляющей внедрение. Эти роли отличаются, и каждая из сторон работает в своей зоне ответственности:

Разработчики свободного ПО отвечают, по сути, за:

Оперативное рассмотрение фичей (новых функций), исправление багов и отзывов сообщества. Разработчики занимаются дальнейшей эволюцией и улучшением ПО на основе обратной связи от пользователей.
Поддержка и обновление основной ветки (апстрим) проекта. Это позволяет всем пользователям open source-решения получать последние обновления и улучшения.

Компания-заказчик или компания по внедрению занимаются:

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

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

Максим Ткачев

– Поддержка во многом зависит от разработчиков. Но стоит понимать, что это не конкретные компании, а community, которые могут игнорировать запросы. На стороне заказчика остается эксплуатация продукта согласно рекомендациям и своевременное предоставление данных в случае проблемы.

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

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

Качественная сервисная поддержка свободного ПО упирается в команду с широким спектром компетенций. Мы отчетливо это видим на примере поддержки Zabbix – Open Source-системы мониторинга ИТ-инфраструктуры и ПО. Она гибкая, в ней можно дорабатывать отдельные модули, ты как инженер получаешь независимость от вендора, чей продукт доработать невозможно.

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

Михаил Назаров

– Заказчику нужно не жалеть времени и пройти обучение по системе, поскольку оно значительно упростит взаимодействие. А также четко понимать класс системы и использовать в первую очередь по ее основному назначению.

Вадим Сабашный

– Для ответа на этот вопрос, стоит разделить программное обеспечение с открытым кодом и свободно распространяемый софт. Если коммерческое программное обеспечение распространяется с открытым кодом, то здесь в поддержке нет различия с любым ПО, исходный код которого недоступен.

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

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

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

Алексей Романов

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

От заказчика – возможность правильно оценить критичность задачи и работать согласно договору SLA

Максим Шалыгин

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

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

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

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

Дмитрий Заруднев

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

От заказчика же требуется полное описание проблемы в момент подачи заявки, помощь в организации доступа для сбора и анализа данных и честная оценка важности задачи. Если каждая задача будет ставиться с приоритетом «супер срочно», в конце концов это приведет к снижению качества поддержки. На мой взгляд, от описанных выше действий и зависит качественная поддержка СПО.

Александр Фролов

– Качественная поддержка зависит от разработчиков свободного ПО в следующих аспектах:

Предоставление документации, руководств пользователя и технических решений.
Разработка обновлений и патчей для устранения ошибок и добавления новых возможностей.
Предоставление технической экспертизы и консультаций.
Компания-заказчик также имеет ответственность в:
Четком описании проблемы или запроса на поддержку.
Предоставлении необходимой информации и доступа к системе для решения проблемы.
Участии в процессе тестирования обновлений и патчей перед их внедрением.

Григорий Сизоненко

– Качественная поддержка – это совместный труд заказчика и вендора (или его авторизованных партнеров). Заказчику необходимо соблюдать рекомендованные вендором правила и требования эксплуатации продуктов. Вендор и его авторизованные партнеры должны обладать уровнем квалификации, необходимым для исполнения условий SLA.

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

Весомое преимущество для заказчика – техподдержка сервисной компанией всего стека импортонезависимого ПО как единого целого, в режиме «одного окна». Если сервисная компания одновременно обслуживает и ОС, и совместимое с ней прикладное ПО, исключается знакомая многим проблема «футбола», когда службы техподдержки бесконечно перенаправляют заявку друг другу – не решают проблему, а ищут «виноватого вендора».

Сергей Головашов

– Как мы уже отмечали выше, поддержка СПО заставляет полностью изменить штатный состав технической поддержки. Если раньше достаточно было пары младших инженеров, которые знали свой продукт и занимались только лишь им, то сейчас в штате уже должны находиться как инженеры, так и архитекторы плюс разработчики решения, которые смогут выстроить правильную стратегию решения любой проблемы и закрыть текущие потребности или проблемы. Если данные службы построены правильно, то производство заплаток (hotfix) становится довольно быстрым и рутинным процессом. А уж какие методики управления процессами разработки вы используете: Agile, canban, waterfall – зависит уже от вас, как руководителя.

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

Николай Молчанов

– Мы используем достаточно широкой перечень решений Open Source и закрываем все потребности сопровождения внутренней компетенцией. Важно отметить, что мы не используем решения Open Source для критически значимых бизнес-систем.

Алексей Казин

– В нашей компании мы используем огромное количество open source-решений и все они проходят обязательный этап тестирования и проверки перед началом «боевого» использования.

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

С разработчиками мы в основном контактируем только в отношении российских open source-продуктов, так как зарубежные разработчики неохотно идут на контакт по известным всем причинам.

Сергей Головашов

– Мы строим техническую поддержку согласно требованиям ITIL и регламентируя GE Blue Book. Именно применение лучших практик иностранных коллег позволяет нам организовывать техническую поддержку наших решений на достойном уровне.

Виктор Вьюшков

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

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

Владислав Билай

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

Если возникают проблемы или недовольство, рекомендуется обратиться к разработчикам с четкими запросами и искать ответы в сообществах пользователей.

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

Сергей Марсанов

– Некоторыми решениями удовлетворены, некоторыми нет. Если возникает проблема, обращаемся напрямую к техподдержке разработчика.

Кроме того, иногда приходится писать свою внутреннюю документацию или использовать ресурсы сообщества open source-разработчиков.

Александр Фролов

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

Необходимо правильно сформулировать свои требования и ожидания в отношении продукта и услуги поддержки.
Активно обратиться к компании-разработчику с вопросами, проблемами и предложениями.
Принять участие в работе сообщества пользователей и разработчиков, чтобы получить поддержку и решить проблемы совместно.
Рассмотреть возможность перехода на другое ПО или поиска другого поставщика поддержки, если проблемы не будут решены достаточно быстро и качественно.

Ключевые слова: техподдержка, ПО с открытым исходных кодом, компания-заказчик, компания-разработчик, решения Open Source.

OPEN SOURCE. Техподдержка СПО – какой она должна быть?

OPEN SOURCE
Техподдержка СПО – какой она должна быть?

Представляем участников заочного круглого стола

Вопрос 1. Типичные проблемы техподдержки open source-продуктов?

Вопрос 2. О чем должны договориться «на берегу», до развертывания и эксплуатации решения, компания – разработчик и потенциальный заказчик?

Вопрос 3. Что должно быть четко прописано в SLA, чтобы заказчик получал поддержку, соответствующую его бизнес-целям?

Вопрос 4. Что в качественной поддержке зависит от разработчиков свободного ПО, а что – от компании-заказчика?

OPEN SOURCE. Техподдержка СПО – какой она должна быть?

OPEN SOURCEТехподдержка СПО – какой она должна быть?

Представляем участников заочного круглого стола

Вопрос 1. Типичные проблемы техподдержки open source-продуктов?

Вопрос 2. О чем должны договориться «на берегу», до развертывания и эксплуатации решения, компания – разработчик и потенциальный заказчик?

Вопрос 3. Что должно быть четко прописано в SLA, чтобы заказчик получал поддержку, соответствующую его бизнес-целям?

Вопрос 4. Что в качественной поддержке зависит от разработчиков свободного ПО, а что – от компании-заказчика?

OPEN SOURCE
Техподдержка СПО – какой она должна быть?