Räägime DevOpsist arusaadavas keeles

Kas DevOpsist rääkides on raske peamist mõtet mõista? Oleme kogunud teile erksad analoogid, rabavad sõnastused ja ekspertide nõuanded, mis aitavad isegi mittespetsialistidel asjani jõuda. Lõpuks on boonuseks Red Hati töötajate enda DevOps.

Mõiste DevOps sai alguse 10 aastat tagasi ja on muutunud Twitteri hashtagist võimsaks kultuuriliikumiseks IT-maailmas – tõeliseks filosoofiaks, mis julgustab arendajaid asju kiiremini tegema, katsetama ja edasi liikuma. DevOps on muutunud lahutamatult seotud digitaalse transformatsiooni kontseptsiooniga. Kuid nagu IT-terminoloogiaga sageli juhtub, on DevOps viimase kümne aasta jooksul omandanud enda kohta palju definitsioone, tõlgendusi ja väärarusaamu.

Seetõttu võite sageli kuulda DevOpsi kohta küsimusi, kas see on sama mis agiilne? Või on see mingi eriline metoodika? Või on see lihtsalt sõna "koostöö" sünonüüm?

DevOps sisaldab palju erinevaid kontseptsioone (pidev kohaletoimetamine, pidev integreerimine, automatiseerimine jne), nii et olulise väljaselgitamine võib olla keeruline, eriti kui olete selle teema vastu kirglik. See oskus on aga väga kasulik, olenemata sellest, kas üritad oma ideid ülemustele edasi anda või lihtsalt räägid oma tööst kellelegi oma perekonnast või sõpradest. Seetõttu jätame DevOpsi terminoloogilised nüansid praegu kõrvale ja keskendume suurele pildile.

Mis on DevOps: 6 definitsiooni ja analoogiat

Palusime ekspertidel võimalikult lihtsalt ja lühidalt selgitada DevOpsi olemust, et selle väärtus saaks selgeks ka mis tahes tehniliste teadmistega lugejatele. Nende vestluste tulemuste põhjal oleme välja valinud kõige silmatorkavamad analoogiad ja silmatorkavamad formulatsioonid, mis aitavad teil luua oma lugu DevOpsi kohta.

1. DevOps on kultuuriline liikumine

"DevOps on kultuuriline liikumine, milles mõlemad osapooled (tarkvaraarendajad ja IT-süsteemide käitamise spetsialistid) tunnistavad, et tarkvara ei too tegelikku kasu enne, kui keegi seda kasutama hakkab: kliendid, kliendid, töötajad, mitte asja mõte," ütleb vanemteadur Eveline Oehrlich. DevOpsi Instituudi analüütik. "Seetõttu tagavad mõlemad pooled ühiselt tarkvara kiire ja kvaliteetse tarnimise."

2. DevOps on arendajatele volituste andmine.

"DevOps annab arendajatele võimaluse omada rakendusi, neid käitada ja hallata tarnimist algusest lõpuni."

"Tavaliselt räägitakse DevOpsist kui viisist, kuidas kiirendada rakenduste tarnimist tootmisse automatiseeritud protsesside loomise ja juurutamise kaudu," ütleb kindlustusfirma Liberty Mutual DevOpsi platvormide direktor Jai Schniepp. "Aga minu jaoks on see palju põhimõttelisem asi." DevOps annab arendajatele võimaluse omada rakendusi või konkreetseid tarkvaraosi, neid käitada ja hallata nende tarnimist algusest lõpuni. DevOps kõrvaldab vastutuse segaduse ja juhendab kõiki, kes on seotud automatiseeritud, arendajapõhise infrastruktuuri loomisega.

3. DevOps on koostöö rakenduste loomisel ja tarnimisel.

"Lihtsamalt öeldes on DevOps lähenemine tarkvara tootmisele ja tarnimisele, kus kõik töötavad koos," ütleb BMC president ja digitaalse äri automatiseerimise juht Gur Staf.

4. DevOps on torujuhe

"Konveieri kokkupanek on võimalik ainult siis, kui kõik osad sobivad kokku."

