Podcast o Kľúčové koncepty IT manažmentu a architektúry

Kapitoly

Úvod

Popis IT služby

Kľúčové parametre

Podpora a incidenty

SLA, SLO a SLI

SLA a prečo nie vždy 99,9 %

Plán kontinuity: RTO a RPO

Záložné lokality od najdrahšej po najlacnejšiu

CapEx verzus OpEx

Cloudové modely IaaS, PaaS, SaaS

Moderné prístupy a kompromisy

Monolit vs. Mikroslužby

Ako systémy komunikujú (API)

Prečo je UX dôležité

Trojvrstvová architektúra

Škálovanie a virtualizácia

Kontajnery a efektivita

Podniková architektúra a zhrnutie

Přepis

Sofia: Viete, čo je tá jedna vec, ktorá pri IT službách zamotá hlavu osemdesiatim percentám študentov na skúške? Je to rozdiel medzi SLA, SLO a SLI. A my vám ukážeme, ako sa postarať o to, aby ste to vy už nikdy nepomýlili.

Michal: Presne tak. Je to jednoduchšie, ako sa zdá, keď viete, na čo sa pozrieť. A ten pocit, keď to konečne docvakne, je na nezaplatenie.

Sofia: Počúvate Studyfi Podcast. Poďme teda rovno na to. Michal, čo si máme predstaviť pod pojmom „IT služba“? Znie to dosť abstraktne.

Michal: Super otázka. Predstav si to ako podrobný manuál alebo... recept na službu. V IT svete na to používame šablónu podľa ITIL. Táto šablóna má dve hlavné časti: biznisovú a technickú.

Sofia: Okej, biznisová je to, čo vidí zákazník, a technická, ako to celé funguje v zákulisí?

Michal: Bingo! Biznisový pohľad hovorí, čo ti garantujeme. Napríklad, že služba bude dostupná na 99,5 percenta. Technický pohľad zase popisuje, ako to dosiahneme — aký máme hardvér, softvér a podobne.

Sofia: Takže v podstate sľub a plán, ako ten sľub dodržať. Čo všetko v takomto „recepte“ nájdeme?

Michal: Jedna z najdôležitejších častí je dostupnosť a prevádzkové hodiny. Služba môže bežať 24/7, teda nepretržite, alebo len v pracovné dni, čo označujeme ako 8x5.

Sofia: A čo tie plánované výpadky? Napríklad keď sa v noci aktualizuje banková aplikácia. To sa potom neráta do tej nedostupnosti, však?

Michal: Väčšinou nie. Plánované okná na údržbu, napríklad každú nedeľu o druhej ráno, sú vopred dohodnuté a zvyčajne sa do metriky dostupnosti nezapočítavajú. Okrem toho tam riešime výkonnosť – ako rýchlo systém reaguje – a kapacitu, teda koľko používateľov naraz zvládne.

Sofia: Chápem. A čo keď sa niečo pokazí? Kto to rieši?

Michal: Na to slúži podpora, ktorá je rozdelená na úrovne. L1, alebo Level 1, je takzvaný service desk. To sú ľudia, ktorí riešia jednoduché problémy, často len navigujú používateľov. Také to klasické „skúsili ste to vypnúť a zapnúť?“

Sofia: To poznáme všetci. A čo ak to nezaberie?

Michal: Potom to ide na L2, kde sú technici s hlbšími znalosťami. A ak je problém priamo v kóde alebo v dodanom riešení, rieši to L3, čo je najvyššia úroveň, často priamo u dodávateľa softvéru. Každá úroveň má presne stanovené reakčné doby.

Sofia: Jasné. Takže je presne dané, kto, čo a dokedy má vyriešiť. A tým sa dostávame k tým trom magickým písmenkám z úvodu, však?

Michal: Presne tak. Poďme si to rozbiť na drobné. Predstav si, že si objednávaš pizzu. SLA, alebo Service Level Agreement, je tvoja kompletná zmluva s pizzeriou.

Sofia: Takže tam bude napísané, že pizza bude teplá, nepoškodená a doručená do 30 minút? A ak nie, dostanem zľavu?

