Nakon lansiranja: naš agencijski playbook za predaju softverskog projekta nakon lansiranja

# Uvod: Lansiranje je prekretnica, ne ciljna crta#

Većina produkcijskih incidenata događa se kad nedostaje kontekst: nejasan pristup, nedokumentirani tijekovi rada ili izostanak dogovorenog procesa odgovora. Zato se predaja softverskog projekta nakon lansiranja mora tretirati kao inženjerski isporučiv artefakt, a ne administrativni zadatak.

Kvalitetna predaja smanjuje rizik na tri mjerljiva načina: brže vrijeme detekcije problema, brže vrijeme vraćanja usluge i manje praznina u vlasništvu koje blokiraju odluke. Ovaj post je naš agencijski playbook koji pokriva dokumentaciju, SLA-ove, pristupe, monitoring dashboarde, incident response i ritam održavanja, uz checklistu za preuzimanje koju možete kopirati u vlastiti proces.

Ako želite širi kontekst isporuke, ovo se dobro nadovezuje na naš pregled procesa: Proces web razvoja korak po korak.

# Kako izgleda “dobro” nakon lansiranja: ishodi i stvari o kojima nema pregovora#

Predaja je uspješna kada tim koji nije gradio aplikaciju može njome sigurno upravljati. Ciljamo ishode koje možete provjeriti već unutar prvog tjedna nakon go-livea.

Pet ishoda o kojima nema pregovora#

1. 1
   Vlasništvo je eksplicitno: tko odlučuje, tko odobrava, tko izvršava i tko dobiva poziv (paged) je zapisano.
2. 2
   Pristup je kontroliran i auditabilan: nema dijeljenih lozinki, nema “misterioznih” admin računa, nema privatnih emailova.
3. 3
   Opservabilnost je aktivna: dashboardi postoje, alerti su testirani, a logovi pretraživi.
4. 4
   Postoje runbookovi za najčešće incidente: koraci oporavka su provedivi, ne teorijski.
5. 5
   Održavanje je planirano: imate ritam za nadogradnje, backup, sigurnosne zakrpe i pregled troškova.

🎯 Ključna poruka: Ako ne možete odgovoriti na pitanje “tko je trenutno vlasnik produkcije” u manje od 30 sekundi, nemate stvarnu predaju.

Zašto je ovo bitno u brojkama#

• IBM-ova često citirana procjena prosječnog troška curenja podataka iznosi 4,88 milijuna USD globalno u 2024., a pogrešne konfiguracije pristupa redovito su temeljni uzrok u incident reportovima. Smanjenje “access sprawl” i stroži offboarding spadaju među post-launch zadatke s najvećim ROI-em.
• Googleove SRE prakse naglašavaju da je smanjenje prosječnog vremena detekcije i vraćanja usluge glavni alat za pouzdanost. Monitoring i runbookovi izravno ciljaju te metrike.

Praktično: ne trebate “enterprise” alate da biste dobili enterprise rezultate. Trebate dosljednu strukturu.

# Isporuka 1: Mapa vlasništva i RACI (klijent naspram agencije)#

Najbrži način da nakon lansiranja nastane kaos je pretpostaviti vlasništvo. Uloge i odgovornosti eksplicitno definiramo na jednoj stranici u RACI-u i držimo ga na istom mjestu kao i runbookove.

Jednostavan RACI koji radi za većinu proizvoda#

Postavite granice da izbjegnete skriveni scope#

Ugovori o podršci pucaju kada se “održavanje” koristi za provlačenje feature posla. Mi odvajamo:

• Reliability rad: uptime, performanse, bug fix, nadogradnje.
• Change rad: novi featurei, redizajni, nove integracije.

Povežite to s quality gateovima. Ako želite čvrstu pre-launch osnovu, koristite ponovljivu QA strategiju poput one koju opisujemo ovdje: Agencijska QA strategija testiranja za web i mobilnu automatizaciju.

# Isporuka 2: Upravljanje pristupima koje preživljava promjene u timu#

Pristup je prva stvar koja vam treba tijekom incidenta i prva stvar o kojoj auditori pitaju. Pristup tretiramo kao formalni inventar s datumima isteka, a ne kao hrpu pozivnica.

Inventar pristupa (što točno navodimo)#

Isporučujemo registar pristupa s:

Ovo sprječava klasični problem “ne možemo deployati jer je inženjer koji je to postavio otišao”.

Minimalne privilegije, vremenski ograničen pristup i break-glass računi#

• Minimalne privilegije: agenciji dajte samo pristup koji joj treba za operiranje sustavom.
• Vremenski ograničeno: tijekom hypercarea odobrite povišeni pristup, a zatim ga automatski smanjite nakon razdoblja predaje.
• Break-glass: jedan emergency admin račun, u vlasništvu klijenta, zaštićen snažnim MFA-om, spremljen u sigurnom vaultu, korišten isključivo za kritični oporavak.

