Вендорская техническая поддержка СУБД Postgres Pro и PostgreSQL

Вендорская техническая поддержка СУБД Postgres Pro и PostgreSQL Обеспечиваем вторую и третью линии техподдержки СУБД Postgres Pro и PostgreSQL в режиме 24х7. Восстановление работоспособности, анализ непредвиденных обстоятельств, исправление ошибок в СУБД и расширениях.

 

 Техническая поддержка доступна в режиме 24x7. Стандартное время отклика - 1 час.

 

Глоссарий

 

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

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

Горячая линия — единая точка входа для обращений Клиента за Услугами технической поддержки, работает в режиме 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) – характеристики качества оказываемых Услуг Исполнителя на запросы Заказчика.

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

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

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

 

Виды предоставляемых услуг технической поддержки

 

Компания оказывает следующие виды базовых услуг:

  • Базовая услуга Техподдержки (далее БУ Техподержки), описание которой приведено в Приложении №2;
  • Базовая услуга Консалтинга (далее БУ Консалтинга), описание которой приведено в Приложении №3;

На основе этих базовых услуг Компания предоставляет Заказчикам следующие виды технической поддержки:

  • Гарантийное обслуживание (далее – ГО), состоит из БУ Техподдержки и предоставляется в рамках гарантийных обязательств Компании, в соответствии с условиями поставки и требованиями законодательства РФ;
  • Стандартная техническая поддержка (далее – СТП) состоит из БУ Техподдержки, которая предоставляется по отдельно приобретаемым Сертификатам на техническую поддержку;
  • Расширенная техническая поддержка (далее – РТП), представляет собой БУ Консалтинга, оказываемые по отдельно приобретаемым сертификатам на Расширенную поддержку в дополнение к действующим сертификатам СТП или ГО.

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

 

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

 

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

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

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

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

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

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

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

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

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

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

Обещанная помощь

Для физических лиц и организаций, не имеющих действующих сертификатов ТП, доступны следующие виды помощи, оказываемой Компанией на безвозмездной основе:

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

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

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

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

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

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

Актуальные сроки технической поддержки различных версий СУБД можно уточнить по ссылке: https://postgrespro.ru/services/support

Приложение №2: Базовая услуга Техподдержки (БУ Техподдержки)

Описание БУ Техподдержки

Целью технической поддержки (техподдержки) является поддержание работоспособности и устранение проблем эксплуатации ИС Заказчика.