Michal: Perfektné prirovnanie! Presne tak. SLA je formálna dohoda, ktorá obsahuje všetky parametre, spôsob merania a sankcie pri neplnení. SLO, Service Level Objective, je konkrétny cieľ v tej zmluve. Teda tých „30 minút“.

Sofia: A to posledné... SLI?

Michal: SLI, Service Level Indicator, je reálna metrika, ktorou to meriame. V našom príklade by to bol čas od objednávky po doručenie, ktorý stopky reálne namerali. SLI teda meria, či sme splnili SLO, ktoré je garantované v SLA.

Sofia: Aha! Takže SLA je celá zmluva, SLO je sľub v tej zmluve a SLI je dôkaz, či bol sľub dodržaný. To je vlastne úplne logické! Pizza mi to vysvetlila lepšie ako hocijaká poučka.

Michal: Vidíš? A presne takto jednoducho sa pozrieme aj na cloudové modely.

Sofia: Takže teraz už chápem, ako tie služby fungujú, ale čo zaručí, že budú naozaj... no, dostupné? Počula som o tých „deviatkach“.

Michal: Áno, hovoríš o dostupnosti. Všetko sa točí okolo troch skratiek. Máme SLA, teda dohodu o úrovni služieb. V nej je definovaný cieľ, čiže SLO. A ten meriame pomocou SLI, indikátora.

Sofia: Počkaj, takže SLA je zmluva, SLO je cieľ v tej zmluve, a SLI je len meradlo, či ten cieľ plníme?

Michal: Presne tak! A tie deviatky, napríklad 99,9 % dostupnosť, znamenajú cieľ. Ale pozor, nie vždy je to ekonomicky zmysluplné.

Sofia: Ako to? Veď chcem, aby všetko fungovalo stále!

Michal: Každé percento navyše stojí obrovské peniaze. Viac ľudí na pohotovosti, záložné servery, druhá lokalita... Predstav si agendový systém na ministerstve. Ľudia tam pracujú od siedmej ráno do piatej poobede. Naozaj potrebujeme, aby bežal o tretej v noci v nedeľu?

Sofia: Asi nie. To dáva zmysel.

Michal: Presne. A keď už hovoríme o výpadkoch, existuje aj plán B. Volá sa to Business Continuity Management, alebo BCM. Je to stratégia, čo robiť, keď udrie katastrofa – požiar, povodeň, čokoľvek.

Sofia: Dobre, takže to je plán pre naozaj zlé scenáre. Čo je v ňom dôležité?

Michal: Dva kľúčové parametre: RTO a RPO. RTO, čiže Recovery Time Objective, je maximálny čas, za ktorý musíme systém obnoviť. Napríklad RTO štyri hodiny znamená, že do štyroch hodín to musí zase bežať.

Sofia: Okej, a to druhé?

Michal: RPO, Recovery Point Objective, je o dátach. Hovorí, akú maximálnu stratu dát si môžeme dovoliť. Ak je RPO 15 minút, znamená to, že po obnove prídeme maximálne o 15 minút práce. Záloha nesmie byť staršia.

Sofia: Chápem. Takže ak by som mala RPO 24 hodín na svoju esej, mohla by som prísť o prácu za celý deň. To by bolelo.

Michal: Presne tak! Preto je to kľúčové správne nastaviť.

Sofia: A ako sa firmy chránia pred takou totálnou katastrofou, napríklad zničením serverovne?

Michal: Existujú záložné lokality. Tá najdrahšia sa volá „hot site“. Je to v podstate zrkadlo hlavnej lokality, beží neustále a prepnutie trvá minúty. Potom je „warm site“, kde je hardvér pripravený, ale obnova trvá pár hodín.

Sofia: A najlacnejšia možnosť?

Michal: Tá sa volá „cold site“. Je to v podstate prázdna miestnosť s elektrinou a internetom. Všetko tam treba doniesť a nainštalovať, čo trvá dni. Je to lacné, ale RTO je obrovské.

Sofia: Takže sme si povedali, ako zaistiť, aby systémy bežali a ako ich obnoviť po katastrofe. To je super. Ale z čoho sa vlastne taký IT systém skladá?

