Spletni kavlji ali paketna obdelava: kdaj vsebine prenašati takoj in kdaj zbrane

Naučite se, kdaj spremembe prek spletnega kavlja potekajo takoj in kdaj so načrtovane uvedbe zanesljivejše pri vsakodnevnem uredniškem delu.

Razlika je predvsem v času

Uredništvo ob 10.14 objavi spremembo svetovalne službe. Spletno mesto mora takoj prikazati novo telefonsko številko, iskalnik v lastnem portalu mora obnoviti indeks, razumljiva jezikovna različica pa pozneje potrebuje strokovno preverjanje. Te posledice pripadajo isti spremembi, vendar jih ni treba vseh obdelati v istem trenutku.

Spletni kavelj je sporočilo, ki ga en sistem takoj po dogodku pošlje drugemu. Uredniški sistem na primer sporoči: »Ta stran je bila objavljena.« Prejemni sistem lahko nato pridobi in obdela prav to vsebino. Ne čaka na naslednji splošni zagon in tudi ne poizveduje nenehno po novih spremembah.

Pri paketni obdelavi se več nalog zbere in izvede skupaj. Vsak večer je na primer mogoče za poročilo preveriti vse strani, ki so bile tisti dan spremenjene. Takšen zagon ni takojšen, je pa dobro načrtljiv. Velike količine lahko obdeluje zaporedoma in rezultat zagotovi kot povezani pregled. Obdelava ima znan začetek in prepoznaven konec.

Spletni kavlji ustrezajo posameznim pomembnim dogodkom

Spletni kavlji so smiselni, kadar hiter odziv prinaša prepoznavno korist. Po objavi opozorila mora aplikacija prejeti isto trenutno vsebino. Po umiku strani mora ta izginiti iz notranjega iskanja. Sporočilo vsakokrat sproži konkretno dejanje in se nanaša na jasno določljivo vsebino.

Za uredništvo je ta postopek neposreden. Prispevek odobri in kmalu zatem vidi novo različico v povezanem kanalu. Te hitrosti pa ne smemo zamenjati z zagotovljeno sočasnostjo. Omrežne napake, vzdrževanje ali preobremenjen prejemni sistem lahko obdelavo zadržijo. Sistem mora prenesti takšne prekinitve.

Vsaka shranjena sprememba ne sme sprožiti spletnega kavlja. Samodejno shranjeni osnutek še ni pomemben za javno iskanje. Smiselni dogodki sledijo vidnemu pomenu: objavljeno, bistveno posodobljeno, umaknjeno ali izbrisano. Tako povezani sistemi prejmejo manj sporočil in lahko jasneje obravnavajo pomembne spremembe stanja. Notranje popravke tipkarskih napak je po potrebi mogoče obravnavati drugače kot nova dejstva.

Paketna obdelava je primerna za količine in določene termine

Večji zagon je primeren, kadar se veliko vsebin obdeluje po istih pravilih. Organizacija želi morda vsako noč preveriti vse objavljene strani glede manjkajočega datuma pregleda. Ali je rezultat na voljo ob 2.00 ali 2.20, za bralce pomeni malo razlike. Takojšnje sporočilo po vsaki manjši obdelavi bi bilo za to po nepotrebnem zahtevno.

Tudi popolna ponovna izgradnja se lahko zavestno izvede zbrano. Po spremembi iskalnega sistema je morda treba znova prebrati 80.000 strani. Posamezni spletni kavlji zaloge ne bi zanesljivo opisali, ker so prizadete tudi nespremenjene vsebine. Paketni zagon se začne z znano količino in dokumentira, katere strani so bile uspešno obdelane.

Določeni čas olajša načrtovanje obremenitve. Opisi slik, osnutki prevodov ali obsežna preverjanja kakovosti zahtevajo računski čas in zunanje storitve. Nočni zagon lahko to delo omeji, ne da bi upočasnil objavo v uredniškem sistemu. Njegovo trajanje tako postane bolj predvidljivo za obratovanje in izvajalce. Nujne vsebine vseeno potrebujejo hitrejšo pot, kadar bi dolgo čakanje povzročilo napačne informacije.

Najprej odloča dovoljena zamuda

Najpomembnejše vprašanje je: kako dolgo sme povezani sistem prikazovati staro stanje? Pri opozorilu pred neurjem so lahko minute odločilne. Pri mesečni analizi kakovosti besedila en dan navadno ni težava. Jasna časovna navedba pomaga bolj kot splošna zahteva, da mora biti vsaka obdelava čim hitrejša.

