Гарантийное обслуживание СУБД Postgres Pro

• Глоссарий
• Приём обращений
• Обязанности Заказчика и Исполнителя
• Ограничения ответственности
• Приложение №1: Поддерживаемое ПО
• Приложение №2: Гарантийное обслуживание
• Приложение №3: Порядок предоставления Услуг на Портале техподдержки

Глоссарий

БД – база данных.

База знаний — раздел с полезной информацией на Портале техподдержки.

Горячая линия — единая точка входа для обращений Клиента за Услугами Гарантийного обслуживания, работает в режиме 24x7 (круглосуточно).

Заказчик – юридическое лицо или его представитель, имеющее право на получение Услуг по Гарантийному обслуживанию у Компании.

Заявка – оформленное в соответствии с определенным порядком обращение Заказчика на предоставление Услуг Гарантийного обслуживания.

Информационная система (ИС) – программно-аппаратный комплекс, выполняющий законченные функции и использующийся в деятельности компании Заказчика.

Инцидент — нештатное поведение ИС, обычно приводящее к ухудшению ее работы.

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

Клиент Гарантийного обслуживания (Клиент) – лицо, обратившееся за гарантийным обслуживанием.

Классы систем:

• Критически важная система (КВС, Mission Critical Systems, MCS) – критически важная ИС Заказчика, работающая в режиме 24х7 (круглосуточно), без которой в краткосрочном промежутке времени невозможно функционирование предприятия, любой простой которой приведет к значительным финансовым потерям.
• Бизнес-критичная система (БКС, Business Critical Systems, BCS) – важная ИС Заказчика, работающая в режиме 24х7 (круглосуточно), простой которой в среднесрочном промежутке времени повлечет за собой финансовые или имиджевые потери, однако в кратковременном промежутке предприятие может выполнять свои обязательства с незначительным снижением уровня сервиса.
• Вспомогательная бизнес-система (ВБС, Business Support Systems, BSS)– ИС Заказчика, используемые в работе, но не требующие режима 24х7. Остановка таких систем на короткое время допустима.
• Система поддержки операций (СПО, Operation Support Systems, OSS) – ИС эксплуатационных подразделений Заказчика, простой которых в среднесрочном периоде не отразится на уровне сервиса и работе прочих систем.

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

Компания – Общество с ограниченной ответственностью «Постгрес Профессиональный» (ООО «ППГ», либо ее дочернее предприятие ООО «ППГ Разработка»).

Критичная проблема – проблема, решаемая в Заявке приоритета П1 или П2.

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

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

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

Обращение – факт взаимодействия Клиента и службы ТП.

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

ОС – операционная система.

Ошибка функционирования СУБД (ошибка в коде, bug) – нештатное поведение СУБД, приводящее к сбоям в работе ИС Заказчика, вызывающее сообщения об ошибке, или поведение, не соответствующее документации.

ПО – программное обеспечение.

Партнер – компания, уполномоченная Заказчиком и имеющая право обращаться за ТП от имени Заказчика.

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

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

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

Проблема – причина одного или нескольких инцидентов.

Портал технической поддержки (Портал техподдержки, Портал, Система управления заявками, СУЗ) – программно-аппаратный комплекс Компании, предназначенный для сбора, обработки Заявок и регламентации деятельности в рамках исполнения Заявок.

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

Рабочий час – астрономический час в пределах Рабочего дня.

Редакция СУБД — разновидность СУБД, представляющая собой СУБД PostgreSQL или переработаную версию (форк) СУБД PostgreSQL; под редакциями СУБД Postgres Pro подразумеваются различные продукты СУБД компании Postgres Pro.

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

Служба технической поддержки (Служба ТП) – подразделение Компании, ответственное за оказание услуг гарантийного обслуживание.

Соглашение об уровне сервиса (Уровень сервиса, SLA, Service Level Agreement) – характеристики качества оказываемых Услуг Исполнителя на запросы Заказчика.

СУБД – система управления базами данных.

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

Эскалация – привлечение внимания к проблеме в конкретной Заявке.

Приём обращений

Служба технической поддержки Компании осуществляет прием обращений следующими способами:

