Vlákno názorů k článku T-Mobile vysvětluje, proč má web několik dnů mimo provoz od Paulos - V souvislosti s upgradem SAPu a podobných firemních...

Jestlize se posle neco do produkce, tak uz to zkratka musi byt overene. Interni testovani musi probihat na temer identicke kopii produkcniho prostredi. Zatezove testy, vse lze nasimulovat (ovsem stoji to prostredky, samozrejme).

Znovu si polozme otazku, stal se v minulosti podobny fail v jine civilizovane zemi, kde T-Mobile ma skutecnou konkurenci ?

Obavam se, ze takovou zkusenost klidne mit muze. Delal sem (napul s kolegou) prevod systemu na technologicky novou verzi. Makali sme na tom cca rok, bez jakyhokoli supportu ze strany (naprosto neschopnyho) dodavatele. Jejich predstava - "to si napisete na papir a pak to tam opisete" ... lol

Ve finale sme si vyhradili na ostry prevod systemu prodlouzeny vikend - vetsina casu byla na pripadny rollback.

System sme (uspesne a prakticky bez problemu) prevedli za jeden den, druhy den se otestoval ...

Po celou tu dobu web normalne bezel, jen byl odstaven objednavkovy system, zakaznici si mohli stahnout ceniky, prohlizet zbozi ...

A samozreme, soucasti bylo i reseni napojenych systemu (jako trebas prave toho shopu a dalsich externich veci).

Normalni patch trva od radove minut do cca hodinu.

Takze odpojeni webu je proste jen a pouze prasarna a naprosta a totalni neschopnost.

já vím, že to jde všechno nasimulovat, hw výkon přepočítat, atp. Jen píšu, že dle mých zkušeností se to tak obvykle nedělá, právě proto, že to stojí moc peněz.

Obavam, se ze prevod IT systemu, na kterem jste delal s kolegou, se neda srovnavat s prevodem desitky systemu, kde na kazdem delala desitka vyvojaru vic jak rok ... a spojit backendy s middlewarem a nakonec frontedem aby vse jelo hned a precizne ... proste potrebuje cas.

Znáte operátory jako například AT&T, Verizon a další, proti kterým jsou ti v ČR naprosto zanedbatelní? Je zajímavé, že v cizině operátoři nemusí zhazovat celé weby jenom kvůli upgradu systémů... :-D

Takže ono to opravdu jde. Mimochodem SAP je pro operátora systém ABSOLUTNĚ NEVHODNÝ - moc pomalý a těžkopádný na takové použití.

To, co může v normálním systému fungovat už za pár sekund (např. různé změny tarifů, SIM karet atd.), tak pokud operátor používá SAP zákonitě to musí ze systému jeho fungování trvat několik minut až hodin.

SAP je dobrý leda tam, kde slouží POUZE K EVIDENCI a nemusí nic řídit a vyvolávat nějaké další složité akce v podsystémech - takže například dobrý ve velkoskladech, obchodech, bankách - to je OK.

Ale u operátorů bych snad SAP zákonem zakázal :-)). V SAPu prostě nikdy neuděláte to, aby Vám SIM karta po výměně fungovala zaručeně ihned, jakmile ji vložíte do telefonu hned na prodejně.

Bohužel, pokud vím, tak v ČR používají teď už SAP všichni operátoři a tak na zákazníka u každého čekají "lákavé hlášky" v SMS, na webech, od operátorů a zaměstnanců prodejen - "změna se projeví do XY hodin/dnů".

A proč operátoři používají SAP, když vědí, že je totálně na prd? PRACHY!!! SAP se dá pořídit pro operátora poměrně levně, stejně jako zaměstnanci, kteří s ním pracují... A zákazník? Nemá v našem "specifickém trhu" jinou možnost!

No a že někdo bude na výměnu SIMky čekat i několik dnů, to náš ČTÚ nepálí - hlavně, že státní platy chodí a víc je nezajímá...

Obavam se, ze se to srovnavat da uplne vpohode. Podotykam, ze zakaznik pro kterejho jsem to delal byl pokud vim jediny, ktery tento system prevedl bez toho, aby po prevodu nastal pruuseer. Naprosto bezna vec byla 14+ denni nefunkcnost (pri postupu dle doporuceni dodavatele systemu ...), vi i o uzivatelich, kteri museli system rollbacknout (a to trebas po tydnu provozu). Dodavatel nebyl schopen predvest jedineho zakaznika, ktery by mohl rict, ze to prevedl bez problemu. Tudiz sem se z vysoka vykaslal na vsechna jejich dporuceni a prevod si implementoval vlastnostnorucne.

