Lista de verificare la preluarea unei aplicații: ce inspectați înainte

Înainte să acceptați responsabilitatea pentru un sistem construit de altcineva, inspectați-l. Aceasta este lista pe care o folosește AL+ la preluarea aplicațiilor. Este scrisă astfel încât un fondator, un director tehnic sau o echipă care preia sistemul s-o poată folosi și fără noi. Parcurgeți-o în ordine; primele secțiuni vă apără de defecțiunile care nu se mai pot repara.

Lista are opt părți. Fiecare punct este o întrebare cu răspuns „da” sau „nu”. Un „nu” nu e un motiv să refuzați sistemul. Este un rând în plan.

1. Accesul și proprietatea

Cea mai frecventă problemă la preluare este să descoperiți, după săptămâni, că un cont critic aparține cuiva care a plecat.

Codul sursă se află într-un depozit deținut de firma dumneavoastră, iar drepturile de administrator aparțin firmei?
Aveți acces de proprietar la găzduire, DNS, registrarul de domenii, bazele de date, stocarea de obiecte și CDN?
Trimiterea de e-mailuri, furnizorii de plăți, API-urile terțe, conturile din magazinele de aplicații și monitorizarea sunt înregistrate pe adrese ale firmei, nu pe adrese personale?
Unde sunt păstrate secretele și puteți schimba fiecare credențială pe care a avut-o dezvoltatorul anterior, fără întreruperea serviciului?
Care conturi sunt plătite, de pe ce card și când se reînnoiește sau expiră fiecare?
Există licențe (fonturi, biblioteci, licențe per utilizator în servicii SaaS, hărți) care vor expira când se închid conturile echipei anterioare?

Dacă un răspuns este „nu știm”, opriți-vă și aflați înainte să modificați ceva.

2. Realitatea din producție

Depozitul de cod arată ce s-a intenționat. Producția arată ce este adevărat.

Ce este publicat acum, din ce versiune de cod, și corespunde ramurii principale?
Cum se publică? Manual, printr-un script, printr-un flux automat? Puteți repeta procedura?
Ce rulează după un program: sarcini cron, cozi, funcții programate, webhook-uri? Unde sunt configurate?
Ce servicii externe apelează sistemul și care îl apelează pe el?
Ce arată logurile și instrumentele de urmărire a erorilor că a eșuat pe tăcute?
Ce alte medii există în afară de producție? Există un mediu de probă asemănător cu ea?

3. Datele

Datele sunt partea dintr-un sistem pe care nu o puteți regenera.

Unde se află datele: baze de date, fișiere, servicii terțe, foi de calcul?
Cât de mari sunt și cât de repede cresc?
Când a fost ultima copie de siguranță și a fost vreodată restaurată undeva și verificată?
Ce date personale sunt păstrate, pe ce temei juridic și unde este documentat?
Există migrări în așteptare, aplicate pe jumătate sau aplicate manual?
Puteți exporta datele într-o formă pe care o puteți muta în alt sistem?

Restaurați o copie de siguranță într-un loc sigur în timpul analizei. O copie de siguranță care nu a fost niciodată restaurată este o speranță, nu o copie de siguranță.

4. Siguranța modificărilor

Va trebui să modificați sistemul. Aflați cât de periculos este acest lucru.

Puteți rula sistemul pe calculatorul unui dezvoltator, pornind doar de la depozitul de cod?
Există teste? Trec? Ce acoperă?
Există o etapă de revizuire înainte ca schimbările să ajungă în producție?
O versiune proastă poate fi retrasă, iar acest lucru s-a mai făcut?
O modificare banală (o greșeală de scriere în subsol) parcurge tot traseul în mai puțin de o zi?

Dacă răspunsul la ultima întrebare este „nu”, repararea acestui traseu este prima sarcină tehnică, înaintea oricărei funcționalități.

5. Dependențe și platformă

Care sunt versiunile mediului de execuție, ale framework-ului și ale bazei de date, și când ajunge fiecare la sfârșitul suportului?
Câte dependențe există, cât de vechi sunt și care nu mai sunt întreținute?
Au vreuna vulnerabilități cunoscute?
Când a fost ultima actualizare și ce s-a stricat?
Este ceva fixat la o anumită versiune dintr-un motiv pe care nu și-l mai amintește nimeni?

6. Securitatea de bază

Aceasta nu este un test de penetrare. Este minimul pe care trebuie să-l știți înainte să preluați sistemul.

Autorizarea se aplică pe server sau doar în interfață?
Sunt secrete în cod sau în istoricul depozitului?
Datele introduse de utilizator sunt validate înainte să ajungă în baza de date sau în shell?
Cine are acces la producție și este acest acces individual și revocabil?
Mai sunt activate puncte de acces administrative, moduri de depanare sau credențiale implicite?
Comunicarea este criptată peste tot, inclusiv între servicii?

7. Cunoștințele

Dezvoltatorul anterior poate fi contactat și acceptă să răspundă la întrebări contra cost?
Există o descriere scrisă a arhitecturii, a publicării sau a motivelor din spatele deciziilor majore?
Ce părți ale sistemului nu le înțelege nimeni în prezent?
La ce părți se feresc toți să se atingă, și de ce?
Ce incidente au avut loc în ultimul an și cum au fost rezolvate?

Întrebați despre decizii, nu despre cod: de ce această bază de date, de ce această găzduire, ce ar schimba, de ce se temeau. Notați răspunsurile.

8. Cost și potrivire

Cât costă sistemul pe lună în găzduire, licențe și servicii terțe?
Cât timp de lucru tehnic cere menținerea lui în funcțiune astăzi?
De ce are nevoie firma de la el în următoarele douăsprezece luni?
Servește vreo parte mare din el un caz de utilizare care nu mai există?
Este un sistem de păstrat, de modernizat pe loc sau de înlocuit? Răspunsul vine din primele șapte secțiuni, nu din prima întâlnire.

Cum folosiți rezultatul

Scrieți răspunsurile într-un singur document, cu o listă a răspunsurilor „nu” ordonată după risc. Ordinea aceasta devine primele săptămâni de lucru: mai întâi accesele și facturarea, apoi copiile de siguranță și publicările, apoi părțile fragile, apoi cele dorite. O preluare făcută în această ordine le arată celor din firmă o funcționalitate nouă mai târziu decât sperau și nicio pană de funcționare.

Dacă preferați să facem noi această analiză și să preluăm apoi sistemul, acesta este serviciul nostru de preluare a aplicațiilor. Dacă vreți s-o parcurgeți singuri, lista vă aparține.