• через Портал технической поддержки https://support.postgrespro.ru/
• по электронной почте: support@postgrespro.ru, consulting@postgrespro.ru
• по телефону: +7 495 150 2691

Гарантийное обслуживание не оказывается по другим каналам: форумы, Skype, ICQ, GoogleTalk, Telegram, WhatsApp, Viber, другие службы мгновенного обмена сообщениями и тому подобное, а также личные телефоны или электронная почта сотрудников. Вопросы, заданные по этим каналам, не являются официальными обращениями и не регистрируются. Подобные средства связи рассматриваются только как вспомогательные средства коммуникации.

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

Обязанности Заказчика и Исполнителя

Обязанности Исполнителя

Исполнитель обязан:

• обеспечить круглосуточную работу «горячей линии» для Заказчика;
• обеспечить прием, регистрацию и правильную приоритезацию обращений от Заказчика в виде Заявок;
• выдавать рекомендации по устранению проблем эксплуатации поддерживаемого ПО;
• исправлять ошибки в коде (bugs) поддерживаемого ПО собственного производства либо отправлять отчёты об ошибках оригинальным авторам поддерживаемого ПО;
• обеспечить доступ к истории обращений Заказчика;
• обеспечить необходимый уровень эскалации проблем Заказчика в соответствии с Приоритетами Заявок.

Обязанности Заказчика

Заказчик обязан:

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

Ограничения ответственности

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

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

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

Сроки гарантийного обслуживания всех версий СУБД Postgres Pro, за исключением имеющих сертификаты ФСТЭК, аналогичны срокам международной версии СУБД PostgreSQL.

Приложение №1: Поддерживаемое ПО

Приложение №2: Гарантийное обслуживание

Описание Гарантийного обслуживания

Целью Гарантийного обслуживания является поддержание работоспособности и устранение проблем эксплуатации ПО Компании в ИС Заказчика.

В состав услуг гарантийного обслуживания входит:

• Доступ к информации о составе купленных лицензий и сертификатов и сроках их действия;
• Доступ к бинарным репозиториям для установки ПО Компании на время действия сертификата;
• Помощь в установке ПО из бинарных пакетов и поиске возникающих проблем при самостоятельной установке;
• «Горячая линия» для приёма обращений:
  • Создание новых Заявок на гарантийное обслуживание и работа с ними;
  • Архив закрытых Заявок и Заявок других сотрудников Заказчика;
  • База знаний;
1. Ответы на телефонные звонки, поступившие на телефонный номер технической поддержки +7 (495) 150-2691;
2. Создание новых Заявок при получении письма на электронный почтовый адрес техподдержки support@postgrespro.ru;
3. Доступ к порталу техподдержки https://support.postgrespro.ru, где доступны:
• Выполнение SLA по обращениям на «горячую линию».
• Ответы на технические вопросы в функциональных рамках Гарантийного обслуживания:
1. по администрированию СУБД;
2. по техническим аспектам работы СУБД;
3. по обновлению СУБД;
4. по выполнению резервного копирования/восстановления СУБД, ее компонентов и накопленных данных;
5. по поиску информации в документации и др.
• Помощь в решении технических проблем в функциональных рамках Гарантийного обслуживания:
1. анализ причин возникновения проблемы;
2. поиск сценария воспроизведения проблемы;
3. поиск обходного пути (workaround) для критичной проблемы;
4. рекомендации по устранению проблемы;
5. рекомендации по восстановлению поврежденных данных.
• Работа с ошибками в коде поддерживаемого ПО (bug):
  • Выявление и исправление ошибок в актуальных версиях;
  • Включение исправления ошибок в новые версии ПО;
  • Выявление ошибок в актуальных версиях;
  • Оформление заявок о выявленных ошибках авторам соответствующего ПО.
