{"id":53925,"date":"2019-12-13T00:00:00","date_gmt":"2019-12-12T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/devops-inzhenerov-ne-sushhestvuet-kto-togda-sushhestvuet-i-chto-s-etim-delat"},"modified":"2020-02-18T14:01:52","modified_gmt":"2020-02-18T11:01:52","slug":"devops-inzhenerov-ne-sushhestvuet-kto-togda-sushhestvuet-i-chto-s-etim-delat","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/devops-inzhenerov-ne-sushhestvuet-kto-togda-sushhestvuet-i-chto-s-etim-delat","title":{"rendered":"DevOps-insenerid ei eksisteeri. Kes siis eksisteerib ja mida sellega teha?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"DevOps-insenerid<\/p>\n

<\/p>\n

Viimastel aegadel on sellised kuulutused internetti tunginud. Kuigi palk on ahvatlev, ei saa j\u00e4tta t\u00e4helepanuta, et sisu on t\u00e4ielik m\u00f6\u00f6da. Alustuseks eeldatakse, et \"DevOps\" ja \"insener\" on mingil moel v\u00f5imalik kokku sulandada, seej\u00e4rel j\u00e4rgneb juhuslik n\u00f5udmiste nimekiri, millest osa on selgelt kopeeritud s\u00fcsteemiadministraatori t\u00f6\u00f6kuulutusest.<\/p>\n

<\/p>\n

Selles postituses tahaksime r\u00e4\u00e4kida, kuidas me oleme j\u00f5udnud sellesse olukorda, mida tegelikult DevOps t\u00e4hendab ja mida selle k\u00f5igega n\u00fc\u00fcd peale hakata.<\/p>\n

<\/p>\n

Selliseid t\u00f6\u00f6kuulutusi v\u00f5ib igati kritiseerida, kuid t\u00f5de j\u00e4\u00e4b t\u00f5eks: neid on palju ja turg on hetkel selline. Me korraldasime DevOps konverentsi ja kuulutasime avatult: \"DevOops<\/a><\/noindex> \u2014 mitte DevOps-inseneridele\". Paljudele tundub see kummaline ja jabur: miks inimesed, kes korraldavad t\u00e4iesti kommertslikku \u00fcritust, l\u00e4hevad turu vastu. Hetkel selgitame k\u00f5ike.<\/p>\n

<\/a><\/noindex><\/p>\n

Kultuurist ja protsessidest<\/h2>\n

<\/p>\n

Alustame sellest, et DevOps ei ole inseneriteema. K\u00f5ik sai alguse sellest, et ajalooliselt v\u00e4lja kujunenud rollide jagamine ei paranda toote kvaliteeti. Kui programmeerijad teevad vaid programmeerimist, kuid ei hooli testimisest, on tarkvara t\u00e4is vigu. Kui administraatoritele ei ole oluline, kuidas ja miks tarkvara on kirjutatud, muutub tugi t\u00f5eliseks v\u00e4ljakutseks. <\/p>\n

<\/p>\n

N\u00e4iteks s\u00fcsteemiadministraatori ja SRE l\u00e4henemise erinevuse kirjeldamine teenuse haldamiseks. algab kuulus Google SRE raamat.<\/a><\/noindex>Huvitavaid uuringuid on l\u00e4bi viidud DORA uuringu<\/a><\/noindex> -st on n\u00e4ha, et parimad arendajad suudavad kuidagi uusi muudatusi tootmisse muita kiiremini kui kord tunnis. Samuti testivad nad k\u00e4sitsi mitte rohkem kui 10% (see on n\u00e4htav eelmisel aastal DORA<\/a><\/noindex>). Kuidas nad selle saavutavad? \"Excel or die\" - \u00fctleb \u00fcks aruande pealkirju. S\u00fcvaanal\u00fc\u00fcsi jaoks selle statistika testimise osas soovitan p\u00f6\u00f6rduda Baruch Sadogursky pealause poole \"Meil on DevOps. L\u00e4hme ja vallandame k\u00f5ik testijad\"<\/a><\/noindex> teisel meie konverentsil, Heisenbug.<\/p>\n

<\/p>\n

\"Kui kaaslaste vahel ei ole \u00fchte meelt,
\nei viib seda asja paika,
\nja sellest ei tule midagi, vaid ainult vaev.\"
\nKunagi oli Luik, V\u00e4hk ja Siig\u2026<\/p><\/blockquote>\n

Kuidas arvate, kui suur hulk veebiarendajatest t\u00f5eliselt m\u00f5istab, millistes tingimustes nende rakendused tootmises t\u00f6\u00f6tavad? Kui palju neist l\u00e4heb s\u00fcsteemiadministraatorite juurde ja proovib m\u00f5ista, mis juhtub andmebaasi kokkuvarisemise korral? Ja kes l\u00e4heb testijate juurde ja palub \u00f5petada, kuidas korralikult teste kirjutada? Ning seal on veel turvaeksperdid, tootejuhid ja palju teisi inimesi.<\/p>\n

<\/p>\n

DevOpsi peamine idee on luua koost\u00f6\u00f6 erinevate rollide ja osakondade vahel. Esiteks saavutatakse see mitte millegi keerulise tarkvaraga, vaid suhtlemise praktikaga. DevOps on kultuur, praktika, metoodika ja protsessid. Sellist inseneri eriala ei eksisteeri, mis nendele k\u00fcsimustele vastaks.<\/p>\n

<\/p>\n

Sulgurts\u00fckkel<\/h2>\n

<\/p>\n

Kust tuli siis distsipliin nimega \"devops-inseneriteadus\"? Meil on selle kohta h\u00fcpotees! DevOpsi ideed osutusid t\u00f5eliselt heaks \u2014 sedav\u00f5rd heaks, et nad said oma edu ohvriks. K\u00f5ikide nende teemade \u00fcmber said kokku m\u00fc\u00fcvad v\u00e4rbajad ja inimesed, kellel on v\u00e4ga eriline \u00f5hkkond.<\/p>\n

<\/p>\n

Kujutage ette: eile olite Himmkas shawarma valmistamas ja t\u00e4na olete juba suur inimene, vanem v\u00e4rbaja. Siin on terve kandidaatide otsingu ja valiku protsess, k\u00f5ik ei ole lihtne, seda tuleb m\u00f5ista. Oletame, et osakonnajuhataja \u00fctleb: leia spetsialist X. Lisame X-le s\u00f5na \"insener\" ja asi on liikumas. Kas vajalik on Linux? Siis on see kindlalt Linuxi insener, kui soovid DevOps'i \u2014 DevOps insener. T\u00f6\u00f6kuulutus ei koosne \u00fcksnes pealkirjast, vaid sinna tuleb kirjutada ka mingi tekst. Lihtsaim on kirjutada Googlest leitud v\u00f5tmes\u00f5nade rida, kes palju suudab fantaasiasse panustada. DevOps koosneb kahest s\u00f5nast \u2014 \"Dev\" ja \"Ops\", seega tuleb kokku panna v\u00f5tmes\u00f5nad, mis puudutavad arendajaid ja administraatoreid, k\u00f5ik \u00fchte hunnikusse. Nii tekivad t\u00f6\u00f6kuulutused, mis r\u00e4\u00e4givad 42 programmeerimiskeele valdamisest ja 20 aastat Kubernetes'i ja Swarmi samaaegsest kasutamisest. T\u00f6\u00f6protsess.<\/p>\n

<\/p>\n

Nii on inimestes juurdunud m\u00f5ttetu ja halastamatu kuvand mingist superkangelasest \"devopsist\", kes seadistab k\u00f5igile deploy'd Jenkinsis ja \u00f5nne tuleb. Ah, kui k\u00f5ik oleks nii lihtne. \"Ja veel, nii saab jahtida s\u00fcsteemi administraatoreid,\" m\u00f5tleb HR, \"moes\u00f5na, v\u00f5tmes\u00f5nad on samad, peaksid s\u00f6\u00f6ma minema.\"<\/p>\n

<\/p>\n

N\u00f5udlus tekitab pakkumise, ja k\u00f5ikide nende jaburite t\u00f6\u00f6kuulutuste peale t\u00f5ttas hullumeelne hulk s\u00fcsteemiadministraatoreid, kes taipasid: saab teha k\u00f5ike nagu varem, aga teenida mitu korda rohkem, nimetades end \"devopsideks\". Kuidas sa seadistasid servereid l\u00e4bi SSH k\u00e4sitsi \u00fckshaaval, teed sa seda edasi, aga n\u00fc\u00fcd on see justkui devopsi praktika. See on keeruline n\u00e4htus, mis on osaliselt seotud klassikaliste adminnide alahindamisega ja DevOpsi \u00fcmber toimuva hype'iga, aga kokkuv\u00f5ttes \u2014 mis on, see on.<\/p>\n

<\/p>\n

Nii et meil on n\u00f5udlus ja pakkumine. Suletud ring, mis toidab ennast ise. Just selle vastu me v\u00f5itleme (sealhulgas korraldades DevOops konverentsi).<\/p>\n

<\/p>\n

Ilmselgelt ei ole ainukesed s\u00fcsteemiadministraatorid, kes on end \"devopsideks\" \u00fcmber nimetanud, ka teisi osalisi \u2014 n\u00e4iteks professionaalsed SRE-d v\u00f5i Infrastructure-as-Code arendajad.<\/p>\n

<\/p>\n

Millega inimesed DevOpsis (t\u00f5eliselt) tegelevad<\/h2>\n

<\/p>\n

Nii et soovite edeneda DevOpsi praktikate \u00f5ppimisel ja rakendamisel. Aga kuidas seda teha, millisesse suunda vaadata? Ilmne on, et pimesi j\u00e4rgida populaarseid m\u00e4rks\u00f5nu ei tasu.<\/p>\n

<\/p>\n

Kui t\u00f6\u00f6d on, peab keegi sellega tegelema. Oleme juba v\u00e4lja selgitanud, et need ei ole \"DevOps-insenerid\", siis kes? Tundub, et \u00f5igem on seda formuleerida mitte ametite, vaid konkreetsete t\u00f6\u00f6valdkondade kaudu.<\/p>\n

<\/p>\n

Esiteks v\u00f5ib tegeleda DevOpsi s\u00fcdamiku \u2014 protsesside ja kultuuriga. Kultuur on aeglane ja keeruline teema, ja kuigi see on traditsiooniliselt juhtide vastutusalas, osalevad selles k\u00f5ik, alates programmeerijatest kuni administraatoriteni. Paar kuud tagasi \u00fctles Tim Lister intervjuus<\/a><\/noindex>:<\/p>\n

<\/p>\n

\u00abKultuur m\u00e4\u00e4ratleb organisatsiooni p\u00f5hiv\u00e4\u00e4rtused. Inimesed ei pruugi seda tavaliselt m\u00e4rgata, kuid meie, olles kogenud konsultandid, oleme selle m\u00e4rkamisega harjunud. Sa l\u00e4hed ettev\u00f5ttesse ja juba m\u00f5ne minuti p\u00e4rast hakkad sa tunnetama, mis toimub. Me nimetame seda \u2018l\u00f5hnaks\u2019. Vahel on see l\u00f5hn t\u00f5eliselt meeldiv. Vahel aga tekitab see iiveldust. (\u2026) Sa ei saa kultuuri muuta, enne kui ei ole teadlik v\u00e4\u00e4rtustest ja uskumustest, mis konkreetseid tegusid juhivad. K\u00e4itumist on lihtne j\u00e4lgida, aga uskumusi on keeruline leida. DevOps on just hea n\u00e4ide sellest, kuidas k\u00f5ik muutub j\u00e4rjest keerulisemaks.\u00bb<\/p><\/blockquote>\n

On the technical side, of course, there is an issue. If your new code comes for testing after a month, but the release only happens a year later, and it's physically impossible to speed this up \u2014 you might never reach good practices. Good practices are supported by good tools. For instance, with the concept of Infrastructure-as-Code in mind, you can use anything from AWS CloudFormation and Terraform to Chef-Ansible-Puppet. You need to know and be able to use all of this, and that is already a proper engineering discipline. It\u2019s important not to confuse cause and effect: first, you work according to SRE principles, and only then implement these principles in the form of specific technical solutions. Moreover, SRE is a very complex methodology that doesn\u2019t just focus on configuring Jenkins but revolves around five key principles:<\/p>\n

<\/p>\n