ISO/IEC 20000-1 u praksi - Ponuda, potražnja, dizajn i promene

ISO/IEC 20000-1 u praksi — deo 7 od 10

SLA iz prethodnog teksta obećava konkretne brojeve. Ovaj deo standarda pita nešto neprijatnije: šta se dešava kad platforma naraste, kad prodaja potpiše tri nova ugovora u istom kvartalu, ili kad neko treba da promeni nešto na produkciji a da pritom ne izazove tačno onaj incident koji SLA pokušava da spreči. Kapacitet i upravljanje promenama su, u praksi, dve strane iste priče — jedna sprečava da firma obeća više nego što može da isporuči, druga sprečava da firma sama sebi pokvari ono što već radi.

8.4.1 — Budžetiranje, ukratko

Nimbus Ops ne vodi poseban formalni dokument za ovo — troškovi AWS infrastrukture se prate mesečno kroz cost allocation tagove po klijentskom paketu (Standard/Premium/Enterprise), što Marku Jovanoviću daje jasnu sliku profitabilnosti po nivou usluge, a direktno se naslanja na rizik R06 iz registra rizika (kolebanje troškova u USD).

8.4.2–8.4.3 — Plan kapaciteta

Plan kapaciteta kod Nimbus Ops-a pokriva dve odvojene stvari koje se lako pobrkaju: tehnički kapacitet platforme i kapacitet ljudi koji rade implementacije. Oboje su usko vezani za rizike R01 i R04 iz registra.

Nimbus Ops d.o.o. — interni dokument sistema upravljanja uslugama
Plan kapaciteta — 2026.
Šifra dokumenta: NO-SMS-DOC-013 Verzija: 1.0 Status: Aktivan
Vlasnik dokumenta: Nikola Erić Poslednje ažuriranje: 10.02.2026. Ciklus pregleda: Kvartalno

A. Infrastruktura (Nimbus Watch platforma)

Resurs Trenutna iskorišćenost Prag za akciju
EKS klaster — CPU (CI-005)62% prosečno, do 85% u vršnim satima80% prosečno → dodavanje čvorova
EKS klaster — memorija58% prosečno75% prosečno
RDS baza — storage (CI-004)71%80% → read replika ili scale-up
RDS baza — CPU45%70%
MSK (Kafka) throughput (CI-006)55% od provisioned kapaciteta70%
Broj monitorisanih čvorova (svi klijenti)~3.200, rast ~8% kvartalnoProjekcija se revidira na 5.000

Prognoza: Na osnovu trenutnog rasta i pipeline-a prodaje (dva nova Enterprise klijenta očekivana u drugoj polovini 2026), broj monitorisanih čvorova bi mogao preći 4.500 do kraja godine. To direktno gura RDS storage i EKS CPU ka pragovima za akciju ranije nego što bi organski rast sam po sebi predvideo.

Planirane investicije:

  • Q2 2026 — dodavanje read replike za RDS bazu (rasterećenje upita za izveštavanje) — videti RFC primer ispod
  • Q3 2026 — evaluacija prelaska na veći instance tip za EKS node grupe
  • Q4 2026 — revizija MSK particionisanja radi budućeg rasta

B. Ljudski kapacitet (Nimbus Care)
Trenutno 8 konsultanata sa prosečnom popunjenošću 92% — praktično bez slobodnog kapaciteta za nove projekte, što je već zabeleženo kao rizik R04 (nivo 16, visok). Pipeline prodaje pokazuje tri nova implementaciona projekta ugovorena za Q2–Q3 2026, što bi zahtevalo dodatnih ~1,5 FTE. Mere: otvorena pozicija za jednog Nimbus Care konsultanta (oglašena februar 2026), i ugovor sa spoljnim frilenserom kao rezerva za vršne periode.

8.5.1 — Politika upravljanja promenama

Rizik R07 (neplanirana promena izazove ispad usluge, nivo 15, visok) je razlog zašto ova politika postoji u pisanom obliku, a ne kao "javi se u Slack pre nego što nešto diraš na produkciji" — što je, iskreno, bio neformalni proces do sredine 2025.

Nimbus Ops d.o.o. — interni dokument sistema upravljanja uslugama
Politika upravljanja promenama
Šifra dokumenta: NO-SMS-DOC-014 Verzija: 1.0 Status: Aktivan
Vlasnik dokumenta: Ana Ristić Odobrio: Marko Jovanović Datum izdavanja: 15.09.2025.

1. Kategorije promena

  • Standardna — niskorizična, ponavljajuća promena sa unapred odobrenom procedurom (npr. rutinski sigurnosni patch, restart poznatog tipa). Ne zahteva pojedinačno CAB odobrenje, samo prijavu u Jira pre izvođenja.
  • Normalna — zahteva popunjen RFC obrazac i odobrenje CAB-a pre implementacije. Ovo je podrazumevana kategorija za sve promene koje nisu standardne ili hitne.
  • Hitna — implementira se odmah radi zaustavljanja ili sprečavanja incidenta u toku. Ne čeka se CAB; retroaktivno odobrenje i dokumentovanje u roku od 24h.