В состав услуг технической поддержки входит:

  • Доступ к информации о составе купленных лицензий и сертификатов и сроках их действия;
  • Доступ к бинарным репозиториям для установки и обновления ПО Компании на время действия сертификата;
  • Помощь в установке ПО из бинарных пакетов и поиске возникающих проблем при самостоятельной установке;
  • «Горячая линия» для приёма обращений:
    • Ответы на телефонные звонки, поступившие на телефонный номер технической поддержки +7 (495) 150-2691;
    • Создание новых Заявок при получении письма на электронный почтовый адрес техподдержки support@postgrespro.ru;
    • Доступ к порталу техподдержки https://support.postgrespro.ru, где доступны:
      • Создание новых Заявок на поддержку и работа с ними;
      • Архив закрытых Заявок и Заявок других сотрудников Заказчика;
      • База знаний;
  • Выполнение SLA по обращениям на «горячую линию».
  • Ответы на технические вопросы в функциональных рамках технической поддержки:
    • по администрированию СУБД;
    • по техническим аспектам работы СУБД;
    • по обновлению СУБД;
    • по выполнению резервного копирования/восстановления СУБД, ее компонентов и накопленных данных;
    • по поиску информации в документации и др.
  • Помощь в решении технических проблем в функциональных рамках технической поддержки:
    • анализ причин возникновения проблемы;
    • поиск сценария воспроизведения проблемы;
    • поиск обходного пути (workaround) для критичной проблемы;
    • рекомендации по устранению проблемы;
    • рекомендации по восстановлению поврежденных данных.
  • Работа с ошибками в коде поддерживаемого ПО (bug):
    • ПО Компании
      • Выявление и исправление ошибок в актуальных версиях;
      • Включение исправления ошибок в новые версии ПО;
    • PostgreSQL:
      • Выявление и исправление ошибок в актуальных версиях;
      • Публикация патчей с исправлениями в открытом доступе;
    • ПО сторонних разработчиков (кроме PostgreSQL):
      • Выявление ошибок в актуальных версиях;
      • Оформление заявок о выявленных ошибках авторам соответствующего ПО.

    Услуги техподдержки предоставляются удаленно.

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

    Порядок предоставления БУ Техподдержки

    Услуги техподдержки предоставляются в рамках оформленных Заявок в соответствии с разделом Приложение №4 Порядок предоставления Услуг на Портале техподдержки.

    Функциональные рамки БУ Техподдержки

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

    Техническая поддержка не распространяется на ПО, не указанное в Сертификате, а также не действует в отношении любых аппаратных средств Заказчика.

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

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

    В техническую поддержку не входят услуги, описанные в РТП:

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

    Эти услуги могут быть оказаны Исполнителем дополнительно в рамках РТП.

    Требования к персоналу Заказчика

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

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

    Минимальными требованиями являются:

    • базовые знания администрирования ОС и СУБД на уровне курса DBA1 (https://postgrespro.ru/education/courses/DBA1);
    • умение работать в консоли сервера.

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

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

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

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

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

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

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

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

    Заявки на дополнительные услуги (консалтинг, РТП) не имеют приоритетов, их выполнение идёт по согласованному графику работ. Перед началом работ по таким заявкам, требуется согласование графика и объёмов работ, которое выполняется только в рабочее время.

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

Приложение №3: Базовая услуга Консалтинга (БУ Консалтинга)

Описание Базовой услуги Консалтинга

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

Состав услуг РТП может включать в себя следующие услуги:

  • участие в проектных работах;
  • сбор диагностических данных и выполнение рекомендаций на системах Клиента;
  • разбор инцидентов с дополнительным исследованием инфраструктуры и прикладного ПО;
  • оптимизация запросов и прикладного ПО, выработка рекомендаций по изменению настроек СУБД;
  • проведение технических аудитов систем Заказчика;
  • экспертная помощь в настройке СУБД и окружающей инфраструктуры: систем мониторинга, резервного копирования;
  • проектирование кластерных решений;
  • помощь в миграциях, в том числе с других типов СУБД;
  • заказная разработка прикладных приложений на основе СУБД Postgres Pro и функционала внутри самой СУБД (расширений);
  • сопровождение запуска систем в промышленную эксплуатацию;
  • помощь в оптимизации работы прикладных систем Заказчика;
  • проведение тематических семинаров для специалистов Заказчика по функциональным возможностям продуктов компании;
  • проведение обучающих курсов в рамках стандартных программ (https://postgrespro.ru/education/courses);
  • проведение сертификации специалистов Заказчика (https://postgrespro.ru/education/cert);
  • и другие услуги по согласованию.

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

Таблица SLA на услуги РТП

Вид работ Время выполенения Примечания
Согласование состава и сроков оказания услуг РТП по каждой заявке 3 рабочих дня с момента подачи заявки SLA выдерживается только при наличии детального технического задания (ТЗ). В противном случае идёт процесс уточнения ТЗ, время уточнения не входит в SLA

Прием обращений по РТП выполняется в соответствии с Приложением №4 Порядок предоставления Услуг на Портале техподдержки. Если обращение выходит за рамки СТП , сотрудники Исполнителя сообщат об этом и переквалифицируют открытую Заявку в услуги РТП.

Чтобы открыть заявку сразу на услуги РТП, можно явно выбрать домен Консалтинг при заведении новой заявки на портале или, при оформлении заявки через электронную почту, использовать электронный почтовый ящик consulting@postgrespro.ru.

К оформлению заявок РТП применимы те же требования, что и для заявок СТП, за исключением приоритета, по заявке РТП сначала согласуется объем, состав и график оказания услуг, а затем оказываются сами услуги в соответствии с достигнутыми договорённостями между Заказчиком и Исполнителем.

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

Согласование услуг РТП проводится только в рабочее время.

Процесс оказания услуг РТП может содержать все или часть нижеприведенных стадий:

  1. Подача заявки.
  2. Согласование.
  3. Выполнение работ.
  4. Приемка - закрытие заявки Заказчиком/Исполнителем - факт подтверждения выполнения работ.

Порядок предоставления услуги РТП

Для получения услуг РТП необходимо быть зарегистрированным в соответствии с порядком, приведенным в разделе «Приложение №4: Порядок предоставления Услуг на Портале техподдержки».

При обращении в ТП по сертификату РТП Клиент предоставляет номер сертификата РТП и описывает суть обращения.

Регистрация поступивших обращений осуществляется автоматически.

При регистрации обращения Клиенту приходит почтовое уведомление о зарегистрированном обращении.

Для сертификатов РТП, требующих учета трудозатрат Исполнителя, учет трудозатрат осуществляется следующим образом:

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

Соглашение об уровне сервиса, регламентирующее время выполнения работ, в отношении услуг РТП не применяется.

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

  • Согласование – производится согласование состава работ по обращению, графика их выполнения и сопутствующих трудозатрат Исполнителя
  • Выполнение – Исполнителем ведутся работы по заявке.
  • Приёмка – работы по заявке завершены, результаты согласуются

После приемки результатов работы заявка может быть закрыта следующими способами:

  • со стороны клиента операцией закрытия на портале ТП - перевод в состояние ACL (Автозакрытие)
  • заявка закрыта со стороны Исполнителя и со стороны Заказчика не последовало возражений в течение 7 календарных дней

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

Портал технической поддержки расположен по адресу 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-персон Заказчика в решение проблемы и т.п.

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

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

Все услуги

Закажите услугу
Вендорская техническая поддержка СУБД Postgres Pro и PostgreSQL

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


Согласие с обработкой персональных данных