Sofia: Takže, keď už máme zvládnuté zálohovanie a kontinuitu, poďme sa pozrieť na to, na čom to celé vlastne beží... na samotný hardvér a infraštruktúru. To znie draho a zložito.

Michal: Presne tak. A to nás privádza k prvej kľúčovej otázke, ktorú rieši každá firma... kde tú infraštruktúru vlastne zobrať? Postaviť si vlastnú, alebo si ju od niekoho prenajať?

Sofia: Hovoríme o voľbe medzi vlastnými servermi, takzvaným on-premises riešením, a cloudom, však?

Michal: Áno, presne. A s tým súvisí aj finančný model. Sú tu dva základné prístupy: CapEx a OpEx. Znie to ako z nejakej nudnej účtovnej príručky, ale je to mega dôležité.

Sofia: Dobre, tak nám to prelož do ľudskej reči.

Michal: Jasné. Think of it this way... CapEx, alebo kapitálové výdavky, je ako keď si kúpiš auto. Zaplatíš naraz veľkú sumu, auto je tvoje, je to tvoj majetok a postupne stráca na hodnote, odpisuje sa.

Sofia: To dáva zmysel. A OpEx?

Michal: OpEx, čiže operačné výdavky, je ako keby si používala taxi službu alebo si auto dlhodobo prenajala. Nemáš žiadny majetok, len platíš mesačný poplatok za používanie. To sú typicky cloudové služby.

Sofia: Takže jednorazová investícia verzus mesačné poplatky. Chápem. Každý model má asi svoje výhody, však?

Michal: Presne. S CapExom máš lepšiu kontrolu, ale viažeš si peniaze. S OpExom si flexibilnejšia a môžeš rýchlo škálovať, ale si závislá od poskytovateľa.

Sofia: Dobre, poďme sa teda pozrieť bližšie na ten cloud. Počula som tie skratky... IaaS, PaaS, SaaS. Priznám sa, vždy sa mi to pletie.

Michal: Je na to skvelá pomôcka... predstav si, že si chceš dať pizzu.

Sofia: Pizzu? Dobre, teraz ma máš!

Michal: Takže... IaaS, Infrastructure as a Service, je ako keby ti niekto dal kuchyňu s pecou. Všetko ostatné – cesto, omáčku, suroviny – si musíš zohnať a urobiť sama. My ti dáme len ten základ, ten hardvér.

Sofia: Okej, takže dostanem virtuálny server a zvyšok si nainštalujem sama. Príkladom je Amazon EC2 alebo Azure Virtual Machines, správne?

Michal: Perfektné. Ideme ďalej... PaaS, Platform as a Service. Tu ti už dajú nielen kuchyňu, ale aj pripravené cesto a základné suroviny. Ty si pizzu už len dozdobíš a upečieš. Poskytovateľ ti dá platformu, napríklad databázu alebo Kubernetes, a ty na tom staviaš svoju aplikáciu.

Sofia: Super, to je už menej práce. A posledný?

Michal: A nakoniec SaaS, Software as a Service. To je jednoduché – objednáš si hotovú, upečenú pizzu priamo domov. Ty ju len zješ. Je to hotový softvér ako služba, napríklad Microsoft 365 alebo Gmail.

Sofia: Táto pizza analógia je geniálna! Takže kľúčový takeaway je, že čím ideme od IaaS k SaaS, tým menej sa o to musíme starať, ale máme aj menšiu kontrolu.

Michal: Presne tak. A mimochodom, keď hovoríme o poskytovateľoch, tí najväčší hráči na trhu sú Amazon Web Services, Microsoft Azure a Google Cloud. A štvrtým, hlavne v Ázii, je Alibaba Cloud, nie Oracle, ako sa niekedy mylne uvádza.

Sofia: Dobre, to je super prehľad. A čo sa zmenilo v posledných rokoch? Ako sa dnes k infraštruktúre pristupuje moderne?

Michal: Veľká vec je takzvaná Infrastructure as Code, alebo IaC. To je úplná revolúcia. Predstav si, že celú sieť a všetky servery nenastavuješ ručne klikaním, ale napíšeš na to kód. Skript.

