Жөнелтілімдерді қадағалау API интерфейсін бағалау метрикалары: Proof of Concept кезінде өлшенетін 8 KPI

Жөнелтілімдерді бақылау API-інің тұжырымдаманы дәлелдеу нұсқасын сегіз KPI арқылы бағалаңыз: пайдалануға жарамды бақылау қамтуы, оқиғалардың толықтығы, мәртебе дәлдігі, жаңарту кідірісі, webhook жеткізу сенімділігі, API сұрауларының сенімділігі, интеграцияға жұмсалатын күш және пайдалануға жарамды бақыланған жөнелтілімнің құны. Оларды тек сәтті демонстрациялық сұраулармен емес, нақты жөнелту қоспаңызбен және келісілген эталондық деректермен салыстырып өлшеңіз. Нәтижелер нақты енгізу, түзету немесе қабылдамау туралы шешімді қолдауы үшін тестілеуді бастамас бұрын қабылдау критерийлерін белгілеңіз.

Бұл нұсқаулық тапсырыстарды басқару жүйесі, қойма платформасы, клиенттерді қолдау процесі немесе бақылау интерфейсі үшін API таңдайтын инженерлік жетекшілерге, логистикалық операциялар командаларына және сатып алуға жауапты тұлғаларға арналған. Төмендегі формулалар жарияланған салалық эталондар емес, ұсынылатын бағалау әдістері болып табылады. Шектік мәндеріңіз жетіспейтін, кешіктірілген немесе қате бақылау ақпаратының салдарын көрсетуі тиіс.

Өндірістік жағдайды көрсететін тест құрыңыз

Тұжырымдаманы дәлелдеу нұсқасы практикалық сұраққа жауап беруі керек: бұл интеграция жөнелтілімдер туралы сенімді ақпаратты қолайлы пайдалану құнымен бере ала ма? Құмсалғыш сұраулар мен жауаптардың жұмыс істейтінін көрсете алады, бірақ оның өзі нақты тасымалдаушы деректерінің сапасын дәлелдей алмайды.

Қолжетімділігі сақталған жағдайда тарихи жөнелтілімдерді тест кезінде бақыланған нақты жөнелтілімдермен біріктіріңіз. Тарихи жағдайлар мәртебелерді түсіндіруді және әдеттен тыс бағыттарды тексеруге көмектеседі. Жаңарту кідірістерін және хабарландырулардың жеткізілуін өлшеу үшін нақты жөнелтілімдер қажет.

• Жөнелту қоспаңызды көрсетіңіз. Негізгі тасымалдаушыларды, шығу және тағайындалу орындарының комбинацияларын, қызмет түрлерін және қажет болса трансшекаралық тасымалдау кезеңдерін қосыңыз. Маңызды сегменттерді бір орташа мәннің ішіне жасырып қоймай, бөлек есеп беріңіз.
• Күрделі бағыттарды қосыңыз. Кешіктірілген жөнелтілімдерді, сәтсіз жеткізу әрекеттерін, қайтарымдарды, тасымалдаушыны анықтаудағы белгісіздікті және әлі физикалық сканерден өтпеген жөнелтілімдерді тексеріңіз.
• Теріс тестілерді бөлек жүргізіңіз. Жарамсыз бақылау нөмірлері мен қолдау көрсетілмейтін сұраулар қателерді өңдеуді тексеруге пайдалы, бірақ олар жарамды жөнелтілімдер үшін қамту көрсеткішін үнсіз төмендетпеуі керек.
• Эталондық дәлелдерді сақтаңыз. Әр бағалауда пайдаланылған тасымалдаушы туралы ақпаратты, уақыт белгілерін, бастапқы уақыт белдеуін, бақылау идентификаторларын және API жауаптарын жазып алыңыз. Журналдардағы жеке деректер мен тіркелгі деректерін қорғаңыз.
• Жауапкершілікті келісіңіз. Инженерия техникалық өлшеу құралдарына, логистикалық операциялар жөнелтілім мағыналарын тексеруге, ал қаржы немесе сатып алу құн моделін тексеруге жауапты болуы керек.

Ұпайларды жинауды бастамас бұрын ортақ бақылау кезеңін пайдаланыңыз және қандай нәтиже пайдалануға жарамды болып саналатынын анықтаңыз. Бірнеше іске асыру нұсқасын салыстырсаңыз, олардың әрқайсысына бірдей жөнелтілім тобын және салыстырмалы тест жағдайларын беріңіз. Нәтижеге әсер етуі мүмкін конфигурация айырмашылықтарын тіркеңіз.

