Lista de verificare a pregătirii producției

Traducerea articolului a fost pregătită special pentru studenții cursului „Practici și instrumente DevOps”, care începe astăzi!

Ați lansat vreodată un nou serviciu în producție? Sau poate ai fost implicat în susținerea unor astfel de servicii? Dacă da, ce te-a motivat? Ce este bun pentru producție și ce este rău? Cum instruiți noi membri ai echipei cu privire la lansări sau întreținerea serviciilor existente.

Majoritatea companiilor ajung să adopte abordări „Wild West” atunci când vine vorba de practicile de operare industrială. Fiecare echipă decide cu privire la propriile instrumente și bune practici prin încercări și erori. Dar acest lucru afectează adesea nu numai succesul proiectelor, ci și inginerii.

Încercarea și eroarea creează un mediu în care arătarea cu degetul și schimbarea vinei sunt comune. Cu acest comportament, devine din ce în ce mai dificil să înveți din greșeli și să nu le mai repete.

Organizații de succes:

• să realizeze nevoia de linii directoare pentru producție,
• studiază cele mai bune practici,
• începe discuții cu privire la problemele de pregătire a producției atunci când dezvoltă noi sisteme sau componente;
• asigura respectarea regulilor de pregatire pentru productie.

Pregătirea pentru producție include un proces de „revizuire”. Revizuirea poate fi sub forma unei liste de verificare sau a unui set de întrebări. Evaluările pot fi făcute manual, automat sau ambele. În loc de liste statice de cerințe, puteți crea șabloane de liste de verificare care pot fi adaptate nevoilor specifice. În acest fel, inginerilor li se poate oferi o modalitate de a moșteni cunoștințe și suficientă flexibilitate atunci când este necesar.

Când să verificați un serviciu pentru pregătirea pentru producție?

Este util să efectuați o verificare a pregătirii producției nu numai imediat înainte de lansare, ci și atunci când o transferați unei alte echipe de operațiuni sau unui nou angajat.

Verificați când:

• Lansați un nou serviciu în producție.
• Transferați funcționarea serviciului de producție către o altă echipă, cum ar fi SRE.
• Transferați funcționarea serviciului de producție către noii angajați.
• Organizați suport tehnic.

Lista de verificare a pregătirii producției

Cu ceva timp în urmă, ca exemplu, eu а publicat lista de verificare pentru testarea pregătirii pentru producție. Deși această listă provine de la clienții Google Cloud, va fi utilă și aplicabilă în afara Google Cloud.

Design și dezvoltare

• Dezvoltați un proces de construire repetabil care nu necesită acces la servicii externe și nu depinde de defecțiunea sistemelor externe.
• În timpul perioadei de proiectare și dezvoltare, definiți și setați SLO-uri pentru serviciile dvs.
• Documentați așteptările privind disponibilitatea serviciilor externe de care depindeți.
• Evitați un singur punct de eșec prin eliminarea dependențelor de o singură resursă globală. Replicați resursa sau utilizați o rezervă atunci când resursa nu este disponibilă (de exemplu, o valoare codificată).

Managementul configurației

• Configurația statică, mică și non-secretă poate fi transmisă prin intermediul parametrilor liniei de comandă. Pentru orice altceva, utilizați serviciile de stocare de configurare.
• O configurație dinamică trebuie să aibă setări de rezervă în cazul în care serviciul de configurare nu este disponibil.
• Configurația mediului de dezvoltare nu ar trebui să fie legată de configurația de producție. În caz contrar, acest lucru poate duce la accesul din mediul de dezvoltare la serviciile de producție, ceea ce poate cauza probleme de confidențialitate și scurgeri de date.
• Documentați ce poate fi configurat dinamic și descrieți comportamentul alternativ dacă sistemul de livrare a configurației nu este disponibil.

Managementul lansărilor

• Documentați procesul de lansare în detaliu. Descrieți modul în care lansările afectează SLO-urile (de exemplu, creșteri temporare ale latenței din cauza erorilor de cache).
• Documentează eliberările canare.
• Dezvoltați un plan de revizuire a lansării Canary și, dacă este posibil, mecanisme automate de retragere.
• Asigurați-vă că rollback-urile pot folosi aceleași procese ca și implementările.

Observabilitate

• Asigurați-vă că setul de valori necesare pentru SLO este colectat.
• Asigurați-vă că puteți face diferența între datele client și server. Acest lucru este important pentru a găsi cauzele defecțiunilor.
• Configurați alerte pentru a reduce costurile cu forța de muncă. De exemplu, eliminați alertele cauzate de operațiuni de rutină.
• Dacă utilizați Stackdriver, includeți valorile platformei GCP în tablourile de bord. Configurați alerte pentru dependențele GCP.
• Propagați întotdeauna urmele primite. Chiar dacă nu sunteți implicat în urmărire, acest lucru va permite serviciilor de nivel inferior să depaneze problemele în producție.

Protectie si siguranta

• Asigurați-vă că toate conexiunile externe sunt criptate.
• Asigurați-vă că proiectele dvs. de producție au configurația IAM corectă.
• Utilizați rețele pentru a izola grupuri de instanțe de mașini virtuale.
• Utilizați un VPN pentru a vă conecta în siguranță la rețelele de la distanță.
• Documentați și monitorizați accesul utilizatorilor la date. Asigurați-vă că accesul tuturor utilizatorilor la date este auditat și înregistrat.
• Asigurați-vă că punctele finale de depanare sunt restricționate de ACL-uri.
• Dezinfectează intrarea utilizatorului. Configurați limitele de dimensiune a sarcinii utile pentru introducerea utilizatorului.
• Asigurați-vă că serviciul dvs. poate bloca în mod selectiv traficul de intrare pentru utilizatorii individuali. Acest lucru va bloca încălcările fără a afecta alți utilizatori.
• Evitați punctele finale externe care inițiază o mulțime de operațiuni interne.

Planificarea capacitatii

• Documentați modul în care se scalează serviciul dvs. De exemplu: numărul de utilizatori, dimensiunea sarcinii utile primite, numărul de mesaje primite.
• Documentați cerințele de resurse pentru serviciul dvs. De exemplu: numărul de instanțe de mașină virtuală dedicată, numărul de instanțe Spanner, hardware specializat, cum ar fi GPU sau TPU.
• Limitări ale resurselor documentului: tip de resursă, regiune etc.
• Documentați restricțiile de cotă pentru crearea de noi resurse. De exemplu, limitarea numărului de solicitări API GCE dacă utilizați API-ul pentru a crea instanțe noi.
• Luați în considerare efectuarea de teste de încărcare pentru a analiza degradarea performanței.

Asta e tot. Ne vedem la ore!

Sursa: www.habr.com