Masivní výpadek služeb Googlu

Uživatele Googlu trápí masivní a globální výpadek služeb. Nefunguje přihlášení na Gmail, G Suite, YouTube... Téměř úplnou nefunkčnost služeb Googlu hlásí uživatelé na sociálních sítích z celého světa. Připojení pomocí VPN z jiného regionu problém neřeší.

14.12.2020 13:33 | brozkeff | IT novinky

Komentáře

[JiK]

prijde mi to vtipne, kazdy cpe vse do cloudu, kazdy ma desitky virtualnich stroju, ktere skoro nic nestoji, kamarad, ktery delal v IT jedne velke americke banky se holebal, jak v campusu, kde je 10 tisic zamestnancu, nemaji ani jednu servrovnu.

Pry je to dnes uz obsolete.

Kazdy outsourcuje a outsourcuje a pak nekdo ukopne snuru do zasuvky v te posledni outsourcovne, nekde v indii, v cloudu vsech cloudu, a naraz bude tma v polovine internetu...

[jiwopene]

A navíc často ani netuší skorem nic o tom, co se s jejich virtuálními stroji vlastně děje a kde je fyzický stroj, na kterém běží.

[Radovan]

Před necelým měsícem jsem se zasmál: https://www.novinky.cz/internet-a-pc/clanek/kvuli-vypadku-serveru-amazonu-nefungovaly-v-usa-vysavace-a-zvonky-40343570

[[Jooky]]

Tiez tuto logiku nepochopim ... nebolo to tak davno, ked facebook rozhodil polku internetu. Kazdy pcha to ich "like" tlacidlo aj na posledne staticke stranky a ked mali v tom kode chybu, tak sa nenacitala cela stranka ... Vsetci sa furt predhanaju kto je vacsi cloud a neuvedomuju si, ze pocas vypadku tie sluzby proste neprenesu inde ... a hlavne su odkazany na nejaku tretiu stranu a ich "snahu" to dat dokopy ...

Mam tricko: "There is no cloud. It's just someone else's computer" ... Manazery su z toho furt pobureny, pritom je to 100% pravda.

[Filip Jirsák]

Přitom je to tak jednoduché. Nevýhody – když nebude fungovat poskytovatel CDN, nebude fungovat ani váš web. V přehledu výpadků přitom výpadky CDN budete těžko hledat mezi výpadky vaší vlastní infrastruktury. Závěr – je to zanedbatelná nevýhoda. A teď výhody. Náklady na diskový prostor, bandwidth a provoz serveru obecně neplatíte vy, ale někdo jiný. Pokud si CDN vyberete dobře, doručí požadované soubory uživateli rychleji, než váš vlastní server – takže uživateli se stránka zobrazí dřív. Takže když si to porovnáme – jedna zanedbatelná nevýhoda, která se projeví jednou za X let (tento výpadek neměl vliv na Google CDN) proti výhodám, které pocítí každý uživatel každý den, a ještě díky tomu ušetříte. Hm, to je těžká volba.

[xkucf03]

provoz serveru obecně neplatíte vy, ale někdo jiný

Jaká je podle tebe motivace, aby někdo poskytoval ostatním takovou službu „zdarma“? A jaké to má vedlejší efekty? Je to dlouhodobě udržitelné? Proč by jedna firma měla nést náklady za jinou firmu?

Mně připadá přirozené, že si každý zaplatí tu část nákladů na provoz infrastruktury, kterou používá. Ale možná jsem staromódní…

[Filip Jirsák]

To je tvoje věc, nikdo tě nenutí ty CDN používat. Já jsem fanda opensource, a opensource je zrovna příklad, kde „každý čistě za své“ vůbec neplatí. Google opensource hodně využívá, takže hostování opensource projektů v CDN může být způsob, jak Google „splácí svůj dluh“. Mimo jiné proto, že pro Google je takové hostování jednoduché (infrastrukturu na to má, přidá „jen“ další soubory), zatímco pro autory drtivé většiny opensource projektů je vlastní CDN nedosažitelná.

[Josef Kufner]

Provozovatel CDN také získává data o provozu různě po Internetu.

[Kate]

Problém je, že ve chvíli výpadku infrastruktury jednoho cloudu sletí nejen jeden web, ale spousta dalších ve stejnou chvíli. Může se třeba stát, že využití alternativní komunikační platformy nebude možné. Ano, pro jeden konkrétní subjekt to výhoda je, ale pro společnost moc ne.

