ako merať (a nemať) výpadky

devops a cloud
13. januára 2016
ako nás zmenili hackeri (1)
30. januára 2016
Zobraziť všetko

ako merať (a nemať) výpadky


ako súvisí meranie výpadkov s ich nemaním? čo nemeriaš, nezlepšíš, vravia exceloví manažéri, ale majú svätú pravdu. ja som výpadkov zažil požehnane a pátral som na rôznych miestach ako ich merať, pýtal som sa rôznych slovenských CIOs, ale nič ma neuspokojilo. tak som vyhútal vlastnú metodiku, ktorú tu ponúkam. toto nie je definitívny návod, ako systematicky riešiť IT incidenty, na to máme napríklad ITIL. ale aj v oblasti riešení skúsim načrtnúť niektoré netradičné postupy inšpirované, napríklad, poznatkami z jadrových elektrární.

najviac skúseností s odozvou na incidenty som získal vo websupporte. najprv som tam  robil niečo úplne iné, radil som do riadenia, marketingu a obchodu. firma zažívala vtedy fenomenálny nárast a potýkala sa s radom problémov súvisiacich s rýchlym škálovaním. posunul som sa na funkciu CTO s cieľom pomôcť ich vyriešiť. michal truban, CEO, tam vtedy zavádzal inovatívne manažérske metódy a vymýšľal KPIs na meranie progresu vo všetkých oblastiach. ja som dostal úlohu vymyslieť čosi na IT.

čo je to výpadok? keď nič nejde? čo, keď nejaká časť služby ide? alebo, keď ide všetko, len pomaly? pátranie som začal klasickou ITIL definíciou, ktorá vraví, že je to hocijaký incident, ktorý spôsobí prerušenie, alebo degradáciu služby. čo je to presne degradácia neurčuje ITčkár, ale biznis užívateľ – v tom má ITIL jasno, i keď v praxi si na slovensku interné IT oddelenia typicky žijú svojím vlastným životom a predstava, že by im oddelenie personalistiky, alebo marketingu, určovalo, čo je a čo nie je výpadok, im určite príde scestná. ale je to tak. ak poskytujete IT služby externým zákazníkom a ste na pochybách, spýtajte sa ich a basta. spravte prieskum. jednoduché, ale kto to robí?

k metrike: ja meriam výpadky pomerom vypadnutej časti služby voči celkovej kapacite služby. som vyštudovaný ekonóm a inšpirácia pochádza z controllingu, konkrétne z activity based costingu, používaného na rozúčtovanie overheadových nákladov alokačným kľúčom konkrétnej službe.

príklad: prevádzkujem e-mailové servery s napríklad 100 tisíc mailboxami (websupport ich má viac). január má 31 dní a 44640 minút. môj celkový objem služieb je:

100 tisíc mailboxov krát 44640 minút = 4464000000 user-minút

a teraz – mám incident, pri ktorom nejde 45 minút 20 tisíc mailboxov. alebo ide, ale tak spomalene, že je to pod úrovňou, ktorá podľa prieskumu zákazníkov je pod akceptovateľnou úrovňou kvality služby (alebo pod SLA úrovňou pri formálnych zmluvých vzťahoch).

môj výpadok má teda rozmer: 

45 krát 20000 mailboxov = 900000 user-minút

a dostupnosť daný mesiac je:

100 - ((4464000000 - 900000) / 4464000000) = 99,98%

tento postup prináša objektívne vyjadrenie veľkosti rozsahu a dĺžky výpadku voči celkovej veľkosti platformy. v prípade rastu počtu užívateľov zohľadňuje dopad na celkový biznis. ak mi vypadlo sto užívateľov pred piatimi rokmi, keď som mal celkovo dvesto užívateľov, bol to väčší prúser, ako keď mi teraz vypadne sto užívateľov z tisíc.

dalo by sa ísť podrobnejšie a zamiešať do toho veľkosť jednotlivých zákazníkov, veľkost mailboxov a podobne. keď mi vypadne zákazník, čo platí málo, je to iné, ako keď vypadne VIP zákazník. prázdny mailbox versus obrovský mailbox a podobne. ale je to ako s activity based costingom – vyššia precíznosť zvyšuje presnosť, ale aj komplexitu meraní a výpočtov.

to je celé, máte metriku, netvrdil som, že je zložitá. treba ju mať konzistentnú dlhé obdobie, aby ste sa mohli porovnávať so svojou minulosťou. sú totiž len dva spôsoby, ako objektívne zistíte, či niečo robíte dobre. môžete sa porovnávať so svojou minulosťou, alebo s konkurenciou. keďže v tomto meraní nie je priemyselný štandard, ostáva vám len to prvé.