1. Пайдалануға жарамды бақылау қамтуы

Сұрақ: API бизнесіңіз нақты жіберетін жөнелтілімдер үшін пайдалы бақылау ақпаратын қайтара ала ма?

Формула: Пайдалануға жарамды бақылау қамтуы = пайдалануға жарамды бақылау нәтижесі бар жарамды тест жөнелтілімдері ÷ барлық жарамды тест жөнелтілімдері × 100.

Жарамдылықты провайдердің қолдау көрсетілетін тасымалдаушылар тізімінен тәуелсіз анықтаңыз. Мысалы, бөлгішке іске қосу ауқымындағы жарамды және бақылау ақпараты болуы ақылға қонымды түрде күтілетіндей ескі барлық жөнелтілімді қосуыңыз мүмкін. Әйтпесе, қолдау көрсетілмейтін жөнелтілімдерді алып тастау өлшегіңіз келетін қамту тапшылығын жасырады.

Пайдалануға жарамды нәтиже сәтті тіркелуден немесе HTTP сәтті жауабынан көп нәрсені білдіруі керек. Жұмыс процесіне қажетті ең аз ақпаратты, мысалы дұрыс анықталған тасымалдаушыны және мағыналы жөнелтілім мәртебесін белгілеңіз. Жапсырма жасалды мәртебесі физикалық табыстауға дейін жарамды болуы мүмкін, бірақ оны кейінгі қозғалыс оқиғасының дәлелі деп санауға болмайды.

Нәтижелерді тасымалдаушы, бағыт және қызмет бойынша бөліңіз. Сондай-ақ қолдау көрсетілмейтін қызметтерді, тасымалдаушыны анықтау қателерін, сканерге дейінгі жөнелтілімдерді және уақытша алу сәтсіздіктерін ажыратыңыз. Жиынтық ұпай қолайлы көрінгенімен, бизнес үшін маңызды бағыт пайдалануға жарамсыз болуы мүмкін.

Шешім ережесі: Міндетті жөнелту сегменттеріндегі қамтуды іске қосу шартына айналдырыңыз. Жоғары жалпы пайыз іске қосу үшін қажет, бірақ қызмет көрсетілмейтін сегменттің орнын толтырмауы керек.

2. Қажетті оқиғалардың толықтығы

Сұрақ: API операцияларыңызға қажетті жөнелтілім кезеңдерін қамти ма?

Формула: Қажетті оқиғалардың толықтығы = сәйкестендірілген қажетті эталондық оқиғалар ÷ тест кезінде байқалған барлық қажетті эталондық оқиғалар × 100.

Сақталған тасымалдаушы жазбаларынан немесе келісілген шынайылық көзінен эталондық оқиғалар жиынын құрыңыз. Сипаттамалар, уақыт белгілері, орындар және оқиға түрлері үшін сәйкестендіру ережелерін анықтаңыз. Екі сипаттама бір оқиғаны білдірсе, мәтіннің бірдей болуын талап етпеңіз және әр тасымалдаушы бірдей кезеңдер тізбегін жариялайды деп күтпеңіз.

Көптеген командалар үшін пайдалы кезеңдерге физикалық қабылдау, қозғалыс, жеткізу әрекеттері, ерекше жағдайлар және соңғы жеткізу жатады. Нақты тізім жұмыс процесіне сәйкес болуы керек. Қолдау командасына аналитикалық бақылау тақтасына қажет емес жеткізу әрекеті оқиғасы керек болуы мүмкін.

Шикі жолдарды санаудың орнына бөлек оқиғаларды сәйкестендіріңіз. Қайталанған сканерлеулер толықтықты арттырмауы керек. Керісінше, провайдер қолданбаға қажетті ақпаратты жоғалтпай, қайталанатын оқиғаларды біріктіруі мүмкін.

Қолжетімсіз эталондық жазбаларды расталған жетіспейтін оқиғалардан бөлек ұстаңыз. Егер эталондық дереккөз оқиғаның болған-болмағанын анықтай алмаса, бұл жағдайды провайдердің сәтсіздігі немесе жетістігі ретінде емес, шешілмеген жағдай ретінде белгілеңіз.

