Skirtumas pirmiausia slypi laiko nustatyme.
Redakcijos komanda 10:14 val. paskelbia atnaujintą konsultavimo centro kontaktinę informaciją. Svetainėje turi būti nedelsiant rodomas naujas telefono numeris, portalo paieškos sistema turi atnaujinti savo indeksą, o aiškią ir glaustą versiją vėliau reikės peržiūrėti specialistui. Šios pasekmės susijusios su tuo pačiu pakeitimu, tačiau nebūtina jų visų apdoroti vienu metu.
„Webhook“ – tai pranešimas, kurį viena sistema siunčia kitai iškart po įvykio. Pavyzdžiui, turinio valdymo sistema gali pranešti: „Šis puslapis buvo paskelbtas.“ Gaunanti sistema gali gauti ir redaguoti būtent šį turinį. Ji nelaukia kito bendro paleidimo ir nuolat netikrina, ar nėra naujų pakeitimų.
Paketinis apdorojimas apima kelių užduočių rinkimą ir vykdymą kartu. Pavyzdžiui, kiekvieną vakarą galima patikrinti, ar visi tą dieną modifikuoti puslapiai yra ataskaitoje. Toks vykdymas nėra momentinis, bet jį lengva suplanuoti. Jis gali apdoroti didelius kiekius nuosekliai ir pateikti rezultatą kaip nuoseklią apžvalgą. Apdorojimas prasideda žinomai ir baigiasi apibrėžtai pabaigai.
„Webhooks“ atitinka atskirus svarbius įvykius
Žiniatinklio kabliai yra naudingi, kai laiku pateiktas atsakas suteikia aiškią naudą. Paskelbus įspėjamąjį pranešimą, programa turėtų gauti tą patį atnaujintą turinį. Pašalinus puslapį, jis turėtų dingti iš vidinių paieškos rezultatų. Kiekvieną pranešimą suaktyvina konkretus veiksmas ir jis yra susijęs su aiškiai apibrėžtu turiniu.
Redakcijos komandai šis procesas atrodo akimirksniu. Jie patvirtina įnašą ir netrukus pamato naują versiją prijungtame kanale. Tačiau šio greičio nereikėtų painioti su garantuotu vienalaikiškumu. Tinklo klaidos, techninė priežiūra ar užimtas nuotolinis serveris gali sulėtinti apdorojimą. Sistema turi atlaikyti tokius trikdžius.
Ne kiekvienas išsaugotas pakeitimas turėtų suaktyvinti žiniatinklio kablį. Automatiškai išsaugotas juodraštis dar nėra aktualus viešajai paieškai. Reikšmingi įvykiai priskiriami pagal jų matomą reikšmę: paskelbta, iš esmės atnaujinta, atšaukta arba ištrinta. Tai sumažina prijungtų sistemų gaunamų pranešimų skaičių ir leidžia joms aiškiau tvarkyti svarbius būsenos pakeitimus. Vidinių rašybos klaidų taisymai, jei reikia, gali būti tvarkomi kitaip nei nauja informacija.
Paketinis apdorojimas tinka dideliems kiekiams ir fiksuotiems terminams
Didesnis tiražas tinka, kai pagal tas pačias taisykles apdorojama daug turinio. Organizacija gali norėti kiekvieną vakarą patikrinti visus paskelbtus puslapius, ar nėra praleistų peržiūros datų. Ar rezultatas pasiekiamas 2:00 val., ar 2:20 val., skaitytojams neturi didelės reikšmės. Siųsti pranešimą iš karto po kiekvieno nedidelio pakeitimo būtų be reikalo daug laiko reikalaujantis procesas.
Visišką atkūrimą taip pat galima sąmoningai atlikti partijomis. Pakeitus paieškos sistemą, gali tekti iš naujo perskaityti 80 000 puslapių. Atskiri žiniatinklio kabliai patikimai neaprašytų inventoriaus, nes būtų paveiktas ir nepakeistas turinys. Paketinis vykdymas pradedamas nuo žinomo puslapių ir dokumentų skaičiaus, kurių puslapiai buvo sėkmingai apdoroti.
Fiksuotas laiko intervalas palengvina apkrovos planavimą. Vaizdų aprašymams, vertimo juodraščiams ar išsamiems kokybės patikrinimams reikia skaičiavimo laiko ir išorinių paslaugų. Naktinis paleidimas gali apriboti šį darbo krūvį nesulėtinant publikavimo redakcijos sistemoje. Jo trukmė tampa labiau nuspėjama tiek įmonei, tiek paslaugų teikėjams. Skubus turinys vis tiek reikalauja greitesnio maršruto, jei ilgas laukimas lemtų netikslią informaciją.
Leistinas vėlavimas lemia pirmiausia
Svarbiausias klausimas: kiek laiko prijungta sistema gali rodyti pasenusią versiją? Įspėjimo apie nepalankias oro sąlygas atveju minutės gali būti labai svarbios. Mėnesinei teksto kokybės analizei viena diena paprastai nekelia problemų. Aiškus laiko nurodymas yra naudingesnis nei bendras reikalavimas, kad visas apdorojimas turi būti kuo greitesnis.
Kitas veiksnys yra tipiško pakeitimo apimtis. Jei paprastai publikuojamas tik vienas puslapis, žiniatinklio kabliukas gali nurodyti tikslų tą puslapį. Jei ištisos duomenų bazės reguliariai keičiasi, suplanuotas vykdymas yra lengviau valdomas. Naujų svetainių su 4000 įrašų importavimas neturėtų nevaldomai sukelti 4000 vienu metu atliekamų tolesnių užduočių.
Taip pat reikia atsižvelgti į sutrikimo pasekmes. Jei pranešimas prarandamas, programėlėje gali likti pasenęs telefono numeris. Jei kasnaktinė ataskaita nepavyksta, redakcijos komanda gali ją paleisti iš naujo ryte. Kiekvienam prijungtam kanalui turėtų būti aiškiai susitarta dėl priimtino vėlavimo. Kuo didesnė tiesioginė žala, tuo svarbesni greiti pakartojimai, matomi įspėjimai ir papildomas visos duomenų bazės suderinimas.
„Webhook“ pranešimas išlieka mažas ir nedviprasmiškas
Geros naujienos pranešime nurodoma, kas įvyko, koks jos turinys ir kada įvyko įvykis. Jame taip pat nurodomas unikalus įvykio numeris ir pranešimo formato versija. Gaunanti sistema gali gauti visus naujausius duomenis per saugią sąsają. Taip pranešimas išlieka glaustas ir išvengiama nereikalingo viso straipsnio įtraukimo.
Ši procedūra taip pat neleidžia uždelsto pranešimo platinti pasenusio teksto. Tarkime, redakcijos komanda du kartus iš eilės greitai pataiso tą patį telefono numerį. Pirmasis pranešimas atkeliauja vėliau nei antrasis dėl gedimo. Jei gavėjas tikrina naujausią versiją, jis vis tiek gaus naujausią patvirtintą versiją, o ne uždelsto pranešimo turinį.
Asmeninė ar konfidenciali informacija neturėtų būti įtraukta į pranešimą, nebent tai būtų absoliučiai būtina. Žurnalai, klaidų ataskaitos ir administravimo sąsajos dažnai saugo žiniatinklio kabliuko duomenis ilgą laiką. Daugeliu atvejų pakanka turinio identifikatoriaus ir įvykio tipo. Įgaliotasis partneris gauna papildomos informacijos tik tada, kai jam ją iš tikrųjų reikia apdoroti. Tai užtikrina, kad net techninės klaidos ataskaitoje nebūtų nereikalingo techninio turinio.
Pasikartojantys pranešimai yra įprastas reiškinys
Jei priimančioji sistema nepatvirtina pranešimo gavimo, siunčiančioji sistema jį išsiunčia iš naujo. Pirmasis pranešimas galėjo būti jau apdorotas, bet jo patvirtinimas buvo prarastas. Todėl priimančioji sistema turi turėti galimybę priimti tą patį įvykį kelis kartus, nepublikuodama pranešimo du kartus ir neužsisakydama to paties vertimo du kartus.
Unikalus įvykio numeris tam padeda. Jei šis numeris jau buvo sėkmingai apdorotas, sistema gali patvirtinti ir praleisti pasikartojimą. Tai patikimiau nei lyginti laiką ar pavadinimus. Du skirtingi pakeitimai gali įvykti beveik vienu metu, o pavadinimas gali pasikeisti, net jei turinys išlieka tas pats.
Netgi eiliškumas ne visada patikimas. Pranešimas apie publikavimą gali būti gautas po pranešimo apie vėlesnį pataisymą. Versijų numeriai arba dabartinė turinio prieigos data neleidžia senesnei versijai turėti pirmenybės. Redakcijos komandoms tai reiškia: matoma versija turi būti teisinga, net jei techniniai pranešimai keliauja nenuspėjamu keliu. Todėl vien gavimo data neturėtų lemti galiojančios versijos.
Gavėjas privalo patvirtinti kilmę
Viešai prieinamą žiniatinklio kabliuko adresą iš principo gali pasiekti ir neįgaliotos šalys. Todėl gavėjas neturėtų pasitikėti pranešimu vien dėl to, kad jis atkeliauja numatytu keliu. Standartinė praktika yra skaitmeninis parašas, apskaičiuojamas pagal turinį ir bendrą slaptą raktą. Gavėjas jį perskaičiuoja ir palygina dvi reikšmes.
Perdavimas vyksta per HTTPS, siekiant apsaugoti turinį ir pasiekti perduodamus duomenis. Slaptasis raktas neįtrauktas į šaltinio kodą, viešąją dokumentaciją ar pranešimo tekstą. Jis saugomas saugiai, prieinamas tik būtinoms paslaugoms ir reguliariai atnaujinamas. Seni raktai turi būti anuliuoti po kontroliuojamo perėjimo.
Laiko žyma dar labiau apriboja, kiek laiko priimamas teisingai pasirašytas pranešimas. Tai neleidžia vėliau savavališkai kartoti įrašyto prašymo. Klaidų atsakymai neturėtų atskleisti jokių vidinių detalių užpuolikams. Tačiau išsaugoma pakankamai informacijos, kad komanda galėtų konkrečiai ištirti atmestą parašą arba pasenusį pranešimo formatą. Įtartini prieigos bandymai yra ribojami ir registruojami atsekamu būdu, kad būtų galima atlikti saugumo auditus. Taikomi atitinkami ir aiškiai dokumentuoti saugojimo laikotarpiai.
Puikiam bėgimui reikia atsekamo stovo
Su 20 000 puslapių paketinis vykdymas retai būna visiškai sėkmingas arba visiškai nesėkmingas. Dalis turinio gali būti neteisinga informacija, o likusi dalis apdorojama teisingai. Todėl kiekvienam įrašui vykdymas turėtų užregistruoti, kas buvo sėkminga ir ką reikia bandyti dar kartą. Vienas klaidingas puslapis neturėtų blokuoti visų tolesnių puslapių.
Reikia atsižvelgti į išorinių paslaugų apribojimus. Sąsaja gali leisti tik tam tikrą užklausų skaičių per minutę. Tada procesas padalija apimtį į valdomus fragmentus ir tęsia po pauzės. Jis išsaugo savo eigą, kad iš naujo paleistumėte nuo pirmojo puslapio ir be reikalo nekartotumėte jau apmokėto darbo.
Redakcijos komandai aiškus ir suprantamas rezultatas yra svarbesnis nei ilgas techninis žurnalo failas. Jie turi matyti, kuris spausdinimo darbas paveiktas, kiek turinio yra baigta ir kuriems puslapiams reikalinga techninė pagalba. Tokio pranešimo kaip „37 klaidos“ nepakanka. Klaidos priskyrimas puslapio pavadinimui, adresui ir konkrečiai priežasčiai paverčia ją valdoma užduotimi. Sėkmingi pakartojimai tada dingsta iš atidaryto redakcinio rodinio.
Dažnai suplanuotas paleidimas papildo žiniatinklio kabliukus.
Žiniatinklio kabliai ir paketinis apdorojimas nėra vienas kito nesuderinami. Naujienų portalas gali nedelsdamas pranešti apie naujus straipsnius savo paieškos funkcijai ir sinchronizuoti visą savo archyvą per naktį. Šis greitas metodas užtikrina svarbių pakeitimų atnaujinimą. Suplanuotas apdorojimas randa įvykius, kurie trūksta dėl gedimo, neteisingo nustatymo arba laikinai neprisijungusio mazgo.
Suprantamai kalbos versijai taip pat gali reikėti abiejų kartų. Jei pakeičiamas specializuotas puslapis, žiniatinklio kabliukas nedelsdamas sugeneruoja užduotį atsakingai redakcijos komandai. Peržiūrėta versija automatiškai nepakeičiama. Kasdienė ataskaita papildomai rodo visas atviras užduotis, jų terminus ir turinį, kuriam trūksta nuorodos į šaltinio puslapį.
Labai svarbu aiškiai nurodyti galiojančią būseną. Žiniatinklio kabliukas praneša apie pakeitimą, o įprasta sinchronizacija patvirtina dabartinę būseną. Jei abu procesai pateikia skirtingą informaciją, negalima leisti, kad vėliausiai įvykdytas procesas turėtų pirmenybę. Publikavimo sistema išlieka autoritetinga, o prijungtos sistemos sinchronizuoja savo būseną su ja. Ši taisyklė turi būti aiškiai dokumentuota net ir po sistemos pakeitimo.
Operacija turi likti suprantama žmonėms.
Techninį patikimumą parodo matoma informacija. Komandos turėtų žinoti, kiek laiko paprastai trunka perdavimas ir kada pranešama apie vėlavimą. Įspėjime nurodomas paveiktas kanalas ir turinys, o ne tik vidinio proceso pavadinimas. Tai leidžia redakcijos komandai įvertinti, ar lankytojai šiuo metu peržiūri pasenusią versiją.
Kiekvienam procesui reikalinga atsakinga šalis. Ji gali iš naujo išsiųsti užstrigusį pranešimą, atnaujinti paketinį vykdymą arba sustabdyti neteisingą publikavimą. Tuo pačiu metu turi būti aišku, kada reikalinga dalyko ekspertizė. Techninė komanda gali perduoti failą, bet negali nuspręsti, ar pakeista pretenzijos sąlyga buvo paaiškinta teisingai.
Taigi tinkamas sprendimas priklauso nuo turinio, laiko ir galimos žalos. „Webhooks“ greitai reaguoja į atskirus įvykius. Paketiniai procesai apdoroja nuspėjamus kiekius ir suderina atsargas. Kartu jie apima dabartinius pakeitimus ir atsargų išsamumą. Jei nuo pat pradžių atsižvelgiama į pasikartojimus, saugumą ir suprantamus pranešimus, prijungtos svetainės ir paslaugos išlieka atnaujintos neapkraunant redakcijos komandos kasdienio darbo nereikalingomis technologijomis.