Separarea buzz-ului de taur: ce nu trebuie automatizat

Indiferent dacă sunteți lider DevOps, inginer de fiabilitate a site-ului, manager IT sau CTO, șansele sunt că automatizarea este destul de înrădăcinată în ceea ce faceți.

În multe privințe, termenii automatizare și DevOps sunt sinonimi. Și în ultimii ani, se simte că termenul a preluat controlul, deoarece soluțiile care au ca scop automatizarea ceva sunt aproape fără sfârșit.

Un raport recent de la Red Hat a constatat că companiile au automatizat în medie 36% din operațiunile lor în cloud. Cu cât o afacere a fost stabilită mai mult timp, cu atât procesele sale manuale au fost înlocuite cu fluxuri de lucru automatizate.

Există o varietate de motive pentru creșterea popularității automatizării:

• Companiile doresc operațiuni de dezvoltare concentrate pe sarcini esențiale
• Dorința de a accelera termenele pentru lansări
• Liderii doresc mai multă agilitate și colaborare din partea echipelor
• Sistemele manuale sunt notoriu predispuse la erori umane
• Există mai multă cerere pentru roluri IT, SRE și DevOps decât există oameni care să le ocupe

Automatizare – mai mult decât un cuvânt la modă?

Rewind s-a întâlnit recent cu diverși lideri în dezvoltarea software-ului despre experiențele lor de automatizare, cum se încadrează automatizarea în obiectivele echipei și cadrele pe care le folosesc pentru a lua decizii.

Scott Sturgeon, CTO la Tugboat Logic by One Trust, este sceptic. „Din perspectiva mea, automatizarea a devenit un cuvânt la modă. Nu totul poate fi automatizat într-un mod sănătos. Nu totul ar trebui să fie. Lucrurile care sunt repetitive și consumatoare de timp sunt lucrurile pe care tind să mă concentrez. Cea mai mare parte a automatizării despre care auziți în aceste zile se rezumă la CI/CD – integrare continuă, implementare continuă. Puteți construi conducte foarte complexe care vă pot actualiza automat instanța de producție. Ceea ce este grozav, dacă ești pregătit să faci asta în mod corespunzător.”

„Cred că automatizarea este un termen foarte generic și vrei să fii mai specific despre ceea ce vrei de fapt. Este o tehnică și o metodă, mai degrabă decât un rezultat”, explică Nigel Kersten, Field CTO la Puppet. Nu automatizezi de dragul automatizării, automatizezi pentru că încerci să obții un rezultat. De asemenea, cred că este un cuvânt bun de marketing pentru că rezonează cu oamenii de pe teren care cred: „Pot face roboții să o facă”. Așa că trebuie să fii precaut cu privire la modul în care folosești acel cuvânt.”

Ținând cont de această precauție, iată câteva sarcini de top care sunt adesea supra-automatizate sau complicate inutil de automatizare.

Ce să nu automatizezi

Deși majoritatea sarcinilor pot fi automatizate, asta nu înseamnă că ar trebui să fie. Iată câteva sfaturi rapide despre ceea ce poate fi eliminat din lista care urmează să fie automatizată :

• Sarcini cu o rentabilitate scăzută a investiției, în care volumul de efort necesar nu produce profituri semnificative
• Testarea experienței utilizatorului sau orice altceva în care aveți un rezultat subiectiv
• Sarcini în care există un grad foarte mare de imprevizibilitate
• Sarcini cu o cantitate redusă de repetabilitate
• Sarcini fără o procedură/un model bine definit

„Lucrurile pe care un computer nu le poate face bine nu ar trebui să fie automatizate. De exemplu, o mulțime de companii încearcă să automatizeze recenziile de cod”, explică Scott. „Este bine pentru lucruri care urmează sintaxă sau dependențe circulare ciudate. Un computer poate înțelege aceste lucruri. Cu toate acestea, a privi logica unei bucăți de cod și dacă este sau nu făcut corect nu este ceva ce un computer poate face bine. O revizuire a codului, în mintea mea, necesită totuși o persoană să se uite la asta.”

James Ciesielski, CTO la Rewind, extinde această abordare bazată pe risc a automatizării în dezvoltare. „Când vine vorba de a decide ce să automatizăm, evaluăm riscul de a implica oameni în menținerea unui proces. Am văzut medii de dezvoltare în care oamenilor li s-au acordat privilegii asemănătoare lui Dumnezeu pentru echipa de dezvoltare. Adesea, acest lucru se face în numele deservirii clienților, dar oamenii fac erori, intenționate și neintenționate.”

Cum să decideți ce are nevoie de automatizare

Realitatea este că multe companii vor trebui să automatizeze lucrurile care au impact direct sau indirect asupra produsului sau serviciului lor. Cazuri de utilizare unice pot apărea în orice mediu, mai ales pe măsură ce piețele devin mai competitive, mai multe companii SaaS sunt online, iar hărțile de parcurs devin mai ambițioase. Dar, așa cum vă va spune orice echipă de dezvoltare de pe planetă, lista lor de lucruri de făcut este incredibil de lungă. Ca echipă, cum prioritizați și vă puneți de acord cu ce să abordați în continuare?

Deși nu există o abordare universală a deciziei, iată câteva semnale pe care experții IT le folosesc pentru a evalua dacă un proces este un bun candidat pentru automatizare:

• Manual : ca și cum rulează manual un script care automatizează o sarcină. Deși scriptul poate fi mai rapid decât executarea efectivă a fiecărui pas manual, timpul necesar pentru a rula un script este încă timp care ar putea fi folosit în altă parte. Cu alte cuvinte, dacă trebuie să continui să apăs pe un buton, în cele din urmă s-ar putea să-mi petrec tot timpul apăsând acel buton.
• Repetitiv : după aproximativ a doua oară de a efectua aceeași sarcină, poate fi necesar să fie automatizat. Rezolvarea problemelor noi nu contează.
• Automatizat : dacă o mașină poate face aceeași treabă la fel de bine ca un om, poate fi considerată trudă. Dacă sarcina are nevoie de un om care să se gândească cu adevărat la lucruri, este posibil să nu fie un candidat bun.
• Tactic : Dacă ceva continuă să întrerupă echipa ta și o pune în modul „reacție”, minimizarea acestor distrageri ar putea fi ceva de rezolvat.
• Fără valoare durabilă: dacă îndeplinești o sarcină și produsul sau serviciul tău rămâne același, probabil că contribuie la trudă.
• Sarcinile cresc odată cu creșterea operațiunilor: dacă amploarea unei sarcini crește odată cu dimensiunea serviciului, volumul de trafic sau numărul de utilizatori, este probabil o problemă.

În cele din urmă, adesea un bun punct de plecare este găsirea proceselor (care adaugă valoare) pe care le faci frecvent și te bazezi pe un om. Când oamenii sunt implicați, șansele de eroare cresc exponențial.

Lena Feygin, liderul echipei DevOps la OwnBackups, subliniază prudența și prudența față de dorința de a „: automate_all_the_things: ”. Sfatul ei? „În cele din urmă, trebuie doar să automatizăm problemele care cauzează cu adevărat probleme și nu să remediem problemele care nu există.”

Căutați mai multe sfaturi de specialitate cu privire la automatizare de la profesioniștii DevOps? Descărcați ghidul nostru complet pentru automatizarea operațiunilor de dezvoltare - absolut gratuit.