A treia conferință a avut loc pe 7 decembrie , organizat de comunitatea DevOps din Moscova cu sprijinul Mail.ru Cloud Solutions. Pe lângă prezentările făcute de cei mai importanți practicieni DevOps, participanții ar putea participa la scurte discuții motivante Lightning Talks, ateliere și să comunice în spații deschise.
Am adunat informații importante din șase discursuri și am realizat interviuri cu mai mulți vorbitori pentru a afla ce a rămas în spatele rapoartelor.
Interior:
- Baruch Sadogursky, JFrog: „Lăsați software-ul să curgă de la furnizor la utilizator ca un lichid”
- Pavel Selivanov, Southbridge: „Dev și Ops au o sarcină comună - să facă un produs care să funcționeze”
- Vladimir Utratenko, X5 Retail Group: „DevOps in Enterprise este o dezvoltare fără durere și incendii”
- Sergey Puzyrev, Facebook: „Inginerului de producție îi pasă de serviciu în ansamblu: pentru ca atât utilizatorii, cât și dezvoltatorii să se distreze”
- Mikhail Chinkov, AMBOSS: „Un departament nu poate urma calea DevOps, întreaga companie trebuie să o urmeze”
- Entuziaștii DevOps ai Rosbank: „1000 de zile pentru a implementa DevOps într-o întreprindere sângeroasă”
1. Baruch Sadogursky, JFrog: „Lăsați software-ul să curgă de la furnizor la utilizator ca un lichid”
Eșecurile actualizării software apar la fiecare oră și pentru toată lumea. Iată doar o poveste de groază din discurs: Knight Capital a pierdut 440 de milioane de dolari într-o oră după o actualizare nereușită.
Baruch a vorbit despre modelele DevOps de actualizări continue care vor ajuta la evitarea eșecurilor și a urii utilizatorilor:
Rollback local — păstrați versiunea anterioară a software-ului pe dispozitiv pentru a reveni dacă se întâmplă ceva. Acest lucru vă va proteja dacă lucrurile devin atât de rău încât nu puteți trimite un plasture prin aer.
Actualizări prin aer - mai bine continuu. În caz contrar, va fi ca și cu dezvoltatorii Jaguar: din cauza unui bug în sistemul de frânare, care nu a putut fi actualizat prin aer, mașinile au trebuit să fie rechemate de la vânzare. A fost dureros și scump.
Actualizări continue — actualizați software-ul în mod continuu de îndată ce o nouă caracteristică este gata. Cu actualizările rare, funcțiile sunt grupate împreună, o actualizare critică poate aștepta cele necritice. Ca și în Tesla, o actualizare care trebuia să repare frânarea aleatorie aștepta o actualizare a jocului de șah.
Implementare automată - înlocuiți oamenii cu mașini, deoarece oamenii sunt prost în a efectua acțiuni de rutină.
Actualizări frecvente - te ajută să-ți dezvolți un obicei și să scapi de frică. Actualizările rare se transformă în evenimente de urgență.
Cunoașterea stării dispozitivului — testează actualizările, nu instalarea de la zero. Acest lucru este important deoarece actualizările se pot comporta diferit în funcție de starea dispozitivului.
Canare eliberează — lansați actualizări pentru un număr mic de utilizatori și observați. Acest lucru reduce daunele dacă ceva nu merge bine.
Actualizări fără indisponibilitate — permiteți clienților să observe doar funcții noi și să nu rămână fără service timp de câteva săptămâni în timp ce lansați o actualizare.
Am discutat cu Baruch Sadogursky despre modul în care viziunea asupra DevOps diferă în IT-ul rus și occidental, dacă Cloud va face totul în curând pentru noi și dacă toate serviciile software vor aluneca în schema aaS - urmăriți interviul:
2. Pavel Selivanov, Southbridge: „Dev și Ops au o sarcină comună - să facă un produs care să funcționeze”
Implementarea Kubernetes nu va ajuta la realizarea DevOps și, dimpotrivă, poate distruge totul. Pavel a explicat de ce tehnologia (chiar și cea mai tare) nu vă poate rezolva toate problemele:
Complexitatea proiectului a depășit codul. Anterior, exista o aplicație complexă: interacțiune în cadrul proiectului și dezvoltare complexă, dar o structură simplă - administratorul o implementa, totul funcționează. Am trecut la microservicii: fiecare serviciu este o aplicație simplă, comunicare folosind protocoale standard și dezvoltare rapidă, dar structura proiectului a devenit mai complexă. Complexitatea unui proiect cu o arhitectură de microservicii nu a dispărut - a depășit codul. Acum, inginerul DevOps este responsabil pentru asta.
Dezvoltatorii nu doresc schimbări după implementarea DevOps. Ca rezultat, fluxul de lucru cu Kubernetes continuă să arate ca și cum ar arunca sarcini de la Dev la Ops peste un perete, doar că nu este unul metaforic - Git devine un astfel de perete. Dezvoltatorul pune codul acolo și funcționează ca înainte, iar administratorii au Kubernetes, CI/CD și orice altceva.
Cu toate acestea, dezvoltatorii trebuie să accepte modificările. Situația în care dezvoltatorii nu știu ce fac administratorii și administratorii nu știu ce se întâmplă cu dezvoltatorii creează probleme.
Dacă nu s-a schimbat nimic pentru dezvoltatori, aceștia nu își dau seama că funcționarea aplicației este responsabilitatea lor - diverse trucuri tehnice nu vor funcționa.
Odată cu apariția DevOps și Kubernetes, multe se vor schimba în dezvoltare. Dezvoltatorii trebuie să fie competenți în operațiuni și invers. Acești specialiști au propriile lor abilități specifice, dar trebuie să fie conștienți de munca celuilalt. Dev și Ops trebuie să fie prieteni înainte de a implementa Kubernetes, altfel vei sparge ceea ce ai.
Pavel Selivanov a vorbit despre ce se va întâmpla cu Kubernetes în 5 ani și despre ce ar trebui să construiască o stivă tehnologică un startup modern - urmăriți interviul:
3. Vladimir Utratenko, X5 Retail Group: „DevOps in Enterprise este o dezvoltare fără durere și incendii”
Companiile ajung la transformarea DevOps atunci când realizează că dezvoltarea este prea lentă și nu corespunde realităților, au dorința de a se dezvolta mai bine și de a se implementa mai repede.
Vladimir a explicat cum se întâmplă acest lucru și care este captura:
- În primul rând, companiile angajează un inginer DevOps. Acesta este un administrator de sistem senior, el este implicat în implementarea unei versiuni în producție, standardizarea mediului de dezvoltare, configurarea infrastructurii, detectarea și remedierea diferitelor probleme, automatizarea proceselor și alte sarcini tehnice.
- Atunci un inginer DevOps nu mai este suficient, iar compania angajează o echipă DevOps. Acesta este un centru de competențe care organizează eforturile inginerilor disparați și le permite să fie concentrate într-o singură direcție.
- De fapt, inginerul DevOps și echipele DevOps sunt anti-modele de transformare DevOps. Deoarece DevOps este despre practici și cultură, în plus, există implementări ale DevOps în companiile de tehnologie (SRE, Production Engineering).
Ce să fac? Angajați o echipă DevOps temporară care va ajuta la implementarea transformării DevOps, la efectuarea de practici, la cultivarea unei culturi de dezvoltare și a unei culturi tehnologice.
Când o afacere intră în joc și investește în DevOps, sunt posibile mai multe scenarii: totul se va prăbuși la decolare; va rămâne ca SRE/Production Engineering sau Embedded Ops; va trece la BizOps, atunci când procesele se bazează pe valorile de afaceri.
Vladimir Utratenko ne-a spus cât de „sângeros” este DevOps într-o întreprindere și cum sunt implementate practicile în retailul mare - urmăriți interviul:
4. Sergey Puzyrev, Facebook: „Inginerului de producție îi pasă de serviciu în ansamblu: pentru ca atât utilizatorii, cât și dezvoltatorii să se distreze”
Facebook este o companie imensă, cu un număr mare de componente, servere, oameni și centre de date. În ciuda dimensiunilor sale uriașe, este foarte rapid - dezvoltatorii pot lansa servicii de multe ori pe zi. De asemenea, Facebook crește rapid și nu doar numărul de utilizatori și servere este în creștere, ci și numărul de dezvoltatori, ceea ce face procesele mai complexe.
Sergey a spus ce face un inginer de producție pe Facebook:
- Un inginer de producție codifică mult, trebuie să aibă cunoștințe de sistem: sisteme de operare, sisteme de fișiere, baze de date, rețele și altele asemenea. Trebuie să aibă experiență de lucru cu sisteme distribuite și Reliability Engineering, adică susținând fiabilitatea produsului. Trebuie să fie de gardă, adică disponibil pentru apelare în orice moment.
- Inginerul de producție diferă de Inginerul de software prin faptul că are abilități avansate în operare, dar, de fapt, este o subspecie a Inginerului de software. Inginerii de software codifică mai mult; pot avea abilități suplimentare legate, de exemplu, de prelucrarea datelor. Pe Facebook, astfel de specialiști trebuie să fie și de gardă, ceea ce vine ca o surpriză neplăcută pentru mulți.
- Piramida nevoilor unui Inginer de Productie intr-o companie incepe cu monitorizarea serverelor si a ciclului lor de viata, adica obtinerea de noi hardware, setarea, punerea in functiune. Următorul nivel este același la nivelul serviciului: serviciile de monitorizare și ciclul lor de viață. Apoi urmează scalarea fără probleme și monitorizarea avansată. Acestea trec la autoscaling după ce ciclul de viață este automatizat. Și în final, este necesar să faceți tuning, astfel încât scalarea să fie eficientă și compania să economisească bani și resurse.
5. Mikhail Chinkov, AMBOSS: „Un departament nu poate urma calea DevOps, întreaga companie trebuie să o urmeze”
Mikhail crede că DevOps este o dezvoltare continuă. Nu poți să introduci niște instrumente și să te oprești aici. Ce probleme împiedică companiile să devină DevOps și cum să implementeze practicile?
Diferența în înțelegerea DevOps. Devopsul canonic, așa cum o văd evangheliștii, se sprijină pe 5 piloni:
- cultura - focus pe oameni si colaborare;
- automatizare - delegarea rutinei către fluxul de lucru;
- lean - accent pe oferirea de valoare utilizatorului;
- împărtășire - schimb continuu de cunoștințe;
- metrici și primirea feedback-ului folosindu-le.
Companiile se concentrează de obicei doar pe automatizare și pe furnizarea de valoare utilizatorului. Dar cultura, partajarea cunoștințelor și valorile DevOps pentru a urmări dezvoltarea trec în fundal.
Provocări de standardizare DevOps. Obiectivele produselor sunt diferite pentru toate companiile și nu pot fi standardizate. Starea DevOps într-o companie depinde de compania în sine, dar mulți nu înțeleg acest lucru și cred că este suficient să angajezi un inginer DevOps.
De ce nu suntem încă DevOps? Există două probleme cheie. În Enterprise există o dezvoltare lentă a organizației, dificultăți cu schimbarea vectorului în mintea a mii de angajați. În startup-uri, există o lipsă de surse de cunoștințe și o problemă cu alocarea resurselor pentru transformare.
Etapele dezvoltării DevOps într-o companie:
- prima este infrastructura în cloud, dar nimeni nu știe cum funcționează, cu excepția unuia sau doi administratori;
- în al doilea rând, infrastructura este transparentă și de înțeles pentru toți inginerii, dar procesele nu sunt simplificate;
- al treilea - inginerii lansează și repară în mod independent servicii live;
- al patrulea - inginerii vor contribui opțional la infrastructura de bază, cod transparent în cloud, implementare prin buton.
Schema ideală este ca toată lumea să aibă același acces la infrastructură, toți inginerii să aibă acces la produs și să înțeleagă ce fac.
După ce au încheiat toate gestaltele culturale și tehnice, transformarea DevOps a companiei va ține cont de feedback-ul de la valorile de afaceri și ale platformei.
6. Entuziaștii DevOps ai Rosbank: „1000 de zile pentru a implementa DevOps într-o întreprindere sângeroasă”
Yuri Bulich, Dina Maltseva, Evgeny Pankov de la Rosbank au povestit cum au ajuns la DevOps în trei ani. Au fost două obiective: să rezolve probleme specifice în echipe specifice și să implementeze instrumente centralizate.
Iată rezultatele obținute:
Rezultate pentru echipele de produse: asamblare de 30 de ori mai rapidă, instalare de 6 ori mai rapidă, economii de până la 30% la ciclul complet. Acum avem capacitatea de a apăsa un buton pentru a trece la productivitate
Rezultate pentru comenzile platformei: asamblare și instalare de 10 ori mai rapidă, număr crescut de instalări cu 87%, acoperire autotest de 46%. Echipa de integrare nu mai este un blocaj
Deci, cum să implementați practicile DevOps într-o întreprindere sângeroasă?
Mai întâi implementați un proiect pilot: Selectați echipe, decideți cum să implementați arhitectura și selectați instrumentele. Am ales instrumente cu licență deschisă, cu instalare în bancă și expertiză în lucrul cu acestea. Rosbank a implementat simultan un cloud privat împreună cu platforma DevOps, iar acest lucru a ajutat la început. În cloud, era posibil să obțineți resursele necesare la atingerea unui buton în 15 minute înainte, un astfel de proces putea dura o săptămână;
În bănci și alte întreprinderi, este necesar să se stabilească în prealabil restricțiile cu echipa de securitate a informațiilor și să se găsească o soluție care să permită implementarea modificărilor.
După pilot, o soluție de succes trebuie extinsă.
- Este important să „îndreptați” conducta cât mai mult posibil, eliminând legăturile inutile din acesta, evidențiind furnizorii de valoare și eliminând componentele rămase. Intermediarii sunt antimodeluri. De exemplu, la Rosbank, o serie de echipe nu au dezvoltat dezvoltare internă, lăsând doar dezvoltare externă. Acest lucru a dus la apariția unei echipe DevOps dedicate, care a asigurat transferul codului de la dezvoltatorii externi la cei interni. Problema a fost rezolvată prin integrarea dezvoltării externe în CI/CD, astfel încât aceștia nu doar să transfere codul de la ei înșiși la bancă, ci să fie și responsabili de succesul acestuia.
- Modelul de maturitate a inclus elemente ale practicilor DevOps, instrumente enumerate și a luat în considerare caracteristicile lucrului cu furnizori externi - în viitor, acest lucru a ajutat la reducerea rapidă a restanțelor de sarcini la implementarea lor în echipe noi.
- Avem nevoie de guvernare sub formă de control soft și recomandări. Un manual DevOps care funcționează bine este un set de caracteristici organizaționale și de instrumente care ajută echipele să utilizeze corect platforma.
- Ar trebui să acordați imediat atenție culturii, apoi multe schimbări se vor întâmpla mai repede și mai ușor. Dezvoltați-vă comunitatea internă, organizați întâlniri, ateliere tehnice, traininguri și activități distractive. Acest lucru dă roade: oamenii împărtășesc practici, văd cine ce a făcut, știu unde să apeleze, există hype și concurență sănătoasă în cadrul companiei.
- Nu are rost să lucrezi cu cei care nu sunt implicați în proces, cu echipe care nu s-au maturizat este mai bine să investești în echipe interesate și oameni loiali;
- Soluția aleasă trebuie să fie convenabilă pentru acei ingineri care o folosesc.
- Dezvoltarea externă nu este un blocant și practicile pot fi implementate acolo, principalul lucru este că echipa în sine are dorința.
Un pic mai mult beneficiu
Lista cărților care merită citite pentru cei din DevOps, de la Alexander Chistyakov, vdsina.ru:
- Irina Yakutenko „Voința și autocontrolul”.
- Daniel Kahneman „Gândind, rapid și încet”.
- Barbara Oakley „O minte pentru numere”.
- Maxim Dorofeev „Tehnici Jedi”.
- Viktor Frankl „Căutarea omului de sens”.
Rămâneţi aproape
Ne place și DevOps. Urmăriți anunțurile seriei și @Kubernetes, precum și alte evenimente Mail.ru Cloud Solutions, pe canalul nostru Telegram:
Sursa: www.habr.com