1. ПО Компании
2. ПО сторонних разработчиков:
• Услуги Гарантийного обслуживания предоставляются удаленно.
  
   Порядок предоставления Гарантийного обслуживания
  
   Услуги Гарантийного обслуживания предоставляются в рамках оформленных Заявок в соответствии с разделом Приложение №3 Порядок предоставления Услуг на Портале техподдержки.
  
   Функциональные рамки Гарантийного обслуживания
  
   Гарантийное обслуживание действует только в отношении Поддерживаемого ПО, надлежащим образом приобретённого у партнёров Компании.
  
   Гарантийное обслуживание не распространяется на ПО, не поддерживаемое Компанией, а также не действует в отношении любых аппаратных средств Заказчика.
  
   За решением проблем стороннего ПО и оборудования следует обращаться в соответствующие службы поддержки их производителей. Все вопросы, связанные с технической и сетевой инфраструктурой, также находятся в зоне ответственности Заказчика и не включаются в функциональные рамки гарантийного обслуживания Компании.
  
   К Гарантийному обслуживанию не относятся случаи, когда причиной неисправности является нарушение Заказчиком рекомендаций, приведенных в технической документации ПО или рекомендаций, полученных в ходе оказания гарантийного обслуживания.
  
   В гарантийное обслуживание не входят услуги, описанные в РТП:
  
  
1. Любые работы Исполнителя на площадке Заказчика, в том числе с удаленным подключением;
2. Проведение тематических семинаров по функциональным возможностям ПО, расширений и утилит, а также их использованию;
3. Написание детальных инструкций или подготовка других документов под конкретные условия Заказчика, включая выдачу любых технических заключений;
4. Проработка архитектуры или выбор оптимальных решений под условия Заказчика;
5. Анализ поведения, оптимизация, подбор оптимальных параметров ИС Заказчика;
6. Участие в проектных работах Заказчика: настройка и конфигурирование ПО; подготовка и миграция данных.
• Эти услуги могут быть оказаны Исполнителем дополнительно в рамках РТП.
  
   Требования к персоналу Заказчика
  
   Эксплуатация СУБД требует соответствующей технической квалификации. Принимая во внимание, что гарантийное обслуживание со стороны Компании оказывается в удаленном формате, то у Заказчика на месте эксплуатации ИС должен присутствовать квалифицированный персонал, который сможет собрать необходимую техническую информацию, запрошенную Исполнителем, и выполнить полученные рекомендации.
  
   Заказчик должен обеспечить наличие необходимой технической квалификации своего персонала.
  
   Минимальными требованиями являются:
  
  
  
