Jump to content
Sign in to follow this  
Myszaty.

DESTINY 2 – PRZERWA TECHNICZNA I PRZYWRÓCENIE DANYCH

Recommended Posts

Dziś (wtorek 11 lutego), po wypuszczeniu poprawki 2.7.1.1, doszły do nas informacje o powrocie błędu, który sprawił, że niewielki procent graczy stracił walutę i materiały. Po pierwszym wystąpieniu tego błędu 28 stycznia, po wypuszczeniu poprawki 2.7.1, które spowodowało, że gracze stracili gotówkę i materiały, przywróciliśmy stan kont graczy. W obliczu dzisiejszego incydentu podjęliśmy podobne kroki i przywróciliśmy konta do stanu z godziny 17:30 CET (czyli przed wypuszczeniem poprawki 2.7.1.1).
 

Ponieważ przyczyna i skutki w obu przypadkach są identyczne i ponieważ oba incydenty miały miejsce w krótkim odstępie czasu, chcemy przybliżyć wam, co poszło nie tak, jak naprawiliśmy błędy i w jaki sposób planujemy zadbać o to, by podobna sytuacja nie miała miejsca w przyszłości. Po pierwsze przyjrzyjmy się, co spowodowało problem: zawinił błąd gry związany z zarządzaniem ekwipunkiem i seria konfiguracji serwerowych, która spowodowała ponowne wprowadzenie owego błędu, choć został już wcześniej naprawiony.

ZARZĄDZANIE EKWIPUNKIEM

W Destiny 2 zadania są traktowane w podobny sposób co inne przedmioty w ekwipunku, takie jak waluta i materiały. Wszystkie przedmioty mają sygnaturę czasową – określa ona moment, w którym trafiły do ekwipunku gracza. Oznaczenie to jest wykorzystywane do sortowania zadań według czasu ich otrzymania. Po każdym logowaniu gra czyści ekwipunek gracza, tak aby był spójny z potencjalnymi zmianami dotyczącymi zawartości w grze, np. maksymalnej liczby przedmiotów danego typu, które można mieć w ekwipunku.
 
Kilka miesięcy temu gracze zgłaszali, że sortowanie zadań nie działa poprawnie, i chcieli, żebyśmy to naprawili. Nasz zespół zbadał problem i odkrył, że proces czyszczenia ekwipunku resetuje sygnatury czasowe części zadań, co zakłóca proces sortowania. Zdecydowaliśmy się to naprawić poprzez wyłączenie resetowania sygnatur czasowych zadań. Pomysł był dobry, ale jego realizacja wywołała pewne subtelne skutki uboczne i okazało się, że zbyt duża część procesu oczyszczania uległa dezaktywacji. W rezultacie gra obliczała zły limit posiadanych przedmiotów jednego typu (takich jak waluta i materiały), przez co przedmioty, które wykraczały poza limit, były tracone. Wiedzieliśmy, że ten fragment kodu ma szczególne znaczenie, i – zgodnie z naszymi procedurami – wyznaczyliśmy do jego sprawdzenia dwóch ekspertów. Niestety, nie udało im się dostrzec tego błędu.
 

Kilka dni później błąd wyłapany został przez nasz wewnętrzny zespół testerów. Niepoprawnie założyliśmy jednak, że powodowany jest przez funkcję narzędzi testerskich i nie będzie występował w standardowej wersji gry. I tak, umknąwszy naszej uwadze, problem pojawił się w łatce 2.7.1. Gdy został odkryty w grze, musieliśmy zdecydować, w jaki sposób go rozwiązać, co prowadzi nas do kolejnego etapu naszej dyskusji: serwerów i ich konfiguracji.

KONFIGURACJE SERWEROWE