Шешім ережесі: Маңызды кезеңдерді бөлек бағалаңыз. Қосымша орын жаңартуының болмауы клиент әрекетін іске қосуы тиіс сәтсіз жеткізу әрекетінің болмауымен тең емес.

3. Нормаланған мәртебе дәлдігі

Сұрақ: API тасымалдаушы оқиғаларын дұрыс операциялық мағынаға аудара ма?

Формула: Мәртебе дәлдігі = дұрыс жіктелген бағаланған мәртебе бақылаулары ÷ барлық бағаланған мәртебе бақылаулары × 100.

API нәтижесін қарамас бұрын күтілетін жіктеулерді логистикалық операциялар командасына анықтатыңыз. Оқиғалар тарихы дәл болғанымен, интеграция жеткізу әрекетін жеткізілді деп түсіндірсе немесе қайтару қозғалысын әдеттегі жөнелту транзиті деп қабылдаса, ағымдағы мәртебе жаңылыстыруы мүмкін.

Жеке оқиғалардың сәйкестендірілуін де, жөнелтілім деңгейіндегі мәртебені де бағалаңыз. Келіспеушіліктерді зерттеу үшін бастапқы тасымалдаушы сипаттамасын мүмкін болған жағдайда нормаланған мәнмен қатар сақтаңыз.

Қай мәртебелердің қай басқаларымен шатастырылатынын көрсету үшін қателер матрицасын пайдаланыңыз. Қате жеткізілді деп жіктеу жағдайларын бөлек есептеңіз, өйткені қате аяқталу сигналы клиент хабарламаларына, қолдау процестеріне және кейінгі тапсырыстарды өңдеуге әсер етуі мүмкін.

Белгісіз санатын міндетті түрде қосыңыз. Абайлап берілген белгісіз нәтиже негізсіз нақты мәртебеден қауіпсіз болуы мүмкін, бірақ оны өңдеудің операциялық ережесі болуы тиіс. Дәлдікті жасанды түрде арттыру үшін белгісіз жағдайларды бөлгіштен алып тастамаңыз.

Шешім ережесі: Қайтымсыз немесе клиентке көрінетін әрекеттерді іске қосатын қателер үшін қатаңырақ қабылдау шарттарын белгілеңіз. Бір қате түрі шамадан тыс тәуекел тудырса, жалпы дәлдік жеткіліксіз.

4. Жаңарту кідірісі

Сұрақ: Жаңа тасымалдаушы оқиғасының жүйеңізде пайдалануға жарамды болуы қанша уақыт алады?

Негізгі өлшем: Бақыланған жаңарту кідірісі = жүйеңіз пайдалануға жарамды жаңартуды тұрақты түрде тіркеген уақыт − келісілген эталондық дереккөзде оқиға алғаш байқалған уақыт.

Тасымалдаушы оқиғасы, эталондық бақылау, webhook қабылдау және ішкі өңдеудің сәтті аяқталуы үшін бөлек уақыт белгілерін тіркеңіз. Бұл уақыт белгілері әртүрлі сұрақтарға жауап береді. Сканерлеу оқиғасының уақыты тасымалдаушы оны жариялаған сәттен ертерек болуы мүмкін, сондықтан тек сканерлеу уақытын шегеру бақылау провайдерінің кідірісін бөлек көрсетпейді.

Эталондық тексерулер өлшеу белгісіздігін туындатады. Егер тасымалдаушы көзін аралықпен тексерсеңіз, оқиғаны алғаш көрген уақытыңызды білесіз, бірақ оның нақты жарияланған уақытын білмейсіз. Осы аралықты құжаттап, нәтижені провайдердің нақты өңдеу уақыты емес, бақыланған кідіріс ретінде сипаттаңыз.

Үлгі жеткілікті болған жағдайда маңызды сегменттер бойынша медиана мен p95 сияқты шеткі процентильді есеп беріңіз. Үлгі көлемін қосыңыз. Жылдам медиана жөнелтілімдердің аз, бірақ операциялық тұрғыдан маңызды тобына әсер ететін ұзақ кідірістерді жасыруы мүмкін.

Шешім ережесі: Кідіріс мақсаттарын әрекетке байланыстырыңыз. Күнделікті есеп беру процесі мен уақытқа сезімтал ерекше жағдай туралы хабарландырудың шегі бірдей болмауы керек. Жетіспейтін жаңартулар кідіріс нәтижелерінен жоғалмай, толықтық есебінде көрініп тұруы тиіс.

