T-Mobile má výpadek systémů, který už trvá více než 24 hodin. Vypadá to, že nejde ani jejich SMS brána - může to někdo potvrdit? Jinak normální SMS jdou, i ty z banky.
Publikováno 01 červenec 2020 - 15:25
T-Mobile má výpadek systémů, který už trvá více než 24 hodin. Vypadá to, že nejde ani jejich SMS brána - může to někdo potvrdit? Jinak normální SMS jdou, i ty z banky.
Publikováno 01 červenec 2020 - 15:33
Normální SMS nejdou stoprocentně. Vím o dvou čtyřech zprávách, které jsem dnes nedostal a dozvěděl se o nich až z následného telefonátu. Naopak poslali notifikaci o měsíc starém dávno zaplaceném vyúčtování a tři měsíce starou potvrzující zprávu o zřízení uživatele na webu.
Takže ani na ty SMS se nespoléhejte.
Dobrovolník si myslí, že ví, co je správné, a dělá to. Aktivista si myslí, že ví, co je správné, a nutí to dělat ty ostatní.
Publikováno 01 červenec 2020 - 20:11
Publikováno 01 červenec 2020 - 21:27
HaLuMa napsal/a 01 Čvc 2020 - 19:11:
Z technického hlediska naprosto nechápu, jak může takový moloch běžet z jednoho diskového pole. Takže buď jsou to neskuteční matláci, nebo je skutečná příčina mnohem horší a tají to.
Pochybuji, že to běží z jednoho, ale i tak při objemu dat dnes desítky TB při poruše dat na jednom a synchronizaci je nutné zajistit zpětné dopsání posledních dat či obnovu dat ze zálohy a to může trvat opravdu dlouho.
Jinak jistě, že to tají, málokdo se přizná, to je taková standardní praxe.Těch lidí, kteří přijdou a řeknou, nedomyslel jsem to a to a podělalo se to, omlouvám se, dáváme to do kupy, těch je málo...
/realme 8 (Android 12) + Locus, Oregon 300 už nepoužívám vůbec/
GC3WERW - Vzpominky Tychona Brahe | GC4XTDT - Opustena infekcni klinika Kopa | GC5FJC2 - Benatecke kolecko | GC5R8AF - Achilles a zelva | GC5VYCQ - Chrastenhof (Chrastecky dvur) | GC6N637 - Zubri na Travinach | GC6Q5BT - QIC neboli ctvrtpalec | GC72925 - 7. PLRO Vlkava - Raketaci | GC7FK96 - Beru Ti Stesti | GC92CY5 - Kopec plný bordelu | GC98JF4 - Chrastenhof (Chrastecky dvur) - reloaded | GC9AV0D - Sečtělá | GC9WFCF - Poslední zvonění
Publikováno 01 červenec 2020 - 22:16
23:15 Teď přišly dvě z těch zpožděných zpráv z odpoledne. Ty dvě zhruba z poledne nedorazily pořád.
Dobrovolník si myslí, že ví, co je správné, a dělá to. Aktivista si myslí, že ví, co je správné, a nutí to dělat ty ostatní.
Publikováno 01 červenec 2020 - 22:43
Publikováno 02 červenec 2020 - 9:35
dejwy napsal/a 01 Čvc 2020 - 20:27:
Pochybuji, že to běží z jednoho, ale i tak při objemu dat dnes desítky TB při poruše dat na jednom a synchronizaci je nutné zajistit zpětné dopsání posledních dat či obnovu dat ze zálohy a to může trvat opravdu dlouho.
Desitky TB jsou drobné. Tady bych očekával i o dva řády víc. Ale zrovna u mobilního operátora bych očekával, že je pád jednoho pole nevyděsí. Dokonce bych očekával, že je nevyděsí ani pád celého jednoho datacentra... kurňa, od čeho jsou všechna ta enterprise fault-tolerance řešení? A kdo jinej si je může dovolit, než těžce výdělečný mobilní operátor?
Publikováno 02 červenec 2020 - 9:48
HaLuMa napsal/a 02 Čvc 2020 - 08:35:
Desitky TB jsou drobné. Tady bych očekával i o dva řády víc. Ale zrovna u mobilního operátora bych očekával, že je pád jednoho pole nevyděsí. Dokonce bych očekával, že je nevyděsí ani pád celého jednoho datacentra... kurňa, od čeho jsou všechna ta enterprise fault-tolerance řešení? A kdo jinej si je může dovolit, než těžce výdělečný mobilní operátor?
ta fault-tolerance není zadarmo, a geograficky oddělená failover řešení jsou naročná na konfiguraci, HR, HW, SW....to co se stalo bych viděl možná na nějaký podělaný disaster/recovery test, kdy se provedla jen disaster fáze a pak se to začlo sr.t. Vždycky je v těhlech řešeních nějaký bottleneck u kterého už se nevyplatí mít zálohu, takže při jeho odchodu do křemíkového nebe se možná čeká na dodávku. Zažil jsem v rámci D/R testu odchod síťového prvku, který nebyl skladem a dva dny jsme byli bez (shodou okolností) diskového pole a nepomohla ani záložní lokalita....
Blog o SQL v GeoGetu || Dakota10 || Android: Locus, mapy PAWS || Windows: Geoget
Publikováno 02 červenec 2020 - 11:02
To maj z toho, ze si ty data neopsali vcas na papir
Publikováno 02 červenec 2020 - 11:14
tarmara napsal/a 02 Čvc 2020 - 08:48:
ta fault-tolerance není zadarmo, a geograficky oddělená failover řešení jsou naročná na konfiguraci, HR, HW, SW....to co se stalo bych viděl možná na nějaký podělaný disaster/recovery test, kdy se provedla jen disaster fáze a pak se to začlo sr.t. Vždycky je v těhlech řešeních nějaký bottleneck u kterého už se nevyplatí mít zálohu, takže při jeho odchodu do křemíkového nebe se možná čeká na dodávku. Zažil jsem v rámci D/R testu odchod síťového prvku, který nebyl skladem a dva dny jsme byli bez (shodou okolností) diskového pole a nepomohla ani záložní lokalita....
Myslis takovej T-mobile Cernobyl
Publikováno 02 červenec 2020 - 11:33
HaLuMa napsal/a 02 Čvc 2020 - 10:20:
Budu se opakovat... kdo jinej by si mohl takové řešení dovolit, než velmi výdělečný mobilní operátor?
když jsem mluvil se známým, co dělával pro O2 a odcházel kvůli přetěžování zaměstnanců a neustálému cost-cuttingu (servisy BTS a backendu, delší intervaly obnovy HW), tak si nedělám iluze, že existuje nějaká korelace mezi ziskovostí a investicemi do vybavení...spíš bych to viděl na důslednou ekonomickou analýzu toho co se dá ještě ojebat a jaký bude mít případný průser ekonomický dopad. Proto možná u TM trvá oprava technologií pro plebs tak dlouho a korporátní dodávky pod kvalitním SLA se smluvními pokutami už jsou dávno vyřešené....chtělo by to nějaký insider pohled.
Blog o SQL v GeoGetu || Dakota10 || Android: Locus, mapy PAWS || Windows: Geoget
Publikováno 02 červenec 2020 - 11:39
No jo, ale to by ta bezpecnejší řešení nepoužíval nikdo. Jedni na to nemají, a druzí jsou držgrešle.
Ergo, někde musí existovat velké firmy, kde nevládnou kreténi. (Kreten8 promine, toho jsem nemyslel.)
Publikováno 02 červenec 2020 - 12:43
HaLuMa napsal/a 02 Čvc 2020 - 10:39:
No jo, ale to by ta bezpecnejší řešení nepoužíval nikdo. Jedni na to nemají, a druzí jsou držgrešle.
Ergo, někde musí existovat velké firmy, kde nevládnou kreténi. (Kreten8 promine, toho jsem nemyslel.)
Ale oni ani v TM nemusí být kreténi - SLAčka vyřeší jako první, tak aby případné pokutičky nebyly větší než to co se na discích ušetřilo....no a pak se řeší věci, ze kterých žádný vícenáklad nekouká....selský rozum za tím neradno hledat....
Blog o SQL v GeoGetu || Dakota10 || Android: Locus, mapy PAWS || Windows: Geoget
Publikováno 02 červenec 2020 - 13:53
tarmara napsal/a 02 Čvc 2020 - 11:43:
Ale oni ani v TM nemusí být kreténi - SLAčka vyřeší jako první, tak aby případné pokutičky nebyly větší než to co se na discích ušetřilo....no a pak se řeší věci, ze kterých žádný vícenáklad nekouká....selský rozum za tím neradno hledat....
Přesně. Zkušenosti říkají, že spousta firem, nejen TM, si v podstatě spočítají to, kolik pokut se jim ještě vyplatí v porovnání s náklady na to, aby bylo vše 100%. Už jsem taky zažila, že garantované lhůty, za které se platilo, nakonec zas tak garantované nebyly. Nebo se oprava nějak nouzově lepila z "odkloněných" věcí pro běžný plebs a skutečná oprava nastala až po nějaké době.
Skutečné umění v tomhle je, trefit tu správnou míru šetření, kde to ještě bude vycházet. Tady to zkrátka jednou nevyšlo, a hned hodně viditelně.
0 uživatelů, 1 návštěvníků 0 anonymních uživatelů