Cloud computing, odnosno cloud usluge su nešto najbolje što Internet danas nudi. Razmislite koliko vi usluga u oblacima koristite.
Koristite vjerojatno Dropbox/Google Drive/OneDrive za pohranu određenih podataka – bilo osobih bilo poslovnih, koristite možda Office365, Github/BitBucket/GitLab za pohranu podataka, Microsoftov Azure za mnogo toga (od hostanja web stranica do raznih drugih usluga), kao i Amazonov AWS i tako dalje.
I sve je super dok sve radi, a većina tih servisa ima uptime 99.9 posto, odnosno gotovo su uvijek dostupni. No, što se dogodi kada ti servisi stanu? Onda nastane kaos – doslovno. Pola Internet usluga stane ili su djelomično funkcionalne, korisnici su frustrirani, posao stoji i slično.
Nedavno se dogodilo nekoliko takvih incidenata što nas je ponukalo da napišemo ovaj tekst i zapitamo se da li stvarno previše oslanjamo na cloud usluge, a premalo na lokalne? Ili možda ipak možemo tolerirati tih 0.01 posto ispada. Sudeći po reakcijama na Internetu, takve usluge bi morale imati 100-postotni uptime, no pitanje je da li je to uopće moguće.
GitLab
Jedan od prvih problema ove godine je imao GitLab – servis za pohranu koda kojeg često koriste programeri i softverske kompanije. GitLab je relativno dobar servis koji, kao i njegovi konkurenti GitHub i BitBucket, nudi uslugu pohrane koda, te neke popratne usluge iako ga se može koristiti i za pohranu drugih dokumenata.
Kroz taj isti sustav možete organizirati kolaboraciju, vidjeti povijest izmjena na svakom dokumentu, tko ga je napravio, kada ga je napravio i slično.
Napomenimo samo da je u GitLab investirano puno novaca, te da su u njega uložili Y Combinator i Khosla Ventures.
Što se dogodilo? Jednu večer je jedan njihov pripravnik trebao obrisati bazu i zabunom je obrisao produkcijsku bazu. Pošto se radilo kroz terminal i ostale alate, dotični pripravnik nije vidio da se nalazi na produkcijskom serveru i slučajno je obrisao krivu bazu.
Onu u kojoj se nalazio sav produkcijski kod, sve izmjene, korisnički računi i slično. Doslovno je te sekunde “pao” cijeli GitLab jer se više nitko nije mogao spojiti, commitati kod ili povuči izmjene ili povuči projekte koji su se tamo nalazili. Dovoljno je reći da više niste mogli otvoriti IT portale, a da na naslovnicama nije bio spomenut GitLab.
Dok su korisnici bili frustrirani, investitori su bili bijesni i pokušali na sve načine sanirati štetu koja je nastala jer se ipak radi o njihovim novcima i reputaciji GitLaba.
Ono što nas je začudilo je otvorena komunikacija GitLaba prema korisnicima. U realnom vremenu su objavljivali podatke o tome što se događa na Twitteru i nisu lagali korisnicima. Rekli su što se dogodilo i što planiraju poduzeti.
No, nažalost tu nije kraj ovoj priči. Drugi veliki problem koji se dogodio je što backup koji je bio star svega 6 sati nisu uspjeli vratiti. Čak i nije problem u tome što je servis bio nedostupan neko vrijeme, nego što je bio nedostupan jer se nije mogao restore-ati backup.
Dobra stvar je što su programeri na svojim računalima i svojim repozitorijima imali sve izmjene pa su ih mogli i vratiti, samo se čekalo da GitLab bude dostupan. Na kraju je uspješno vraćen backup, GitLab je postao dostupan i svijet se vratio u ravnotežu.
Kolika je financijska ili neka druga šteta, ne znamo jer podataka nema, no GitLab je obilježen kao “loš” servis zbog ovog incidenta. Poznato je jedino da pripravnik koji je napravio ovu štetu je i dalje zaposlenik GitLaba. Barem je bio tako rečeno. Greške se događaju i događati će se, no ipak je jako nezgodno kada se ovako nešto dogodi.
Enterprise korisnici nisu bili pogođeni ovim ispadom jer oni imaju svoje GitLab repozitorije lokalno spremljene na svojim serverima tako da su oni nesmetano radili. Pogođeni su bili oni koji nemaju enterprise “On demand” uslugu, a takvih je 99 posto GitLab korisnika.
Nažalost, mnoge firme su stale sa razvojem tih dan ili dva, što je u neku ruku određeni financijski gubitak. Kako ćete svojim klijentima objasniti da im ne možete isporučiti novu verziju softvera jer je GitLab nedostupan? Teško.
Amazon AWS
Drugi i nama mnogo zanimljiviji ispad se dogodio krajem veljače ove godine, kada je “pao” Amazon AWS. No, prije nego se pozabavimo samim padom, par rečenica o samom servisu. Amazon je krajem 2015.-te godine uveo hrpu novina u svoj cloud servis na koji ste mogli postaviti hrpu sadržaja – od samih datoteka do web stranica.
Amazon to još naziva i S3 usluga (Simple Storage Service). Mnogim malim firmama i startupima je to mnogo jefitnije jego ulagati u vlastitu infrastrukturu jer ona može koštati na stotine tisuća ili milijuna kuna.
Naravno da to mnogim kompanijama ne dolazi u obzir jer nemaju nikakvog kapitala niti postoji više potreba da sve imamo lokalno kod sebe kada postoje jeftini servisi koji će to učiniti za nas. Praktički sve radimo on-demand. Što nam treba, to zakupimo i plaćamo po korištenju. Kad nam ne treba – ne plaćamo niti koristimo.
I tu dolazimo do toga da su mnoge web stranice koristile ovaj web servis, odnosno Amazonove usluge. Bio je to sasvim običan dan, osim što kada ste upalili svoje omiljene web stranice ili mobilne aplikacije, nešto nije bilo u redu.
U početku je sve radilo jako usporeno, a zatim je sve stalo. Amazon je u jednom trenutku imao jako puno errora koji su se gomilali dok server(i) nisu stali. Samo nabrojimo neke od pogođenih stranica – Engadget, Giphy, Quora, Medium, Slack …
Zanimljivo je kako je pogođeno samo jedno područje, odnosno nekoliko servera, a stale su gotovo sve popularne web stranice i servisi. Očito su svi oni koristili iste servere u Americi. Ostatak Amazonovih servera je i dalje radio, mogli ste kupovati preko Amazona i slično.
Slična stvar se dogodila i u Australiji 2016.-te godine, no onda je sve stalo jer su sve stranice i servisi koji su tamo bili “stacionirani” pali.
Zato Amazon i preporuča korištenje opcije deployanja podataka u dvije dostupne zone – one su geografski udaljene, na različitim serverima i ako jedan padne, drugi se aktivira. Krajnji korisnik ne osjeti nikakvu razliku. Nažalost, dotični servisi nisu koristili tu opciju.
Ono što je također zanimljivo je da Amazon tvrdi da je njihova dostupnost 99.99999999999 posto. Da, dobro ste pročitali – 11 devetki. Što će reći da su potrošili svu zalihu nedostupnosti za ovu godinu. Barem za dio korisnika.
Sigurno se pitate što se točno dogodilo? U ovom slučaju opet ljudska greška. Jedan zaposlenik je imao skup naredbi koje je morao ispucati na serveru, no nije sve dobro kopirao ili upisao i nije se posao izvršio do kraja.
Zatim su se počeli nizati errori jedan za drugim dok server nije stao, odnosno dok ga nisu popravili i vratili nazad u produkciju. Riješili su problem, potpuno resetirali server i sve njegove procese i sve je opet profunkcioniralo.
Problem se čini kao banalan, no nedostupnost servisa, posebice billing sustava koji se nalazi na tom serveru, je mogao prouzročiti određenu financijsku štetu. Možda nekome i jest.
S druge strane, Amazon se ispričao, te su potvrdili da su uveli dodatni mehanizam koji će provjeravati da li je sve dobro napravljeno i da se ovakve situacije neće ponoviti.
Treba li i dalje vjerovati cloud servisima?
Posebice je važno pitanje, treba li Amazonu i dalje vjerovati? Odgovor je da. Ne postoji web servis koji je 100 posto dostupan i koji radi savršeno. To dobro znaju oni koji se bave razvojem softvera i koji se sa sličnim problemima suočavaju svaki dan, iako u manjem obimu.
Spomenimo samo da su slične ispade imali i Microsoft sa Azureom, Google sa svojim web servisima i cloud uslugama, Facebook ima problema … sve velike kompanije, bez obzira na uslugu, imaju ponekad tehničkih problema. Važno je da ga se na vrijeme otkloni, da se takav isti scenarij više nikada ne ponovi i da se nešto nauči iz toga.
Korisnici u tom trenutku neće biti sretni, pogotovo ako im posao ovisi o tome, no to je rizik s kojim se moraju pomiriti kada koriste određeni servis. Povijest nas je naučila da ispadi ovog tehničkog tipa nikada ne traju predugo, odnosno da se relativno brzo otklanja kvar.
Čak i u nekim “ekstremno” dugim situacijama to ne traje duže od 24 sata, mada većina servisa dođe nazad unutar 8 sati. Stoga, slobodno i dalje koristite blagodati koje nam daje Internet ali se nemojte oslanjati na njih da će uvijek biti dostupne.
Barem imajte određene podatke lokalno spremljene za backup ili slične hitne situacije. Barem one kritične podatke bez kojih ne možete.
Autor: B.P.
