Ataki na centra danych Yandex zmiażdżyły ruch botów, ale niekoniecznie dezinformację

Ataki na centra danych Yandex wyłączyły dwa rosyjskie obiekty i uszkodziły trzeci w ciągu czterech dni. Cloudflare odnotował następnie spadek ruchu botów Yandex do 0,4% niedawnego maksimum.

Moment jest uderzający. Zgłaszane ukraińskie ataki dronów uderzyły w infrastrukturę Yandex w Sasowie, Kałudze i Włodzimierzu między 8 a 11 października. Yandex potwierdził uszkodzenia i przerwy w świadczeniu usług we wszystkich trzech lokalizacjach.

Jednak wiralowy wniosek wykracza poza dowody. Cloudflare mierzył zautomatyzowane żądania HTTP z sieci Yandex, a nie zweryfikowany wykaz rosyjskich kont wpływu. Ruch botów mogą generować roboty indeksujące wyszukiwarek, usługi monitorujące, aplikacje chmurowe i złośliwa automatyzacja.

To rozróżnienie zmienia narrację. Załamanie ruchu stanowi rzadki dowód na to, że fizyczne ataki zakłóciły internetową infrastrukturę Yandex. Nie dowodzi, że ukraińskie drony z dnia na dzień wyeliminowały rosyjskie boty dezinformacyjne.

Ataki na centra danych Yandex wyłączyły trzy obiekty

Trzy ataki w ciągu czterech dni doprowadziły do mierzalnej awarii fizycznej i sieciowej infrastruktury Yandex.

Sekwencja rozpoczęła się w nocy z 7 na 8 października. Atak dronów poważnie uszkodził centrum danych Yandex w Sasowie, w rosyjskim obwodzie riazańskim.

Yandex poinformował, że obiekt w Sasowie został całkowicie wyłączony. W swoim komunikacie firmowym opisał lokalizację jako poważnie uszkodzoną i nie podał terminu przywrócenia jej wyposażenia do działania.

Kolejny atak dotarł 9 października do centrum danych Yandex w Kałudze. Firma podała, że część infrastruktury uległa awarii, a kilka modułów centrum danych zostało całkowicie wyłączonych z eksploatacji.

Yandex nadal oceniał skalę szkód, gdy wydał to oświadczenie. Ostrzegł, że niektóre usługi mogą doświadczać zakłóceń, zgodnie z oświadczeniem dotyczącym Kaługi.

Trzeci atak uderzył w obiekt we Włodzimierzu w nocy poprzedzającej 11 października. Yandex zaktualizował swój rosyjskojęzyczny komunikat, podając, że centrum danych przestało działać.

Firma nie zgłosiła obrażeń wśród pracowników w trzech lokalizacjach. Nie umniejsza to jednak operacyjnych skutków utraty mocy obliczeniowej, pamięci masowej i przepustowości sieci w kilku regionach.

Zgłaszane ataki nie uszkodziły jedynie łatwo zastępowalnych budynków biurowych. Centra danych skupiają serwery, sprzęt sieciowy, systemy pamięci masowej, dystrybucję energii i chłodzenie w ściśle skoordynowanych obiektach.

Wyłączenie jednego obiektu może przenieść ruch do innego regionu. Utrata kilku lokalizacji w krótkim czasie wywiera znacznie większą presję na systemy przełączania awaryjnego, które przekierowują obciążenia po awarii.

Yandex prowadzi działalność znacznie szerszą niż sama wyszukiwarka. Jego infrastruktura obsługuje mapy, transport, rozrywkę, sztuczną inteligencję, aplikacje biznesowe oraz usługi chmurowe używane przez inne firmy.

Awaria we Włodzimierzu miała podobno dotknąć użytkowników w dziesiątkach rosyjskich miast. Problemy objęły też Kazachstan, Białoruś i Armenię, zgodnie z doniesieniami o regionalnych zakłóceniach.

Użytkownicy zgłaszali problemy z zamawianiem taksówek i dostępem do usług bankowych. Awarie te pokazują, jak zakłócenie działania chmury lub platformy może rozprzestrzenić się przez oprogramowanie, które nie nosi nazwy dostawcy infrastruktury.

Klienci chmurowi tworzą kolejną warstwę zależności. Firma może prowadzić własną aplikację, jednocześnie polegając na Yandex w zakresie mocy obliczeniowej, baz danych, pamięci obiektowej lub sieci działającej pod spodem.