Nato šteje obseg značilne spremembe. Če se večinoma objavi ena stran, lahko spletni kavelj navede prav to stran. Če se redno spreminjajo celotne zbirke, je načrtovani zagon preglednejši. Uvoz novih lokacij s 4.000 vnosi ne sme nenadzorovano sprožiti 4.000 sočasnih nadaljnjih opravil.

V odločitev sodijo tudi posledice izpada. Če se sporočilo izgubi, morda v aplikaciji ostane zastarela telefonska številka. Če nočno poročilo ne uspe, ga lahko uredništvo zjutraj znova zažene. Sprejemljiva zamuda mora biti izrecno dogovorjena za vsak povezani kanal. Večja ko je neposredna škoda, pomembnejši so hitre ponovitve, vidna opozorila in dodatna primerjava celotne zbirke.

Sporočilo spletnega kavlja ostane majhno in nedvoumno

Dobro sporočilo pove, kaj se je zgodilo, na katero vsebino se nanaša in kdaj je dogodek nastal. Dodata se enolična številka dogodka in različica oblike sporočila. Prejemni sistem lahko nato prek zaščitenega vmesnika pridobi celotne trenutne podatke. Tako sporočilo ostane pregledno in po nepotrebnem ne vsebuje celotnega članka.

Ta pristop tudi prepreči, da bi zapoznelo sporočilo razširjalo staro besedilo. Denimo, da uredništvo isto telefonsko številko dvakrat hitro popravi. Prvo sporočilo zaradi motnje prispe pozneje kot drugo. Če prejemni sistem pridobi trenutno stanje, vseeno dobi nazadnje odobreno različico in ne vsebine zapoznelega sporočila.

Osebni ali zaupni podatki brez potrebe ne sodijo v sporočilo. Dnevniki, poročila o napakah in skrbniški vmesniki pogosto dlje časa hranijo podatke spletnih kavljev. V mnogih primerih zadostujeta identifikator vsebine in vrsta dogodka. Pooblaščeni prejemni sistem pridobi dodatne podatke šele, ko jih mora resnično obdelati. Tako tudi tehnično poročilo o napaki ostane brez nepotrebnih strokovnih vsebin.

Ponovljena sporočila so običajen primer

Če prejemna stran ne potrdi prejema sporočila, ga izvorni sistem pošlje znova. Prvo sporočilo je bilo morda že obdelano, vendar se je njegova potrditev izgubila. Zato mora prejemni sistem isti dogodek sprejeti večkrat, ne da bi prispevek objavil dvakrat ali isti prevod naročil dvakrat.

Pri tem pomaga enolična številka dogodka. Če je bila ta številka že uspešno obravnavana, lahko sistem ponovitev potrdi in preskoči. To je zanesljivejše od primerjave časov ali naslovov. Dve različni spremembi se lahko zgodita skoraj sočasno, naslov pa se lahko spremeni, čeprav gre še vedno za isto vsebino.

Tudi vrstni red ni vedno zagotovljen. Sporočilo o objavi lahko prispe po sporočilu o poznejšem popravku. Številke različic ali pridobitev trenutne vsebine preprečijo, da bi prevladalo starejše stanje. Za uredniške ekipe to pomeni, da mora vidno stanje ostati pravilno, tudi če tehnična sporočila potujejo po nemirni poti. Datum prejema zato ne sme sam odločati o veljavni različici.

Prejemnik mora preveriti izvor

Javno dosegljiv naslov spletnega kavlja lahko načeloma pokličejo tudi nepooblaščene osebe. Prejemni sistem sporočilu zato ne sme zaupati le zato, ker prispe na pričakovano pot. Običajna je digitalna podpisna vrednost, izračunana iz vsebine in skupnega skrivnega ključa. Prejemnik jo znova izračuna in obe vrednosti primerja.

Prenos poteka prek HTTPS, da so vsebina in podatki za dostop zaščiteni na poti. Skrivni ključ ne sodi v izvorno kodo, javno dokumentacijo ali besedilo sporočila. Hrani se zaščiteno, dostop do njega imajo le potrebne storitve, redno pa se obnovi. Stari ključi morajo po nadzorovanem prehodu prenehati veljati.

Časovni žig dodatno omeji, kako dolgo je pravilno podpisano sporočilo sprejeto. Tako posnetega klica ni mogoče poljubno ponoviti pozneje. Odgovori ob napakah napadalcem ne smejo razkriti notranjih podrobnosti. Lastna ekipa vseeno ohrani dovolj podatkov za ciljno raziskavo zavrnjenega podpisa ali zastarele oblike sporočila. Sumljivi dostopi se omejijo in sledljivo beležijo za varnostno preverjanje. Za to veljajo primerni in jasno dokumentirani roki hrambe.