metrika musí byť konzistentná krížom cez rôzne IT oddelenia a rôzne pobočky firmy, aby ste ich mohli porovnávať. diferenciácia je základný manažérsky princíp. tých, čo to robia super, treba vyzdvihovať a odmeňovať a zdravé jadro posúvať k nim. odpadlíkov treba trestať a vyhadzovať, inak laxnosťou stiahnu k sebe zdravé jadro.

výsledné KPI dostupnosti by malo byť vo firme verejne známe. mali by byť na neho naviazané odmeny.

keďže sa výpadky v každej firme definujú a merajú inak, nemá zmysel sa verejne oháňať devinami. 99,9%, 99,95%, štyri deviny, päť devín, nič to neznamená. niekto mi povie, že má štyri deviny a nič to so mnou nespraví. áno? a ako to meriaš? čo je to výpadok? hrušky s jablkami.

sú stránky, čo porovnávajú dostupnosť rôznych verejných cloud service providerov. sú blbosť. cloud harmony vlastní priam gartner a robia to zle. kúpia si u každého cloud providera jednu, alebo zopár služieb, zavesia tam monitoring a potom mudrujú. môže vypadnúť celý cloud provider okrem pár služieb, vrátane tej ich, a nič si nevšimnú. alebo naopak. reálne nikto nevie o skutočnom rozsahu výpadkov, iba samotný provider.

vo webhostingu je u zákazníkov populárna služba pingdom. hodíte si kus kódu na svoju stránku a aj vo free verzii vám meria dostupnosť a rýchlosť webu. servery majú vo švédsku. robil som webhosting a stane sa vám, že niekedy nad ránom, cestou medzi švédskom a zákazníkovou stránkou, si grckne nejaký router a ráno už vám píše nahnevaný premúdrelý zákazník. mobilná appka pingdomu ho totiž upozornila na „výpadok“.

niečo o tých nápravách. treba poriadne zanalyzovať okolnosti výpadku a pozrieť logy v najrôznejších systémoch na úrovni sietí, storage, serverov, aj aplikácií. podstatné môžu byť aj malé výchylky v nápadných časových koreláciách, viditeľných na grafoch. jednoznačne je potrebné dáta grafovať v čase a zoskupovať podľa najrôznejších spoločných kritérií. bežne sa nám stalo, že bol pes zakopaný na nezvyčajných miestach a len dobrá vizualizácia dát to odhalila. pri webhostingu sme napríklad niektoré typy útokov videli len pri agregácii stoviek miliónov access logov a ich sortovaní podľa zdrojovej, alebo cieľovej adresy.

ale naštastie tu máme dobu big data. je nevyhnutné agregovať logy zo všetkých systémov na jednom mieste a robiť nad nimi sofistikovanú analytiku. na zber logov sa stáva populárnou NoSQL databáza elasticsearch s nadstavbou kibana. poznám dve firmy v bratislave, čo takto zbierajú 400 miliónov logov denne, na infraštrukúre cc 8 serverov dokážu držať 2 týždne dát a v reálnom čase ich rôzne prekreslovať. je to úžasný nástroj, s tuctami využití, od security, cez ladenie výkonu, až po rootcause analýzy výpadkov. odozvy sa dajú neskôr automatizovať. na slovensku to implementuje napríklad firma bonet.

často chodím po rozumy o ITčku za svojím otcom, ktorý je pomerne počítačovo negramotný. spravil kariéru v energetike, robil aj veľa na prevádzke, bol prvým certifikovaným operátorom jadrového reaktora v československu. aj ja som robil ako mladé ucho chvíľu pre jadrové elektrárne, v radiačnej dozimetrii. je neskutočné, aké praktické sú tieto skúsenosti vo svete IT. všetky naše problémy už vyriešili ruskí projektanti pred pätdesiatimi rokmi! (niekto by mal na najbližšiu konferu infotrendy zavolať niekoho z bohuníc. doporučená téma: zmenové riadenie.)

ako je riešený incident manažment v jadrovej elektrárni? podobne ako v IT. takže čo je prevratné? robia to poriadne. operátori sú drilovaní prevádzkovými a havarijnými predpismi do tak šialenej miery, že je to pre ITčkára neuchopiteľné. ak predsa niekto, alebo niečo, pochybí, na rad prichádza najprv analýza logov. elektráreň má tisíce ventilov, teplomerov, dozimetrov, prietokomerov a najrôznejších iných meracích prístrojov. centralizovaný zber údajov a sofistikovanú analytiku nad nimi mali poriešenú dávno pred počítačovou érou. stroje podobné telegrafom klepkali tisíce údajov na nekonečný papier a analýzu incidentov malo len v jaslovských bohuniciach na starosti 30-členné analytické oddelenie. potom nastúpila havarijná komisia, vyhodnotila výsledky analytikov, vyvodili dôsledky, spustili zmenové riadenie a v prípade ľudskej chyby strhávali prémie. bravo.

