Politica noastră de retenție a șters versiunea la care trebuia să revenim

O lansare de software într-o după-amiază de vineri a dus la o creștere rapidă a ratelor de eroare, necesitând o revenire imediată. Cu toate acestea, revenirea a eșuat deoarece imaginea specifică necesară pentru a reveni la o stare stabilă fusese ștearsă de o politică automată de ciclu de viață pe registrul de containere. Această politică, menită să păstreze cele mai recente zece imagini, devenise prea agresivă din cauza frecvenței crescute a construirilor, incluzând reconstruiri nocturne ale dependențelor și construirile de previzualizare per ramură, ștergând astfel imagini de producție mai vechi, dar necesare, într-un interval de timp mult mai scurt decât se anticipase.

Politica învechită, care fusese în vigoare timp de doi ani fără revizuire, a șters versiunea de producție care fusese stabilă de luni, miercuri seara. În consecință, echipa a trebuit să implementeze o corecție prin avansarea implementării în loc de o revenire, implicând o revizuire rapidă și o perioadă de serviciu degradat. Această situație a subliniat o defecțiune critică în procedurile lor de implementare și revenire, unde un proces automat de curățare a eliminat neintenționat active esențiale de recuperare.

Pentru a remedia acest lucru, echipa a implementat mai multe modificări: pipeline-ul de implementare aplică acum o etichetă imuabilă imaginilor de producție, care este exclusă din politica de ciclu de viață, iar reguli separate păstrează imaginile implementate timp de un an. Imaginile de previzualizare și de ramură expiră acum după șapte zile, iar un job programat verifică prezența și posibilitatea de preluare a imaginilor de producție curente și anterioare, acționând ca o repetiție pentru revenire. Această măsură proactivă a identificat alte servicii cu versiuni anterioare lipsă, subliniind fragilitatea mecanismelor lor anterioare de recuperare.