Un timeout nu este un buton de oprire

Orice comandă la distanță are nevoie de un termen-limită. Partea aceasta nu este contestată de nimeni: un proces care poate aștepta la nesfârșit va ajunge să aștepte la nesfârșit, iar o singură cerere blocată va ține ocupat un lucrător, o conexiune și un rând din coada dumneavoastră până când cineva repornește ceva.

Mult mai puțin evident este ce face de fapt acel termen-limită. El încheie așteptarea de partea dumneavoastră. Nu încheie, în cazul general, lucrarea de cealaltă parte. Tot ce este dificil la operațiunile de lungă durată trăiește în acest interval.

Noi rulăm un agent pe hipervizoarele clienților și îi trimitem comenzi. Copia de siguranță a unei mașini virtuale este comanda care ne-a făcut să luăm intervalul în serios, pentru că o copiere de siguranță poate dura sincer o oră, iar o oră este exact acolo unde se află propriile noastre limite.

Plafonul nu este o preferință

Agentul nostru limitează fiecare termen-limită de comandă la o oră. Platforma poate cere mai mult; nu va primi. Limitarea este un singur min() aplicat valorii care sosește în cerere, cu zero interpretat drept „nesetat” și cu o valoare implicită de două minute atunci când câmpul lipsește.

Limitarea aceasta are o consecință pe care oamenii o scapă din vedere când setează timeouturi într-un fișier de configurare. Dacă platforma crede într-un termen-limită în care agentul nu crede, aveți două sisteme care nu sunt de acord asupra momentului în care o comandă este moartă, iar dezacordul apare sub forma celui mai rău simptom cu putință: agentul renunță, raportează și merge mai departe, în timp ce platforma încă ține rândul deschis și așteaptă un răspuns care nu va veni niciodată în forma pe care o așteaptă.

Așa că regula la care am ajuns este plicticoasă și merită totuși scrisă. Fiecare timeout de partea platformei este ales cu plafonul agentului de față. Termenele noastre pentru copiere de siguranță și pentru restaurare sunt de o oră tocmai pentru că acela este plafonul, iar din câteva zeci de termene-limită de comandă ele sunt singurele două care îl ating.

Termenele-limită nu sunt o chestiune de stil

Iată cum arată de fapt termenele noastre de comandă și de ce fiecare este ce este.

Două dintre rândurile acelea sunt mai degrabă povești decât numere.

Cel cu mașina din cloud cădea înainte pe valoarea implicită de două minute. Două minute ajung pentru o imagine care se întâmplă să fie la zi și nu ajung pentru nimic altceva, așa că platforma raporta un eșec în timp ce instalarea din interiorul mașinii mergea mai departe și se încheia câteva minute mai târziu. Comanda era marcată drept eșuată. Mașina funcționa. Acesta este cel mai rău fel de greșeală: nu o eroare, ci o contradicție, iar clientul este cel care trebuie să o rezolve.

Cel cu migrarea este cel mai lung termen-limită care nu este plafonul agentului, iar raționamentul din spatele lui este o numărătoare și nu o impresie. Migratorul face un apel de API pentru fiecare utilizator și unul pentru fiecare server către panoul de destinație. La o mie de servere înseamnă o mie de apeluri duse și o mie de răspunsuri întoarse, cu o citire completă a ambelor părți înainte și cu o renumărare după.

Costurile greșelii nu sunt simetrice

Acesta este principiul de sub ambele povești. Un termen-limită prea scurt și unul prea lung eșuează în feluri complet diferite, iar tratarea lor ca două capete ale aceluiași buton vă dă de fiecare dată numărul greșit.

Prea lung: o operațiune care a murit cu adevărat ține un rând deschis încă o vreme. Cineva așteaptă. Nimic nu este corupt, nimic nu este duplicat, iar curățenia de la final se face fără incidente.

Prea scurt: consemnați un eșec pentru o lucrare care a reușit. Acum evidențele dumneavoastră și realitatea nu mai sunt de acord, iar fiecare traseu de recuperare pe care îl aveți, adică reîncercarea, recrearea, rambursarea, alerta, este îndreptat către o problemă care nu există și va crea o a doua.

Acestea nu sunt la fel de rele, deci nu ar trebui să primească marje la fel de mari. Pentru orice creează, mută sau șterge resurse reale, alegem în mod deliberat partea generoasă și scriem de ce.

Două ceasuri care pornesc în momente diferite

Există o subtilitate în orice sistem de comenzi cu coadă, ușor de trecut cu vederea și ușor de măsurat. Platforma noastră calculează termenul-limită ca moment absolut, în clipa în care rândul comenzii este scris. Agentul își calculează termenul ca durată, pornind când începe execuția.

Acestea sunt ceasuri diferite. Dacă agentul este deconectat, sau ocupat, sau dacă comanda stă treizeci de secunde în coadă, platforma a cheltuit deja treizeci de secunde din bugetul ei, iar agentul nu. Platforma renunță prima.

Aceasta este ordinea corectă și merită spus explicit de ce. Termenul platformei răspunde întrebării pe care clientul o pune de fapt: cât a trecut de când am apăsat? Cel al agentului răspunde alteia: cât timp are voie să ruleze această bucată de lucrare? Timpul scurs de la clic este numărul despre care se poartă o discuție de asistență. Să le facem același număr ar fi mai îngrijit și ar răspunde la întrebarea greșită.