je dôležité výpadky zapisovať a klasifikovať, podľa postihnutej služby, typu chyby (ľudská vs. technická), zariadenia, atď. jedine tak vieme štatisticky presne povedať, ktorý typ chyby spôsobuje akú časť výpadkov a dá sa prioritne venovať tým podstatným.

väčšinu výpadkov spôsobujú ľudské chyby a zmeny. ľudským chybám sa dá predchádzať len drilovaním a zmeny treba dôkladne posudzovať z pohľadu ich potreby a dopadu. netreba sa im však vyhýbať. veľa oddelení prevádzky IT sa kvôli tomu mení na „department of No“. rezistujú zmeny, ale neuvedomujú si, že aj keď väčšina zmien je kvôli výpadkom, aj nerobenie zmien spôsobuje výpadky. ak služba rastie, škálovanie si zmeny vyžaduje nevyhnutne. čo funguje v malom, nefunguje vo veľkom. ak prevádzkujete internetové služby, ale aj vo všeobecnosti, okolité prostredie sa mení. sú nové útoky a podobne. ak sa nebudete meniť, budete mať výpadky.

pri výpadku je dôležité mať jasné pravidlá a role. výpadok je dôležité ihneď komunikovať. počas výpadku, po úvodnej bleskovej analýze toho čo sa deje, musí službukonajúci prevádzkar, ako hneď druhý krok, rýchlo informovať o výpadku, jeho príčine, dopade a predpokladanej dĺžke. aby sa prevádzkar nezdržoval, mali sme v minulej práci unix-ový command-line príkaz s parametrami, kde sa tieto infošky stručne zadali a ono to poslalo správu všetkým technikom, podpore, vedeniu a PR. prihlásiť sa na odber správ o výpadkoch sa mohol hocikto ďalší vo firme. oznam o výpadku má ísť cez PR hneď na sociálne siete a nie až po týždni a celý prikrášlený. na výpadky je dobré mať zriadený vždy bežiaci interný jabber diskusný kanál, pri výpadkoch nie je nič efektívnejšie, ako instant messaging. skúste slack a jeho mobilnú appku.

záverom len prianie, aby ste ich mali čím menej. i keď občas sú fajn. pri najbližšom výpadku facebooku chodťe von pozrieť prírodu. toto som videl včera, opäť som v cloude:

2 Comments

  1. To navrhovane meranie vypadkov je celkom dobre pokial chces vediet o celkovej kvalite sluzby. Horsie je, ked potrebujes merat a reportovat dostuponost per zakaznika. Vtedy by som tento vypocet nepouzil.

    Celkovo este odporucam pred riesenim merania vypadkov (dostupnosti) si vydefinovat hranice sluzby a komunikovat to aj zakaznikom (hlavne tym technickym) – potom meranie „premúdrelého zákazníka“ cez pigndom nebude problem. ITIL odporuca end-to-end meranie ale to plati ak ide o poskytovatela sluzieb na rozhrani k biznisu, nie k dalsiemu IT.

    Tema jasne pravidla a role pri vypadku sa v ITILe vola Major incident management. Problem je ze ani ITIL nehovori co v takom pripade treba robit, len ze treba mat jasne definovanu proceduru a preto to ma kazde IT trochu inak, co ale nie je zle. A na oznamovanie vypadkov sa momentalne skor hodi dobry Servicedesk nastroj, ktory vela notifikacnych a publikacnych veci automatizuje.

    • Miroslav Pikus píše:

      Vdaka za dobre pripomienky.. Ano, cele som to pisal skor z pohladu servisneho providera, ktory obsluhuje viacero zakaznikov. Ale ta „uctovna“ metoda sa da opat aplikovat v situaciach, ak ma jeden zakaznik u providera viacero sluzieb, uzivatelov a pod. – da sa to pouzit na kvantifikovanie vypadkov.. vacsinou je vypadok „boolean“ a nie je to optimalne imho.

      Servicedesk nastroj na reportovanie vypadkov nevidim v korporaciach velmi dobre fungovat.. Minimalne v tej forme, v akej sa tie informacie o vypadkoch do nich zadavaju, nie su zrozumitelne napriklad pre PR oddelenie, alebo manazment, ktori by mali byt hned v obraze.. V 21 storoci si to predstavujem viac ako notifikacie prichadzajuce z Facebooku 🙂 Mozno je namieste implementovat dvojaky reportovaci tool, jeden interny technicky Servicedeskovy a potom druhy, zrozumitelnejsi, pre tretie strany, siritelny modernymi sposobmi.