ISO 27031: Hibridna infrastruktura i model deljene odgovornosti

Kad je VoxServis pre dve godine potpisivao ugovor za cloud CRM (sistem za praćenje klijenata koji radi na serverima spoljnog dobavljača, ne kod VoxServis-a), u ponudi je pisalo: 99,9% dostupnosti, podaci se čuvaju na dva odvojena mesta. Zvučalo je bolje od bilo čega što je VoxServis ikad imao na sopstvenim serverima. Prirodan zaključak, iako nikad izgovoren naglas: ovaj deo je sad tuđi problem, dobavljač to već rešava.

Taj zaključak je pogrešan. Ne zato što dobavljač laže o dostupnosti – 99,9% dostupnosti platforme je realan i najčešće ispunjen broj. Nego zato što dostupnost platforme i mogućnost da vi vratite svoje podatke nisu ista stvar.

Šta dobavljač garantuje, a šta ne

Cloud dobavljač je odgovoran za infrastrukturu ispod usluge – fizičke servere, mrežu između njih, rezervno napajanje. Ako jedan njihov data centar (prostorija puna servera) izgori, imaju plan da vaš CRM nastavi da radi iz drugog. To zaista dobijate za svoj novac.

Ono za šta ste i dalje odgovorni vi: kako je vaš nalog podešen, ko ima pristup čemu, i da li možete da vratite stanje na jučerašnji dan ako neko – slučajno ili namerno – nešto obriše ili enkriptuje. Visoka dostupnost platforme štiti od toga da dobavljač padne. Ne štiti od toga da zaposleni greškom obriše bazu kontakata, ili da ransomware (virus koji zaključava fajlove i traži otkup) enkriptuje podatke koji se automatski sinhronizuju u cloud. U oba slučaja, dobavljačeva replikacija (kopiranje podataka na više mesta) savršeno vredno kopira i tu grešku, na oba mesta gde se čuva. Zato ozbiljni dobavljači u svojoj dokumentaciji izričito kažu da je bekap – u smislu mogućnosti povratka na tačku pre greške – odgovornost kupca, ne njihova. To retko ko pročita pre potpisa.

Zavisnosti koje se ne vide dok ne otkažu

U prošlom tekstu smo videli kako je pad domenskog kontrolera (servera koji proverava korisničke prijave) zaustavio i telefoniju i cloud CRM istovremeno. To nije izuzetak – kod hibridne infrastrukture, najopasnije tačke otkaza nisu pojedinačni sistemi, nego spojevi između njih.

Prijava korisnika. Domenski kontroler u Beogradu sinhronizuje naloge sa cloud identitetom koji koriste i CRM i imejl. Kroz tu jednu tanku vezu prolazi pristup skoro svemu.

Mrežna veza između lokacije i cloud-a. VoxServis ima jednu vezu koja povezuje serversku sobu u Beogradu sa cloud okruženjem. I server i cloud servis mogu pojedinačno raditi savršeno – ako ta jedna veza otkaže, agent u Novom Sadu ne može da dođe ni do jednog.

DNS na oba kraja. DNS (sistem koji imena servera i sajtova prevodi u tehničke adrese) postoji i lokalno, za interne resurse, i na cloud strani, za javno dostupne adrese. Promena na jednoj strani koja zaboravi da ažurira drugu izaziva probleme koje je teško dijagnostikovati – simptomi liče na "aplikacija je spora", ne na "ovo je DNS problem".

Veza između telefonije i CRM-a. Kad telefon zazvoni, sistem preko API-ja (kanala kojim dva softvera automatski razmenjuju podatke) odmah prikaže agentu podatke o klijentu. I telefonija i CRM mogu raditi savršeno, a sama ta veza između njih može da otkaže – zbog isteka pristupnog ključa, na primer. Agent tada radi, samo sporije i bez konteksta.

Zašto ovo menja kako se mapiraju zavisnosti

Uobičajeno mapiranje ide po lokaciji: šta imamo u serverskoj sobi, šta imamo u cloud-u, dva odvojena spiska. Za hibridnu infrastrukturu to je pogrešan ugao. Mapiranje mora da prati poslovnu aktivnost, pa unazad kroz sve što ta aktivnost dodiruje, bez obzira gde fizički sedi.

Za VoxServis-ovu aktivnost "prijem poziva podrške", lanac izgleda ovako: telefonska linija → PBX (na svom serveru) → prijava agenta (domenski kontroler plus cloud sinhronizacija) → CRM za podatke o klijentu (cloud) → veza između PBX-a i CRM-a → mrežna veza ka cloud-u. Šest karika, tri različita vlasnika – interni IT, cloud dobavljač, telekom operater – za jednu jedinu aktivnost.

Deljena odgovornost znači i deljeno testiranje

Zato se ne može testirati on-premise deo i cloud deo odvojeno i zaključiti da je sve u redu. VoxServis može savršeno da testira restore domenskog kontrolera, i može savršeno da veruje izveštajima cloud dobavljača o njihovoj dostupnosti – a i dalje nema pojma da li ceo lanac, od zvona telefona do prikaza podataka o klijentu, radi kad jedna karika u sredini otkaže.

Ono što je realno tražiti od dobavljača nije "garantujte da nikad nećete pasti" – to niko neće potpisati. Realno je tražiti jasan SLA (ugovoren nivo usluge) sa merljivim brojem i posledicama ako se ne ispuni, informaciju o njihovoj sopstvenoj strategiji oporavka, i jasnoću oko toga šta tačno oni bekapuju za vas, a šta ostaje na vama.

Degradacija umesto potpunog pada

Cilj ne mora da bude "sve radi ili ništa ne radi". Ako cloud CRM padne, da li agenti mogu da nastave da primaju pozive uz ručnu proveru osnovnih podataka o klijentu, sporije ali funkcionalno, dok se CRM ne vrati? Ovakva rešenja su često jeftinija i realističnija od pokušaja da se svaka komponenta učini savršeno neuništivom.

Najčešća greška

Pretpostavka da visoka dostupnost dobavljačeve platforme znači da je vaš kontinuitet rešen. To dvoje se preklapa samo delimično. Dostupnost platforme štiti od toga da dobavljač padne. Ne štiti od vaše greške, tuđe zlonamernosti u vašem nalogu, ili prekinute veze na granici dva sveta.

Šta sledi

Poslednji uvodni tekst pre nego što krenemo kroz standard klauzula po klauzula: realan trošak i pristup uvođenju IRBC-a kod firme veličine VoxServis-a.