Jak w jak najszerszy sposób zaktualizować żywą, ruchliwą stronę www?

Wiele dobrych rad już.

Jak już ludzie wspominali, jeśli nie masz ani jednego punktu, łatwo jest po prostu wprowadzić zmiany poprzez aktualizację serwera aplikacji na raz. Ale to rzadko się zdarza, więc zignorujmy to i skupmy się na trudnych sprawach.

Zazwyczaj jest tam db, które jest wspólne dla wszystkiego innego. Oznacza to przestój całego systemu. Jak to zminimalizować?

Automatyka . Skrypt całego wdrożenia procedura. Obejmuje to (szczególnie) wszelkie zmiany schematu bazy danych. Dotyczy to (zwłaszcza) migracji danych pomiędzy wersjami schematu.

Kontrola jakości . Upewnij się, że są testy. Zautomatyzowane testy akceptacyjne (co użytkownik widzi i oczekuje z perspektywy logiki biznesowej / doświadczenia). Rozważ posiadanie kont testowych w systemie produkcyjnym, które możesz skryptować, aby przetestować działania tylko w trybie readonly. Jeśli nie współdziałasz z innymi systemami zewnętrznymi, rozważ zrobienie pisz też zajęcia. Być może trzeba będzie odfiltrować aktywność konta testowego w niektórych częściach systemu, zwłaszcza jeśli dotyczą one pieniędzy i księgowości. Liczniki fasoli denerwują się, z dobrych powodów, kiedy fasola nie pasuje.

Ćwiczyć . Wdrażaj w środowisku przejściowym, które jest jak najbardziej identyczne z produkcyjnym. Zrób to z wielkościami danych produkcyjnych i danymi produkcyjnymi. Musisz poczuć, jak długo zajmuje stół do alter. I musisz sprawdzić, czy alter table działa zarówno strukturalnie, jak i ze wszystkimi kluczami obcymi w rzeczywistych danych.

Jeśli masz ogromne ilości danych, zmiany schematu wymagają czasu. Może więcej czasu, niż możesz sobie pozwolić. Jednym z rozwiązań jest użycie stopniowych migracji danych , tak aby zmiana schematu była wypełniana danymi "ostatnimi" lub "bieżącymi"(powiedzmy jedno-lub trzymiesięcznymi) w czasie przestoju, a dane z pozostałych pięciu lat mogą wyciekać po ponownym uruchomieniu. Dla użytkownika końcowego rzeczy wyglądają ok, ale niektóre funkcje nie mogą być dostępne przez kolejne kilka godzin/dni / cokolwiek.

W pracy spędzamy pewien czas z kodem zamrożonym w środowisku testowym. Następnie po kilku tygodniach wypowiedzenia, zabieramy witrynę w piątek o północy, pracujemy przez całą noc, wdrażając i zatwierdzając, i umieszczamy ją w sobotę późnym rankiem. Statystyki ruchu pokazały nam, że był to najlepszy czas, aby to zrobić.

Jeśli masz zestaw obciążonych serwerów, będziesz mógł wziąć jeden po drugim offline oddzielnie i zaktualizować go. Brak przestojów dla użytkowników!

Mieć ładny, rozbrajający obraz i / lub stronę kopii zapasowej. Niektóre witryny implementują proste gry javascript, aby zająć cię podczas oczekiwania na aktualizację.

Np. fail whale.

- Adam

W ostatnim miejscu, w którym pracowałem, QA przeprowadzało testy w środowisku QA. Wszelkie poważne problemy zostaną naprawione, przetestowane i zweryfikowane przed wdrożeniem.

Po certyfikacji kompilacji przez QA, zespół wsparcia produkcji wypchnął kod do środowiska testowego, gdzie klient patrzy na witrynę i sprawdza, czy wszystko jest zgodnie z życzeniem.

Rzeczywiste uruchomienie produkcji odbywa się w godzinach poza godzinami pracy (po 21: 00, jeśli jest to nocne naciśnięcie awaryjne, lub od 5: 00. - 8.00, jeśli jest to normalnie zaplanowane uruchomienie).

Strona jest hostowana na wielu serwerach, które są równoważone za pomocą Load Balancer F5:

[[9]} kilka serwerów zostało usuniętych z produkcji,
• kod jest zainstalowany, a
• pobieżna kontrola jest wykonywana na serwerach przed umieszczeniem serwerów z powrotem w Puli.

Jest to powtarzane, dopóki wszystkie serwery nie zostaną zaktualizowane do najnowszego kodu i pozwoli witrynie pozostać w całości czas.

