API integracija: kas nutinka, kai duomenys nesutampa?

Blogiausias integracijos gedimas nėra nutrūkęs ryšys. Nutrūkęs ryšys pastebimas: kažkas nustoja veikti, kažkas paskambina. Blogiausias gedimas yra tylus – abi sistemos atsakinėja, niekas nerodo klaidos, bet skaičiai jose nebesutampa. Toks neatitikimas paprastai pastebimas mėnesio gale, kai jau nebeaišku, kuris skaičius teisingas ir nuo kada.

Trumpai

• Susitarkite, kuri sistema yra tiesos šaltinis kiekvienam duomenų tipui. Be šio susitarimo neįmanoma išspręsti nė vieno neatitikimo.
• Kartojimas po klaidos yra būtinas, bet be atpažinimo ženklo jis kuria dublikatus.
• Pranešimas gali būti pristatytas du kartus – projektuokite taip, kad antras kartas nieko nesugadintų.
• Neatitikimai turi būti matomi patys, o ne aiškinami po fakto. Reikia bent minimalaus suderinimo patikrinimo.
• Ribos tarp sistemų yra ir atsakomybės ribos: užrašykite, kas ką taiso, dar prieš pirmą incidentą.

Kodėl tyli klaida pavojingesnė už garsią

Kai integracija nukrenta visiškai, problema turi savininką ir laiką. Kai ji veikia iš dalies, problema kaupiasi. Tipiniai atvejai: pranešimas išsiųstas, bet atsakymas nepasiektas, todėl siuntėjas mano, kad nepavyko, ir pakartoja; laukas pervadintas vienoje sistemoje, o kita toliau rašo į senąjį; du žmonės tuo pačiu metu redagavo tą patį įrašą, ir laimėjo tas, kuris išsaugojo vėliau. Nė vienas šių atvejų nerodo klaidos ekrane.

Kaip atsiranda dublikatai

Daugumoje integracijų pristatymas yra „bent kartą“, o ne „lygiai vieną kartą“. Praktiškai tai reiškia, kad tas pats pranešimas gali atvykti antrą kartą – po tinklo trikties, po kartojimo, po perkrovimo. Jei gaunanti pusė kiekvieną gautą pranešimą traktuoja kaip naują faktą, gaunami du įrašai vietoje vieno. Tai ne teorinė rizika, o normali tinklo elgsena.

• Siuntėjas nepagavo atsakymo ir pakartojo, nors pirmas kartas buvo įrašytas.
• Tarpinė paslauga pakartojo pranešimą pagal savo tvarkaraštį.
• Rankinis pakartojimas po incidento, nežinant, kiek jau buvo apdorota.
• Du skirtingi šaltiniai perdavė tą patį įvykį skirtingu formatu, ir jie neatpažinti kaip tas pats.
• Importas paleistas antrą kartą, nes pirmas atrodė nepavykęs.

Atpažinimo ženklas: paprasčiausia apsauga

Sprendimas paprastas ir dažnai praleidžiamas: kiekvienas pranešimas turi turėti stabilų, siuntėjo sukurtą atpažinimo ženklą, o gaunanti pusė turi jį įsiminti. Jei tas pats ženklas atvyksta antrą kartą, veiksmas nekartojamas ir grąžinamas tas pats atsakymas kaip pirmą kartą. Svarbu, kad ženklas būtų susietas su įvykiu, o ne su bandymu – kitaip kiekvienas kartojimas atrodys kaip naujas įvykis.

• Ženklą kuria siuntėjas ir jis nesikeičia kartojant tą patį įvykį.
• Gaunanti pusė saugo apdorotus ženklus tiek laiko, kiek realiai gali užsitęsti kartojimas.
• Pakartotinis tas pats ženklas grąžina tą patį rezultatą, o ne klaidą – kitaip siuntėjas kartos be galo.
• Kartojimas daromas su didėjančiais intervalais, o ne iš karto ir be pabaigos.
• Yra riba, po kurios nustojama kartoti, o pranešimas atidedamas žmogui – tyliai mesti negalima.

Kuri sistema yra tiesa