"Ma võrdleksin DevOpsi autode koosteliiniga," jätkab Gur Staff. – Idee seisneb selles, et kõik osad tuleb eelnevalt projekteerida ja valmistada, et neid saaks seejärel ilma individuaalse reguleerimiseta kokku panna. Konveieri kokkupanek on võimalik ainult siis, kui kõik osad sobivad kokku. Need, kes mootorit projekteerivad ja ehitavad, peavad mõtlema, kuidas seda kerele või raamile kinnitada. Need, kes pidureid teevad, peavad mõtlema ratastele jne. Sama peaks kehtima ka tarkvaraga.

Äriloogikat või kasutajaliidest loov arendaja peab mõtlema klienditeavet talletavale andmebaasile, turvameetmetele kasutajaandmete kaitsmiseks ja sellele, kuidas see kõik toimib, kui teenus hakkab teenindama suurt, võib-olla isegi mitme miljoni dollari suurust kasutajaskonda. ."

„Suurim takistus, mida ületada, on panna inimesi tegema koostööd ja mõtlema nende töö osadele, mida teised teevad, selle asemel, et keskenduda ainult oma ülesannetele. Kui saate seda teha, on teil suurepärane võimalus digitaalseks muutumiseks, " lisab Gur Staff.

5. DevOps on inimeste, protsesside ja automatiseerimise õige kombinatsioon

DevOpsi instituudi tegevdirektor Jayne Groll pakkus DevOpsi selgitamiseks suurepärase analoogia. Tema sõnul on DevOps nagu retsept, millel on kolm peamist koostisosade kategooriat: inimesed, protsess ja automatiseerimine. Enamikku neist koostisosadest saab võtta teistest valdkondadest ja allikatest: Lean, Agile, SRE, CI/CD, ITIL, juhtimine, kultuur, tööriistad. DevOpsi, nagu iga hea retseptigi, saladus seisneb selles, kuidas saada nende koostisainete õiged proportsioonid ja segu, et suurendada rakenduste loomise ja väljastamise kiirust ja tõhusust.

6. DevOps on see, kui programmeerijad töötavad nagu vormel 1 meeskond

"Jooks ei ole planeeritud algusest lõpuni, vaid vastupidi, finišist stardini."

"Kui ma räägin sellest, mida DevOpsi algatusest oodata, pean näiteks NASCARi või vormel 1 võidusõidumeeskonda," ütleb Red Hati pilveplatvormi turunduse vanemjuht ja DevOpsi uudiskirja väljaandja Chris Short. – Sellise meeskonna juhil on üks eesmärk: võtta võistluse lõpus võimalikult kõrge koht, võttes arvesse meeskonna käsutuses olevaid ressursse ja väljakutseid, mis teda tabasid. Sel juhul ei planeerita sõitu algusest lõpuni, vaid vastupidi, finišist stardini. Esiteks seatakse ambitsioonikas eesmärk ja seejärel määratakse selle saavutamise viisid. Seejärel jagatakse need alamülesanneteks ja delegeeritakse meeskonnaliikmetele.

«Meeskond veedab terve nädala enne võistlust boksipeatuse täiustamisega. Ta teeb jõutreeningut ja kardiotreeningut, et kurnavaks võistluspäevaks vormis püsida. Harjutab koostööd, et lahendada võistluse ajal tekkida võivaid probleeme. Samuti peaks arendusmeeskond treenima uute versioonide sagedase väljalaskmise oskust. Selliste oskuste ja hästi töötava turvasüsteemi olemasolul toimub ka uute versioonide tootmisse toomine sagedamini. Selles maailmapildis tähendab suurenenud kiirus suurenenud turvalisust,” ütleb Short.

"Asi ei ole selles, et teha õigeid asju," lisab Short, "see on võimalikult paljude asjade kõrvaldamine, mis takistavad soovitud tulemuse saavutamist. Tehke koostööd ja kohandage reaalajas saadud tagasiside põhjal. Olge valmis kõrvalekalleteks ja töötage kvaliteedi parandamise nimel, et minimeerida nende mõju teie eesmärgi saavutamisel. See ootab meid DevOpsi maailmas.

Kuidas DevOpsi skaleerida: 10 näpunäidet ekspertidelt

