Capcanele invizibile ale infrastructurii. Lecția Heathrow despre riscuri IT care nu apar în rapoarte

În martie 2025, un incendiu la o stație electrică a blocat aeroportul Heathrow pentru aproape o zi întreagă. Peste 1.300 de zboruri au fost anulate. Aproximativ 300.000 de pasageri au fost afectați. Titlurile globale au numit evenimentul o „pană de curent”, dar realitatea din spate a fost mult mai îngrijorătoare.

Nu a fost vorba de servere. Nici de aplicații. Și nu a fost vorba nici de o lipsă de redundanță pe hârtie – Heathrow, la fel ca majoritatea operatorilor de infrastructură critică, avea sisteme de alimentare de rezervă. Defecțiunea a apărut la comutare (switchover): timpul și complexitatea necesare pentru a transfera sarcina către sursele redundante atunci când cea principală a picat fără avertisment. Iar investigația care a urmat a scos la iveală ceva și mai grăitor – riscuri it asociate unei probleme la echipamentele stației electrice, care existau încă din 2018, așteptând în liniște să devină o criză.

Acesta este tiparul din spatele aproape oricărei defecțiuni majore de infrastructură: blocajul (bottleneck) se află rareori acolo unde se uită toată lumea. Echipele își fac planuri pentru penuria de CPU și capacitatea de stocare. Ceea ce oprește de fapt activitatea unei companii este, de obicei, ceva aflat mai jos în stivă – alimentarea, răcirea, rețeaua sau „instalațiile” operaționale pentru a căror inspectare nimeni nu își alocă buget de timp până când nu se strică.Pentru orice specialist de Infrastructură IT, cazul Heathrow este un memento util că reziliența nu este o simplă căsuță de bifat. Este o disciplină continuă, care de obicei cedează în liniște, cu mult înainte ca eșecul să devină vizibil.

Riscuri IT mai puțin evidente

Câteva dintre constrângerile care surprind cel mai des organizațiile nepregătite:

Disponibilitatea energiei electrice. Multe camere de date corporative sau camere de servere au destul spațiu în rack-uri, dar nu și suficientă energie utilizabilă. O echipă investește în echipamente noi de înaltă densitate sau hardware bazat pe GPU, doar pentru a descoperi că rack-urile nu pot furniza cei peste 30 kW necesari pentru a le rula. Energia electrică, nu spațiul fizic, devine adevăratul plafon de capacitate – și este cel mai greu de extins rapid, deoarece modernizarea rețelelor și lucrările la stațiile electrice pot dura luni sau ani, nu săptămâni.

Capacitatea de răcire. Echipamentele de calcul moderne, în special cele pentru sarcini de lucru AI, generează mult mai multă căldură decât a fost proiectată să gestioneze infrastructura moștenită (legacy). Acum zece ani, un server cu două socket-uri consuma aproximativ 250–300 W doar pentru procesoare, ceea ce ducea la o densitate tipică de putere pe rack de 5–8 kW. Astăzi, un server cu două socket-uri poate necesita 700–1.000 W doar pentru procesoare, împingând densitatea de putere pe rack la un nivel complet nou. Punctele fierbinți (hot spots), fluxul de aer inadecvat și sistemele de răcire dimensionate pentru densitatea de ieri devin blocaje în calea implementării înainte ca puterea de calcul să fie o problemă.

Arhitectura de rețea construită pentru un tip greșit de trafic. Majoritatea rețelelor enterprise sunt proiectate pentru traficul user-to-application într-o singură locație sau regiune. Însă, într-o arhitectură distribuită care se întinde pe mai multe centre de date sau regiuni cloud, AI-ul, virtualizarea și microserviciile generează un trafic masiv de la server la server (trafic „est-vest”) care traversează rack-uri, clustere și, uneori, regiuni întregi – un tipar care nu a făcut niciodată parte din designul inițial. Într-un scenariu tipic, o companie care rulează sarcini de lucru în trei centre de date regionale (de exemplu, Frankfurt, Amsterdam și Varșovia) presupune că majoritatea traficului va rămâne local și că doar solicitările la nivel de aplicație vor traversa legăturile dintre site-uri. Cu toate acestea, odată ce se introduc antrenarea AI sau analizele distribuite, fiecare nod poate avea nevoie să schimbe continuu parametri de model sau seturi de date, transformând ceea ce se anticipa a fi un trafic inter-site de <20% într-un trafic est-vest susținut de 60–80% de-a lungul regiunilor.

Chiar și o interconectare gigabit bine dimensionată între locații poate deveni saturată, ducând la cozi de așteptare, pierderi de pachete și vârfuri imprevizibile de latență. Rezultatul nu este o pană totală, ci o scădere severă a performanței: utilizarea clusterelor de GPU-uri scade sub 40–50%, timpii de interogare se triplează, iar sarcinile de lucru care arătau perfect echilibrate în documentele de proiectare se degradează dramatic odată ce începe sincronizarea reală între regiuni.

Performanța de stocare (throughput), nu capacitatea de stocare. Terabiții sunt ieftini. IOPS-urile nu sunt. Sarcinile de lucru de AI și analiză de date au nevoie de un randament susținut și de o latență scăzută – iar când stocarea nu poate ține pasul, echipamentele scumpe de calcul stau degeaba așteptând datele.Ferestrele de backup și recuperare. Infrastructura tinde să crească mai repede decât capacitatea de a o proteja. O fereastră de backup care gestiona confortabil 100 TB în patru ore se poate extinde în liniște la 12 ore pe măsură ce volumele de date se triplează. Impactul depășește sarcinile de backup: o organizație cu un Obiectiv de Timp de Recuperare (RTO) de patru ore poate descoperi că restaurarea a 150 TB de date de producție durează de fapt 18–24 de ore, ceea ce face ca planurile de recuperare în caz de dezastru să fie imposibil de respectat în practică. În același timp, legăturile de replicare care sincronizau cândva 3 TB de modificări zilnice printr-o conexiune de 10 Gbps pot rămâne permanent în urmă atunci când modificările zilnice de date cresc la 12–15 TB. Organizațiile descoperă adesea aceste blocaje doar în timpul unei defecțiuni majore sau al unui test complet de recuperare în caz de dezastru, când obiectivele de recuperare care păreau realizabile pe hârtie se dovedesc imposibile în condiții reale.