Šis susitarimas svarbesnis už bet kokią techninę detalę. Kol neaišku, kuri sistema yra tiesos šaltinis konkrečiam duomenų tipui, kiekvienas neatitikimas tampa diskusija. Naudinga susitarti ne apie sistemą apskritai, o apie kiekvieną duomenų rūšį atskirai: kliento kontaktai gali būti valdomi vienoje sistemoje, o užsakymo statusas – kitoje. Tada neatitikimas nustoja būti nuomonių klausimu ir tampa taisymo veiksmu.

• Kiekvienam duomenų tipui: kuri sistema jį valdo ir kuri tik atspindi.
• Kas nutinka, jei pakeista abiejose vietose – laimi tiesos šaltinis, ne vėlesnis išsaugojimas.
• Kurie laukai apskritai nesinchronizuojami, kad nekiltų iliuzijos, jog jie visada vienodi.
• Kaip atrodo įrašo tapatumas: pagal kurį lauką sprendžiama, kad tai tas pats klientas ar užsakymas.
• Kas vyksta, kai tiesos šaltinyje įrašas ištrinamas.

Suderinimas: kaip pastebėti neatitikimą pačiam

Net gerai suprojektuota integracija kada nors išsiskirs. Skirtumas tarp tvarkingos ir netvarkingos sistemos yra ne tas, ar tai nutinka, o ar tai pastebima be kliento skambučio. Minimalus suderinimas nėra didelis darbas: periodiškai palyginti įrašų kiekius ir kelis kritinius laukus tarp abiejų pusių, ir turėti vietą, kur neatitikimas užrašomas.

• Reguliarus kiekių palyginimas: kiek įrašų yra abiejose pusėse per tą patį laikotarpį.
• Kelių kritinių laukų palyginimas, ne visų – visų palyginimas dažniausiai niekada nepradedamas.
• Neapdorotų pranešimų eilė su matomu skaičiumi, kad būtų aišku, jei ji auga.
• Įrašai apie tai, kas ir kada buvo perduota – be jų incidento negalima ištirti.
• Aiškus pranešimas atsakingam žmogui, kai neatitikimas didesnis už sutartą ribą.

Iliustracinis pavyzdys

Iliustracinis scenarijus, ne kliento projekto aprašymas. Įsivaizduokime, kad užsakymai iš svetainės perduodami į apskaitos sistemą. Vieną naktį tinklas trumpai nutrūksta po to, kai apskaitos sistema jau įrašė užsakymą, bet prieš tai, kai svetainė gavo atsakymą. Svetainė mano, kad nepavyko, ir kartoja. Be atpažinimo ženklo apskaitoje atsiranda du vienodi užsakymai, o klientas gauna dvi sąskaitas. Su ženklu antras bandymas atpažįstamas ir grąžinamas pirmojo rezultatas. Svarbu, kad problema buvo ne ryšio nutrūkimas – jis normalus – o tai, kad kartojimas nebuvo saugus.

Atsakomybės ribos

Techninė riba tarp sistemų beveik visada yra ir organizacinė riba. Prieš paleidimą verta užrašyti kelis dalykus, kurie incidento metu tampa svarbiausi: kas stebi eilę, kas turi teisę pakartoti perdavimą, kas gali taisyti duomenis tiesiogiai ir kam skambinama, jei neatitikimas kilo išorinio tiekėjo pusėje. Šis sąrašas atrodo biurokratiškas – iki pirmo incidento.

Ko šis vadovas nepasako

Jame nėra sumų ir nėra konkrečios technologijos rekomendacijos: tie patys principai taikomi ir eilėms, ir tiesioginėms sąsajoms, ir failų perdavimui. Taip pat nepateikiama universali suderinimo riba – kiek neatitikimo yra „normalu“, priklauso nuo veiklos, ir bet kuris čia įrašytas skaičius būtų prielaida, ne norma. Vadovo tikslas kitas: kad kartojimas būtų saugus, tiesos šaltinis sutartas, o neatitikimas pastebimas be kliento skambučio.

Jei prieš integracijos darbus susitarsite tik dėl dviejų dalykų – kuri sistema yra tiesa kiekvienam duomenų tipui ir kaip atpažįstamas pakartotas pranešimas – didžioji dalis tylių klaidų nebeturės kur atsirasti.