Основна дошка для роботи ІТ відділу має назву P.Sale IT Board та дає змогу працювати в рамках наступних задач:
...
CDB31 проблемаCDB3 - задачі що стосуються технічних проблем роботи самої ЦБД-3, взаємодії майданчиків з ЦБД-3, реалізації/оновлення програмного забезпечення та документування змін/робіт.
...
До кожної окремої задачі кріпиться перелік тест кейсів по процедурі ро якій проводиться тестування, так званий тестовий прогон, який створюється персонально під майданчик. Окрім того, задача містить перелік багрепортів які було задокументовано в ході тестування
Задачі данного проекту створюються тестувальниками співробітниками ІТ відділу.
Створення зовнішнього тікета
...
Після вводу даних облікового запису аба реєстрації загальна форма має вигляд:
Створення запиту на виачу/заміну ключа для роботи майданчика з процедурою та Документ сервісом:
Для Для створення запиту такого типу необхідно необхідно перейти за посиланням, обрати пункт IT Service Desk і на отриманій формі обрати CDB requests а потім KEYS API і DS:
...
Основна інструкція по заповненню полів
Поля форми:
Тема - короткий опис того, на що робиться запит, має містити інформацію про інформацію або дію яку потрібно виконати, ЦБД по якій заповнюється запит та назву майданчика. Бажано заповнювати тему за правилом "Що зробити + Де зробити + У кого зробити". Наприклад, "Замінти ключі ЦБД-2 для майданчика 1"
...
E-mail (не обязательно) — електрона пошта контактної особи
Для повідомлення ДП про виникнення технічних проблем слід використовувати проект:
Для створення запиту такого типу необхідно перейти за посиланням, обрати пункт DEV_Infra:
...
і на отриманій формі обрати Incident:
Поля форми:
Тема — короткий та змістовний опис проблеми, бажано сформований за првилом “Що сталося + Де сталося + Укого сталося”, наприклад “403 помилка при роботі з ДС, ЦБД-2 майданчик-1”
...
Описание (optional) — опис дій які привели до виникнення інциденту, оточення на якому виникли проблеми та інших суттєвих технічних даних, може містити посилання на створенний Звіт про помилку з загальним доступом.
Для підвищення якості обробки звітів про помилки при роботі з API ЦБД Прозорро слід якомога повніше подавати наступну інформацію в звітах про помилки.
Інцидент із API, DS
Перші три - найважливіша ключова інформації, і далі в порядку важливості
- Шлях API/DS URL (куди надсилали запит) ! без ключів
- X-request-id заголовок відповіді сервера (якщо було декілька аналогічних спроб x-request-id цих спроб)
- Заголовок X-Client-Request-ID запиту (якщо було декілька аналогічних спроб X-Clent-Request-id цих спроб).
- Час запиту (хоча б з точністю до хвилини)
- Код і вміст відповіді від сервера
- Вміст запиту ! без ключів автентифікації / іншої конфіденційної інформації !
- ID документа - ID тендера / аукціону / плану / файла
- IP адреса - з якої надсилали запит
- Вкажіть ваш майданчик
Інцидент із Auction
- Код (ідентифікатор) тендера
- Код (ідентифікатор) лота
- Фотографії / відео екрану, якщо є
- Опис помилки/проблеми
- Фотографія (скріншот) екрану з відкритим меню ( потрібні значення Browser ID, Session ID )
- Інформація про Операційну систему, бровзер, тип інтернет підключення, провайдер
412 помилка від сервера
- Переконатися, що майданчик коректно працює з API в режимі крастеру. Детальніше можна прочитати за посиланням http://api-docs.openprocurement.org/uk_UA/latest/cluster.html#cluster
- Якщо майданчик продовжує отримувати у відповідь 412 після декількох повторних спроб, надати наступну інформацію:
- broker_id майданчика
- cookies, що використовуються майданчиком при подачі POST/PUT/PATCH/DELETE запитів
- періодичність, з якою майданчик отримує 412 помилку
...