Asi on selles, et DevOps ja mass DevOps on täiesti erinevad asjad. Me räägime teile, kuidas ületada tõkked teel esimesest teise.

Paljude organisatsioonide jaoks algab teekond DevOpsini lihtsalt ja meeldivalt. Luuakse väikesed kirglikud meeskonnad, vanad protsessid asendatakse uutega ning esimesed õnnestumised ei lase end kaua oodata.

Kahjuks on see lihtsalt vale sära, edu illusioon, ütleb konsultatsioonifirma North Highlandi tegevdirektor ja digivaldkonna juht Ben Grinnell. Varased võidud on kindlasti julgustavad, kuid need ei aita saavutada lõppeesmärki – DevOpsi laialdast kasutuselevõttu kogu organisatsioonis.

Lihtne on mõista, et tulemuseks on „meie” ja „nende” jagamise kultuur.

"Tihti käivitavad organisatsioonid need teedrajavad projektid, mõeldes, et need sillutavad teed peavoolule DevOpsile, mõtlemata sellele, kas teised suudavad või soovivad seda teed järgida," selgitab Ben Grinnell. – Meeskonnad selliste projektide elluviimiseks komplekteeritakse tavaliselt enesekindlatest „varagilastest“, kes on juba mujal midagi sarnast teinud, kuid teie organisatsioonis uued. Samal ajal julgustatakse neid rikkuma ja hävitama reegleid, mis jäävad kõigile teistele siduvaks. On lihtne näha, et tulemuseks on „meie“ ja „nende“ kultuur, mis pärsib teadmiste ja oskuste edasiandmist.

"Ja see kultuuriprobleem on vaid üks põhjustest, miks DevOpsi on raske skaleerida. DevOpsi meeskonnad seisavad silmitsi suurenenud tehniliste väljakutsetega, mis on tüüpilised kiiresti kasvavatele IT-ettevõtetele,“ ütles Scalyri asutaja ja esimees Steve Newman.

„Kaasaegses maailmas muutuvad teenused kohe, kui vajadus tekib. Tore on pidevalt uusi funktsioone juurutada ja juurutada, kuid selle protsessi koordineerimine ja tekkivate probleemide kõrvaldamine on paras peavalu, lisab Steve Newman. – Väga kiiresti arenevates organisatsioonides on ristfunktsionaalsete meeskondade inseneridel raskusi, et säilitada nähtavust muutuste ja nende tekitatavate kaskaadmõjude suhtes sõltuvuse tasemel. Pealegi pole insenerid õnnelikud, kui nad sellest võimalusest ilma jäävad ja seetõttu on neil raskem mõista tekkivate probleemide olemust.

Kuidas ületada need ülalkirjeldatud väljakutsed ja liikuda DevOpsi massilisele kasutusele suures organisatsioonis? Eksperdid nõuavad kannatlikkust, isegi kui teie lõppeesmärk on kiirendada tarkvara arendustsüklit ja äriprotsesse.

1. Pea meeles, et kultuurimuutus võtab aega.

Jayne Groll, DevOpsi Instituudi tegevdirektor: "Minu arvates peaks DevOpsi laiendamine olema sama järkjärguline ja iteratiivne kui agiilne arendus (ja samavõrra puudutama ka kultuuri). Agile ja DevOps rõhutavad väikeseid meeskondi. Kuid kuna nende meeskondade arv ja integreerumine kasvab, jõuame selleni, et rohkem inimesi võtab kasutusele uued tööviisid ja selle tulemusena toimub tohutu kultuuriline ümberkujundamine.

2. Kuluta piisavalt aega planeerimisele ja platvormi valikule

Eran Kinsbruner, Perfecto juhtiv tehniline evangelist: "Skaleerimise toimimiseks peavad DevOpsi meeskonnad kõigepealt õppima kombineerima traditsioonilisi protsesse, tööriistu ja oskusi ning seejärel aeglaselt arendama ja stabiliseerima DevOpsi iga üksikut faasi. Kõik algab kasutajalugude ja väärtusvoogude hoolikast planeerimisest, millele järgneb tarkvara kirjutamine ja versioonikontroll, kasutades tüvipõhist arendust või muid koodide harundamiseks ja ühendamiseks kõige sobivamaid lähenemisviise.