Taki model zazwyczaj pozwala klientom uniknąć zarządzania fizycznymi serwerami. Podczas poważnej awarii dostawcy kilka niepowiązanych aplikacji może jednak przestać działać z powodu tej samej zależności.

Ataki wywołały zatem dwa powiązane zdarzenia. Przerwały usługi konsumenckie i biznesowe, a zarazem zbiegły się z poważnym spadkiem zautomatyzowanego ruchu opuszczającego sieci Yandex.

Drugie zdarzenie przyciągnęło większą uwagę międzynarodową, ponieważ wydawało się łączyć fizyczną infrastrukturę z operacjami wpływu w internecie. Taka interpretacja wymaga znacznie większej ostrożności, niż sugerowało wiele nagłówków.

Dlaczego wykres sieciowy stał się politycznym dowodem

Dramatyczny wykres przekształcił awarię infrastruktury w twierdzenie o rosyjskiej propagandzie, zanim badacze zidentyfikowali dotknięte nią boty.

Cloudflare Radar publikuje zagregowane pomiary oparte na ruchu obserwowanym w sieci Cloudflare. Jego publiczny wykres ruchu botów wskazuje AS13238 jako sieć obsługiwaną przez Yandex.

System autonomiczny, czyli AS, to zbiór tras internetowych zarządzanych zgodnie z polityką routingu jednej organizacji. AS13238 reprezentuje przestrzeń sieciową Yandex, a nie każde połączenie internetowe w Rosji.

Wykres pokazał gwałtowny spadek zautomatyzowanych żądań HTTP w okresie ataków. Doniesienia opisywały poziom jako około 57% dwutygodniowego maksimum po ataku w Sasowie.

Po kolejnych atakach odczyt spadł do około 0,4% tego maksimum. Zbieżność fizycznych uszkodzeń i spadku aktywności sieciowej stanowi mocny dowód operacyjnego zakłócenia.

Nie ujawnia jednak każdego programu odpowiedzialnego za te żądania. Klasyfikacja Cloudflare identyfikuje prawdopodobną automatyzację na podstawie charakterystyki żądań i ocen botów.

Robot indeksujący wyszukiwarki jest botem. Monitor strony internetowej jest botem. Botem może być również zautomatyzowany skaner bezpieczeństwa, scraper cen, integracja aplikacji lub złośliwy program testujący dane uwierzytelniające.

Yandex musi stale indeksować strony internetowe, aby utrzymywać indeks wyszukiwarki. Jego roboty automatycznie wysyłają żądania stron, co czyni je naturalnym źródłem znacznego ruchu botów.

Platformy chmurowe również generują żądania między maszynami. Systemy monitorujące sprawdzają dostępność, oprogramowanie pobiera dane przez interfejsy programowania aplikacji, a procesy działające w tle synchronizują informacje bez udziału człowieka.

Cloudflare wyjaśnia, że żądania otrzymujące niskie oceny botów są klasyfikowane jako prawdopodobnie zautomatyzowane. Jego klasyfikacja botów szacuje, czy żądanie wygenerowało oprogramowanie, czy człowiek.

System ten nie określa politycznego celu każdego żądania. Nie pokazuje też, czy żądanie doprowadziło do publikacji w mediach społecznościowych, manipulowało dyskusją lub rozpowszechniało propagandę.

Operacje dezinformacyjne często próbują upodobnić się do prawdziwych użytkowników. Ich operatorzy mogą kierować ruch przez przejęte komputery, usługi mieszkaniowych serwerów proxy, urządzenia mobilne lub infrastrukturę należącą do niepowiązanych dostawców.

Takie taktyki utrudniają przypisanie odpowiedzialności. Kampania kontrolowana z Rosji nie musi wysyłać każdego publicznego żądania bezpośrednio z adresu należącego do Yandex.

Odwrotnie, ruch pochodzący z sieci Yandex nie jest automatycznie powiązany z rosyjskim rządem. Yandex prowadzi usługi komercyjne z legalnymi użytkownikami, klientami, programistami i systemami zautomatyzowanymi.

Określenie „rosyjski ruch botów” jest technicznie uzasadnione, gdy oznacza zautomatyzowane żądania z sieci rosyjskiej firmy. Staje się mylące, gdy czytelnicy interpretują je jako zweryfikowaną aktywność kontrolowaną przez Kreml w mediach społecznościowych.

