Atšķirība galvenokārt slēpjas laika noteikšanā.
Redakcijas komanda publicē atjauninātu konsultāciju centra kontaktinformāciju plkst. 10:14. Tīmekļa vietnē nekavējoties jāparāda jaunais tālruņa numurs, portāla meklētājprogrammai ir jāatjaunina savs indekss, un skaidra un kodolīga versija vēlāk būs jāpārskata profesionālim. Šīs sekas izriet no vienām un tām pašām izmaiņām, taču tās visas nav jāapstrādā vienlaicīgi.
Webhook ir ziņojums, ko viena sistēma nosūta otrai tūlīt pēc notikuma. Piemēram, satura pārvaldības sistēma var ziņot: "Šī lapa ir publicēta." Saņēmēja sistēma pēc tam var izgūt un rediģēt tieši šo saturu. Tā negaida nākamo vispārīgo palaišanu un pastāvīgi nepārbauda jaunas izmaiņas.
Pakešu apstrāde ietver vairāku uzdevumu apkopošanu un izpildi kopā. Piemēram, katru vakaru var pārbaudīt visas tajā dienā modificētās lapas, lai izveidotu atskaiti. Šāda apstrāde nav tūlītēja, taču to ir viegli plānot. Tā var secīgi apstrādāt lielus daudzumus un sniegt rezultātu kā saskaņotu pārskatu. Apstrādei ir zināms sākums un noteikts beigas.
Webhooks saskaņo atsevišķus svarīgus notikumus
Tīmekļa āķi ir noderīgi, ja savlaicīga atbilde sniedz skaidru labumu. Pēc brīdinājuma ziņojuma publicēšanas lietotnei jāsaņem tāds pats atjauninātais saturs. Pēc lapas atsaukšanas tai jāpazūd no iekšējiem meklēšanas rezultātiem. Katru ziņojumu aktivizē konkrēta darbība, un tas attiecas uz skaidri definētu saturu.
Redakcijas komandai šis process šķiet tūlītējs. Viņi apstiprina ieguldījumu un neilgi pēc tam redz jauno versiju pievienotajā kanālā. Tomēr šo ātrumu nevajadzētu jaukt ar garantētu vienlaicīgumu. Tīkla kļūdas, apkope vai aizņemts attālais serveris var aizkavēt apstrādi. Sistēmai ir jāspēj izturēt šādus pārtraukumus.
Ne katrai saglabātajai izmaiņai vajadzētu aktivizēt tīmekļa āķi. Automātiski saglabāts melnraksts vēl nav atbilstošs publiskai meklēšanai. Nozīmīgi notikumi tiek noteikti, pamatojoties uz to redzamo nozīmīgumu: publicēts, būtiski atjaunināts, atsaukts vai dzēsts. Tas samazina ziņojumu skaitu, ko saņem pievienotās sistēmas, un ļauj tām skaidrāk apstrādāt svarīgas stāvokļa izmaiņas. Iekšējās drukas kļūdu labojumus var apstrādāt citādi nekā jaunu informāciju, ja nepieciešams.
Pakešu apstrāde ir piemērota lieliem daudzumiem un fiksētiem termiņiem.
Lielāks apjoms ir piemērots, ja liels satura apjoms tiek apstrādāts saskaņā ar vieniem un tiem pašiem noteikumiem. Organizācija varētu vēlēties katru vakaru pārbaudīt visas publicētās lapas, vai tajās nav trūkstošo pārskatīšanas datumu. Tas, vai rezultāts ir pieejams plkst. 2:00 vai 2:20, lasītājiem maz ko maina. Tūlītēja paziņojuma nosūtīšana pēc katras nelielas rediģēšanas būtu nevajadzīgi laikietilpīga.
Pilnīgu atjaunošanu var veikt arī pakešu veidā. Pēc meklēšanas sistēmas izmaiņām, iespējams, būs jāpārlasa 80 000 lappušu. Atsevišķas tīmekļa āķi nevarētu ticami aprakstīt inventāru, jo tiktu ietekmēts arī nemainīts saturs. Pakešu palaišana sākas ar zināmu lappušu un dokumentu skaitu, kuru lapas tika veiksmīgi apstrādātas.
Fiksēts laika intervāls atvieglo slodzes plānošanu. Attēlu aprakstiem, tulkojumu melnrakstiem vai plašām kvalitātes pārbaudēm ir nepieciešams skaitļošanas laiks un ārējie pakalpojumi. Katru nakti veikts darbs var ierobežot šo darba slodzi, nepalēninot publicēšanu redakcijas sistēmā. Tā ilgums kļūst paredzamāks gan uzņēmumam, gan pakalpojumu sniedzējiem. Tomēr steidzamam saturam joprojām ir nepieciešams ātrāks maršruts, ja ilga gaidīšana novestu pie neprecīzas informācijas.
Vispirms nosaka atļautā aizkave
Vissvarīgākais jautājums ir: Cik ilgi pievienotā sistēma var attēlot novecojušu versiju? Spēcīgu laikapstākļu brīdinājuma gadījumā minūtēm var būt izšķiroša nozīme. Mēneša teksta kvalitātes analīzei viena diena parasti nerada problēmas. Skaidra laika norāde ir noderīgāka nekā vispārējā prasība, ka visai apstrādei jābūt pēc iespējas ātrākai.
Nākamais faktors ir tipisku izmaiņu apjoms. Ja parasti tiek publicēta tikai viena lapa, tīmekļa āķis var norādīt tieši šo lapu. Ja regulāri mainās veselas datubāzes, plānota izpilde ir vieglāk pārvaldāma. Jaunu vietņu importēšanai ar 4000 ierakstiem nevajadzētu nekontrolējami izraisīt 4000 vienlaicīgus turpmākos uzdevumus.
Lēmuma pieņemšanā jāņem vērā arī elektroenerģijas padeves pārtraukuma sekas. Ja ziņojums tiek pazaudēts, lietotnē var palikt novecojis tālruņa numurs. Ja ikvakara ziņojums neizdodas, redakcijas komanda to var restartēt no rīta. Pieņemamā kavēšanās ir skaidri jāvienojas par katru pievienoto kanālu. Jo lielāks ir tūlītējais kaitējums, jo svarīgāka kļūst ātra atkārtošana, redzami brīdinājumi un visas datubāzes papildu saskaņošana.
Webhook ziņojums joprojām ir mazs un nepārprotams
Labā ziņa norāda notikušā notikumu, tā saturu un notikuma laiku. Tajā ir iekļauts arī unikāls notikuma numurs un ziņojuma formāta versija. Saņēmēja sistēma pēc tam var izgūt pilnīgus, aktuālus datus, izmantojot drošu saskarni. Tas nodrošina ziņojuma kodolīgumu un novērš nevajadzīgu visa raksta iekļaušanu.
Šī procedūra arī novērš novecojuša teksta izplatīšanu ar aizkavētu ziņojumu. Pieņemsim, ka redakcijas komanda divas reizes ātrā secībā labo vienu un to pašu tālruņa numuru. Pirmais ziņojums pienāk vēlāk nekā otrais tehniskas problēmas dēļ. Ja saņēmēja puse pārbauda jaunāko versiju, tā joprojām saņems jaunāko apstiprināto versiju, nevis aizkavētā ziņojuma saturu.
Ziņojumā nedrīkst iekļaut personisku vai konfidenciālu informāciju, ja vien tas nav absolūti nepieciešams. Žurnāli, kļūdu ziņojumi un administratīvās saskarnes bieži vien ilgstoši glabā tīmekļa āķu datus. Daudzos gadījumos pietiek ar satura identifikatoru un notikuma veidu. Pilnvarotā puse iegūst papildu informāciju tikai tad, kad tā faktiski ir jāapstrādā. Tas nodrošina, ka pat tehniskas kļūdas ziņojumā nav nevajadzīga tehniska satura.
Atkārtoti ziņojumi ir normāla parādība.
Ja saņēmēja sistēma neapstiprina ziņojuma saņemšanu, nosūtītāja sistēma to nosūta atkārtoti. Pirmais ziņojums, iespējams, jau ir apstrādāts, bet tā apstiprinājums ir zudis. Tāpēc saņēmēja sistēmai ir jāspēj pieņemt vienu un to pašu notikumu vairākas reizes, nepublicējot ziņojumu divreiz vai nepasūtot vienu un to pašu tulkojumu divreiz.
Unikālais notikuma numurs palīdz šajā jautājumā. Ja šis numurs jau ir veiksmīgi apstrādāts, sistēma var apstiprināt un izlaist atkārtošanos. Tas ir uzticamāk nekā laiku vai nosaukumu salīdzināšana. Divas dažādas izmaiņas var notikt gandrīz vienlaikus, un nosaukums var mainīties, pat ja saturs paliek nemainīgs.
Pat secība ne vienmēr ir uzticama. Paziņojums par publicēšanu var pienākt pēc paziņojuma par vēlāku labojumu. Versiju numuri vai pašreizējais satura piekļuves datums neļauj vecākajai versijai būt prioritāram. Redakcijas komandām tas nozīmē: redzamajai versijai ir jābūt pareizai, pat ja tehnisko ziņojumu ceļš ir neparedzams. Tāpēc saņemšanas datumam vien nevajadzētu noteikt derīgo versiju.
Saņēmējam ir jāpārbauda izcelsme
Publiski pieejamai tīmekļa āķa adresei principā var piekļūt arī neatļautas personas. Tāpēc saņēmējam nevajadzētu uzticēties ziņojumam tikai tāpēc, ka tas nonāk paredzētajā ceļā. Standarta prakse ir digitālais paraksts, kas tiek aprēķināts no satura un koplietotas slepenās atslēgas. Saņēmējs to pārrēķina un salīdzina abas vērtības.
Pārraide notiek, izmantojot HTTPS, lai aizsargātu saturu un piekļūtu datiem pārsūtīšanas laikā. Slepenā atslēga nav iekļauta pirmkodā, publiskajā dokumentācijā vai ziņojuma pamattekstā. Tā tiek droši glabāta, pieejama tikai nepieciešamajiem pakalpojumiem un regulāri atjaunota. Vecās atslēgas pēc kontrolētas pārejas ir jāanulē.
Laika zīmogs vēl vairāk ierobežo to, cik ilgi tiek pieņemts pareizi parakstīts ziņojums. Tas novērš ierakstīta pieprasījuma patvaļīgu atkārtošanu vēlāk. Kļūdu atbildēm nevajadzētu atklāt uzbrucējiem iekšēju informāciju. Tomēr tiek saglabāts pietiekami daudz informācijas, lai komanda varētu īpaši izmeklēt noraidītu parakstu vai novecojušu ziņojuma formātu. Aizdomīgi piekļuves mēģinājumi tiek ierobežoti un reģistrēti izsekojamā veidā drošības auditu veikšanai. Tiek piemēroti atbilstoši un skaidri dokumentēti saglabāšanas periodi.
Lieliskam skrējienam nepieciešams izsekojams audzes stāvoklis
Ar 20 000 lappusēm partijas apstrāde reti ir pilnībā veiksmīga vai pilnīgi neveiksmīga. Daļa satura var saturēt nederīgu informāciju, bet pārējā daļa tiek apstrādāta pareizi. Tāpēc katrai ievadnei ir jāreģistrē, kas bija veiksmīgi un kas ir jāmēģina atkārtoti. Vienai bojātai lapai nevajadzētu bloķēt visas nākamās lapas.
Jāņem vērā ārējo pakalpojumu ierobežojumi. Saskarne var atļaut tikai noteiktu pieprasījumu skaitu minūtē. Pēc tam process sadala apjomu pārvaldāmos fragmentos un turpina darbu pēc pauzes. Tas saglabā savu progresu, lai restartēšana nesāktos no pirmās lapas un nevajadzīgi neatkārtotu jau apmaksātu darbu.
Redakcijas komandai skaidrs un saprotams rezultāts ir svarīgāks par garu tehnisko žurnālfailu. Viņiem ir jāspēj redzēt, kurš drukas darbs ir ietekmēts, cik daudz satura ir pabeigts un kurām lapām nepieciešama tehniskā palīdzība. Ziņojums, piemēram, "37 kļūdas", nav pietiekams. Kļūdas piešķiršana lapas nosaukumam, adresei un konkrētam iemeslam pārveido to par pārvaldāmu uzdevumu. Pēc tam veiksmīgi atkārtoti kļūdu gadījumi pazūd no atvērtā redakcijas skata.
Bieži vien plānota palaišana papildina tīmekļa āķus.
Tīmekļa āķi un partiju apstrāde nav savstarpēji izslēdzoši. Ziņu portāls var nekavējoties ziņot par jauniem rakstiem savā meklēšanas funkcijā un sinhronizēt visu savu arhīvu nakts laikā. Šī ātrā pieeja uztur svarīgas izmaiņas atjauninātas. Plānotā apstrāde atrod notikumus, kas trūkst darbības traucējumu, nepareiza iestatījuma vai īslaicīgi bezsaistē esoša līdzinieka dēļ.
Saprotamas valodas versijai var būt nepieciešami abi laiki. Ja tiek mainīta speciālista lapa, tīmekļa āķis nekavējoties ģenerē uzdevumu atbildīgajai redakcijas komandai. Pārskatītā versija netiek automātiski aizstāta. Dienas pārskatā papildus tiek parādīti visi atvērtie uzdevumi, to termiņi un saturs, kuram trūkst saites uz sākotnējo lapu.
Skaidrs derīgā stāvokļa avots ir ļoti svarīgs. Tīmekļa piesaiste ziņo par izmaiņām, un regulāra sinhronizācija apstiprina pašreizējo stāvokli. Ja abi sniedz atšķirīgu informāciju, nedrīkst ļaut pēdējam izpildītajam procesam piešķirt prioritāti. Publicēšanas sistēma saglabā autoritatīvu stāvokli, un savienotās sistēmas sinhronizē savu stāvokli ar to. Šim noteikumam ir jāpaliek skaidri dokumentētam pat pēc sistēmas izmaiņām.
Darbībai ir jāpaliek cilvēkiem saprotamai.
Tehnisko uzticamību apliecina redzamā informācija. Komandām jāzina, cik ilgs laiks parasti nepieciešams pārraidei un kad tiek ziņots par kavēšanos. Brīdinājumā ir norādīts skartais kanāls un saturs, nevis tikai iekšējais procesa nosaukums. Tas ļauj redakcijas komandai novērtēt, vai apmeklētāji pašlaik skata novecojušu versiju.
Katram procesam ir nepieciešama atbildīgā persona. Tā var atkārtoti nosūtīt iestrēgušu ziņojumu, atsākt partijas izpildi vai apturēt nepareizu publikāciju. Tajā pašā laikā ir jābūt skaidram, kad nepieciešama tehniskā atbildība. Tehniskā komanda var pārsūtīt failu, bet nevar izlemt, vai mainītais prasības nosacījums ir pareizi izskaidrots.
Tādējādi atbilstošais risinājums izriet no satura, laika un iespējamā kaitējuma. Webhooks ātri reaģē uz atsevišķiem notikumiem. Partiju izpildes apstrādā paredzamus apjomus un saskaņo krājumus. Kopā tie aptver pašreizējās izmaiņas un krājumu pilnīgumu. Ja jau no paša sākuma tiek ņemti vērā atkārtojumi, drošība un saprotami ziņojumi, savienotās tīmekļa vietnes un pakalpojumi paliek atjaunināti, neapgrūtinot redakcijas komandas ikdienas darbu ar nevajadzīgām tehnoloģijām.