Infrastructura unui proiect web: criterii explicate prin portofoliul GabrielDev

De la portofoliu la o cerință tehnică verificabilă

Portofoliul public GabrielDev prezintă proiecte web și platforma AsistAi. Aceste prezentări pot ajuta la înțelegerea tipului de produs, dar nu dovedesc ce server folosește fiecare client, cât costă operarea lui sau ce performanță a fost măsurată. Articolul explică modul în care cerințele unui proiect devin un plan de infrastructură. Scenariile de mai jos sunt ilustrative; nu descriu configurații private ale clienților.

Materialul este sponsorizat. Relația comercială nu înlocuiește dovezile tehnice și nu transformă portofoliul într-un audit independent. Pentru afirmațiile despre proiectele prezentate, sursa este propria lor descriere publică. Pentru capacitate, disponibilitate și recuperare sunt necesare măsurători și documente specifice proiectului evaluat.

O discuție utilă cu un dezvoltator începe cu operațiile importante pentru utilizator. „Vreau un server bun” nu spune dacă trebuie protejate comenzi, mesaje din formulare, documente încărcate sau istoricul unei conversații. Scrie ce trebuie să se întâmple, ce date rezultă și cum afli că operația a eșuat. Abia apoi alegi componentele care susțin acel flux.

Scenariul unu: site de servicii cu formular

Pentru un site de servicii, un traseu reprezentativ este: vizitatorul citește pagina, completează formularul, primește confirmarea, iar echipa primește cererea. Faptul că pagina principală se încarcă nu demonstrează că întregul traseu funcționează. Formularul poate returna succes, în timp ce emailul nu ajunge sau cererea nu este păstrată nicăieri.

În brief, stabilește unde se salvează cererea și cine verifică livrarea notificării. Dacă mesajul este trimis printr-un furnizor extern, notează ce se întâmplă când acesta este indisponibil. O coadă cu reîncercări poate fi o soluție, dar aduce un proces care trebuie supravegheat. Pentru un proiect mic, o soluție mai simplă poate fi suficientă dacă păstrează dovada și permite recuperarea cererilor.

Proba de acceptare folosește o adresă de test și un mesaj fictiv identificabil. Verifică înregistrarea, notificarea și confirmarea afișată utilizatorului. Testează separat intrarea invalidă. O confirmare de succes nu trebuie afișată dacă operația necesară nu s-a realizat. Rezultatul verificării se notează fără a introduce date personale reale în documentația partajată.

În acest scenariu, investiția prioritară poate fi observabilitatea fluxului și recuperarea mesajelor, nu un procesor mai mare. Decizia rezultă din riscul concret: pierderea unei cereri valoroase poate conta mai mult decât câteva zeci de milisecunde economisite pe o pagină rar accesată.

Scenariul doi: magazin cu plăți și procese de fundal

Un magazin are mai multe stări intermediare. Comanda poate fi creată înainte ca plata să fie confirmată. Notificarea de la procesator poate întârzia sau se poate repeta. Stocul și emailurile pot fi actualizate de procese diferite. Infrastructura trebuie discutată împreună cu aceste reguli, nu ca o mașină izolată pe care „instalăm magazinul”.

Într-un mediu de test, urmărește un identificator de comandă de la început până la confirmare. Cere verificarea unui eveniment de plată repetat: aceeași notificare nu ar trebui să producă o a doua livrare sau o a doua scădere a stocului. Verifică și cazul în care procesul de fundal este oprit temporar, apoi repornit. Acestea sunt probe ale aplicației și ale operării ei, nu simple teste de disponibilitate HTTP.

Pentru date, inventariază baza de date și fișierele încărcate. O copie a codului nu include automat imaginile produselor sau documentele generate. Dacă aplicația folosește stocare externă, accesul și recuperarea acelei stocări trebuie incluse în plan. Nu presupune că backup-ul unei mașini acoperă tot ce există în conturi separate.

La predare, proprietarul magazinului trebuie să știe cine urmărește comenzile rămase într-o stare intermediară și cum sunt investigate. O alertă utilă descrie impactul și acțiunea, de exemplu existența unor comenzi confirmate care nu au trecut la etapa următoare. O alertă despre CPU, luată singură, nu arată dacă utilizatorii pot cumpăra.

Scenariul trei: aplicație SaaS cu un serviciu AI extern

Prezentarea publică AsistAi descrie o platformă de chatbot. Din această descriere nu rezultă automat furnizorul infrastructurii sau limitele tehnice ale instalării. Folosim categoria de produs pentru un scenariu general: o aplicație primește o întrebare, apelează un serviciu extern și afișează răspunsul. Fiecare etapă are propriul timp de așteptare și propriile erori.

