Алаңдағы қызметкерлерге офлайн-синхрондау: деректер жоғалмауы үшін

Алаңдағы командалардағы проблема және деректер неге жоғалады

Қарапайым офистегідей байланыс далада өте сирек болады. Қазір 4G, кейін 2G, кейін подвал, лифт немесе елді мекендер арасындағы жол — байланыс үзіліп-қосылады. Қолданба үшін бұл тек «баяу» емес: сұраулар үзіліп қалады, жауаптар кешігіп келеді немесе бірнеше рет қайталанады. Нәтижесінде қызметкер енгізген дерек сақталмайды немесе жартылай сақталады.

Көбінесе жоғалатын нәрсе «үлкен деректер» емес, ең құнды кішкентай жұмыс элементтері: толтырылған формалар (тексеру актісі, чек-лист), фотосуреттер мен қолтаңбалар, статус өзгерістері («принято», «в работе», «закрыто»), комментарийлер, көрсеткіштер, координаттар және келу уақыты. Ең жағымсыз сценарий — бір жол немесе бір фото ғана жоғалу: қызметкер «жібердім» деп ойлайды, ал серверде бұл жоқ.

Пайдаланушы үшін «офлайн» көбіне былай келеді: «мен әдеттегідей жұмыс істеймін, кейін бәрі өзі жіберіледі». Шындық жиі басқа: қолданба жасыл «галочка» көрсетеді, бірақ деректер тек телефонның жадында ғана қалуы мүмкін. Немесе жіберу барысында тұрып қалып, келесі тапсырмаға өтуге мүмкіндік бермейді. Тағы бір проблема — дубльдер: қызметкер «Сохранить» түймесін бірнеше рет басады, себебі байланыс «ойлануда», және серверге бірдей жазбалар бірнеше рет жіберілуі мүмкін.

Офлайн-синхрондаудың мақсаты — тек «интернеттің қайтуын күту» емес. Ол екі нәтижені кепілдендіргені жөн: өзгерістер жоғалмауы тиіс және олар дұрыс түрде қолданылуы керек. «Дұрыс» дегеніміз — жүйе әрекеттер тізбегін түсіне алады, дубльдер жасамайды және басқа адамның түзетулерін үнсіз басып тастамайды. Егер өзгерістер қайшылыққа келсе, қолданба алдын ала белгіленген ережелерге сәйкес нұсқаны таңдайды немесе адамнан растауды сұрайды.

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

Негізгі ұғымдар: не синхрондаймыз

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

Кэш — «жылдам қолжетімділікке арналған көшірме». Ол әлсіз байланыс кезінде клиент картасын, мекенжайды немесе өтініштер тарихын ашуға көмектеседі. Бірақ кэш өзі өзгерістердің серверге жететініне кепіл бермейді. Ол үшін құрылғыдағы локальды дерекқор қажет: қолданба қайта іске қосылғанда, телефон қайта жүктелгенде немесе уақытша ақау болғанда деректерді қалпына келтіруге мүмкіндік беру үшін.

Синхрондау — бұл құрылғы мен сервер арасындағы өзгерістер алмасуы, ережелер бойынша. Синхрондалатын нәрсе — «экранның бәрі» емес, нақты объектілер: өтініштер, статустар, комментарийлер, фото, қолтаңбалар, көрсеткіштер, координаттар.

Оқу және жазу — әртүрлі міндеттер

Оқуға көбіне алдын ала деректер жүктеп қою және желі пайда болғанда жаңарту жеткілікті. Проблема қолданушы бір нәрсені өзгертсе басталады: статус «выполнено» қояды, фото қосады, мекенжай түзетеді немесе бөлшекті ауыстырғанын белгілейді.

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

Өзгерістер кезегі (очередь) дегеніміз не және неге қажет

Өзгерістер кезегі — серверге жеткізу керек операциялар тізімі. Мұнда «жаңа версияны сақтау» емес, нақты әрекеттер сақталады: жазба құру, өрістерді жаңарту, файлды тіркеу, жұмысты жабу.

Кезек «кес-кесте» байланыстан туындайтын жағдайларға қажет: сұрау жіберілген, бірақ жауап келмеген болуы мүмкін; қолданба жабылуы мүмкін; телефон желіні ауыстыруы мүмкін. Кезек болғанда қолданба жіберуді қауіпсіз және дұрыс тәртіппен қайталай алады.