[Filip Jirsák]

Bavíme se tu o webu a CDN, nevím, co v tomto kontextu znamená „alternativní komunikační platforma“.

[mirec]

když nebude fungovat poskytovatel CDN, nebude fungovat ani váš web

Záleží na tom na aký účel sa CDN používa. Ak je použitý len na ukladanie médií tak bude fungovať úplne v pohode, akurát sa nenačítajú obrázky / videá.

takže uživateli se stránka zobrazí dřív

V zásade ani nie. Na mojich weboch najviac spomľauje načítanie DNS a spojenie so serverom. Keď už browser komunikuje so serverom je načítanie tých dokopy do 100kB obrázkov, javascriptu, css a fontov rýchle. Keď som meral čas načítavania so statickými súbormi v CDN bývavalo načítanie o 20-50% pomalšie, pretože pribudla komunikácia s ďalším serverom + DNS.

[Filip Jirsák]

Jenže DNS záznam té CDN už má prohlížeč obvykle dávno v cache, případně je v cache nejbližšího DNS resolveru.

[Filip Jirsák]

Mam tricko: "There is no cloud. It's just someone else's computer" ... Manazery su z toho furt pobureny, pritom je to 100% pravda.

Pravda to není. Cloud není jeden počítač, je to spousta počítačů v různých lokalitách. Takže pravděpodobnost výpadku nebo přetížení je podstatně menší, než u jednoho počítače.

[xkucf03]

Pravda to je. Tady nejde o množství serverů a počet záloh (zálohovat můžu i vlastní infrastrukturu), ale o to, kdo to vlastní a že nakonec to jsou zase jen nějaké počítače, které někomu patří – nikoli nějaký magický cloud poskytující zázračné funkce, jak si často asi veřejnost pod vlivem marketingových kampaní těch dodavatelů představuje.

Pokud by někdo nevěděl, co to je za citát: There is no cloud – existuje to i jako samolepky.

[Filip Jirsák]

Samozřejmě že jde o množství serverů a počet záloh. To je totiž ten jediný reálný způsob, jak za rozumnou cenu zvyšovat spolehlivost. Neznám nikoho, kdo by si myslel, že magický cloud poskytuje zázračné funkce. Zato už jsem viděl spoustu komentářů, kde si dotyčný myslel, že jeho lokální řešení je absolutně spolehlivé.

[[Jooky]]

Cloud není jeden počítač, je to spousta počítačů v různých lokalitách. Takže pravděpodobnost výpadku nebo přetížení je podstatně menší, než u jednoho počítače.

Pravda to je. Tam nejde o to ci to je, alebo nie je redundantne. Redundantne riesenie sa da bez problemov spravit aj "in-house" a toto bezne robia firmy, ktore sa tomu rozumeju. Cloud je len "buzz word", ktory s radostou pouzivaju manazeri, lebo maju pocit, ze migracia do clodu vyriesi vsetky problemy sveta. Realita je taka, ze taka migracia len prenesie data "na niekoho ineho pocitace" a funkcnost, alebo nefunkcnost je na pleciach niekoho ineho. Presne o tom je ta nalepka / tricko ...

... co si malo kto uvedomi je, ze s migraciou do cloudu stracaju kontrolu nad datami. Kym "in-house" si vie clovek problemy relativne rychlo opravit, tak v cloude moze byt aj mesiace bez sluzby. Kedze vsetko zalezi od dalsej osoby "a jeho pocitacoch".

[Filip Jirsák]

Jde o to, zda to je či není redundantní. To je totiž jediný použitelný způsob, kterým se dosahuje vyšší spolehlivost. Platí to samozřejmě nejenom pro servery, ale třeba také pro úložná zařízení. Je to jako kdybyste tvrdil, že RAID1 je k ničemu, protože je to jen druhý disk, nebo že zálohování je k ničemu, protože je to jenom druhé místo uložení. Cloud je samozřejmě možné provozovat in-house, nikdo tu netvrdil opak.

Cloud je len "buzz word", ktory s radostou pouzivaju manazeri, lebo maju pocit, ze migracia do clodu vyriesi vsetky problemy sveta.

Že má někdo údajně tenhle pocit už jsem četl mnohokrát. Nikdy jsem ale neslyšel nebo nečetl nikoho, kdo by to doopravdy říkal. Není to spíš tak, že vy máte pocit, že někdo jiný má takovýhle pocit?

