Dobry den
Zvykli sme pravidelne citat tento mailinglist a aj ked sme sa citili castokrat dotknuti roznymi vyjadreniami, vzdy sme to ignorovali. Dnes sme vsak boli nazvani "banda neschopnych hovad", tak uz reagovat musime.
So serverom Epsilon bol za posledne mesiace castokrat problem. Niekto ten server zrejme pretazuje a to tak, ze je nutny restart. Tento restart sme robili pravidelne na dialku. Problem bol/je, ze server skoro nikdy nenabehol, ostal na FSCK a bola teda nutna navsteva serverovne.
Tuto navstevu sme vykonavali my (firma Platon). Nie su to nase servery a nemame k nim administratorsky pristup, pomahali sme vsak vpsFree a to aj napriek tomu, ze tieto (caste) zasahy nikdy neboli oficialne dohodnute (tazko sa pracuje so serverom, ktory sami nespravujeme).
Rovnaka situacia nastala aj dnes. Bohuzial celkom dobre nechapem preco boli nutne tieto invektivy na nasich ludi.
Chronologia - ako som si ju vyziadal od zamestnancov:
17:45 - vypadok servera (podla mailinglistu outage-list) 18:00 - nahlaseny problem u nas (priblizny cas) 18:45 - nas zamestnanec v serverovi zistuje situaciu a posiela prvy e-mail zakaznikovi (vpsFree)
Nasledne sa zakaznik stazuje, ze nema pristup na remote management. V tejto chvili som ako konatel postavil do pozoru celu firmu (aj ked je sobota), ze ako je mozne, ze tato vec, ktoru tam zakaznik osobne doniesol a nefunguje! Fakt som bol nastvany, za taketo lajdactvo!
Lenze ukazalo sa, ze tento pristup bol nakonfigurovany dna 27-Oct-2011. To co nebolo nakonfigurovane bol samotny remote management device. Mame vsetky switche v SVN, takze vieme presne kedy ktora zmena nastala, vieme kedy bol dany port otvoreny:
+! Last configuration change at 11:36:16 CEST Thu Oct 27 2011 by miquel +! NVRAM config last updated at 11:36:26 CEST Thu Oct 27 2011 by miquel + description zeta.vpsFree.cz - MNG + switchport access vlan 201
Nasledne teda zacali nasi ludia na zaklade instrukcii od zakaznika konfigurovat toto zariadenie na remote pristup. Samozrejme to je vec, s ktorou my nemame ziadne skusenosti, ani taketo zariadenie nevlastnime, ani sme nikdy nepredpokladali, ze s tym budeme musiet robit. Mysleli sme, ze dane zariadenie je nakonfigurovane, ved to bol primarny ciel pred niekolkymi mesiacmi.
Aj po oprave remote managementu server stale nestartoval kvoli chybnemu filesystemu. Ten bol po cca hodine opraveny a nasledne server funkcny. Cely tento cas boli zamestnanci firmy osobne pritomni v datovom centre pre pripad, ze by zakaznik vyzadoval este dalsi zasah.
Nemame problem remote management zariadenie nakonfigurovat ak treba, ale mohli sme tak urobit za posledne dva mesiace kedykolvek. Neprisel vsak ziadny e-mail ohladom toho, ze s tym treba cokolvek robit. To naozaj nik za 2 mesiace neotestoval ten remote management pristup ci funguje? Aky zmysel ma nefunkcny remote management? Ved to je akoby tam ziadny nebol.
Mrzi nas vzniknuta situacia a sposobeny vypadok, ktory sa dotkol urcite mnohych ludi, kedze virtualnych serverov tam bezi vela. Z nasej strany sme ale spravili maximum, alebo aspon sme sa o to pokusili.
Urcite nie sme dokonala firma, mame svoje chyby a muchy, na ktorych musime pracovat. Kazdopadne moji zamestnaci si nezasluzia oznacenie "banda neschopnych hovad". Zvlast nie po dnesnej sobote.
Este raz sa opravedlnujem za vypadok. Plynie z toho pre nas ponaucenie do buducnosti pro-aktivne pristupovat aj k veciam, ktore su mimo nasej spravy, aby vzniknute emergency situacie neboli takto stresujuce.
Dakujem za precitanie
S pozdravom
Ondrej Jombik konatel spolocnosti
-- Ondrej JOMBIK Platon Technologies Ltd., Hlavna 3, Sala SK-92701 +421 903 PLATON - info@platon.org - http://platon.org
Dobry den a pokud mozno podavam virtualne ruku na znak pokoja! Mrzi mne a stydim se, za ten hanebny vyrok smerem k Vasim zamestnancum. Jsem pro existenci serveru v BA. Myslenka rozlozeni zateze geografickou vzdalenosti a nutnost nadnarodni spoluprace byly take duvody proc jsem se stal clenem.
Pavel ADAM sw tester Praha
P.S. Testeri mnohokrat udelaji chybu a reportuji issue, ktere plyne z nevhodne verze, konfigurace, apod. Bandou neschopnych hovad je nikdo nenazyva. ... ?? Dne 11.12.2011 6:05 "Ondrej Jombik" jombik@platon.org napsal(a):
Dobry den
Zvykli sme pravidelne citat tento mailinglist a aj ked sme sa citili castokrat dotknuti roznymi vyjadreniami, vzdy sme to ignorovali. Dnes sme vsak boli nazvani "banda neschopnych hovad", tak uz reagovat musime.
So serverom Epsilon bol za posledne mesiace castokrat problem. Niekto ten server zrejme pretazuje a to tak, ze je nutny restart. Tento restart sme robili pravidelne na dialku. Problem bol/je, ze server skoro nikdy nenabehol, ostal na FSCK a bola teda nutna navsteva serverovne.
Tuto navstevu sme vykonavali my (firma Platon). Nie su to nase servery a nemame k nim administratorsky pristup, pomahali sme vsak vpsFree a to aj napriek tomu, ze tieto (caste) zasahy nikdy neboli oficialne dohodnute (tazko sa pracuje so serverom, ktory sami nespravujeme).
Rovnaka situacia nastala aj dnes. Bohuzial celkom dobre nechapem preco boli nutne tieto invektivy na nasich ludi.
Chronologia - ako som si ju vyziadal od zamestnancov:
17:45 - vypadok servera (podla mailinglistu outage-list) 18:00 - nahlaseny problem u nas (priblizny cas) 18:45 - nas zamestnanec v serverovi zistuje situaciu a posiela prvy e-mail zakaznikovi (vpsFree)
Nasledne sa zakaznik stazuje, ze nema pristup na remote management. V tejto chvili som ako konatel postavil do pozoru celu firmu (aj ked je sobota), ze ako je mozne, ze tato vec, ktoru tam zakaznik osobne doniesol a nefunguje! Fakt som bol nastvany, za taketo lajdactvo!
Lenze ukazalo sa, ze tento pristup bol nakonfigurovany dna 27-Oct-2011. To co nebolo nakonfigurovane bol samotny remote management device. Mame vsetky switche v SVN, takze vieme presne kedy ktora zmena nastala, vieme kedy bol dany port otvoreny:
+! Last configuration change at 11:36:16 CEST Thu Oct 27 2011 by miquel +! NVRAM config last updated at 11:36:26 CEST Thu Oct 27 2011 by miquel
- description zeta.vpsFree.cz - MNG
- switchport access vlan 201
Nasledne teda zacali nasi ludia na zaklade instrukcii od zakaznika konfigurovat toto zariadenie na remote pristup. Samozrejme to je vec, s ktorou my nemame ziadne skusenosti, ani taketo zariadenie nevlastnime, ani sme nikdy nepredpokladali, ze s tym budeme musiet robit. Mysleli sme, ze dane zariadenie je nakonfigurovane, ved to bol primarny ciel pred niekolkymi mesiacmi.
Aj po oprave remote managementu server stale nestartoval kvoli chybnemu filesystemu. Ten bol po cca hodine opraveny a nasledne server funkcny. Cely tento cas boli zamestnanci firmy osobne pritomni v datovom centre pre pripad, ze by zakaznik vyzadoval este dalsi zasah.
Nemame problem remote management zariadenie nakonfigurovat ak treba, ale mohli sme tak urobit za posledne dva mesiace kedykolvek. Neprisel vsak ziadny e-mail ohladom toho, ze s tym treba cokolvek robit. To naozaj nik za 2 mesiace neotestoval ten remote management pristup ci funguje? Aky zmysel ma nefunkcny remote management? Ved to je akoby tam ziadny nebol.
Mrzi nas vzniknuta situacia a sposobeny vypadok, ktory sa dotkol urcite mnohych ludi, kedze virtualnych serverov tam bezi vela. Z nasej strany sme ale spravili maximum, alebo aspon sme sa o to pokusili.
Urcite nie sme dokonala firma, mame svoje chyby a muchy, na ktorych musime pracovat. Kazdopadne moji zamestnaci si nezasluzia oznacenie "banda neschopnych hovad". Zvlast nie po dnesnej sobote.
Este raz sa opravedlnujem za vypadok. Plynie z toho pre nas ponaucenie do buducnosti pro-aktivne pristupovat aj k veciam, ktore su mimo nasej spravy, aby vzniknute emergency situacie neboli takto stresujuce.
Dakujem za precitanie
S pozdravom
Ondrej Jombik konatel spolocnosti
-- Ondrej JOMBIK Platon Technologies Ltd., Hlavna 3, Sala SK-92701 +421 903 PLATON - info@platon.org - http://platon.org
______________________________**_________________ Community-list mailing list Community-list@lists.vpsfree.**cz Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/**listinfo/community-listhttp://lists.vpsfree.cz/listinfo/community-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Dobry den vsem,
timto se oficialne omlouvam.
Stalo se to, co by necekal nikdo z nas - muj uzasny operator (o2 CZ) ma nejaky problem, takze mi nezvoni telefon, kdyz mi nekdo vola, ackoliv se to tvari volajicimu, ze zvoni.
Proto nam totalne zamrzla komunikace a ja jsem si myslel, ze se na nas zamestnanci Platonu vykaslali. Nemel jsem vynaset tak rychle soudy.
Nicmene, abych byl uprimny, presunem serveru do Prahy jednak usetrime a jednak ziskame 24/7 support primo v datacentru, coz je neco, pokud se nepletu, co nam Platon Technologies umoznit nemohou. Desim se okamziku, kdy neco lehne na pateri a nikdo nebude v Bratislave, aby se o to postaral. A jelikoz nikdo neni primo 24/7 v budove serverovny, stat se to muze.
Jinak mam k Platonu par dalsich vyhrad, ale asi neni nejlepsi to probirat verejne.
Velice se omlouvam za to, ze reaguji tak prudce.
Rekl bych, zavolejme si a vec vyresme, nicmene 100% vim, ze ted se mi nikdo nedovola (resim to s operatorem). Takze navrhuji se presunout off-list a doresit vec e-mailem.
Za tu nadavku se opravdu omlouvam. V dany okamzik jsem mel za to, ze se nikdo nestara, aby vec vyresil (viz vyse).
S pozdravem,
Pavel Snajdr
Predseda sdruzeni vpsFree.cz
On 12/11/2011 08:47 AM, Pavel Adam wrote:
Dobry den a pokud mozno podavam virtualne ruku na znak pokoja! Mrzi mne a stydim se, za ten hanebny vyrok smerem k Vasim zamestnancum. Jsem pro existenci serveru v BA. Myslenka rozlozeni zateze geografickou vzdalenosti a nutnost nadnarodni spoluprace byly take duvody proc jsem se stal clenem.
Pavel ADAM sw tester Praha
P.S. Testeri mnohokrat udelaji chybu a reportuji issue, ktere plyne z nevhodne verze, konfigurace, apod. Bandou neschopnych hovad je nikdo nenazyva. ... ??
Dne 11.12.2011 6:05 "Ondrej Jombik" <jombik@platon.org mailto:jombik@platon.org> napsal(a):
Dobry den Zvykli sme pravidelne citat tento mailinglist a aj ked sme sa citili castokrat dotknuti roznymi vyjadreniami, vzdy sme to ignorovali. Dnes sme vsak boli nazvani "banda neschopnych hovad", tak uz reagovat musime. So serverom Epsilon bol za posledne mesiace castokrat problem. Niekto ten server zrejme pretazuje a to tak, ze je nutny restart. Tento restart sme robili pravidelne na dialku. Problem bol/je, ze server skoro nikdy nenabehol, ostal na FSCK a bola teda nutna navsteva serverovne. Tuto navstevu sme vykonavali my (firma Platon). Nie su to nase servery a nemame k nim administratorsky pristup, pomahali sme vsak vpsFree a to aj napriek tomu, ze tieto (caste) zasahy nikdy neboli oficialne dohodnute (tazko sa pracuje so serverom, ktory sami nespravujeme). Rovnaka situacia nastala aj dnes. Bohuzial celkom dobre nechapem preco boli nutne tieto invektivy na nasich ludi. Chronologia - ako som si ju vyziadal od zamestnancov: 17:45 - vypadok servera (podla mailinglistu outage-list) 18:00 - nahlaseny problem u nas (priblizny cas) 18:45 - nas zamestnanec v serverovi zistuje situaciu a posiela prvy e-mail zakaznikovi (vpsFree) Nasledne sa zakaznik stazuje, ze nema pristup na remote management. V tejto chvili som ako konatel postavil do pozoru celu firmu (aj ked je sobota), ze ako je mozne, ze tato vec, ktoru tam zakaznik osobne doniesol a nefunguje! Fakt som bol nastvany, za taketo lajdactvo! Lenze ukazalo sa, ze tento pristup bol nakonfigurovany dna 27-Oct-2011. To co nebolo nakonfigurovane bol samotny remote management device. Mame vsetky switche v SVN, takze vieme presne kedy ktora zmena nastala, vieme kedy bol dany port otvoreny: +! Last configuration change at 11:36:16 CEST Thu Oct 27 2011 by miquel +! NVRAM config last updated at 11:36:26 CEST Thu Oct 27 2011 by miquel + description zeta.vpsFree.cz <http://zeta.vpsFree.cz> - MNG + switchport access vlan 201 Nasledne teda zacali nasi ludia na zaklade instrukcii od zakaznika konfigurovat toto zariadenie na remote pristup. Samozrejme to je vec, s ktorou my nemame ziadne skusenosti, ani taketo zariadenie nevlastnime, ani sme nikdy nepredpokladali, ze s tym budeme musiet robit. Mysleli sme, ze dane zariadenie je nakonfigurovane, ved to bol primarny ciel pred niekolkymi mesiacmi. Aj po oprave remote managementu server stale nestartoval kvoli chybnemu filesystemu. Ten bol po cca hodine opraveny a nasledne server funkcny. Cely tento cas boli zamestnanci firmy osobne pritomni v datovom centre pre pripad, ze by zakaznik vyzadoval este dalsi zasah. Nemame problem remote management zariadenie nakonfigurovat ak treba, ale mohli sme tak urobit za posledne dva mesiace kedykolvek. Neprisel vsak ziadny e-mail ohladom toho, ze s tym treba cokolvek robit. To naozaj nik za 2 mesiace neotestoval ten remote management pristup ci funguje? Aky zmysel ma nefunkcny remote management? Ved to je akoby tam ziadny nebol. Mrzi nas vzniknuta situacia a sposobeny vypadok, ktory sa dotkol urcite mnohych ludi, kedze virtualnych serverov tam bezi vela. Z nasej strany sme ale spravili maximum, alebo aspon sme sa o to pokusili. Urcite nie sme dokonala firma, mame svoje chyby a muchy, na ktorych musime pracovat. Kazdopadne moji zamestnaci si nezasluzia oznacenie "banda neschopnych hovad". Zvlast nie po dnesnej sobote. Este raz sa opravedlnujem za vypadok. Plynie z toho pre nas ponaucenie do buducnosti pro-aktivne pristupovat aj k veciam, ktore su mimo nasej spravy, aby vzniknute emergency situacie neboli takto stresujuce. Dakujem za precitanie S pozdravom Ondrej Jombik konatel spolocnosti -- Ondrej JOMBIK Platon Technologies Ltd., Hlavna 3, Sala SK-92701 +421 903 PLATON - info@platon.org <mailto:info@platon.org> - http://platon.org _________________________________________________ Community-list mailing list Community-list@lists.vpsfree.__cz <mailto:Community-list@lists.vpsfree.cz> http://lists.vpsfree.cz/__listinfo/community-list <http://lists.vpsfree.cz/listinfo/community-list>
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
community-list@lists.vpsfree.cz
-
Ondrej Jombik -
Pavel Adam -
Pavel Snajdr