Ono se řekne fungující aplikace, ale dnešní aplikace, nebo lépe řečeno softwarové systémy, už nejsou tak jednoduché jako v dobách jednouživatelských aplikací v DOSu. Dnes chceme softwarové systémy, které umějí zpracovat velmi mnoho transakcí za sekundu, pracují s nimi stovky nebo ještě lépe tisíce uživatelů, jsou vícevrstvé, integrované z více vzájemně propojených subsystémů těmi nejlepšími integračními nástroji, tím jsou i škálovatelné a robustní. O těchto termínech už jste možná slyšeli, ale kdo se v tom má nakonec vyznat? To aby jste k provozu takovéhoto systému měli tým odborníků. Koho že to vlastně potřebujete? Softwarového architekta, analytika, vývojáře, administrátora operačního systému, databázového administrátora a sítového administrátora. Skvěle, ale to už máte takové měsíční náklady, že to musí být opravdu výtečný obchodní plán, který pokryje režii všech těchto lidí a ještě Vám něco zbyde. Ale i kdyby nakrásně jste takový tým měli, je schopný tento tým rychle a kvalitně odhalit veškeré problémy s provozem systému? Na jednom konkrétním případě se pokusím ukázat, že odhalení nefunkčnosti softwarového systému nemusí být až tak triviální. Pro jednoho zákazníka již léta vyvíjíme a provozujeme online rezervační systém letenek. Systém je rozdělen do několika vzájemně komunikujících vrstev. Vrstva (říkejme jí vrstva 1), která je nejblíže zákazníkovi je klasický webový systém, který pomocí objektově orientovaných technik (dědičnosti), rozšiřuje jednodušší webovou vrstvou (říkejme jí vrstva 2), jenž obsahuje veškerou funkčnost logiky uživatelského rozhraní, ale neobsahuje všechny uživatelské vlastnosti, specifický design, texty a další customizace, které implementuje až vrstva 1. Toto je velmi vhodné hlavně proto, že existuje velké množství customizovaných webů, které fungují nad stejným základem. Obě tyto vrstvy zajišťují pouze grafické uživatelské rozhraní a vlastní rezervační logika je na straně aplikačního serveru (vrstva 3), se kterým vrstva 2 komunikuje pomocí XML přes TCP/IP protokol. Vrstva 3 simuluje práci živého cestovního operátora a snaží se najít v mezinárodním rezervačním systému AMADEUS optimální letecké spoje podle požadavků internetového uživatele. Vrstva 3 tedy komunikuje se systémem AMADEUS pomocí speciálních API funkcí systému AMADEUS přes TCP/IP. Vrstva 3 si však musí pamatovat určité informace a k tomu používá databázový server, se kterým také komunikuje po síti přes protokol TCP/IP. Uznejte, že o tomuto systému už rozhodně nelze mluvit jako o jednoduchém softwarovém systému. Když se na celý systém podíváme z pohledu hardwaru, pak jsou použity minimálně 3 servery. Webový server pro vrstvy 1 a 2, aplikační server pro vrstvu 3 a databázový server.Všechny tyto servery musí být propojeny sítí. A to nemluvíme o serverech systému AMADEUS, které jsou umístěny na druhé straně zeměkoule, ani o případných dalších serverech pro rozdělení zátěže, zálohování, automatické mailování informací o rezervacích, serverech DNS, apod. Celý popis tohoto "poměrně jednoduchého" systému jsem však sepsal proto, abych ukázal, jak není vůbec lehké najít příčinu najednou se objevící závady. Celý systém softwarově vyvíjíme a upravujeme zhruba 5 let a provoz zajišťovala třetí firma, se kterou majitel systému spolupracoval. Asi před rokem se majitel po delší nespokojenosti rozhodl ukončit spolupráci s třetí firmou a požádal nás i o provoz systému. Ten kdo po někom někdy přebíral nějaký informační systém určitě ví, že to rozhodně nění procházka růžovým sadem. Pro nás, jako vývojáře systému to bylo o dost jednodušší, neboť jsme celému systému jako takovému rozuměli, ale i tak se za dobu provozu udělalo na produkčních serverech několik "vylepšení", o kterých nikdo nic moc nevěděl. Naštěstí se povedlo domluvit s bývalým provozovatelem systému, že dojde k postupnému předání serverů a k dodatečné dokumentaci všech "vylepšení". Nebudu zastírat, že postupný převod serverů probíhá již 9 měsíců, ale jelikož systém funguje, tak nebylo zase až tak kam spěchat. Přesun probíhal a probíhá tak, že se vždy připraví nový hardware a vše se úplně znovu nainstaluje. Zároveň se provede upgrade hardwaru, operačního systému i potřebných knihoven. Nicméně již se pomalu dostáváme k pointě celého článku. Jednoho dne systém vypadal tak, že webové servery i aplikační server byly v servrovně bývalého provozovatele a databázový server již byl úspěšně přesunut do naší servrovny. V takovémto stavu systém úspěšně fungoval několik týdnů. V tom volal zákazník a stěžoval si na občasnou nefunkčnost webového rezervačního systému. Po další diagnostice se ukázalo, že systém se občas jeví jako funkční, občas pomalý a občas nefunkční. Po prostudování logů bylo jasné, že problém je mezi aplikačním (vrstva 3) a databázovým serverem. V logu aplikačního serveru se objevovali hlášky o neúspěšných připojeních do databáze. Začal jsem hledat co se v posledních hodinách a dnech se systémem dělo. Den před incidentem jsme nasazovali novější verzi aplikačního serveru. Změny však nebyly nijak velké a rozhodně by neměly mít vliv na spojení do databáze. Nicméně jsme pro jistotu nasadil starší verzi aplikačního serveru. To však nepomohlo. Zaměřil jsem se tedy na prověření funkčnosti databáze. V logu databáze byly záznamy o mnoha neúspěšných pokusech o připojení aplikačního serveru. Po mnoha neúspěšných pokusech databázový server úplně zablokoval možnost připojení z problematického místa. Zaměřil jsem se tedy na zkoumání konfigurace datábáze. Pokusil jsem se zvětšit maximální počet připojených klientů, zvětšit timeout pro připojení klientů a podobné konfigurační parametry. Na problému už jsem celkově trávil asi dvě hodiny a nic z toho nevedlo ke zlepšení situace. V tu chvíli jsem si vzpomněl na týden staré mailové upozornění od našeho ISP, u kterého máme pronajatý rack v servrovně, že budou mít 5ti minutový výpadek v 5:00 hodin ráno. Okamžitě jsem se podíval do mailů a zjistil, že opravdu ten den výpadku byl dnes. Navíc to přesně souhlasilo s časem, kdy se objevily v logu aplikačního serveru první problémy s připojením do databáze. Tomuto mailu jsme sice před týdnem věnovali patřičnou pozornost, ale naše systémy se s podobným výpadkem běžně umí bez problému vypořádat. Navíc náš centrální monitoring systém nehlásil žádný problém. Už asi tušíte, že jelikož byl aplikační server v jiné servorvně než server databázový (u různých ISP), tak to vypadalo na problém síťový. Okamžitě jsem provedl trošku masivnější ping (
ping -s 1000 -i 0.01) z aplikačního serveru na databázový a objevila se ztrátovost paketů kolem 10ti procent. V tu chvíli bylo jasno a pomocí utilit traceroute a ping bylo otázkou vteřin identifikovat kde je přesně problém. Problém byl samozřejmě mezi routerem v naší servrovně a switchem našeho ISP. Takovéto problémy má na svědomí v 99% špatně nastavený duplex na síťových rozhraních. Na našem rozhraní byla nastavena autodetekce zdetekovaná na 10Mbps half-duplex a po telefonátu s ISP nám bylo řečeno, že u nich je nastaven 10Mbps full-duplex. Přenastavil jsem tedy nastavení našeho rozhraní na 10Mpbs full-duplex a ztrátovost byla vyřešena. Jako mávnutím kouzelného proutku byl vyřešen i problém s celým softwarovým systémem. V tu chvíli jsem si utřel pot z čela a začal celou situaci hodnotit. Problém zavinil ISP tím, že neuložil na jeho switchi konfiguraci, kterou jsme si před několika měsíci domluvili (auto-negotiation na portu). Po výpadku proudu se samozřejmě nahrálo předchozí nastavení switche. Mám štěstí, že jsem ještě z generace IT lidí, kteří mají široký záběr a všechny popsané postupy si umím zajistit sám. Nedovedu si představit, že by podobný problém řešil administrátor OS, administrátor databáze, programátor aplikačního serveru a nakonec by stejně museli zavolat síťaře. Ať žijí jednoduché systémy! Chce se mi křičet "KDO TOMU VŠEMU MÁ ROZUMĚT!". Nicméně s tím se prostě budeme muset smířit a všichni z IT se neustále vzdělávat, aby jsme byli schopni co nejdříve identifikovat opravdové příčiny problémů. Nejhorší je se dostat do stavu, kdy nevíte čím to může být a říkat sobě i druhým, "JO, TO JE HOLT NĚCO MEZI NEBEM A ZEMÍ".