Żadne dowody na publicznym wykresie Cloudflare nie identyfikują operatorów, miejsc docelowych ani przekazów stojących za żądaniami. Wykres nie oznacza też tego ruchu jako dezinformacji.

Ta luka nie powstrzymała rozpowszechnienia silniejszej narracji. Dyskusje online szybko uznały spadek za dowód, że zniknęły farmy trolli, konta propagandowe lub profile powiązane politycznie.

Twierdzenie wydaje się wiarygodne, ponieważ Rosja ma udokumentowane operacje wpływu, a Yandex posiada znaczącą rosyjską infrastrukturę obliczeniową. Wiarygodność wciąż nie może jednak zastąpić przypisania odpowiedzialności.

Ciężar dowodu rośnie wraz ze szczegółowością wniosku. Ustalenie awarii sieci wymaga pomiarów ruchu. Ustalenie zniszczenia operacji wpływu wymaga dowodów dotyczących kont, treści, zachowań i infrastruktury.

Badacze musieliby połączyć dotknięte adresy Yandex ze skoordynowanymi kontami lub kampaniami. Musieliby również wykluczyć rutynową automatyzację wyszukiwania i chmury.

Dopóki taka praca się nie pojawi, wykres wspiera węższy wniosek. Ataki gwałtownie ograniczyły zautomatyzowany ruch pochodzący z sieci Yandex.

Odwrócenie ruchu botów Yandex jest realne, ale ograniczone

Odwrócenie dotyczy tego, co dowodzą liczby: fizyczne ataki zakłóciły cyfrową aktywność, podczas gdy najbardziej politycznie atrakcyjne wyjaśnienie pozostaje niezweryfikowane.

Infrastruktura internetowa zwykle wydaje się oderwana od geografii. Użytkownicy widzą aplikacje, wyniki wyszukiwania, pulpity chmurowe i interfejsy mobilne, a nie generatory, systemy chłodzenia i szafy serwerowe.

Załamanie ruchu botów Yandex odsłania fizyczną warstwę pod tymi usługami. Systemy zautomatyzowane nadal zależą od budynków z energią elektryczną, połączeniami światłowodowymi, chłodzeniem, częściami zamiennymi i przeszkolonym personelem.

Uszkodzenie jednego budynku nie zawsze powoduje widoczną publicznie awarię. Operatorzy rozdzielają obciążenia, przechowują kopie zapasowe i przygotowują alternatywne trasy sieciowe.

Trzy incydenty w ciągu czterech dni tworzą trudniejszy problem odzyskiwania sprawności. Zespoły muszą przywracać uszkodzone lokalizacje, jednocześnie przenosząc obciążenia i chroniąc pozostałą przepustowość przed przeciążeniem.

Pomiary Cloudflare są istotne, ponieważ pokazują zewnętrzny skutek. Komunikaty Yandex potwierdzają uszkodzenia obiektów, a wykres sieciowy rejestruje odpowiadającą im zmianę widoczną poza firmą.

To połączenie jest silniejsze niż każde z tych źródeł z osobna. Oświadczenie firmy może zaniżać skalę szkód, podczas gdy pojedyncza zmiana ruchu może mieć kilka przyczyn.

Sekwencja stanowi również naturalny test. Zautomatyzowany ruch spadł po pierwszym ataku, pozostawał ograniczony, a następnie zbliżył się do zera w okolicach trzeciej awarii.

Korelacja nie identyfikuje każdego dotkniętego obciążenia. Jednak moment wystąpienia zdarzeń czyni związek między atakami a spadkiem aktywności sieciowej bardziej przekonującym.

To, co się załamało, pozostaje kluczowym pytaniem. Robot indeksujący Yandex jest oczywistym kandydatem, ponieważ indeksowanie generuje duże wolumeny zautomatyzowanych żądań internetowych.

Jeśli aktywność robota indeksującego odpowiada za większość brakującego ruchu, bezpośredni skutek dotyczy indeksowania wyszukiwarki. Yandex mógłby wolniej odkrywać nowe strony i rzadziej ponownie odwiedzać istniejące.

Zmniejszyłoby to aktualność jego indeksu wyszukiwania. Mogłoby również wpłynąć na strony internetowe zależne od wykrywania przez Yandex w celu pozyskiwania ruchu w Rosji i na pobliskich rynkach.

Część brakujących żądań może pochodzić od klientów Yandex Cloud. Zautomatyzowane aplikacje biznesowe często komunikują się z zewnętrznymi usługami, wysyłają zapytania do stron internetowych lub uruchamiają zaplanowane zadania.