Маңызды: «кейін жіберсе жеткілікті» деген қарапайым тәсіл жиі жұмыс істемейді. Біріншіден, контекст жоғалады — қолданушы не істеген және қандай реттілікпен істегені анық емес. Екіншіден, қайта жіберуді ескерместен дубльдер немесе жартылай қолданылған өзгерістер пайда болуы оңай (мысалы, статус өзгеріп, ал фото жіберілмей қалады).

Шынайы дереккөзі: қайсы нұсқа дұрыс

"Шынайы дереккөзі" — финалдық дерек қайда сақталатынын айтады. Көбінесе бұл сервер: ол барлық құрылғыларды көреді және жалпы ережелерді қолданады. Бірақ офлайн-сценарийлерде шындықтың бір бөлігі уақытша құрылғыда болады: желі жоқ кезде дәл сол құрылғы қызметкердің не істегенін біледі.

Сондықтан алдын ала ережелер белгіленеді. Қай өрістерді тек сервер өзгертетіні (мысалы, соманы есептеу), қайсысын құрылғыдан өзгертуге болатыны (статустар, комментарийлер), және бір өтінішті екі жақтан бір уақытта өзгертсе не істеу керек — осы анықталады. Бұл дауларға әкеледі, бірақ алдымен база — локальды сақтау + өзгерістер кезегі + анық шынайы дереккөзі — орнатылуы тиіс.

Өзгерістер кезегі: оны қалай дұрыс ұйымдастыру керек

Өзгерістер кезегі — офлайн-режимнің жүрегі. "Экранның суреттерін" немесе толық кестелерді сақтау орнына операцияларды сақтаңыз: құру, өзгерту, жою. Осылайша қызметкердің не істегенін нақты білесіз және байланыс қалпына келгенде бұл әрекеттерді қауіпсіз қайталауға болады.

Практикалық ереже: әр қолданушы әрекетін кезектегі жеке оқиғасына айналдырыңыз. Сол кезде қолданба өз-өзімен «қақтығыспайды» және жартылай жіберулер кезінде түзетулердің мәні жоғалмайды.

Оқиғаға не жазылады

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

Практикада бұл бірнеше өріске келеді: қолданушы немесе құрылғы идентификаторы; жасау уақыты (локальды және мүмкін болса монотонды есептегіш); объект түрі және жазба ID; өзгертілген өрістер плюс нұсқа/ревизия; техникалық жеткізу өрістері (оқиғаның уникалды ID-сі, статус, талпыныстар саны).

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

Идентификаторлар мен реттік тәртіп

Интернет жоқ кезде «келесі нөмірді база береді» дегенге сенуге болмайды. Сондықтан локальды түрде уникалды ID (мысалы, UUID) жасаңыз және оларды синхрондауға дейін қолданыңыз. Сервер ресми идентификаторды қайтарғанда сәйкестікті сақтап, сілтемелерді жаңартыңыз. Сонымен бірге бұрын жасалған оқиғаларды артқа қарай жазбай тұрған абзал.

Реттілік бір жазбаға қатысты қарапайым болуы тиіс: кезек жазбаға арналған дара реттілікпен болуы керек. Қызметкер өтініш жасаса, кейін оған фото мен комментарий қосса, осы оқиғалар сол тәртіпте қолданылуы тиіс. Ыңғайлы тәсіл — операцияның локальды номерін (1, 2, 3...) сақтау және оны өзгертпеу.

Байланыс қалпына келгенде оқиғаларды бір-бірлеп немесе шағын пачкаларда жіберіп, қолданылғандарын растап отыру керек. Егер пачка ортасында үзіліп қалса, прогресс сақталады: расталғандары қалпына келтірілмейді, қалғандары қайта жіберіледі.

Қайталап жіберу дубльге айналмау үшін үш қағиданы ұстаныңыз:

• оқиғаның уникалды ID-сы және сервердегі идемпотенттік (сол ID-мен қайта жіберу қосымша жазба жасамайды);
• кезектегі түсінікті статустар (жаңа, жіберілуде, расталған, қате);
• жазбаның нұсқасын бекіту: егер нұсқа сәйкес келмесе, оқиға қақтығысқа түседі, автоматты түрде «көзге көрінбестен» қолданылмайды.

Осылайша кезек болжамды қалады: байланыс жоғалды — сіз жұмыс істей бересіз, байланыс келді — бәрін жоғалтпай, дубльсіз жібересіз.

Локальды сақтау: желі жоқта тәуліктен қалай аман қалу

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

Локальдыда не сақтау керек

