Běžné pracovní podmínky v IT pro support

[M]

Doporuceni dobry monitoring a spravne nastaveny tresholdy. Udelany zatezovy testy, testy stability, penetracni testy, HA testy.
Ted jen donutit managment, aby na to byl budget....

To je otázka nastavení smlouvy mezi odběratelem a dodavatelelm. Pokud je to smluvně tak, že každá započatá hodina výpadku systému je penále 2 MKč (neřeší se, zda je to SW nebo HW záležitost, je to problém dodavatele), kdy první 2 MKč se naúčtují po 10 sekundách nefunkčnosti. Horní hranice plnění je neomezeně, zajištění proti nečekanému úpadku dodavatele při vyúčtování penále je směnkami, které vypisuje celý management na sebe jako na fyzické osoby na hezké desítky MKč, tak pak se připomíná správný model vývoje a potřeby pro něj lépe. :-)

[Reklama]

[Waseihou]

U nás se to udělalo tak, že dělat pohotovost je dobrovolná záležitost s tím že dotyčný dostane telefon, a v případě že mu zákazník zavolá a on to zvedne a problém vyřeší, tak dostane odměnu 300 euro. Pokud to nezvedne, tak se nic neděje, zákazník má možnost zkusit dalšího developera. Support tedy není garantovaný, protože opravdu garantovaný support by nedělal nikdo. Navíc se to týká jen víkendů a je za to nějaký ten příplatek (10% nebo kolik) jenom za to že to někdo dělá. Pokud problém nevyřeší, furt má svojích 10%, ale bez odměny. Někteří lidi u nás ve firmě nám byli schopni zařídit takovéto dobré podmínky, no není se co divit, jinak by to totiž nikdo dobrovolně nedělal .

[Zdenek Henek]

Ahoj,

U nas delaji vyvojari support posledni dva roky a stabilita applikace je ted na neuveritelne vysoke urovni, kdyz to vlastne pouzivame .
Kdypak se vyvojari dostanou normalne ke "sve" aplikaci kdyz kolabuje? Muzou si stahnout heap dump, thread dump. Podivat se ktery ze sql dotazu v db zabral nejvice prostredku v dobe kolabovani aplikace? Nikdy, jen v provozu.

Pokud napisete aplikaci, ktera nekolabuje, berte 24/7 jako benefit. Nam chodi varovani tak 5 - 10x za tyden a kriticke chyby, ktere se musi resit okamzite tak 2 - 5 krat za mesic. Uzivatelske dotazy typu "Na co mam kliknout abych dostal ten report, ktery potrebuju" neuvazuju. Na to je dalsi skupina lidi, kteri nepracuji na aplikaci, ale delaji zas upravy a rozsireni pozadovane zakaznikama. A navic si myslim, ze to do druheho dne vetsinou pocka. Zaroven si nemyslim, ze vyvojar je vhodny clovek na takovouto praci, protoze ma na aplikaci uplne jiny pohled nez uzivatel a myslim, ze by si vubec nerozumeli .

Mam 24/7 jeden tyden (prave tento) za cca 2 mesice. Za to mam pak 1 den volno, nebo zaplaceny jeden den navic.

Dale pouzivame monitorovaci system, ktery dokaze spoustu problemu detekovat nez nastanou, aby v dobe pohotovosti nenastal pruser typu neni misto na disku etc.

Pouzivame nagios a spoustu scriptu a v pripade problemu se posila sms zprava. Na archivace statistik pouzivame ganglia vzdaleny monitoring a JavaMelody (uklada historii statistik lokalne na danem serveru)
Na pohotovosti mame vzdy dva lidi. Jeden ma sluzbu a druhy je zaloha(neplacena) pro pripad, ze nekdo proste nema v tu chvili net, nebo se nezbudi po prvnch dvou sms zpravach.

Kdyz dojde sms tak musi clovek oncall do 5 minut udelat ACK, pokud neprovede v systemu ack, dostane dalsi sms za pet minut. Pokud do 15 minut neni provedeno ACK v systemu, dostanou sms zpravu zaloha, pokud do dalsich 5 minut neni provedeno ack v systemu, tak dostanou sms vsichni kdo se ucastni hlidani systemu.

Co ostatni? Jak je to u vas? Nebo tady jen tlachate jak se vyhnout zodpovednosit za svuj kod?
Prosim pouze reakce popisujici konkretni implementaci 24/7. Nechci flame jaky predvadite u jineho vlakna kde uz je nekolik set reakci o nicem.

[Dohled]

Kdypak se vyvojari dostanou normalne ke "sve" aplikaci kdyz kolabuje? Muzou si stahnout heap dump, thread dump. Podivat se ktery ze sql dotazu v db zabral nejvice prostredku v dobe kolabovani aplikace? Nikdy, jen v provozu.

