|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Вопрос 1. Типичные проблемы техподдержки open source-продуктов?
– Главная проблема поддержки open source (и не только!) продуктов связана с растущим дефицитом квалифицированных кадров, и, как следствие, их высокой стоимостью. В последние годы она усугубилась усилившимся оттоком опытных специалистов за рубеж. В этих условиях компании вынуждены открывать корпоративные университеты и самостоятельно растить кадровый резерв. А чтоб готовый специалист не ушел к конкурентам, ему нужно предложить достойную мотивацию, понятную траекторию развития, интересные задачи и проекты. Другой путь, который выбрали многие наши заказчики – передача обслуживания ИТ на аутсорс специализированной компании, способной разом закрыть все потребности бизнеса и гарантировать качество сервиса в соответствии с SLA.
– Техподдержка программных продуктов на основе свободного ПО во многом совпадает с техподдержкой проприетарных программ. Речь идет о вендорских свободных разработках. Именно такие программы имеет смысл использовать и корпоративным заказчикам, и физическим лицам. Вендорские программные продукты обладают долгим жизненным циклом – то есть планомерно развиваются на протяжении долгих лет, они включены в Единый реестр российского ПО. Компания-разработчик таких программных продуктов берет на себя ответственность за их надежную работу у заказчиков, поэтому выстраивает систему техподдержки. Как правило, услуги первой и второй линии поддержки оказывают партнеры вендора, а наиболее сложные задачи, связанные с доработкой кода, решают специалисты разработчика. Частным лицам ряд разработчиков предоставляет свои программные продукты бесплатно – их можно скачать с сайта вендора и отдельно за умеренную плату приобрести услуги техподдержки.
– На мой взгляд, наибольшей проблемой поддержки СПО является отсутствие у команды разработки полного понимания логики и архитектуры используемого СПО. Зачастую разработчики изучают код open source-продуктов лишь поверхностно и только в части того функционала, который им требуется. Отсюда сложность поддержки при возникновении проблем. Требуется больше времени на поиск решения, чем если бы это был собственный продукт.
– Компания «Диджитал Дизайн» разрабатывает решения как с использованием проприетарного ПО, так и программного обеспечения с открытым кодом. В части оказания техподдержки заказчикам можно выделить следующие проблемы: многомодульность ПО с высоким уровнем кастомизации; подбор, подготовку и удержание квалифицированных ресурсов; выстраивание коммуникации с заказчиком; составление детального и понятного технического задания. В случаях, когда в решениях использованы СПО-продукты, дополнительную сложность при оказании технической поддержки создает невозможность привлечения вендора. В части решения проблемы развития и мотивации инженеров мы постоянно ведем подготовку квалифицированных ресурсов, учитываем готовность специалистов к работе в режиме многозадачности, а также, с целью предупреждения профессионального выгорания, осуществляем их ротацию между проектами и перевод в смежные подразделения (внедрение, разработка, аналитика), проводим тимбилдинги, обучение, оплачиваем участие в спортивных мероприятиях. Для выстраивания простой и прозрачной коммуникации важно быстро доводить до специалиста техподдержки суть запроса и предоставлять необходимые материалы – скриншоты, видео и т.д. Решить эту проблему позволяет использование чатов и Telegram-каналов. В некоторых случаях мы ведем для одного проекта до пяти чатов, имеющих разную направленность, для общения с ИТ-подразделением заказчика, подрядчиком, внутренней коммуникации, уточнения требований функционального заказчика и т.д. Если диалог в Telegram-каналах не приводит к результату или пониманию результата – проводим оперативные митапы (летучки) с заказчиком.
– Если у разработчика отлажены процессы техподдержки, а именно автоматизированная работа над входящими заявками от клиента service desk, то никаких проблем с техподдержкой open source-продуктов не должно возникать. Кроме того, у многих компаний-разработчиков есть команда техподдержки, а в клиентском договоре прописаны все условия для качественной техподдержки продукта: скорость реакции, доступы и др. В этом случае компания-разработчик будет надежной компанией техподдержки.
– Основная проблема – отсутствие коммерческой поддержки от вендора для большинства пользователей. Крупный потребитель со значительным бюджетом еще может рассчитывать на установление тесных связей с разработчиком и влиять на процесс разработки, но для основной массы пользователей решение поставляется «как есть», и возможные инциденты при внедрении и эксплуатации придется решать самостоятельно. Еще одна типичная проблема – низкое качество документации на ПО – она не всегда вовремя обновляется, имеет недостаточную детализацию, содержит мало примеров. Зачастую это компенсируется большим комьюнити, но требует высокой подготовки технических специалистов на стороне пользователей продукта. Также и качество ИТ-продукта для разных модулей и функциональности может значительно отличаться – это зависит от того, кто именно их разрабатывал, и какой функционал востребован.
– Типичные проблемы, с которыми техническая поддержка открытых программных продуктов (open source), может столкнуться:
Это только некоторые из типичных проблем, с которыми техподдержка open source-продуктов может столкнуться. Конкретные проблемы могут варьироваться в зависимости от конкретного проекта и его сообщества
– Мы считаем, что самые распространенные проблемы, с которыми приходится сталкиваться, следующие:
При этом любая организация должна на момент перехода на СПО отдавать себе отчет в том, что ее структура технической поддержки должна быть перестроена, в ней должны присутствовать не просто несколько эникейщиков, но и архитекторы 4-го уровня, DevOps и DevSecOps-инженеры. Экосистема программного обеспечения с открытым исходным кодом отличается от мира проприетарного программного обеспечения, и организациям необходимо изучить новые способы управления и поддержки этих решений. Некоторые вопросы, которые следует учитывать: открытость и диффузный характер разработки СПО; то, насколько хорошо проприетарное программное обеспечение работает с программным обеспечением с открытым исходным кодом; лицензионные ограничения обоих продуктов.
– Поддержка open source-продуктов существенно отличается от поддержки привычных проприетарных enterprise-продуктов. Например, мы не можем рассчитывать на продуктивную коммуникацию с создателем решения. Часто разработчики не в состоянии протестировать продукт на том же или похожем «железе», на котором работает заказчик. В свою очередь, подготовка инженера поддержки осложняется отсутствием учебных материалов и основывается только на документации. Разработчики описывают не все случаи, поэтому многие ограничения приходится узнавать опытным путем. При возникновении проблем инженерам поддержки часто приходится заглядывать в код, что подразумевает наличие соответствующих компетенций. В случае с 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 – объект двоичной компоновки), с этого момента это – его код и его блоб, и он несет за него ответственность. Во-вторых, требования к использованию проприетарного и открытого ПО в ландшафте корпоративных ИТ схожи и включают:
В неподдерживаемых open source-продуктах, как правило, это всего нет.
– Операционная поддержка открытых исходников может быть сложной задачей, поскольку она часто включает в себя самостоятельное обслуживание и поддержку сообщества, вместо формальной поддержки от коммерческого поставщика. Вот некоторые общие проблемы. Проблемы с обновлениями и совместимостью: open source-проекты часто быстро развиваются, и новые версии могут содержать значительные изменения, которые способны привести к проблемам совместимости. Отсутствие официальной поддержки: open source-проекты часто поддерживаются сообществом разработчиков, и, хотя это может быть полезным источником помощи, оно не может гарантировать быстрый ответ или решение проблем. Неопределенность будущего проекта: open source-проекты могут прекратиться или развиваться в направлении, которое не соответствует нуждам вашей компании. Чтобы гарантировать поддержку, перед развертыванием и эксплуатацией решения необходимо убедиться, что: разработчики проекта активны и отзывчивы. Есть сильное и активное сообщество, которое может предоставить поддержку и помощь. Проект стабилен и его будущее предсказуемо.
– Типичные проблемы техподдержки open source-продуктов могут быть связаны с неясной или недостаточной документацией, отсутствием явного ответственного за поддержку лица или команды, а также возникающими сложностями совместимости или безопасности при интеграции и использовании продукта. Открытость и доступность исходного кода могут привести к тому, что ответственность за техподдержку может лежать на сообществе пользователей, что иногда способно затруднить получение быстрого и качественного отклика на запросы и проблемы.
– Отсутствие гарантированной поддержки является одним из недостатков open source-продуктов. В связи с этим возникают следующие проблемы:
Хотя open source-продукты не дают гарантированную поддержку, существуют различные способы получения помощи, такие как форумы, комьюнити, документация и т.д. Кроме того, многие open source-продукты имеют большое сообщество пользователей и разработчиков, которые могут оказать помощь в решении проблемы.
– Программное обеспечение с открытым кодом, несмотря на свои мощь и гибкость, имеет уникальные проблемы, связанные с технической поддержкой. Одной из основных проблем является зависимость от поддержки сообщества. Несмотря на то, что сообщество разработчиков ПО с открытым исходным кодом часто является активным и компетентным, качество и доступность поддержки могут сильно различаться. Это связано с тем, что поддержка обычно осуществляется добровольцами, которые не всегда могут быть доступны или обладать специальными знаниями, необходимыми для решения более сложных задач. Другой распространенной проблемой является качество документации. В идеальном мире программное обеспечение с открытым исходным кодом должно поставляться с полной и актуальной документацией. Однако это не всегда так. Документация может быть неполной, устаревшей или вообще отсутствовать, что значительно затрудняет поиск и устранение неисправностей. Кроме того, может отсутствовать стандартизированная практика. Это означает, что разные разработчики могут решать схожие проблемы по-разному, что приводит к несоответствиям и путанице. Наконец, могут возникнуть проблемы, связанные с интеграцией открытого ПО с проприетарными системами. Выявление ошибок и проблем с производительностью в сложных программных стеках, включающих как открытые, так и проприетарные компоненты, может быть затруднено. Это лишь некоторые из проблем. Однако важно отметить, что, несмотря на эти проблемы, преимущества использования ПО с открытым исходным кодом часто перевешивают их, особенно если у вас есть надежная стратегия управления этими проблемами.
– По своему опыту в роли пользователя и разработчика хочу отметить следующие проблемы: плохая документация, продукт в какой-то момент может перестать обновляться, просто потому что так решил разработчик, который начинал этот проект. Конечно, его развитием могут заняться другие разработчики, но надо понимать, что для них это может быть не основным видом деятельности и будут дорабатывать нерегулярно. Долгая обратная связь по заданным вопросам и ошибкам, найденным в процессе пользования. Поэтому перед тем, как начать пользоваться продуктом в облаке, либо устанавливать его на свой сервер, стоит уточнить следующие моменты:
В зависимости от самой компании этот список можно дополнять еще какими-то пунктами. Основной смысл в том, что происходит процесс управления ожиданиями клиента. И появляется понимание, что мы получим, в какое время и в какую стоимость. Но для качественной поддержки нужно еще учитывать следующие моменты, например:
В своей практике было ПО, где техподдержкой остались довольны, в другом случае остались недовольны. В первую очередь смотрим на наличие документации и как она оформлена, насколько она полная. Это на самом деле хороший показатель, чтобы сделать определенные выводы. Если есть демоверсия продукта, то через доступные каналы техподдержки задаем вопросы по функционалу и смотрим в данном случае на скорость ответа и насколько информация была полезной. Как правило, в свободном ПО, есть такие моменты, когда документации могут уделять мало времени. А если задавать вопросы – то отвечают люди, которые пользовались или сталкивались с подобными проблемами и сами ответы могут появляться очень долго. Конечно, в связи с тем, что у нас есть компетенции в самой разработке, мы можем посмотреть исходный код, который предоставляется. И если ПО написано на платформах и языках, в которых у нас есть компетенции – мы готовы потратить время на то, чтобы изучить, как работает функционал изнутри. В случае если такое не удается сделать, надо искать другое решение.
– Типичные проблемы техподдержки opensource-продуктов могут включать следующее:
– Перед развертыванием и эксплуатацией решения компания-разработчик и потенциальный заказчик должны договориться о следующих аспектах:
– До этапа развертывания компания-разработчик должна трезво оценить долю использования СПО в своём решении, наличие компетенций для поддержки и сложность используемого СПО. Далее требуется разделить возможные проблемы на несколько уровней сложности и оценить время для их решения. Последний этап – это фиксация данных оценок с заказчиком на документальном уровне. Важно, чтобы у каждой стороны было четкое понимание требуемого времени на решение каждого кейса.
– Важно разделять запросы, которые исполнитель обязан решить в рамках гарантийного обслуживания (обязательства по договору внедрения), и запросы непосредственно в техническую поддержку: инциденты, связанные с ошибочным поведением системы, запросы на обслуживание (настройка системы, выгрузка данных и т.д.), запросы на изменение (задачи, связанные с развитием системы), консультации. На начальном этапе необходимо проработать детальное техническое задание, в частности: договориться, требуется ли заказчику первая, вторая или третья линия техподдержки в зависимости от зрелости его ИТ-подразделения; определить уровень услуг (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-лицензий (рисунок).
Так, с учетом возможных ограничений компания-разработчик должна предоставить исчерпывающую справку на все части, взятые из открытых источников. Например, речь может идти об авторском праве на продукт, который создается на базе исходного кода. В частности, необходимы документы на возможность заключения коммерческого договора с третьими лицами по продаже лицензий, а также на возможность патентования доработанного решения. В справке должны быть указаны ограничения, которые накладывает на новый продукт его донор. И ответы на вопросы: необходимо ли в последующем открывать код, какие требования есть к удаленному сетевому взаимодействию и другие. Чтобы в будущем избежать неожиданных последствий, этому важно уделять должное внимание, особенно если речь идет о создании коммерческих продуктов.
– Перед началом развертывания и эксплуатации продукта на основе открытого исходного кода компания-разработчик и потенциальный заказчик должны договориться о следующих вопросах:
– Прежде чем приступить к развертыванию и эксплуатации решения с открытым исходным кодом, разработчику и потенциальному заказчику необходимо согласовать несколько ключевых моментов. Во-первых, необходимо иметь общее представление о возможностях и ограничениях программного обеспечения. Это включает в себя четкое представление о том, что программа может делать, чего она не может делать, и как она вписывается в существующую технологическую экосистему заказчика. Во-вторых, обе стороны должны прийти к взаимному согласию относительно уровня технической экспертизы, необходимой для эффективного использования и сопровождения программного обеспечения. Программное обеспечение с открытым исходным кодом часто требует более высокого уровня технической квалификации, и важно, чтобы заказчик знал об этом заранее. В-третьих, необходимо четко определить процесс информирования и решения проблем. Это включает в себя понимание того, как сообщать о проблемах, каково ожидаемое время реагирования, как будут определяться приоритеты и решаться проблемы. Наконец, необходимо согласовать условия обновления и модернизации программного обеспечения. Это включает в себя понимание того, как часто будут выходить обновления, как они будут реализовываться и каков будет процесс перехода на новые версии программного обеспечения. Согласование этих моментов до начала развертывания позволит разработчику и заказчику обеспечить бесперебойную работу решения и повысить эффективность сотрудничества.
– Необходимо чётко определить объем услуг и ответственность каждой стороны, глубину ответственности и объёмы покрытия возможного ущерба. Поставить вопросы документации и обучения, чтобы обеспечить совместное понимание решения. Оговорить время ответа на запросы и доступность поддержки. Согласовать обновления и патчи, а также соблюдение лицензий на ПО.
– Прежде всего, сторонам таких взаимоотношений необходимо детально обсудить и закрепить «на бумаге» бизнес-, функциональные и технологические требования к будущему решению. Это поможет избежать множества взаимных недопониманий и претензий в процессе его разработки и внедрения. Также необходимо проговорить ключевые аспекты договора: состав и объем работ, их стоимость, этапы и сроки реализации, чтоб в конечном итоге прийти к единому представлению конечного результата.
– В SLA (соглашении об уровне обслуживания) должно быть четко прописано:
– Важно включить следующие аспекты в SLA:
– Да, собственно, что обычно в SLA и прописывается – зоны ответственности, скорость реакции, её объем и стоимость.
– Не могу дать четкого ответа, как и у любого продукта (услуги), параметры SLA должны удовлетворять бизнес-целям компании заказчика и не противоречить производственным процессам компании поставщика.
– В SLA (договор об уровне обслуживания) должны быть четко прописаны уровни поддержки, которые заказчик получит, включая время ответа на запросы, время восстановления после сбоев и уровень квалификации специалистов подрядчика. Также должны быть установлены метрики, по которым будет измеряться качество предоставленной услуги, процедуры по управлению рисками и изменениями в рамках поддержки, формат ответственности подрядчика в случае несоблюдения условий договора. Обеим сторонам важно убедиться, что SLA соответствует бизнес-целям заказчика, и что заказчик полностью понимает условия договора.
– Есть три основополагающих компонента:
Также необходимо обращать внимание на время сервисной поддержки. Допустим у нас есть варианты сервисной поддержки 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 (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 в разделе описания процесса управления доступностью приводит следующие метрики оценки качества ИТ-сервиса:
Однако SLA регламентирует отношения с внешним потребителем, т.е. внутри самой организации. Поэтому требования к качеству сервиса, предписанные внутренним стандартом, обычно выше тех, что указаны в SLA. Исходя их этого мы делаем вывод, что SLA должен определяться на момент прохождения ПСИ и регламентироваться отдельными внутренними положениями еще до вхождения СПО в промышленную эксплуатацию.
– В договоре четко должны быть прописаны следующие пункты:
– В SLA должен быть зафиксирован уровень проблем, которые будет решать техподдержка. Необходимо определить SLA-реакции и SLA-решения, с разделением по типу запросов и их приоритетности. Таким образом, обращение с целью получения консультации будет иметь низкий приоритет с большим временем реагирования, а время реакции и решения на аварию, когда ПО или один из основных модулей системы не работает, или критичная проблема затронула более 50% пользователей, будут минимальными.
– В SLA должен быть четко прописан алгоритм взаимодействия заказчика и исполнителя в случае возникновении проблем. Должны быть указаны все доступные каналы связи, указаны временные рамки осуществления поддержки, время реакции на проблему и на решения, в зависимости от ее сложности. Требуется указать размер штрафа при неисполнении обязательств. Понимание всего процесса поддержки дает заказчику уверенность, что бизнес-процессы не будут нарушены.
– В SLA должны быть четко зафиксирован объём и порядок предоставления сервисных услуг. Например, режим поддержки 24/7 или 12/5. Это важно, поскольку объем и сложность услуг напрямую влияют не только на надежность работы ИТ-инфраструктуры заказчика, но и на сумму сервисного контракта.
– Для соответствия SLA задачам заказчика, ему необходимо совместно с сервисным партнером определить предельно приемлемое для бизнеса время простоя различных ИТ-систем и составить оптимальные сценарии устранения возможных инцидентов. Обычно они включают описание последовательности вовлечения в работу различных уровней техподдержки, время реагирования инженеров первого уровня и эскалирования заявок при невозможности их закрытия. Также в SLA прописывается состав и периодичность проведения регламентных работ, и порядок устранения срочных неполадок.
– Умение прислушиваться друг к другу и компетенции в используемых решениях. Может быть хороший заказчик, может быть отличный исполнитель, но все же поддержка это про помощь и тут главное, чтобы обе стороны говорили на одном языке и понимали с чем они имеют дело. Разработчик должен знать свой продукт и уметь оперативно исправлять возникающие проблемы, заказчик должен уметь использовать продукт и понятно объяснять свои проблемы или пожелания.
– Я бы не стал в данном контексте разделять эти стороны, ибо качество поддержки в конечном счете зависит от того, насколько между ними выстроена коммуникация и взаимопонимание. Для этого важно, чтоб заказчик четко понимал, какой конечный результат он хочет получить от подрядчика и мог его сформулировать. А руководитель проекта должен уметь одинаково корректно донести требования клиентов, выраженные в бизнес-терминах, до всех участников процесса: от тимлида до тестировщика. Тогда достигается желаемый всеми результат.
– От компании-поставщика зависят технические характеристики, уровень техподдержки и документации решения. От компании-заказчика зависит, насколько эффективно решение будет способствовать развитию бизнес-целей компании. Оптимальный вариант для достаточно крупных компаний заказчиков, – иметь у себя подразделение, которое отвечает за внедрение и эксплуатацию решения и взаимодействует с компанией поставщиком.
– В поддержке от разработчика свободного ПО зависят наличие и качество документации, наличие и качество тестов, а также сроки исправления ошибок и выпуска обновлений. От компании-заказчика зависят уровень взаимодействия со специалистами разработчика, включая предоставление детальной информации об ошибках, тестирование новых версий и обратная связь по качеству поддержки.
– Разработчики свободного ПО должны обеспечивать актуальность документации, оперативные исправления ошибок и обновления. Также важно участие в сообществе и обратная связь с пользователями. От компании-заказчика зависят предоставление доступа к релевантным данным, а также обучение персонала. Клиенты могут способствовать улучшению продукта через активное участие и предоставление фидбэков.
– От компании-заказчика зависит подготовка своего персонала к реакции на инциденты. Мы столкнулись на собственном опыте, что сертификаты и SLA не доводятся до службы эксплуатации заказчика. И, соответственно, не проводится обучение по действиям специалиста службы при возникновении инцидента: какие шаги должны предприниматься, куда заводить тикеты и т.п. Получается, когда происходит инцидент, время тратится не на решение проблемы, а на выяснение, как завести тикет. А от компании-разработчика зависит, если мы говорим о разработчике решений enterprise-класса, соответствие прописанному SLA.
– От заказчика прежде всего зависит умение взвешенно оценивать уровень требований к сопровождению и соответствие компетенции самого заказчика, разработчика и сторонних компаний заданным уровням. От разработчика зависит выбор зрелой технологической платформы Open Source и развитие экспертизы своих специалистов.
– Самое главное тут – знание кода используемого open source-продукта. Разработчик должен хорошо в нем разбираться. Наша команда поддержки сформирована из инженеров-разработчиков OpenJDK, которые знакомы с его структурой на микроуровне и имеют более 25 лет опыта развития Java.
– Качественная поддержка свободного ПО может быть обеспечена только при совместных усилиях разработчиков и заказчиков. От разработчиков зависят предоставление необходимых инструментов и средств для решения возникающих проблем, а также постоянное обновление и улучшение своего ПО с учетом потребностей пользователей. Однако компания-заказчик также играет важную роль в качественной поддержке, поскольку она может предоставлять разработчикам информацию о проблемах, с которыми сталкиваются пользователи, а также финансовые средства для улучшения ПО и решения этих проблем. Например, разработчики могут предоставить документацию, обучающие материалы, форумы и системы технической поддержки для своего ПО, чтобы помочь пользователям решать возникающие проблемы. Они также могут регулярно выпускать обновления и исправления ошибок, чтобы обеспечить бесперебойную работу ПО. Однако компания-заказчик, как правило, лучше знает, как используется ПО и какие проблемы могут возникнуть при его использовании. Поэтому важно, чтобы компания-заказчик предоставляла обратную связь разработчикам, сообщая о проблемах, с которыми сталкиваются пользователи, и предлагала улучшения ПО. Кроме того, компания-заказчик может финансировать разработку новых функций и улучшений. Это позволит разработчикам уделять больше внимания ПО и обеспечивать его дальнейшее развитие. Конечно, разработчики также должны быть заинтересованы в развитии своего ПО и нести ответственность за его качество. Но взаимодействие разработчиков и компаний-заказчиков является ключевым фактором в обеспечении качественной поддержки свободного ПО.
– Разработчики open source-проекта отвечают за исправление ошибок, обновление программного обеспечения и обеспечение его безопасности. С другой стороны, компания-заказчик отвечает за внедрение и использование программного обеспечения в соответствии с его бизнес-целями.
– В качественной поддержке свободного ПО зависит от разработчиков предоставление обновлений, исправлений и технической экспертизы по коду, а также поддержки сообщества пользователей. Со своей стороны, компания-заказчик отвечает за интеграцию, настройку и адаптацию решения под свои конкретные бизнес-потребности, а также предоставляет детальную информацию и контекст для решения проблем.
– От разработчика зависит многое – желание слышать обратную связь, учитывать её при разработке продукта. Важнейшую роль играет скорость реакции на обнаруженные ошибки и время на их исправление. От компании-заказчика – нужно четко и вовремя давать обратную связь в том формате, который разработчику максимально комфортен и понятен. Например, подробно описать ошибку и переслать всю техническую информацию.
– Качественная поддержка свободного ПО зависит от разделения ролей между разработчиками свободного ПО и компанией-заказчиком или компанией, осуществляющей внедрение. Эти роли отличаются, и каждая из сторон работает в своей зоне ответственности: Разработчики свободного ПО отвечают, по сути, за:
Компания-заказчик или компания по внедрению занимаются:
Таким образом, разработчики свободного ПО отвечают за активное обслуживание и развитие ПО, основываясь на обратной связи из сообщества, в то время как компания-заказчик или компания по внедрению играют важную роль в обеспечении сотрудничества, отправке важных изменений в сообщество и обратной интеграции обновлений. Это симбиотическое партнерство способствует развитию качественного и инновационного свободного ПО.
– Поддержка во многом зависит от разработчиков. Но стоит понимать, что это не конкретные компании, а community, которые могут игнорировать запросы. На стороне заказчика остается эксплуатация продукта согласно рекомендациям и своевременное предоставление данных в случае проблемы. Ни разработчик, ни заказчик тестированием решения не занимаются. В этом «уязвимом» месте сильно спасает аутсорсинг: профильные специалисты могут проверить на совместимость решение с уже имеющимися продуктами в окружении заказчика. Если рассуждать об открытом софте с позиции интегратора, то качественная поддержка напрямую зависит от нескольких факторов: компетентности инженера, опыта внедрения open source-продуктов в эксплуатацию и желания разбираться с проблемой. Формальный подход, при котором за спиной есть вендор как некая страховка, здесь не работает. Качественная сервисная поддержка свободного ПО упирается в команду с широким спектром компетенций. Мы отчетливо это видим на примере поддержки Zabbix – Open Source-системы мониторинга ИТ-инфраструктуры и ПО. Она гибкая, в ней можно дорабатывать отдельные модули, ты как инженер получаешь независимость от вендора, чей продукт доработать невозможно. Заказчик тоже более автономен: данные хранятся внутри компании плюс отсутствуют риски ухода вендора, роста цен и т. д. При этом в обслуживании Zabbix, как и другие open source-системы, требует большего вовлечения и компетенций.
– Заказчику нужно не жалеть времени и пройти обучение по системе, поскольку оно значительно упростит взаимодействие. А также четко понимать класс системы и использовать в первую очередь по ее основному назначению.
– Для ответа на этот вопрос, стоит разделить программное обеспечение с открытым кодом и свободно распространяемый софт. Если коммерческое программное обеспечение распространяется с открытым кодом, то здесь в поддержке нет различия с любым ПО, исходный код которого недоступен. В ситуации со свободным ПО очень часто присутствует коммерческая компания, которая берет на себя все задачи по его сопровождению и обслуживанию, именно от нее зависит качество поддержки. Если же мы говорим о прямой связи пользователя с разработчиком свободного ПО, то компания-разработчик может консультировать и отвечать на вопросы, но может и не делать этого – тогда основная надежда на собственные силы и помощь комьюнити. Такие внедрения происходят под собственную ответственность. В идеальной модели взаимодействия с заказчиком разработчик ПО предоставляет качественную документацию, план по реализации новой функциональности, возможность консультаций, оперативную проверку и внедрение в релиз исправлений, предложенных пользователями. Компания-интегратор выполняет всё обслуживание, доработку и обеспечивает сообщение об ошибках с их исправлениями (патчами).
– От разработчика – подробно рассказать заказчику об услугах, оказываемых компанией в рамках техподдержки продукта, настроить у себя service desk (автоматизированную работу над входящими заявками) и, конечно, у компании должна быть команда, оказывающая техподдержку От заказчика – возможность правильно оценить критичность задачи и работать согласно договору SLA
– Со стороны разработчика во главе угла стоят люди. Квалификация и мотивированность команды является основным условием оказания качественной техподдержки. Также разработчику необходимо выстроить взаимодействие между командами смежных подразделений. Заказчику важно иметь единую точку входа, одно контактное лицо для направления запросов, за которым на стороне исполнителя будет налажена коммуникация между всеми вовлеченными специалистами: аналитиками, инженерами внедрения, специалистами техподдержки, отделом разработки, коммерческой дирекцией. Заказчику необходимо быть готовым вести открытый диалог с разработчиком, осуществляющим техническую поддержку, и уделять внимание качественной постановке задач и предоставлению максимально полной информации, материалов для их анализа при разборе проблемы. Не менее важны такие факторы, как детализированное техническое задание и тщательное тестирование внедряемых решений, которое поможет предотвратить потенциальные проблемы до момента внедрения изменений у заказчика, а также ведение исполнителем базы знаний, что позволяет быстрее реагировать на запросы, используя опыт других проектов, а также знания более опытных и квалифицированных специалистов.
– В качественной поддержки от разработчиков требуется понятная обратная связь. Нужно информировать заказчика об этапах решения проблемы и, главное, сроках. В случае задержки в решении, сразу объяснять причину этой задержки и озвучивать сколько дополнительного времени требуется. От заказчика же требуется полное описание проблемы в момент подачи заявки, помощь в организации доступа для сбора и анализа данных и честная оценка важности задачи. Если каждая задача будет ставиться с приоритетом «супер срочно», в конце концов это приведет к снижению качества поддержки. На мой взгляд, от описанных выше действий и зависит качественная поддержка СПО.
– Качественная поддержка зависит от разработчиков свободного ПО в следующих аспектах:
– Качественная поддержка – это совместный труд заказчика и вендора (или его авторизованных партнеров). Заказчику необходимо соблюдать рекомендованные вендором правила и требования эксплуатации продуктов. Вендор и его авторизованные партнеры должны обладать уровнем квалификации, необходимым для исполнения условий SLA. Очень важно, чтобы вендор создал и поддерживал систему получения обратной связи от заказчика. Информация о проблемах, с которыми сталкивается заказчик в ходе эксплуатации программного продукта, помогает вендору его совершенствовать. Весомое преимущество для заказчика – техподдержка сервисной компанией всего стека импортонезависимого ПО как единого целого, в режиме «одного окна». Если сервисная компания одновременно обслуживает и ОС, и совместимое с ней прикладное ПО, исключается знакомая многим проблема «футбола», когда службы техподдержки бесконечно перенаправляют заявку друг другу – не решают проблему, а ищут «виноватого вендора».
– Как мы уже отмечали выше, поддержка СПО заставляет полностью изменить штатный состав технической поддержки. Если раньше достаточно было пары младших инженеров, которые знали свой продукт и занимались только лишь им, то сейчас в штате уже должны находиться как инженеры, так и архитекторы плюс разработчики решения, которые смогут выстроить правильную стратегию решения любой проблемы и закрыть текущие потребности или проблемы. Если данные службы построены правильно, то производство заплаток (hotfix) становится довольно быстрым и рутинным процессом. А уж какие методики управления процессами разработки вы используете: Agile, canban, waterfall – зависит уже от вас, как руководителя.
– Мы используем достаточно широкой перечень решений Open Source и закрываем все потребности сопровождения внутренней компетенцией. Важно отметить, что мы не используем решения Open Source для критически значимых бизнес-систем.
– В нашей компании мы используем огромное количество open source-решений и все они проходят обязательный этап тестирования и проверки перед началом «боевого» использования. А что касается техподдержки, то мы стараемся решать возникающие проблемы собственными силами и с помощью официальной документации, также у нас есть сильные центры компетенций, и участники этих ЦК также привлекаются для решения возникающих проблем. С разработчиками мы в основном контактируем только в отношении российских open source-продуктов, так как зарубежные разработчики неохотно идут на контакт по известным всем причинам.
– Мы строим техническую поддержку согласно требованиям ITIL и регламентируя GE Blue Book. Именно применение лучших практик иностранных коллег позволяет нам организовывать техническую поддержку наших решений на достойном уровне.
– Мы стремимся удовлетворить ожидания заказчиков, но иногда могут возникать некоторые несоответствия. При неудовлетворительном опыте, мы обращаемся к компании-разработчику с запросами на улучшение поддержки и обратной связи. Важно также активно участвовать в сообществе и обмениваться опытом с другими пользователями. При необходимости, рассматриваем возможность сотрудничества с сторонними поставщиками для дополнительной поддержки и консультаций.
– Удовлетворенность качеством выбранного ПО, его техподдержкой, официальной документацией и обратной связью с компанией-разработчиком зависит от того, насколько решение соответствует конкретным потребностям заказчика. Если возникают проблемы или недовольство, рекомендуется обратиться к разработчикам с четкими запросами и искать ответы в сообществах пользователей. При необходимости, можно рассмотреть возможность перехода на другое решение или обсудить улучшение техподдержки с компанией-разработчиком для наилучшего соответствия бизнес-целям заказчика.
– Некоторыми решениями удовлетворены, некоторыми нет. Если возникает проблема, обращаемся напрямую к техподдержке разработчика. Кроме того, иногда приходится писать свою внутреннюю документацию или использовать ресурсы сообщества open source-разработчиков.
– Если заказчик не удовлетворен качеством выбранного ПО, его техподдержкой, официальной документацией или обратной связью с компанией-разработчиком, следующие проблемы могут быть решены с помощью следующих мер:
Ключевые слова: техподдержка, ПО с открытым исходных кодом, компания-заказчик, компания-разработчик, решения Open Source.
Подпишитесь на журнал Комментарии отсутствуют
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|