5. Webhook жеткізу сенімділігі

Сұрақ: Күтілетін жаңартулар, соның ішінде жеткізу уақытша сәтсіз болған жағдайларда да, қабылдаушы қолданбаңызға жете ме?

Формула: Webhook жеткізу сенімділігі = келісілген терезе ішінде тұрақты түрде қабылданған бөлек күтілетін хабарландырулар ÷ барлық күтілетін хабарландырулар × 100.

Күтілетін хабарландырулар жиынын құжатталған жазылым ережелерінен, байқалған бастапқы өзгерістерден және басқарылатын тестілерден анықтаңыз. Әрбір шикі тасымалдаушы сканерлеуі бөлек хабарландыру тудыруы тиіс деп болжамаңыз. Егер күтілетін жиынды тәуелсіз анықтау мүмкін болмаса, нәтижені толық жеткізу сенімділігі деп мәлімдемей, ішінара нәтиже ретінде есеп беріңіз.

Уақытша сервер қателерін, байланыс үзілуін, қайталанған хабарламаларды, кешіктірілген растауларды және қалпына келуді тексеріңіз. Құжатталған қайталап көру әрекеттерін және олар тоқтағаннан кейін не болатынын растаңыз. Үздіксіз тестілер үшін өндірістік емес жөнелтілімдерді немесе оқшауланған ортаны пайдаланыңыз.

HTTP әрекеттерін емес, бөлек хабарландыруларды санаңыз. Қайталанған жеткізу әрекеттері алымды ұлғайтпауы керек. Қолданбаңыздың жобасына сәйкес хабарды қауіпсіз жазып алғаннан немесе кезекке қойғаннан кейін ғана endpoint қабылдауды растауы тиіс.

Провайдердің жеткізуін және ішкі өңдеуді бөлек есептеңіз. Webhook сәтті келіп, қолданба тапсырысты жаңартпауы мүмкін. Қайталанған хабарламалар клиентке қайталама хабарландырулар жасамайтындай, идемпотентті өңдеуді тексеріңіз.

Шешім ережесі: Қалыпты жағдайдағы сәтті жеткізуді ғана емес, жіберілген жаңартуларды қалпына келтірудің дәлелденген жолын талап етіңіз.

6. API сұрауларының сенімділігі

Сұрақ: API күтілетін жүктеме кезінде сәтті жауап бере ме?

Формула: API сұрауларының сенімділігі = белгіленген тайм-аут ішінде күтілетін, талдауға болатын жауап қайтаратын жарамды сұраулар ÷ жасалған барлық жарамды сұраулар × 100.

Жарамды сұрауды құжатталған аутентификация, пайдалы жүктеме және келісілген сұрау шектері арқылы анықтаңыз. Құрылымы қате сұрауларды интеграция ақаулары ретінде бөлек бақылаңыз. Сондай-ақ жиынтық ұпай түсінікті болуы үшін шектеуге ұшырауды, аутентификация қателерін, тайм-ауттарды және сервер қателерін жеке есептеңіз.

Жөнелтілімді тіркеуді, алуды және іске асыруыңыз нақты пайдаланатын басқа endpoint-терді тексеріңіз. Тек оқу операциясының сәтті тесті жаппай бастапқы енгізудің қолайлы болатынын дәлелдемейді.

Сенімділікпен қатар жауап беру уақытының процентильдерін өлшеңіз. Бірінші әрекеттегі сәттілікті қайталап көруден кейінгі түпкілікті сәттіліктен бөлек көрсетіңіз: қайталап көру операцияны қалпына келтіруі мүмкін, бірақ кідіріс, трафик және өңдеу жұмысын арттырады.

Google компаниясының Site Reliability Engineering нұсқаулығы кідірісті, трафикті, қателерді және қанығуды пайдалы бақылау сигналдары ретінде анықтайды. Сәтсіздіктермен қатар сұрау көлемі мен параллельділікті тіркеп, осы құрылымды POC-қа қолданыңыз. Трафик жасамас бұрын жүктеме тестінің шектерін келісіңіз.

Шешім ережесі: Қысқа POC нәтижесін ұзақ мерзімді қолжетімділіктің дәлелі немесе келісімшарттық міндеттемелерді алмастыратын нәрсе емес, тек тексерілген жүктеме мен кезең туралы дәлел ретінде қарастырыңыз.