Pokládám za samozřejmost že tato data musí dobře udělaný dohled poskytovat automaticky. Je nesmyslné aby je někdo (ať už admin nebo vývjář nebo jakákoliv jiná živá bytost) musel získávat ručně, to je zbytečně neefektivní. V případě výpadku se pak jen vezmou data nasbíraná automatickým dohledem jako podklad k reportu vývojářům. Příznakem toho že provozní procesy nejsou nastavené dobře jsou požadavky vývojářů na přístup přímo k produkčním serverům - ten by nikdy neměli potřebovat.

[Waseihou]

Příznakem toho že provozní procesy nejsou nastavené dobře jsou požadavky vývojářů na přístup přímo k produkčním serverům - ten by nikdy neměli potřebovat.

Muhehehe, někdy to jinak nejde a dohled míváme vypnutý kvůli performance problémům. Takže se to řeší tak že v případě problému se dohled třeba na týden zapne a pak se čeká až/jestli se to zreprodukuje. Nejhorší jsou situace "občas nám to náhodně spadne, okamžitě to vyřešte" případně "tady se to vypočítalo nějak divně, proč?"...

[Reklama]

[Dohled]

Příznakem toho že provozní procesy nejsou nastavené dobře jsou požadavky vývojářů na přístup přímo k produkčním serverům - ten by nikdy neměli potřebovat.

Muhehehe, někdy to jinak nejde a dohled míváme vypnutý kvůli performance problémům. Takže se to řeší tak že v případě problému se dohled třeba na týden zapne a pak se čeká až/jestli se to zreprodukuje. Nejhorší jsou situace "občas nám to náhodně spadne, okamžitě to vyřešte" případně "tady se to vypočítalo nějak divně, proč?"...

K tomu se dá napsat jen jediné: špatně udělaný dohled. Jaké performance problémy asi tak může způsobit průběžné sbírání statistik z databáze? Jaké performance problémy může mít jednorázový thread dump v případě detekce pomalých odezev aplikace (odezvy aplikace je každopádně třeba průběžně měřit)? Jaké performance problémy může mít automatická tvorba heap dumpu v případě detekování nadměrně dlouhého běhu GC, nebo dokonce OutOfMemoryError?

[Waseihou]

V "customer driven developmentu" nejsou peníze na to něco takového naimplementovat, dokonce ani nepíšeme programátorskou dokumentaci protože by to byly dodatečné hodiny které by zákazník musel zaplatit. To že to nakonec stojí víc protože všechno se řeší stylem "zeptej se, zavolej, zoufej" nikdo neřeší, ale zaběhnutí developeři (tak 2-3 letech) už tyto problémy tolik nemají. Když se na toto nedávno poukazovalo, tak se došlo k tomu, že ani commenty nejsou potřeba, protože "kód má být sám sobě dokumentací".

Prakticky to znamená že když máme více jak 1000 procedur a funkcí v oracle databázi (a několik set dllek...), tak k většině není ani na pár řádků popsáno co přesně dělá (to se přece pozná z názvu) a jaké má výstupy (to se pozná z názvu výstupních proměnných) a na čem všem závisí (aplikační nastavení, to se přece pozná ze zdrojáku) a co všechno volá ("vedlejší" efekt). Jako perličku máme vypnuty debugging informace takže ani nelze krokovat v debugger v toadu a všechny infa si musíme vypisovat přes package který to vypisuje do DBMS_OUTPUT. Tohle nás má donutit je psát, protože u zákazníka taky nemůžou být zapnuty (zase performance) a tak ani my na nich nemůžeme záviset. No a třeba jedna z významných logik je napsána jako .sql funkce co má asi 10000 řádek if .. elsif... elsif ... else

[Jan Forman]

Příznakem toho že provozní procesy nejsou nastavené dobře jsou požadavky vývojářů na přístup přímo k produkčním serverům - ten by nikdy neměli potřebovat.

Muhehehe, někdy to jinak nejde a dohled míváme vypnutý kvůli performance problémům. Takže se to řeší tak že v případě problému se dohled třeba na týden zapne a pak se čeká až/jestli se to zreprodukuje. Nejhorší jsou situace "občas nám to náhodně spadne, okamžitě to vyřešte" případně "tady se to vypočítalo nějak divně, proč?"...

K tomu se dá napsat jen jediné: špatně udělaný dohled. Jaké performance problémy asi tak může způsobit průběžné sbírání statistik z databáze? Jaké performance problémy může mít jednorázový thread dump v případě detekce pomalých odezev aplikace (odezvy aplikace je každopádně třeba průběžně měřit)? Jaké performance problémy může mít automatická tvorba heap dumpu v případě detekování nadměrně dlouhého běhu GC, nebo dokonce OutOfMemoryError?

Pokud to má mít milisekundové odezvy a je velké množství transakcí tak rozhodně to problém je