„Siis tuleb integreerimise ja testimise etapp, kus automatiseerimiseks on juba vaja skaleeritavat platvormi. Siin on DevOpsi meeskondade jaoks oluline valida õige platvorm, mis vastab nende oskuste tasemele ja projekti lõppeesmärkidele.

Järgmine etapp on tootmisse juurutamine ja see peaks olema orkestreerimistööriistade ja konteinerite abil täielikult automatiseeritud. DevOpsi kõikides etappides (tootmissimulaator, kvaliteedikontrolli keskkond ja tegelik tootmiskeskkond) on oluline omada virtualiseeritud keskkondi ning kasutada asjakohaste järelduste tegemiseks testide jaoks alati ainult uusimaid andmeid. Analytics peab olema nutikas ja suuteline töötlema suuri andmeid kiire ja teostatava tagasisidega.

3. Võtke süü vastutusest välja.

Gordon Haff, RedHati evangelist: „Katsetamist võimaldava ja julgustava süsteemi ja atmosfääri loomine võimaldab agiilse tarkvaraarenduse puhul nn edukaid ebaõnnestumisi. See ei tähenda, et keegi teine ​​ei vastuta ebaõnnestumiste eest. Tegelikult muutub vastutaja tuvastamine veelgi lihtsamaks, kuna "vastutus" ei tähenda enam "õnnetuse põhjustamist". See tähendab, et vastutuse olemus muutub kvalitatiivselt. Neli tegurit muutuvad kriitiliseks: häirete ulatus, lähenemisviisid, tootmisprotsessid ja stiimulid. (Lisateavet nende tegurite kohta saate lugeda Gordon Huffi artiklist "DevOpsi õppetunnid: tervislike katsete 4 aspekti.")

4. Vabastage tee edasi

Ben Grinnell, konsultatsioonifirma North Highland tegevdirektor ja digivaldkonna juht: „Mastaabi saavutamiseks soovitan käivitada „tee puhastamise“ programm koos teedrajavate projektidega. Selle programmi eesmärk on koristada prügi, mille DevOpsi pioneerid endast maha jätavad, nagu aegunud reeglid ja muu taoline, nii et tee edasi jääks selgeks.

„Andke inimestele organisatsioonilist tuge ja hoogu suhtluse kaudu, mis ulatub teerajajarühmast palju kaugemale, tähistades laialdaselt uute tööviiside edu. Treenige inimesi, kes on seotud DevOpsi projektide järgmise lainega ja on närvis DevOpsi esmakordse kasutamise pärast. Ja pidage meeles, et need inimesed on pioneeridest väga erinevad.

5. Demokratiseerige tööriistad

Steve Newman, Scalyri asutaja ja esimees: "Tööriistad ei tohiks olla inimeste eest varjatud ja need peaksid olema suhteliselt hõlpsasti õpitavad kõigile, kes soovivad aega kulutada. Kui logide päringute tegemise võimalus on piiratud kolme tööriista kasutamiseks "sertifitseeritud" inimesega, on probleemi lahendamiseks alati saadaval maksimaalselt kolm inimest, isegi kui teil on väga suur arvutuskeskkond. Teisisõnu, siin on kitsaskoht, mis võib kaasa tuua tõsiseid (ärilisi) tagajärgi.“

6. Loo ideaalsed tingimused meeskonnatööks

Tom Clark, ITV ühise platvormi juht: “Sa võid teha kõike, aga mitte kõike korraga. Nii et seadke suured eesmärgid, alustage väikestest ja liikuge kiirete iteratsioonidega edasi. Aja jooksul kujuneb teil välja maine asjade tegemisel, nii et ka teised soovivad teie meetodeid kasutada. Ja ärge muretsege väga tõhusa meeskonna loomise pärast. Selle asemel looge inimestele ideaalsed töötingimused ja tulemuslikkus järgneb.

7. Ärge unustage Conway seadust ja Kanbani tahvleid