7. Интеграция және қалпына келтіру жұмысы

Сұрақ: Интеграцияны қауіпсіз пайдалануға дайындау үшін қанша инженерлік жұмыс қажет?

Негізгі өлшем: Интеграцияға жұмсалатын күш = келісілген өндірістік дайындық бақылау тізімін аяқтауға қажетті тіркелген инженерлік сағаттар.

Әр іске асыру үшін бірдей бақылау тізімін пайдаланыңыз. Аутентификацияны, тіркеуді, webhook қабылдауды, мәртебелерді сәйкестендіруді, қайталануды жоюды, салыстырып тексеруді, мониторингті, тіркелгі деректерін өңдеуді, орналастыруды және операциялық құжаттаманы қосыңыз. Күнтізбелік өткен уақытты нақты инженерлік жұмыс уақытынан бөлек тіркеңіз.

Алғашқы сәтті сұраудан кейінгі жұмысты өлшеңіз. Жылдам демонстрация қателерді өңдеуде, тарихи қалпына келтіруде және қолдау құралдарында елеулі жұмыс қалдыруы мүмкін.

Қалпына келтіру жаттығуын өткізіңіз: тұтынушыңызды тоқтатыңыз, оны қалпына келтіріңіз және зардап шеккен жөнелтілім күйлерін салыстырып тексеруге болатынын анықтаңыз. Қалпына келтіру уақытын, қолмен араласуды және шешілмеген жазбаларды тіркеңіз. Қай мәселелер қолданбаңыздан, ал қайсысы провайдердің көмегін қажет ететінін белгілеңіз.

Шешім ережесі: Күшті тек бірдей дайындық деңгейінде салыстырыңыз. Мониторингі жоқ прототип тексерілген қалпына келтіруі бар өндірістік дайын іске асырудан интеграциясы оңай болып көрінбеуі керек.

8. Пайдалануға жарамды бақыланған жөнелтілімнің құны

Сұрақ: Талаптарыңызға сай жөнелтілім ақпаратын алу қанша тұрады?

Формула: Пайдалануға жарамды бақыланған жөнелтілімнің құны = кезеңдегі есептелетін жалпы операциялық шығын ÷ сол кезеңде келісілген пайдалану жарамдылығы критерийлеріне сай келетін бірегей жөнелтілімдер.

Есептеу тәртібін өзіңіз болжамай, жазбаша баға ұсынысын немесе қолданылатын коммерциялық шарттарды пайдаланыңыз. Тіркеу әрекеттері, қайталама жіберулер, қайта бақылау, артық көлем, тарихи қолжетімділік және бөлек ақылы қызметтер қалай есептелетінін растаңыз. Бұл — тексерілуі тиіс сұрақтар, алдын ала қабылданатын төлемдер емес.

Ішкі жалпы құнды есептегенде инфрақұрылым мен қайталанатын операциялық жұмысты қосыңыз. Бір реттік іске асыру құнын бөлек көрсетіңіз немесе оның қандай кезеңге амортизацияланатынын ашып жазыңыз.

POC-та тексерілген жөнелту қоспасын пайдаланып, күтілетін және ең жоғары жөнелту көлемдерін модельдеңіз. Болжамдарды бағалау ретінде белгілеңіз. Сенімді операциялық шығын деректері қолжетімсіз болса, провайдер алымдарына қатысты тарлау көрсеткішті есептеп, қандай шығындар қосылмағанын көрсетіңіз.

Шешім ережесі: Шығындарды ең төменгі сапа талаптары орындалғаннан кейін ғана салыстырыңыз. Тіркелген бақылау нөмірінің төмен құны пайдалы нәтиженің төмен құнын білдірмейді.

Нәтижелерді іске қосу туралы шешімге айналдырыңыз

Әр KPI анықтамасын, қабылдау шегін, байқалған нәтижені, үлгі көлемін, сегменттер бойынша бөліністі, шешілмеген жағдайларды және жауапты тұлғаны қамтитын бағалау кестесін жасаңыз. Нәтижелерді қарамас бұрын шектерді белгілеңіз. Әрбір жөнелту операциясына сай келетін әмбебап өту пайызы жоқ.

