Internetul pare a fi o structură puternică, independentă și de neclintit. În teorie, rezistența rețelei este suficientă pentru a supraviețui unui atac nuclear. În realitate, internetul poate cădea din cauza unui singur router mic. Toate aceste probleme se datorează faptului că internetul este un amalgam de contradicții, vulnerabilități, erori și videoclipuri cu pisici. Baza internetului - protocolul BGP - conține o mulțime de probleme. Este uimitor că mai funcționează. Pe lângă erorile în sine ale internetului, este sabotat de toți cei care nu au alte ocupații: mari furnizori de servicii internet, corporații, state și atacuri DDoS. Ce să facem cu aceasta și cum să trăim cu asta?
Răspunsul îl știe Alexey Uchaikin () - liderul echipei de inginerie de rețea de la IQ Option. Principala sa responsabilitate este asigurarea disponibilității platformei pentru utilizatori. În transcrierea raportului lui Alexey de la , vom discuta despre BGP, atacurile DDoS, întrerupătoarele de internet, erorile furnizorilor, descentralizarea și situațiile în care un mic router a trimis internetul la somn. La final - câteva sfaturi despre cum să supraviețuim tuturor acestor lucruri.
Ziua în care Internetul s-a stricat
Voi prezenta doar câteva incidente în care conectivitatea Internetului a fost afectată. Acestea vor fi suficiente pentru a oferi o imagine de ansamblu completă.
«Incidentul AS7007». Prima dată când internetul s-a stricat a fost în aprilie 1997. În software-ul unui router din sistemul autonom 7007 a fost o eroare. La un moment dat, routerul a anunțat vecinilor tabelul său intern de rutare și a trimis jumătate din rețea într-un black hole.
«Pakistan împotriva YouTube». În 2008, niște băieți curajoși din Pakistan au decis să blocheze YouTube la ei. Au reușit atât de bine încât jumătate din lume a rămas fără pisici.
«Captura prefixelor VISA, MasterCard și Symantec de către Rostelecom». În 2017, Rostelecom a început din greșeală să anunțe prefixele VISA, MasterCard și Symantec. Ca rezultat, traficul financiar a fost redirecționat prin canale controlate de furnizor. Scurgerea a durat puțin, dar companiilor financiare le-a fost neplăcut.
«Google împotriva Japoniei». În august 2017, Google a început să anunțe în parte prefixele marilor furnizori japonezi NTT și KDDI. Traficul a fost trimis către Google ca tranzit, cel mai probabil din greșeală. Deoarece Google nu este un furnizor și nu permite trafic de tranzit, o parte considerabilă a Japoniei a rămas fără internet.
«DV LINK a capturat prefixele Google, Apple, Facebook, Microsoft». În 2017, furnizorul rus DV LINK a început să anunțe fără motiv rețelele Google, Apple, Facebook, Microsoft și alți jucători mari.
„eNet din SUA a preluat prefixele AWS Route53 și MyEtherwallet”. În 2018, un furnizor din Ohio sau cineva dintre clienții săi a anunțat rețelele Amazon Route53 și portofelul criptografic MyEtherwallet. Atacul a fost un succes: chiar și în ciuda certificatului auto-semnat, care afișa un avertisment utilizatorului la accesarea site-ului MyEtherwallet, multe portofele au fost compromise și o parte din criptomonedă a fost furată.
Numărul incidentelor de acest tip doar în 2017 a fost de peste 14.000! Rețeaua este încă descentralizată, așa că nu totul cedează și nu la toți. Dar incidentele se întâmplă cu miile, și toate sunt legate de protocolul BGP, pe care funcționează internetul.
BGP și problemele sale
Protocolul BGP - Border Gateway Protocol, a fost descris pentru prima dată în 1989 de doi ingineri de la IBM și Cisco Systems pe trei „servetele” - foi de format A4. Aceste încă mai sunt păstrate în sediul principal al Cisco Systems din San Francisco ca o relicvă a lumii rețelurilor.
La baza protocolului stă interacțiunea sistemelor autonome — Autonomous Systems sau pe scurt - AS. Un sistem autonom este pur și simplu un anumit ID, sub care în registrul public sunt înregistrate rețele IP. Un router cu acest ID poate anunța aceste rețele în lume. Prin urmare, orice rută în internet poate fi reprezentată sub formă de vector, denumit AS Path. Vectorul este compus din numerele sistemelor autonome prin care trebuie să trecem pentru a ajunge la rețeaua de destinație.
De exemplu, există o rețea formată dintr-un anumit număr de sisteme autonome. Trebuie să ajungem din sistemul AS65001 în sistemul AS65003. Drumul de la un sistem este reprezentat prin AS Path pe diagramă. Acesta este format din două autonome: 65002 și 65003. Pentru fiecare adresă de destinație există un vector AS Path, care constă din numerele sistemelor autonome prin care trebuie să trecem.
Atunci, care sunt problemele BGP?
BGP este un protocol de încredere
Protocolul BGP este bazat pe încredere. Asta înseamnă că, implicit, ne încredem în vecinul nostru. Aceasta este o caracteristică a multor protocoale care au fost dezvoltate la începuturile internetului. Să analizăm ce înseamnă „a avea încredere”.
Nu există autentificare a vecinului. Formal există MD5, dar MD5 în 2019 este... cam discutabil...
Nu există filtrare. BGP are filtre și acestea sunt descrise, dar nu sunt utilizate, sau sunt utilizate greșit. Voi explica mai târziu de ce.
Foarte simplu de a configura vecinătățile. Configurarea vecinătăților în protocolul BGP pe aproape orice router - câteva linii de configurare.
Nu sunt necesare drepturi de administrare BGP. Nu este nevoie să susții examene pentru a-ți dovedi calificarea. Nimeni nu îți va lua drepturile pentru configurarea BGP în stare de ebrietate.
Două probleme principale
Furarea prefixelor - prefix hijacks. Furarea unui prefix înseamnă anunțarea unei rețele care nu îți aparține, cum ar fi cazul MyEtherwallet. Am preluat câteva prefixe, ne-am înțeles cu furnizorul sau l-am hack-uit, și prin el anunțăm aceste rețele.
Scurgerile de rute - route leaks. Cu scurgerile este puțin mai complicat. O scurgere este o modificare a AS Path. În cel mai bun caz, modificarea va duce la o întârziere mai mare, pentru că trebuie să parcurgi o rută mai lungă sau printr-un link mai puțin capabil. În cel mai rău caz, se va repeta cazul Google și Japonia.
Chiar și Google nu este operator și nu este un sistem autonom de tranzit. Dar când acesta a anunțat furnizorului său rețelele operatorilor japonezi, traficul prin Google pe AS Path a fost perceput ca având prioritate mai mare. Traficul a fost îndreptat acolo și a fost pierdut pur și simplu pentru că setările de rutare din Google sunt mai complicate decât simplele filtre de pe margine.
De ce nu funcționează filtrele?
Nimănui nu-i pasă. Aceasta este principala problemă - tuturor le este indiferent. Administratorul unui mic furnizor sau al unei companii care s-a conectat la furnizor prin BGP a luat un MikroTik, l-a configurat pentru BGP și nici măcar nu știe că există filtre ce pot fi configurate.
Erori de configurare. Am debug-uit ceva, am greșit masca, am setat o rețea greșită - și iată, din nou o eroare.
Nu există capacitate tehnică. De exemplu, furnizorii de telecomunicații au mulți clienți. Ar fi ideal să actualizezi automat filtrele pentru fiecare client - să urmărești când apar o rețea nouă, când au închiriat rețeaua cuiva. Să urmărești acest lucru este greu, manual - și mai greu. De aceea, se folosesc pur și simplu filtre relaxate sau nu se folosesc deloc.
Excepții. Există excepții pentru clienți favoriți și mari. În special în cazul interconexiunilor între operatori. De exemplu, TransTelecom și Rostelecom au o grămadă de rețele și între ele există o interconexiune. Dacă interconexiunea cade - nu va fi bine pentru nimeni, de aceea filtrele sunt relaxate sau complet eliminate.
Informații învechite sau neactualizate în IRR. Filtrele sunt construite pe baza informațiilor care sunt înregistrate în IRR - Registrul Routing Internet. Acestea sunt registrele registratorilor internet regionali. Adesea, registrele conțin informații învechite sau neactualizate, sau uneori ambele.
Cine sunt acești registratori?
Toate adresele de pe internet aparțin unor organizații IANA - Autoritatea pentru Numere Atribuite Internetului. Când cumpărați o rețea IP de la cineva, nu cumpărați adresele, ci dreptul de utilizare a acestora. Adresele sunt un resurs nematerial și, printr-o convenție generală, toate acestea aparțin agenției IANA.
Sistemul funcționează astfel. IANA delegă gestionarea adreselor IP și a numerelor sistemelor autonome cinci registratorilor regionali. Aceștia emit sisteme autonome LIR - registratori locali de internet. Apoi, LIR-urile alocă adrese IP utilizatorilor finali.
Deficitul sistemului este că fiecare dintre registratorii regionali își ține registrele în modul său. Fiecare are propriile opinii despre ce informații ar trebui să conțină registrele, cine ar trebui sau nu ar trebui să le verifice. Drept urmare, se crează o confuzie, care există și acum.
Cum mai putem lupta împotriva acestor probleme?
IRR - calitate mediocră. E clar cu IRR - acolo e totul prost.
BGP-communities. Acesta este un anumit atribut care este descris în protocol. Putem atașa, de exemplu, o comunitate specială la anunțul nostru, astfel încât vecinul să nu trimită rețelele noastre altor vecini. Când avem un link P2P, schimbăm doar rețelele noastre. Pentru a ne asigura că un traseu nu ajunge accidental în alte rețele, atașăm o comunitate.
Comunitățile nu sunt tranzitive. Aceasta este întotdeauna o convenție între două părți, și acesta este dezavantajul lor. Nu putem atașa o comunitate oarecare, cu excepția uneia care este acceptată implicit de toți. Nu putem fi siguri că această comunitate va fi acceptată de toți și interpretată corect. De aceea, în cel mai bun caz, dacă te înțelegi cu uplink-ul tău, acesta va înțelege ce vrei de la el prin comunitate. Dar s-ar putea ca vecinul să nu înțeleagă, sau operatorul să-ți elimine eticheta, iar tu nu vei obține ceea ce ai dorit.
RPKI + ROA rezolvă doar o mică parte din probleme. RPKI este Infrastructura de Cheie Publică pentru Resurse — un cadru special pentru semnarea informațiilor de rutare. O idee bună pentru a obliga LIR-urile și clienții lor să păstreze o bază de date actualizată a spațiului de adresare. Dar există o problemă legată de aceasta.
RPKI este de asemenea un sistem ierarhic de chei publice. IANA are o cheie de la care se generează cheile RIR, iar de la acestea cheile LIR? prin care își semnează spațiul de adrese folosind ROA — Autorizații de origine a rutei:
— Vă asigur că acest prefix va fi anunțat în numele acestei autonome.
În afară de ROA, există și alte obiecte, dar despre ele vom vorbi altădată. Pare a fi o idee bună și utilă. Dar nu ne protejează de scurgeri în totalitate și nu rezolvă toate problemele legate de furtul prefixelor. De aceea, participanții nu se grăbesc să o implementeze. Totuși, deja de la mari jucători precum AT&T și mari IX-uri, există asigurări că prefixele cu înregistrare ROA invalid vor fi eliminate.
Poate că vor face acest lucru, dar până acum avem un număr enorm de prefixe care nu sunt semnate în niciun fel. Pe de o parte, nu este clar dacă sunt valide. Pe de altă parte, nu putem să le eliminăm implicit, deoarece nu suntem siguri dacă este corect sau nu.
Ce mai există?
BGPSec. Este o idee interesantă, creată de academicieni pentru rețeaua poneilor roz. Ei au spus:
— Avem RPKI + ROA — un mecanism de asigurare a semnăturii spațiului de adrese. Haideți să introducem un atribut BGP separat și să-l numim BGPSec Path. Fiecare router va semna anunțurile pe care le face către vecini cu propria sa semnătură. Astfel, vom obține un drum de încredere dintr-un lanț de anunțuri semnate și vom putea verifica acest lucru.
Teoretic este bine, dar în practică sunt multe probleme. BGPSec încalcă multe mecanisme existente BGP legate de alegerea next-hop-ului și gestionarea traficului intern/extern direct pe router. BGPSec nu funcționează până când 95% din participanții de pe piață nu-l implementează, ceea ce în sine este o utopie.
BGPSec se confruntă cu probleme mari de performanță. Pe hardware-ul actual, viteza de verificare a anunțurilor este de aproximativ 50 de prefixe pe secundă. Spre comparație: tabelul actual al internetului cu 700.000 de prefixe ar fi încărcat în 5 ore, timp în care s-ar schimba de încă 10 ori.
BGP Open Policy (BGP bazat pe roluri). O propunere recentă bazată pe modelul Gao-Rekford. Aceștia sunt doi cercetători care studiază BGP.
Modelul Gao-Rekford se bazează pe următoarele principii. Dacă simplificăm, în cazul BGP există un număr mic de tipuri de interacțiuni:
- Provider Customer;
- P2P;
- interacțiune internă, să zicem iBGP.
Pe baza rolului routerului, deja se pot aplica politici de import/export implicit. Administratorul nu trebuie să configureze liste de prefixe. Pe baza rolului convenit între routere și care poate fi setat, obținem deja unele filtre implicite. Acum, acesta este un draft care este discutat în IETF. Sper ca în curând să vedem acest lucru sub formă de RFC și implementare pe echipamente.
Furnizori mari de internet
Să luăm ca exemplu furnizorul CenturyLink. Este al treilea cel mai mare furnizor din SUA, care deservește 37 de state și are 15 centre de date.
În decembrie 2018, CenturyLink a avut o cădere pe piața din SUA timp de 50 de ore. În timpul incidentului, au fost probleme cu funcționarea bancomatelor în două state, numărul 911 nu a funcționat câteva ore în cinci state. De asemenea, a fost suspendată o loterie în Idaho. Comisia de Comunicații Federale din SUA investighează în prezent acest incident.
Cauza tragediei a fost o placă de rețea defectă într-un centru de date. Placa a eșuat, a trimis pachete incorecte și cele 15 centre de date ale furnizorului au căzut.
Pentru acest furnizor, ideea „prea mare pentru a cădea”. Această idee nu funcționează deloc. Poate fi luat orice jucător mare și poate fi doborât de o problemă minoră. În SUA, conectivitatea este încă bună. Clienții CenturyLink, care aveau rezervă, au plecat în masă la el. Mai apoi, operatorii alternativi s-au plâns de supraîncărcarea legăturilor lor.
Dacă ar cădea un „Kcell” ipotetic, întreaga țară ar rămâne fără internet.
Corporații
Probabil că internetul este susținut de Google, Amazon, Facebook și alte corporații? Nu, și ele îl afectează.
În 2017, la conferința ENOG13 din Sankt Petersburg Jeff Houston din APNIC a prezentat . În el se afirmă că ne-am obișnuit că interacțiunile, fluxurile de bani și traficul pe internet sunt verticale. Avem furnizori mici care plătesc pentru conectivitate unor furnizori mai mari, iar aceștia plătesc pentru conectivitate către tranzitul global.
În prezent, avem o structură orientată vertical. Totul ar fi bine, dar lumea se schimbă — jucătorii mari construiesc cabluri transoceanice pentru a-și construi propriile backbones.
Știre despre cablul CDN.
În 2018, TeleGeography a publicat un studiu care arată că mai mult de jumătate din traficul de pe internet nu mai este internet, ci backbones CDN ale marilor jucători. Acest trafic este legat de internet, dar nu mai este acea rețea despre care am vorbit.
Internetul se descompune într-un set mare de rețele slab interconectate.
Microsoft are propria rețea, Google are a sa, iar între ele există o intersecție slabă. Traficul care își are începutul în SUA circulă prin canale Microsoft peste ocean către Europa, ajungând în jurul CDN-ului, apoi se conectează la providerul dumneavoastră prin intermediul CDN-ului sau IX și ajunge la routerul dumneavoastră.
Centralizarea dispare.
Această forță a internetului, care îl va ajuta să supraviețuiască după un atac atomic, se pierde. Apar locuri de concentrare a utilizatorilor și a traficului. Dacă Google Cloud s-ar prăbuși, ar exista multe victime simultan. Parțial, am simțit acest lucru când Roskomnadzor a blocat AWS. Iar exemplul CenturyLink arată că pentru asta e suficient și un lucru mic.
În trecut, nu totul se împiedica și nu la toată lumea. În viitor, putem ajunge la situația în care, influențând un jucător important, putem sparge multe lucruri, în multe locuri și pentru mulți.
Statele
Următoarele sunt statele, și cu acestea se întâmplă de obicei așa.
Aici, Roskomnadzor nu este deloc un pionier. Practica shutdown-ului Internet este prezentă în Iran, India, Pakistan. În Anglia există un proiect de lege ce permite deconectarea internetului.
Orice stat mare dorește să aibă un întrerupător pentru a opri internetul fie complet, fie parțial: Twitter, Telegram, Facebook. Nu că nu înțeleg că nu vor reuși niciodată, dar foarte mult își doresc. Întrerupătorul este folosit, de obicei, în scopuri politice - pentru a elimina concurenții politici, sau atentatele sunt la orizont, sau hackerii ruși au spart din nou ceva.
Atacurile DDoS
Nu voi lua pâinea colegilor de la Qrator Labs, ei o fac mult mai bine decât mine. Au privind stabilitatea internetului. Iată ce au scris în raportul din 2018.
Durata medie a atacurilor DDoS scade până la 2,5 ore. Atacatorii încep să numere banii, iar dacă resursa nu cedează imediat, atunci o lasă repede în pace.
Intensitatea atacurilor crește. În 2018, am văzut 1,7 Tb/s în rețeaua Akamai, și acesta nu este limita.
Apar noi vectori de atac și se amplifică cele vechi. Apar noi protocoale expuse amplificării, noi atacuri asupra protocoalelor existente, în special asupra TLS și similare.
Cea mai mare parte a traficului provine de pe dispozitive mobile. Traficul de internet se mută către clienții mobili. Atât cei care atacă, cât și cei care se apără trebuie să știe cum să se ocupe de asta.
Nu există soluții fără vulnerabilități. Aceasta este ideea principală — nu există și nu va apărea o protecție universală care să prevină orice DDoS.
O sistem nu poate fi oprit, decât dacă nu este conectat la internet.
Sper că v-am speriat suficient. Să ne gândim acum la ce putem face în legătură cu asta.
Ce să facem?!
Dacă aveți timp liber, dorință și cunoștințe de limba engleză — participați în grupuri de lucru: IETF, RIPE WG. Acestea sunt liste de discuții deschise, abonați-vă la newslettere, participați la discuții, veniți la conferințe. Dacă aveți statut LIR, puteți vota, de exemplu, în RIPE pentru diverse inițiative.
Pentru oamenii obișnuiți — asta monitorizare. Pentru a ști ce s-a stricat.
Monitorizare: ce să verifici?
Ping obișnuit, și nu doar un control binar — funcționează sau nu. Înregistrați RTT-ul în istoric, pentru a observa ulterior anomalii.
Traceroute. Aceasta este o aplicație software pentru a determina rutele de livrare a datelor în rețelele TCP/IP. Ajută la identificarea anomaliilor și blocajelor.
Verificări HTTP pentru adrese URL personalizate și certificate TLS vor ajuta la descoperirea blocajelor sau a înlocuirii DNS pentru un atac, ceea ce este practic același lucru. Blocajele sunt adesea realizate prin înlocuirea DNS-ului și cu redirecționarea traficului către o pagină de eroare.
Dacă este posibil, verificați rezolvarea originii dvs. din diferite locuri, dacă aveți aplicații. Astfel, veți descoperi anomalii de interceptare DNS, cu care uneori se confruntă furnizorii.
Monitorizare: de unde să verifici?
Nu există un răspuns universal. Verificați din locurile de unde vine utilizatorul. Dacă utilizatorii sunt în Rusia — verificați din Rusia, dar nu vă limitați la aceasta. Dacă utilizatorii dvs. locuiesc în diferite regiuni — verificați din aceste regiuni. Dar cel mai bine este din întreaga lume.
Monitorizare: cu ce să verifici?
Am găsit trei metode. Dacă știți mai multe — scrieți în comentarii.
- RIPE Atlas.
- Monitorizare comercială.
- Rețeaua proprie de mașini virtuale.
Să discutăm despre fiecare dintre ele.
RIPE Atlas — este o cutie mică. Pentru cei care cunosc „Revizorul” autohton — este aceeași cutie, dar cu un alt autocolant.
RIPE Atlas — un program gratuit. Te înregistrezi, primești un router prin poștă și îl conectezi la rețea. Pentru că altcineva folosește proba ta, primești anumite credite. Cu aceste credite poți efectua singur anumite cercetări. Poți testa în diferite moduri: ping, traceroute, verificarea certificatelor. Acoperirea este destul de mare, multe noduri. Dar există nuanțe.
Sistemul de credite nu permite construirea de soluții de producție. Creditele nu sunt suficiente pentru cercetări permanente sau monitorizare comercială. Creditele sunt suficiente pentru o cercetare scurtă sau o verificare unică. Norma zilnică cu o probă este consumată de 1-2 verificări.
Acoperirea este inegală. Deoarece programul este gratuit în ambele direcții, acoperirea este bună în Europa, în partea europeană a Rusiei și în unele regiuni. Dar, dacă ai nevoie de Indonezia sau Noua Zeelandă, atunci totul este mult mai slab — este posibil să nu se adune 50 de probe pe țară.
Nu poți verifica http cu proba. Aceasta este cauzată de nuanțe tehnice. Promit că vor remedia problema în noua versiune, dar deocamdată nu se poate verifica http. Poți verifica doar certificatul. O verificare http poate fi efectuată doar pe un dispozitiv special RIPE Atlas, numit Anchor.
A doua metodă — monitorizarea comercială. Cu aceasta, totul este bine, pentru că plătești bani, nu? Îți promit zeci sau sute de puncte de monitorizare din întreaga lume, iar tablourile de bord sunt frumos desenate „din cutie”. Dar, din nou, există probleme.
Este plătit, uneori foarte. Monitorizarea prin ping, verificările din întreaga lume și numeroasele verificări http pot costa câteva mii de dolari pe an. Dacă bugetul permite și îți place această soluție — te rog.
Acoperirea poate fi insuficientă în regiunea de interes. Atunci când este verificat prin ping, se precizează maximum o parte abstractă a lumii — Asia, Europa, America de Nord. Sistemele de monitorizare rare pot detalia proba până la o anumită țară sau regiune.
Suport slab pentru teste personalizate. Dacă ai nevoie de ceva personalizat, nu doar un simplu „clic” pe url, atunci această problemă apare și ea.
A treia metodă — propria monitorizare. Este clasic: „Hai să scriem ceva de-al nostru!”
Monitorizarea proprie se transformă într-un produs software distribuit. Căutați un furnizor de infrastructură, analizați cum să-l distribuiți și să-l monitorizați - după toate, trebuie să monitorizăm monitorizarea, nu-i așa? Și mai aveți nevoie de suport. Gândiți-vă de zece ori înainte de a vă angaja în asta. Poate că e mai simplu să plătiți pe cineva care să o facă pentru dumneavoastră.
Monitorizarea anomaliilor BGP și atacurilor DDoS
Aici, resursele accesibile sunt și mai simple. Anomaliile BGP sunt detectate cu ajutorul unor servicii specializate precum QRadar, BGPmon.Acestea acceptă tabelul full view de la mai mulți operatori. Pe baza a ceea ce văd din partea diferitelor operatori, pot detecta anomalii, căuta amplificatoare și așa mai departe. De obicei, înregistrarea este gratuită - introduceți numărul autonomiei dumneavoastră, vă abonați la notificări prin e-mail, iar serviciul vă va alerta cu privire la problemele dumneavoastră.
În monitorizarea atacurilor DDoS, de asemenea, totul este simplu. De obicei, este bazat pe NetFlow și jurnale.Există sisteme specializate precum FastNetMon, module pentru Splunk.În ultimă instanță, există furnizorul dumneavoastră de protecție DDoS. Acesta poate primi și NetFlow, iar pe baza acestuia va alerta cu privire la atacurile îndreptate împotriva dumneavoastră.
Conclusions
Nu vă faceți iluzie - internetul se va rupe cu siguranță.Nu totul și nu pentru toată lumea, dar 14.000 de incidențe în 2017 sugerează că incidentele vor continua.
Sarcina dumneavoastră este să observați problemele cât mai devreme posibil.Cel puțin, nu mai târziu decât utilizatorul dumneavoastră. În plus față de faptul că este necesar să observați, aveți mereu un «plan B» de rezervă. Planul este strategia pe care o veți urma când totul se va prăbuși:operatori de rezervă, DC, CDN. Planul este o listă de verificare separată prin care verificați funcționarea a tot.
Planul ar trebui să funcționeze fără a implica ingineri de rețea, deoarece de obicei sunt puțini și ei doresc să doarmă.
Pe scurt, vă doresc o disponibilitate ridicată și o monitorizare verde. HighLoad++ Siberia 2019. să rezervați bilete. Vă așteptăm în Siberia!
Sursa: habr.com