Velik zagon potrebuje sledljivo stanje

Pri 20.000 straneh paketni zagon le redko v celoti uspe ali v celoti ne uspe. Nekatere vsebine lahko vsebujejo neveljavne podatke, preostanek pa se pravilno obdela. Zagon mora zato za vsak vnos zabeležiti, kaj je uspelo in kaj je treba poskusiti znova. Ena napačna stran ne sme blokirati vseh naslednjih.

Upoštevati je treba omejitve zunanjih storitev. Vmesnik morda dovoljuje le določeno število zahtev na minuto. Zagon takrat količino razdeli na sprejemljive dele in po premoru nadaljuje. Napredek shrani, da se ob ponovnem zagonu ne začne znova pri prvi strani in po nepotrebnem ponovi že plačano delo.

Za uredništvo je razumljiv rezultat pomembnejši od dolge tehnične dnevniške datoteke. Prepoznati mora, kateri zagon je prizadet, koliko vsebin je dokončanih in katere strani potrebujejo strokovno pomoč. Sporočilo, kot je »37 napak«, ne zadošča. Povezava z naslovom strani, naslovom URL in konkretnim razlogom spremeni napako v obvladljivo nalogo. Uspešne ponovitve nato izginejo iz odprtega uredniškega pogleda.

Načrtovani zagon pogosto dopolnjuje spletne kavlje

Spletni kavlji in paketna obdelava se ne izključujejo. Novičarski portal lahko nove prispevke takoj sporoči svojemu iskalniku in ponoči primerja celotno zbirko. Hitra pot ohranja pomembne spremembe aktualne. Načrtovani zagon najde dogodke, ki manjkajo zaradi motnje, napačne nastavitve ali začasno izključenega prejemnega sistema.

Tudi razumljiva jezikovna različica lahko potrebuje oba časa. Ko se strokovna stran spremeni, spletni kavelj takoj ustvari nalogo za pristojno uredništvo. Preverjena različica se ne zamenja samodejno. Dnevno poročilo dodatno pokaže vse odprte naloge, njihove roke in vsebine, pri katerih manjka povezava z izvorno stranjo.

Odločilen je jasen vir veljavnega stanja. Spletni kavelj sporoči spremembo, redna primerjava pa potrdi trenutno zbirko. Če dajeta različne podatke, ne sme naključno prevladati zadnji izvedeni postopek. Sistem za objavljanje ostane merodajen, povezani sistemi pa z njim uskladijo svoje stanje. To pravilo mora ostati nedvoumno dokumentirano tudi po zamenjavi sistema.

Obratovanje mora ostati razumljivo ljudem

Tehnična zanesljivost se pokaže v vidni informaciji. Ekipe morajo vedeti, koliko časa prenos običajno traja in kdaj se začne zamuda prijavljati. Opozorilo navede prizadeti kanal in vsebino, ne le notranjega imena postopka. Uredništvo lahko tako presodi, ali obiskovalci trenutno vidijo zastarelo stanje.

Vsak postopek potrebuje pristojno osebo ali službo. Ta lahko znova pošlje obtičalo sporočilo, nadaljuje paketni zagon ali ustavi napačno objavo. Hkrati mora biti jasno, kdaj je potrebna strokovna odgovornost. Tehnična ekipa lahko prenese datoteko, ne more pa odločiti, ali je spremenjeni pogoj za upravičenost vsebinsko pravilno pojasnjen.

Ustrezna rešitev tako izhaja iz vsebine, časa in možne škode. Spletni kavlji se hitro odzivajo na posamezne dogodke. Paketni zagoni obdelujejo načrtljive količine in primerjajo zbirke. Skupaj pokrivajo trenutne spremembe in popolnost zbirke. Če se ponovitve, varnost in razumljiva sporočila upoštevajo od začetka, povezane spletne strani in storitve ostanejo aktualne, ne da bi uredniško vsakdanjost obremenjevale z nepotrebno tehniko.

Verodostojni viri

  1. RFC 9110 - Semantika HTTP
  2. RFC 2104 - HMAC: zgoščevanje s ključem za preverjanje pristnosti sporočil
  3. Cloud Native Computing Foundation - CloudEvents
  4. Zbirka preglednic OWASP - Upravljanje skrivnosti

Začnite uporabljati Simple8 brezplačno.

Ustvarite svoj brezplačen račun in vsak mesec brezplačno uporabite do 15.000 znakov.