Sofia: Wow. Takže infraštruktúra sa stáva programovateľnou? To znie ako super-schopnosť pre adminov.

Michal: V podstate áno! Umožňuje to brutálnu automatizáciu a opakovateľnosť. Žiadne ľudské chyby. Vytvoríš si infraštruktúru za pár minút a keď ju nepotrebuješ, jedným príkazom ju zrušíš.

Sofia: To priamo súvisí s tým, o čom sme sa bavili... on-premises versus cloud. Zdá sa, že cloud vyhráva na plnej čiare v agilite.

Michal: Rozhodne. Ale je tu jeden zásadný kompromis. Kontrola verzus agilita. On-premises ti dáva maximálnu kontrolu nad hardvérom, bezpečnosťou, všetkým. Ale je to pomalé a neflexibilné.

Sofia: Zatiaľ čo cloud ti dáva obrovskú rýchlosť a flexibilitu, teda agilitu, ale vzdávaš sa časti kontroly. Musíš dôverovať poskytovateľovi.

Michal: Bingo. A práve preto existujú hybridné modely, kde si firmy nechávajú najcitlivejšie dáta u seba a zvyšok prevádzkujú v cloude. Alebo dokonca multi-cloud, kde využívajú služby viacerých poskytovateľov naraz, aby neboli závislí len od jedného.

Sofia: Super, takže infraštruktúru a cloud máme, myslím, celkom pekne pokrytú. To nás ale prirodzene privádza k ďalšej otázke... a to je softvér samotný. Ako sa rozhodnúť, či si ho kúpiť, alebo si ho nechať vyvinúť na mieru?

Sofia: ...a takto sa firmy rozhodujú, aký softvér použiť. Ale často počujem slovo "architektúra". Znie to, akoby sme stavali budovu, nie písali kód.

Michal: To je vlastne skvelá analógia, Sofia. Presne o tom to je. O tom, ako sú tie digitálne "tehličky" poskladané.

Sofia: Tehličky? Takže existujú rôzne spôsoby, ako ich skladať?

Michal: Presne tak. Predstav si dva prístupy. Prvý je monolit. To je ako keby si postavila jeden obrovský dom, kde je všetko pod jednou strechou. Všetky funkcie sú v jednom veľkom balíku.

Sofia: Chápem. A ten druhý prístup?

Michal: Ten sa volá mikroslužby. Namiesto jedného domu si predstav malú dedinu. Každý domček je samostatná služba—jedna rieši platby, druhá prihlasovanie, tretia posielanie emailov...

Sofia: Znie to organizovanejšie. Má to nejaké výhody?

Michal: Obrovské. Keď potrebuješ opraviť strechu na jednom domčeku, nemusíš zatvoriť celú dedinu. Jednoducho opravíš len tú jednu časť. Je to oveľa flexibilnejšie.

Sofia: Dobre, ale ako tie domčeky... teda služby... spolu komunikujú? Posielajú si listy?

Michal: Skoro. Používajú niečo, čo sa volá API—Aplikačné programové rozhranie. Je to vlastne taký digitálny čašník.

Sofia: Čašník? Rozveď to.

Michal: Predstav si, že sedíš v reštaurácii. Nepôjdeš priamo do kuchyne kričať na kuchára, čo chceš. Povieš to čašníkovi. On zoberie tvoju objednávku—to je vstup—a prinesie ti jedlo, teda výstup. API je ten čašník medzi dvoma systémami.

Sofia: Takže API definuje, ako si majú systémy "objednávať" informácie jeden od druhého. To je super prirovnanie!

Michal: Presne tak. A celé to riadia DevOps tímy. To nie sú oddelené skupiny programátorov a správcov, ale jeden zmiešaný tím, ktorý spolupracuje, aby všetko fungovalo hladko.

Sofia: Super. Ale na konci dňa je dôležité, ako to celé vníma používateľ, však?

Michal: Absolútne. A tu prichádza na rad UX, alebo User Experience—používateľský zážitok. To je celkový pocit, ktorý máš pri používaní produktu.

