Kiedy bezpiecznie rozszerzyć pojemność serwera?
Pokażemy, kiedy rozszerzyć pojemność serwera, jakie sygnały należy mierzyć oraz kiedy proces, aplikacja lub baza danych są prawdziwym problemem w tle.
Short Answer
Pokażemy, kiedy rozszerzyć pojemność serwera, jakie sygnały należy mierzyć oraz kiedy proces, aplikacja lub baza danych są prawdziwym problemem w tle.
Jest poniedziałkowy poranek, magazyn chciałby otworzyć zamówienia, a obsługa klienta szuka faktur, ale system działa zauważalnie wolno. Pierwsza reakcja jest zazwyczaj zrozumiała: potrzeba więcej serwerów. Pytanie jednak nie brzmi, czy spowolnienie jest irytujące, ale kiedy rozszerzyć pojemność serwera tak, aby rzeczywiście rozwiązało to problem biznesowy, a nie tylko tymczasowo go ukryło.
Rozszerzenie pojemności jest często uzasadnione. Rozwijający się sklep internetowy, nowa lokalizacja, produkcja na kilka zmian lub zwiększony ruch klientów to rzeczywiste obciążenie. Jednak często serwer jest tylko miejscem, gdzie widoczny jest objaw źle działającego procesu, wolnego zapytania lub błędnego połączenia systemowego. W takich przypadkach większa infrastruktura przynosi dodatkowe koszty, podczas gdy opóźnienia, błędy i niepewność pozostają.
Wolny system to jeszcze nie brak pojemności
Kiedy czas odpowiedzi aplikacji biznesowej się pogarsza, warto najpierw dokładnie określić, co jest wolne, kiedy i dla kogo. Nie jest obojętne, czy cały system jest obciążony, czy tylko raport przygotowywany na koniec miesiąca trwa dwadzieścia minut. Nie jest też obojętne, czy wszyscy użytkownicy odczuwają problem, czy tylko ci, którzy korzystają z określonego raportu, funkcji magazynowej lub panelu administracyjnego sklepu internetowego.
W firmie handlowej zatrudniającej 80 osób na przykład przetwarzanie zamówień może być opóźnione po południu. Może to wynikać z faktu, że wtedy masowo napływają zamówienia z e-sklepu. Może to być również spowodowane tym, że w tym samym czasie proces w tle przelicza cały zapas, podczas gdy zewnętrzne połączenie logistyczne ponownie próbuje przekazać już przetworzone dane. Obie sytuacje wymagają innej interwencji.
Wykorzystanie CPU serwera, pamięci i przestrzeni dyskowej to ważne dane, ale same w sobie nie wystarczą. Maszyna może wydawać się spokojna, podczas gdy użytkownicy czekają z powodu blokad bazy danych. Odwrotnie też: obciążenie procesora może być krótkotrwale wysokie, podczas gdy proces biznesowy działa bez zakłóceń. Infrastruktura powinna być oceniana nie na podstawie jednego wskaźnika technicznego, ale na podstawie rzeczywistego działania usługi.
Jakie sygnały uzasadniają rozszerzenie pojemności serwera?
Rozszerzenie pojemności jest uzasadnione, jeśli dane pomiarowe i doświadczenie biznesowe wskazują na to samo. Jeśli system wielokrotnie osiąga lub trwałe zbliża się do granic dostępnych zasobów, problem nie jest związany tylko z jednym wyjątkowym zdarzeniem, a obciążenie prawdopodobnie będzie rosło, rozszerzenie może być krokiem zapewniającym niezawodność.
Sytuację należy traktować szczególnie poważnie, jeśli regularnie pojawiają się poniższe wzorce:
- procesor, pamięć, operacje dyskowe lub połączenie sieciowe są trwałe nasycone w godzinach szczytu;
- czas odpowiedzi bazy danych rośnie, zapytania i transakcje czekają;
- kopie zapasowe, synchronizacje lub zadania przetwarzania już wkraczają w czas pracy;
- system staje się nieprzewidywalny podczas nowego klienta, kampanii, zmiany produkcyjnej lub sezonowego okresu;
- dla krytycznej usługi z punktu widzenia działalności nie ma istotnej rezerwy na wypadek awarii, aktualizacji lub szczytowego obciążenia.
Rezerwa pojemności to nie marnotrawstwo. Celem systemu zarządzania przedsiębiorstwem, zbierania danych produkcyjnych czy systemu zarządzania zamówieniami nie jest radzenie sobie w przeciętny dzień. Celem jest, aby pozostał przewidywalny nawet w przypadku spodziewanych szczytów, wyjątkowych przetwarzań i niektórych błędów.
Jest to szczególnie ważne tam, gdzie do systemu podłączonych jest wiele obszarów. Jeśli sklep internetowy, zapasy, fakturowanie i organizacja transportu korzystają z tej samej bazy danych, jeden problem z wydajnością nie oznacza incydentu IT. Może opóźnić wysyłkę paczek, informowanie klientów, fakturowanie, a ostatecznie realizację przychodów.
Kiedy większy serwer nie jest odpowiedzią?
W wielu organizacjach za zapotrzebowaniem na pojemność kryje się działanie, które warto najpierw uporządkować. Typowym przypadkiem jest, gdy aplikacja pobiera te same dane z kilku systemów, a następnie przetwarza je wielokrotnie. Często zdarza się również, że raport przy każdym otwarciu przelicza dane z lat wstecz, mimo że kierownik potrzebuje tylko aktualnych wyników tygodniowych.
W bazach danych brakujący indeks, źle skonstruowane zapytanie lub nieuzasadnione przesuwanie dużej ilości danych mogą powodować nieproporcjonalne obciążenie. Więcej procesorów lub pamięci może tymczasowo złagodzić problem, ale go nie rozwiąże. W miarę wzrostu wolumenu zamówień, liczby użytkowników lub ilości danych produkcyjnych, problem pojawi się ponownie - tylko na wyższym poziomie kosztów.
Warto również zadać pytania dotyczące procesu. Czy naprawdę konieczne jest, aby po każdej zmianie ceny produktu natychmiast uruchamiano pełną aktualizację zapasów i katalogu? Czy konieczne jest przekazywanie tych samych danych co godzinę między dwoma systemami, czy wystarczy wysłać tylko zmiany? Czy uzasadnione jest, aby pracownik codziennie eksportował tysiące wierszy do arkusza kalkulacyjnego, a następnie ładował te same informacje do innej aplikacji?
To nie są wyłącznie kwestie techniczne. Oznaczają one również niepotrzebne obciążenie, powtarzalną pracę ludzką i możliwość błędów. Dobrze przemyślana integracja lub uproszczony przepływ danych często poprawia wydajność przy mniejszych nakładach inwestycyjnych i mniejszym ryzyku operacyjnym niż natychmiastowe rozszerzenie infrastruktury.
Pomiar powinien podążać za procesem biznesowym
Aby podjąć dobrą decyzję, nie wystarczy wiedzieć, jakie jest wykorzystanie serwera. Trzeba również wiedzieć, jakie są tego konsekwencje biznesowe. Warto rejestrować wskaźniki związane z codzienną działalnością: ile czasu zajmuje przeniesienie zamówienia z e-sklepu do magazynu, ile minut trwa wystawienie faktury, ile czasu zajmuje przetworzenie informacji zwrotnej z produkcji, czy ile nieudanych transakcji występuje w godzinach szczytu.
To pomaga oddzielić nieprzyjemne, ale nie krytyczne zjawiska od tych, które rzeczywiście zagrażają działaniu. Raport może być przygotowany pięć minut później, nie powodując szkody biznesowej. Pięciominutowe opóźnienie w przetwarzaniu zamówień w okresie dużego ruchu może jednak szybko spowodować zator w magazynie i obsłudze klienta.
Pomiar powinien również dostarczać wzorców czasowych. Pierwszy dzień miesiąca, naliczanie płac, kampania promocyjna, sezonowy szczyt czy wieczorne przetwarzanie danych to różne obciążenia. Jeśli decyzja opiera się tylko na migawce, łatwo jest przewymiarować lub niedoszacować zapotrzebowanie.
Planowanie na wzrost, a nie tylko na dzisiejszy problem
Rozszerzenie pojemności serwera to nie tylko kwestia sprzętu czy zasobów chmurowych. Należy również zbadać, jak zapewnić ciągłość usługi. Jeden większy serwer może być szybki, ale jeśli ulegnie awarii, jest w trakcie aktualizacji lub błędny proces go zajmie, cała firma może stać się podatna na zagrożenia.
Dlatego przy podejmowaniu decyzji liczy się dostępność, zdolność do tworzenia kopii zapasowych i przywracania, nadzór, zarządzanie uprawnieniami i kontrola zmian. W niektórych przypadkach nie zwiększenie wydajności jest głównym zadaniem, ale oddzielenie krytycznych usług, stworzenie systemu rezerwowego lub odpowiednie harmonogramowanie procesów w tle.
Zarówno infrastruktura chmurowa, jak i lokalna mogą mieć swoje miejsce. Chmura może zapewnić bardziej elastyczne rozszerzenie przy zmiennym obciążeniu, ale trzeba zarządzać kosztami, ruchem danych, zależnościami systemowymi i odpowiedzialnością operacyjną. Środowisko lokalne może być bardziej przewidywalne w przypadku niektórych operacji przemysłowych lub intensywnych danych, ale rozszerzenie pojemności może wymagać dłuższego przygotowania. Właściwy wybór zawsze zależy od krytyczności biznesowej, wzorca obciążenia i stanu istniejących systemów.
Kiedy rozszerzyć pojemność serwera? Najpierw zweryfikujmy
Dobra kolejność jest zazwyczaj prosta: najpierw należy zidentyfikować dokładne miejsce spowolnienia lub awarii, następnie zbadać proces i aplikację, a potem potwierdzić ograniczenie infrastruktury danymi pomiarowymi. Jeśli to jest zrobione, rozszerzenie nie jest zgadywaniem, ale planowaną decyzją biznesową.
Celem nie jest zakup najsilniejszego serwera. Celem jest, aby zamówienia, produkcja, dostawy, fakturowanie i informacje zarządcze były dostępne niezawodnie, gdy firma najbardziej ich potrzebuje. Dobrze zweryfikowane rozszerzenie pojemności to zapewnia. Pochopne może jedynie podnieść koszty tego samego problemu operacyjnego.
Planning a similar system or integration?
Show us the current process and systems. We will help identify the lowest-risk next step.
Key Takeaways
- procesor, pamięć, operacje dyskowe lub połączenie sieciowe są stale przeciążone w godzinach szczytu;
- czas odpowiedzi bazy danych rośnie, zapytania i transakcje czekają;
- kopie zapasowe, synchronizacje lub zadania przetwarzania wchodzą w czas pracy;
- system staje się nieprzewidywalny podczas nowego klienta, kampanii, zmiany produkcyjnej lub sezonowego okresu;
- krytyczna usługa z punktu widzenia biznesu nie ma znaczących rezerw na wypadek awarii, aktualizacji lub szczytowego obciążenia.
Frequently Asked Questions
Jakie sygnały wskazują na konieczność rozszerzenia pojemności serwera?
Rozszerzenie pojemności jest uzasadnione, gdy dane pomiarowe i doświadczenie biznesowe wskazują na to samo. Jeśli system wielokrotnie osiąga lub stale zbliża się do granic dostępnych zasobów, problem nie jest związany tylko z pojedynczymi wyjątkowymi zdarzeniami, a obciążenie prawdopodobnie będzie rosło, rozszerzenie może być krokiem w kierunku bezpieczeństwa operacyjnego.
Kiedy większy serwer nie jest odpowiedzią?
W wielu organizacjach za potrzebą zwiększenia pojemności stoi działanie, które warto najpierw uporządkować. Typowym przypadkiem jest, gdy aplikacja pobiera te same dane z wielu systemów, a następnie przetwarza je wielokrotnie. Często zdarza się również, że raport przy każdym otwarciu przelicza dane z wielu lat wstecz, mimo że kierownik potrzebuje jedynie aktualnych wyników tygodniowych.
Related Engineering Insights
Indywidualny portal klienta czy gotowy CRM - kiedy lepiej?
Kwestia wyboru między indywidualnym portalem klienta a gotowym CRM nie jest rozstrzygana przez listę funkcji, lecz przez potrzeby procesów klienta, danych i długoterminowego zarządzania.
Dlaczego ewidencja zapasów jest niedokładna?
Dlaczego ewidencja zapasów jest niedokładna? Odkrywamy prawdziwe przyczyny rozbieżności i pokazujemy, gdzie warto najpierw uporządkować proces już w tym tygodniu.
Studium przypadku zbierania danych produkcyjnych w fabryce
Studium przypadku zbierania danych produkcyjnych pokazuje, jak z opóźnionych, niepewnych raportów zmianowych uzyskano użyteczne informacje produkcyjne do lepszego podejmowania decyzji.