PC flotila vs server estate: prevádzkové praktiky, ktoré sa líšia v GLPI

PC flotila vs server estate: prevádzkové praktiky, ktoré sa líšia v GLPI

„Endpoint" a „server" sa v GLPI obidva nachádzajú ako objekty Computer, ale prevádzkovať ich rovnako je chyba. Líšia sa refresh cyklusmi, patch oknami, kritickosťou aj audit potrebami. Tento článok je o praktickom rozdelení — čo nakonfigurovať inak v GLPI keď spravujete 200 kancelárskych staníc oproti 15 produkčným serverom.

Refresh cadence a lifecycle stavy

PC sa zvyčajne refreshujú v 3 – 4 ročnom cykle (notebooky rýchlejšie ako desktopy). Servery bežia 5 – 7 rokov pred refreshom, niektoré stabilné workloady aj dlhšie. V GLPI to znamená dva odlišné state machine:

PC lifecycle (rýchlejší)
  Procured → In Stock → Assigned → In Use → End-of-Lease/Refresh → Retired
  Typická doba v "In Use": 3 – 4 roky

Server lifecycle (pomalší, viac stavov)
  Procured → Racked → Burn-in → Production → Maintenance Window →
  End-of-Support → Decommissioning → Decommissioned (data wiped) → Retired
  Typická doba v "Production": 5 – 7 rokov

Konfigurujte ich ako oddelené stavové sady per Item type (Setup → Dropdowns → States s typovo-špecifickým filtrom). Nepoužívajte jednu sadu stavov pre obidva — server „Burn-in" a „End-of-Support" sú šum na PC, a PC „End-of-Lease" sa neaplikuje na väčšinu serverov.

Naming conventions

PC sa zvyčajne menujú podľa používateľa (NB-NOVAK, DESK-FINANCE-12). Servery potrebujú odlišnú schému, ktorá kóduje rolu, prostredie a inštanciu:

PC (kotvené na používateľa)
  Formát: <typ>-<user-shortcut>
  Príklady: NB-NOVAK01, DESK-RECEPTION01

Servery (kotvené na rolu)
  Formát: <env>-<role>-<NN>
  Príklady: PROD-DB-01, STAGE-WEB-02, DR-FILE-01
  Kóduje: prostredie (PROD/STAGE/DR), rolu, číslo inštancie

V GLPI nakonfigurujte Auto-naming pravidlá v Setup → General → Inventory s oddelenými šablónami podľa subtypu objektu, alebo cez business rules ktoré upozornia na porušenie naming patternu.

Patch okná a change control

PC sa patchujú cez Windows Update / Intune / WSUS cyklus — typicky utorok-streda rolling reboot. Patche sú väčšinou nízkoriskové; ak nejaký pokazí, prerobíte image. Servery sa patchujú v plánovanom change okne s rollback plánom, validačnými krokmi a blackout obdobím.

V GLPI:

  • Pre PC: nedávajte updaty cez Change modul. Patche sú príliš časté (mesačne) a nízkoriskové. Trackujte cez Tickets ak konkrétny patch spôsobí incidenty.
  • Pre servery: každý patch nad rámec kritických bezpečnostných updatov ide cez objekt Change s CAB validáciou. Naviažte Change na dotknuté server aktíva cez záložku Items; história Change sa stáva audit trailom.

GLPI Agent intervaly

Inventárna frekvencia GLPI Agenta by sa mala líšiť:

  • PC: každých 24 hodín stačí. Ľudia inštalujú softvér, menia periférie, sú prepriraďovaní. Agent zachytí zmeny cez noc.
  • Servery: každé 4 – 12 hodín, niekedy kratšie. Konfigurácie serverov sú prísne kontrolované a neočakávané zmeny (nový balík, config drift) sú incident signál, ktorý sa oplatí zachytiť rýchlejšie.

Konfigurujte oddelene cez --delaytime agenta alebo v config súbore pushnutom cez Ansible/Puppet do server flotily.

Monitoring očakávania

GLPI sám nie je monitoring systém, ale je centrálnym záznamom, ktorý sa s ním integruje. Vzory:

  • PC: monitoring je oportunistický — agent inventár raz denne, tiket vytvorený keď používateľ nahlási problém. Žiadny proaktívny 24/7 watch.
  • Servery: monitoring je kontinuálny. Zabbix/Prometheus/iný posiela webhook do GLPI pri prahu, automaticky vytvára incident s naviazaným serverom. Pozri REST API + webhooks pre mechaniku.

Audit cadence

Fyzické audity — chodenie s barcode skenerom — prebiehajú v rôznych frekvenciách:

  • PC: ročne, ideálne počas obdobia s nízkou aktivitou (leto, medzi koncom fiškálneho roka a budget kick-offom). Cieľ 95%+ reconciliation rate. Použite barcode/QR workflow.
  • Servery: kontinuálne. Servery sa nehýbu; rack location v GLPI by mal vždy zodpovedať fyzickej realite. Walk-around každých 6 mesiacov zachytí zriedkavý prípad (decommissioned ale ešte v racku, výmena ktorá sa nezaznamenala).

Rigor pri decommissioningu

End-of-life proces sa výrazne líši:

  • PC retirement: data wipe (DBAN alebo vendor tool), asset state na „Retired", update finančného asset registra, zalogovanie donation/disposal trasy. 30 minút procesu na zariadenie.
  • Server decommissioning: projekt. Stakeholder sign-off (kto závisí od tohto servera?), grace period (1 – 4 týždne „shutdown ale nie unracked" aby vyplávali závislosti), migrácia závislých služieb, archivácia configov, revokácia certifikátov, čistenie DNS záznamov, potom fyzické odstránenie a disposal. Niekoľko dní až týždňov procesu na server.

V GLPI server decommissioning si zaslúži vlastný Change objekt s checklistom a validáciami. PC retirement stačí ako Ticket typu Request.

Čo zostáva rovnaké

Napriek rozdielom obidve kategórie ťažia z rovnakej GLPI hygieny: presný inventár cez agenta, kontrakty naviazané na aktíva, ticket história prepojená s konkrétnymi položkami, audit logy zachované. Rozdiely sú v cadence a rigore, nie v underlying data modeli. Jedna GLPI inštancia zvládne obidva — konfigurácia ich rozdeľuje. Pre špecifiká začiatku pozri návod na bootstrap inventára.

Potrebujete pomôcť s touto témou?

Kontakt