Sofia: Čiže nielen to, ako vyzerá appka?

Michal: Nie, je to všetko. Od prvého emailu, cez jednoduchosť používania, až po riešenie reklamácie. Kľúčové pravidlo je toto: dobrý UX znamená, že nepotrebuješ návod. Všetko je intuitívne.

Sofia: A zlý UX je, keď musím googliť, ako sa niečo robí.

Michal: Presne tak! To je znak, že niečo nefunguje. A práve zlepšovanie týchto procesov je základom digitálnej transformácie, o ktorej si ešte povieme.

Sofia: Super. Takže sme prebrali štruktúru softvéru. Ale čo ho vlastne poháňa? Ako fungujú siete, ktoré to všetko spájajú? Poďme sa na to pozrieť.

Sofia: Takže sme prebrali siete a teraz sa poďme pozrieť, ako to celé funguje dokopy. Michal, čo je taká tá klasická architektúra informačného systému?

Michal: Super otázka! Najčastejšie sa stretneš s takzvanou trojvrstvovou architektúrou. Je to ako sendvič.

Sofia: Sendvič? Dobre, to znie chutne a jednoducho. Aké sú tie vrstvy?

Michal: Prvá vrstva je klient. To je to, čo používaš – webový prehliadač, mobilná appka, alebo aj skener v obchode. Komunikuje s aplikačným serverom, ktorý spracováva všetku logiku.

Sofia: Jasné. A tá posledná vrstva je asi databáza, však?

Michal: Presne tak. Databázový server, kde sú uložené všetky dôležité dáta. Takže klient, aplikácia, dáta. Tri jednoduché vrstvy.

Sofia: Chápem. A čo keď na tú aplikáciu zrazu príde strašne veľa ľudí? Ako sa to rieši?

Michal: Tomu sa hovorí škálovateľnosť. Máš dve hlavné možnosti. Buď vertikálne škálovanie – to je ako dať tvojmu jednému serveru steroidy, proste mu pridáš viac RAM a CPU.

Sofia: A tá druhá možnosť?

Michal: Horizontálne škálovanie. Namiesto jedného supersilného servera pridáš viacero menších, identických. A práve tu prichádza na scénu virtualizácia.

Sofia: To je to kúzlo, kde z jedného fyzického servera urobíš viacero virtuálnych, že?

Michal: Presne! Z hmotného urobíš nehmotné. Vďaka tomu môžeme vytvárať nové servery za pár minút a efektívne využívať hardvér.

Sofia: A existuje ešte niečo nad virtualizáciou? Nejaká ďalšia úroveň abstrakcie?

Michal: Áno, kontajnerizácia. Predstav si virtuálny stroj ako byt. Kontajner je potom jedna izba v tom byte, ktorá má všetko potrebné pre jednu konkrétnu aplikáciu. Je to ešte rýchlejšie a efektívnejšie.

Sofia: Takže na jednom fyzickom hardvéri môže bežať viacero virtuálnych strojov, a na každom z nich ešte niekoľko kontajnerov? To je ako ruská matrioška.

Michal: Perfektné prirovnanie! A vďaka tomu dokážeme z jedného hardvéru dostať oveľa viac výkonu, než by si čakala.

Sofia: Posledná otázka. Ako v tom veľké firmy udržiavajú poriadok? Musí v tom byť chaos.

Michal: Na to slúži podniková architektúra. Je to súbor pravidiel a dokumentov, ktoré definujú poriadok vo všetkom hardvéri a softvéri firmy. Rozdeľuje sa na biznisovú, aplikačnú, dátovú a technologickú vrstvu.

Sofia: Super. Takže na záver, kľúčové sú tri vrstvy architektúry, škálovateľnosť cez virtualizáciu a kontajnery, a podniková architektúra ako strecha, ktorá to všetko drží pokope. Michal, ďakujem ti veľmi pekne za všetky cenné rady!

Michal: Rado sa stalo. Držím palce všetkým pri štúdiu!

Sofia: Aj ja sa pripájam. Toto bol Studyfi Podcast, počujeme sa nabudúce. Ahojte!