⚠️ Upozorenje: Ne koristite dijeljene kredencijale za cloud, DNS ili app storeove. Dijeljeni kredencijali uništavaju auditabilnost i čine offboarding nepouzdanim.

Higijena tokena za API-je i automatizacije#

Ako koristite n8n, Zapier ili custom cron jobove, skriveni rizik su long-lived tokeni kojih se nitko ne sjeća. Uključujemo:

• Popis svih tokena i webhooks koji se koriste u produkciji.
• Upute za rotaciju i raspored rotacije.
• Napomenu o “blast radiusu” za svaki token: što se kvari ako se opozove.

Ako automatizirate operativne tokove, držite pravila vlasništva i pristupa usklađenima s ostatkom proizvoda, posebno za incident notifikacije i customer emailove.

# Isporuka 3: Runbookovi i “Day 2” dokumentacija koju ljudi stvarno koriste#

Dokumentacija propada kad je napisana kao specifikacija. Post-launch dokumentacija mora biti napisana kao pilotski checklist: kratko, provjerljivo i povezano s alatima.

Minimalni set dokumenata koji predajemo#

Format runbooka koji koristimo (copy-paste predložak)#

Svaki runbook neka bude:

• Simptomi: što ćete vidjeti na dashboardima i u logovima.
• Utjecaj: što korisnici doživljavaju i koji su podaci ugroženi.
• Provjere: 3 do 5 brzih potvrda.
• Akcije: korak-po-korak popravci s rollback opcijama.
• Eskalacija: kada pageati agenciju i tko odobrava rizične akcije.
• Nakon incidenta: koje metrike i bilješke prikupiti.

💡 Savjet: Svaki korak u runbooku stavite uz link na dashboard ili log query. Ako se korak ne može provjeriti, to nije korak — to je pretpostavka.

Primjer: kratki snippet runbooka za rollback#

# 1) Identify the last known good deployment
git tag --list "prod-*"
git show prod-2026-08-01
 
# 2) Roll back (example: Docker + container registry)
docker pull registry.example.com/app:prod-2026-08-01
kubectl set image deployment/app app=registry.example.com/app:prod-2026-08-01
 
# 3) Verify health
kubectl rollout status deployment/app
curl -f https://api.example.com/health

Neka bude kratko. Ako runbook treba 80 linija, podijelite ga.

# Isporuka 4: Monitoring dashboardi i alerti koji hvataju stvarne kvarove#

Predaja bez opservabilnosti je samo optimizam. Dashboarde i alert pravila isporučujemo kao dio definicije “done”.

Za dublji praktični vodič, pogledajte naš post o opservabilnosti: Vodič za opservabilnost web aplikacija za logove, metrike i tracing.

Set dashboarda koji smatramo baselineom#

Principi alertinga koji smanjuju šum#

Alerte dizajniramo tako da budu provedivi:

• Alertajte prvo na utjecaj na korisnike: error budgeti, 5xx skokovi, checkout kvarovi.
• Kad je moguće, koristite burn-rate alerte za SLO-ove umjesto sirovih thresholdova.
• Rutirajte alerte u jedan primarni kanal s definiranim on-call rasporedom.

Praktičan kompromis kad nemate puni SLO “stroj”: alertajte na stopu i trajanje.

# Example pseudo-rule for high API error rate
name: api_5xx_spike
condition: "5xx_rate_percent >= 2 for 5m AND requests_per_minute >= 100"
severity: high
notify: ["oncall", "incident-channel"]
runbook: "https://docs.example.com/runbooks/api-5xx"

Test primopredaje monitoringa (uvijek ga radimo)#

Prije nego što predaju proglasimo završenom, validiramo:

1. 1
   Alerte okidamo kad treba koristeći kontrolirani test endpoint ili synthetic monitor.
2. 2
   Prave osobe dobiju alerte unutar 60 sekundi.
3. 3
   Link na runbook radi i dostupan je bez posebnog VPN pristupa.
4. 4
   Alerte je moguće potvrditi (acknowledge) i utišati (silence) uz audit logove.

Time monitoring prelazi iz “konfigurirano” u “operativno”.

# Isporuka 5: Incident response, SLA-ovi i pravila komunikacije#

Incidenti su neizbježni. Zbunjenost je izbježiva. Definiramo incident proces i SLA uvjete tako da ne pregovarate usred outagea.

Razine ozbiljnosti s ciljevima odaziva#

Koristite mali set razina ozbiljnosti, vezan uz mjerljiv utjecaj:

Vrijeme odaziva odnosi se na potvrdu (acknowledgement) i trijažu, ne na rješenje. Ciljevi vraćanja usluge moraju uzeti u obzir kvarove ovisnosti i vremena app store reviewa kad je riječ o mobilnim aplikacijama.

Tko što govori, i gdje#

Definiramo komunikacijske kanale:

• Interni incident kanal: samo engineering, visoki signal.
• Kanal za stakeholdera: kratke obavijesti, utjecaj, ETA, vrijeme sljedećeg updatea.
• Customer updatei: status stranica ili email, unaprijed odobreni predlošci.