În brief, separă durata aplicației tale de durata furnizorului extern. Dacă serviciul răspunde lent, mai multă memorie locală poate să nu schimbe experiența. Stabilește timeout-uri, mesaje de eroare și reguli de reîncercare. O reîncercare automată poate avea cost sau poate produce un efect duplicat; nu o activa fără să înțelegi operația și contractul integrării.

Pentru capacitate, măsoară cereri concurente și resursele efectiv consumate. Pentru cost, ține separat serverul, stocarea și consumul serviciului extern. Un preț lunar mic al serverului nu spune nimic despre factura totală a unei aplicații cu utilizare variabilă. Folosește limite și alerte alese pentru proiect, cu un responsabil care le primește și poate interveni.

Proba de acceptare include un răspuns valid, indisponibilitatea furnizorului și un răspuns care nu respectă structura așteptată. Aplicația trebuie să comunice situația fără să expună chei sau detalii interne. Pentru medii cu mai mulți clienți, verifică și izolarea datelor prin conturi de test distincte. O demonstrație vizuală reușită nu înlocuiește aceste probe.

Cine răspunde de fiecare componentă

Un proiect poate avea dezvoltator, proprietar, administrator de server și furnizori externi. Dacă fiecare presupune că altcineva verifică backup-ul, responsabilitatea nu există în practică. Creează o listă cu domeniul, DNS-ul, găzduirea, aplicația, baza de date, emailul, stocarea și integrările. Pentru fiecare trece titularul contului, responsabilul operațional și calea de escaladare.

Accesul trebuie să poată fi predat și retras controlat. Evită situația în care singura copie a unei chei sau singurul cont de administrare aparține unei persoane care nu mai lucrează la proiect. Documentul operațional nu trebuie să conțină parole în clar; el indică locul și procedura autorizată de acces. Testează predarea cu persoana care va administra efectiv serviciul.

Stabilește ce înseamnă o intervenție inclusă și ce necesită o comandă separată. Actualizarea unui pachet, restaurarea după o eroare și dezvoltarea unei funcții noi sunt activități diferite. Un contract de mentenanță neclar poate transforma un incident tehnic într-o dispută despre responsabilitate exact când timpul contează cel mai mult.

Recuperarea începe cu o probă, nu cu o bifă

Definește împreună cu proprietarul câtă informație poate fi pierdută și cât timp poate sta serviciul oprit. Un site informativ și un magazin cu comenzi frecvente pot avea răspunsuri diferite. Aceste obiective determină frecvența copiilor, retenția și modul de restaurare; nu pot fi deduse doar din existența unui buton Backup.

Într-un mediu separat, restaurează aplicația și un set de date fictive. Verifică pornirea, o autentificare de test, un fișier încărcat și operația principală a produsului. Notează durata, pașii manuali și componentele lipsă. Dacă ai nevoie de o configurație pe care nimeni nu a salvat-o, proba a identificat o problemă reală înaintea unui incident.

Planul trebuie să includă și accesul la serviciile externe. O bază restaurată nu poate trimite emailuri dacă lipsesc configurările necesare, iar un domeniu expirat nu este reparat prin restaurarea serverului. Distinge datele care pot fi recreate din cod de datele persistente care necesită copii. Păstrează dovada ultimei restaurări reușite și repetă proba după schimbări relevante.

Ce documente ceri la predare

Un dosar util conține schema componentelor, versiunile relevante, pașii de instalare și publicare, configurările necesare fără secrete expuse, procedura de backup și restaurare, probele de acceptare și contactele responsabile. Adaugă costurile fixe și variabile și indică cine primește alertele. Acest dosar trebuie să poată fi folosit de o altă persoană competentă, nu doar de autorul aplicației.

Pentru fiecare afirmație importantă cere o dovadă potrivită. „Se poate restaura” cere rezultatul unei restaurări. „Suportă încărcarea estimată” cere un scenariu și măsurători. „Datele clienților sunt separate” cere verificări de acces. Nu toate dovezile trebuie publicate, dar proprietarul proiectului trebuie să le poată consulta și să înțeleagă limitele lor.

Portofoliul este un început al conversației comerciale. Decizia tehnică se bazează pe cerințele proiectului tău, pe responsabilități și pe probe. Dacă două propuneri folosesc tehnologii diferite, compară rezultatul operațional promis și metoda prin care va fi verificat. Astfel poți discuta concret despre infrastructură fără să atribui clienților configurații sau performanțe care nu sunt documentate public.