Ten proces jest idealny, ale zdarzają się przypadki, gdy baza danych wymaga aktualizacji. Jeśli tak jest, to istnieją dwie opcje, w zależności od tego, czy nowa baza danych zepsuje witrynę, czy nie.

Jeśli nowa baza danych jest niezgodna z istniejącym front endem, nie masz prawdziwego wyboru, jak tylko mieć okno czasu, w którym strona jest wyłączona.

Ale jeśli nowa baza danych jest zgodna z istniejącym front endem, nadal możesz wypchnąć kod bez żadnych rzeczywiste przestoje, ale wymaga to istnienia dwóch serwerów produkcyjnych baz danych.

• cały ruch jest kierowany do drugiego DB, a pierwszy serwer DB jest ściągany.
• pierwszy DB jest aktualizowany i po weryfikacji jest zakończona, umieścić z powrotem w produkcji.
• cały ruch jest kierowany do pierwszego DB, a drugi DB jest ciągnięty.
• drugi DB jest aktualizowany i po weryfikacji jest zakończona, umieścić z powrotem w produkcji.
• następnym krokiem jest wykonanie częściowych aktualizacji jak opisano powyżej.

Tak podsumowując:

• Kiedy wprowadzasz zmiany na aktywnej stronie internetowej, jak sprawdzić, czy system działa poprawnie?W najlepszym przypadku odbywa się to stopniowo.

• Jakich narzędzi używasz? ręczne sprawdzanie poprawności kodu wraz z podstawowymi testami automatycznymi przy użyciu dowolnego Narzędzia automatyzacji. Użyliśmy selenu IDE.

• Kto to robi? DBA wykonuje aktualizacje DB, wsparcie techniczne / Administratorzy systemu push / pull serwerów i instaluje kod, a QA lub wsparcie produkcyjne wykonuje testy Ręczne i / lub uruchamia testy automatyczne.

• Czy blokujesz dostęp do Witryny na okres testowy? jeśli to możliwe, należy tego unikać za wszelką cenę, zwłaszcza, jak Gilles wspomniał wcześniej, jeśli jest to płatna strona.

• Jaka ilość przestojów jest dopuszczalna? przestoje powinny być ograniczone do czasów kiedy użytkownicy będą najmniej skłonni do korzystania z witryny i powinny być wykonane w czasie krótszym niż 3 godziny.
  Uwaga: 3 godziny są bardzo hojne. Po ćwiczeniach i próbach, jak wspomniał jplindstrom, zespół będzie miał cały proces w dół i może wejść i wyjść w czasami mniej niż godzinę.

Mam nadzieję, że to pomoże!

Część z tego zależy od tego, czy aktualizujesz bazę danych. W przeszłości, jeśli DB był aktualizowany, usuwaliśmy witrynę na planowany (i opublikowany) okres konserwacji - zwykle coś naprawdę poza godzinami, gdzie wpływ był minimalny. Jeśli aktualizacja nie wiąże się z DB, to w środowisku zrównoważonym obciążeniem wyjmiemy 1 pudełko z mieszanki, wdrożymy i przetestujemy. Jeśli to się powiodło, weszło do miksu, a drugie pudełko (zakładając 2 pudełka) zostało wyciągnięte i zaktualizowane/Przetestowane.

Uwaga: Nie testujemy kodu, tylko to, że wdrożenie poszło gładko, więc czas przestoju był minimalny. Jak już wspomniano, kod powinien już przejść testy w innym środowisku.

IMHO długie przestoje (godziny) są dopuszczalne dla Darmowej Strony. Jeśli odpowiednio edukować użytkowników zrozumieją, że jest to konieczne. Może dać im coś do zabawy, dopóki strona nie wróci do góry (np. flash game, webcam live feed pokazujący zespół dev w pracy, itp.). W przypadku strony internetowej, za którą ludzie płacą, Wiele osób będzie marnować Twój czas na skargi, jeśli będziesz karmić je regularnymi przestojami. Uniknąłbym przestojów jak plaga i rozwijałbym aktualizacje naprawdę powoli i ostrożnie, gdybym prowadził usługę, która obciąża użytkowników.

W mojej obecnej konfiguracji mam drugą stronę podłączoną do tej samej bazy danych i pamięci podręcznej, co Kopia NA ŻYWO, aby przetestować moje zmiany.

Mam również kilka skryptów" page watcher " uruchomionych na zadaniach cron, które używają wyrażeń regularnych, aby sprawdzić, czy witryna prawidłowo renderuje kluczowe strony.

