Întreținerea unei rețele de 50 de obiecte: de ce nu este 50 de proiecte separate

Când o companie are cinci puncte de vânzare sau locații de producție, problemele IT se rezolvă „prin telefon”: ceva nu funcționează, cineva la fața locului repornește, reinstalează, reconectează. La cincizeci de obiecte, modelul nu mai scalează. Nu se opresc imprimante separate — se oprește însăși capacitatea de a administra infrastructura.

Vedem asta în mod regulat: afacerea crește de la 5 la 30 de obiecte, apoi la 50, iar la un moment dat infrastructura începe să consume tot atâtea resurse cât activitatea de bază. Nu pentru că obiectele sunt prea multe — ci pentru că sunt întreținute ca 50 de proiecte fără legătură între ele.

Simptomele „50 de proiecte în loc de o singură rețea”

Sunt ușor de verificat. Dacă răspunsul este „da” la cel puțin trei — exact aceasta este situația dvs.:

• La fiecare obiect lucrează un alt furnizor sau un „om care știe”, iar nimeni nu mai știe cine a configurat routerul la obiectul 17.
• Deschiderea unui obiect nou durează 3–6 săptămâni nu din cauza pereților și a echipamentelor, ci din cauza „configurării IT pentru noul amplasament”.
• Când trebuie schimbată parola de administrator — durează un sprint, nu o zi. Și undeva veche tot rămâne.
• Incidentele apar „pe nepusă masă”: despre căderea casei sau a rețelei află nu administratorul, ci casiera care sună la birou.
• Backup-urile există, dar nimeni nu mai ține minte când a fost testată ultima restaurare. La majoritatea obiectelor — niciodată.
• Licențele și echipamentele se cumpără din nou, pentru că nimeni nu urmărește unde au plecat lucrurile când s-a închis obiectul anterior.
• Auditorul sau echipa de securitate întreabă despre politicile de acces — nu există răspuns.

Niciuna dintre aceste probleme nu este „a unui obiect anume” — toate sunt probleme ale modelului. Obiectele arată la fel; infrastructura de sub fiecare este unică.

De ce „50 de proiecte” se prăbușește la scară

Nu este vorba de cantitate. E vorba de trei efecte sistemice care apar tocmai după 15–20 de obiecte.

1. Drift de configurație

Zece obiecte deschise în momente diferite de oameni diferiți înseamnă zece configurații ușor diferite. La al unsprezecelea, inginerul nu mai ține minte cum era „corect” și copiază de la cel mai apropiat. După doi ani aveți 50 de fulgi de zăpadă unici: asemănători, dar nu identici. Orice operație în masă — actualizarea antivirusului, înlocuirea certificatului, rotirea cheilor VPN — devine un micro-proiect separat la fiecare obiect.

2. Lipsa observabilității

50 de obiecte disparate sunt 50 de cutii negre. Nu știți ce se întâmplă în interiorul lor până când ceva nu se strică suficient cât să se plângă un utilizator. Fără monitorizare centralizată, este imposibil să vedeți tendințele: că discul la obiectul 23 se umple mai repede decât de obicei, că VPN-ul la obiectul 41 „pâlpâie” o dată pe săptămână, că UPS-ul la obiectul 7 trece pe baterie în fiecare marți la ora 14:00.

3. Responsabilitate difuză

Dacă fiecare obiect are propriul furnizor, atunci la orice incident IT răspunsul este același: „nu e de la noi”. Casa nu funcționează — e software-ul de la vendor. Rețeaua merge greu — e furnizorul de internet. Imprimanta nu printează — e furnizorul de imprimante. În final, pentru întregul lanț răspunde doar proprietarul afacerii, în timp ce fiecare furnizor în parte acoperă o fâșie îngustă.

Ce trebuie să trăiască în centru, nu pe obiect

Principiul de bază — centralizat în mod implicit, local doar unde este necesar. La obiect rămâne doar ce trebuie să continue să funcționeze atunci când conexiunea cu biroul cade. Restul — în infrastructura comună.

În centru — fără excepție

• Conturi de utilizator și drepturi de acces. O singură sursă de adevăr (Active Directory, Microsoft Entra ID sau echivalent). Angajatul a plecat — accesele sunt revocate o singură dată și dispar peste tot. Administratorii locali pe fiecare obiect sunt principala sursă de conturi „eterne” aparținând unor oameni care au plecat de mult.
• Monitorizare și alertare. Un singur Zabbix / Grafana / Prometheus care vede fiecare obiect. Alertele merg către o tură de serviciu, nu într-un chat cu casiera.
• Backup și plan de restaurare. Backup-urile se fac după o politică unică și ajung într-un loc verificabil. Restaurarea se exersează după program, nu „când se sparge ceva”.
• Șabloane de configurație. Imaginea stației de lucru, configurația de bază a routerului, GPO, politica antivirus — totul prin șabloane, nu „cum îmi amintesc”.
• Loguri și audit. Logurile tuturor obiectelor se colectează central. Fără asta, investigarea unui incident la obiectul 34 de acum trei săptămâni este imposibilă.
• Gestionarea parcului de dispozitive. Un singur MDM / SCCM care știe ce laptop unde se află, cine lucrează pe el, ce actualizări sunt instalate.
• Politici de rețea. Controllere Wi-Fi, concentratoare VPN, firewall-uri — toate gestionate central; altfel, în timpul unui incident de securitate veți aplica aceeași schimbare manual de 50 de ori.