Inny ruch może obejmować narzędzia bezpieczeństwa, systemy reklamowe, gromadzenie danych, usługi sztucznej inteligencji lub nadużywającą automatyzację. Same publiczne dane Radar nie pozwalają rozdzielić tych kategorii.

Rozróżnienie ma znaczenie, ponieważ każda kategoria wywołuje inne konsekwencje. Wyłączony robot indeksujący wpływa na jakość wyszukiwania, podczas gdy awaria obciążenia chmurowego może przerwać działanie banku, sprzedawcy detalicznego lub usługi transportowej.

Złośliwy bot wyłączony z działania może poprawić sytuację docelowych stron internetowych. Wyłączony bot monitorujący może utrudnić wykrywanie awarii.

Wskaźnik 0,4% również wymaga kontekstu. Porównuje obserwowany poziom z maksimum w wybranym dwutygodniowym okresie, a nie z całym globalnym ruchem botów.

Nie oznacza to, że zniknęło 99,6% rosyjskich botów. Nie oznacza nawet, że 99,6% całej automatyzacji Yandex zostało trwale zatrzymane.

Pomiar opisuje żądania widoczne dla Cloudflare z wybranej sieci Yandex. Ruch spoza tej sieci, w tym automatyzacja u innych dostawców hostingu, pozostaje poza zakresem tego twierdzenia.

Odbudowa może również szybko zmienić wykres. Yandex może ponownie uruchomić usługi w innych lokalizacjach, ogłosić nowe trasy lub przenieść obciążenia do działających obiektów.

Szybkie odbicie wspierałoby pogląd, że spadek wynikał przede wszystkim z przeniesienia infrastruktury. Trwały spadek sugerowałby głębsze straty sprzętowe lub wolniejszą odbudowę operacyjną.

Żaden z tych wyników sam w sobie nie dowodziłby, czym zajmowała się automatyzacja. Do tego badacze potrzebują bardziej szczegółowej telemetrii niż zapewnia publiczny wykres ruchu.

Ostrożny wniosek nadal jest istotny. Krótka kampania przeciwko trzem centrom danych zakłóciła zautomatyzowaną obecność dużej firmy technologicznej w sieci.

Wynik ten pokazuje, jak skoncentrowana infrastruktura może przenosić fizyczne szkody na awarie wyszukiwania, chmury i aplikacji. Nie wymaga niepotwierdzonego twierdzenia o dezinformacji, by mieć znaczenie.

Szersza awaria wykraczała poza roboty sieciowe

Szersze ryzyko nie dotyczy jednej kategorii botów, lecz koncentracji kluczowych usług w niewielkiej liczbie obiektów.

Yandex przedstawia się jako codzienne narzędzie dla konsumentów i firm. Ludzie korzystają z jego systemów do wyznaczania tras, mediów, zakupów, komunikacji, przetwarzania w chmurze oraz uzyskiwania odpowiedzi na codzienne pytania.

Firma twierdzi, że z jej technologii korzystają setki tysięcy przedsiębiorstw. Jej infrastruktura może więc znajdować się kilka warstw poniżej usługi, z której — jak sądzi klient — korzysta.

Aplikacja do zamawiania przejazdów ilustruje tę zależność. Potrzebuje usług lokalizacyjnych, baz danych, systemów tożsamości, połączeń płatniczych oraz niezawodnej komunikacji między pasażerami a kierowcami.

Jeśli awaria współdzielonego centrum danych przerywa działanie kilku komponentów, aplikacja może stać się bezużyteczna, nawet gdy jej interfejs mobilny nadal się otwiera.

Ten sam wzorzec dotyczy bankowości i handlu detalicznego. Usługa skierowana do klienta może zależeć od baz danych w chmurze, pamięci masowej, uwierzytelniania lub usług sieciowych hostowanych przez Yandex.

Architektura chmurowa ma ograniczać te ryzyka dzięki redundancji geograficznej. Kopie danych i aplikacji mogą działać w oddzielnych strefach dostępności lub regionach.

Redundancja ma swoje ograniczenia. Zawodzi, gdy klienci przechowują kopie zapasowe u tego samego dostawcy, gdy kilka lokalizacji współdzieli zależności lub gdy przepustowość mechanizmów przełączenia awaryjnego nie może obsłużyć popytu.

