Kontrolni popis održavanja nakon lansiranja: web, mobilni i automatizacijski sustavi koji ne propadaju

# Uvod#

Lansiranje nije ciljna crta. To je trenutak kada vaše web aplikacije, mobilne aplikacije i automatizacije počinju skupljati entropiju: ovisnosti stare, certifikati istječu, API-ji se mijenjaju, a “privremena” rješenja postaju trajna.

Cijena ignoriranja održavanja je mjerljiva. IBM-ovo izvješće Cost of a Data Breach navodi da je globalni prosječni trošak povrede podataka 4,88 milijuna USD. Odvojeno, Googleovo SRE istraživanje populariziralo je operativnu istinu: pouzdanost je funkcionalnost, a pouzdanost zahtijeva kontinuirani rad.

Ovaj vodič je praktičan, ponavljajući kontrolni popis održavanja web aplikacije za timove koji vode React i Next.js frontend, mobilne aplikacije u Flutteru te automatizacijske sustave poput n8n. Fokusira se na to što raditi tjedno, mjesečno i tromjesečno, što automatizirati naspram onoga što treba ljudsku provjeru, te kako dodijeliti odgovornosti i SLA-ove da ništa ne “propada” nakon lansiranja.

Za dublji okvir operativne primopredaje, uparite ovaj popis s našim postom o primopredaji, operacijama, SLA-ovima i dokumentaciji.

# Definirajte vlasništvo i SLA-ove prije nego dirate tooling#

Održavanje najčešće propadne iz jednog razloga: svi pretpostave da to radi netko drugi. Prije postavljanja alerta ili dependency botova, definirajte vlasnike, ciljeve vremena odgovora i eskalaciju.

RACI i “tko radi što” kroz web, mobilno i automatizaciju#

Ne treba vam teška procedura. Treba vam jasnoća. Dovoljna je lagana RACI matrica: Responsible, Accountable, Consulted, Informed.

Imena se mijenjaju, ali struktura sprječava “mislili smo da vi to imate.”

SLA-ovi koji odgovaraju poslovnom riziku#

SLA-ovi trebaju odražavati utjecaj, a ne optimizam. Tipičan set za post-launch operacije:

Povežite SLA-ove s monitoring okidačima. Ako nijedan alert ne mapira na Sev 1, vaš SLA je teorijski.

ℹ️ Napomena: Tretirajte SLA-ove kao ugovor između producta i engineeringa. Ako se obvezujete na odgovor u 15 minuta, trebate i on-call pokrivenost, pristupe i runbookove da to bude izvedivo.

# Ponavljajući kontrolni popis: tjedno, mjesečno, tromjesečno#

Ovo je srž kontrolnog popisa održavanja web aplikacije. Dizajniran je da se ponavlja, prati i da bude auditabilan. Koristite ticketing sustav, ne shared doc koji nitko ne otvara.

Tjedni popis (brzo, sigurnost na prvom mjestu)#

Tjedni ritam je o sigurnosti, detekciji drifta i ranom hvatanju tihih kvarova.

1) Ovisnosti i sigurnosne zakrpe

Cilj: Smanjiti vrijeme izloženosti poznatim ranjivostima i spriječiti “big bang” projekte nadogradnji.

• Pregledajte PR-ove za ažuriranje ovisnosti.
• Kritične sigurnosne probleme zakrpajte odmah.
• Provjerite promjene lockfilea i pokrenite smoke testove.

Automatizirati:

• Kreiranje dependency PR-ova i osnovne provjere.

Ljudska provjera:

• Mergeanje, posebno kad se može promijeniti runtime ponašanje.

Praktična baza za JS i Flutter:

• Node tooling: npm, pnpm, Yarn lockfile ažuriranja.
• Next.js i React ekosustav: provjerite build output i routing.
• Flutter: flutter pub outdated za vidljivost, ali nadograđujte namjerno.

Primjeri naredbi koje možete pokretati u CI-ju ili lokalno:

npm audit --audit-level=high
npm outdated

flutter pub outdated

2) Monitoring i pregled alerta

Cilj: Učiniti alerte akcijskima, smanjiti noise i otkriti spore regresije.

• Pregledajte zadnjih 7 dana alerta i incidenata.
• Uklonite ili dotjerajte alerte koji su se palili bez ikakve akcije.
• Potvrdite da routing alerta još uvijek dolazi do pravih ljudi.

Minimalni tjedni monitoring signali:

• API stopa grešaka i percentili latencije.
• Database CPU, broj konekcija, spori upiti.
• Dubina reda (queue depth) ili backlog poslova.
• Sintetičke provjere dostupnosti na ključnim user flowovima.

Ako ste fokusirani na performanse, držite ovo usklađeno s baseline metrikama. Naš vodič o optimizaciji performansi web stranice je dobra referenca što mjeriti i zašto.

3) Sigurnosne kopije: potvrditi da su prošle i da se mogu vratiti

Cilj: Sigurnosne kopije su beskorisne dok ne možete napraviti restore.

Tjedno:

• Potvrdite da su backup jobovi završili.
• Potvrdite da je veličina backupa u očekivanom rasponu.

Ljudska provjera:

• Spot-check restore logova ili parcijalni restore na staging.

Automatizirati:

• Raspored backupa, retention politike i alerte za neuspjeh.

4) Zdravlje automatizacijskih workflowa (n8n i integracije)

Cilj: Spriječiti “tihu degradaciju” zbog promjena third-party API-ja, isteka tokena i rubnih payloadova.

Tjedni zadaci:

• Provjerite stopu grešaka n8n izvršavanja.
• Pregledajte neuspjele runove i kategorizirajte uzroke.
• Potvrdite da su kredencijali i OAuth tokeni valjani.
• Provjerite da retry mehanizmi ne maskiraju sistemske kvarove.

Ako se vaše automatizacije oslanjaju na retry i alerting, implementirajte obrasce iz n8n error handling, retries i alerting.

💡 Savjet: Pratite “pouzdanost automatizacije” kao broj: success rate = successful runs / total runs * 100. Ciljajte 99 posto ili više za business-critical workflowe i alertajte ako padne ispod praga dulje od 30 minuta.

5) Drift pristupa i tajni

Cilj: Smanjiti vrijeme incidenta i sigurnosni rizik.

Tjedno:

• Provjerite domene i certifikate kojima ističe rok.
• Potvrdite da raspored rotacije tajni nije probijen.
• Osigurajte da je pristup produkciji i dalje ograničen na potrebne osobe.

Ljudska provjera:

• Odobravanje promjena pristupa.
• Validacija least-privilege uloga.

Mjesečni popis (stabilnost, higijena i kontrolirane nadogradnje)#

Mjesečno je kada namjerno podižete pouzdanost i sprječavate nakupljanje tehničkog duga.

1) Planirane nadogradnje ovisnosti i regresijske provjere

Cilj: Ostanite unutar podržanih verzija i izbjegnite end-of-life rizik.

Mjesečne radnje:

• Nadogradite ne-razbijajuće ovisnosti.
• Provjerite support prozore frameworka, posebno za Next.js i Node LTS.
• Pokrenite regresijska testiranja na ključnim flowovima.

Praktičan pristup:

• Mergeajte low-risk ažuriranja kontinuirano.
• Grupirajte medium-risk ažuriranja u mjesečni release train.
• Velike nadogradnje planirajte tromjesečno.

2) Sigurnosni pregled: tempo zakrpa, headeri i dozvole

Cilj: Smanjiti attack surface i provjeriti sigurnosne pretpostavke.

Mjesečne provjere za web aplikacije:

• Potvrdite da su security headeri prisutni i ispravni.
• Pregledajte postavke autentikacije i sesija.
• Provjerite rate limiting na osjetljivim endpointima.

Mjesečne provjere za mobilno:

• Osigurajte da su SDK-ovi ažurirani zbog poznatih CVE-ova.
• Pregledajte dozvole za analitiku i push notifikacije.
• Validirajte strategiju certificate pinninga ako je primjenjivo.

Mjesečne provjere za automatizaciju:

• Pregledajte tokene i scopeove te rotirajte dugotrajne kredencijale.
• Potvrdite da su webhook endpointi zaštićeni i validirani.

Ako želite konkretan baseline za security headere, testirajte javne endpointe s Mozilla Observatory i pratite poboljšanja kroz vrijeme.

3) Baseline performansi i provođenje budžeta

Cilj: Zaustaviti regresije performansi prije nego ih korisnici osjete.

Mjesečni zadaci:

• Usporedite trenutne Core Web Vitals s prošlim mjesecom.
• Provjerite top stranice i ključne flowove za promjene LCP, INP, CLS.
• Identificirajte nove teške client bundleove ili server “hotspotove”.

Rad na performansama nikad nije “gotov”. Čim dodate feature, mijenjaju se bundle, upiti i caching. Držite budžete eksplicitnima:

• Maksimalni JS po ruti.
• Maksimalna API p95 latencija.
• Maksimalno vrijeme DB upita za ključne endpointe.

4) Vježba povrata backupa na staging

Cilj: Dokazati da se možete oporaviti.

Mjesečna vježba:

• Restore baze na staging.
• Pokrenite skriptirani smoke test.
• Dokumentirajte vrijeme povrata.

Pratite:

• RPO kao “koliko podataka si možete priuštiti izgubiti”.
• RTO kao “koliko brzo možete ponovno biti dostupni”.

Koristite samo inline matematiku: RTO = restore time + verification time.

5) Pregled workflowa i kvalitete podataka za automatizacije

Cilj: Održati automatizacije usklađenima s poslovnom stvarnošću.

Mjesečna pitanja za pregled:

• Koji workflowi generiraju ručni rad zbog djelomičnih kvarova?
• Koje integracije su promijenile polja ili formate?
• Prikupljamo li nove podatke koji trebaju validacijska pravila?

Za n8n, prepoznajte anti-patternove:

• Nema idempotency, pa nastaju duplikati.
• Preveliko oslanjanje na retry, pa greške kasne.
• Nema dead-letter ili puta za ručnu provjeru loših payloadova.