Локальды сақтау тек "Сохранить" батырмасының нәтижесін ғана емес, аралық күйді де сақтауы қажет. Бұл ұзын формалар үшін аса маңызды: акт, чек-лист, объектіні тексеру, комментарийлері бар өтініш. Бірнеше секунд сайын автосақтау (және қолданба свёрнут болғанда) телефон қоңырауы, қайта жүктеу немесе кенет жабылудан болатын жоғалуларды қатты азайтады.

Деректермен қатар түсінікті статус сақтау пайдалы: «черновик», «жіберуге дайын», «жіберілді», «тексеруді қажет етеді». Пайдаланушы жазба жоғалғанын сезбеуі тиіс, тіпті егер байланыс жарты күн бойы болмаса да.

Локальды сақтау шамадан тыс орын алмауы үшін шектеулерді алдын ала ойлаңыз. Негізгі көлем әдетте фотолар, файлдар және қолтаңбалар береді. Типтік сценарий: инженер 10 сурет тіркейді, ал байланыс кешке ғана келеді. Егер құрылғыда жад аз болса, қолданба сусылап немесе құлап қалады — және деректер тағы да қауіп астында болады.

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

Қауіпсіздік пен тазалау

Офлайн-деректерде жеке тұлғалар туралы мәліметтер мен объектінің деректері болуы мүмкін. Сондықтан локальды сақтау шифрлануы керек, ал қолданбаға кіру PIN-код немесе биометрия арқылы қорғалуы тиіс. Бұл құрылғы жоғалған кезде маңызды.

Сақтауды тазалау саясаты да қажет: не және қашан жою керек. Мысалы, жіберілген жазбаларды 30 күннен кейін автоматты түрде өшіру, бірақ соңғы 100 жазбаны тарих үшін қалдыру. Қателер мен «тұрып қалған» черновиктерді белгілеп, қолданушыға шешім ұсынған дұрыс: қайта жіберу, біріктіру немесе жоюды растау арқылы.

Сенімді жеткізу: өзгерістерді қалай жоғалтпай жіберу

Байланыс үзіліп қалғанда басты қауіп — өзгерістер мүлдем жіберілмеу емес, жартылай немесе екі рет жіберілуі. Сондықтан "жеткізілген" деген не және қорғалған қайталап жіберу қалай болады дегенге келісу маңызды.

Қайталап жіберу және дубльдер жоқтығы

Жұмыс ережесі: клиент бір өзгерісті қайта жіберсе де, сервер оны алғаш келгендей өңдеуі қажет. Әр өзгерісқа уникалды идентификатор (мысалы, UUID) беріледі. Сервер осы идентификатор бойынша өңдеу фактін сақтап, қайталап келгенде дәл сол нәтижемен жауап береді, дубль жасамай.

Практикада «жеткізілді» әдетте үш қадамды білдіреді: сервер сұрауды қабылдап, өзгерісті жазды; сол идентификатормен растау қайтарды; клиент растаманы локальда сақтап, өзгерісті орындалған деп белгілейді.

Егер растау жетпесе (таймаут, үзіліс), клиент болжам жасамайды. Ол кейін қайта жібереді, себебі идемпотенттік дубльден қорғайды. Жартылай сәтсіздіктер кезінде қателерді жіктеу маңызды: «желіге қосылмады» (қайта жібереміз) және «сервер өзгерісті қабылдамады» (тоқтатып, себебін қолданушыға көрсету).

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

Мысал: инженер подвалда бір өтініш үшін 12 әрекет жасады (фото, статус, материалдар). Байланыс бір минутқа пайда болды. Қолданба 5 әрекеттен тұратын пакетті жіберді, сервер 4-ін растады, ал 5-шіде қосылыс үзіліп қалды. Клиент 4-ін «жеткізілген» деп белгілеп, 5-ші оқиғаны кезекте қалдырып, кейін қайта жібермек.

Шынымен көмектесетін логтар

Логтарсыз «деректер жоғалды» дегенді талқылау дауласуға айналады. Кем дегенде келесілерді тіркеу жеткілікті: өзгеріс идентификаторы және оны құрылғыда жасау уақыты; әр жіберу талпынысының уақыты мен нәтижесі (сәттілік, таймаут, бас тарту); сервер қатесінің коды және қысқа хабар; дерек нұсқасы (мысалы, жазба нөмірі) және қолданушы; құрылғы немесе қолданба орнатылымының идентификаторы.

Осы жазбалар қайда ақау болғанын жедел анықтауға көмектеседі — құрылғыда ма, желіде ме, серверде ме — және деректер жоғалмағанын, олар қайта жіберуді күтетінін дәлелдейді.

Деректер қақтығысы: қалай тануға және шешуге