Logan Daigle, CollabNetVersionOne'i tarkvara tarnimise ja DevOpsi strateegia direktor: "On oluline mõista Conway seaduse tagajärgi. Minu lõdvalt ümbersõnastades ütleb see seadus, et meie loodud tooted ja protsessid, mida me selleks kasutame, sealhulgas DevOps, osutuvad ülesehituseks samamoodi nagu meie organisatsioon.

„Kui organisatsioonis on palju silohoidlaid ja kontroll vahetab tarkvara planeerimisel, ehitamisel ja väljastamisel mitu korda omanikku, on skaleerimise mõju null või lühiajaline. Kui organisatsioon loob funktsionaalseid meeskondi toodete ümber, mida rahastatakse turule keskendudes, suureneb eduvõimalus järsult.

"Teine skaleerimise oluline aspekt on kõigi pooleliolevate tööde (WIP, workinprogress) kuvamine Kanbani tahvlitel. Kui organisatsioonil on koht, kus inimesed saavad neid asju näha, julgustab see oluliselt koostööd, millel on positiivne mõju skaleerimisele.

8. Otsige vanu arme

Manuel Pais, DevOpsi konsultant ja Team Topologies kaasautor: „DevOpsi tavade rakendamine väljaspool Dev ja Ops ennast ja nende rakendamine teistele funktsioonidele on vaevalt optimaalne lähenemine. Kindlasti on sellel teatud mõju (näiteks käsitsijuhtimise automatiseerimisega), kuid palju enamat on võimalik saavutada, kui alustada tarne- ja tagasisideprotsesside mõistmisest.

“Kui organisatsiooni IT-süsteemis on vanu arme – protseduure ja juhtimismehhanisme, mis on juurutatud mineviku intsidentide tulemusena, kuid on kaotanud oma aktuaalsuse (muutuste tõttu toodetes, tehnoloogiates või protsessides) –, siis tuleb need kindlasti eemaldada. või silutud, mitte automatiseerida ebatõhusaid või mittevajalikke protsesse.

9. Ärge kasvatage DevOpsi valikuid

Anthony Edwards, Eggplanti operatsioonide direktor: "DevOps on väga ebamäärane termin, nii et igal meeskonnal on oma DevOpsi versioon. Ja pole midagi hullemat, kui organisatsioonil on ühtäkki 20 erinevat DevOpsi, mis omavahel eriti läbi ei saa. Kõigil kolmel arendusmeeskonnal on võimatu omada oma spetsiaalset liidest arenduse ja tootehalduse vahel. Samuti ei tohiks toodetel tootmissimulaatorisse üleviimisel olla oma ainulaadseid ootusi tagasiside käsitlemisel. Vastasel juhul ei saa te kunagi DevOpsi skaleerida.

10. Jutlustage DevOpsi äriväärtust

Steve Newman, Scalyri asutaja ja esimees: "Töötage DevOpsi väärtuse tuvastamiseks. Õppige ja rääkige julgelt oma tegevuse eelistest. DevOps säästab uskumatult aega ja raha (mõelge vaid: vähem seisakuid, lühem keskmine taastumisaeg) ning DevOpsi meeskonnad peavad väsimatult rõhutama (ja jutlustama) nende algatuste tähtsust äriedu jaoks. Nii saate laiendada järgijate ringi ja suurendada DevOpsi mõju organisatsioonis.

BONUS

Edasi Red Hat Foorum Venemaa Meie oma DevOps saabub 13. septembril – jah, Red Hatil kui tarkvaratootjal on oma DevOpsi meeskonnad ja praktikad.

Meie insener Mark Birger, kes arendab sisemisi automatiseerimisteenuseid teistele rühmadele kogu organisatsioonis, räägib selges vene keeles oma loo – kuidas Red Hat DevOpsi meeskond migreeris rakendused Ansible hallatavatest Hat Virtualizationi virtuaalsetest keskkondadest täieõiguslikku konteinerivormingusse OpenShifti platvorm.

Kuid see pole veel kõik:

Kui organisatsioonid on töökoormused konteineritesse teisaldanud, ei pruugi traditsioonilised rakenduste jälgimise meetodid töötada. Teises kõnes selgitame oma motivatsiooni logimisviisi muutmisel ja näitame tee jätku, mis viis meid tänapäevaste raie- ja seiremeetoditeni.

Allikas: www.habr.com