Un al treilea ceas se ascunde tot acolo. La agentul nostru, așteptarea unui permis de concurență se petrece în afara termenului de execuție. O comandă pusă la coadă în spatele altei comenzi către aceeași integrare nu își arde propriul buget cât timp așteaptă. Dacă termenele dumneavoastră sunt strânse, verificați care dintre ceasuri include așteptarea în coadă; răspunsul este rareori cel din documentație.

Ce anulează de fapt termenul-limită

Când termenul agentului expiră, el semnalează anularea și încetează să aștepte. Ceea ce atinge acea anulare este propriul dumneavoastră cod: bucla de interogare care întreba hipervizorul cum merge sarcina.

Ea nu ajunge la hipervizor. Copierea de siguranță merge mai departe. Se va încheia, sau va eșua, complet fără noi. Nimic din anulare nu a coborât până la sistemul de stocare.

Aceasta nu este o limitare de eliminat prin inginerie. Este forma sinceră a problemei, iar mișcarea utilă este să consemnați rezultatul cu adevărat, în loc să vă prefaceți. Taxonomia care a supraviețuit contactului cu producția are trei rezultate, nu două.

• Eșuat. Știm că nu s-a întâmplat nimic. Clientul poate reîncerca și nu este nimic de curățat.
• Necunoscut. Am încetat să ascultăm înainte să existe un răspuns. Ceva poate exista.
• Necesită reconciliere. Avem motive pozitive să credem că există ceva de care nu putem da socoteală.

O restaurare care depășește termenul este cazul cel mai ascuțit. Se poate să existe acum, la hipervizor, o mașină pentru care baza noastră de date nu are niciun rând. Să o marcăm drept eșuată ar fi o minciună care ascunde o mașină; să o marcăm drept reușită ar fi o minciună care inventează una. Este marcată drept ceva ce necesită o privire, iar panoul îi cere clientului să verifice, în loc să îi ofere un buton de reîncercare care ar construi o a doua mașină lângă prima.

Am pus regula aceea în cod ca listă a cazurilor sigure, nu a celor nesigure. Patru coduri de eroare anume înseamnă că lucrarea nu a început niciodată, pentru că toate patru vin din verificări pe care agentul le face înainte de primul apel. Tot restul, inclusiv orice cod de eroare pe care îl adăugăm mai târziu și uităm să îl clasificăm, cade implicit în nesigur. Direcția contează: un cod uitat care se înregistrează în tăcere drept eșec face ca o mașină existentă să dispară din evidențe, iar un cod uitat care se înregistrează drept nesigur îl costă pe cineva doar o privire.

Un rezultat nesigur are nevoie de o cale spre certitudine

Un statut care înseamnă „cineva ar trebui să verifice” este sincer numai dacă cineva, sau ceva, chiar verifică. Al nostru este un lucrător care cere periodic fiecărei mașini cu istoric de copii de siguranță să își enumere din nou punctele de restaurare, astfel încât o arhivă care a dispărut în tăcere la furnizor devine o notificare și nu o listă care s-a scurtat în ziua în care s-a uitat din întâmplare un client.

Există o constrângere deliberată de ieftinătate pe bucla aceea, pentru că fiecare enumerare este o comandă care rulează pe gazda altcuiva. Ea vizitează numai mașinile care au o politică sau cel puțin un punct de restaurare cunoscut și ia un lot mărginit la fiecare rundă. Când asta nu mai ajunge, remediul corect este un cursor, nu un număr mai mare.

Bucla trebuie să supraviețuiască și situației în care două dintre serverele dumneavoastră hotărăsc să o ruleze în aceeași secundă. Facem asta cu o cheie durabilă de idempotență alcătuită din mașină și din numărul ferestrei, nu dintr-o marcă de timp: două servere nu bat niciodată în aceeași milisecundă, dar sunt cu siguranță în interiorul aceleiași ferestre de șase ore, așa că o marcă de timp nu ar deduplica nimic.

Ce v-am spune să scrieți

Dacă alegeți termene-limită pentru lucrări la distanță, patru întrebări vă duc pe cea mai mare parte a drumului.

1. 01Care este plafonul dur și cine îl impune? Dacă două componente nu sunt de acord, în practică învinge cea mai mică, iar cea mai mare este ficțiune.
2. 02Când pornește fiecare ceas? Timpul petrecut în coadă este ori în buget, ori nu, iar ambele răspunsuri se pot apăra. Să nu știți nu se poate apăra.
3. 03Ce anulează expirarea? Dacă răspunsul este „propria noastră așteptare”, spuneți-o cu voce tare, pentru că restul proiectării decurge de acolo.
4. 04De care parte cade un rezultat neclasificat? Faceți din incertitudine varianta implicită și lăsați certitudinea să fie lucrul pe care trebuie să îl scrieți.

Nimic din toate acestea nu scurtează o copiere de siguranță lungă. Face ca evidența ei să fie adevărată, iar aceea este partea pe care o veți citi la două noaptea.