Cere o analiză

Acasă/Proiecte/Pontaj, instituție publică

Studiu de caz · În producție

Pontaj și control accesîntr‑o instituție publică

O instituție publică folosește un sistem de pontaj și control acces biometric cu 16 cititoare. În mentenanță am găsit foști angajați rămași pe cititoare, liste diferite de la o intrare la alta și o bază de date umflată. Am verificat, am curățat și am reparat totul pe o copie, apoi pe producție, cu copie de siguranță înainte.

76foști angajați scoși de pe cititoare, cu 778 de comenzi23.10.2026
342–352 → 277utilizatori pe cititoarele zonei principale: aceeași listă pe toatedupă reparații
1.387 → 688 MBdimensiunea bazei de date după curățarea jurnalelor24.10.2026
196.811pontaje în sistem, pentru 233 de angajați activivolum gestionat
Situația

De unde am pornit

Sistemul era în funcțiune. Când am preluat mentenanța, foștii angajați nu erau șterși de pe cititoare: 76 din 79 de persoane plecate erau încă acolo.

Cititoarele aveau liste diferite între ele, ecranul de pontaj live afișa „null” în loc de nume, iar baza de date crescuse din cauza jurnalelor. Concediile sunt ținute în programul de resurse umane, fără legătură cu dreptul de acces.

Ce am făcut

Soluția

  • am citit direct de pe fiecare cititor lista de utilizatori și am comparat-o cu baza de date;
  • am scos foștii angajați și vizitatorii închiși de pe cititoare;
  • am curățat baza de date, cu copie de siguranță înainte;
  • am corectat ecranul de pontaj live: vizitatorii apar acum ca „Vizitator”, cu cod;
  • am făcut o unealtă care repetă verificările și reparațiile din câteva clicuri, întâi în mod de test.
Cum lucrăm

Întâi pe copie, apoi pe producție

Operațiile pe date s-au făcut în weekend, iar pe producție nu s-a modificat nimic fără confirmarea noastră.

Citirelistele de utilizatori, direct de pe cititoare
Compararecu o copie a bazei de date
Testscripturile rulează întâi în mod de test
Copie de siguranțăînainte de orice modificare
Aplicare și recitirerezultatul verificat pe cititoare

„null” în pontajele live

Cauza era în codul compilat al aplicației: numele se lua doar din fișa de angajat, iar cardurile de vizitator nu au fișă. Prima corectură a acoperit doar încărcarea paginii; a doua și actualizările în timp real.

O greșeală, reparată în aceeași seară

Prima unealtă a trimis pe un cititor 52 de vizitatori în loc de 47, pentru că pe producție istoricul comenzilor se păstrează mai puțin decât pe copie. Am reparat în aceeași seară, am verificat prin recitire și am schimbat unealta să folosească drept referință un cititor citit live. De atunci, orice unealtă rulează întâi în mod de test.

Propus, în așteptarea deciziei clientului: blocarea automată a accesului pe durata concediilor, cu date preluate din programul de resurse umane, reversibilă și cu jurnal.

Rolul lui Claude

Ce a făcut Claude în proiect

Fiecare sesiune de lucru a fost notată într-o fișă, inclusiv greșelile și corectarea lor.

Ce a făcut Claude

  • a analizat datele pe o copie a bazei
  • a scris uneltele de verificare și reparare
  • le-a testat întâi pe copie, apoi în mod de test
  • a comparat listele citite de pe cititoare cu baza

Ce am făcut noi

  • am rulat uneltele pe serverul clientului
  • am adus listele citite de pe cititoare pentru comparare
  • am confirmat fiecare modificare pe producție
  • deciziile, verificarea finală și relația cu clientul

Nimic nu s-a modificat pe producție fără test, copie de siguranță și confirmarea unui om.

Ai un sistem de pontaj pe care nu-l mai controlezi?

Verificăm cine are acces pe fiecare cititor și aducem listele și baza de date în ordine, întâi pe o copie.

Cere o analiză →