Limitele WAN și de conectivitate. Pe măsură ce organizațiile mizează tot mai mult pe modelele cloud și hibride, blocajul se mută adesea complet în afara centrului de date – în saturația MPLS, circuite de internet aglomerate sau latență ridicată către regiunile cloud. Performanța cloud-ului devine limitată de rețea, mai degrabă decât de capacitatea de calcul.

Niciuna dintre aceste probleme nu apare într-un raport simplu de capacitate. Ele devin vizibile în timpul unui incident sau în timpul unei extinderi (scale-up), când remedierea lor este deja costisitoare.

De ce se întâmplă asta în continuare

Numitorul comun în toate aceste cazuri este dezechilibrul. Organizațiile investesc masiv în calcul – mai multe servere, mai multe GPU-uri, mai multă stocare – în timp ce infrastructura adiacentă (alimentare, răcire, rețea, backup, conectivitate) este lăsată să recupereze decalajul mai târziu. O singură verigă slabă este suficientă pentru a limita randamentul tuturor celorlalte investiții. Un rack plin de GPU-uri nu oferă nimic dacă circuitul electric nu îl poate alimenta, dacă răcirea nu îl poate susține sau dacă rețeaua nu poate muta datele în și din el suficient de rapid pentru a-l menține ocupat.Și pentru că aceste componente sunt de obicei gestionate de echipe diferite, cu bugete diferite și în intervale de timp diferite, nimeni nu are o imagine de ansamblu. Aceasta este exact breșa care transformă o „problemă cunoscută din 2018” într-un subiect de primă pagină la nivel național, șapte ani mai târziu.

Unde intervine M247 Global

Aceasta este exact problema pentru a cărei rezolvare a fost creat M247 Global. În loc de a trata alimentarea, răcirea, conectivitatea, cloud-ul și continuitatea activității ca elemente separate, gestionate de furnizori diferiți, M247 Global oferă soluții de infrastructură digitală end-to-end – un singur furnizor, un singur contract, un singur punct de contact – susținute de un centru de date Tier III în București, cu recuperare completă în caz de dezastru în Brașov, și asigurate de suport tehnic expert 24/7/365.

Iată câteva moduri în care acest lucru abordează direct blocajele menționate mai sus:

• Constrângerile de alimentare și densitate sunt rezolvate prin colocare cu configurații de alimentare de mare densitate, personalizabile – de la rack-uri partajate până la implementări complet dedicate – astfel încât investițiile în hardware să nu fie blocate din cauza energiei insuficiente.
• Sarcinile de lucru de AI sau cele HPC sunt susținute prin infrastructură pregătită pentru AI: noduri propulsate de GPU, configurate special pentru sarcina de lucru și integrate cu framework-uri de AI de top, evitând problema „GPU-ului inactiv” cauzată de un mediu dezechilibrat.
• Blocajele de rețea sunt adresate printr-o rețea globală IP MPLS cu zeci de puncte de prezență și redundanță pe rute duale pentru fiecare conexiune.
• Backup-ul, recuperarea și exact tipul de eroare de comutare care a oprit aeroportul Heathrow sunt acoperite prin DRaaS – continuitate a afacerii bazată pe cloud, proiectată pentru recuperare rapidă, nu doar un plan de redundanță care funcționează doar în teorie.
• Expunerea la riscuri cibernetice și atacuri DDoS, un declanșator din ce în ce mai comun pentru defecțiunile în cascadă ale infrastructurii, este gestionată prin servicii de Securitate construite cu Fortinet și Corero.

Scopul nu este doar menținerea în funcțiune a unei singure componente. Este vorba despre o infrastructură echilibrată, în care alimentarea, răcirea, rețeaua, stocarea, cloud-ul și reziliența sunt proiectate și gestionate împreună – astfel încât blocajul care va ieși eventual la suprafață să nu fie cel pe care nu îl urmărea nimeni.

Activitatea companiei nu trebuie să se oprească niciodată. Cu un uptime de 99,99%, monitorizare proactivă și o echipă de gardă non-stop, M247 Global este construit astfel încât următorul „Heathrow” să nu se întâmple în infrastructura ta.

FAQ 1: Care a fost cauza reală a blocării aeroportului Heathrow?

Eșecul procesului de comutare (switchover) la sistemele de rezervă și ignorarea unor riscuri tehnice cunoscute de ani de zile, nu lipsa de redundanță pe hârtie.

FAQ 2: De ce apar blocajele de infrastructură în locuri neașteptate?

Companiile monitorizează straturile evidente (CPU, stocare), dar ignoră infrastructura de suport (alimentare, răcire, backup) administrată fragmentat de echipe diferite.

FAQ 3: Cum devine designul de rețea un blocaj în mediile moderne?

Sarcinile de lucru de tip AI sau microservicii generează trafic masiv server-la-server („est-vest”) care saturează rapid legăturile inter-site și prăbușește performanța.

FAQ 4: Cum pot organizațiile să prevină aceste blocaje ascunse?

Prin trecerea de la optimizarea izolată la o arhitectură holistică. M247 Global elimină aceste riscuri unificând puterea de calcul, conectivitatea și reziliența într-o singură soluție.