Қақтығыс — бір өріс не құжат екі жақтан өзгертіліп, синхрондау кезінде кездескенде пайда болады. Типтік жағдай: выездтік қызметкер мекенжайды түзетіп, оффлайнда комментарий жазды; сол уақытта диспетчер офисде өтініштің статусын өзгертті. Жақсы байланыста мұндай сирек байқалады, бірақ нашар байланыста өзгерістер бірнеше сағатқа дейін «айырылып» қалуы мүмкін.

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

Шешу стратегиялары

Стратегияны алдын ала шешіп қою керек, дерек түріне қарай:

• «соңғы өзгеріс жеңеді» — қарапайым, бірақ маңызды өрістер үшін қауіпті;
• рөлге басымдық — мысалы, статус пен финалдық жабуды диспетчер шешеді, ал көрсеткіштер мен фотоларды тек полевик енгізеді;
• өрістер бойынша шешу — статус серверден алынады, ал ескертпелер мен тіркемелер біріктіріледі;
• қолданушы таңдайды — автоматты түрде дұрыс нұсқаны анықтау мүмкін емес болғанда.

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

Интерфейсте пайдалы нәрселер: тек қақтығысқа түскен өрістерді ерекшелеу; «кім өзгертті» және «қашан» деген белгілер (мүмкін болса, сервер уақыты бойынша); "менікі қалсын" және "серверді қабылдау" батырмалары мен алдын ала қарау; тарихта «қақтығыс шешілді» мәртебесін белгілеу.

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

Тәжірибелік мысал: выездтік өтініш және екі жақтағы өзгерістер

Техник объектке барып, подвалға түседі — онда байланыс нашар. Қолданбада өтініш ашық: мекенжай, контакт, жұмыстар тізімі және акт алаңшасы. Ол орындалған тармақтарды белгілейді, 3 фото түсіреді, комментарий жазады және клиенттің қолын экранда алады.

Сол уақытта диспетчер офисінде клиент басқа жауапты тағайындауды сұрайды және мекенжайды (басқа кіре беріс) нақтылайды. Диспетчер өтініштің мекенжайын өзгертеді және статусын "В работе"-тан "Ожидает запчасть"-қа ауыстырады.

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

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

Содан кейін қақтығыс пайда болуы мүмкін: серверде диспетчердің жаңартқан мекенжайы мен статусы бар, ал техник кезегінде әлі «ескі» өрістер бар. Жақсы қолданба бәрі тамаша деп көрсетпейді. Ол сервердегі мекенжайды қабылдап, қайшылық тудыратын өрістер жанында «тексеруді талап етеді» белгісін көрсетеді. Статус та қайшылықты болуы мүмкін: техник жұмысты орындағанын жазған, ал диспетчер запчасть күтуді қойған.

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

Офлайн-синхрондауды енгізудің қадамдық жоспары

Қадам бойынша не істеу керек

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

Келесі — деректер моделі мен идентификаторларды таңдау. Әр объектінің тұрақты ID-сі болуы керек, оны құрылғыда жасайды және синхрондаудан кейін өзгермейді. Бұл байланыс үзіліп болғанда дубльдердің санын азайтады.

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

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

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

Мәліметтерді жоғалтпау үшін тестілеу

Тестіде эмулятордан ғана бас тартпаңыз. Шағын выезд топтары қолданатын нақты құрылғыларда тексеріңіз (корпоративтік ПК мен моноблоктарды қоса).

Офлайн-режимді ең жиі бұзатын сценарийлерді тексеріңіз: жіберу кезінде кенет үзіліс және 5–30 минут кейін қалпына келу; бір тәуліктен астам интернетсіз жұмыс және жиналғандардың барлығын бірден жіберу; үлкен тіркемелер (фото, скан) және жартылай жүктелген файлдар; бір жазбаны екі құрылғыдан параллельді өзгерту; толтырылған черновик кезінде қолданушының шығуы немесе аккаунт ауыстыру.

Әр тесттен кейін сіз деректер қайда екенін және келесі қадамда не жіберілетінін нақты айта алсаңыз, негізгі контур пилотқа дайын.

Офлайн-режимдегі типтік қателер мен тұзақтар

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

Деректер жоғалтуға әкелетін жиі қателер

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

"Черновик" пен "жіберілді" күйін араластыру да қауіпті. Онда қолданушы не серверге жеткенін, не тек құрылғыда екенін түсінбейді. Сондай-ақ қақтығыстар: қолданба өзгерістерді үнсіз біріктіріп, бір нұсқаны таңдап, екіншісін жоғалтады.

