Wysyłanie do niektórych kont Sirv zawodzi, ze względu na problem z serwerem. Może to również uniemożliwić wyświetlanie obrazów sporadycznie. Pracujemy nad jak najszybszym rozwiązaniem tej kwestii.
resolved
Przyczyna problemu została zidentyfikowana i została w pełni rozwiązana. W tym okresie około 25% kont Sirv mogło doświadczyć niepowodzenia części plików. Pobieranie plików może się udać, ponieważ dotyczyło to tylko niewielkiej liczby wniosków. Obecnie odbywa się przegląd, a dalsze informacje zostaną dostarczone później.
Niektóre pliki i przetwarzanie obrazu nie powiodły się z powodu problemów z danymi
Początek 27 czerwca 2026 18:34 UTC · 14h 29m
OutagePoważny incydent
monitoring
Niewielka liczba usterek i żądań zwraca błędy z powodu wielu awarii przełącznika sieciowego w głównym datacentrum Sirva. Prośby CDN działają normalnie. Dokładnie monitorujemy sytuację i dostarczymy aktualizacje w miarę dostępności większej ilości informacji.
resolved
Wszystkie usługi wracają do normy, a wnioski są wypełniane.
resolved
Problem ten został spowodowany przez rdzeniową usterkę routera wpływającą na pierwotne centrum danych Sirv. Spowodowało to krótkie, przerywane przestoje na przechowywaniu plików i przesyłaniu plików, we wszystkich rodzajach transmisji: API, S3 i FTP. Sirv automatycznie przełączył się na usługę default-over, tak więc przetwarzanie i dostawa plików kontynuowano jak zwykle. Prośby CDN były również kontynuowane w normalnych warunkach. Wszystkie usługi zostały przywrócone, gdy datacentre usunął rdzeń routera.
Czas odpowiedzi dla niektórych wniosków w Niemczech jest wolniejszy niż zwykle, a niewielka liczba jest na czas. Sprawa jest badana.
resolved
Sprawa została rozwiązana. Jeden z serwerów obsługujących Niemcy był przeciążony i reagował wolniej niż zwykle. Serwer znów jest zdrowy. Sprawdzamy, jakie działania należy podjąć, aby zmniejszyć szanse na to ponownie.
Niektóre prośby z Kalifornii są powolne, a niewielka liczba (poniżej 2%) zawodzi. Jest to prawdopodobnie związane z nowymi serwerami CDN, które zostały dziś rozmieszczone w Los Angeles.
resolved
Sprawa została rozwiązana. Problem został spowodowany przez utratę pakietów wpływającą na nasze nowe dane z Los Angeles. Wpis danych śledził ten problem do ich dostawcy wyższego szczebla, Arelion, który doświadczył niestabilności sieci. Kwestia ta została rozwiązana, gdy Arelion został tymczasowo wyłączony jako dostawca wyższego szczebla, a ruch został przekierowany przez innych dostawców. W takich scenariuszach wymagamy, aby nasi agenci identyfikowali i przekierowywali ruch automatycznie i szybko. Rezolucja w tej sprawie nie była jednak wystarczająco szybka i biorąc pod uwagę, że nastąpiło to wkrótce po przyjęciu tego nowego wpisu, zdecydowaliśmy się zaprzestać jego stosowania. Cały ruch jest teraz przenoszony z naszego oryginalnego centrum danych w Los Angeles (od 7 kwietnia 2025).
Niektóre pliki nie uzupełniają się ze względu na problem z serwerem. Sprawa jest badana. Kwestia ta dotyczy niewielkiej liczby rachunków. Jeśli plik nie zostanie wysłany, proszę poczekać, aż problem zostanie rozwiązany.
identified
Kwestia ta jest nadal w toku. Zidentyfikowano przyczynę problemu i pracujemy nad jego jak najszybszym rozwiązaniem.
resolved
Sprawa została rozwiązana. Problem został spowodowany przez dwa serwery w jednym klastrze, które jednocześnie zawodzą. To wpłynęło na przesyłanie nowych plików do około 20% kont Sirv. Wysyłanie jest zaprojektowane tak, aby trwało normalnie, gdy jeden serwer jest w dół, ale kiedy dwa serwery są w dół, niektóre pliki mogą się nie udać, co się stało. Nie udało im się z powodu usługi eksportera, który przestał działać na jednym serwerze, a następnie na drugim serwerze. Błędy uniemożliwiły ponowne uruchomienie usług. Druga kwestia spowodowała, że rozdzielczość trwała dłużej, niż się spodziewano, ponieważ serwery nie mogły zostać zrestartowane. Było to spowodowane przestarzałym BIOS. Po aktualizacji BIOS, serwery zostały zrestartowane i przyczyna problemu została rozwiązana. Aby nie dopuścić do tego ponownie, wdrożyliśmy nowy proces zarządzania BIOS z naszym wejściem danych. Skrócamy również nasz cykl odświeżania sprzętu, dla częstszych aktualizacji sprzętu. Aby zmniejszyć szanse niepowodzenia usługi eksporter z powtarzających się, wyłączyliśmy proces i monitorujemy mierniki serwera.
Przez 3 minuty między 09: 29 a 09: 32 UTC niektóre wnioski nie zostały zwrócone. Kwestia ta dotyczyła tylko niektórych wniosków i tylko niektórych rachunków. Większość rachunków nie została naruszona.
resolved
Sprawa została rozwiązana w ciągu 3 minut. Przyczyną było ponowne uruchomienie wielu serwerów w tym samym czasie, podczas gdy tylko 1 serwer powinien być ponownie uruchomiony. To było przeoczenie w naszych standardowych procedurach operacyjnych. Badamy sposoby automatycznej ochrony i zapobiegania nawrotom.
Błąd serwera powoduje, że niektóre pliki nie powiodą się dla ograniczonej liczby kont. Sprawa została rozwiązana. W przypadku nieudanego wysłania, należy przerwać i spróbować ponownie później.
resolved
Sprawa została rozwiązana. Niezwykle duża liczba serwerów nie powiodła się jednocześnie. Sirv jest zaprojektowany, aby kontynuować normalne działanie podczas wyłączania serwera i wszystkie systemy kontynuowały jako normalne, ale niektóre pliki nie powiodły się. Zastanawiamy się nad możliwymi zmianami, jakie można wprowadzić, aby pomóc w takich sytuacjach w przyszłości.
Podwyższone 504 odpowiedzi dla wniosków o wysłanie API
Początek 14 listopada 2024 09:52 UTC · 18h 50m
IssuesDrobny incydent
investigating
Zwraca się zwiększoną liczbę 504 timeout dla żądań wysyłania plików API.
investigating
Nadal istnieje duże obciążenie API z żądań wysyłania. Czynnikiem przyczyniającym się do realizacji projektu jest duża liczba wniosków o zwiększenie skali obrazków ptasiej grypy, których przetwarzanie trwa dłużej niż zwykle. Opóźnienie spowodowane kolejką żądań powoduje niepowodzenie niektórych żądań wysyłania plików API z odpowiedzią 504.
resolved
Dokonano zmian, a problem jest prawie rozwiązany. Większość wniosków o wysłanie są skuteczne.
resolved
Przeładowanie API jest prawie w pełni rozwiązane.
resolved
Kwestia została w pełni rozwiązana. Problem rozpoczął się, gdy ciężkie uaktualnianie obrazu API żądań przeładować API, powodując niektóre wnioski API zwrócić 504 błędów. Zostało to rozwiązane, ale efekt knock- on spowodował około 5% wniosków API, aby nie udało się z 502 odpowiedzi. Aby zapobiec ponownemu wystąpieniu tego problemu, wprowadzono ulepszenia mające na celu zmniejszenie obciążenia skalowaniem obrazu i lepszą dystrybucję obciążenia. Wprowadza się również zmiany w zakresie logowania i ostrzegania, aby szybciej identyfikować takie scenariusze. Największy wpływ tego problemu był na wtyczkę Sirv WordPress. Wtyczka była wysyłanie wniosku API na wszystkich stronach admin, które zablokowały stronę od załadowania aż do otrzymania odpowiedzi - zazwyczaj mniej niż 300ms, ale do 20 sekund, jeśli API wymaga czasu. Te wnioski API nie były wymagane, więc nowa wersja wtyczki WordPress v7.3.3 została wydana na 1805 UTC (14 listopada) w celu usunięcia takich wniosków i zapobiec tej kwestii powtarzające się: https: / / wordpress.org / plugins / sirv / Ά-- Jeśli używasz API Sirv, zalecamy, aby skrypty zostały napisane, aby ponownie spróbować żądań, które otrzymują odpowiedź 502. Zalecenia dotyczące obsługi 502 i innych odpowiedzi na błędy przedstawiono tutaj: https: / / sirv.com / help / articles / sirv- rest- api / # error- handling- guide
Niektóre pliki nie są zwracane dla niewielkiej liczby kont. Kwestia ta jest pilnie rozpatrywana.
resolved
Sprawa została rozwiązana. Przy 1052 UTC, około 11% wniosków na niewielką liczbę rachunków (12 rachunków, z 50 000 +) zwróciło 404 odpowiedzi (nie znaleziono pliku), kiedy powinny zwrócić 200 odpowiedzi (OK). Kiedy zespół Sirv zidentyfikował problem, szybko pracowali nad jego rozwiązaniem i do 1206 UTC wszystkie takie wnioski były zwracanie normalnej 200 odpowiedzi. Problem ten miał miejsce z powodu błędnej konfiguracji przez inżynierów Sirv podczas konfigurowania nowego klastra pamięci. Niektóre prośby trafiały do nowego odłamka, zanim było gotowe je przyjąć. Zaklasyfikowany jako poziom ciężkości 3: niewielkie uderzenie.
Duża liczba wniosków do 25 lokalizacji CDN Sirv 'a zwraca błąd. Nasi inżynierowie pracują szybko, aby zidentyfikować i rozwiązać problem.
resolved
Sprawa została rozwiązana. Został on spowodowany przez awarię demona oprogramowania jednocześnie na wielu serwerach. Jest to lekki i wysoce wydajny menedżer usług, który nigdy nie zawiódł w przeszłości. W okresie od 3% do 58% wniosków HTTPS zwróciło błąd, w zależności od tego, który z 25 lokalizacji CDN otrzymał wniosek. Badamy teraz, dlaczego tak się stało i będziemy podejmować działania, aby zapobiec wpływowi na dostępność usług w przyszłości. Zaklasyfikowany jako poziom ciężkości 2: Znaczący wpływ.
Na CDN występuje podwyższony poziom 415 błędów. Nasi inżynierowie badają sprawę.
investigating
Kontynuujemy badanie przyczyn tej kwestii. Jego natura jest złożona. Przedstawia się jako błąd 415, z plików zero bajtów. Istnieje również podwyższony choć niższy wskaźnik 500 błędów. Większość wniosków to udane 200 odpowiedzi. Nasi inżynierowie ciężko pracują, by to zrozumieć i rozwiązać.
resolved
Problem 415 został spowodowany obcięciem niektórych plików, co oznacza, że stracili część zawartości. Pliki te pokazują w panelu kontrolnym my.sirv.com jako mające 0 bajtów. Pliki wysłane dziś były bardziej prawdopodobne, aby zostać obcięte, choć wydaje się, że obcinanie dzieje się z plikami od dłuższego czasu. Nie zostało to zidentyfikowane, ponieważ wykonywały one całkowicie jako normalne, ze względu na buforowanie wersji nieokrojonych. Okrojony plik stał się zauważalny dopiero dzisiaj, po modernizacji infrastruktury. Serwery zostały wyczyszczone, a okrojone wersje stały się widoczne. Przyczyną skrócenia jest prawdopodobnie błąd oprogramowania, który został rozwiązany. Obecnie pracujemy nad przywróceniem okrojonych plików - procesu, który może trwać od godzin do dni. Jeśli jesteś w stanie ponownie przesłać pliki, które nie są aktualnie ładowane, zrób to teraz. Szacuje się, że problem ten wpływa na około ~ 0.2% plików.
resolved
Około 80% okrojonych plików zostało odzyskanych. Liczba 415 błędów znacznie spadła, choć pozostają one wysokie. Aby w pełni rozwiązać problem, pozostałe okrojone pliki należy zastąpić oryginalnym. Pracujemy nad sposobami odzyskania tych pozostałych plików, choć trudno je uzyskać i może to trwać kilka godzin lub dni. W celu uzyskania jak najszybszej rozdzielczości zaleca się ponowne przesyłanie plików. Takie pliki będą wyświetlane na Twoim koncie jako mające 0 bajtów. Zacznij od następującego adresu URL, aby zobaczyć listę wszystkich plików przesłanych w ciągu ostatnich 30 dni: https: / / my.sirv.com / # / search /? created = 30d Znajdź jakiekolwiek pliki zero bajtów, sortując wyniki według Rozmiar, Wznosząc. Inna aktualizacja zostanie opublikowana tutaj, gdy będziemy mieli wiadomości o pozostałych plikach.
investigating
Kontynuujemy odzyskiwanie niewielkiej liczby pozostałych okrojonych plików. Szacuje się, że wymaga to kolejnych 12- 24 godzin. Jeśli masz jakieś pliki, które nie są obsługiwane, możesz to natychmiast rozwiązać, przesyłając je ponownie. Tworzymy narzędzie do generowania listy plików zero bajtów. Jeśli chcesz listę plików zero bajtów na koncie, prosimy o złożenie wniosku pod adresem https: / / sirv.com / help / support / # support i przygotujemy listę, gdy narzędzie będzie gotowe. Niezależnie od tego, będziemy kontynuować pracę, aby odzyskać wszystkie pliki. Jeśli wysyłasz pliki za pomocą funkcji Autofetch Sirv, możesz po prostu usunąć pliki zero bajtów i zostaną one ponownie pobrane ze zdalnej lokalizacji na następne żądanie.
resolved
Przywrócono więcej plików. Wskaźnik 415 błędów nadal spada. Możesz zobaczyć listę 415 błędów na tej stronie swojego konta: https: / / my.sirv.com / # / analytics / error / 415? from = 20231206 & to = 20231206 Możesz przesłać pliki, aby rozwiązać wszelkie 415 błędów w plikach. W razie potrzeby możemy dostarczyć listę plików zero bajtów - prosimy o kontakt z zespołem wsparcia Sirv za pośrednictwem tego formularza: https: / / sirv.com / help / support / # support Wciąż przywracamy jak najwięcej plików.
resolved
Problem, który spowodował podwyższony wskaźnik 415 błędów, został rozwiązany. Ocięte pliki były spowodowane przez program, który napisał kilka plików z zerem bajtów. Ponieważ było to oprogramowanie, spowodowało to replikację okrojonych plików we wszystkich wersjach pliku głównego. Sirv triplikuje każdy plik, aby chronić go przed problemami sprzętowymi (awarią serwera lub dysku twardego), jednak zaktualizowane pliki przekazywały wszystkie kontrole i wiernie tryplikowały pliki. Istniał bez wykrycia, ponieważ do przetwarzania i dostarczania plików wykorzystano wersje buforowe. Wszystkie systemy działały perfekcyjnie, aż do wczorajszej aktualizacji infrastruktury po oczyszczeniu plików. Przyczyna została rozwiązana przez identyfikację i korektę problemu oprogramowania, który spowodował skrócenie. Zostało to zakończone przez 1500 UTC w dniu 5 grudnia. Następnie zadaniem było przywrócenie plików, które zostały obcięte. Na całej platformie wpłynęło to na około 0,2% plików. Z tych plików udało nam się przywrócić między 95% a 100%, w zależności od konta. Wszelkie konta, które miały mniej niż 100% przywrócenia jest wysyłana lista zerobajtowych plików, które powinny być przywrócone poprzez załadowanie plików ponownie. Proszę zwrócić uwagę na nasz e-mail z listą plików. Prosimy o przesłanie nam wiadomości poprzez adres URL, jeśli potrzebujesz pomocy: https: / / sirv.com / help / support / # support Trwa szczegółowe dochodzenie w tej sprawie, które zostanie szczegółowo przedstawione pocztą elektroniczną. W sprawozdaniu znajdzie się wykaz działań podejmowanych w celu zapobieżenia ewentualnemu powtórzeniu tej kwestii, a także udoskonalenia i nowe funkcje, które są już opracowywane. Przepraszamy wszystkich klientów, którzy zostali dotknięci tą kwestią. Po raz pierwszy utracono dane. Wyciągniemy z niego każdą możliwą lekcję i uczynimy Sirva jeszcze silniejszym i niezawodnym niż wcześniej.
resolved
Ponad 99% pozostałych okrojonych plików zostało również przywróconych. Każdy dotknięty użytkownik otrzymał dokładną listę plików, które zostały dotknięte. Z tej kwestii nie ma już żadnych pozostałych skutków. Zaklasyfikowany jako poziom ciężkości 1: uderzenie krytyczne.
Od 0419 UTC, wysoki poziom 429 błędów został zwrócony z Sydney CDN lokalizacji.
resolved
Sprawa została rozwiązana w 1031 UTC. Przyczyną była błędna konfiguracja serwera, która sprawiła, że lokalizacja Sydney CDN widziała wszystkie żądania pochodzące z tego samego adresu IP, zamiast prawdziwego adresu IP klienta. Wywołało to ochronę DDOS, aby ograniczyć nadmierną liczbę wniosków z tego samego IP. Zwrócono 429 odpowiedzi na wiele wniosków. Problem ten wydawał się być niezwykle krótki, kiedy sieć danych Sydney stała się niedostępna. Ten problem trwał tylko około 1 minuty. Jednak faktyczny incydent rozpoczął się zaraz po tym, jak nasz zespół odbudował lokalizację Sydney CDN, czyli wtedy, gdy zastosowano błędną konfigurację serwera. Problem został rozwiązany, gdy odkryliśmy błąd konfiguracji i poprawiliśmy go. Podejmuje się wiele działań w celu zapobieżenia powtarzaniu się tej kwestii i zmniejszenia wpływu podobnych, ale różnych kwestii w przyszłości: - Dodatkowe monitorowanie i ostrzeganie
- Nowy formularz zgłoszeniowy
- Doradztwo dotyczące delikatnej rozdzielczości kontekstowej
- Szersze wewnętrzne ostrzeżenie Tylko położenie Sydney CDN zostało naruszone. Zaklasyfikowany jako poziom ciężkości 3: niewielkie uderzenie.
Około 1830 UTC 22 listopada, rozpoczęliśmy aktualizację do podstawowej bazy danych plików do nowego, potężniejszego klastra. Podczas gdy uaktualnienie miało miejsce, pytania API były nieskuteczne.
resolved
Na 1035 UTC w dniu 23 listopada, upgrade był kompletny i wyszukiwania wznowione normalne działanie. Nie było przestoju i wszystkie systemy funkcjonowały normalnie, z wyjątkiem tego, że żądania wyszukiwania API były zwracanie odpowiedzi błędów. Problem ten nie został zidentyfikowany, ponieważ inne wnioski API były zwracane jako normalne, więc całkowita odpowiedź API błędów była tylko nieznacznie podniesiona i nie wywołano żadnych wpisów. Kwestia ta została zidentyfikowana po zdarzeniu, po tym jak raport użytkownika wywołał dochodzenie. Aby automatycznie zidentyfikować takie kwestie w przyszłości, oceniamy sposoby monitorowania API wyszukiwania. Będziemy również aktualizować wtyczkę Sirv WordPress, aby pokazać wyraźnie opisane wiadomości w przypadku nieudanego wyszukiwania. Zaklasyfikowany jako poziom ciężkości 4: minimalne uderzenie.
Panel sterujący na my.sirv.com ładuje się wolniej niż zwykle
Początek 13 listopada 2023 20:47 UTC · 1d 17h
Pending
investigating
Narzędzia zarządzania plikami na my.sirv.com ładują powoli ze względu na nieudany serwer. Lista plików i wyszukiwanie plików trwa od 2 do 20 sekund, podczas gdy zwykle trwa od 1 do 4 sekund. Nieudany serwer zostanie zastąpiony i spodziewamy się, że prędkość powróci do normy w ciągu 72 godzin. Następnie w ciągu najbliższych 3 miesięcy nastąpi znaczna modernizacja całego zestawu serwerów panelu sterowania.
investigating
Czekamy na zaopatrzenie nowego serwera, aby dodać do klastra, a następnie prędkość nawigacji UI będzie znacznie szybciej.
resolved
Nowy serwer został uruchomiony wieczorem 14 listopada i stopniowo napełniał swoje cache. Panel sterujący powrócił do oryginalnej szybkiej wydajności. Dodatkowe serwery są obecnie uaktualniane, więc panel sterowania będzie ładować szybciej jeszcze w ciągu najbliższych 2 tygodni. Zaklasyfikowany jako poziom ciężkości 4: minimalne uderzenie.
W dniu 23 października o godz. 14: 10 doszło do znacznego wzrostu liczby wniosków dotyczących lokalizacji CDN w Waszyngtonie, co spowodowało powolne zwrócenie niewielkiej części wniosków - ponad 2 sekundy. Kwestia ta ustała w ciągu najbliższych 3 godzin, chociaż średni czas reakcji pozostał wydłużony. Problem powrócił następnego dnia o 14: 32 UTC w dniu 24 października, ciężej niż wcześniej powodując 17% wniosków o powolne ładowanie - więcej niż 2 sekundy, a niektóre nawet 30 sekund. Sprawa dotyczyła dwóch z 25 lokalizacji CDN Sirva.
resolved
Sprawa została rozwiązana 25 października 2006: 48 UTC. Dochodzenie wskazuje na dwie przyczyny - wzrost był spowodowany przez dostawcę DNS Sirv, który kierował żądania POP do Waszyngtonu. To byłoby w porządku w izolacji, ale datacentre wydaje się zahamować przepustowość serwerów odbierających, powodując powolne reakcje. Dochodzenie jest w toku, nie wyciągnięto jeszcze ostatecznych wniosków i wymaga współpracy z naszymi dostawcami DNS i danych. Podejmowane są już działania mające na celu zapobieżenie ewentualnemu powtórzeniu tej kwestii. W późniejszym terminie przedstawione zostanie w pełni szczegółowe sprawozdanie.
resolved
Szczegółowe dochodzenie w tej sprawie wykazało dwa czynniki przyczyniające się do jego powstania. Pierwszą z nich była aktualizacja do AWS Route53, która wydaje się być wdrożona przez AWS 17 października. Zmiana ta nie została dokonana przez Sirv do jej zasad Route53, ale zmiana w samej usłudze Route53. Los Angeles POP miało nieco inną logikę routingu niż inne POP, a aktualizacja AWS spowodowała, że routing zachowywał się inaczej, a ruch przekierowywał się do Waszyngtonu. Poszło to niezauważone, ponieważ wyższe obciążenie było nadal w jego pojemności i prośby zostały zwrócone pomyślnie, więc stało się niezauważone, ponieważ Waszyngton DC był w stanie obsłużyć dodatkowe obciążenie. Drugi czynnik przyczyniający się do tego wzrostu był wyższy niż normalny ruch podczas szczytowych godzin handlowych USA w dniach 23 i 24 października. Te dwa czynniki łącznie spowodowały, że twarde dyski Washington DC zwróciły wnioski znacznie wolniej niż zwykle. Od czasu wystąpienia tej kwestii podjęliśmy wiele działań, aby zapobiec jej powtarzaniu się; aby złagodzić podobne możliwe incydenty; oraz aby przyspieszyć proces restrukturyzacji i uporządkowanej likwidacji w przypadku incydentu. Działania obejmują: - Zastosowano nową logikę routingu.
- Pojemność Waszyngtonu wzrosła.
- We wszystkich innych lokalizacjach CDN zwiększyła się zdolność rezerwowa.
- Nowa tolerancja wprowadzona w celu usunięcia lokalizacji CDN z trasy.
- Dodatkowe monitorowanie dysków, aby pomóc we wczesnym przygotowaniu aktualizacji pojemności.
- Dyski są zamieniane na SSD.
- Aktualizacja SOP dla naszego zespołu wsparcia w celu zbadania i odpowiedzi na podobne problemy. Zaklasyfikowany jako poziom ciężkości 3: niewielkie uderzenie.
Wcześniejszy problem wysokiego wykorzystania wysyłania powróciło, z niewielką liczbą API przesłać niepowodzeniem.
resolved
Problem rozwiązał się w ciągu 9 minut po normalizacji wolumenu. W tym okresie udało się około 98% transmisji, a 2% nie. Wpisy do API REST są ograniczone na godzinę, do kwoty określonej na stronie użycia konta Sirv https: / / my.sirv.com / # / account / use. Jeśli używasz API REST do wysyłania obrazów, best- praktyka jest sprawdzanie odpowiedzi dla każdego żądania wysyłania, a jeśli otrzymasz odpowiedź błędu (400, 401, 429 itp.) następnie wstrzymać wysyłanie i ponownie spróbować później. Zobacz tutaj dokumenty: https: / / sirv.com / help / articles / sirv- rest- api / # error- handling- guide Zaklasyfikowany jako poziom ciężkości 4: minimalne uderzenie.
Niewielka liczba żądań wysyłania REST API jest niewystarczająca ze względu na bardzo duże obciążenie.
resolved
Problem ten rozwiązał się, gdy ładunek API zaczął spadać. W tym okresie udało się około 97% transmisji, a 3%. Wpisy do API REST są ograniczone na godzinę, do kwoty określonej na stronie użycia konta Sirv https: / / my.sirv.com / # / account / use. Jeśli używasz API REST do wysyłania obrazów, best- praktyka jest sprawdzanie odpowiedzi dla każdego żądania wysyłania, a jeśli otrzymasz odpowiedź błędu (400, 401, 429 itp.) następnie wstrzymać wysyłanie i ponownie spróbować później. Zobacz tutaj dokumenty: https: / / sirv.com / help / articles / sirv- rest- api / # error- handling- guide Zaklasyfikowany jako poziom ciężkości 4: minimalne uderzenie.
Jeden z serwerów CDN w Los Angeles stał się niezdrowy i zaczął zwracać błędy 4xx przy 0000 UTC. Został usunięty z trasy po 90 sekundach i w ciągu kolejnych 60 sekund, cały ruch był przenoszony na zdrowe serwery.
resolved
Kwestia została automatycznie rozwiązana w ciągu 3 minut. Zaklasyfikowany jako poziom ciężkości 4: minimalne uderzenie.
Niektóre prośby do londyńskiego POP Sirv CDN, zwracają błędy z powodu dużego obciążenia. Ten POP służy Wielkiej Brytanii i Irlandii. Pracujemy nad rezolucją.
resolved
Kwestia ta została rozwiązana i jest obecnie monitorowana.
resolved
Niektóre prośby otrzymane przez jeden z londyńskich serwerów CDN nie powiodły się ze względu na połączenie lokalnej rozdzielczości DNS i pulsujących timeout sieci. Problem rozpoczął się na 1215 UTC i został rozwiązany na 1332 UTC. W tym okresie 25% wniosków ze Zjednoczonego Królestwa i Irlandii zwróciło błąd 404 lub 500. Kwestia ta zostałaby rozwiązana wcześniej, ale niezwiązane z tym niepowodzenie walidacji certyfikatu SSL kilka godzin wcześniej zablokowane alarmy od otrzymania przez nasz system monitorowania. Wprowadzono już zmiany zapobiegające powtarzaniu się tej kwestii. Kwestia certyfikatu SSL została rozwiązana; skonfigurowano drugi poziom niezależnego monitorowania; testuje się dodatkową automatykę zdrowotną, która może automatycznie rozwiązać te problemy. Zaklasyfikowany jako poziom ciężkości 3: niewielkie uderzenie.
Sprawa została rozwiązana w 0755 UTC. Na 0625 UTC, niektóre wnioski do Indore CDN POP, który służy Indie zaczęły zwracać 404 odpowiedzi (plik nie znaleziono), zamiast 200 odpowiedzi (OK). Problem pojawił się 14 godzin po aktualizacji na wszystkich serwerach CDN na całym świecie. Wszystkie POP zachowywały się zdrowo, w tym indyjski POP, ale Indore POP nie zaktualizował się z powodzeniem i ostatecznie zaczął zwracać błędy. Po zidentyfikowaniu problemu został on rozwiązany poprzez ponowne przekazanie aktualizacji do indyjskiego POP. Podczas incydentu 94% wniosków zwróciło błąd. Wnioski do wszystkich innych krajów zostały zwrócone jako normalne. Aby zapobiec powtarzaniu się tej kwestii, tworzy się nową, zautomatyzowaną zasadę rozmieszczenia dla części procesu rozmieszczenia, w której przeprowadzono jedynie kontrolę na ludziach. Tworzy się również dodatkowy wskaźnik alarmowy w celu określenia sytuacji, w której rozmieszczenie nie powiodło się. Przepraszamy wszystkich klientów, którzy zostali dotknięci tym incydentem i oceniamy inne zmiany, które mogą zapobiec ewentualnym powtórzeniom tej kwestii. W przypadku wystąpienia takiego problemu CDN, jednym z natychmiastowych rozwiązań w Twojej kontroli jest tymczasowe wyłączenie CDN w ustawieniach Sirv tutaj: https: / / my.sirv.com / # / account / settings / domain Zaklasyfikowany jako poziom ciężkości 2: Znaczący wpływ.
