Sistemul tău funcționează excelent. Până când lucrează persoana care știe de ce.
Compania are un sistem care a fost construit timp de șapte ani. Funcționează. Deservește clienții. Se conectează cu alte sisteme. Realizează procese fără de care, practic, compania nu ar putea funcționa normal.
În acești șapte ani, la proiect au lucrat cinci programatori. În plus, doi freelanceri și o agenție. O parte din documentație se află în Confluence, o parte pe Google Drive, o parte în ticketuri. Mai există pe undeva un document vechi privind una dintre integrări. Iar când cineva întreabă de ce un anumit fragment al sistemului funcționează exact așa, răspunsul este: "Cred că Mihai își amintea."
Mihai a plecat acum trei ani.
Și exact atunci începe adevărata problemă.
Nu pentru că sistemul este prost scris. Nu pentru că a încetat brusc să funcționeze. Problema este că firma a încetat să mai dețină cunoașterea completă despre propriul ei sistem.
Sistemul funcționează, dar firma poate să nu îl controleze
Aceasta este una dintre cele mai subestimate forme de datorie tehnologică.
Când vorbim despre datorie tehnologică, de obicei ne gândim la cod vechi, biblioteci neactualizate, erori de arhitectură, lipsa testelor sau soluții care cândva erau rapide, dar astăzi îngreunează dezvoltarea.
Între timp, mai există încă un alt tip de datorie. Datoria de cunoaștere.
Ea apare atunci când sistemul depinde de informații care nu se află în documentație, în repository, în proceduri sau în organizație, ci doar în mințile unor persoane concrete.
Iar atâta timp cât acele persoane sunt disponibile, totul poate părea normal.
Problema apare la schimbarea echipei, plecarea programatorului, încheierea colaborării cu un software house, căderea serverului, schimbarea administratorului sau necesitatea implementării rapide a unei noi soluții.
Dintr-odată se dovedește că firma are cod, dar nu are cunoaștere.
Are server, dar nu știe cine are acces.
Are o integrare, dar nu se știe pe ce cont a fost creată.
Are documentație, dar nu se știe care versiune este actuală.
Are proces, dar nu se știe de ce a fost proiectat exact așa.
Și atunci apare foarte repede întrebarea: cine este, de fapt, proprietarul acestui sistem?
Bus factor, adică ce se întâmplă dacă dispare o persoană?
În lumea IT există conceptul de bus factor. Simplificat, el înseamnă numărul de persoane a căror indisponibilitate poate face ca echipa să nu mai fie capabilă să dezvolte sau să întrețină eficient proiectul.
Nu este vorba, desigur, despre un eveniment literal. Este o modalitate de a gândi despre concentrarea cunoașterii.
Dacă doar o singură persoană știe cum funcționează o integrare critică, bus factor pentru acea cunoaștere este unu.
Dacă doar un singur administrator are acces la producție, bus factor este unu.
Dacă doar un singur om știe de ce sistemul execută un anumit proces în fiecare noapte, bus factor poate fi unu.
Dacă firma colaborează cu un software house extern, iar din partea clientului nimeni nu înțelege arhitectura soluției, apare o problemă și mai mare - cunoașterea poate fi în afara organizației.
Asta nu înseamnă că fiecare firmă trebuie să aibă cinci experți pentru fiecare fragment al sistemului.
Este vorba despre ceva mult mai simplu: firma ar trebui să știe unde se află cunoașterea critică și dacă o poate recupera fără o anumită persoană.
Codul spune cum. Nu spune întotdeauna de ce.
Un programator poate citi codul și poate înțelege ce face o anumită funcție.
Nu va ști întotdeauna însă, de ce a fost scrisă exact în acest fel.
Este o diferență uriașă.
Se poate găsi fragmentul responsabil de trimiterea datelor către un sistem extern. Se poate analiza endpoint-ul, parametrii, autorizarea și gestionarea erorilor.
Dar codul nu va răspunde neapărat la întrebările:
- De ce trimitem datele la ora 2:00 noaptea?
- De ce este omis acest status anume?
- De ce, după o eroare, sistemul reîncearcă exact de trei ori?
- De ce o valoare este recalculată înainte de trimitere?
- De ce nu se poate schimba ordinea acestor operațiuni?
- De ce folosește această integrare un anumit cont?
Răspunsul se poate afla în istoria proiectului, într-un ticket vechi, într-un email de acum șase ani sau - și mai rău - doar în memoria omului care nu mai lucrează în firmă.
De aceea, o documentație bună nu ar trebui să fie doar un ghid despre "ce să dai click".
Ar trebui să păstreze, de asemenea, contextul și deciziile.
Cea mai mare problemă poate fi integrarea de care nimeni nu-și mai amintește
Un sistem modern aproape niciodată nu funcționează complet de sine stătător.
Se conectează cu sistemul ERP. CRM. Gateway-ul de plăți. Furnizorul de SMS. Sistemul de curierat. API-ul partenerului. Serviciul cloud. Platforma de analiză. Sistemul contabil. Mecanismul de autorizare.
Fiecare astfel de conexiune este o parte a lanțului tehnologic.
Și fiecare parte a acestui lanț poate avea propriul proprietar, cont, cheie API, certificat, contract, limită, versiune API și ciclu de viață.
După câțiva ani, nimeni nu-și mai poate aminti cine a creat acel cont.
Iar atunci este suficient să expire certificatul sau să se schimbe API-ul pentru ca sistemul să înceteze să funcționeze.
Și mai rău este dacă firma nici măcar nu știe că o anumită dependență există.
De aceea, într-o abordare matură a sistemelor, capătă o importanță tot mai mare proveniența software-ului, gestionarea dependențelor și transparența lanțului de aprovizionare al software-ului. NIST, în materialele sale actuale privind securitatea lanțului de aprovizionare, indică printre altele importanța informațiilor despre componente, originea lor, ciclul de viață și dependențele. SBOM, adică Software Bill of Materials, este unul dintre instrumentele care permit organizarea cunoașterii despre din ce componente este alcătuit software-ul.
Acesta nu mai este de mult un subiect exclusiv pentru echipa de security.
Este și un subiect pentru conducere.
Pentru că, dacă firma nu știe din ce este construit sistemul ei, îi este mai greu să evalueze riscul, costul de întreținere și consecințele schimbărilor.
Documentația nu este un cost. Este o poliță.
În multe firme, documentația este tratată ca ceva ce "se va face mai târziu".
Mai întâi funcționalitatea.
Apoi implementarea.
Apoi corecțiile.
Apoi următorul proiect.
Iar documentația?
"Când va fi timp."
Problema este că timpul pentru documentație apare, de obicei, exact atunci când este deja prea târziu.
Documentația ar trebui să funcționeze ca o asigurare de business. Nu pentru că cineva o va citi zilnic. Dimpotrivă - ideal ar fi să fie nevoie de ea cât mai rar posibil într-o situație de urgență.
Dar când apare o problemă, firma ar trebui să poată răspunde la întrebările de bază:
- Cum funcționează sistemul?
- Din ce este alcătuit?
- Unde se află mediul de producție?
- Cine are acces?
- Care sunt integrările critice?
- Ce conturi și servicii externe sunt utilizate?
- Care sunt dependențele?
- Cum se fac backupurile?
- Cum arată procesul de implementare?
- Ce se întâmplă în timpul unei avarii?
- Care elemente sunt critice pentru business?
- De ce au fost luate deciziile arhitecturale cheie?
- Cine poate prelua întreținerea sistemului?
Asta nu trebuie să însemne sute de pagini de documentație.
O documentație bună trebuie să fie înainte de toate utilă, actualizată și disponibilă pentru persoanele potrivite.
„Să nu umblăm, pentru că merge” nu este întotdeauna o decizie proastă
Mai există o problemă foarte frecventă.
Sistemul funcționează de ani de zile, așa că firma adoptă regula: „Nu umblăm. Merge.”
Și uneori acest lucru este absolut rezonabil.
Nu orice tehnologie veche necesită înlocuire imediată. Nu orice fragment de cod mai vechi trebuie rescris. Nu orice bibliotecă înseamnă o catastrofă. Nu orice arhitectură de acum câțiva ani este greșită.
Problema începe atunci când „să nu umblăm” înseamnă și:
- „Să nu analizăm.”
- „Să nu documentăm.”
- „Să nu verificăm dependențele.”
- „Să nu întrebăm cine are acces.”
- „Să nu verificăm dacă mai avem toate conturile.”
- „Să nu stabilim ce se întâmplă dacă executantul actual nu mai este disponibil.”
Atunci lipsa schimbărilor nu este o strategie.
Este amânarea riscului.
Uneori, cea mai bună decizie tehnică este într-adevăr să nu reconstruiești nimic.
Dar această decizie ar trebui să rezulte din cunoașterea sistemului, nu din lipsa cunoașterii sistemului.
Ce ar trebui să includă un audit al unui sistem moștenit?
Când o firmă preia un sistem de la o altă firmă de software, de la un freelancer sau de la o echipă internă, primul pas nu ar trebui să fie rescrierea automată a totului.
Mai întâi trebuie înțeles ce anume a fost preluat.
Auditul ar trebui să răspundă cel puțin la câteva domenii de bază.
Arhitectura. Cum este construit sistemul? Care sunt componentele sale principale? Unde se află datele? Cum comunică elementele individuale?
Cod și repository-uri. Compania deține codul sursă complet? Se știe care ramură și care versiune sunt în producție? Poate fi reprodus procesul de build și implementare?
Infrastructura. Unde rulează producția? Cum arată mediul de test? Cine are acces? Cum arată monitorizarea și backupul?
Integrările. Cu ce comunică sistemul? Ce API-uri folosește? Cine este proprietarul conturilor și cheilor individuale?
Dependențele. Ce biblioteci, frameworkuri și componente externe sunt utilizate? Sunt actualizate? Au probleme de securitate cunoscute? Cum arată ciclul lor de viață?
Procesul de implementare. O persoană nouă poate pregăti, testa și implementa o schimbare fără să-l sune pe fostul programator?
Cunoașterea. Ce se află în documentație și ce există încă doar în mintea oamenilor?
Riscul de business. Ce se întâmplă dacă o anumită componentă încetează să funcționeze timp de o oră, o zi sau o săptămână?
Abordarea modernă privind securitatea lanțului de aprovizionare al software-ului subliniază din ce în ce mai mult tocmai nevoia de a cunoaște componentele, furnizorii, dependențele, originea lor și ciclul de viață. NIST indică, de asemenea, importanța due diligence-ului față de furnizorii de tehnologie și a evaluării rezilienței și riscului asociat întregului lanț de aprovizionare.
Auditul nu înseamnă „să rescriem sistemul de la zero”
Acest lucru este important, deoarece un audit tehnic este adesea confundat greșit cu reconstruirea.
Între timp, auditul se poate încheia cu o concluzie foarte simplă: „Sistemul este în regulă. Trebuie doar să organizăm cunoștințele și să eliminăm câteva riscuri.”
Se poate dovedi și că sistemul are nevoie de modernizare doar într-un singur domeniu.
Sau că cea mai mare problemă nu este codul, ci lipsa accesului la infrastructură.
Sau că aplicația este bine scrisă, dar nimeni nu are cunoștințe actuale despre procesul de implementare.
Sau că totul funcționează, dar firma depinde de un singur furnizor extern.
De aceea, o analiză bună a unui proiect moștenit ar trebui să răspundă la întrebarea: „Ce trebuie cu adevărat schimbat și ce nu trebuie atins?”
Abia atunci pot fi luate decizii de investiții.
Și dacă schimbi firma de software?
Acesta este unul dintre momentele în care problema datoriei de cunoaștere invizibile iese la iveală.
Firma încheie colaborarea cu executantul.
Noul partener primește repository-ul.
Și începe să pună întrebări:
- „Unde este producția?”
- „Cum pornesc proiectul local?”
- „Care versiune este actuală?”
- „La ce servește acest serviciu?”
- „Cine deține contul pentru acest API?”
- „Ce face acest cron?”
- „De ce pornește acest proces la ora aceea?”
- „De unde luăm acest parametru?”
- „Ce se întâmplă dacă îl dezactivăm?”
Dacă răspunsul la majoritatea întrebărilor este „nu știm”, noua firmă de software nu preia proiectul. Mai întâi trebuie să-l descopere.
Iar descoperirea sistemului costă timp. Timp pe care apoi îl plătește clientul.
De aceea, predarea proiectului între echipe ar trebui să fie un proces, nu aruncarea unui ZIP cu codul și parola pentru un singur cont.
Sistemul trebuie să supraviețuiască oamenilor
Aceasta este probabil cea mai importantă regulă.
Oamenii se schimbă. Programatorii își schimbă joburile. Freelancerii încheie colaborările. Firmele de software își schimbă clienții. Administratorii trec la alte companii. Conducerile se schimbă.
Sistemul rămâne.
De aceea, sistemul ar trebui proiectat astfel încât cunoștințele necesare pentru întreținerea lui să poată fi recuperate.
Asta nu înseamnă că fiecare angajat trebuie să știe totul.
Înseamnă că organizația ar trebui să aibă un mecanism de păstrare a cunoștințelor:
- Repository-uri.
- Documentație.
- Registrul integrărilor.
- Informații despre infrastructură.
- Accese gestionate de companie.
- Descrierea proceselor cheie.
- Istoricul deciziilor importante.
- Informații despre dependențe.
- Proceduri de urgență.
- Și, mai presus de toate, oameni care știu să folosească această documentație.
NIST, în ghidurile actuale privind planificarea securității sistemelor, atrage de asemenea atenția asupra definirii formale a responsabilității, a statutului operațional al sistemului și a rolurilor persoanelor care administrează, susțin sau au acces la sistem.
Asta arată o schimbare mai amplă în modul de a gândi tehnologia.
Sistemul nu este doar cod. Sistemul înseamnă și oameni, procese, infrastructură, dependențe, date, acces și responsabilitate.
La Web24 începem adesea chiar cu întrebarea: „Ce avem de fapt aici?”
Preluarea unui proiect existent nu ar trebui să înceapă cu promisiunea că totul va fi rescris de la zero.
Ar trebui să înceapă cu înțelegerea situației:
- Ce funcționează?
- Ce nu funcționează?
- Ce este critic?
- Ce este depășit?
- Unde sunt cele mai mari riscuri?
- Ce lipsește din documentație?
- Ce dependențe sunt invizibile?
- Se poate dezvolta în siguranță sistemul existent?
- Este nevoie de modernizare sau doar de organizare?
Abia apoi se poate decide dacă proiectul trebuie dezvoltat, reconstruit, rescris parțial sau pur și simplu documentat bine.
Acest lucru este deosebit de important în proiectele care au fost dezvoltate timp de ani de zile de persoane și companii diferite.
Pentru că un bun partener tehnologic nu ar trebui să fie necesar doar pentru că numai el știe cum funcționează sistemul.
Ar trebui să fie necesar pentru că poate dezvolta, securiza și transmite mai departe cunoștințele despre acest sistem.
Cea mai periculoasă greșeală poate fi omul care a plecat deja
Nu întotdeauna problema este codul vechi.
Nu întotdeauna problema este tehnologia învechită.
Nu întotdeauna problema este lipsa celui mai nou framework.
Uneori, cel mai mare risc este informația pe care nimeni nu a notat-o.
Un singur mesaj.
O singură decizie arhitecturală.
O singură integrare.
O singură excepție în proces.
Un singur om care, ani la rând, a știut cum funcționează.
Iar apoi a plecat.
De aceea merită să-ți pui astăzi o întrebare foarte simplă: Dacă mâine din firmă ar dispărea persoana care cunoaște cel mai bine sistemul vostru, ați mai putea să-l administrați?
Dacă răspunsul este "da" - excelent.
Dacă răspunsul este "nu știu" - merită verificat.
Iar dacă răspunsul este "categoric nu" - probabil tocmai ați identificat una dintre cele mai importante zone de risc tehnologic din firma voastră.
Sistemul ar trebui să fie mai mare decât memoria unei singure persoane.
