Plecarea din companie#

O persoană pleacă printr-un singur merge request, în ziua în care pleacă. Tot ce urmează după primul pas se întâmplă de la sine; restul paginii este ce trebuie verificat și ce nu are de unde să știe automatizarea. Managerul deschide merge request-ul; cineva din infra îl integrează și aplică. În total: cincisprezece minute.

În aceeași zi#

În director (https://id.profuse.ro/if/admin → Directory → Users → persoana): debifează Is active și scoate-o din toate grupurile. Nu șterge contul — el păstrează istoricul persoanei și urma de audit; ștergerea este o decizie separată, de mai târziu (vezi „Mai târziu”). Schimbarea aceasta singură este cea care închide tot restul și are efect imediat: fără merge request, fără apply, fără nimic de așteptat.
Sesiunile Cloudflare: apply-ul dezactivează contul, iar SCIM îi spune lui Access, care revocă sesiunile persoanei și înregistrarea din WARP în câteva minute. Verifică în Zero Trust → My Team → Users → persoana: starea revoked. Dacă nu este așa (SCIM încă neconfigurat sau dacă ai dubii), revocă manual de acolo sau:
```
curl -X POST -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" -H "Content-Type: application/json" \
  https://api.cloudflare.com/client/v4/accounts/fa3fedaca96d6834e5166640e2aee819/access/organizations/revoke_user \
  -d '{"email":"<person>@profuse.ro"}'
```
sv1 (doar dacă persoana era în infra): shell-urile deschise supraviețuiesc schimbării din director. Pe sv1:
```
sudo sss_cache -u <username>; sudo pkill -KILL -u <username>
```
Contul dispare imediat din getent passwd (se văd doar conturile cu ak-active=TRUE).
PostgreSQL: pg-directory-sync șterge rolul în cinci minute. Un rol cu o sesiune deschisă nu poate fi șters, deci încheie-le întâi dacă persoana ar putea fi conectată:
```
SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE usename = '<username>';
```
pe prod și pe staging, apoi sudo systemctl start pg-directory-sync și citește-i jurnalul.
E-mail: mailcow-directory-sync oprește căsuța în cincisprezece minute (IMAP, SMTP și parolele de aplicație se opresc; nu se șterge nimic). Rulează-l acum dacă îl vrei acum: sudo systemctl start mailcow-directory-sync. Managerul decide redirectarea și răspunsul automat — se pun în mailcow, pe căsuța inactivă — și data până la care se păstrează.
GitLab: gitlab-directory-sync blochează contul și îl scoate din ambele grupuri în cinci minute (sudo systemctl start gitlab-directory-sync dacă îl vrei acum). Issue-urile și merge request-urile își păstrează autorul. Transferă tot ce ținea persoana singură: token-urile personale de acces mor odată cu blocarea, dar un proiect sau o programare de pipeline care îi aparțineau continuă să meargă sub un proprietar blocat — dă-le altcuiva. Un administrator de instanță nu este niciodată blocat de sincronizare: ea spune asta și îți lasă ție decizia.

Ce nu are de unde să știe automatizarea#

Secretele pe care persoana le putea citi. Schimbă, în aceeași zi, toate datele de acces la care ajungea: pentru developers, valorile din .env-ul de staging pe care le putea vedea într-un log de deploy sau direct pe mașină; pentru infra, în plus token-ul de bootstrap al authentik (/srv/authentik/.env, apoi variabila de CI AUTHENTIK_TOKEN), cheia de API a mailcow, token-urile de API Cloudflare (infra-tofu-*), token-urile GitLab people-provisioner și RELEASE_TOKEN, datele de acces restic/R2. Lista variabilelor de CI de pe profuse/infra și guestget este lista de verificat; fiecare dintre ele este o decizie.
Dispozitivele. Dispozitivul din WARP este revocat odată cu utilizatorul; laptopul companiei se recuperează și se șterge; passkey-urile de pe un dispozitiv personal devin inutile din clipa în care contul este dezactivat.
Lucrurile din afara directorului. Calitatea de membru în contul Cloudflare, administrarea instanței GitLab, conturile la registrar și la găzduire, Stripe, Channex, portalurile ANAF/SDI, seiful de parole: caută în fiecare adresa de e-mail a persoanei. Revizia trimestrială (docs/access-review.md) prinde ce a scăpat, dar cineva care pleacă nu trebuie lăsat pe seama ei.

Mai târziu#

S-a terminat retenția (data pusă de manager, implicit 90 de zile): șterge contul din director, după ce exporți din căsuța de e-mail tot ce păstrează compania. Contul de GitLab rămâne blocat, nu șters, ca să-i supraviețuiască istoricul.
Dacă se întoarce: bifează din nou Is active și pune-i rolurile înapoi. Contul, rolul din baza de date, GitLab și căsuța de e-mail revin de la sine; persoana își pune o parolă nouă printr-un link de resetare (ak-recovery-link).