... co si malo kto uvedomi je, ze s migraciou do cloudu stracaju kontrolu nad datami. Kym "in-house" si vie clovek problemy relativne rychlo opravit, tak v cloude moze byt aj mesiace bez sluzby. Kedze vsetko zalezi od dalsej osoby "a jeho pocitacoch".

Naopak tenhle nesmysl se v diskusích objevuje často. Čím jsou ty „servery někoho jiného“ tak odlišné, že na nich dochází k neopravitelným závadám, zatímco na vašich serverech k takovým závadám nedochází? Jak přesně se na opravení závady projeví to, zda ta „další osoba“, na které to závisí, je placená pře kolonku „služby“ nebo kolonku „mzdy“? I když máte něco in-house, pořád závisíte na nějakých serverech a na lidech, kteří je umí spravovat.

[Josef Kufner]

Ono "Cloud" se používá ve dvou kontextech. Jeden je ten manažerský, který je opravdu jen buzz word a zázračné řešení. Ten druhý je technický, kdy se oddělí běžící služby od fyzického hardwaru pomocí virtualizace a kontejnerů, což je velice smysluplná věc.

[Filip Jirsák]

Jeden je ten manažerský, který je opravdu jen buzz word a zázračné řešení.

To tak opravdu někdy někdo vnímal? Že se tak děje čtu každou chvíli, ale nikdy jsem nezaznamenal konkrétní případ. Samozřejmě to může být někdy přeceňováno i podceňováno, stejně jako cokoli jiného.

Ten druhý je technický, kdy se oddělí běžící služby od fyzického hardwaru pomocí virtualizace a kontejnerů, což je velice smysluplná věc.

Podle mne podstatou cloudu je hlavně automatizace infrastruktury, tj. automatizace škálování a zotavení z chyb jednotlivých uzlů.

[Josef Kufner]

Ti co nevědí, o čem je řeč, to tak vnímají celkem běžně. Asi máš štěstí na zasvěcené lidi v tvém okolí.

Podle mne podstatou cloudu je hlavně automatizace infrastruktury

To je důsledek virtualizace, tedy spíš důsledek její kombinace s continuous integration/delivery. Automatizace bez virtualizace je taková neohrabaná a neuniverzální.

[Filip Jirsák]

Není to nevyhnutelný důsledek virtualizace. Virtuální servery tu byly už dávno před cloudem, ale jako cloud se začalo označovat to prostředí, kde se aplikace nasazují, migrují a škálují automaticky. To byla ta novinka v cloudu – že když vypadl jeden server, nemusel nikdo na základě zprávy z monitoringu někde ručně nastartovat jiný, ale že se to stalo automaticky. Že nemusel někdo ručně přidávat další servery, když se zvýšilo zatížení systému. Že nebylo potřeba ručně migrovat servery, když se do infrastruktury zapojilo další datacentrum (ať už kvůli výpadku jiného nebo v rámci posilování kapacity nebo rozkládání zátěže). Proto se začal používat název cloud – protože aplikace najednou neběží na konkrétních serverech, které někdo určil, ale běží tam někde mezi mnoha servery, podle toho, kam zrovna aplikaci umístila infrastruktura. Ona ta aplikace ve skutečnosti pořád běží na nějakých konkrétních serverech, ale cloud se liší tím, že to není podstatné, kde přesně běží.

[deda.jabko]

Virtuální servery tu byly už dávno před cloudem, ale jako cloud se začalo označovat to prostředí, kde se aplikace nasazují, migrují a škálují automaticky. To byla ta novinka v cloudu – že když vypadl jeden server, nemusel nikdo na základě zprávy z monitoringu někde ručně nastartovat jiný, ale že se to stalo automaticky.

Jako cloud se puvodne oznacovalo prostredi, kde si clovek pronajimal virtualni servery podle sve aktualni potreby. Prvotnim hybatelem v tomto smeru byl Amazon se svym Elastic Cloud, ktery mel tuny zeleza nachystane na to, aby vykryl vanocni svatky a po zbytek roku se mu flakaly v datacenterch. Kouzlo cloudu, zejmena pro manazery, spocivalo v tom, ze uz nebylo nutne kupovat drahe zelezo, ktere se nikdy nevyuzilo na sto procent, ale slo pronajmout podle aktualni potreby nekde, kdo vi kde, proste v cloudu, a proto se vyznam cloud rozsiroval od IaaS i smerem k PaaS a SaaS, kde se plati taky podle aktualni potreby.