2. Change Advisory Board (CAB)
Sastav: Ana Ristić (predsedava), Nikola Erić (tehnička procena), Stefan Vuković (za promene sa bezbednosnim uticajem), Jelena Popović (po potrebi, ako promena utiče na aktivne klijentske projekte). CAB se sastaje nedeljno (utorkom) i po potrebi vanredno za hitne slučajeve koji ipak dozvoljavaju kratko čekanje.

3. Procena rizika promene
Svaka Normalna promena mora imati procenu rizika (nizak/srednji/visok) na osnovu: kritičnosti pogođenih komponenti (prema CMDB, deo 5 ove serije), složenosti rollback-a, i toga da li se promena izvodi u definisanom prozoru održavanja ili van njega.

4. Obavezni elementi svakog RFC-a
Opis promene, poslovno opravdanje, pogođene komponente (CI reference), procena rizika, plan testiranja, rollback plan, predloženi prozor izvođenja.

5. Freeze periodi
Bez ne-hitnih promena tokom poslednje nedelje decembra i u periodima najavljenih velikih demonstracija ili poslovno kritičnih događaja kod Enterprise klijenata (najava dolazi od Milice Đorđević najmanje 10 dana unapred).

Primer popunjenog RFC obrasca

Evo kako izgleda stvarno podnet zahtev za promenu — baš onaj koji rešava problem rasta baze pomenut u Planu kapaciteta iznad.

Nimbus Ops d.o.o. — Zahtev za promenu (RFC)
RFC-2026-014 — Dodavanje read replike za nimbus-watch-db
Šifra dokumenta: NO-SMS-DOC-015 Kategorija: Normalna Status: Odobreno
Podnosilac: Nikola Erić Datum podnošenja: 10.02.2026. Procena rizika: Srednja

Opis promene
Uvođenje read replike za produkcionu RDS PostgreSQL bazu (CI-004) radi rasterećenja upita za izveštavanje sa primarne instance.

Poslovno opravdanje
Iskorišćenost storage-a i CPU-a na primarnoj bazi približava se pragu definisanom u Planu kapaciteta (NO-SMS-DOC-013). Postoji rizik od degradacije performansi tokom vršnih perioda, posebno za Enterprise klijente sa strožim SLA ciljevima (P1 odziv 15 min, dostupnost 99,9%).

Pogođene komponente (CMDB)
CI-004 (nimbus-watch-db) — direktno; CI-001 (nimbus-watch-api) — indirektno, zbog izmene konfiguracije rutiranja upita.

Plan testiranja
Verifikacija replikacije na staging okruženju pre produkcije; provera da API ispravno rutira read upite ka replici bez uticaja na write operacije.

Rollback plan
Uklanjanje read replike ne utiče na primarnu bazu. U slučaju problema, konfiguracija API-ja se vraća na direktno čitanje sa primarne instance putem feature flag-a — bez potrebe za novim deployem.

Predloženi prozor izvođenja
Nedelja, 22.02.2026, 02:00–04:00 CET (redovan prozor za planirano održavanje, u skladu sa SLA tačkom 5).

Odobrenja

Odobrio Uloga Datum
Ana Ristić Proceduralno odobrenje 12.02.2026.
CAB (kolektivno) Tehnička i rizik procena 12.02.2026. — jednoglasno odobreno

8.5.5 — Plan izdanja

Odobrena promena se ne izvodi izolovano — uklapa se u kalendar izdanja koji Nikola Erić vodi kako se rutinske popravke ne bi sudarale sa većim funkcionalnim izdanjima u istoj nedelji.

Nimbus Ops d.o.o. — interni dokument sistema upravljanja uslugama
Plan izdanja — Q1 2026.
Šifra dokumenta: NO-SMS-DOC-016 Verzija: 1.0 Status: Aktivan
Vlasnik dokumenta: Nikola Erić Poslednje ažuriranje: 10.02.2026. Ciklus: Nedeljne popravke, mesečna funkcionalna izdanja
Verzija Sadržaj Datum Rizik Povezan RFC
2026.03.1 Redovne sigurnosne zakrpe (standardna promena) 01.03.2026. Nizak — (standardna, bez RFC)
2026.02 Read replika baze, manje popravke dashboard UI-ja 22.02.2026. Srednji RFC-2026-014
2026.03 Novi modul za prilagođene alarme (custom alert rules) 15.03.2026. Visok (nova funkcionalnost) RFC-2026-021 (u pripremi)

Izdanja ocenjena kao "Visok" rizik automatski se najavljuju Enterprise klijentima najmanje dve nedelje unapred, u skladu sa freeze pravilima iz Politike upravljanja promenama.

Kako se ovo koristi u svakodnevnom radu