Przed każdą większą premierą (np. przed Twierdzą Cieni) przeprowadzamy wyczerpujące testy wytrzymałościowe, próbując stworzyć model zachowania użytkowników i ustalić wpływ, jaki będzie ono miało na nasze serwery. Ponieważ nie da się jednak odtworzyć prawdziwego zachowania milionów graczy, w ramach uzupełnienia tych testów monitorujemy uważnie zachowanie serwerów tuż po premierze.
 
W październiku, aby uporać się ze zwiększonym zapotrzebowaniem na moc obliczeniową i liczbą graczy w okolicach premiery Twierdzy Cieni, uruchomiliśmy dodatkowe serwery (w tym przypadku nazwane WorldServers) – w sumie wykorzystywaliśmy więcej serwerów niż kiedykolwiek wcześniej. Obsługiwanie takiej liczby serwerów miało pewne skutki uboczne, które wyśledziliśmy, ale pozostawały one zwykle niezauważalne dla graczy. Przykładowo: niewielki odsetek (mniejszy niż 1 procent) tych serwerów ulegał awarii po uruchomieniu z powodu obciążenia zapasowych baz danych. Obejściem tego błędu było po prostu ręczne restartowanie serwerów za każdym razem, gdy wykrywaliśmy ten problem. Wydawało się, że rozwiązuje go to w sposób, który nie wywiera żadnego wpływu na graczy.
 
Teraz szybko przeskoczmy do sytuacji sprzed dwóch tygodni. Aktualizacja 2.7.1 wprowadzała wspomniany wcześniej błąd, który powodował uszkodzenie danych postaci i doprowadził do pierwszego w historii przywrócenia kopii zapasowej danych postaci. Aby szybko pozbyć się błędu, zaktualizowaliśmy serwery, zamiast ingerować w kod gry i wypuszczać jej zaktualizowany build. W tym celu zmodyfikowaliśmy jedno z ustawień serwera, tak aby lekceważył kod gry wykorzystywany do przetwarzania danych postaci, a następnie zrestartowaliśmy serwery WorldServers, aby zastosować tę zmianę. 
 
Kolejny przeskok, tym razem do dnia dzisiejszego (11 lutego), w którym wypuściliśmy aktualizację 2.7.1.1, związaną z rozpoczęciem Karmazynowych Dni. Niektóre z serwerów WorldServers ponownie uległy awarii z powodu jednoczesnego uruchomienia dużej ich liczby. Raz jeszcze zrestartowaliśmy te serwery i myśleliśmy, że wszystko jest w porządku. Myliliśmy się. 
 
Niespodziewanie dla nas awarie serwerów WorldServers sprawiły, że uprzednia poprawka błędu uszkadzającego dane nie została zaimplementowana. Oznaczało to, że niewielki odsetek serwerów WorldServers działał na starym kodzie i powodował błąd uszkadzający dane. Posiadamy systemy weryfikacji takich przypadków niedopasowania konfiguracji, ale błędy krytyczne serwerów WorldServers i ich ręczny restart sprawiły, że nie przeszły one również procesu weryfikacyjnego. Do dzisiejszego ranka uważaliśmy, że ominięcie zaimplementowania poprawki w konfiguracji serwerów i procesu weryfikacji jest niemożliwe.
 
W ramach standardowej procedury sprawdzania nowej wersji gry nasze zespoły testerskie logują się do Destiny za pomocą określonej liczby kont testowych, aby zweryfikować wrażenia gracza. Ponieważ w naszym środowisku dysponujemy setkami serwerów, każdy z testów, które wykonaliśmy, trafił akurat na prawidłowo działający serwer, omijając ten niewielki procent serwerów, na których błąd występował. Daliśmy więc sobie zielone światło.
 