Тіркемелер бөлек қауіп аймағы. Фотоларды/видеоларды/скандарды шектеусіз және қысусыз сақтағанда құрылғыдағы орын тез толып, кейін тіпті мәтін де сақталмай қалады. Соңында интерфейстің нашар коммуникациясы: не синхрондалмағаны және не себепті салғаны түсініксіз.

Егер сізде төмендегідей белгілер болса, офлайн-режиміңіз қауіпсіз емес: жазбаның айқын статусы жоқ (черновик, кезекте, жіберілді, қате); қайта жібергенде дубльдер пайда болады; қақтығыстар қолданушыға сұрамастан шешіледі және журнал сақталмайды; тіркемелер бақылаусыз жиналып, тазаланбайды; қандай өрістер серверге жетпегені белгісіз.

Практикалық сақтық шаралары

Мысал ретінде выездтік инженері ойлап көрейік: ол акт толтырып, 6 фото түсіріп, "Готово" батырмасын басады подвалда. Егер қолданба бәрін айқын сақтамаса, ол жарты сағаттық жұмысын жоғалтады. Егер сақтағанымен "в очереди: 1 акт, 6 фото" деген анық көрсетпесе, ол әрі қарай жүреді де, жіберілмегенін байқамайды.

Қорғаныс қарапайым және көрнекті болуы керек: айқын сақтау және автосақтау растамасы; операция идентификаторы бойынша қауіпсіз қайталап жіберу; статустар мен тарих (не өзгертілді, не жіберілді, не қайтарылды); қарапайым қақтығыс терезесі «ваша версия» және «версия на сервере»; тіркемелерге мөлшер мен сан бойынша шектеу, қысу және тазалау.

Егер бұл сценарийлер корпоративтік ортада (жұмыс станциялары, ноутбуктер немесе планшеттер) жүзеге асырылса, ережелер аппараттан тәуелсіз бірдей маңызды. Пайдаланушы әрдайым білуі тиіс: не локальда сақталған, не серверге жеткен және не назар аударуды қажет етеді.

Релиз алдында чек-лист және әрі қарай не істеу

Релиз алдында тек "интернетсіз жұмыс істей ме" ғана емес, байланыс үзілістерінде мінез-құлықтың болжамдылығын тексеріңіз. Негізгі мақсат — кез келген әрекет сақталады және байланыс жарты жолда үзіліп қалса да жоғалмайды.

Релиз алдындағы чек-лист

Бес тексеріс, әдетте көп тосынсыйды пилотқа дейін дер кезінде табады:

• Кез келген әрекет (құру, түзету, комментарий, фото) алдымен сенімді түрде локальды сақтау мен кезекке түседі, қолданба жадысында "желі күтуі" емес.
• Кезекте статустар бар: "в очереди", "отправляется", "доставлено", "ошибка", және қолданушы не істеу керек екенін көреді.
• Қайталап жіберу дубль жасамайды: бірдей операция бірдей идентификатормен екі өтінішті немесе екі бірдей есептен шығаруды тудырмайды.
• Қақтығыстарға ережелер бар және автоматты шешім жоқ кезде қолданушыға қарапайым таңдау ұсынылады.
• Тіркемелер нашар байланысқа дайын: фотоларды қысу, үзілістен кейін жалғастыру, мөлшер шектеуі және файл тым ауыр болса анық көрсету.

Тексеру сценарийі: шебер объектте өтініш статусын өзгертеді және 3 фото тіркейді, байланыс жоғалады, кейін 2 минутқа қайта пайда болады, тағы жоғалады. Мұндай секірулерден кейін сағаттың соңында деректер серверге жетіп, қолданушы не жіберілгенін көре білуі тиіс.

Әрі қарай не істеу керек

Келесі қадам — бір командада (5–15 адам) нақты тапсырмалар бойынша пилот өткізу. Пилот барысында қай хабарламалар түсініксіз, қай кезек «құрысып қалатыны» және қай қақтығыстар жиі болатындығы анық көрінеді.

Параллельді түрде құрылғыларды қолдауды және орнатуды ретке келтіріңіз: ОС пен қолданба бірдей нұсқалары, бос орынды бақылау, камера мен файлдармен жұмыс ережелері, лог жинау. Егер жоба GSE.kz (gse.kz) компаниясымен бірге жүзеге асырылатын болса, құрылғылар, сервер жағы және қолдау регламенттерінің жауапкершілігін алдын ала бөлу ыңғайлы. Бұл жұмыс станцияларынан серверге дейінгі біріккен шешімді және тәулік бойғы техникалық қолдауды ұйымдастырғанда әсіресе қолайлы.