Маңызды қамту, қауіпті мәртебе қателері, қалпына келтіру мүмкіндігі және басқа да міндетті талаптар үшін міндетті қақпаларды пайдаланыңыз. Салмақталған бағалауды осы қақпалардан өткеннен кейін ғана қолданыңыз. Әйтпесе төмен баға немесе жылдам жауап беру уақыты елеулі операциялық сәтсіздікті математикалық тұрғыда жасыруы мүмкін.

Үш нәтиженің бірін таңдаңыз: шектеулі іске қосуды мақұлдау, көрсетілген белгісіздіктерді шешу үшін POC-ты ұзарту немесе тексерілген конфигурациядан бас тарту. Ұзарту қандай дәлел жетіспейтінін және оны жабатын шартты көрсетуі керек. Іске қосу кезінде өндірістік өнімділік салыстырмалы болып қалуы үшін сол анықтамалар бойынша мониторингті жалғастырыңыз.

Егер 17TRACK қысқа тізіміңізде болса, тестіңізге қатысты интеграция талаптарын растауды бастау үшін оның Tracking API page және official API documentation беттерін пайдаланыңыз. Сол бағалау кестесі мен нақты жөнелтілім тексерулерін қолданыңыз; құжаттаманы қарау өлшенген нәтижелердің орнын баспайды.

Жиі қойылатын сұрақтар

Бақылау API-інің POC нұсқасына қанша жөнелтілім қосылуы керек?

Әмбебап үлгі көлемі жоқ. Әрбір бизнес үшін маңызды сегментті және жұмыс процестеріңізге әсер ететін ерекшеліктерді бағалауға жеткілікті бақылау қосыңыз. Сегмент деңгейіндегі санақтар мен белгісіздікті көрсетіңіз. Бір тасымалдаушыға шоғырланған үлкен үлгі тексерілмеген тасымалдаушылар немесе бағыттар бойынша сенімділікті дәлелдей алмайды.

Құмсалғыш нақты жөнелтілімдерді тестілеуді алмастыра ала ма?

Құмсалғыш сұраулардың құрылуын, талдауды және қолданба әрекетін тексере алады. Бірақ ол нақты оқиғалардың толықтығын, тасымалдаушының жариялау кідірістерін немесе өндірістік хабарландыру өнімділігін өздігінен дәлелдей алмайды. Оны нақты тестілеумен қатар пайдаланыңыз, оның орнына емес.

Тасымалдаушының веб-сайты мен API сәйкес келмесе не істеу керек?

Екі жазбаны да бақылау уақыттарымен бірге сақтаңыз. Кінәні анықтамас бұрын уақыт белдеуін түрлендіруді, жөнелтілім сәйкестігін, жариялау уақытын және мәртебені түсіндіруді тексеріңіз. Екі дереккөз де айырмашылықты шешпесе, оны шешілмеген деп белгілеп, сәттілік немесе сәтсіздік белгісін күштеп қоймай зерттеңіз.

Жетіспейтін оқиғалар баяу жаңартулар ретінде есептелуі керек пе?

Өлшемдерді бөлек ұстаңыз. Ешқашан келмеген оқиға дәлелге байланысты толықтықтың сәтсіздігі немесе шешілмеген жағдай болып табылады. Кідіріс келген оқиғаларды өлшейді. Жетіспейтін оқиғалар кідіріс өнімділігін жасанды түрде жақсы етіп көрсетпеуі үшін екеуін бірге есептеңіз.

POC өткеннен кейін не болуы керек?

Бақыланатын ауқымға енгізіңіз, салыстырып тексеру және кері қайтару рәсімдерін сақтаңыз, сол KPI көрсеткіштерін бақылауды жалғастырыңыз. Өндірістік нәтижелер қолдаған жағдайда ғана кеңейтіңіз. Тасымалдаушылар қоспасы, жөнелту көлемі, интеграция конфигурациясы немесе коммерциялық шарттар өзгергенде қайта бағалаңыз.

Дереккөздер

• Google Site Reliability Engineering: Monitoring Distributed Systems — кідірісті, трафикті, қателерді және қанығуды қоса алғанда, сұрау сенімділігі туралы талқылаудың негізіндегі мониторинг қағидалары.
• 17TRACK Tracking API — 17TRACK API бағалауын қарастыратын командаларға арналған ресми өнім анықтамасы.
• 17TRACK API Documentation — іске асыруға тән тестілерді жобаламас бұрын интеграция талаптарын тексеруге арналған ресми құжаттама.