Kedy rozšíriť kapacitu servera bezpečne?
Ukážeme vám, kedy rozšíriť kapacitu servera, aké signály treba merať a kedy je skutočným problémom proces, aplikácia alebo databáza v pozadí.
Short Answer
Ukážeme vám, kedy rozšíriť kapacitu servera, aké signály treba merať a kedy je skutočným problémom proces, aplikácia alebo databáza v pozadí.
Je pondelok ráno, sklad by otvoril objednávky a zákaznícky servis by hľadal faktúry, ale systém je nápadne pomalý. Prvá reakcia je zvyčajne pochopiteľná: potrebujeme viac serverov. Otázka však nie je, či je spomalenie rušivé, ale kedy rozšíriť kapacitu serverov tak, aby to skutočne vyriešilo obchodný problém, a nie len dočasne zakrylo.
Rozšírenie kapacity je v mnohých prípadoch opodstatnené. Rastúci e-shop, nové miesto, viacsmenná výroba alebo zvýšený zákaznícky tok predstavujú skutočné zaťaženie. Často sa však stáva, že server je len miestom, kde sa prejavuje symptóm zle fungujúceho procesu, pomalého dopytu alebo chybného systémového spojenia. V takýchto prípadoch väčšia infraštruktúra prináša dodatočné náklady, zatiaľ čo oneskorenia, chyby a neistota zostávajú.
Pomalý systém ešte neznamená nedostatok kapacity
Keď sa zhoršuje odozva obchodnej aplikácie, je vhodné najprv presne určiť, čo je pomalé, kedy a pre koho. Nie je jedno, či je zaťažený celý systém, alebo len mesačná uzávierka trvá dvadsať minút. Tiež nie je jedno, či všetci používatelia vnímajú problém, alebo len tí, ktorí používajú určitý report, skladovú funkciu alebo administratívne rozhranie e-shopu.
V 80-člennej obchodnej spoločnosti môže napríklad spracovanie objednávok popoludní viaznuť. Dôvodom môže byť, že vtedy hromadne prichádzajú objednávky z e-shopu. Ale môže to byť aj tým, že v rovnakom čase prepočítava celý skladový stav, zatiaľ čo externé logistické spojenie opakovane skúša odovzdať už spracované údaje. Obe situácie vyžadujú iný zásah.
Využitie CPU servera, pamäte a úložiska sú dôležité údaje, ale samy o sebe nestačia. Stroj môže byť zdanlivo pokojný, zatiaľ čo používatelia čakajú kvôli zámkom databázy. Naopak, môže byť krátkodobo vysoké zaťaženie procesora, zatiaľ čo obchodný proces funguje bez problémov. Infraštruktúru treba hodnotiť nie podľa jedinej technickej hodnoty, ale podľa skutočného fungovania služby.
Aké signály odôvodňujú rozšírenie kapacity serverov?
Rozšírenie kapacity je oprávnené, ak meracie údaje a obchodné skúsenosti ukazujú na to isté. Ak systém opakovane dosahuje alebo dlhodobo sa blíži k hranici dostupných zdrojov, problém nie je len spojený s jednou výnimočnou udalosťou a očakáva sa ďalší rast zaťaženia, rozšírenie môže byť krokom k zabezpečeniu prevádzkovej bezpečnosti.
Situáciu treba brať obzvlášť vážne, ak sa pravidelne objavujú nasledujúce vzory:
- procesor, pamäť, diskové operácie alebo sieťové spojenie sú počas špičky trvalo plné;
- odozva databázy sa zvyšuje, dopyty a transakcie čakajú;
- zálohy, synchronizácie alebo spracovateľské úlohy už zasahujú do pracovného času;
- systém sa stáva nepredvídateľným počas nového zákazníka, kampane, výrobnej zmeny alebo sezónneho obdobia;
- kritická služba z hľadiska obchodnej prevádzky nemá podstatnú rezervu pre prípad chyby, aktualizácie alebo špičkového zaťaženia.
Rezervná kapacita nie je plytvanie. Cieľom podnikového systému, zberu výrobných údajov alebo systému správy objednávok nie je, aby sa zvládal len priemerný deň. Cieľom je, aby bol predvídateľný aj pri očakávaných špičkách, mimoriadnych spracovaniach a niektorých chybách.
To je obzvlášť dôležité tam, kde je systém prepojený s viacerými oblasťami. Ak e-shop, sklad, fakturácia a plánovanie dopravy pracujú z tej istej databázy, jeden problém s výkonom neznamená len IT incident. Môže sa oneskoriť odoslanie zásielky, informovanie zákazníkov, fakturácia a nakoniec aj realizácia príjmov.
Kedy nie je väčší server odpoveďou?
V mnohých organizáciách sa za požiadavkou na kapacitu skrýva prevádzka, ktorú je najprv potrebné upraviť. Typický prípad je, keď aplikácia načítava tie isté údaje z viacerých systémov a potom ich viackrát spracováva. Rovnako časté je, že report pri každom otvorení znovu počíta údaje za roky dozadu, hoci vedúci potrebuje len aktuálny týždenný výsledok.
V databázach môže chýbajúci index, zle navrhnutý dopyt alebo neodôvodnené presúvanie veľkého množstva údajov spôsobiť neprimerané zaťaženie. Viac procesorov alebo pamäte to môže dočasne zmierniť, ale neodstráni. Ako rastie objem objednávok, počet používateľov alebo množstvo výrobných údajov, chyba sa opäť objaví - len na vyššej nákladovej úrovni.
Je tiež vhodné sa pýtať z pohľadu procesu. Je naozaj potrebné, aby po každej zmene ceny produktu okamžite prebehla aktualizácia celého skladu a katalógu? Je potrebné každú hodinu úplne prenášať rovnaké údaje medzi dvoma systémami, alebo stačí posielať len zmeny? Je odôvodnené, aby zamestnanec denne exportoval tisíce riadkov do tabuľky a potom tie isté informácie nahrával do inej aplikácie?
Tieto otázky nie sú len technické. Predstavujú zbytočné zaťaženie, opakovanú manuálnu prácu a možnosť chýb. Dobre premyslená integrácia alebo zjednodušený tok údajov často zlepšuje výkon s menšími investíciami a menším prevádzkovým rizikom ako okamžité rozšírenie infraštruktúry.
Meranie by malo sledovať obchodný proces
Na dobré rozhodnutie nestačí vidieť, aké je využitie servera. Je potrebné vidieť aj to, aké obchodné dôsledky to má. Je vhodné zaznamenávať ukazovatele, ktoré súvisia s každodennou prevádzkou: koľko času trvá, kým sa objednávka z e-shopu dostane do skladu, koľko minút trvá vytvorenie faktúry, ako dlho trvá spracovanie výrobnej spätnej väzby alebo koľko neúspešných transakcií sa vyskytne počas špičky.
To pomáha oddeliť nepríjemné, ale nie kritické javy od tých, ktoré skutočne ohrozujú prevádzku. Report môže byť o päť minút pomalší bez toho, aby spôsobil obchodnú škodu. Päťminútové oneskorenie spracovania objednávok však môže počas obdobia s vysokým obratom rýchlo spôsobiť preťaženie skladu a zákazníckeho servisu.
Meranie by malo poskytnúť aj časový vzor. Prvý deň v mesiaci, mzdová uzávierka, propagačná kampaň, sezónna špička alebo večerné spracovanie údajov prinášajú rôzne zaťaženia. Ak sa rozhodnutie robí len na základe momentálnej snímky, je ľahké preceňovať alebo podceňovať potrebu.
Plánovanie na rast, nielen na dnešný problém
Rozšírenie kapacity serverov nie je len otázkou hardvéru alebo cloudových zdrojov. Treba tiež preskúmať, ako zabezpečiť kontinuitu služby. Jeden väčší server môže byť rýchly, ale ak sa pokazí, je v aktualizácii alebo chybný proces ho zablokuje, celá spoločnosť sa stáva zraniteľnou.
Preto pri rozhodovaní záleží aj na dostupnosti, schopnosti zálohovania a obnovy, dohľade, správe oprávnení a kontrole zmien. V niektorých prípadoch nie je hlavným cieľom zvýšenie výkonu, ale oddelenie kritických služieb, vytvorenie rezervného systému alebo správne načasovanie pozadových procesov.
Cloudová aj miestna infraštruktúra majú svoje miesto. Cloud môže poskytnúť flexibilnejšie rozšírenie pri meniacom sa zaťažení, ale treba riešiť aj náklady, prenos údajov, systémové závislosti a zodpovednosť za prevádzku. Miestne prostredie môže byť predvídateľnejšie pre niektoré priemyselné alebo dátovo intenzívne prevádzky, avšak rozšírenie kapacity môže vyžadovať dlhšiu prípravu. Správna voľba vždy závisí od obchodnej kritickosti, vzoru zaťaženia a stavu existujúcich systémov.
Kedy rozšíriť kapacitu serverov? Najprv validujte
Správne poradie je zvyčajne jednoduché: najprv identifikujte presné miesto spomalenia alebo výpadku, potom preskúmajte proces a aplikáciu a nakoniec overte meracími údajmi obmedzenie infraštruktúry. Ak je to hotové, rozšírenie nie je hádanie, ale plánovateľné obchodné rozhodnutie.
Cieľom nie je získať čo najsilnejší server. Cieľom je, aby objednávky, výroba, dodávky, fakturácia a manažérske informácie boli spoľahlivo dostupné aj vtedy, keď ich spoločnosť najviac potrebuje. Dobre validované rozšírenie kapacity to zabezpečí. Unáhlené rozhodnutie môže len zvýšiť náklady na rovnaký prevádzkový problém.
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, pamäť, diskové operácie alebo sieťové pripojenie sú počas špičky trvalo preťažené;
- doba odozvy databázy sa zvyšuje, dotazy a transakcie čakajú;
- zálohy, synchronizácie alebo spracovateľské úlohy zasahujú do pracovného času;
- systém sa stáva nepredvídateľným počas nového klienta, kampane, výrobnej zmeny alebo sezónneho obdobia;
- kritická služba z hľadiska obchodnej činnosti nemá dostatočnú rezervu pre prípad chyby, aktualizácie alebo špičkového zaťaženia.
Frequently Asked Questions
Aké signály naznačujú potrebu rozšírenia kapacity servera?
Rozšírenie kapacity je opodstatnené, ak meracie údaje a obchodné skúsenosti ukazujú na to isté. Ak systém opakovane dosahuje alebo trvalo sa približuje k hranici dostupných zdrojov, problém nie je len s jednorazovou udalosťou a očakáva sa ďalšie zvýšenie zaťaženia, rozšírenie môže byť bezpečnostným krokom.
Kedy nie je väčší server odpoveďou?
V mnohých organizáciách je za požiadavkou na kapacitu skrytá prevádzka, ktorú je vhodné najprv upraviť. Typickým prípadom je, keď aplikácia načítava rovnaké údaje z viacerých systémov a následne ich viackrát spracováva. Rovnako bežné je, že správa pri každom otvorení prepočítava údaje za niekoľko rokov dozadu, hoci vedúci potrebuje len aktuálny týždenný výsledok.
Related Engineering Insights
Vlastný zákaznícky portál alebo hotové CRM - kedy je lepšie?
Otázku vlastného zákazníckeho portálu alebo hotového CRM nerozhoduje zoznam funkcií, ale potreby zákazníckych procesov, údajov a dlhodobého fungovania.
Prečo je evidencia zásob nepresná?
Prečo je evidencia zásob nepresná? Odhalíme skutočné príčiny odchýlok a ukážeme, kde sa oplatí začať s poriadkom v procese už tento týždeň.
Zber výrobných dát: prípadová štúdia z továrne
Prípadová štúdia zberu výrobných dát ukazuje, ako sa z neskorých, neistých správ o zmene stali použiteľné výrobné informácie pre lepšie rozhodovanie.