Local — doar ce trebuie să funcționeze offline

• Cache-ul POS și al software-ului comercial, ca bonurile să poată fi tipărite la o întrerupere de conexiune.
• DHCP/DNS local — un obiect nu trebuie să cadă din cauza căderii canalului spre birou.
• Recorderul video — înregistrează local, metadatele și clipurile urcă în sus.
• Canal de rezervă (LTE/4G) cu comutare automată.

Cum trecem de la „50 de proiecte” la „o singură rețea” fără a opri afacerea

Nu e „rescriem totul de la zero”. Este o tranziție pe etape, de obicei 4–9 luni pentru un parc de 50 de obiecte, în funcție de starea actuală.

1. Inventariere. Înainte de a centraliza, trebuie să știți ce aveți. Fiecare dispozitiv, fiecare canal, fiecare licență, fiecare „om care știe”. 2–4 săptămâni de muncă de teren la 50 de obiecte.
2. Alegerea și ridicarea nucleului central. AD/Entra, monitorizare, server de backup, MDM, concentrator VPN. În paralel cu exploatarea celor existente.
3. Configurație de referință pe un obiect. Pilot pe 1–2 obiecte: imagine nouă a stațiilor de lucru, rețea nouă, conectare la monitorizarea și backup-ul central. Pilotul rezolvă 90% din problemele viitoare.
4. Migrare în valuri. 5 obiecte pe săptămână este un ritm realist. După fiecare val — o scurtă retrospectivă și ajustarea referinței.
5. Decomisionarea celor vechi. Pasul cel mai uitat. VPN-uri vechi, conturi vechi, servicii închiriate vechi — opriți-le, altfel vor mai trăi ani de zile, iar dvs. veți plăti pentru ele tot atâția ani.

Ce se schimbă în cifre

Pe proiecte reale (anonim — cifre din experiența noastră în rețele de retail, alimentație și obiecte logistice), trecerea la modelul centralizat aduce de obicei:

• Deschiderea unui obiect nou scade de la 4–6 săptămâni la 3–7 zile pentru partea IT.
• Timpul de reacție la incident scade de la „când observă utilizatorul” la 5–15 minute (alerta vine — cineva o ia în lucru).
• Cheltuielile de suport IT scad cu 25–40% prin eliminarea contractelor și licențelor duplicate.
• Restaurarea din backup trece de la „nu am încercat niciodată” la „facem exerciții trimestrial”.
• Auditul de securitate și conformitatea (Legea RM nr. 195/2024, GDPR pentru clienții străini) încetează să mai fie urgență și devin rutină planificată.

Listă de verificare: cum stați acum

Tipăriți și treceți prin parcul dvs. Dacă răspunsul este „nu” pentru mai mult de 10% dintre obiecte la oricare punct — funcționați după modelul „50 de proiecte”.

• La obiect nu există conturi de administrator local în afara catalogului corporativ.
• Un angajat plecat trimestrul trecut — toate accesele lui pe toate obiectele au fost revocate automat.
• Pot vedea într-o singură interogare starea tuturor obiectelor: care sunt online, care au făcut backup astăzi, cui îi rămâne mai puțin de 20% spațiu liber.
• Backup-ul ultimului obiect a fost restaurat pe un stand de testare în ultimele 90 de zile.
• Deschiderea celui de-al 51-lea obiect durează cel mult 5 zile lucrătoare la partea IT.
• Orice politică de rețea (de exemplu, blocarea unui domeniu) o pot aplica întregului parc într-o singură zi.
• Dacă un incident IT are loc în afara orelor de lucru la un obiect, despre asta află inginerul de gardă din birou, nu colegul din schimb de la acel obiect.

Întrebări frecvente

Dar dacă obiectele noastre sunt în jurisdicții diferite — de exemplu, Moldova și România?

Nu este un obstacol pentru centralizare. Cerințele locale privind păstrarea datelor sunt luate în calcul la alegerea platformelor (o parte din date pot rămâne în centre de date locale), însă administrarea și monitorizarea se construiesc oricum ca un sistem unic.

Nu este mai scump să ridicăm un nucleu propriu decât să lăsăm „cum e”?

Pe orizontul de 6–12 luni — da, este nevoie de o investiție. Pe orizontul de 2 ani, modelul centralizat este aproape întotdeauna mai ieftin, datorită încetării contractelor duplicate, deschiderii rapide a obiectelor și reducerii incidentelor IT care ajung la client.

Și ce facem cu datele care, conform legii, trebuie să rămână în țară?

Arhitectural se rezolvă prin alegerea platformei pentru date și separarea „control plane / data plane”: gestionarea poate rămâne centralizată, iar datele pot sta pe teritoriul cerut. În Moldova acest lucru este deosebit de relevant pentru Legea RM nr. 195/2024 și prelucrarea datelor cu caracter personal.

Suntem mici — avem doar 12 obiecte. E prea devreme pentru noi?

Simptomele apar la aproximativ 15–20 de obiecte. Dar dacă planificați creșterea, modelul „ca o rețea” este cel mai ieftin de implementat la 8–15 obiecte, cât timp totul se mai poate inversa fără migrări mari.