Dalsi veci jako automaticke skalovani prisly az s urcitym odstupem, kdyz se pomalu zacalo zjistovat, k cemu vsemu je EC2 vlastne pouzitelny.

[Filip Jirsák]

Nutnou podmínkou ovšem byla právě ta automatizace. Pokud si pronajímáte VPS v měsíčních cyklech, dá se to řešit ručně. Pokud chcete pronajímat po hodinách nebo po ještě kratších úsecích, je potřeba tu infrastrukturu spravovat automaticky.

[xkucf03]

Jde o to, zda to je či není redundantní. To je totiž jediný použitelný způsob, kterým se dosahuje vyšší spolehlivost.

Ano, to děláme všichni. Sám zmiňuješ ten RAID1 – to mají lidi i v pracovních stanicích, ne jen ve vlastních serverech. Stejně tak je celkem normální zálohovat síťové prvky, konektivitu, mít skladem součástky, které se běžně rozbíjejí, mít připravený další HW navíc (na něm se dá běžně třeba vyvíjet nebo testovat a v případě potřeby bys ho použil jako záložní pro produkci). K ničemu z toho cloud nepotřebuješ – jsou to běžné/dobré praktiky, které uplatníš i s vlastní infrastrukturou.

(Veřejný) cloud se může vyplatit v případě, kdy máš velké výkyvy v požadovaném výkonu – jednou potřebuješ velké kapacity, pak zase ne a nevyplatilo by se ti dlouhodobě vlastnit a provozovat tu infrastrukturu. Čím větší firma/organizace jsi a čím jsou tvoje potřeby víc konstantní (nebo postupně rostoucí), tím je (veřejný) cloud méně výhodný. Pak se ti víc vyplatí vlastní infrastruktura, případně klasický hosting nebo housing. Od určité úrovně tomu pak můžeš říkat privátní cloud a být sám sobě poskytovatelem (interními zákazníky jsou pak jednotlivá oddělení nebo projekty).

[Bherzet]

+1. Např. AWS je všechno, jen ne „levné“, jak bylo řečeno výše. Vyvíjel a spravoval jsem docela rozsáhlý backend provozovaný právě na AWS a i když to v některých případech bylo naprosto neocenitelné (nového zákazníka, pro kterého jsme potřebovali víc výkonu než pro pomalu všechny ostatní dohromady, jsme byli schopni začít obsluhovat během pár hodin), tak si přesto myslím, že v našem případě by možná bylo lepší zahausovat si někde pár serverů a alespoň ty stálé klienty obsluhovat skrz ně.

Ten objem už byl docela velký, za AWS se platilo hodně a úspora by mohla být dost velká. Když vezmeš třeba t2.micro ve Frankfurtu (1 GiB/1 vCPU/EBS), tak to stojí kolem dvou stovek měsíčně. Pár desítek procent odečti, když si to zarezervuješ na několik měsíců dopředu. U Forpsi dostaneš tohle za 70 Kč měsíčně.

Ano, samozřejmě, nemáš k tomu všechna ta klikátka, monitoring, managed služby (ElastiCache, SQS, S3, load balancery, …). Jde ale o to si uvědomit, že aby ti AWS vůbec nabízelo nějaké výhody oproti běžným VPSkám, tak potřebuješ mít celý ten backend postavený na bázi mikroslužeb. Na každou úlohu máš jednu mikroslužbu. Tu mikroslužbu nainstaluješ na EC2 instanci, vytvoříš z ní image, flákneš ho do autoscaling groupy a podle trafficu si automaticky spawnuješ třeba 3 až 10 instancí.

S každou instancí platíš nějakou marži provozovateli. Jakákoliv snaha snížit počet instancí (např. používat 2 silné instance místo 10 slabých, nebo na jednu instanci ve skutečnosti nainstalovat víc mikroslužeb), ti zhoršuje tu škálovatelnost a zejména spolehlivost. To je totiž další věc, že když si u instancí nastavíš healh check (třeba klasický ping nebo jednoduchý HTTP request), tak můžeš detekovat vadné instance, nechávat je odstřelit a místo nich naspawnovat nové. Opět i proto je žádoucí na jedné instanci mít těch služeb co nejméně, protože pokud jich tam máš víc a jedna z nich chcípne, musí se vyměnit celý stroj – což se i při správném softwarovém návrhu (nevznikne někde nějaká nekonzistence v datech, …) projeví minimálně nějakou latencí. To je problém hlavně u front-facing služeb, ale i u těch asynchronních vadí, když se na vyřízení úlohy najednou bude čekat několik minut místo pár vteřin. Pokud se to stane častěji, uživatelé budou (právoplatně) nasraní.