Seria ataków dodatkowo skraca czas na odzyskanie sprawności. Inżynierowie mogą mieć niewiele okazji, by ustabilizować jeden incydent, zanim kolejny obiekt utraci przepustowość.

Ataki wywierają presję zarówno na Yandex, jak i jego klientów. Yandex musi przywracać sprzęt i usługi, jednocześnie decydując, jaką część mocy zarezerwować dla każdego obciążenia.

Klienci muszą ustalić, czy ich własne plany ciągłości działania rzeczywiście obejmują niezależne domeny awarii. Kopia zapasowa zależna od tej samej infrastruktury bazowej zapewnia ograniczoną ochronę.

Wydarzenie to testuje także strategie suwerenności danych. Rosyjskie firmy coraz częściej polegały na krajowych dostawcach, ponieważ sankcje i decyzje polityczne ograniczyły dostęp do części zachodnich technologii.

Krajowy hosting może spełniać cele regulacyjne lub polityczne. Może też koncentrować obciążenia u mniejszej liczby dużych dostawców i w mniejszej liczbie lokalizacji geograficznych.

Koncentracja nie jest zjawiskiem wyjątkowym dla Rosji. Poważna awaria dowolnego hiperskalowego dostawcy chmury może dotknąć firmy, które przed awarią wydawały się niepowiązane.

Kontekst militarny odróżnia ten incydent od innych. Fizyczna odporność centrów danych obejmuje teraz możliwość powtarzających się ataków dalekiego zasięgu, a nie tylko pożary, awarie sprzętu lub zakłócenia dostaw mediów.

To zagrożenie zmienia planowanie infrastruktury. Operatorzy potrzebują rozdzielenia geograficznego, niezależnego zasilania, zróżnicowanych tras sieciowych, zapasowego sprzętu oraz procedur odzyskiwania zakładających, że zawieść może więcej niż jedna lokalizacja.

Fizyczna ochrona może również stać się częścią tych kalkulacji. Jednak obrona każdego dużego obiektu przed dronami wiąże się ze znacznymi kosztami operacyjnymi i kosztami dla polityki publicznej.

Yandex nie ujawnił pełnej technicznej oceny szkód. Nie podał też wiążącego harmonogramu przywrócenia uszkodzonego sprzętu.

Takie braki są zrozumiałe w trakcie aktywnego odzyskiwania sprawności. Uniemożliwiają jednak zewnętrznym obserwatorom ocenę, jaka część mocy obliczeniowej zniknęła i które usługi otrzymały priorytet.

Doniesienia, że obiekt w Sasowie mieścił ważne systemy superkomputerowe, rodzą pytania dotyczące obciążeń związanych ze sztuczną inteligencją. Publicznie dostępne dowody nie pokazują jeszcze, czy projekty szkoleniowe utraciły dane, czy jedynie dostępność mocy obliczeniowej.

Współczesne szkolenie modeli AI może korzystać z punktów kontrolnych, które zapisują postęp modelu w określonych odstępach. Ich użyteczność zależy od miejsca przechowywania kopii i dostępności sprzętu zastępczego.

Uszkodzony klaster może opóźnić szkolenie bez zniszczenia bazowego modelu. Może również zmusić zespoły do przekierowania ograniczonej liczby akceleratorów z badań na potrzeby usług dla klientów.

Ta sama ostrożność dotyczy twierdzeń o YandexGPT lub innych produktach AI. Zakłócenia usług nie oznaczają automatycznie, że zniszczono wagi modeli, dane szkoleniowe lub dokumentację badawczą.

Potwierdzone jest coś bardziej bezpośredniego. Yandex utracił działalność operacyjną w Sasowie i Włodzimierzu, podczas gdy część infrastruktury w Kałudze przestała działać.

Firma przyznała, że przywrócenie sprawności będzie trudne, i nie potrafiła powiedzieć, kiedy uszkodzony sprzęt wróci do działania. Ta niepewność sprawia, że odporność infrastruktury — a nie propaganda — jest najwyraźniejszym problemem dla branży.

Trzy sygnały pokażą, co rzeczywiście się zmieniło

O tym, czy była to tymczasowa awaria, czy trwała strata strategiczna, zdecydują odbudowa ruchu, stabilność usług oraz niezależna analiza kampanii.

Pierwszym sygnałem jest wzorzec odbudowy dla sieci AS13238 i Yandex Cloud. Ruch godzinowy może pokazać, czy zautomatyzowane żądania wracają stopniowo, gwałtownie się przenoszą, czy pozostają na obniżonym poziomie.

