Vorbim, desigur, despre . Dacă nu intrați în detalii, atunci pe 30 septembrie și 1 octombrie vom organiza o conferință privind combinarea proceselor de dezvoltare, testare și operare, iar dacă intrați în detalii, vă rugăm, sub cat.
În cadrul abordării DevOps, toate părțile dezvoltării tehnologice ale proiectului sunt împletite, apar în paralel și se influențează reciproc. De o importanță deosebită aici este crearea de procese de dezvoltare automatizate care pot fi modificate, simulate și testate în timp real. Acest lucru vă ajută să răspundeți instantaneu la schimbările de pe piață.
La conferință dorim să arătăm modul în care această abordare influențează dezvoltarea produsului. Cum se asigură fiabilitatea și adaptabilitatea sistemului pentru client. Cum schimbă DevOps structura și abordarea unei companii în organizarea procesului de lucru.
în spatele scenelor
Este important pentru noi să știm nu numai ce fac diferite companii în cadrul abordării DevOps, ci și să înțelegem de ce se fac toate acestea. Prin urmare, am invitat nu doar experți să se alăture Comitetului de program, ci specialiști care văd discursul DevOps din diferite poziții:
- ingineri superiori;
- dezvoltatori;
- conducătorii de echipe;
- CTO.
Pe de o parte, acest lucru creează dificultăți și conflicte atunci când discutăm cererile de rapoarte. Dacă un inginer este interesat să analizeze un accident major, atunci este mai important ca un dezvoltator să înțeleagă cum să creeze software care funcționează în nori și infrastructuri. Dar prin acordul, creăm un program care va fi valoros și interesant pentru toată lumea: de la ingineri la CTO.
Scopul conferinței noastre nu este doar acela de a selecta cele mai multe rapoarte de hype, ci de a prezenta imaginea de ansamblu: cum funcționează abordarea DevOps în practică, ce fel de rake puteți întâlni atunci când treceți la noi procese. În același timp, construim partea de conținut, coborând de la problema de business la tehnologii specifice.
Secțiunile conferinței vor rămâne aceleași ca în .
- Platformă de infrastructură.
- Infrastructura ca cod.
- Livrare continuă.
- Părere.
- Arhitectură în DevOps, DevOps pentru CTO.
- Practici SRE.
- Training si managementul cunostintelor.
- Securitate, DevSecOps.
- Transformarea DevOps.
Apel pentru lucrări: ce fel de rapoarte căutăm
Am împărțit condiționat publicul potențial al conferinței în cinci grupuri: ingineri, dezvoltatori, specialiști în securitate, lideri de echipă și CTO. Fiecare grup are propria sa motivație de a veni la conferință. Și, dacă te uiți la DevOps din aceste poziții, poți înțelege cum să-ți concentrezi subiectul și unde să pui accent.
Pentru ingineri, care creează o platformă de infrastructură, este important să înțelegem tendințele existente, să înțelegem care tehnologii sunt acum cele mai avansate. Aceștia vor fi interesați să învețe despre experiența din viața reală în utilizarea acestor tehnologii și să facă schimb de opinii. Un inginer va fi bucuros să asculte un raport care analizează un accident grav, iar noi, la rândul nostru, vom încerca să selectăm și să lustruim un astfel de raport.
Pentru dezvoltatori este important să înțelegem un astfel de concept ca aplicație nativă cloud. Adică, cum să dezvolti software, astfel încât să funcționeze în cloud și diverse infrastructuri. Dezvoltatorul trebuie să primească în mod constant feedback de la software. Aici dorim să auzim cazuri despre modul în care companiile construiesc acest proces, cum să monitorizeze performanța software-ului și cum funcționează întregul proces de livrare.
Specialiști în securitate cibernetică Este important să înțelegeți cum să configurați procesul de securitate, astfel încât să nu blocheze procesele de dezvoltare și schimbare din cadrul companiei. Vor fi interesante și subiectele despre cerințele pe care DevOps le impune unor astfel de specialiști.
Liderii echipei vor să știe, cum funcționează procesul de livrare continuă în alte companii. Ce cale au urmat companiile pentru a realiza acest lucru, cum au construit procesele de dezvoltare și de asigurare a calității în cadrul DevOps. Liderii echipei sunt, de asemenea, interesați de nativul Cloud. Și, de asemenea, întrebări despre interacțiunea în cadrul echipei și între echipele de dezvoltare și de inginerie.
Pentru CTO cel mai important lucru este să vă dați seama cum să conectați toate aceste procese și să le ajustați la nevoile afacerii. El se asigură că aplicația este fiabilă atât pentru afacere, cât și pentru client. Și aici trebuie să înțelegeți ce tehnologii vor funcționa pentru ce sarcini de afaceri, cum să construiți întregul proces etc. CTO este, de asemenea, responsabil pentru buget. De exemplu, el trebuie să înțeleagă câți bani trebuie cheltuiți pentru recalificarea specialiștilor, astfel încât aceștia să poată lucra în DevOps.
Dacă aveți ceva de spus despre aceste chestiuni, nu rămâneți tăcuți, . Termenul limită pentru apelul pentru lucrări este 20 august. Cu cât vă înregistrați mai devreme, cu atât veți avea mai mult timp pentru a finaliza raportul și a vă pregăti prezentarea. Deci, nu întârzia.
Ei bine, dacă nu aveți nevoie să vorbiți în public, doar și vino pe 30 septembrie și 1 octombrie să comunici cu colegii. Promitem că va fi interesant și inspirator.
Cum vedem DevOps
Pentru a înțelege exact ce înțelegem prin DevOps, vă recomand să citiți (sau recitiți) raportul meu „" Mergând prin valurile pieței, am observat cum se transforma ideea DevOps în companii de diferite dimensiuni: de la un mic startup la companii multinaționale. Raportul este construit pe o serie de întrebări, răspunzând la ele, puteți înțelege dacă compania dumneavoastră se îndreaptă către DevOps sau dacă există probleme undeva.
DevOps este un sistem complex, trebuie să includă:
- Produs digital.
- Module de afaceri care dezvoltă acest produs digital.
- Echipe de produse care scriu cod.
- Practici de livrare continuă.
- Platformele ca serviciu.
- Infrastructura ca serviciu.
- Infrastructura ca cod.
- Practici separate pentru menținerea fiabilității, integrate în DevOps.
- O practică de feedback care descrie totul.
La sfârșitul raportului există o diagramă care oferă o idee despre sistemul DevOps din companie. Vă va permite să vedeți care procese din compania dvs. au fost deja simplificate și care nu au fost încă construite.
Puteți urmări videoclipul reportajului .
Și acum va exista un bonus: mai multe videoclipuri de la RIT++ 2019, care abordează cele mai generale probleme ale transformării DevOps.
Infrastructura companiei ca produs
Artyom Naumenko conduce echipa DevOps la Skyeng și se ocupă de dezvoltarea infrastructurii companiei sale. El a spus cum infrastructura afectează procesele de afaceri la SkyEng: cum să calculăm rentabilitatea investiției pentru aceasta, ce valori ar trebui alese pentru calcul și cum să lucrăm pentru a le îmbunătăți.
Pe drumul către microservicii
Compania Nixys oferă suport pentru proiecte web ocupate și sisteme distribuite. Directorul său tehnic, Boris Ershov, a spus cum să traducă produsele software, a căror dezvoltare a început acum 5 ani (sau chiar mai mult), pe o platformă modernă.
De regulă, astfel de proiecte sunt o lume specială în care există colțuri atât de întunecate și străvechi ale infrastructurii pe care inginerii actuali nu știu despre ele. Iar abordările ale arhitecturii și dezvoltării care au fost odată alese sunt depășite și nu pot oferi afacerii același ritm de dezvoltare și lansare a noilor versiuni. Drept urmare, fiecare lansare de produs se transformă într-o aventură incredibilă, în care ceva cade constant și în cel mai neașteptat loc.
Managerii unor astfel de proiecte se confruntă inevitabil cu nevoia de a transforma toate procesele tehnologice. În raportul său, Boris a spus:
- cum să alegeți arhitectura potrivită pentru proiect și să puneți în ordine infrastructura;
- ce instrumente să folosești și ce capcane se întâlnesc pe calea transformării;
- ce e de facut in continuare.
Automatizarea lansărilor sau modul de livrare rapid și fără durere
Alexander Korotkov este un dezvoltator de top al sistemului CI/CD la CIAN. El a vorbit despre instrumentele de automatizare care au făcut posibilă îmbunătățirea calității și reducerea timpului de livrare a codului la producție de 5 ori. Dar astfel de rezultate nu au putut fi obținute numai cu automatizarea, așa că Alexander a acordat atenție și schimbărilor în procesele de dezvoltare.
Cum vă ajută accidentele să învățați?
Alexey Kirpichnikov implementează DevOps și infrastructura la SKB Kontur de 5 ani. Pe parcursul a trei ani, aproximativ 1000 de fakaps cu diferite grade de epicitate au avut loc în compania lui. Dintre acestea, de exemplu, 36% au fost cauzate de lansarea unei versiuni de calitate scăzută în producție, iar 14% au fost cauzate de lucrările de întreținere a hardware-ului din centrul de date.
O arhivă de rapoarte (post-mortems) pe care inginerii companiei le țin de câțiva ani la rând face posibilă obținerea unor informații atât de precise despre accidente. Autopsia este scrisă de inginerul de gardă, care a răspuns primul la semnalul de urgență și a început să repare totul. De ce să chinuiți inginerii care se luptă noaptea cu facaps scriind rapoarte? Aceste date vă permit să vedeți întreaga imagine și să mutați dezvoltarea infrastructurii în direcția corectă.
În discursul său, Alexey a împărtășit cum să scrieți un post-mortem cu adevărat util și cum să implementați practica unor astfel de rapoarte într-o companie mare. Dacă vă plac poveștile despre cum a greșit cineva, urmăriți videoclipul spectacolului.
Înțelegem că viziunea ta despre DevOps poate să nu se potrivească cu a noastră. Va fi interesant să știți cum vedeți transformarea DevOps. Împărtășește-ți experiența și viziunea asupra acestui subiect în comentarii.
Ce rapoarte am acceptat deja în program?
În această săptămână, Comitetul de Program a adoptat 4 rapoarte: privind securitatea, infrastructura și practicile SRE.
Poate cel mai dureros subiect al transformării DevOps: cum să vă asigurați că băieții de la departamentul de securitate a informațiilor nu distrug conexiunile deja construite între dezvoltare, operare și administrare. Unele companii se descurcă fără un departament de securitate a informațiilor. Cum se asigură securitatea informațiilor în acest caz? Despre Mona Arkhipova de la sudo.su. Din raportul ei aflăm:
- ce trebuie protejat și de cine;
- care sunt procesele de securitate de rutină;
- cum se intersectează procesele IT și securitatea informațiilor;
- ce este CSC CSC și cum se implementează;
- cum și după ce indicatori să efectueze controale regulate de securitate a informațiilor.
Următorul raport se referă la dezvoltarea infrastructurii ca cod. Reduceți cantitatea de rutină manuală și nu transforma întregul proiect în haos, este posibil acest lucru? La această întrebare Maxim Kostrikin din Ixtens. Compania lui folosește Terraform pentru lucrul cu infrastructura AWS. Instrumentul este convenabil, dar întrebarea este cum să evitați crearea unui bloc uriaș de cod atunci când îl utilizați. Întreținerea unei astfel de moșteniri va deveni din ce în ce mai costisitoare în fiecare an.
Maxim va arăta cum funcționează modelele de plasare a codului, având ca scop simplificarea automatizării și dezvoltării.
Un alt vom auzi despre infrastructură de la Vladimir Ryabov de la Playkey. Aici vom vorbi despre platforma de infrastructură și vom învăța:
- cum să înțelegeți dacă spațiul de stocare este utilizat eficient;
- câte sute de utilizatori pot primi 10 TB de conținut dacă se utilizează doar 20 TB de stocare;
- cum să comprimați datele de 5 ori și să le furnizați utilizatorilor în timp real;
- cum să sincronizezi datele din mers între mai multe centre de date;
- cum să eliminați orice influență a utilizatorilor unul asupra celuilalt atunci când utilizați o mașină virtuală secvenţial.
Secretul acestei magii este tehnologia ZFS pentru FreeBSD și furculița ei proaspătă ZFS pe Linux. Vladimir va împărtăși cazuri de la Playkey.
Matvey Kukuy de la Amixr.IO gata cu exemple din viata , ce s-a întâmplat EOA și cum ajută la construirea unor sisteme fiabile. Amixr.IO trece incidentele clienților prin backend-ul său, zeci de echipe de serviciu din întreaga lume au tratat deja 150 de mii de cazuri. În cadrul conferinței, Matvey va împărtăși statisticile și perspectivele pe care compania sa le-a acumulat prin rezolvarea problemelor clienților și analiza eșecurilor.
Încă o dată vă îndemn să nu fiți lacom și să vă împărtășiți experiența ca samurai DevOps. Servi pentru un raport, iar tu și cu mine vom avea 2,5 luni pentru a pregăti un discurs excelent. Dacă vrei să fii ascultător, la buletinul informativ cu actualizări ale programului și gândiți-vă serios la rezervarea biletelor din timp, pentru că acestea se vor scumpi mai aproape de datele conferinței.
Sursa: www.habr.com