1. базовые знания администрирования ОС и СУБД на уровне курса DBA1 (https://postgrespro.ru/education/courses/DBA1);
2. умение работать в консоли сервера.

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

Приоритеты Заявок и Уровень сервиса

Целевое время обработки Заявок определено следующим образом:

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

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

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

 Время предоставления решения

• 1. Для целей Уровня сервиса фиксируется только время работы Службы технической поддержки после назначения Заявки на Исполнителя. Время ожидания информации от Клиента или согласованные с Клиентом ожидания внешних событий не учитываются для целей определения параметров Уровня сервиса.
  2. Режим работы Клиента по Заявке должен соответствовать запрашиваемому в этой Заявке приоритету — 24х7 или 9х5.
  3. Время реакции. Для нового обращения это соответствует времени, в течение которого будет обработана Заявка и назначен ответственный исполнитель, направлено уведомление об этом Клиенту.
  4. Время предоставления решения. За это время Исполнитель запросит всю необходимую информацию, и при условии наличия технической информации, достаточной для подготовки таких рекомендаций, подготовит исчерпывающий ответ на вопрос и/или предложит варианты решения проблемы. Время выполнения рекомендаций гарантийного обслуживания может оказаться значительным (например, восстановление из резервной копии) и не входит в SLA.
  5. Если Заказчик аргументированно покажет, что предложенное решение не является приемлемым, или сообщит другую дополнительную информацию, согласно которой предложенное решение не может быть использовано, Исполнитель подготовит новое решение, однако учет времени для предоставления нового решения будет выполняться заново.
  6. Если время предоставления информации от Заказчика превысит время предоставления решения, установленного по Заявке (4 часа для П1 и так далее), то приоритет такой заявки может быть понижен Исполнителем.
  7. Невыполнение рекомендаций Службы техподдержки снимает с Исполнителя обязательства по выполнению параметров Уровня сервиса.
  8. Несоответствие квалификации персонала Заказчика необходимому уровню, приведенному в разделе «Требования к персоналу Заказчика» может повлечь непредвиденные задержки в решении проблемы и по таким Заявкам Уровень сервиса не гарантируется.
  9. Для приоритета «П1 Высший» заведение Заявки или предоставление информации по Заявке должно сопровождаться телефонным звонком на «горячую линию» техподдержки.
  10. В процессе работы над Заявкой ее приоритет может меняться: повышаться, если стали известны новые обстоятельства, увеличивающие критичность проблемы, либо понижаться, если найден приемлемый обходной путь.
  11. Работа над Заявками продолжается до решения проблемы или до тех пор, пока достижим прогресс в решении.
• Время исправления в коде ошибки функционирования СУБД
  1. Указанное в Уровне сервиса время исправления ошибки относится только к случаям, когда Заказчик предоставил информацию, достаточную для воспроизведения проблемы на внутренних ресурсах Компании. Служба технической поддержки может помочь Заказчику с поиском шагов для воспроизведения проблемы.
  2. Исправления делаются следующим образом:
     • для ПО Компании — ошибки выявляются, исправляются и включаются в новые версии ПО;
     • для остального ПО, не являющегося ПО Компании, — ошибки выявляются и оформляются в виде заявок авторам соответствующего ПО.
  3. Время исправления ошибок в целях исполнения Уровня сервиса применимо только для ПО Компании, находящемся на Гарантийном обслуживании.
  4. В экстренных случаях, по критичным приоритетам, исправления могут быть переданы Заказчику в виде патча (для ПО с открытым кодом) или специальной бинарной сборки. Данный способ исправления ошибок не рекомендуется как основной, так как такие сборки не проходят всех необходимых процедур выпуска версии. Бинарные сборки для исправления ошибок необходимо заменить на официально выпущенную новую версию ПО, содержащую необходимое исправление, как только такая версия станет доступна.
  5. По своему усмотрению, для исправления критичных ошибок в своем ПО, Компания выпускает внеплановые релизы.

Приложение №3: Порядок предоставления Услуг на Портале техподдержки

Портал технической поддержки расположен по адресу https://support.postgrespro.ru и служит для взаимодействия Заказчиков с Компанией.

Набор лицензий

Всё взаимодействие между Заказчиком и Компанией привязано к Набору лицензий. К нему привязаны все лицензии и сертификаты, приобретённые Заказчиком. К нему же привязаны все Заявки. Также через Набор лицензий осуществляется доступ к репозиториям для установки продуктов Компании. Чтобы получить доступ к заявкам, пользователям надо выполнить привязку к соответствующему Набору лицензий.

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

Регистрация и управление пользователями

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

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

Существуют следующие уровни доступа:

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

Обратите внимание, что учётная запись на Портале техподдержки (support.postgrespro.ru) не совпадает с учётной записью на основном сайте компании Postgres Pro (postgrespro.ru).

Доступ к репозиториям и установка продуктов Postgres Pro

Большинство продуктов Postgres Pro распространяются из online-репозиториев, где доступны бинарные пакеты для начальной установки или обновления штатными пакетными менеждерами серверных ОС.

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

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

Более подробная информация доступна на Портале техподдержки в Базе знаний.

Конфигурации

При работе с заявками часто возникает необходимость ознакомиться с экземпляром СУБД на котором обнаружена проблема. Для этих целей служит диагностический скрипт, который собирает основную информацию о сервере: об оборудовании, об ОС и СУБД. При загрузке такого отчёта в заявку, Портал распознаёт его автоматически и прикрепляет отчёт к уже существующей Конфигурации, если по такому экземпляру СУБД отчёты уже ранее загружались, или создаёт новую Конфигурацию. Также уже существующую Конфигурацию можно указать при оформлении новой заявки.

Все существующие Конфигурации доступны из верхнего меню, Администрирование → выбрать Набор лицензий → Конфигурации.

База знаний

База знаний содержит статьи с полезной информацией, разбитой по древовидной структуре разделов. По статьям можно осуществлять поиск.

Работа с заявками

Взаимодействие между Заказчиком и Исполнителем ведётся в рамках Заявок по следующему базовому сценарию:

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

Подробная инструкция по работе с заявками расположена на Портале техподдержки.

Список заявок, фильтры и поиск

В верхнем меню Портала можно выбрать пункт «Заявки», откроется список с заявками. Этот список можно фильтровать. Есть некоторое количество преднастроенных фильтров: посмотреть на свои заявки, эскалированные, все открытые и так далее. По-умолчанию, если не выбран другой фильтр, выбирается фильтр, который показывает все открытые заявки. Также есть возможность определить свой фильтр, нажав на кнопку с воронкой — выбрать значения или диапазоны для полей, для сложного фильтра можно выбрать подфильтры. Самостоятельно сделанный фильтр можно сохранить, а ранее сохранённые можно удалить. Предопределённые фильтры удалить нельзя. Также можно определить поля для показа в списке заявок и выбрать сортировку.

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

Чтобы открыть новую заявку надо нажать кнопку в верхнем меню «Создать заявку», указать домен в соответствии с ожидаемой услугой (консалтинг, гарантийное обслуживание, продажи), тему и описание, заполнить все дополнительные поля, набор которых зависит от выбранного домена.

Взаимодействие по заявке между Заказчиком и Исполнителем ведётся в комментариях в заявке. Чтобы написать комментарий в заявку, нужно её открыть на Портале и написать комментарий внизу страницы в поле ввода. В процессе ввода можно вставлять картинки (через drag-n-drop и copy-paste), а также прикреплять файлы. Если прикрепить файл с отчётом диагностического скрипта, то автоматически будет создана конфигурация. Поле ввода комментариев поддерживает переключение в режим WISIWIG и markdown-подобного синтаксиса.

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

Чтобы закрыть заявку, нужно открыть её на Портале и нажать кнопку «Закрыть заявку».

Работа с Заявками через электронную почту

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

Новое письмо на адреса Портала откроет новую заявку. Ответ через почту на уведомление по Заявке от Портала из электронной почты создаст новый комментарий в Заявке, если в заголовке письма есть номер Заявки, а у автора письма есть права на добавление комментариев в Заявку. Респонденты, указанные в СС письма попадут в список слежения (СС) по Заявке.

Стадии заявок

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

• Согласование — проводится согласование объёмов и сроков работ,
• Выполнение — ведутся работы Исполнителем в соответствии с согласованным ранее графиком,
• Приёмка — работы выполнены Исполнителем, идёт ведётся приёмка выполненных работ.

Статусы заявок

Текущее состояние заявки отражено в её статусе. В заявках используются следующие статусы:

• NEW - Новая — в этом статусе создаются новые заявки.
• WIP - Работает агент — над заявкой работает исполнитель.
• CUS - Работает клиент — в заявке были предоставлены рекомендации или запрошена дополнительная информация от клиента.
• HLD - Ожидание — ожидание внешних событий (например, исправления ошибки или выпуска версии).
• ACL - Автозакрытие — заявка закрывается из-за неактивности со стороны клиента более семи календарных дней.
• CLS - Закрыто — заявка закрыта, работы по ней завершены, но её ещё можно переоткрыть.
• CLX - Закрыто окончательно — заявка закрыта и переоткрыть её уже нельзя.

Новые заявки открываются в статусе NEW. Любое изменение в заявке — загруженный файл или написанный комментарий — переводят статус заявки в WIP, закрытая заявка при этом будет открыта заново. Если Клиент не отвечает более семи календарных дней по заявке в статусе CUS, заявка перейдёт в статус автоматического закрытия ACL, а ещё через семь календарных дней закроется. Заявки в статусе CLX открыть заново нельзя. При необходимости продолжить работы по той же проблеме возможно заведение новой заявки, со ссылкой на предыдущую.

Приоритеты заявок

Определения приоритетов заявок домена поддержки:

• П1 Высший — Проблема критична, что обозначает полную неработоспособность СУБД в промышленной эксплуатации для ИС Заказчика класса «Критически важная (Mission Critical)» или «Бизнес-критичная (Business Critical)». Работы со стороны Заказчика и Исполнителя ведутся в непрерывном режиме 24х7.
• П2 Высокий — Проблема критична, что обозначает полную неработоспособность СУБД в промышленной эксплуатации для ИС Заказчика класса «Критически важная (Mission Critical)» или «Бизнес-критичная (Business Critical)». Работы со стороны Заказчика и Исполнителя ведутся в рабочее время в режиме 9х5.
• П3 Средний — Проблема критична (см. выше), но ИС Заказчика не в промышленной эксплуатации, или не является «Критически важной (Mission Critical)» или «Бизнес-критичной (Business Critical)», либо система работоспособна с какими-либо ограничениями, либо для проблемы существует обходной путь решения. Работы ведутся в рабочее время в режиме 9х5.
• П4 Низкий — Проблема некритична, либо проявляется на тестовой системе, либо не приводит к недоступности критичного функционала или потере данных, либо проблема в документации или носит косметический характер. Также это приоритет для всех консультаций и запросов информации. Работы ведутся в рабочее время в режиме 9х5.

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

Оформление заявок

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

Для установки приоритета выше «П4 Низкий» необходимо привести обоснование важности проблемы в бизнес-терминах, так как техническая проблема не обязательно влечет бизнес-критичные потери для бизнеса Заказчика.

При обращении в техподдержку необходимо подготовить и предоставить следующую информацию:

• Описание проблемы, содержащее конкретизацию, в чем именно заключается проблема и какое требуется решение.
• Сообщение об ошибке как оно есть (as is) и в текстовом виде.
• Где было обнаружено сообщение об ошибке.
• Когда появилась проблема, в чем проявлялась, какие события произошли в то же время или непосредственно до: менялась ли конфигурация СУБД, обновлялось ли ПО или аппаратное обеспечение сервера или сетевое оборудование, были ли другие сбои, перезагрузки и т.п.
• Воспроизводима ли проблема: всегда, плавающая, единичный сбой.
• Шаги по воспроизведению.
• (*) Точное название СУБД (PostgreSQL, 1C, Standard, Enterprise, Shardman, Certified) и полная версия.
• (*) Поставлена ли СУБД из репозитория (какого) или собрана самостоятельно.
• (*) Точное название и версия ОС, архитектура CPU.
• (*) Файлы конфигурации СУБД.
• Лог-файлы СУБД и ОС на момент появления проблемы.
• (*) Работает ли СУБД в кластере, участвует ли в репликации. Какое кластерное ПО используется.
• Критична ли проблема? Какие есть критичные даты?
• В случае запроса Высшего приоритета требуется обоснование и контакты 24х7 от Заказчика (см. ниже).
• Только для критичных проблем:
• Обоснование критичности в бизнес-терминах.
• Для проблем производительности:
• (*) Количество CPU и размер RAM.
• (*) Размер БД (включая все табличные пространства).
• (*) На каком дисковом хранилище расположены файлы БД (включая все табличные пространства).
• Есть ли система мониторинга, которая позволит проанализировать, как развивались события.

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

Для устранения ошибок в коде поддерживаемого ПО (bugs) требуется предоставить сценарий воспроизведения проблемы на внутренних ресурсах Исполнителя или доступ к среде Заказчика, где проблема воспроизводится. В противном случае устранение ошибки в ПО в указанный в SLA срок не гарантируется.

Оформление заявки приоритета «П1 Высший»

При заведении заявки приоритета «П1 Высший» дополнительно требуется:

• Указать причину, почему проблема является критичной, какой ущерб бизнесу Заказчика нанесен.
• Подтвердить готовность работать в режиме 24х7.
• Указать контактные данные (имя и телефон) технического контактного лица, кто работает по проблеме в режиме 24х7.
• Указать контактные данные (имя и телефон) руководителя, который отвечает за организацию работ по проблеме в режиме 24х7.
• Заведение новой заявки или предоставление информации по таким заявкам необходимо сопровождать звонком на телефон «горячей линии» техподдержки.

Эскалации

Эскалация – это привлечение внимания руководителя соответствующей службы Компании к проблеме в конкретной Заявке.

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

Причина эскалации, как и критичность проблемы, должна формулироваться в терминах ущерба для бизнеса, так как любая самая большая техническая проблема может никак не влиять на бизнес, и наоборот незначительная техническая проблема может иметь огромное влияние на бизнес в определённых обстоятельствах. Типичные причины эскалации: недовольство ходом работ; появление новых обстоятельств, меняющих масштаб проблемы; запуск системы в эксплуатацию или наступление других важных дат; вовлечение VIP-персон Заказчика в решение проблемы и т.п.

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

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