Szybkie odbicie wskazywałoby, że Yandex skutecznie przekierował obciążenia lub przywrócił przepustowość. Osłabiłoby to twierdzenia, że ataki trwale wyeliminowały dużą operację internetową.

Powolna lub niepełna odbudowa wskazywałaby na głębsze ograniczenia infrastrukturalne. Wzmocniłaby wniosek, że kilka obiektów obsługiwało obciążenia, których nie można było szybko przenieść.

Obserwatorzy powinni porównać ruch botów z szerszą aktywnością HTTP. Jeśli oba wskaźniki wrócą jednocześnie, spadek prawdopodobnie odzwierciedlał ogólne przywracanie sieci, a nie odrębną operację polityczną.

Drugim sygnałem jest status usług Yandex w obszarach wyszukiwania, chmury, transportu i produktów dla firm. Stabilne przywrócenie działania niepowiązanych usług pokazałoby, że przepustowość przełączenia awaryjnego się utrzymuje.

Powtarzające się awarie sugerowałyby dalszą presję na współdzieloną infrastrukturę. Mogłyby również ujawnić zależności, które przed atakami pozostawały niewidoczne.

Klienci chmurowi powinni monitorować dostępność baz danych, pamięci obiektowej, mocy obliczeniowej i sieci regionalnej. Aplikacje konsumenckie mogą wrócić do działania, zanim głębsze usługi biznesowe odzyskają normalną wydajność.

Znaczenie mają również przyszłe ujawnienia Yandex. Harmonogramy odbudowy, zmiany przepustowości lub zapowiedzi przenoszenia obciążeń wyjaśniłyby techniczną skalę szkód.

Trzecim sygnałem jest niezależna analiza skoordynowanych kampanii internetowych. Badacze musieliby zidentyfikować konkretne klastry kont, które stały się nieaktywne podczas awarii.

Wiarygodne badanie powinno powiązać te konta z infrastrukturą Yandex na podstawie czegoś więcej niż zbieżności czasowej. Przydatne dowody mogłyby obejmować rejestry sieciowe, powtarzające się wzorce zachowań, wspólne treści lub wcześniej ustalone przypisanie kampanii.

Badacze powinni również sprawdzić konkurencyjne wyjaśnienia. Konta mogą wstrzymać aktywność z niepowiązanych powodów operacyjnych, przenieść się do innych dostawców lub działać dalej przez domowe serwery proxy.

Jeśli zidentyfikowane sieci wpływu zniknęły wraz z ruchem Yandex i pozostały nieobecne, silniejsze twierdzenie o dezinformacji zyskałoby poparcie. Jeśli aktywność w mediach społecznościowych toczyła się normalnie, twierdzenie to osłabłoby.

Pojawienie się tych dowodów może zająć tygodnie. Publiczne wykresy sieciowe pojawiają się szybko, podczas gdy odpowiedzialne przypisanie wymaga obserwacji obejmującej platformy i infrastrukturę.

Dla deweloperów i kupujących rozwiązania dla przedsiębiorstw praktyczna lekcja pojawia się wcześniej. Architektury wieloregionowe działają tylko wtedy, gdy regiony, sieci, kopie zapasowe i mechanizmy odzyskiwania unikają tych samych bazowych punktów awarii.

Zespoły powinny zmapować, które usługi zależą od jednego dostawcy, a następnie przetestować, co dzieje się, gdy kilka obiektów staje się jednocześnie niedostępnych. Dokumentacja powinna obejmować zależności od zewnętrznych aplikacji i systemów tożsamości.

Pracownicy wiedzy powinni także zachować rozróżnienie między pomiarem a jego interpretacją. Wykres ruchu botów mierzy automatyzację, podczas gdy twierdzenie o dezinformacji przypisuje tożsamość, cel i kontrolę polityczną.

Ataki na centra danych Yandex wyraźnie wywołały poważny wstrząs infrastrukturalny. Stworzyły też wyjątkowo widoczny eksperyment pokazujący, jak fizyczne szkody rozchodzą się w systemach chmurowych.

Kolejnym krokiem jest zdyscyplinowana obserwacja. Należy śledzić, czy ruch Yandex wraca, czy zależne usługi się stabilizują oraz czy badacze powiążą brakującą automatyzację z nazwanymi kampaniami. Do tego czasu odczyt 0,4% dokumentuje załamanie sieci, a nie zniknięcie rosyjskiej dezinformacji.