Me räägime muidugi sellest . Kui detailidesse ei lasku, siis 30. septembril ja 1. oktoobril korraldame arendus-, testimis- ja kasutusprotsesside ühendamise konverentsi ning kui lähed detailidesse, siis palun kat.
DevOpsi lähenemisviisi raames on kõik projekti tehnoloogilise arengu osad läbi põimunud, toimuvad paralleelselt ja mõjutavad üksteist. Siin on eriti oluline automatiseeritud arendusprotsesside loomine, mida saab reaalajas muuta, simuleerida ja testida. See aitab teil turul toimuvatele muutustele koheselt reageerida.
Konverentsil tahame näidata, kuidas selline lähenemine tootearendust mõjutab. Kuidas on tagatud süsteemi töökindlus ja kohandatavus kliendi jaoks. Kuidas DevOps muudab ettevõtte struktuuri ja lähenemist oma tööprotsessi korraldamisele.
kaamerate taga
Meile on oluline mitte ainult teada, mida erinevad ettevõtted DevOps-lähenemise raames teevad, vaid ka mõista, miks seda kõike tehakse. Seetõttu kutsusime programmikomiteega liituma mitte ainult eksperte, vaid spetsialiste, kes näevad DevOpsi diskursust erinevatelt positsioonidelt:
- vaneminsenerid;
- arendajad;
- meeskonna juhid;
- CTO.
Ühest küljest tekitab see raskusi ja konflikte aruandlustaotluste arutamisel. Kui insener on huvitatud suurõnnetuse analüüsimisest, siis arendajale on olulisem mõista, kuidas luua pilvedes ja infrastruktuurides töötavat tarkvara. Kuid kokku leppides loome programmi, mis on väärtuslik ja huvitav kõigile: inseneridest tehniliste juhideni.
Meie konverentsi eesmärk ei ole lihtsalt välja valida kõige rohkem hype raporteid, vaid esitada üldpilt: kuidas DevOps lähenemine praktikas töötab, millise reha otsa võib uutele protsessidele üleminekul sattuda. Samal ajal ehitame üles sisuosa, laskudes äriprobleemilt konkreetsete tehnoloogiateni.
Konverentsi sektsioonid jäävad samaks, mis aastal .
- Infrastruktuuri platvorm.
- Infrastruktuur kui kood.
- Pidev tarne.
- Tagasiside
- Arhitektuur DevOpsis, DevOps CTO jaoks.
- SRE praktikad.
- Koolitus ja teadmusjuhtimine.
- Turvalisus, DevSecOps.
- DevOpsi teisendus.
Call for Papers: milliseid aruandeid me ootame
Konverentsi potentsiaalse publiku jagasime tinglikult viide rühma: insenerid, arendajad, turvaspetsialistid, meeskonnajuhid ja CTO. Igal rühmal on oma motivatsioon konverentsile tulla. Ja kui vaatate DevOpsi nendest positsioonidest, saate aru, kuidas oma teemat keskenduda ja kuhu rõhku panna.
Inseneridele, kes loovad taristuplatvormi, on oluline mõista olemasolevaid suundumusi, mõista, millised tehnoloogiad on praegu kõige arenenumad. Nad on huvitatud nende tehnoloogiate kasutamisest ja arvamuste vahetamisest reaalse elukogemuse kohta. Insener kuulab hea meelega aruannet, mis analüüsib mõnd rasket õnnetust, ja meie omakorda proovime sellise aruande välja valida ja lihvida.
Arendajatele on oluline mõista sellist mõistet nagu pilvepõhine rakendus. Ehk kuidas arendada tarkvara nii, et see toimiks pilvedes ja erinevates infrastruktuurides. Arendaja peab tarkvaralt pidevalt tagasisidet saama. Siin tahame kuulda juhtumeid selle kohta, kuidas ettevõtted seda protsessi üles ehitavad, kuidas tarkvara jõudlust jälgida ja kogu tarneprotsess toimib.
Küberturvalisuse spetsialistid Oluline on mõista, kuidas turvaprotsess üles seada nii, et see ei takerduks ettevõttesiseseid arendus- ja muutusprotsesse. Huvitavad on ka teemad, mis käsitlevad nõudeid, mida DevOps sellistele spetsialistidele esitab.
Meeskonna juhid tahavad teada, kuidas toimib pidev tarneprotsess teistes ettevõtetes. Millise tee ettevõtted selleni jõudsid, kuidas nad DevOpsis arendus- ja kvaliteeditagamisprotsesse üles ehitasid. Meeskonna juhid on huvitatud ka pilvepõhisest rakendusest. Ja ka küsimused meeskonnasisese ning arendus- ja insenerimeeskondade vahelise suhtluse kohta.
eest CTO kõige tähtsam on välja mõelda, kuidas kõiki neid protsesse ühendada ja ärivajadustega kohandada. Ta hoolitseb selle eest, et rakendus oleks usaldusväärne nii ettevõtte kui ka kliendi jaoks. Ja siin peate mõistma, millised tehnoloogiad milliste äriülesannete jaoks töötavad, kuidas kogu protsessi üles ehitada jne. CTO vastutab ka eelarve koostamise eest. Näiteks peab ta mõistma, kui palju raha tuleb kulutada spetsialistide ümberõppele, et nad saaksid töötada DevOpsis.
Kui teil on nende asjade kohta midagi öelda, ärge vaikige, . Tööde esitamise tähtaeg on 20. august. Mida varem registreerute, seda rohkem on teil aega aruande lõplikuks vormistamiseks ja esitluseks valmistumiseks. Nii et ärge viivitage.
Noh, kui teil pole vajadust avalikult rääkida, siis lihtsalt ja tule 30. septembril ja 1. oktoobril kolleegidega suhtlema. Lubame, et see on huvitav ja inspireeriv.
Kuidas me DevOpsi näeme
Et mõista täpselt, mida me DevOpsi all mõtleme, soovitan lugeda (või uuesti läbi lugeda) oma aruanne "" Läbi turulainete kõndides jälgisin, kuidas DevOpsi idee oli muutumas erineva suurusega ettevõtetes: väikesest idufirmast rahvusvaheliste ettevõteteni. Raport on üles ehitatud rea küsimustele, neile vastates saad aru, kas sinu ettevõte liigub DevOpsi poole või on kuskil probleeme.
DevOps on keeruline süsteem, mis peab sisaldama:
- Digitoode.
- Ärimoodulid, mis arendavad seda digitaalset toodet.
- Tootemeeskonnad, kes kirjutavad koodi.
- Pidev kohaletoimetamise praktika.
- Platvormid kui teenus.
- Infrastruktuur kui teenus.
- Infrastruktuur kui kood.
- DevOpsi sisse ehitatud eraldi tavad töökindluse säilitamiseks.
- Tagasiside praktika, mis seda kõike kirjeldab.
Aruande lõpus on diagramm, mis annab ülevaate DevOps süsteemist ettevõttes. See võimaldab teil näha, millised protsessid teie ettevõttes on juba sujuvamaks muudetud ja millised on alles ehitamata.
Saate vaadata aruande videot .
Ja nüüd on boonus: mitu RIT++ 2019 videot, mis puudutavad DevOpsi teisendamise kõige üldisemaid probleeme.
Ettevõtte infrastruktuur kui toode
Artjom Naumenko juhib Skyengis DevOpsi meeskonda ja hoolitseb oma ettevõtte infrastruktuuri arendamise eest. Ta rääkis, kuidas infrastruktuur mõjutab SkyEngi äriprotsesse: kuidas selle jaoks ROI-d arvutada, milliseid mõõdikuid arvutamiseks valida ja kuidas nende parandamiseks töötada.
Teel mikroteenuste poole
Ettevõte Nixys pakub tuge hõivatud veebiprojektide ja hajutatud süsteemide jaoks. Selle tehniline direktor Boriss Ershov rääkis, kuidas tõlkida kaasaegsele platvormile tarkvaratooted, mille arendamine algas 5 aastat tagasi (või isegi rohkem).
Sellised projektid on reeglina eriline maailm, kus on nii hämaraid ja iidseid taristu nurgakesi, mida praegused insenerid ei teagi. Ja kunagi valitud lähenemisviisid arhitektuurile ja arendusele on aegunud ega suuda pakkuda ettevõttele samasugust arengutempot ja uute versioonide väljaandmist. Selle tulemusena muutub iga toote väljalaskmine uskumatuks seikluseks, kus midagi kukub pidevalt maha ja seda kõige ootamatumas kohas.
Selliste projektide juhid seisavad paratamatult silmitsi vajadusega muuta kõik tehnoloogilised protsessid. Boris ütles oma aruandes:
- kuidas valida projektile õige arhitektuur ja teha korda infrastruktuur;
- milliseid tööriistu kasutada ja milliste lõksudega ümberkujundamise teel kokku puututakse;
- mida edasi teha.
Väljalaskmiste automatiseerimine ehk kuidas toimetada kiiresti ja valutult
Aleksander Korotkov on CIANi juhtiv CI/CD-süsteemi arendaja. Ta rääkis automatiseerimistööriistadest, mis võimaldasid parandada kvaliteeti ja lühendada koodi tootmisse tarnimise aega 5 korda. Kuid selliseid tulemusi ei olnud võimalik saavutada ainult automatiseerimisega, mistõttu Alexander pööras tähelepanu ka muutustele arendusprotsessides.
Kuidas aitavad õnnetused õppida?
Aleksei Kirpitšnikov on SKB Konturis DevOpsi ja infrastruktuuri juurutanud 5 aastat. Kolme aasta jooksul juhtus tema ettevõttes ligikaudu 1000 erineva eepilisusega faapi. Nende hulgas oli näiteks 36% põhjuseks madala kvaliteediga väljalaske tootmisse viimine ja 14% andmekeskuse riistvarahooldustööd.
Nii täpset teavet õnnetuste kohta võimaldab hankida aruannete arhiiv (surmajärgsed uuringud), mida ettevõtte insenerid on juba mitu aastat järjest haldanud. Surmajärgselt kirjutab valveinsener, kes reageeris esimesena hädasignaalile ja asus kõike parandama. Miks piinata aruandeid kirjutades insenere, kes vaevlevad öösel näoga? Need andmed võimaldavad näha tervikpilti ja liigutada infrastruktuuri arendamist õiges suunas.
Aleksei rääkis oma kõnes, kuidas kirjutada tõeliselt kasulikku surmajärgset pilti ja kuidas selliste aruannete praktikat suures ettevõttes rakendada. Kui teile meeldivad lood sellest, kuidas keegi nässu ajas, vaadake etenduse videot.
Mõistame, et teie nägemus DevOpsist ei pruugi meie omaga ühtida. Huvitav on teada, kuidas näete DevOpsi teisendust. Jagage oma kogemusi ja nägemust sellel teemal kommentaarides.
Milliseid aruandeid oleme juba programmi vastu võtnud?
Sel nädalal võttis programmikomitee vastu 4 aruannet: turvalisuse, infrastruktuuri ja SRE tavade kohta.
DevOpsi transformatsiooni ehk valusaim teema: kuidas teha nii, et infoturbe osakonna kutid ei lõhuks juba loodud seoseid arenduse, toimimise ja halduse vahel. Mõned ettevõtted saavad hakkama ilma infoturbe osakonnata. Kuidas sel juhul tagada infoturve? Sellest Mona Arkhipova saidilt sudo.su. Tema aruandest saame teada:
- mida ja kelle eest tuleb kaitsta;
- millised on rutiinsed turvaprotsessid;
- kuidas IT ja infoturbe protsessid ristuvad;
- mis on CIS CSC ja kuidas seda rakendada;
- kuidas ja milliste näitajate alusel teha regulaarset infoturbe kontrolli.
Järgmine aruanne käsitleb infrastruktuuri kui koodi arendamist. Vähendage käsitsi rutiini ja ärge muutke kogu projekti kaoseks, kas see on võimalik? Sellele küsimusele Maxim Kostrikin Ixtensist. Tema firma kasutab Terraform AWS-i infrastruktuuriga töötamiseks. Tööriist on mugav, kuid küsimus on selles, kuidas vältida selle kasutamisel tohutu koodiploki tekkimist. Sellise pärandi ülalpidamine läheb iga aastaga aina kallimaks.
Maxim näitab, kuidas töötavad koodipaigutuse mustrid, mille eesmärk on automatiseerimise ja arendamise lihtsustamine.
Teine kuuleme taristu kohta Vladimir Ryabov Playkeyst. Siin räägime infrastruktuuriplatvormist ja õpime:
- kuidas aru saada, kas salvestusruumi kasutatakse tõhusalt;
- kui mitusada kasutajat saavad vastu võtta 10 TB sisu, kui kasutatakse ainult 20 TB salvestusruumi;
- kuidas andmeid 5 korda tihendada ja kasutajatele reaalajas edastada;
- kuidas sünkroonida andmeid käigult mitme andmekeskuse vahel;
- kuidas kõrvaldada kasutajate igasugune mõju üksteisele ühe virtuaalmasina järjestikusel kasutamisel.
Selle maagia saladus on tehnoloogia ZFS FreeBSD jaoks ja selle värske kahvel ZFS Linuxis. Vladimir jagab Playkey juhtumeid.
Matvey Kukuy ettevõttest Amixr.IO valmis näidetega elust , mis on juhtunud SRE ja kuidas see aitab luua usaldusväärseid süsteeme. Amixr.IO edastab kliendijuhtumid oma taustaprogrammi kaudu; kümned valves olevad meeskonnad üle maailma on tegelenud juba 150 tuhande juhtumiga. Konverentsil jagab Matvey statistikat ja arusaamu, mida tema ettevõte on klientide probleeme lahendades ja rikkeid analüüsides kogunud.
Veel kord soovitan teil mitte olla ahne ja jagada oma kogemusi DevOpsi samuraina. Serveeri raporti jaoks ja teil ja minul on 2,5 kuud aega suurepärase kõne ettevalmistamiseks. Kui tahad olla kuulaja, programmi uuendustega uudiskirja ja mõelge tõsiselt piletite enneaegsele broneerimisele, sest konverentsi kuupäevade lähenedes lähevad need kallimaks.
Allikas: www.habr.com