Publicat pe 1 noiembrie 2026 · Echipa mitza.es

Când un serviciu din cloud cade, problema rareori este „a noastră”: căderea vine din exterior, fără avertisment, și nu se poate repara. Dar firma este cea care decide dacă în ziua respectivă vinde, facturează și își deservește clienții sau stă și se uită la un ecran. Acest ghid pornește de la trei căderi reale din toamna lui 2025, explică ce ne învață și propune un plan de continuitate pe care un IMM îl poate monta cu buget redus.
Trei căderi în mai puțin de o lună
- AWS, 20 octombrie 2025 (regiunea US-EAST-1): o problemă în sistemul de nume (DNS) al serviciului de baze de date DynamoDB, care, potrivit analizei AWS, a pornit dintr-o condiție de cursă latentă în automatizarea sa, a lăsat o înregistrare DNS goală și s-a propagat către alte servicii. A afectat aplicații atât de diferite precum Slack, Atlassian, Snapchat sau Roblox, timp de mai multe ore.
- Microsoft Azure, 29 octombrie 2025: o modificare de configurație involuntară în Azure Front Door, serviciul care distribuie traficul multor aplicații, a lăsat noduri care nu s-au încărcat corect. A afectat Microsoft 365, centrul său de administrare și servicii precum Xbox sau Minecraft. Microsoft a blocat noile modificări de configurație și a revenit la ultima configurație validă. Sursele plasează incidentul la circa opt sau nouă ore, cu mici diferențe de orar.
- Cloudflare, 18 noiembrie 2025: o modificare a permisiunilor unei baze de date a dublat dimensiunea unui fișier de configurație al sistemului de gestionare a boților; la depășirea unei limite interne, serverele proxy au căzut. A lăsat fără răspuns, printre altele, platforme precum X, ChatGPT, Spotify sau Canva timp de aproximativ trei ore. Cloudflare a precizat că nu a fost un atac.
În toate trei cazurile originea a fost o eroare internă sau o modificare de configurație, nu un hacking. Și în toate trei lecția este aceeași: depinzi de furnizori foarte fiabili, dar nu infailibili. Am văzut efecte asemănătoare și cu unelte concrete, precum căderile ChatGPT din august 2026.
Cât costă de fapt o oră de oprire
Înainte să proiectezi ceva, calculează costul unei ore în care fiecare serviciu este oprit: vânzări care nu se fac, comenzi care nu pot fi gestionate, facturi care nu pleacă, oameni plătiți care nu pot lucra și clienți care se duc în altă parte. Nu e nevoie de precizie: un ordin de mărime este suficient pentru a decide în ce merită să investești un plan B și în ce nu.
Pasul 1: harta dependențelor
Fă o listă cu tot ce folosește afacerea ta în cloud sau prin internet și, pentru fiecare element, notează cine îl găzduiește și ce s-ar întâmpla dacă ar cădea patru ore:
- Email și calendar.
- Program de facturare, ERP sau CRM.
- Terminal POS și procesator de plăți.
- Site web și magazin online (și serviciul care îi servește imaginile sau DNS-ul).
- Fișiere partajate și documente.
- Telefonie și mesagerie (WhatsApp, Teams, Meet...).
- Instrumente de inteligență artificială, pontaj, salarii etc.
De multe ori descoperirea este incomodă: mai multe servicii depind, fără să știi, de același furnizor din spate.
Pasul 2: decide ce este critic și definește un plan B pentru fiecare serviciu
- Email: dacă pică furnizorul tău, cum te mai găsește clientul? Ai un canal alternativ (telefon, WhatsApp Business) și comunică-l. Ia în calcul un acces prin browser, pe lângă programul de desktop.
- Vânzări și încasări: există o altă modalitate de a încasa (terminal de card cu altă conexiune, Bizum, transfer)? Poți nota comenzile de mână și să le înregistrezi mai târziu?
- Site și magazin: ține pregătită o pagină statică de avertizare pe care s-o poți publica în alt loc și află cine controlează DNS-ul tău. Explicăm această parte în domeniu și hosting.
- Fișiere: păstrează o copie sincronizată a documentelor critice local sau pe un NAS pentru a le putea deschide fără internet.
- Comunicare internă: stabiliți din timp cum este anunțată echipa atunci când pică instrumentul obișnuit.
Pasul 3: copii independente ale datelor tale
O cădere a unui furnizor este temporară, dar dacă tot ce ai se află în el, marja ta de manevră este zero. O copie independentă și testată, cu regula 3-2-1 a copiilor de siguranță, este baza oricărui plan de continuitate. Dacă folosești stocare în cloud, amintește-ți că sincronizarea nu înseamnă copie de siguranță.
Pasul 4: conexiunea și electricitatea
Nu toate căderile vin din cloud. O linie de internet de rezervă (4G/5G) costă puțin și evită multe opriri; un UPS protejează echipamentele și discurile de întreruperile de curent. Verifică și ce se întâmplă dacă cade fibra: terminalul de card, routerul de rezervă și telefoanele mobile continuă să funcționeze?
Pasul 5: comunicarea în caz de cădere
- Pregătește din timp o notă pentru clienți („întâmpinăm un incident la un furnizor; răspundem prin...”).
- Decide cine o trimite și pe ce canal (rețele sociale, telefon, afiș, mesaj automat).
- Consultă paginile de stare oficiale ale furnizorilor tăi înainte să presupui că defecțiunea este a ta.
- Notează ce s-a pierdut (comenzi, ore) pentru a solicita credite de serviciu sau a ajusta planul.
Contracte și garanții: ce promit de fapt
Marii furnizori publică acorduri privind nivelul serviciului (SLA), dar de obicei compensația constă în credite de serviciu, nu într-o despăgubire pentru pierderile tale. Citește ce garantează, de când numără o cădere și cum se solicită creditul. Iar dacă depinzi de un singur serviciu ca să facturezi, întreabă-te dacă merită să contractezi redundanță sau să păstrezi o alternativă de bază.
Pasul 6: testează planul o dată pe an
Un plan care nu a fost niciodată exersat de obicei cedează chiar în ziua în care e nevoie de el. Dedică o oră pe an simulării unei căderi: oprește „pe hârtie” serviciul principal și verifică dacă fiecare persoană știe ce are de făcut, dacă copiile se restaurează și dacă telefoanele și accesele alternative funcționează.
Greșeli frecvente
- Să crezi că „cloud-ul” include deja continuitatea afacerii.
- Să ai emailul, site-ul și DNS-ul la același furnizor și fără acces alternativ.
- Să nu știi cine are cheile domeniului și cum se schimbă DNS-ul.
- Să nu fi testat niciodată restaurarea unei copii.
- Să comunici târziu sau fără transparență cu clienții.
- Să investești în redundanță pentru un serviciu puțin important și să lași fără plan B pe cel critic.
Legătura cu strategia ta de cloud
Toate acestea nu sunt un argument împotriva cloud-ului: pentru majoritatea IMM-urilor rămâne mai fiabil și mai ieftin decât un server propriu. Este un argument pentru a-l folosi cu ochii deschiși. Dacă vrei panorama completă a modelelor, avantajelor și riscurilor, citește ghidul nostru despre cloud computing pentru IMM-uri.
Cum te ajutăm la Mitza
Te ajutăm să construiești harta dependențelor, să definești planul B pentru ce este critic și să pregătești copiile de siguranță și accesele alternative. Dacă te afli în sudul Madridului, vezi serviciul nostru de mentenanță IT sau scrie-ne din pagina de contact.