Client nou preluat, un producător local cu ~120 de utilizatori. Domeniul Active Directory rula din 2013, migrat de două ori (2008 R2 → 2016 → 2019), trecut prin trei administratori diferiți și zero audituri. Genul de AD despre care toată lumea spune “merge, nu-l atinge”. Exact tipul de infrastructură care merge… până în ziua în care nu mai merge, și atunci merge foarte prost.

M-au chemat pentru altceva — o migrare de file server — dar prima întrebare pe care o pun mereu la un client nou e: “când ați făcut ultimul audit de securitate pe AD?”. Răspunsul, ca de obicei: tăcere, apoi “păi… nu prea”. Am cerut o oră să rulez un scan rapid înainte să atingem orice. Ora aia a devenit proiectul lunii.

Ideea de fond: într-un AD vechi, riscul real nu e că cineva sparge o parolă. Riscul e că, prin acumulare de configurări proaste peste ani, un cont oarecare de utilizator poate ajunge Domain Admin în trei pași pe care nimeni nu i-a plănuit vreodată. Nu vezi asta uitându-te manual în ADUC. Vezi asta doar cu unelte care mapează relațiile.

Client nou, e-commerce mic, ~2000 vizitatori/zi organic + campanii Google Ads active pe search și shopping. Buget lunar Ads: ~4500 EUR. Problema cu care mă cheamă nu era una tehnică pe partea de server (“nu pică nimic”), ci una financiară: CPC-ul mediu crescuse de la 0.42 EUR la 0.71 EUR în două luni, iar conversiile scăzuseră cu ~18%. Agenția anterioară le spusese “e piața, e sezon, concurență mare”. Managerul nu era convins și a cerut o părere tehnică.

Prima uitătură în Google Ads: Quality Score mediu pe cuvintele cheie principale — 4/10, cu note explicite pe “Landing page experience: Below average”. Când am dat click pe detalii, mesajul Google era limpede: “Users may experience slow load times or poor mobile experience on this landing page.”

Adică nu era problema de bidding, de copy sau de match type. Era problema mea, ca sysadmin/DevOps. Google penaliza pagina și crescuse costul pe click ca să compenseze un CTR estimat mai slab. Fiecare secundă în plus de LCP se traducea direct în cash pierdut lunar.

Cel mai des îmi spun clienții SMB: “Avem deja Zabbix / PRTG / un script care trimite mail când scade spațiul pe disc, e suficient.” Și până într-un punct chiar e. Funcționează, te anunță când ceva moare, costă puțin sau nimic. Apoi crești la 30-40 de servere, încep să apară micro-serviciile, container-ele, un cluster de Kubernetes mic, și deodată stack-ul vechi nu mai poate ține pasul.

L-am întâlnit la un client cu 25 de VM-uri pe Proxmox, 3 noduri Kubernetes (k3s pe bare metal pentru aplicațiile interne) și o stivă de containere Docker pe câteva host-uri standalone. PRTG-ul lor cu 100 sensori plătiți era depășit – nu putea face metrics per-container, alertele erau rigide, dashboard-urile fixe. Ne-au cerut “ceva care să crească cu noi fără să plătim 10k/an”.

Răspunsul a fost Prometheus + Grafana, cu Alertmanager în spate. Setup zero costuri de licențiere, scalează ușor, comunitate uriașă. Dar nu e plug-and-play – dacă vrei să faci treabă serioasă, intri în câteva concepte care la prima vedere par overkill pentru SMB.

Backup la configurările Docker pe Raspberry Pi folosind GitHub prin SSH

Dacă rulezi mai multe containere pe un Raspberry Pi, fișierele de configurare (în special docker-compose.yml) sunt cele mai importante de salvat.

Ce salvăm (și ce NU salvăm)

• Salvăm: fișierele docker-compose.yml, scripturile, fișierele de configurare statice.
• NU salvăm: volumele cu date (baze de date, fișiere mari) și secretele din .env (parole, token-uri). Acestea se exclud prin .gitignore.

Acum cativa ani am setat zeci de VPN-uri clasice pentru clienții care treceau peste noapte la work-from-home. OpenVPN pe pfSense, WireGuard pe Mikrotik, SoftEther pe Windows Server – fiecare cu certificatele lui, cu user database separat, cu configul exportat în .ovpn și trimis pe email pentru fiecare angajat nou.

Cativa ani mai târziu, situația era previzibilă: utilizatori cu config-uri vechi care încă funcționau (pentru că nimeni nu rotise certificatele), foști angajați care încă aveau acces (pentru că lista de revocare nu era ținută la zi), un VPN care expunea o întreagă rețea internă “/24” la oricine nimerea credențialele. Mai era și partea operațională: la fiecare angajat nou, 30 de minute pentru generat config, instruit utilizatorul, debug când nu functiona pe Mac vs Windows.

Lucrez de ani buni cu Veeam Backup & Replication la mai mulți clienți SMB – de la firme cu 5 servere la infrastructuri cu 60-80 de VM-uri pe VMware și Hyper-V. Pattern-ul e mereu același: clientul cumpără licența, instalăm jobs-urile, vedem 3 luni la rând bifa verde “Success” în consolă, și toată lumea e fericită.

Apoi vine ziua aia. Un controller RAID care cedează, un ransomware care criptează un share, sau cel mai banal – un coleg care șterge “din greșeală” un folder cu 200GB de proiecte arhivate. Și descoperim că backup-ul rulează de luni de zile, dar nimeni nu a încercat vreodată un restore real.

Spoiler: în 3 din 10 cazuri pe care le-am văzut, restore-ul nu functiona. Job-ul era verde, dar fie repository-ul era corupt silent, fie credentialele de Active Directory expiraseră și application-aware processing-ul nu mai mergea, fie cineva mutase un VM și backup-ul îl ignora de săptămâni.

Context real pe care probabil mulți îl recunoașteți: companie de ~400 de angajați, HR-ul trimite pe mail „a venit Ionescu luni, îi faci cont?”. Procesul de onboarding arăta cam așa pe partea de IT:

• Deschizi ADUC, creezi userul în OU-ul corect
• Îl bagi în grupurile de securitate în funcție de departament (uneori 8-10 grupuri)
• Deschizi portalul M365, îi asignezi licența potrivită
• Creezi mailbox-ul, configurezi signature-ul cu template-ul companiei
• Creezi folderul personal pe file server, setezi permisiuni NTFS
• Adaugi userul în Teams în canalele departamentului
• Trimiți credențialele temporare pe telefonul managerului (că userul nu are încă mail)
• Updatezi un Excel cu cine a fost adăugat când și cu ce licență

Fiecare pas – click-uri, așteptări, verificări. Timpul mediu: 40-50 minute per user, și asta când totul mergea bine.Clar trebuia automatizat. Varianta complet comercială (ex: soluții de IAM/IGA) era peste budget. Am mers pe combinație de PowerShell + un CSV generat din HR + Task Scheduler.

Prezența online nu mai este un „nice to have” pentru companii, ci o necesitate. Indiferent că vorbim despre firme mici, afaceri locale sau companii în creștere, modul în care sunt percepute online influențează direct încrederea clienților și decizia de a colabora. Un website nu mai este doar o carte de vizită digitală, ci un punct central al identității unei afaceri.