Tromjesečni popis (upravljanje rizikom i priprema za budućnost)#

Tromjesečno je kada radite veće poteze: velike nadogradnje, arhitekturne korekcije i učenje iz incidenata.

1) Nadogradnje glavnih verzija i lifecycle platforme

Cilj: Ostati podržan i smanjiti dugoročni trošak.

Tromjesečno planiranje:

• Nadogradite Node na najnoviji LTS.
• Nadogradite Next.js na novu glavnu verziju kad treba.
• Nadogradite Flutter i kritične plugine.
• Pregledajte verzije baze podataka i cache enginea.

Ljudska provjera je ovdje obavezna:

• Test planovi, rollback planovi i release prozori.
• Dokumentacija breaking promjena.

2) Postmortemi incidenata i poboljšanja pouzdanosti

Cilj: Smanjiti ponavljanja incidenata i skratiti vrijeme oporavka.

Tromjesečno:

• Pregledajte sve Sev 1 i Sev 2 incidente.
• Identificirajte ponavljajuće uzroke.
• Pretvorite lekcije u engineering zadatke.

Pratite metrike koje prisiljavaju napredak:

• MTTA: mean time to acknowledge.
• MTTD: mean time to detect.
• MTTR: mean time to recover.

Čak i ako ih ne izračunate savršeno, trend je bitan.

3) DR plan i pregled pristupa

Cilj: Validirati da je “možemo se oporaviti” istina.

Tromjesečni DR zadaci:

• Puni restore i simulacija cutovera u neprodukcijskom okruženju.
• Provjerite procese obnove DNS-a, CDN-a i certifikata.
• Rotirajte privilegirane kredencijale.
• Pregledajte i uklonite zastarjele pristupe.

⚠️ Upozorenje: Mnogi timovi backupiraju bazu, ali zaborave object storage. Ako aplikacija ovisi o uploadovima, računima ili generiranim PDF-ovima, provjerite i te backupove i restore putanje.

4) Pregled arhitekture automatizacija

Cilj: Zadržati automatizacije održivima kako rastu.

Tromjesečni pregled:

• Konsolidirajte duplicirane workflowe.
• Uvedite zajedničke utilitie: validaciju, logging, retry politike.
• Odlučite što treba prebaciti iz workflow logike u kod, posebno složene transformacije.

Korisno pravilo:

• Ako workflow zahtijeva više od 2 stranice dokumentacije ili česte hotfixeve, razmislite o migraciji core logike u servis s testovima, a neka n8n orkestrira.

# Što automatizirati, a što zahtijeva ljudsku provjeru#

Automatizacija treba smanjiti toil, ne povećati rizik. Koristite ovu podjelu kao politiku.

Najbrži način da stvorite “maintenance dug” je potpuno automatsko mergeanje nadogradnji bez vlasnika i plana izdanja.

# Praktičan kontrolni popis koji možete kopirati u tickete#

Koristite ovo kao ponavljajuće zadatke u Jira, Linear ili GitHub Issues. Neka svaka stavka bude binarna: odrađeno ili nije odrađeno.

Tjedni predložak ticketa#

Mjesečni predložak ticketa#

Tromjesečni predložak ticketa#

# Minimalna implementacija: tooling koji pokriva 80 posto#

Ne treba vam enterprise tooling da biste imali profesionalne operacije. Pragmatičan baseline:

Ako želite da održavanje bude mjerljivo, automatski povežite alerte s ticketima i tagirajte ih severityjem.

# Ključne poruke#

• Pretvorite održavanje u ponavljajuće tickete s opsegom tjedno, mjesečno i tromjesečno, i tražite dokaze poput logova, izvješća ili snapshotova metrika.
• Definirajte vlasništvo jednostavnim RACI-jem i postavite realne SLA-ove po severityju, zatim mapirajte alerte na te severityje da ciljevi odgovora budu ostvarivi.
• Automatizirajte low-risk, high-frequency posao poput skeniranja, zakazivanja backupa i dependency PR-ova, ali držite ljude u petlji za mergeanje, major nadogradnje, restore i promjene pristupa.
• Smatrajte backup nedovršenim dok ne radite redovite restore vježbe i ne pratite RTO i RPO prema poslovnim očekivanjima.
• Spriječite propadanje automatizacija praćenjem success ratea workflowa, validacijom promjena third-party API-ja i implementacijom retry plus alerting obrazaca.

# Zaključak#

Lansiranje bez plana održavanja je spori neuspjeh. Ako ovaj kontrolni popis održavanja web aplikacije implementirate kao ponavljajući posao s vlasnicima, SLA-ovima, monitoringom i restore vježbama, vaši web, mobilni i automatizacijski sustavi ostat će pouzdani i jeftiniji za održavanje.

Ako želite da Samioda to postavi end-to-end, uključujući monitoring, alerting, strategiju ovisnosti i “hardening” n8n workflowa, javite nam se kroz naš playbook za post-launch operacije ili krenite s baselineom performansi uz naš vodič o optimizaciji performansi web stranice.