Vlastní hardware si zaplatíš jednou (+ potom samozřejmě více/méně fixní náklady na provoz). Kolik si do něj nastrkáš kontajnerů je vlastně víceméně jedno. U AWS platíš určitou daň z objemu a ta není zcela zanedbatelná. V určitou chvíli se musíš rozhodnout, jestli se ti vyplatí ji nadále platit, a nebo si raději „ušpiníš ruce“ a rozběháš si vlastní hardware a vlastní infrastrukturu. Na to potřebuješ lidi a třeba v našem případě fakt nebylo úplně jednoduché odhadnout, jestli to stojí za to nebo ne.

Uzavřel jsem si to pro sebe s tím, že správná odpověď neexistuje a ostatně – mně by vyhovovalo obojí. AWS se mi jako programátorovi líbí, ale nebránil bych se ani tomu naskillovat se víc v klasickém adminování. Zůstalo se u AWS a jako jo, asi se nám díky tomu lépe spalo. Ale ten argument s rozumnou cenou je prostě mimo. Kdybych se teď rozhodl začít vyrábět boty, tak se taky můžu rozhodnout, že buď si postavím vlastní ševcovskou dílnu/továrnu, nebo si jen objednám výrobu u nějaké existující, ale vzdám se pár desítek procent marže. Na začátku je to rozhodování jednoduché, ale později u rozjeté firmy? To je už otázka strategie a hlavně osobních preferencí.

Z ryze ekonomického hlediska se prostě nabízí prostor zvýšit si zisky tím, že si to budu vyrábět sám. On ostatně ten Amazon nezačal dělat do hostingu taky jen tak náhodou, že. Stejně tak třeba Seznam by asi nedokázal zdůvodnit zrušení vlastních serveroven nějakou „rozumnou cenou“.

[Josef Kufner]

Byl by v takové situaci problém běžet na privátním cloudu i na AWS současně? Tedy mít pár vlastních levných serverů pro pokrytí typického vytížení služeb a AWS používat, jen když je potřeba přidat výkon, nebo nějaký server vypadne?

[Bherzet]

Byl by to problém hlavně kvůli databázím a nutnosti je synchronizovat napříč datacentry. Objem těch dat nebyl zanedbatelný. Asi by to šlo, ale moc by se to nevyplatilo. Používat jen vlastní železo, jednou denně posílat inkrementální zálohu (diff) na AWS a když shit hits the fan, tak udělat failover, to by reálné bylo. Ale mít jednu mikroslužbu tady a druhou tam, to by byl jen zdroj problémů a starostí a nevěřím, že by to něco přineslo.

[Josef Kufner]

Říkal jsem si, že databáze asi bude tím problémem. Na jednu stranu nějaká replikace často poběží tak jako tak, aby byla záloha, ale ten opačný směr (tj. multi-master) už je problematický.

[Filip Jirsák]

Nikdo netvrdil, že cloud pro redundanci potřebuju. Jenom jsem připomněl takovou drobnost, že zařízení bez redundance a zařízení s redundancí není to samé.

[frufru]

Klid, to byla jen zkouška vypnutí Gogle. To byla jen malá ukázka pro státy. Nebudete platit, tak Vám to vypnem! Co bude evropská unie dělat, až jim servry na dálku vypnou. Mám rád konspiraci

[j]

Nejlepsi argumentace na to tema je, ze oni maji ty profiky (mineno v IT) a tudiz se jim nic takovyho stat nemuze ... ;D. Takze zatimco blbej lokalni ITk muze vyresit skoro libovolnej vypadek behem minut (i kvuli rozsahu), tak v cmoudu si muzes pockat i par (ty)dnu ... a to se vyplati.

A to jeste treba dodat, ze se ti taky muze stat, ze tvoje data proste nebudou, a provozovatel tak maximalne pokrci rameny, pripadne naopak, tvoje data budou verejny. Vyber si co je horsi.

