Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: radsiAnonymne 09. 10. 2012, 19:18:46
-
Zdravim,
Meli bysme ve firme zacit delat support 24/7, ale ve smlouve to nemame, takze se bude psat nejaky dodatek. Me by zajimalo, jake jsou tak bezne podminky pro "pracovni pohotovost". V praxi to znamena byt neustale na telefonu a pobliz pocitace, aby mohl clovek behem nekolika minut resit problem, i kdyby to bylo treba ve tri rano. Takze to neni jen o zvedani telefonu.
Podle zakona by za takove hodiny pohotovosti melo byt minimalne 10% bezne hodinove mzdy, ale to mi prijde smesne malo treba za zabity vikend. Nemate s tim nekdo zkusenosti? Co je tak bezna praxe v IT? Jedna se tady o (java EE) vyvojare.
P.S. Doufam, ze tady nejsem uplne off-topic - tyka se to pracovniho vztahu, ale praci nehledam a nenabizim a jsem vyvojar, takze jsem zvolil sekci vyvoj.
-
Proč anonymně? Proč bych ti já měl odpovídat pod svým obvyklým nickem?
24/7 držíme, ale je to ošemetná záležitost!
A) V nočních hodinách operátoři provádí údržbu sítě a až překvapivě často dochází k omezení služeb (několikrát ročně)
B) V budovách nebývá pokrytí 100% a občas dochází k poruchám dostupnosti.
C) Zákazníci mají pocit, že operátor hypnotizuje celou noc telefon a na první zazvonění to vezme, tedy zvoní třeba jen 2x a 3x, což spícího člověka vůbec nemusí vzbudit.
D) 24/7 je koule na noze! Člověk nemůže jít ani na záchod, aniž by riskoval, že nějaký hovor propásne. Nejhorší to je třeba o víkendech při sekání trávy atd.
E) Support 24/7 se v 1-2 lidech nedá zajistit, pokud telefon nedáš teda jednateli firmy.
F) Příplatek rozhodně ve výši 100%, kdy polovina jde firmě a polovina zaměstnanci.
G) Pořád platí NBD! Žádné "Zavoláte a začneme to řešit!" V noci se toho moc nevyřeší, operátoři na všech možných linkách chrápou a například ze zkušenosti vím, že problémy nahlášené na O2 se stejně začnou řešit až v 9 ráno! To mám vyzkoušené opakovaně!
Obecně se dá říct: Ano, budete mít servis 24/7, ale negarantovaně, pokud to chcete garantovaně, připlatíte si cca 20 tisíc na našeho nového zaměstnance.
Věř mi, vím o čem mluvím, telefon od šéfa jsem dostal před půl rokem a je to jako koule na noze!
-
Proč anonymně? Proč bych ti já měl odpovídat pod svým obvyklým nickem?
24/7 držíme, ale je to ošemetná záležitost!
A) V nočních hodinách operátoři provádí údržbu sítě a až překvapivě často dochází k omezení služeb (několikrát ročně)
B) V budovách nebývá pokrytí 100% a občas dochází k poruchám dostupnosti.
C) Zákazníci mají pocit, že operátor hypnotizuje celou noc telefon a na první zazvonění to vezme, tedy zvoní třeba jen 2x a 3x, což spícího člověka vůbec nemusí vzbudit.
D) 24/7 je koule na noze! Člověk nemůže jít ani na záchod, aniž by riskoval, že nějaký hovor propásne. Nejhorší to je třeba o víkendech při sekání trávy atd.
E) Support 24/7 se v 1-2 lidech nedá zajistit, pokud telefon nedáš teda jednateli firmy.
F) Příplatek rozhodně ve výši 100%, kdy polovina jde firmě a polovina zaměstnanci.
G) Pořád platí NBD! Žádné "Zavoláte a začneme to řešit!" V noci se toho moc nevyřeší, operátoři na všech možných linkách chrápou a například ze zkušenosti vím, že problémy nahlášené na O2 se stejně začnou řešit až v 9 ráno! To mám vyzkoušené opakovaně!
Obecně se dá říct: Ano, budete mít servis 24/7, ale negarantovaně, pokud to chcete garantovaně, připlatíte si cca 20 tisíc na našeho nového zaměstnance.
Věř mi, vím o čem mluvím, telefon od šéfa jsem dostal před půl rokem a je to jako koule na noze!
Diky za reakci. Tady jde o to, ze tu pohotovost budou mit vyvojari a bude se chtit, aby se ten vyvojar problemem aktivne zabyval a treba ve dve v noci prolejzal logy, databazi, nebo kod aplikace. Ve smlouve o tom nic nemame a melo by to jen relativne kratkodobe - na par mesicu. Predpoklada se, ze tech problemu nebude moc(mozna par za tyden) a pripadne se vyresi za chvili. Jde spis o tu kouli na noze.
P.S. "Proč anonymně?" - No to kdybych se moc rozpovidal, snad mi odpustite.
-
Tady jde o to, ze tu pohotovost budou mit vyvojari a bude se chtit, aby se ten vyvojar problemem aktivne zabyval a treba ve dve v noci prolejzal logy, databazi, nebo kod aplikace.
Jestli je tvoje predstava takova, ze budes ty nebo zakaznik vyvojarum volat na mobil domu tak pocitej s tim ze tak do 2 mesicu ti odejdou vsichni tvoji nejlepsi lide. Staci aby odesel jeden a spusti to lavinu kterou nezastavis. Bez klicovych lidi ti to cele zdechne, protoze zbytek si namele rypak na kazdem netrivialnim problemu.
Vetsi nadeji na uspech ma kdyz ty lidi co maji pohotovost budou v praci a dostanou za to minimalne +50% navrch.
-
Jestli je tvoje predstava takova, ze budes ty nebo zakaznik vyvojarum volat na mobil domu tak pocitej s tim ze tak do 2 mesicu ti odejdou vsichni tvoji nejlepsi lide. Staci aby odesel jeden a spusti to lavinu kterou nezastavis. Bez klicovych lidi ti to cele zdechne, protoze zbytek si namele rypak na kazdem netrivialnim problemu.
Vetsi nadeji na uspech ma kdyz ty lidi co maji pohotovost budou v praci a dostanou za to minimalne +50% navrch.
Ja jsem prave ten vyvojar :-\ Asi nas k tomu dokopou a rad bych vyjednal nejake rozumne podminky kdyz uz to musi byt. Vyslo by to na osobu tak 20 hodin pohotovosti tydne. Pokud se nic nestane, tak podle ceskeho zakoniku prace za to nalezi odmena 10%, tedy jako kdybych dve hodiny pracoval. To mi prijde k smichu.
-
A jak se to tak stane? Já právě spíše začal dělat vývojáře, protože u systémů dost často chtěli pohotovosti a to mi přijde spíše jako práce pro nějakého dělníka. Ale už i u vývoje? Finačně to bylo vždy velmi zajímavé. Příplatek byl nějaký fixní za počet hodin a pak za noční akci další. Nikdy jsem do toho ale nešel, tak nevím přesně.
-
Co se tyka tech 10%, tak ono to nemusi byt zase malo. Protoze behem pracovnich dnu to je 16 hodin denne a o vikendech 24 hodin. Tim padem tech tvych 20 hodin pohotovosti tydne je napr. jeden necely den o vikendu.
Cele to je o tom, jaka je pravdepobnost, ze nekdo zavola.
Pak jeste zalezi na konkretnich lidech, jak travi svuj volny cas. Ja o sobe vim, ze dokazu mit pohotovost maximalne tak jeden tyden v mesici. Vetsi doba uz by me omezovala, nehodlam vsude nosit mobil a mnohdy to mam minimalne hodinu k internetu. Takze tyden se omezovat vydrzim, ale dele nechci a musi se se mnou nekdo stridat.
A naopak jsou kolegove, kteri vedi, ze jejich zakazky v podstate funguji a ze stejne sedi furt doma na netu, takze jim nevadi mit pohotovost celorocne. A navic jim beztak nikdo volat nebude... a ty procenta k platu, vzdyt ono jim to dela skoro 15-20% (hruby vypocet) platu. A navic kdyz nekdo opravdu v noci zavola a resi se to hned v noci, tak se obvykle zakaznikovi pocita vyrazne vyssi sazba (on si aspon rozmysli volat zbytecne) a to se take priznive projevi na vyplate.
-
ale to mi prijde smesne malo treba za zabity vikend. Nemate s tim nekdo zkusenosti? Co je tak bezna praxe v IT? Jedna se tady o (java EE) vyvojare.
Souhlas. A nejde jen o nějaké blaho zaměstnanců – když budou nevyspalí, unavení, naštvaní, tak i produktivita práce půjde do háje.
Co takhle to řešit pomocí náhradního volna – někdy bude mít zkažený víkend, ale jindy bude mít den volna navíc?
-
Spíše pomocí levné pracovní síly. Nechápu, proč by vývojář měl makat ještě v noci. Někdo na telefonu z Indie potvrdí, že se na problému pracuje a je klid.
-
Spíše pomocí levné pracovní síly.
To už rovnou na tom telefonu můžeš nechat odpovídat automat – plechovou hubu. Je to takové, aby se vlk nažral… zákazník bude mít slíbeno 24/7, SLAčka se budou formálně plnit, všichni budou šťastní, ale ve skutečnosti to bude úplně na nic, jako by žádná podpora nebyla.
-
Mně to je v podstatě jedno, kdo to bude dělat. Třeba ať jen restartuje servery. Ale aby mě jako vývojáře někdo obtěžoval v noci? To tak ve snu. Samo o sobě je to dost náročná pozice a ještě obtěžování. Proč to padá na vývojáře? Asi si jich nikdo neváží. Celkově mi to přijde jako špatné řešení. Stejně tak budit kvalitního serveraře. Mělo by to sice všechno šlapat a výpadek stojí plno peněz, ale v noci s tím stejně nic neuděláš, pokud to bude náročné. Když ne, stačí ti nějaký "brigádník".
-
O zadnych podminkach nevyjednavej. Jak zacnes vyjednavat tak prohrajes protoze management je v tom proste lepsi a ma vic zkusenosti a tvuj prirozeny respekt.
Vyhrajes jedine kdyz se do te hry nenechas zatahnout. Nic nepodepisuj a premlouvej ostatni lidi at se na to vykaslou a jdou delat s tebou jinam tak aby te management videl jak je premlouvas.
-
Vyhrajes jedine kdyz se do te hry nenechas zatahnout. Nic nepodepisuj a premlouvej ostatni lidi at se na to vykaslou a jdou delat s tebou jinam tak aby te management videl jak je premlouvas.
Pokiaľ sa jedná o rozšírenie kľúčového biznisu, tak s tým prístupom vyhrá iba výpoveď na hodinu. Ostatní budú poučení, že majú držať hubu a krok, inak pôjdu tiež. Dôvod sa vždy nájde, veď aj preto sú vedúci občas na oko tak tolerantní. Videl by som to skôr na linked.in alebo inú službu ktorú už teraz monitoruje personálne oddelenie. Vtedy vie management, že človek zvažuje alternatívy a robí odhady potrieb.
Ak sa vyjadria k tíme to response a aj k tíme to fix, tak bude človek vedieť o čom to je.
My sa delíme o pohotovosť dohromady asi 15ti, takže ten jeden týždeň za kvartál človek zvládne. Ale, máme rozumných operátorov a tak nás nevolajú s každou blbosťou.
-
Hele... a jak moc to je vlastne kriticka aplikace? Co se stane, kdyz to nebude par hodin fungovat?
Vybouchne to? Zamrzne to? Umrou lidi? Zastavi se vyroba ve Skodovce v Boleslavi? Hrozi nejake sankce?
-
Ted drzim pohotovosti pro vnitrniho zakaznika. Tedy podporuji nase vlastni systemy. Mam priplatek 10tis(za min to tu proste nikdo nebyl ochoten delat) a pohotovost drzim 1 tyden v mesici. Casteji je to sebevrazda a clovek nema soukromi. Drive jsem delal pohotovost 1x za 6 tydnu a odmena byla 25% prumerne hodonove mzdy.
-
Kdyby to bylo o mě, tak prostě řeknu, že doma nemám takové pokrytí signálem, že to zkrátka není možné. (On to nikdo zkoumat nebude.)
Ber to tak, že když se do té hry necháš zatáhnout, snadno si rozházíš biorytmus a bude zle.
Vývojář má v noci spát.
Navíc tím ukradneš práci nějakému chudákovi, co by to dělal ještě rád za 20k hrubého.
-
App k těm procentům, pokud se bavíme o procentech ze mzdy za každou hodinu, kdy jsi dostupný na telefonu, tak to pak ano, to je 20% z hodinové sazby docela dobré. Já za hodiny na telefonu příplatek nemám, ale pokud zákazník zavolá, celá částka "je moje", proto jsem psal 100% navíc. Na druhou stranu to by se mi líbilo, protože se šéfem jsme na telefonu pořád tj. 24/7*30. 20% ze mzdy, to by byla pěkná sumička.
-
Pokiaľ sa jedná o rozšírenie kľúčového biznisu, tak s tým prístupom vyhrá iba výpoveď na hodinu.
To je asi to posledni, z ceho bych mel strach.
Hele... a jak moc to je vlastne kriticka aplikace? Co se stane, kdyz to nebude par hodin fungovat?
Vybouchne to? Zamrzne to? Umrou lidi? Zastavi se vyroba ve Skodovce v Boleslavi? Hrozi nejake sankce?
Sankce jsou pomerne vysoke, vic bych to nerozvadel.
Navíc tím ukradneš práci nějakému chudákovi, co by to dělal ještě rád za 20k hrubého.
Ono jde prave o to mit cloveka co je schopen problem resit/vyresit, ne automat oznamujici "problemem se zabyvame".
20% ze mzdy, to by byla pěkná sumička.
Kdyby ti tohle navrhl zamestnanec, po kterem bys neco takoveho kratkodobe zadal, tak bys to pokladal za rozumne?
Samozrejme, ze nejjednodussi reseni je proste rict ne, ale to z ruznych duvodu nechci/nemuzu udelat. Jen jsem chtel vedet, jestli nekdo nema zkusenosti s tim, ze vyvojar dela(byt jen narazove) 24/7 support. Rad bych vyjednal neco nad ramec zakoniku prace, abych si nemusel pripadat jako idiot.
-
20% ze mzdy, to by byla pěkná sumička.
Kdyby ti tohle navrhl zamestnanec, po kterem bys neco takoveho kratkodobe zadal, tak bys to pokladal za rozumne?
No, jestli šéf jezdí v 8 let starým Subaru a je rád, že to utáhne, tak asi ne.
Jestli jezdí ve slušným autě a užívá si komfortního života, tak bych se rozhodně nestyděl.
Příklad rozhovoru:
Uděláš to? Je to jen na pár měsíců!
Ok, ale chci 20% normálního platu za každou hodinu, co budu na telefonu.
To je moc!
Ale vždyť je to jen na pár měsíců ne?
Nebo:
Uděláš to? Je to jen na pár měsíců!
Ok, ale chci 20% normálního platu za každou hodinu, co budu na telefonu.
To je moc, 10%!
Víš, mám hrozně zlou ženu a budu mít doma peklo, dej to někomu jinýmu.
Nebo:
Uděláš to? Je to jen na pár měsíců!
Ok, ale chci 20% normálního platu za každou hodinu, co budu na telefonu.
Ani náhodou, uděláš to zadarmo!
A myslíš, že je lepší www.jobs.cz nebo www.prace.cz?
Nebo:
Uděláš to? Je to jen na pár měsíců!
Ok, ale chci 20% normálního platu za každou hodinu, co budu na telefonu.
15%!
Tak fajn, ale budu na telefonu jen od 6 do 24:00.
Nebo:
Uděláš to? Je to jen na pár měsíců!
Ok, ale chci 20% normálního platu za každou hodinu, co budu na telefonu.
Fajn.
-
A ještě jedna oblíbená varianta:
Uděláš to? Je to jen na pár měsíců!
Ok, ale chci 20% normálního platu za každou hodinu, co budu na telefonu.
Ale Karel dostává 10%!
Super, tak o čem se bavíme, ať to dělá Karel, já mám hrozně zlou ženu a navíc u nás v baráku je všechno hrozně slyšet, jak telefonuju, ruší to sousedy a pak máme po baráku peklo!
-
Podle IP to jsou lidi, co stojí za registrem SPZtek ;D
Mám pravdu, žejo!
-
Navíc tím ukradneš práci nějakému chudákovi, co by to dělal ještě rád za 20k hrubého.
Ono jde prave o to mit cloveka co je schopen problem resit/vyresit, ne automat oznamujici "problemem se zabyvame".
Jak se ve tři ráno řeší problém s programem? Chápu, že u serveru ho stejně nakonec třeba restartuješ, ale u programu? Nějaká logická chyba a 100 milionů řádků? :D
-
Podle IP to jsou lidi, co stojí za registrem SPZtek ;D
Mám pravdu, žejo!
Ne. Nejsem prizivnik, zakaznici jsou mimo CR.
Jak se ve tři ráno řeší problém s programem? Chápu, že u serveru ho stejně nakonec třeba restartuješ, ale u programu? Nějaká logická chyba a 100 milionů řádků? :D
Samozrejme nebudes ve tri rano kompilovat a nasazovat novou verzi, ale napr. zakaznik nahlasi problem->v logu najdes vyjimku-> kouknes do kodu-> prijdes na to, ze je nejspis chyba v datech -> kouknes do DB -> je to tak -> zmena v datech a problem vyresen.
-
Jak se ve tři ráno řeší problém s programem? Chápu, že u serveru ho stejně nakonec třeba restartuješ, ale u programu? Nějaká logická chyba a 100 milionů řádků? :D
Nehledě na to, že vytáhnout ze zákazníka, v čem je vlastně problém a neposlat ho při tom do ******, bývá opravdu umění. Za takovou drsnou detektivní práci s prvky psychologie je 10% asi opravdu málo. 24/7 nedělám, ale jinak se zákazníky jednám skoro pořád, takže o tom vím svoje.
Samozrejme nebudes ve tri rano kompilovat a nasazovat novou verzi, ale napr. zakaznik nahlasi problem->v logu najdes vyjimku-> kouknes do kodu-> prijdes na to, ze je nejspis chyba v datech -> kouknes do DB -> je to tak -> zmena v datech a problem vyresen.
To zní až podezřele jednoduše na to, aby to byla vždycky pravda...
-
To zní až podezřele jednoduše na to, aby to byla vždycky pravda...
To byl jen priklad, abych ilustroval ze neni uplny nesmysl, aby v nejake kriticke chvili byl dostupny vyvojar 24/7.
-
pohotovost spis vetsinou drzi adminove, nevim, proc by nekdo platil vic za programatora, ktery k tomu vetsinou ani neni kompetentni.
A BTW kdyz zakaznik nahlasi problem a je to chybou datech v DB, tak nastinene reseni mi pripada ponekud pofiderni - samozrejme, ze kompilovat musis. Novy release bude potom pravdepodobne osetrovat onu vyjimku v datech (tak, aby to nevlivnilo fci aplikace) a soucasti bude i db skript, ktery narovna nekorektni data. Teprve potom bude problem vyresen, v opacnem pripade jsi pouze promrhal prostredky zamestnavatele a nic se nevyresilo - takova pohotovost moc smysl nema.
-
Taky drzime pohotovost v 6ti lidech je to asi neco malo pod 10K za tyden, kazdej umime neco jinyho, vsichni umime jen zakladni diagnostiku a restartovat, ja jsem taky java vyvojar.
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....
Na jednom projektu jsem vzdy dostal telefon(firma se jmenovala telefonika ale na sluzebni telefon jsem nemel narok) incident A do 3 h nahodit (1 h to lezelo v nejake fronte), psat SQL pres 60 tabuli se tremi rekurzivnimi subdotazi a dvema temp tabulkama, zjistit ktery subdovatel to rozbil, vetsinou ten ktery ma SLA 24h ;-)
Dneska vecer se jeste musim uklidnit abych zitra nepodal vypoved nebo je nepostrilel ;-)
Asi bych se stavil k tomu jak to casto to bude padat a jaky je riziko ze budou nabalovat projekty (za stejny penize).....
Pokud budou penize na rozvoj bude to padat casem min, pokud je posranej navrh padat min to nikdy nebude,
jak se budou plnit databaze/rust trafic bude to padat vic (obzvlast pokud je malo HW a spatny skalovani).
Nejvetsi pruser je kdyz projekt zavisi na spouste cizich komponent (webovy sluzby, databaze, midleware, ), pak je to jak hra zachod.....
Nejcastejsi servisni zasahy jsou nejdriv restartovat (a potom se ptat) nebo rict shorelo to, muze za toto a proto to neni v ramci SLA, a pak kontrola systemu po nejake neocekavane udalosti, z kontrol logu uz mam nocni mury (vzdycky kdyz se tam kouknu vidim aspon 3 bugy a ten co hledam tam neni),
Vyvojari nejvic rozumeji logu a dokazaji z vyjimek dohledat kod a co jim basnik(cti jiny vyvojar) chtel rict, maji nejvetsi prehled v databazi, rozumeji svemu runtime
-
Pokiaľ je otázka postavená do finančnej roviny, tak na Slovensku sú dve sadzby. Jedna je za pohotovosť a druhá za výkon práce v pohotovosti. O pokrytí služby 7x24 som počul len počas pilotnej prevádzky testovania novej verzie interfejsov. Pokiaľ sa jedná o dynamického zákazníka, tak tam sa pilotná prevádzka môže ukončiť až vypršaním kontraktu.
Takže aj podľa upresnenia sa nejedná o pohotovosť pre programátora ale pre operátora. A cena sa odvíja aj od TTR. Ja bez problému zoberiem 10% ak budem mať povinnosť prijať požiadavku do štyroch hodín. Pri inej SLA je aj cenník iný. Inak by si človek nenakúpil a ani nezašiel domov.
-
pohotovost spis vetsinou drzi adminove, nevim, proc by nekdo platil vic za programatora, ktery k tomu vetsinou ani neni kompetentni.
100% souhlas. Pracuji pro jednu z největších firem v .cz a je to přesně tak: existuje oddělení provozu, které drži pohotovnosti (střídají se, je jich hodně). Ostatní (včetně vývojářů) pohotovost nedrží. Ano, byly pokusy zatáhnout do pohotovostí vývojáře, ale ty velmi brzy skončily poté co si vývojáři (se svými vysokými platy) řekli o ta samá procenta platu za pohotovost jako mají adminové z provozu.
Ono se stejně ukazuje, že problémy jsou většinou způsobené provozními anomáliemi (výpadky napájení, výpadky na datové síti, výpadky databází, výpadky kdečeho, ...) se kterými by stejně vývojář nepomohl. Přínos vývojáře by v drtivé většině výpadků nebyl efektivní. Ano, je to celé podložené formálním procesem předávání z vývoje do provozu (dokumentace!!!!), ale nakonec to funguje.
-
Jen pro dokreslení celé situace, existuje ještě jedno řešení: mít víc provozů geograficky šikovně rozdělených tak aby všude byl zrovna den a žádná noční pohotovost nebyla potřeba (nekecám, i takhle to v realitě u doopravdy velkých společností funguje). Chápu že tohle není řešení pro kdekterou malou firmu, ale pro úplnost jsem to musel uvést.
-
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. :-)
-
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 ;D.
-
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.
-
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.
-
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č?"...
-
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?
-
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 :D
-
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 :)