24.06.2010

Příběh: běžný provoz a údržba IT (1. díl)

Přesunuli jsme se do pondělního odpoledne, kdy Marie opět volá Petovi, aby se informovala o pokroku. Cholerický Petr se naštve, protože ho Marie opakovaně vyrušuje od práce a on potřebuje dokončit build pro zítřejší nasazení. Petr tedy přestane programovat a začne se zabývat identifikací problému, proč aplikace Sklad a Objednávky nefunguje jak má. Marie stále vykonává nepodstatnou práci, důležité objednávky stále nejsou zpracovány a nemohou jít do výroby. Marie si uvědomí, že dnes už asi žádné řešení nepřijde a tak odchází dříve domů. Petr zůstává v práci až do 20h a hledá kde je program provozován, na jakých serverech běží (HW) a jaký middleware (aplikační server) a databázi daný program používá (SW).

V úterý ráno potřebuje Petr dokončit build určený k nasazení, proto přichází dřív do práce i přesto, že včera pracoval do večera. Marie přišla do práce raději později než obvykle, protože si nebyla jista, zda už bude její aplikace funkční. Poté, co Petr dokončil build, pokračuje v hledání serverů z předchozího dne – konečně je nachází, jedná se o Linux servery. Díky tomu, že je Petr linuxový nadšenec a programátor a tudíž zná Linux prostředí (příkazovou řádku a nástroje Linuxu) nedělá mu problém se s problémem s radostí poprat. Bohužel ale zjišťuje, že nemá uživatelský účet na tyto servery. Zavolá tedy Johna (systémového administrátora) a poprosí ho o nějaké přihlášení. John jako Petrův dobrý kamarád mu dá root heslo v domnění, že Petr na Linuxový server nahraje nejaké nové filmy či hudbu, proč jinak by na tento server chtěl přístup.

Na oběd dnes nemá Petr čas a tak jsme se plynule dostali až do úterního odpoledne. Petr se přihlásí jako root a hledá adresář s programem SkladAObjednávky v1.1, aby si mohl prohlédnout logy, jestli v nich něco nenajde. Náhodou si při startu MC všimne, že je disk na tom serveru plný. Smaže tedy nějaké dočasné soubory, to vše pořád jako root. Petr přijde za Johnem a poprosí ho, aby restartoval Oracle DB a Apache, jelikož zjistil, že je program využívá a že oba nejedou. John je restartuje, bez toho aniž by někdo uvědomil další uživatele serveru. Nyní program SkladAObjednávky v1.1 opět běží. Petr tedy spokojeně zavolá Marii a na celý příběh zapomíná. Marie může opět začít pracovat s aplikací a zpracovávat objednávky. Petr se vrátí k práci na buildu pro zítřejší nasazení – spouští a analyzuje testy. Díky skluzu s hledáním chyby pro Marii zůstává v práci opět až do 20h do večera.

Ve středu ráno Marie zpracovává poslední objednávky, ale po 2 hodinách práce se opět objeví stejný problém. Volá tedy opět Petrovi, jestli netuší, co se stalo, ale nikdo telefon v jeho kanceláři nebere, jelikož Petr instaluje nový release, který poslední dva dny dolaďoval a testoval, přímo ve výrobě. Marie mu tedy zavolá na soukromý mobilní telefon a vysvětlí situaci. Petr volá zpátky Johnovi, aby se na problém podíval, jelikož je s ním od včerejška alespoň trochu obeznámen – ví o které servery se jedná a věnuje se dále své práci na instalaci. John vidí plný disk na daném serveru, přesune tedy na jiný server vybrané logy pro pozdější analýzu a smaže nějaké dočasné soubory. Poté John restartuje opět všechny služby a vidí, že všechno funguje správně.

Po obědě ve středu odpoledne se John začně zabývat daným problémem. Píše skript, který bude pravidelně zálohovat na jiný server a mazat na původním dočasné soubory a některé logy. John si chtěl také zkopírovat všechny logy programů běžících na tomto serveru, aby mohl zjistit, kde je chyba, proč se disk stále plní. Díky tomu zjistil, že se velmi dlouho stahuje log Oracle databáze. Zjistil, že důvodem je jeho velikost – 2.96 GB! Začne tedy zkoumat přednostně tento log přímo na serveru a zjistí, že obsahuje programátorské výpisy. Přepíše zamýšlený skript tak, aby zálohoval a na původním serveru mazal hlavně Oracle log a skript nasadí. Zavolá Marii, že může opět pracovat s aplikací, problém se již neopakuje. John dále prohledává Internet a hledá ve fórech, zda se s tímto problémem (programátorské výpisy v Oracle logu v dané verzi databáze) již někdo setkal a zda je problém řešen. Nenajde žádnou odpověď, reportuje tedy chybu společnosti Oracle.

Závěry tohoto scénáře:

I když je daný příklad velmi ostrý a chyby viditelné, spousta organizací opravdu pracuje na podobných principech a nepřipadá jim to divné, jsou-li na toto upozorněny. To je bohužel naše osobní zkušenost. Z tohoto příkladu můžeme udělat několik závěrů:

  • Mary nemohla zpracovávat téměř dva dny objednávky = byznys společnosti se mohl zastavit a nikdo se nad tím nepozastavil.
  • Petr je přetížený a naštvaný.
  • John jako administrátor začíná zkoumat problém (dělat svou práci) až třetí den od incidentu.
  • Release může obsahovat chyby, kterých si Petr díky únavě a napětí nemusel všimnout.
  • Petr přistupuje na servery, kam nemá právo přístupu a to dokonce jako root a navíc zde maže jako root soubory.
  • Znovu se opakující incidenty.
  • Kořenová příčina incidentů stále neřešena.

Máte k tomu co říct?

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *