Kiedy najlepiej zaplanować regularne aktualizacje na wewnętrznym serwerze produkcyjnym?


9

Biorąc pod uwagę serwer wewnętrzny działający w trybie produkcyjnym, chciałbym ograniczyć wpływ na użytkowników podczas wdrażania regularnych aktualizacji (na samym serwerze, a nie na komputerach użytkowników… ale to byłby dość podobny problem).

Oczywista odpowiedź na moje pytanie brzmi: „w nocy, gdy użytkownicy są w domu”. Ale „noc” to długi okres. Czy należy zacząć wcześnie wieczorem, aby być może wcześnie wykryć problemy z aktualizacją i być gotowym do wycofania? A może lepiej zacząć wcześnie rano i użyć pierwszych użytkowników jako „świnek morskich”, aby szybciej wywołać problemy? A może w środku nocy, kiedy koncentracja osoby nadzorującej aktualizację jest dość niska, ale na pewno nie ma otwartych uchwytów plików niektórych późno pracujących użytkowników?

Czy są jakieś prace badawcze na ten temat?

Odpowiedzi:


5

Dlaczego nie spojrzeć historycznie na równoczesne korzystanie z systemu i ustalić, które pory dnia są najniższe? Następnie wklej swoją zmianę w środku tego niskiego okresu użytkowania.

Podczas ustalania, jak długo potrwa zmiana, należy uwzględnić testy przed / po wdrożeniu i testy weryfikacyjne produkcji. Ponadto określ, ile czasu zajmie przywrócenie zmiany, jeśli jakiekolwiek testowanie zakończy się niepowodzeniem.

IMHO twoimi „pierwszymi użytkownikami” nie powinny być świnki morskie. Posiadanie użytkowników na żywo w zasadzie testu weryfikującego produkcję, nie jest dobrą rzeczą. Niszczy zaufanie użytkowników końcowych, a nieoczekiwane wyniki mogą zepsuć produkcję, co oznacza, że ​​nie tylko musisz cofnąć zmianę, ale także cofnąć wszelkie „szkody”, które mogła spowodować zmiana.

Nie znam żadnych artykułów naukowych, ale spójrz na dowolne ramy zarządzania usługami IT (ITSM), takie jak ITIL, znajdziesz wiele standardów i najlepszych praktyk dotyczących zarządzania wydaniami oprogramowania. Wszystkie systemy są różne, więc zależy od tego, ile praktyk i jakie formalności zastosujesz. Standardy ITSM mają na myśli duże systemy.


standardy i najlepsze praktyki nie wypadają z powietrza, dlatego interesowały mnie „oryginalne” badania. ale i tak dzięki.
akira

Tak, zdaję sobie sprawę, że standardy nie pojawiają się znikąd; stwierdzając moją niewiedzę na temat prac badawczych w tej dziedzinie.
Nick Kavadias

5

Jest to całkowicie zależne od charakteru działalności. Niektóre biura pracują od 9 do 5 dni w tygodniu. Inne firmy działają 24 godziny na dobę, 365 dni w roku. Istotną rolę odgrywają inne czynniki, takie jak dostępność personelu i zasobów. Żaden artykuł badawczy nie byłby w stanie kompleksowo opisać każdego możliwego harmonogramu lub przypadku.

Ostatecznie kierownictwo firmy lub działu w porozumieniu z kierownictwem IT musi ustalić, co jest najlepsze.

Kluczem do sukcesu jest komunikowanie się z użytkownikami, kiedy zaplanowane jest rozpoczęcie przestoju, jak długo powinno ono trwać, wszelkie przygotowania użytkowników wymagane i czego mogą oczekiwać w wyniku sukcesu lub niepowodzenia. Duża część tego polega na spełnianiu ustalonych oczekiwań.

W końcu nic nie jest wyryte w kamieniu. Jeśli proces nie działa, wprowadź zmiany. Doceniona zostanie twoja elastyczność i zdolność adaptacji.

Wykonując procedury konserwacji i aktualizacji sprzętu testowego, jeśli to możliwe, będziesz lepiej przygotowany, jeśli przyjdzie czas na ich wdrożenie w systemach produkcyjnych.


williamson: badanie: można zmierzyć, ile ogólnej liczby administratorów dokonuje aktualizacji o danej porze dnia i czy napotyka więcej błędów rano lub wieczorem. nawet jeśli pewien administrator musi postępować tak, jak robi to w danym momencie, aby dopasować się do okoliczności firmy: jeśli badania wykazują, że znajduje się w strefie czasowej „błędu”, być może może nieco zmienić sytuację. byłem ciekawy, kiedy ludzie naprawdę robią aktualizacje, pierwsze 2 odpowiedzi wybrały dokładnie „wieczór” i „poranek” :)
akira

1
Zacznij od początku wynegocjowanego okna wyłączenia. To daje ci najwięcej czasu na naprawienie czegoś, co idzie nie tak.
mfinni

szczerze mówiąc, jest to rodzaj „głównie zdrowego rozsądku”, o którym często zapominamy wspominać.
mfinni

3

Pracuję u usługodawcy internetowego i z mojego doświadczenia wynika, że ​​większość osób, które uważam za administratorów systemu hitterów wybierają piątkowe wieczory w weekendy wakacyjne, aby dokonać poważnych przeglądów sieci. To daje im dodatkowe 24 godziny na przetestowanie i, jeśli to konieczne, wycofanie zmian. Jednak w dużym stopniu jest to całkowicie zależne od charakteru i nawyków użytkowników.


1
Zrobiliśmy to samo, kiedy pracowałem na uniwersytecie - wakacje oznaczały również, że ludzie byli mniej skłonni do przebywania w pobliżu, ale w zależności od rodzaju firmy może to mieć odwrotny skutek.
Joe H.

tak, ale tutaj dążę do „codziennych” aktualizacji. jeśli czas bezczynności wynosi 48 godzin ... to naprawdę jest to oczywisty wybór.
akira

@akira: nikt przy zdrowych zmysłach nie aktualizuje codziennie
Zypher

2

Instalujemy aktualizacje o 21.00, wystarczająco późno, aby większość ludzi nie była włączona, wystarczająco wcześnie, aby w razie potrzeby wyciągnąć wszystko.


2

W moim przypadku instalujemy aktualizacje o 4 rano, aby uniknąć wpływu na użytkowników, nawet tych, którzy pracują nieco później.

Jeśli masz dobry system monitorowania, który ostrzega w przypadku wystąpienia problemu, powinieneś być w stanie naprawić go wcześnie rano, nawet przed pójściem do pracy.


1

To zależy od charakteru twojej firmy, ale ja osobiście wolę środę wieczorem po 17:00. Nigdy nie chcesz tego robić w piątkowe wieczory, ponieważ jeśli coś pójdzie nie tak, będziesz pracował przez weekend. Wykonanie tego w środę da ci czwartek i piątek, aby rozwiązać ewentualne problemy.

Innym ważnym czynnikiem jest zaplanowanie okien zarządzania zmianami. Bardzo ważne jest, aby poinformować ludzi, że przeprowadzasz konserwację - aby usługi mogły zostać zakłócone lub niedostępne w tym okresie. Pozwoli ci to pracować z pewnością, zamiast martwić się, że użytkownicy będą narzekać na brak usług. Twoje kierownictwo musi oczywiście zatwierdzić okna zmian.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.