Jak je tu o fous vedle, naprosto pak netusis, kde na cem ty tvoje data vlastne vubec sou, a kdo knim ma jakej pristup. Krasny jsou na tom i ty "garance" ... na tema ze ti teda vratej ten mesicni poplatek, ale tvoje klidne stamilionovy skody si muzes ...

---

Dete s tim guuglem dopice!

[MadCatX]

Zdroj zprávičky. Výpadek měl podle všeho trvat cca hodinu.

[xkucf03]

IMHO LOL.

Přestaly fungovat i všechny weby, které se odkazují na JavaScripty od Googlu, místo, aby si je hostovaly samy?

[O.V.]

Nektere hostovat lokalne nelze. Treba mapy.

[plostenka]

OSM samozrejme hostovat lokalne lze.

[Josef Kufner]

Také záleží, kolik map potřebuješ. Dost často jen okolí nějakého místa a to můžeš na web hodit klidně jako statické soubory, tedy dopředu si nastahovat těch pár MB dlaždic. Ono se to nezdá, ale celý svět v přiblížení, kdy je Evropa akorát na obrazovku (z = 5) má nějakých 10 MB.

Druhá možnost je kešujcí proxy na serveru, kdy se při prvním zobrazení nakešuje, co je potřeba a další uživatelé mohou dostávat lokální kopii bez závislosti na třetí straně. Jen je vhodné to nakešované čas od času aktualizovat.

[trekker.dk]

Dost často jen okolí nějakého místa a to můžeš na web hodit klidně jako statické soubory, tedy dopředu si nastahovat těch pár MB dlaždic.

Tipnul bych si, že dát na web rámeček s google maps je jednoduché, zatímco postahovat si pro okolí nějakého místa statické soubory a na zbytek používat tu mapu už tak jednoduché nebude. Plus je tu otázka autorských práv.

[Jindřich Makovička]

Ne. CDN normálně fungovala.

[_]

To mohly napsat abych dvacetkrat neresatroval router........

[Vrána]

Seznam jsi zkoušel?

[_]

Youtube aplikace na ipadu mi jaksi seznam neukazuje

[Vykook]

Testovat konektivitu youtube aplikaci, je minimálně divné..

[_]

Sám seš divnej, někdy jde všechno kromě youtube a restart routeru pomůže. Tak drž tlamu nebo mi to sprav.

[Vykook]

Tím dětinským koupáním kolem sebe a útoky ad hominem si moc nepomůžeš. Jistě že bych ti to mohl opravit, ale zadarmo dělám jen pro BFU z rodiny..

[Matlák]

Dobře ti tak. Ach jo. Popravdě nevím, co mimo totálního rozpadu služeb impéria Googlu a impéria Facebooku by pomohlo lidem, aby začali trochu používat mozek. Vím že minimálně jedno podtržítko tady není uplně blbé, ale nedá mi to:

....a zde, pánové, vidíte typického moderního uživatele internetu. Už nehostuje servery, už nesdílí kód a nápady. Už ani aktivně nekomunikuje. Jen pasivně, v transu čumí na leské placce na jedno křiklavé video za druhým za přizvukování ukřičených reklam a v případě výpadku umí jen mechanicky dvacetkrát za sebou odpojovat a připojovat kabel k routeru, jako by to byl nějaký rituál k přivolání trubkového boha...

Tochu mi to připomíná strašidelný výjev z The Machine Stops.

Mimochodem, zajímalo by mě jak si vedla v té chvíli recaptcha tady na abíčku. Jak CDN tak DNS servery fungovaly, což při minulém výpadku alespoň lokálně neplatilo.

[_]

Ehm, vzadu je tlačítko, kabele.

[Matlák]

Tím hůř, technický mágu, ty co znáš tlačítko.

[_]

Ty jsi si žádný tlačítko nikdy nezmáčk co xD

[Orlando]

Ví někdo přesný čas od kdy do kdy Google nefungoval? Protože jsem nijaké problémy nezaznamenal.

[JiK]

asi proto, ze ti proxy pro vsechny google veci dela NSA...

[min]

Začalo mi to zlobit ve 13 hod. (a něco) a zcela se to rozběhlo až ve 14:30

[Max]

Je to různé podle lokace a jiných věcí. Každopádně první problémy byly hlášeny kolem 12:30 a poslední problémy mizely kolem 14:30
Něco ukáže downdetector.
Zdar Max