Internet sembra una struttura forte, indipendente e inespugnabile. In teoria, la robustezza della rete dovrebbe essere sufficiente per sopravvivere a un'esplosione nucleare. In realtà, Internet può andare in tilt a causa di un piccolo router. Questo perché Internet è un accumulo di contraddizioni, vulnerabilità, errori e video di gattini. La base di Internet, il protocollo BGP, contiene un sacco di problemi. È sorprendente che sia ancora in funzione. Oltre agli errori all'interno di Internet, è anche soggetto ad attacchi da parte di chiunque: grandi provider di servizi Internet, corporation, stati e attacchi DDoS. Come si può affrontare tutto ciò e come si vive con questa situazione?
La risposta la sa Aleksej Učakin () è il leader del team di ingegneri di rete nella società IQ Option. Il suo compito principale è garantire la disponibilità della piattaforma per gli utenti. Nella sua presentazione durante parleremo di BGP, attacchi DDoS, interruttori di Internet, errori dei provider, decentralizzazione e casi in cui un piccolo router ha fatto addormentare Internet. Alla fine, qualche consiglio su come affrontare tutto questo.
Il giorno in cui Internet si è bloccato
Riporterò solo alcuni incidenti in cui la connettività di Internet è stata compromessa. Questo sarà sufficiente per avere un quadro completo.
«L'incidente di AS7007». La prima volta in cui Internet si è bloccato è stato ad aprile 1997. Nel software di un router del sistema autonomo 7007 c'era un errore. A un certo punto, il router ha annunciato ai vicini la propria tabella di routing interna e ha diretto metà della rete in un black hole.
«Pakistan contro YouTube». Nel 2008, i coraggiosi ragazzi del Pakistan hanno deciso di bloccare YouTube nel loro paese. Hanno fatto così bene che metà del mondo è rimasta senza gattini.
«Cattura dei prefissi VISA, MasterCard e Symantec da parte di Rostelecom». Nel 2017, Rostelecom ha erroneamente iniziato a pubblicizzare i prefissi di VISA, MasterCard e Symantec. Di conseguenza, il traffico finanziario è stato deviato attraverso canali controllati dal provider. La fuga di dati è durata poco, ma è stata sgradevole per le società finanziarie.
«Google contro Giappone». Nell'agosto 2017, Google ha iniziato a pubblicizzare su parte dei suoi uplink i prefissi dei principali provider giapponesi NTT e KDDI. Il traffico è stato inviato a Google come transitario, probabilmente per un errore. Poiché Google non è un provider e non accetta traffico di transito, una parte significativa del Giappone è rimasta senza Internet.
«DV LINK ha acquisito i prefissi di Google, Apple, Facebook, Microsoft». Nello stesso 2017, il fornitore russo DV LINK ha iniziato a pubblicizzare, per qualche motivo, le reti di Google, Apple, Facebook, Microsoft e di altri grandi operatori.
«eNet dagli USA ha acquisito i prefissi di AWS Route53 e MyEtherwallet». Nel 2018, un fornitore dall'Ohio o uno dei suoi clienti ha annunciato le reti di Amazon Route53 e del wallet crittografico MyEtherwallet. L'attacco è riuscito: nonostante un certificato autofirmato, il quale avvisava l'utente all'ingresso nel sito MyEtherwallet, molti wallet sono stati rubati e parte della criptovaluta è stata sottratta.
Solo nel 2017 ci sono stati oltre 14.000 incidenti di questo tipo! La rete è ancora decentralizzata, quindi non tutte le parti si rompono e non per tutti. Ma gli incidenti si verificano a migliaia e tutti sono correlati al protocollo BGP, su cui si basa Internet.
I problemi del BGP
Protocollo BGP - Border Gateway Protocol, descritto per la prima volta nel 1989 da due ingegneri di IBM e Cisco Systems su tre «tovaglioli» - fogli A4. Questi sono ancora custoditi presso la sede centrale di Cisco Systems a San Francisco come una reliquia del mondo delle reti.
Alla base del protocollo c'è l'interazione tra sistemi autonomi — Autonomous Systems o, in breve, AS. Un sistema autonomo è semplicemente un ID che ha assegnato nella registrazione pubblica delle reti IP. Un router con tale ID può annunciare queste reti al mondo. Di conseguenza, ogni percorso su Internet può essere rappresentato come un vettore chiamato AS Path. Il vettore è composto dai numeri dei sistemi autonomi che devono essere attraversati per raggiungere la rete di destinazione.
Ad esempio, c'è una rete composta da un certo numero di sistemi autonomi. È necessario passare dal sistema AS65001 al sistema AS65003. Il percorso da un sistema è rappresentato dall'AS Path nel diagramma. È composto da due autonomi: 65002 e 65003. Per ogni indirizzo di destinazione esiste un vettore AS Path, composto dai numeri dei sistemi autonomi da attraversare.
Quali sono quindi i problemi del BGP?
Il BGP è un protocollo di fiducia
Il protocollo BGP è basato sulla fiducia. Ciò significa che di default ci fidiamo del nostro vicino. Questa è una caratteristica di molti protocolli sviluppati alle origini di Internet. Vediamo cosa significa «fidarci».
Non c'è autenticazione del vicino. Formalmente esiste l'MD5, ma l'MD5 nel 2019 è …
Non c'è filtraggio. BGP ha dei filtri e sono descritti, ma non vengono utilizzati o vengono utilizzati in modo errato. Spiegherò più tardi perché.
È molto semplice impostare la vicinanza. La configurazione della vicinanza nel protocollo BGP su quasi qualsiasi router richiede solo un paio di righe di configurazione.
Non sono necessari diritti di gestione BGP. Non è necessario sostenere esami per convalidare le proprie qualifiche. Nessuno ti toglierà i diritti per configurare BGP in stato di ebbrezza.
Due problemi principali
Riconfigurazioni di prefissi - prefix hijacks. Il dirottamento di un prefisso è l'annuncio di una rete che non ti appartiene, come nel caso di MyEtherwallet. Abbiamo preso alcuni prefissi, abbiamo raggiunto un accordo con il fornitore o l'abbiamo violato, e attraverso di lui annunciamo queste reti.
Fughe di percorso - route leaks. Le fughe di percorso sono un po' più complicate. Una fuga è una modifica dell'AS Path. Nella migliore delle ipotesi, la modifica porterà a un aumento della latenza, perché sarà necessario passare attraverso un percorso più lungo o su un link meno capiente. Nella peggiore delle ipotesi, si ripeterà il caso di Google e Giappone.
Google stesso non è un operatore e non è un sistema autonomo di transito. Ma quando annunciò al suo fornitore le reti degli operatori giapponesi, il traffico attraverso Google è apparso come più prioritario nel AS Path. Il traffico è andato lì e è stato perso semplicemente perché le impostazioni di routing all'interno di Google sono più complesse rispetto a semplici filtri al confine.
Perché non funzionano i filtri?
A nessuno importa. Questa è la causa principale: a tutti non importa. L'amministratore di un piccolo fornitore o di un'azienda che si è connessa a un fornitore tramite BGP ha preso un MikroTik, l'ha configurato con BGP e nemmeno sa che ci sono filtri da configurare.
Errori di configurazione. Qualcosa è stato debuggato, si è sbagliato nella maschera, si è impostata la rete sbagliata, e voilà, di nuovo un errore.
Nessuna possibilità tecnica. Ad esempio, i fornitori di servizi hanno molti clienti. In modo intelligente, bisognerebbe aggiornare automaticamente i filtri per ogni cliente - monitorare che emerga una nuova rete, che abbiano affittato una rete a qualcuno. È difficile tenere traccia di tutto questo, a mano è ancora più difficile. Pertanto, si impostano semplicemente filtri rilassati o non si impostano affatto.
Eccezioni. Ci sono eccezioni per i clienti preferiti e grandi. Soprattutto nel caso di interconnessioni tra operatori. Ad esempio, TransTeleCom e Rostelecom hanno molte reti e un'interconnessione tra di loro. Se l'interconnessione si guasta, nessuno sarà contento, quindi i filtri vengono allentati o rimossi completamente.
Informazioni obsolete o non pertinenti in IRR. I filtri sono costruiti sulla base delle informazioni registrate in IRR - Internet Routing Registry. Questi sono i registri degli enti regionali di registrazione di internet. Spesso nei registri ci sono informazioni obsolete o non pertinenti, oppure entrambi.
Chi sono questi registratori?
Tutti gli indirizzi su internet appartengono all'organizzazione IANA - Internet Assigned Numbers Authority. Quando acquisti una rete IP da qualcuno, non stai acquistando gli indirizzi, ma il diritto di usarli. Gli indirizzi sono una risorsa immateriale e, per comune accordo, tutti appartengono all'agenzia IANA.
Il sistema funziona così. IANA delega la gestione degli indirizzi IP e dei numeri di sistema autonomi a cinque registratori regionali. Questi rilasciano sistemi autonomi LIR - registratori internet locali. Gli LIR poi assegnano indirizzi IP agli utenti finali.
Il difetto del sistema è che ognuno dei registratori regionali tiene i propri registri a modo suo. Ognuno ha la propria visione su quali informazioni dovrebbero essere contenute nei registri, chi dovrebbe o non dovrebbe verificarle. Di conseguenza, ne risulta un pasticcio come quello attuale.
Come si possono affrontare ulteriormente questi problemi?
IRR - qualità mediocre. Con l'IRR è chiaro: è tutto pessimo.
BGP-communities. Questo è un certo attributo descritto nel protocollo. Possiamo associare, ad esempio, una community speciale al nostro annuncio, affinché il vicino non invii le nostre reti ai propri vicini. Quando abbiamo un link P2P, scambiamo solo le nostre reti. Per evitare che un percorso venga accidentalmente inviato ad altre reti, associamo una community.
Le community non sono transitive. È sempre un accordo tra due, e questo è il loro difetto. Non possiamo associare alcuna community, tranne una che è accettata per default da tutti. Non possiamo essere certi che questa community venga accettata e interpretata correttamente. Pertanto, nel miglior caso, se concordi con il tuo uplink, lui capirà cosa vuoi da lui tramite la community. Ma il suo vicino potrebbe non capirlo, o l'operatore potrebbe semplicemente scartare il tuo tag, e non raggiungerai ciò che volevi.
RPKI + ROA risolve solo una piccola parte dei problemi. RPKI è Resource Public Key Infrastructure — un framework speciale per la firma delle informazioni di routing. È una buona idea per costringere i LIR e i loro clienti a mantenere un database attuale dello spazio indirizzi. Ma c'è un problema con questo.
RPKI è anche un sistema gerarchico di chiavi pubbliche. IANA ha una chiave da cui sono generate le chiavi RIR, e da esse le chiavi LIR? con le quali firmano il loro spazio indirizzi tramite ROA — Route Origin Authorisations:
— Garantisco che questo prefisso sarà annunciato a nome di questa autonomia.
Oltre ai ROA ci sono altri oggetti, ma di questo parleremo in seguito. Sembra una cosa buona e utile. Ma non ci protegge per niente dalle perdite e non risolve tutti i problemi con i furti di prefissi. Perciò i protagonisti non si affrettano a implementarlo. Anche se già da grandi attori come AT&T e grandi IX ci sono assicurazioni che i prefissi con registrazione ROA non valida saranno scartati.
Potrebbero farlo, ma al momento abbiamo un'enorme quantità di prefissi che non sono stati firmati in alcun modo. Da un lato, non è chiaro se sono validi per essere annunciati. Dall'altro, non possiamo scartarli per impostazione predefinita perché non siamo sicuri se sia corretto o meno.
Che cos'altro c'è?
BGPSec. È una cosa fantastica inventata dagli accademici per una rete di ponies rosa. Hanno detto:
— Abbiamo RPKI + ROA — un meccanismo di garanzia per la firma dello spazio indirizzi. Creiamo un attributo BGP separato e lo chiamiamo BGPSec Path. Ogni router firmerà con la propria firma gli annunci che comunica ai vicini. In questo modo otterremo un percorso fidato da una catena di annunci firmati che potremo verificare.
In teoria è bello, ma nella pratica ci sono molti problemi. BGPSec rompe molte meccaniche BGP esistenti per la scelta del next-hop e per la gestione del traffico in entrata/uscita direttamente sui router. BGPSec non funziona finché non viene implementato dal 95% dei partecipanti al mercato, il che è utopico.
BGPSec ha enormi problemi di prestazioni. Sull'hardware attuale, la velocità di verifica degli annunci è di circa 50 prefissi al secondo. Per confronto: l'attuale tabella di internet con 700.000 prefissi richiederebbe 5 ore, durante le quali cambierebbero ulteriormente 10 volte.
BGP Open Policy (BGP basato su ruoli). Una proposta fresca basata sul modello Gao-Rexford. Questi sono due studiosi che studiano BGP.
Il modello Gao-Rexford consiste nel seguente. Se semplificato, nel caso di BGP ci sono un numero ristretto di tipi di interazioni:
- Fornitore Cliente;
- P2P;
- interazione interna, ad esempio, iBGP.
Sulla base del ruolo del router, è già possibile applicare per default alcune politiche di importazione/esportazione. L'amministratore non deve configurare le liste di prefissi. Sulla base del ruolo, concordato tra i router, e che può essere impostato, otteniamo già alcuni filtri predefiniti. Al momento è una bozza che è in discussione in IETF. Spero che presto vedremo questo sotto forma di RFC e implementazione sull'hardware.
Grandi fornitori di Internet
Consideriamo l'esempio del fornitore CenturyLink. È il terzo fornitore più grande degli Stati Uniti, che serve 37 stati e ha 15 data center.
A dicembre 2018, CenturyLink è stato inattivo nel mercato statunitense per 50 ore. Durante l'incidente si sono verificate problematiche con i bancomat in due stati, e per diverse ore il numero 911 non ha funzionato in cinque stati. Inoltre, è stata interrotta una lotteria in Idaho. A causa di questo incidente, la Commissione per le comunicazioni degli Stati Uniti sta attualmente conducendo un'indagine.
La causa della tragedia è stata una scheda di rete in un data center. La scheda è andata fuori uso, inviava pacchetti non corretti e tutti i 15 data center del fornitore sono andati giù.
Per questo fornitore non ha funzionato l'idea «troppo grande per cadere». Questa idea in realtà non tiene. Si può prendere qualsiasi grande attore e farlo crollare per qualche motivo minore. Negli Stati Uniti la connettività è ancora sufficientemente buona. I clienti di CenturyLink che avevano riserve sono fuggiti in massa verso di lui. Poi gli operatori alternativi si sono lamentati del sovraccarico delle loro linee.
Se crollasse il condizionale "Kazakhtelecom", l'intero paese rimarrebbe senza Internet.
Corporazioni
Probabilmente Google, Amazon, FaceBook e altre corporation sostengono Internet? No, anche loro lo rompono.
Nel 2017, a San Pietroburgo, durante la conferenza ENOG13 Jeff Houston da APNIC ha presentato . In essa si parla del fatto che ci siamo abituati a che l'interazione, i flussi di denaro e il traffico su Internet siano verticali. Abbiamo piccoli fornitori che pagano per la connettività ai più grandi, che a loro volta pagano per la connettività al transito globale.
Ora abbiamo una struttura verticale-orientata. Tutto andrebbe bene, ma il mondo sta cambiando: i grandi attori stanno costruendo i loro cavi transoceanici per creare le proprie dorsali.
Notizia sul cavo CDN.
Nel 2018, TeleGeography ha pubblicato uno studio che più della metà del traffico su Internet non è più Internet, ma le dorsali CDN dei grandi attori. Questo traffico è legato a Internet, ma non è più quella rete di cui parlavamo.
Internet si sta frammentando in un grande insieme di reti poco collegate tra loro.
Microsoft ha la propria rete, Google ha la sua e tra loro si incrociano poco. Il traffico che è nato da qualche parte negli Stati Uniti si dirige attraverso i canali Microsoft oltre l'oceano verso l'Europa, dove si connette a un CDN, poi tramite il CDN o l'IX si interfaccia con il tuo fornitore e arriva al tuo router.
La decentralizzazione sta scomparendo.
Questa è una forza del web che lo aiuterà a sopravvivere dopo un'esplosione nucleare, ma si sta perdendo. Stanno nascendo luoghi di concentrazione di utenti e traffico. Se cade un ipotetico Google Cloud, ci saranno molti colpiti contemporaneamente. In parte lo abbiamo sentito quando Roskomnadzor ha bloccato AWS. E nell'esempio di CenturyLink si vede che bastano piccole cose per questo.
In passato non si rompeva tutto e non a tutti. In futuro potremmo arrivare a un punto in cui, influenzando un grande attore, si può rompere molto, in molti posti e per molte persone.
Stati
Il prossimo nella lista sono gli stati, e con loro di solito succede così.
Qui il nostro Roskomnadzor non è affatto un pioniere. Pratiche simili di shutdown di Internet sono in atto in Iran, India e Pakistan. In Inghilterra c'è un progetto di legge sulla possibilità di disconnessione di Internet.
Qualsiasi grande stato desidera avere un interruttore per disattivare Internet, sia completamente che parzialmente: Twitter, Telegram, Facebook. Non è che non capiscano che non ci riusciranno mai, ma lo desiderano molto. L'interruttore viene usato, di solito, per scopi politici: per eliminare i concorrenti politici, oppure in vista delle elezioni, o perché i hackers russi hanno di nuovo rotto qualcosa.
Attacchi DDoS
Non toglierò il pane ai compagni di Qrator Labs, lo fanno molto meglio di me. Hanno sulla stabilità di Internet. Ecco cosa hanno scritto nel rapporto del 2018.
La durata media degli attacchi DDoS scende a 2,5 ore. Anche gli attaccanti iniziano a contare i soldi, e se la risorsa non è stata assegnata subito, viene rapidamente lasciata in pace.
Aumenta l'intensità degli attacchi. Nel 2018 abbiamo visto 1,7 Tb/s sulla rete Akamai, e questo non è il limite.
Emergono nuovi vettori di attacco e si intensificano quelli vecchi. Emergono nuovi protocolli soggetti a amplificazione, compaiono nuovi attacchi a protocolli esistenti, specialmente su TLS e simili.
La maggior parte del traffico proviene da dispositivi mobili. Inoltre, il traffico internet si sta spostando verso i clienti mobili. È necessario saper gestire questa situazione sia per chi attacca che per chi si difende.
Non ci sono vulnerabilità. Questo è il messaggio principale: non esiste e non esisterà una protezione universale che protegga da ogni DDoS.
Non è possibile mettere fuori uso un sistema, a meno che non sia scollegato da internet.
Spero di avervi spaventato a sufficienza. Ora pensiamo a cosa fare.
Cosa fare?!
Se hai tempo libero, voglia e conoscenze di inglese, partecipa ai gruppi di lavoro: IETF, RIPE WG. Questi sono elenchi di posta aperti, iscriviti alle newsletter, partecipa alle discussioni, vieni alle conferenze. Se hai lo status di LIR, puoi votare, ad esempio, in RIPE per varie iniziative.
Per i comuni mortali, è monitoraggio. Per sapere cosa si è guastato.
Monitoraggio: cosa controllare?
Ping normale, e non solo un controllo binario — funziona o no. Registra il RTT nella storia, così da poter osservare anomalie.
Traceroute. Questo è un programma di utilità per determinare i percorsi dei dati nelle reti TCP/IP. Aiuta a identificare anomalie e blocchi.
Controlli HTTP: verifica custom URL e certificati TLS aiuteranno a scoprire blocchi o sostituzioni DNS per attacchi, che sono praticamente la stessa cosa. I blocchi vengono spesso eseguiti tramite sostituzione DNS e con l'inoltro del traffico a una pagina di sostituzione.
Se possibile, controlla la risoluzione del tuo origin dai tuoi clienti da luoghi diversi, se hai un'applicazione. In questo modo scoprirai anomalie di intercettazione DNS, di cui a volte sono colpevoli i fornitori.
Monitoraggio: da dove controllare?
Non esiste una risposta universale. Controlla da dove proviene l'utente. Se gli utenti si trovano in Russia, controlla dalla Russia, ma non limitarti a questo. Se i tuoi utenti vivono in diverse regioni, controlla da queste regioni. Ma è meglio farlo da tutto il mondo.
Monitoraggio: come controllare?
Ho ideato tre modi. Se ne conoscete altri, scrivete nei commenti.
- RIPE Atlas.
- Monitoraggio commerciale.
- La propria rete di virtualizzazioni.
Parliamo di ciascuno di essi.
RIPE Atlas — è una piccola scatola. Per chi conosce il locale «Revisore», è la stessa scatola, ma con un'etichetta diversa.
RIPE Atlas è un programma gratuito. Ti registri, ricevi a casa un router e lo colleghi alla rete. Per il fatto che qualcun altro utilizza la tua prova, ti vengono accreditati alcuni crediti. Con questi crediti puoi svolgere alcune ricerche. Puoi testare in vari modi: ping, traceroute, verificare i certificati. La copertura è abbastanza ampia, ci sono molte nodi. Ma ci sono delle eccezioni.
Il sistema di crediti non permette di costruire soluzioni di produzione. I crediti non bastano per ricerche continuative o monitoraggi commerciali. I crediti sono sufficienti per ricerche brevi o controlli una tantum. La norma giornaliera con una prova viene consumata in 1-2 controlli.
La copertura non è uniforme. Poiché il programma è gratuito in entrambe le direzioni, la copertura è buona in Europa, nella parte europea della Russia e in alcune regioni. Ma se hai bisogno dell'Indonesia o della Nuova Zelanda, la situazione è molto peggiore: può non essere possibile raggiungere 50 prove per paese.
Non è possibile controllare http dalla prova. Questo è dovuto a questioni tecniche. Promettono di risolvere il problema nella nuova versione, ma per ora non è possibile controllare http. Puoi solo verificare il certificato. Un qualche controllo http può essere fatto solo fino a un dispositivo speciale di RIPE Atlas, chiamato Anchor.
Il secondo metodo è il monitoraggio commerciale. Con questo va tutto bene, stai pagando, giusto? Ti promettono decine o centinaia di punti di monitoraggio in tutto il mondo, e ti forniscono dashboard attraenti "pronte all'uso". Ma, di nuovo, ci sono dei problemi.
Questo è a pagamento, a volte anche molto costoso. Il monitoraggio tramite ping, i controlli da tutto il mondo e numerosi controlli http possono costare diverse migliaia di dollari all'anno. Se hai la possibilità economica e ti piace questa soluzione, vai pure.
La copertura potrebbe non essere sufficiente nella regione di interesse. Lo stesso ping determina al massimo una parte astratta del mondo: Asia, Europa, Nord America. Alcuni sistemi di monitoraggio rari possono dettagliare la prova fino a un paese o una regione specifici.
Debole supporto per test personalizzati. Se hai bisogno di qualcosa di personalizzato, e non solo di un semplice “carlino” su url, ci sono dei problemi anche con questo.
Il terzo metodo è il tuo monitoraggio. È un classico: “Scriviamo il nostro!”
Il tuo monitoraggio si trasforma nello sviluppo di un prodotto software, e per di più distribuito. Cerchi un fornitore di infrastruttura, guardi come implementarlo e monitorarlo — il monitoraggio va monitorato, giusto? E poi c'è bisogno di supporto. Pensa dieci volte prima di intraprendere questa strada. Forse è più semplice pagare qualcuno che lo faccia per te.
Monitoraggio delle anomalie BGP e degli attacchi DDoS
Qui con le risorse disponibili è tutto più semplice. Le anomalie BGP vengono scoperte tramite servizi specializzati come QRadar, BGPmon. Loro accettano una full view-table da molti operatori. Sulla base di ciò che vedono da diversi operatori, possono scoprire anomalie, cercare amplificatori e altro ancora. Di solito la registrazione è gratuita — inserisci il numero della tua autonoma, ti iscrivi per le notifiche via email e il servizio ti avvisa dei tuoi problemi.
Nel monitoraggio degli attacchi DDoS è anche tutto semplice. Di solito, si tratta di NetFlow-based e log. Ci sono sistemi specializzati come FastNetMon, moduli per Splunk. In caso estremo, c'è il tuo fornitore di protezione DDoS. Puoi anche inviare a lui i NetFlow e sulla base di questo ti informerà sugli attacchi nella tua direzione.
Conclusioni
Non avere illusioni — Internet si romperà certamente. Non si romperà tutto e non a tutti, ma 14 mila incidenti nel 2017 suggeriscono che ci saranno incidenti.
Il tuo compito è notare i problemi il prima possibile. Almeno, non oltre il tuo utente. Oltre a notare, tieni sempre a disposizione un “piano B”. Il piano è la strategia su cosa fare quando tutto si rompa: operatori di riserva, centri di dati, CDN. Il piano è una lista di controllo separata, secondo la quale verifichi il funzionamento di tutto. Il piano deve funzionare senza coinvolgere ingegneri di rete, perché di solito ce ne sono pochi e vogliono dormire.
Questo è tutto. Ti auguro alta disponibilità e monitoraggio verde.
La prossima settimana a Novosibirsk è previsto sole, carico elevato e alta concentrazione di sviluppatori a . In Siberia si prevede un incontro di relazioni sul monitoraggio, la disponibilità e il collaudo, la sicurezza e la gestione. Si prevedono precipitazioni sotto forma di appunti scritti, networking, fotografie e post sui social media. Si consiglia di rimandare tutti gli impegni del 24 e 25 giugno e . Vi aspettiamo in Siberia!
Fonte: habr.com