Dzisiaj, gdy gra wystartowała po wypuszczeniu poprawki 2.7.1.1, gracze zaczęli zgłaszać nam utratę waluty. Zespół przystąpił do natychmiastowych testów i o godzinie 19:30 CET usługa Destiny została wyłączona. Do gry zdążyły się już zalogować – albo uzyskać dostęp do swoich postaci poprzez usługi zewnętrzne – setki tysięcy graczy. Nasze śledztwo ujawniło sytuację, o której myśleliśmy, że jest niemożliwa: niewielka liczba serwerów WorldServers została uruchomiona bez poprawnej konfiguracji, która rozwiązywała problem z aktualizacji 2.7.1. Niestety, wszyscy gracze, którzy uzyskali dostęp do swojej postaci za pośrednictwem jednego z uszkodzonych serwerów, napotkali problem z uszkodzonymi danymi postaci.
 

Po ustaleniu, że mamy do czynienia z tym samym błędem co 28 stycznia, i wyśledzeniu, w jaki sposób doszło do niego ponownie, nasz zespół uznał, że najlepszym sposobem na jego rozwiązanie będzie przywrócenie wszystkich danych postaci z kopii zapasowej, która została wykonana tuż przed wypuszczeniem poprawki 2.7.1.1 – gdybyśmy mieli identyfikować każde konto, którego dane zostały uszkodzone, mogłoby się to skończyć przegapieniem któregoś z nich. 

ŚRODKI ZAPOBIEGAWCZE

Zespół wprowadził kilka dodatkowych zabezpieczeń, które powinny sprawić, że ten konkretny błąd nie będzie się powtarzał w przyszłości. 
 
1) Wprowadziliśmy dodatkowe zabezpieczenie do procesu „aktualizacji na żywo” naszych serwerów, tak aby nie mogły uruchomić się w nieprawidłowej wersji. Zmiana ta wejdzie w życie już dzisiaj, gdy usługa Destiny zostanie ponownie włączona.
2) Naprawiliśmy problem, który powodował, że niewielka liczba serwerów WorldServers ulegała awarii po uruchomieniu. Poprawka ta zostanie zastosowana wraz z rozpoczęciem sezonu 10. 
3) W kolejnej aktualizacji wprowadzona zostanie permanentna poprawka błędu powodującego uszkodzenie danych postaci, dzięki czemu nadpisywanie konfiguracji stanie się niepotrzebne. (Niestety, z aktualizacją 2.7.1.1 sprawy zaszły już za daleko, by można było wprowadzić do niej tę poprawkę).
4) Szukamy właśnie sposobów na przyspieszenie mechanizmów przywracania kopii zapasowych i odzyskiwania danych.
5) W przyszłych aktualizacjach uporamy się z sytuacją, która pozwala serwerom na pomijanie etapu wczytania danych konfiguracyjnych.
6) Dodamy również zabezpieczenia do kodu czyszczącego konta w trakcie logowania, co powinno zapobiec występowaniu w przyszłości tak dokuczliwych błędów.
7) Wprowadzamy zmiany w naszym procesie produkcyjnym, aby zauważać tego typu błędy wcześniej. 
 
Dzisiejsze przywrócenie kopii zapasowej danych sprawi, że wszystkie postacie wrócą do stanu z godziny 17:30 CET. Zespół pracuje również nad poprawką 2.7.1.2, którą planujemy wydać 13 lutego. Ma ona także naprawić błąd związany z nieskończonym Ostrzem Świtu.
 
Wiemy, że dzisiejsza awaria oraz reset postaci jest dla was frustrujący, zwłaszcza, że zbiegło się to z premierą Karmazynowych Dni. Także jesteśmy sfrustrowani, albowiem zdajemy sobie sprawę, że jest to problem, któremu powinniśmy byli zapobiec. Przepraszamy za utrudnienia, które spowodowała ta sytuacja. Obecnie pracujemy nad tym, aby zapobiec podobnym incydentom w przyszłości. Jak zawsze, jeśli macie problem z grą Destiny, możesz skontaktować się z nami poprzez stronę Bungie Help i nasze konto Twitterze: @BungieHelp. Dziękujemy za waszą cierpliwość!
 
 
 
 
 
 

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...