Odpowiedź brzmi: "to zależy". Po pierwsze, na rodzaj środowiska, które uwalniasz. Czy jest to strona typu "hello, world" na współdzielonym hostingu, czy google.com z pół miliona serwerów? Czy zazwyczaj jest jeden użytkownik dziennie, lub więcej jak kilka milionów? Publikujesz HTML / CSS / JPG, czy istnieje Duży owłosiony backend z serwerami SQL, serwerami średniego poziomu, rozproszonymi pamięciami podręcznymi itp.?

Ogólnie -- jeśli stać Cię na osobne środowiska do rozwoju, QA, inscenizacja i produkcja. Jeśli masz zasoby-Utwórz ekosystem, aby można było zbudować kompletny pakiet instalacyjny za pomocą jednego (jednego) kliknięcia. I upewnij się, że ta sama instalacja binarna może zostać pomyślnie zainstalowana w DEV/QA/STAGE/PROD jednym kliknięciem... Jest mnóstwo rzeczy napisanych na ten temat, i musisz być bardziej szczegółowy ze swoim pytaniem, aby uzyskać rozsądną odpowiedź

Uruchom główny serwer na porcie innym niż 80. Nginx) przed nim na porcie 80. Po aktualizacji witryny Uruchom inną instancję na Nowym Porcie. Test. Po upewnieniu się, że został poprawnie wdrożony, Edytuj plik konfiguracyjny serwera proxy i uruchom go ponownie. W przypadku nginx skutkuje to zerowym przestojem lub nieudanymi żądaniami, a także może zapewnić poprawę wydajności w porównaniu z bardziej typową opcją hostingu tylko Apache.

Oczywiście, to nie zamiast odpowiedniego serwera pośredniczącego, jest to jedynie "grzeczny" sposób wykonania przekazania przy ograniczonych zasobach.

Aby przetestować wszystko jak najlepiej na oddzielna strona dev przed uruchomieniem, używam Selenium (Tester stron www), aby przejść przez wszystkie nawigacyjne części serwisu, wypełnianie wartości w formularzach, sprawdzanie że wartości te pojawiają się w odpowiednich miejscach w wyniku, itp.

Jest wystarczająco potężny, aby sprawdzić dużo javascript lub dynamiczne też.

Potem znowu szybki przebieg z selenem po aktualizacja aktywnej witryny sprawdza, czy aktualizacja pracował i że nie ma brakujące linki lub błędy bazy danych.

Ratuje mnie kilka razy wyłapując subtelne błędy, które Przegapiłbym tylko ręczne przeskakiwanie.

Również, jeśli umieścisz witrynę na żywo za jakimś " odwrotnym proxy" lub load balancer (jeśli jest duży), co ułatwia przełączanie wróć do poprzedniej wersji, jeśli występują problemy.

Jedynym sposobem, aby uczynić go przejrzystym dla użytkowników, jest umieszczenie go za równoważonym obciążeniem proxy. Usuwasz jeden serwer podczas aktualizacji innego serwera. Następnie po zakończeniu aktualizacji umieszczasz tę, którą zaktualizowałeś online, a drugą usuwasz. Tak to robimy.

Jeśli masz jakąś wersję 'beta', nie rozwijaj jej na serwerze live. Jeśli masz "żywą, ruchliwą Stronę", są szanse, że ludzie będą na niej Walić i coś zepsuć.

To typowy wysoki konfiguracja dostępności, aby utrzymać wysoką dostępność, potrzebujesz minimum 3 serwerów. 2 live i 1 serwer testowy. Plus wszelkie dodatkowe serwery oter, jeśli chcesz mieć dedykowany DB lub coś.

Utwórz klasę hosta i wdroż swoją witrynę na tej klasie hosta. Przez klasę host mam na myśli zestaw hostów, w których ustawiane jest równoważenie obciążenia i łatwe dodawanie i usuwanie hostów z klasy.

Kiedy skończysz beta testy i będziesz gotowy do produkcji, nie musisz usuwać witryny, po prostu usuń jakiś host z klasy hosta produkcyjnego, dodaj go do nowej klasy hosta i wdroż tam swój najnowszy kod i przetestuj poprawnie. Gdy jesteś pewien, że wszystko działa dobrze przenieść wszystkie swoje host stopniowo do nowego i wskaż nową klasę hosta jako klasę hosta produkcyjnego. Możesz też użyć tego samego, którego używałeś początkowo, cała idea tego działania polega na upewnieniu się, że testujesz wdrożenie na polach produkcyjnych, gdzie Twoja witryna będzie działać po wdrożeniu, ponieważ problemy z wdrożeniem są przerażające i trudne do debugowania.