Plan kapaciteta se ne čita jednom kvartalno i zaboravlja — brojevi iz njega su razlog zašto RFC-2026-014 uopšte postoji. Bez zapisanog praga ("80% storage → read replika"), odluka o tome kada tačno reagovati zavisila bi od toga ko je te nedelje gledao dashboard, a ne od unapred dogovorenog pravila.

RFC proces je najvidljiviji u trenutku kad neko u inženjerskom timu poželi da "brzo nešto ispravi" na produkciji van CAB sastanka — tada matrica iz Teksta 2 i ova politika jasno kažu: ili je promena standardna (pa ide direktno), ili čeka utorak, ili je dovoljno hitna da opravda hitnu kategoriju — ali "brzo i tiho" nije opcija koja postoji.

Sledeći tekst u seriji prelazi na rešavanje — obrazac prijave incidenta, matrica prioriteta, primer velikog incidenta sa post-incident izveštajem i zapis poznate greške.

Comments

Post a Comment

Popular posts from this blog

Šta je ISO 27001 i da li je mojoj firmi stvarno potreban?

  Prvi tekst na blogu InfoSec bez stresa — i pitanje koje sebi postavi skoro svaki vlasnik male ili srednje firme onog trenutka kad prvi put čuje za ovaj standard. Realna situacija Zamislite ovo: firma ima 15 zaposlenih, radi razvoj softvera ili pruža IT usluge, posluje solidno, sve funkcioniše. Onda stigne mejl od velikog klijenta — banke, osiguravajuće kuće ili strane kompanije s kojom se pregovara o saradnji. U prilogu je bezbednosni upitnik, a na dnu jedna rečenica koja pokvari popodne: „Molimo dostavite ISO 27001 sertifikat ili plan implementacije u naredna tri meseca." Ili, druga verzija iste priče: firma konkuriše na tenderu, sve uslove ispunjava — sem jednog. Traži se ISO 27001. Prva reakcija je obično paničan Google upit u stilu „šta je ISO 27001" i „da li mi to stvarno treba", u ponoć, uz osećaj da se upravo otvorila rupa u budžetu i rasporedu koje niko nije planirao. Ako je ovo vaša situacija — ili slutite da bi mogla postati — ovaj tekst je tu da va...
Read more

ISO 22301:2019 u praksi — Praktična obuka na primeru fabrike piva

Ova serija od osam članaka provodi vas kroz sve zahteve standarda ISO 22301:2019 — Sistemi upravljanja kontinuitetom poslovanja (BCMS) , klauzulu po klauzulu, na konkretnom praktičnom primeru: fiktivnoj proizvodnoj pivari „Zeleni Hmelj" d.o.o. , sa sopstvenom varionicom, punionicom i hibridnom IT/OT arhitekturom (SCADA/PLC industrijski sistemi, lokalni ERP i cloud servisi — Microsoft 365, cloud backup/DR, SaaS CRM). Umesto apstraktnog prepričavanja teksta standarda, svaki post gradi stvaran, upotrebljiv dokument — politiku, matricu, BIA analizu, BCP plan, zapisnik — kakav bi auditor tražio na sertifikacionoj proveri. Kroz celu seriju provlači se jedan princip: zahtevi kontinuiteta poslovanja dolaze od biznisa ka IT sektoru, a ne obrnuto — proizvodnja i komercijala definišu koliko dugo mogu da izdrže bez svog sistema, a IT/OT sektor sprovodi tehnička rešenja koja taj zahtev ispunjavaju. Sadržaj serije Deo 1 Uvod u BCMS i Klauzula 4 — Kontekst organizacije Razlika BCMS v...
Read more

ISO 27031: Upravljanje IRBC-om i usklađivanje sa ciljevima kontinuiteta (klauzula 6.1–6.3)

6.1 – Opšte Standard deli uzroke prekida u nekoliko grupa: prirodni uzroci – požar, poplava. Retki, ali fizički pogađaju celu lokaciju odjednom, ne samo jednu komponentu. tehnički kvarovi – hardver, softver, napajanje, klimatizacija. Najčešća kategorija u praksi, i ona za koju firme obično imaju najviše iskustva. ljudska greška – loše podešen bekap, propust u upravljanju izmenama. Retko ko je namerno kriv, ali posledice su iste kao da jeste. namerna akcija – hakovanje, malver, sabotaža. Ovde je pored oporavka bitna i istraga – ko je i kako ušao. društveni faktori – pandemija, štrajk. Ne pogađaju tehnologiju direktno, nego ljude koji je održavaju. cyber napadi – DoS, DDoS, napadi koji preplave sistem saobraćajem dok ne prestane da radi. lanac snabdevanja – prekid kod cloud provajdera, nejasni bezbednosni uslovi u ugovoru sa dobavljačem. Ovde firma nema direktnu kontrolu, samo ugovor i poverenje. Rizik da IT prestane da radi ima jedan prepoznatljiv obrazac: retko se ...
Read more