Također definirajte tko može odobriti rizične akcije, poput database rollbcka ili isključivanja payment providera.

ℹ️ Napomena: Ako ste u reguliranoj industriji, incident bilješke usmjerite u trajni log radi audita. Treatajte incident write-upove kao kontrolirane dokumente.

Post-incident rutina#

Svaki SEV1 i SEV2 dobiva:

• Kratku vremensku crtu s timestampovima.
• Root cause i doprinoseće faktore.
• Action iteme s vlasnicima i datumima.
• Plan prevencije mapiran na monitoring i testove.

Tu se QA i opservabilnost vraćaju u isporuku. Najbolji incident je onaj koji postane test i alert.

# Isporuka 6: Ritam održavanja i vlasništvo nad “održavanjem zdravlja”#

Nakon lansiranja sustav počinje driftati: ovisnosti stare, troškovi rastu, a vendor API-ji se mijenjaju. Održavanje je način da spriječite spore kvarove.

Ritam održavanja koji preporučujemo#

Ritam vežite uz vlasništvo. Klijent treba posjedovati prioritizaciju, a agencija može izvršavati kroz ugovor o održavanju.

Što “održavanje” uključuje i isključuje#

Ovo eksplicitno definirajte u handoff paketu.

Ovo sprječava razočaranje i stvara čist proces promjena za roadmap posao.

# Checklist za preuzimanje: kopirajte ovaj handoff paket u svoj workspace#

Možete ovo zalijepiti u Notion, Confluence ili GitHub issue i pratiti završetak. Tretirajte kao release gate za svoju predaju softverskog projekta nakon lansiranja.

Handoff Checklist (Markdown)#

# After-Launch Handoff Checklist
 
## 1) Ownership and Roles
- [ ] RACI agreed and shared with stakeholders
- [ ] On-call schedule defined for hypercare and after
- [ ] Escalation path documented (names, phone, email)
- [ ] “Break-glass” approver identified (client)
 
## 2) Access and Security
- [ ] Root accounts owned by client (cloud, DNS, stores, billing)
- [ ] Agency access granted with least privilege
- [ ] MFA enabled everywhere possible
- [ ] Shared credentials eliminated
- [ ] Token and webhook inventory completed
- [ ] Offboarding steps written per system
 
## 3) Documentation and Runbooks
- [ ] Architecture overview with dependency map
- [ ] Deployment and rollback runbook verified
- [ ] Incident runbook with severity levels and comms rules
- [ ] Operations runbook (backups, restores, rotations)
- [ ] Known risks list with owners and due dates
 
## 4) Observability
- [ ] Dashboards: golden signals, API, frontend, DB, queues, third-party, cost
- [ ] Alerts configured for user impact
- [ ] Alert routing tested end-to-end
- [ ] Log search and trace navigation documented
- [ ] Synthetic checks for critical flows added
 
## 5) Release and Environment Hygiene
- [ ] Environments defined (dev, staging, prod) with clear purpose
- [ ] Secrets management documented and rotated if needed
- [ ] Backups enabled and restore test scheduled
- [ ] Data retention and GDPR policy confirmed
 
## 6) Support and Maintenance
- [ ] SLA terms agreed (response, updates, restore targets)
- [ ] Hypercare period defined (30 to 90 days recommended)
- [ ] Maintenance cadence agreed (weekly, monthly, quarterly)
- [ ] Change request process documented

💡 Savjet: Prođite checklistu kao agendu sastanka i odradite uživo “test pristupa i alerta” sesiju. Većina rupa u predaji otkrije se tek kad simulirate stvarni incident.

# Ključne poruke#

• Učinite vlasništvo eksplicitnim pomoću jednostraničnog RACI-a koji pokriva produkcijski pristup, incident response i granice održavanja.
• Tretirajte pristup kao auditabilan inventar: klijent je vlasnik root računa i naplate, agencija dobiva minimalne privilegije, vremenski ograničene dozvole i testiran offboarding.
• Isporučite runbookove koje se može izvršiti: simptomi, provjere, akcije, rollback, eskalacija i post-incident bilješke.
• Zahtijevajte opservabilnost kao isporuku predaje: dashboardi, testovi rutiranja alerta i alerti povezani s runbookovima za smanjenje vremena detekcije i vraćanja usluge.
• Definirajte SLA-ove i ritam održavanja unaprijed kako ne biste pregovarali tijekom outagea ili slučajno pretvorili podršku u razvoj featurea.

# Zaključak#

Pouzdana predaja softverskog projekta nakon lansiranja nije mapa s PDF-ovima. To je operativni model koji funkcionira: jasno vlasništvo, kontrolirani pristup, provedivi runbookovi, testiran monitoring i ritam održavanja koji sprječava drift.

Ako želite da odradimo vašu post-launch predaju ili postavimo support i opservability tako da vaš tim to može samouvjereno preuzeti, kontaktirajte Samioda i predložit ćemo handoff paket, SLA opcije i plan implementacije usklađen s vašim stackom u React, Next.js, Flutter i automations.