Mimochodem, tento bazmek (napr) pouziva jista dcerinka CEZu, a ac mnoho nechybelo, zamestnanci (tusim jich je cca 15 000) nakonec vejplaty dostali.

Zakladem samozrejme byla spoluprace se zamestnanci ( s temi nekolika), kteri vedi co a jak fungovat ma, takze oni testovali a mi sme psali sripty, ktere zajistily ve finale bezproblemovy prevod. V prubehu toho roku sme ten update delali minimalne 10x, takze to bylo dostatecne nacviceno a odladeno.

Ale to sme porad u toho, ze neexistuje ani jediny duvod(kdo totalne debilniho navrhu), aby po dobu aktualizace naprosto libovolnyho systemu byl down web.

BTW: AD testovani zminovane nekde vyse, testovalo se samo na pomalejsim HW, ale tim lip, protoze v okamziku kdy to i na nem bylo takz jakz pouzitelne se da vcelku spolehlive predpokladat, ze ostry HW to zvladne.

Jiste, jsou to kydy. Nevim jak SAP, ale u jinych systemu jsme meli na zmenu verze cas radove v jednotkach minut a nebyl s tim problem.

Co se na tom muze ladit ? Spekulace: pokud do takove zmeny investujete jen treba 10% realne potrebne castky, nelze se divit ze to pak trva tak dlouho. Cesky zakaznik to zkousne, tak proc to delat poradne, ze. Takhle v CR funguje prakticky vsechno. Za co nejvice penez nejmene muziky.

Mimochodem jsem zvedav kdy se ozve SAP s tiskovym prohlasenim, ze toto nebylo zpusobeno na jejich strane. System je to sice "ne prilis optimalni", ale predpokladam ze smlouva rika, ze kazdy problem si musi hodit na hlavu T-Mobile, i kdyby za to vyjimecne nemohl :-)

neznám přímo architekturu T-mobile, ale obecně jsou velké releasy na sapu dycky trochu adrenalin. To že maj na sap navázané další systémy je klidně možné, jestli zrovna toto musí trvat 60 hodin to posoudit neumím. Ale v praxi se do času té odstávky dává vata na řešení nepředpokládaných problémů, které u velkých změn nastávají, dále se počítá s nějakým časem na případný rollback v případě neuspěchu, něco na interní testování, celkem to zas není úplně mnoho.
Testovací systémy sice jsou (sap se obvykle staví jako třísystémový landscape, tj. vývoj/test/pro­dukce), ale zpravidla běhají na slabším hardware a mají další omezení, která se blbě řeší. Už jen když máte několik sapích systémů, do toho pár nesapích, to celé je integrované a máte udělat ze všeho aktuální kopii tak, aby zůstala přes všechny ty systémy konzistentní data není úplně triviální, nehledě na časovou náročnost pořízení těchto kopií (obvykle jde o opravdu velké objemy dat).
Takže realita bývá taková, že na testovacích systémech se otestuje co se dá a pošle se to do produkce a tam běží další interní testování, než se tam pustí zákazníci.

Ale jak říkám, nevím jak je to přesně u TM, popisuju s čím se potkávám na sapu jinde.

V jednotkách minut? Ale tady se nebavíme o upgradu v síti o 100 uživatelích, ale o systémech pro 3 miliony zákazníků a 3000 zaměstnanců. Obávám se, že nemáte ani zkušenosti, znalosti a ani představivost, abyste dokázal komplexnost takového upgradu pochopit. Sám jsem zažil změny systémů například v České poště nebo Českomoravském betonu a věřte, že plně chápu, proč upgrade trval 72 hodin, nemluvě o tom, že pokud vím, TM má SAP a pak dva rozdílné systemy pro eshop a web. Pokud udělali v pátek odstávku a přes víkend upgrade SAPu, tak na updatech ostatních systémů mohli dělat od včerejšího rána a počítal bych, že když to dobře půjde, pustí web dnes okolo poledne. Pokud to stihnou, tak to bude z prdele klika.