Spis treści:
Bezpłatny kurs Pythona ➞ Mini kurs dla początkujących i doświadczonych programistów. 4 ciekawe projekty w portfolio, komunikacja na żywo z prelegentem. Kliknij i dowiedz się, czego możesz nauczyć się na kursie.
Dowiedz się więcejMiędzynarodowe firmy IT czasami doświadczają nieoczekiwanych i katastrofalnych incydentów, które mogą prowadzić do długotrwałego przestoju usług, utraty danych lub, przeciwnie, nieautoryzowanego rozpowszechniania informacji online. W tym artykule przyjrzymy się pięciu poważnym incydentom, które pokazały podatność nawet najbardziej niezawodnych systemów.
Notion zablokowany z powodu skarg dotyczących phishingu
12 lutego 2021 r., od godziny 2:00 czasu moskiewskiego, Notion napotkał poważne problemy z dostępem. Użytkownicy, w tym wielu klientów korporacyjnych, nie mogli uzyskać dostępu do swoich danych. Sytuacja ta spowodowała znaczne niedogodności dla użytkowników, którzy polegają na Notion w zarządzaniu projektami i przechowywaniu informacji. Problemy z ładowaniem platformy podkreślają wagę niezawodności usług w chmurze dla firm.
W usuniętym już tweecie Notion zwrócił się do swoich obserwatorów z prośbą o pomoc w związku z problemami z Name.com, dostawcą hostingu dla domeny notion.so. Name.com odpowiedział, że aktywnie współpracuje z właścicielami domeny, aby jak najszybciej rozwiązać problem. Zespół Notion wyraził zdziwienie i ironicznie zapytał, gdzie dokładnie powinni kierować wiadomości.
Zespół Notion poinformował serwis TechCrunch o problemach z DNS Pojawiły się problemy, które są już prawie rozwiązane. Obiecali regularnie aktualizować status na swoim profilu na Twitterze.
Gdy odwiedzasz stronę internetową, Twoja przeglądarka wysyła żądanie do serwera DNS, który tłumaczy nazwę domeny na adres IP. Dzięki temu Twoje urządzenie może znaleźć serwer hostujący żądaną usługę. Proces tłumaczenia domeny na adres IP jest kluczowym krokiem w zapewnieniu szybkiego i wydajnego dostępu do zasobów internetowych. Prawidłowa konfiguracja DNS pomaga poprawić szybkość ładowania stron i ogólną wydajność witryny.
Notion zarejestrował domenę notion.so za pośrednictwem rejestratora Name.com. Jednak domeny kończące się na .so są zarządzane przez inną firmę, Hexonet. Hexonet działa jako pośrednik, łącząc domenę .so z rejestratorami takimi jak Name.com. Ta interakcja spowodowała awarię, która uniemożliwiła dostęp do platformy Notion.
Rzecznik Name.com, Jared Evie, potwierdził tę informację w e-mailu do TechCrunch.
Firma Hexonet otrzymała zgłoszenia o użytkownikach tworzących strony Notion w celach phishingowych. W rezultacie firma tymczasowo zawiesiła domenę Notion. Po tym incydencie zespoły z trzech firm połączyły siły, aby szybko przywrócić usługę. Obecnie opracowujemy nowe protokoły, aby zapobiec podobnym incydentom w przyszłości.
GitLab utracił bazę danych
W styczniu 2017 roku GitLab doświadczył poważnej utraty danych, która dotknęła użytkowników przez sześć godzin. Incydent spowodował utratę raportów o problemach, żądań ściągnięcia, danych użytkowników i komentarzy. Jednak repozytoria Git, wiki i lokalne instancje GitLab pozostały nienaruszone. Wszystkie dane, które użytkownicy dodali do bazy danych między 17:20 a 23:25 UTC, zostały utracone. Wsparcie techniczne musiało przywrócić utracone informacje z kopii zapasowej, co wymagało znacznego wysiłku i niemal ręcznej interwencji. Ten incydent podkreśla wagę regularnego tworzenia kopii zapasowych i solidnego zarządzania danymi, aby zapobiec podobnym incydentom w przyszłości.
31 stycznia 2017 roku, o godzinie 18:00 UTC, GitLab wykrył problem z zalewaniem bazy danych przez spamerów, którzy tworzyli liczne fragmenty kodu. Miało to negatywny wpływ na stabilność bazy danych. Zespół techniczny GitLab natychmiast zareagował na sytuację i rozpoczął aktywne działania mające na celu wyeliminowanie problemu.
O godzinie 21:00 UTC doszło do krytycznej sytuacji, w wyniku której GitLab zablokował wszystkie rekordy operacji w bazie danych. Doprowadziło to do całkowitego wyłączenia systemu.
Zespół techniczny serwisu pomyślnie rozwiązał pierwotny problem. Ich działania w zakresie rozwiązywania problemów spełniły oczekiwania użytkowników, co potwierdza ich profesjonalizm i kompetencje w zakresie obsługi klienta. Możesz być pewien, że serwis będzie nadal zapewniał wysokiej jakości wsparcie i ulepszał swoją funkcjonalność.
- Spamerzy zostali zidentyfikowani i zablokowani na podstawie adresu IP (ci, którzy lubią grać w Counter-Strike'a lub Quake'a w sieci z lat 2000, docenią to);
- Użytkownik korzystający z repozytorium jako sieci dystrybucji treści (CDN) został usunięty. Z tego powodu do systemu zalogowało się 47 000 adresów IP, co niemal spowodowało awarię bazy danych;
- Użytkownicy zostali usunięci z powodu spamu.
O godzinie 22:00 UTC GitLab wykrył poważne problemy z synchronizacją zawartości kopii bazy danych, co doprowadziło do znacznego opóźnienia w replikacji. Przyczyną tej awarii był gwałtowny wzrost liczby operacji zapisu, z którymi baza danych nie była w stanie sobie poradzić. Ta sytuacja wymaga uwagi, aby zoptymalizować działanie systemu i zapobiec podobnym awariom w przyszłości.
Zapis zawartości db2 był opóźniony o 4 GB, co uniemożliwiło synchronizację db2.cluster z innymi kopiami. W rezultacie klaster przeszedł procedurę samooczyszczania. Problem pogłębił się z powodu braku połączenia db2.cluster z db1 z powodu niskiego parametru ax_wal_senders, który ogranicza liczbę klientów replikacji. Próby ponownego uruchomienia PostgreSQL na db1 zakończyły się niepowodzeniem, a system odmówił uruchomienia. Po kilku próbach PostgreSQL w końcu się uruchomił, ale replikacja z db2.cluster zakończyła się niepowodzeniem, a klaster nadal się zawieszał. Aby rozwiązać ten problem, należy zmienić ustawienia replikacji i parametry konfiguracji PostgreSQL.
O godzinie 23:00 UTC programista GitLab podejrzewał, że kopia zapasowa bazy danych nie działa z powodu pustego katalogu PostgreSQL. Próbując rozwiązać problem, usunął katalog, ale omyłkowo zrobił to na serwerze głównym db1.cluster.gitlab.com zamiast w replice. Zanim zdał sobie sprawę ze swojego błędu, było już za późno: z 300 GB danych pozostało tylko około 4,5 GB. Incydent ten podkreśla znaczenie ostrożnego obchodzenia się z danymi i potrzebę regularnego monitorowania procesów tworzenia kopii zapasowych w systemach zarządzania bazami danych.
Firma została zmuszona do zamknięcia gitlab.com i powiadomienia użytkowników o problemie za pośrednictwem Twittera. To tymczasowe zawieszenie zostało wprowadzone w celu rozwiązania problemu i zapewnienia bezpieczeństwa danych użytkowników. Rozumiemy, że może to powodować niedogodności i dokładamy wszelkich starań, aby przywrócić platformę tak szybko, jak to możliwe. Śledź nasze konto na Twitterze, aby być na bieżąco z informacjami o stanie usługi.
Żadne z pięciu wdrożonych rozwiązań tworzenia kopii zapasowych nie zadziałało. W rezultacie zespół GitLab był w stanie przywrócić jedynie kopię zapasową utworzoną sześć godzin wcześniej. Podkreśla to wagę niezawodnych kopii zapasowych i konieczność regularnego testowania stanu systemów odzyskiwania danych.
W Google Cloud zabrakło miejsca
14 grudnia 2020 roku, około godziny 14:00 czasu moskiewskiego, nastąpiła awaria Google Cloud. Użytkownicy mieli problemy z dostępem do swoich dokumentów i nie mogli wysyłać e-maili w Gmailu. Na ekranie pojawił się komunikat: „Spróbuj odświeżyć tę stronę lub wróć za kilka minut. Przepraszamy za niedogodności”. Problemy trwały około godziny, wywołując oburzenie użytkowników i dyskusję na temat incydentu w mediach społecznościowych. Takie przerwy podkreślają wagę niezawodności usług w chmurze dla codziennej pracy i komunikacji.
Firma zgłosiła, że przyczyną przerwy w działaniu usługi był błąd systemu uwierzytelniania.
Dzisiaj, o godzinie 3:47 czasu pacyficznego (USA), w Google wystąpiła tymczasowa przerwa w działaniu systemu uwierzytelniania, która trwała około 45 minut. Przyczyną przerwy był problem z wewnętrznymi limitami pamięci masowej. O 4:32 problem został rozwiązany i wszystkie usługi Google znów działały online.
Według The Guardian przyczyną problemu była niewystarczająca ilość miejsca przydzielonych w wewnętrznych systemach firmy do usług uwierzytelniania. Oczekiwano, że system automatycznie zwiększy pojemność pamięci masowej na dane, ale tak się nie stało. Podkreśla to znaczenie efektywnego zarządzania zasobami w infrastrukturze IT, zwłaszcza w kontekście zapewnienia niezawodności i bezpieczeństwa usług.
Awaria w Google spowodowała szereg problemów dla użytkowników. Wielu miało trudności z włączeniem oświetlenia w urządzeniach Google Home, prowadzeniem spotkań w Google Meet i uczestnictwem w lekcjach w Google Classroom. Szczególnie krytyczna była sytuacja z autoryzacją w Slacku i innych usługach, do których dostęp był realizowany za pośrednictwem konta Google. Te awarie znacznie utrudniły pracę użytkowników i wpłynęły na ich codzienne funkcjonowanie.
Facebook* nie działał przez jeden dzień
Ostatnia awaria usług Facebooka nie jest pierwszą w historii firmy. 13 marca 2019 roku, około południa, Facebook, Facebook Messenger i Instagram doświadczyły globalnych przerw w działaniu, które trwały prawie cały dzień. Użytkownicy WhatsApp zgłaszali również problemy z wysyłaniem zdjęć, a użytkownicy Facebooka zobaczyli powiadomienie o tymczasowej awarii serwisu z powodu prac konserwacyjnych. Takie incydenty podkreślają potrzebę solidnych systemów i technologii, aby zapewnić płynne działanie popularnych platform społecznościowych.
Platforma zgłaszania błędów Facebooka była tymczasowo niedostępna, co utrudniało użytkownikom zgłaszanie problemów z usługą. Firma zaczęła informować o sytuacji za pośrednictwem Twittera, jednej z niewielu głównych platform społecznościowych, nad którymi nie ma kontroli. Około godziny 15:00 czasu moskiewskiego Facebook potwierdził problem i poinformował, że aktywnie pracuje nad jego rozwiązaniem. Firma zaznaczyła również, że awaria nie była związana z atakami DDoS.
W czwartek Instagram ogłosił na Twitterze, że wszystkie problemy techniczne zostały rozwiązane. Facebook później potwierdził tę informację, stwierdzając, że usługa znów działa w pełni.
Facebook przedstawił wyjaśnienie awarii, która miała miejsce 24 godziny temu. Oficjalnie przyczyną awarii serwisu społecznościowego były zmiany w konfiguracji serwera.
Wczoraj nastąpiła zmiana konfiguracji serwera, która spowodowała problemy z dostępem do naszych aplikacji i usług dla wielu użytkowników. Szybko rozwiązaliśmy wszystkie problemy, a nasze systemy są obecnie przywracane do działania. Przepraszamy za niedogodności i dziękujemy wszystkim za cierpliwość w tym czasie. Doceniamy Państwa lojalność i nadal pracujemy nad poprawą jakości naszych usług.
Przesyłanie wiadomości z Facebooka na Twittera jest ważnym aspektem integracji mediów społecznościowych. Udostępnianie treści z Facebooka na Twittera pozwala poszerzyć grono odbiorców i zwiększyć widoczność postów. Korzystanie z wielu platform do dystrybucji informacji pomaga zwiększyć zaangażowanie użytkowników i poprawić interakcję z grupą docelową. Udostępnianie postów z Facebooka na Twitterze pomaga w stworzeniu jednolitej strategii promocyjnej i przyczynia się do skutecznego marketingu w mediach społecznościowych.
AOL ujawnia dane dotyczące zapytań użytkowników
4 sierpnia 2006 roku AOL Research opublikował dane dotyczące 650 000 użytkowników swojego dostawcy Internetu. Na jednej z jej stron internetowych opublikowano skompresowany plik tekstowy zawierający 20 milionów słów kluczowych. Dane te były początkowo przeznaczone do badań wewnętrznych, ale ich publikacja wywołała szerokie oburzenie opinii publicznej i podniosła kwestie prywatności i bezpieczeństwa danych osobowych w internecie. Sprawa AOL stała się znaczącym przykładem wagi ochrony danych użytkowników i konieczności przestrzegania standardów etycznych w przetwarzaniu informacji.
7 sierpnia AOL przeprosił swoich użytkowników i usunął poufne dane ze strony. Jednak do tego czasu informacje te zdążyły już rozprzestrzenić się po internecie. Co ciekawe, AOL nie uznał tego incydentu za poważny problem, dopóki jeden z użytkowników nie napisał o nim na blogu. Sytuacja ta podkreśla wagę ochrony danych osobowych i świadomości potencjalnych zagrożeń w przestrzeni cyfrowej.
Wyciekła baza danych zawierała zapytania użytkowników z okresu od 1 marca do 31 maja 2006 r., powiązane z unikalnymi identyfikatorami użytkowników (user_id). Dane obejmowały historię i wyniki wyszukiwania, a także linki, na które klikali użytkownicy. Tego typu informacje mogą być interesujące w kontekście analizy zachowań użytkowników i optymalizacji wyszukiwarek.
Żądania powiązane z losowymi identyfikatorami użytkownika umożliwiają jednoznaczną identyfikację wielu użytkowników. Użytkownicy często wyszukują swoje imiona i nazwiska lub imiona i nazwiska osób, które znają, aby dowiedzieć się, jakie informacje na ich temat są dostępne online. W rezultacie wiele zapytań zawiera dane osobowe, takie jak imiona i nazwiska, adresy, numery ubezpieczenia społecznego i inne poufne informacje. Podkreśla to wagę ochrony danych osobowych i świadomości, że informacje publikowane w Internecie mogą być dostępne dla innych osób.
W styczniu 2007 roku magazyn Business 2.0 w CNNMoney umieścił ten incydent na liście „101 najgłupszych momentów w biznesie”, zajmując 57. miejsce. Sprawa ta stała się jaskrawym przykładem złego zarządzania i strategicznych błędów w biznesie, przyciągając uwagę zarówno specjalistów, jak i opinii publicznej.
Z powodu skandalu dyrektor ds. technicznych firmy zdecydował się zrezygnować.
Błędy są nieuniknioną częścią każdej ścieżki zawodowej, ale ich liczbę można znacznie ograniczyć, dogłębnie studiując swoją specjalizację. Na stronie Skillbox, w sekcji „Programowanie”, znajdziesz kursy opracowane przez doświadczonych specjalistów z wiodących firm IT. Głębokie szkolenie pod okiem profesjonalistów pomoże Ci szybko opanować niezbędne umiejętności i zwiększyć swoją konkurencyjność na rynku pracy.
