{"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

Viimaseid aegu on sellised kuulutused t\u00e4itnud internetti. Kuigi palk v\u00f5ib olla meeldiv, ei saa eirata, et jagatud kirjutises on t\u00e4ielik vale. Alguses eeldatakse, et \u201eDevOps\u201c ja \u201einsener\u201c saab mingil moel kokku liita \u00fcheks s\u00f5naks, siis j\u00e4rgnevad suvaline nimekiri n\u00f5udmistest, millest osa on selgelt kopeeritud s\u00fcsteemiadministraatori t\u00f6\u00f6kohast.<\/p>\n

<\/p>\n

Selles postituses tahaksime r\u00e4\u00e4kida, kuidas me sellesse olukorda j\u00f5udsime, mis DevOps tegelikult on ja mida n\u00fc\u00fcd sellega teha.<\/p>\n

<\/p>\n

Selliseid t\u00f6\u00f6pakkumisi v\u00f5ib kindlasti kriitika alla v\u00f5tta, kuid p\u00f5hjused on selged: neid on palju ja selline on hetke turg. Me korraldasime devops-konverentsi ja \u00fctleme avameelselt: \"DevOops<\/a><\/noindex> \u2014 ei ole DevOps-inseneridele\". Paljudele tundub see kummaline ja veider: miks inimesed, kes korraldavad t\u00e4iesti \u00e4rilist \u00fcritust, on turu vastu. Praegu seletame k\u00f5ik v\u00e4lja.<\/p>\n

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

Kultuurist ja protsessidest<\/h2>\n

<\/p>\n

Alustame sellest, et DevOps ei ole inseneriteadus. K\u00f5ik algas sellest, et ajalooliselt kujunenud rollide jaotamine ei t\u00f6\u00f6ta tootete kvaliteedi nimel. Kui programmeerijad programmeerivad, kuid ei soovi kuulda testimisest \u2013 tarkvara on t\u00e4is vigu. Kui administraatorid ei hooli, kuidas ja miks tarkvara on kirjutatud \u2013 tugi muutub \u00f5uduseks. <\/p>\n

<\/p>\n

N\u00e4iteks kirjeldatakse erinevust s\u00fcsteemiadministraatori ja SRE l\u00e4henemise vahel teenuse haldamisel kuulsas Google SRE raamatus.<\/a><\/noindex>Huvitavad uuringud viidi l\u00e4bi DORA k\u00fcsitluses<\/a><\/noindex> \u2013 on selge, et parimad arendajad suudavad kuidagi uusi muudatusi tootmisse panna kiiremini kui kord tunnis. Nad testivad aga k\u00e4sitsi mitte rohkem kui 10% (see on n\u00e4ha) eelmisest DORA'st.<\/a><\/noindex>Kuidas nad selle saavutavad? \"Excel or die\" \u2013 \u00fctleb \u00fcks aruande pealkirjadest. \u00dcksikasjalikumate arutelude saamiseks selle statistika kohta testimise kontekstis v\u00f5id p\u00f6\u00f6rduda Baruch Sadogursky k\u00f5ne poole \"Meil on DevOps. Tulge, vallandame k\u00f5ik testijad\"<\/a><\/noindex> meie teisel konverentsil, Heisenbug.<\/p>\n

<\/p>\n

\"Kui s\u00f5prade seas pole kokkulepet,
\nSiis ei \u00f5nnestu koost\u00f6\u00f6l,
\nJa ei tule sellest muud kui vaev.
\nKord Luulet, Kraan ja Siig...\"<\/p><\/blockquote>\n

Mida arvate, kui suur osa veebiprogrammeerijatest m\u00f5istab tegelikult, millistes tingimustes nende rakendused tootmises t\u00f6\u00f6tavad? Kui palju neist l\u00e4heb administraatorite juurde ja p\u00fc\u00fcab v\u00e4lja selgitada, mis juhtub andmebaasi kokkuvarisemisel? Ja kes neist l\u00e4heks teste tegema ja paluks \u00f5petada, kuidas \u00f5igesti teste kirjutada? Seal on veel turvamehi, tootejuhte ja palju teisi inimesi.<\/p>\n

<\/p>\n

DevOpsi peamine idee on tagada sujuv koost\u00f6\u00f6 rollide ja osakondade vahel. Esiteks saavutatakse see mitte mingite keerukate tarkvaralahendustega, vaid suhtlemise praktikaga. DevOps on kultuur, praktika, metodoloogia ja protsessid. Ei ole sellist insenerierialat, mis vastaks nendele k\u00fcsimustele.<\/p>\n

<\/p>\n

Sulgur ring<\/h2>\n

<\/p>\n

Kust aga tekkis distsipliin nimega \u201edevops-inseneria\u201d? Meil on teooria! DevOpsi ideed osutusid nii heaks, et nad muutusid oma edu ohvriks. \u00dcmber selle teema hakkasid kogunema kahtlased v\u00e4rbajad ja inimkaubitsejad, kellel on oma ainulaadne \u00f5hkkond.<\/p>\n

<\/p>\n

Kujutage ette: eile tegite Himmis shawarma\u2019t, aga t\u00e4na olete juba suur inimene, vanem v\u00e4rbaja. Siin on terve kandidaatide otsimise ja valimise protsess, k\u00f5ik ei ole lihtne, tuleb aru saada. Oletame, et osakonna juht \u00fctleb: leia spetsialist X jaoks. Lisame X-ile s\u00f5na \u201einsener\u201d ja asi on klaar. Kas on vajalik Linux? No see on kindel Linux-insener, soovite DevOps\u2019i \u2014 DevOps-insener. T\u00f6\u00f6kuulutus ei koosne mitte ainult pealkirjast, vaid sees peab olema ka mingit teksti. Lihtsaim on kirjutada Google\u2019ist leitud m\u00e4rks\u00f5nade kogum,et kellelgi piisab fantaasiast. DevOps koosneb kahest s\u00f5nast \u2014 \u201eDev\u201d ja \u201eOps\u201d, seega tuleb kokku kleebida arendajate ja administratoride suhtes seotud m\u00e4rks\u00f5nad, k\u00f5ik \u00fchte kuhja. Nii tekivad t\u00f6\u00f6kuulutused, mis n\u00f5uavad 42 programmeerimiskeele valdamist ja 20 aastat Kubernetes\u2019i ja Swarm\u2019i samaaegset kasutamist. T\u00f6\u00f6korraldus.<\/p>\n

<\/p>\n

Nii on inimeste teadvuses juurdunud m\u00f5ttetu ja halastamatu superkangelaste \u201edevops\u2019i\u201d kuvand, kes seadistab k\u00f5igile Jenkinsis deploy\u2019i ja \u00f5nn tuleb. Oh, kui k\u00f5ik oleks nii lihtne. \"Ja veel v\u00f5ib sellega s\u00fcsteemiadministreerijate peal jahipidada,\" m\u00f5tleb HR, \"moodne s\u00f5na, m\u00e4rks\u00f5nad on samad, peaksid kindlasti klikkima.\"<\/p>\n

<\/p>\n

K\u00fcsimus loob pakkumise ja k\u00f5ikidele nende n\u00f5medatele t\u00f6\u00f6pakkumistele on tunginud meeletu arv s\u00fcsteemiadministraatoreid, kes on aru saanud: neid samu asju saab teha sama h\u00e4sti nagu varem, aga n\u00fc\u00fcd saab teenida mitu korda rohkem, nimetades ennast 'devops' nende considerat ning see \"devopsi praktika\". Nii nagu sa seadistad servere SSH kaudu k\u00e4sitsi \u00fckshaaval, nii j\u00e4tkad sa seda tegemist, ainult et n\u00fc\u00fcd on see n\u00e4iliselt devopsi harjutamine. See on keeruline n\u00e4htus, mis on osaliselt seotud klassikaliste adminnide alahindamise ja DevOpsi h\u00fcpete ringiga, kuid kokkuv\u00f5ttes on see, mis see on.<\/p>\n

<\/p>\n

Nii et meil on n\u00f5udlus ja pakkumine. Isolatsioon, mis toidab iseennast. Sellega meie tegeleme (sh luues DevOops konverentsi).<\/p>\n

<\/p>\n

Muidugi, lisaks s\u00fcsteemiadminnidele, kes on nimetatud 'devopsiks', on ka teisi osalisi \u2014 n\u00e4iteks professionaalsed SRE-d v\u00f5i Infrastructure-as-Code arendajad.<\/p>\n

<\/p>\n

Mida inimesed DevOpsis t\u00f5eliselt teevad<\/h2>\n

<\/p>\n

Nii et soovid s\u00fcveneda DevOpsi praktikatena. Kuidas seda teha, kuhu suunda vaadata? Ilmselt ei tasu pime pidada kinni populaarsetest m\u00e4rks\u00f5nadest.<\/p>\n

<\/p>\n

Kui t\u00f6\u00f6 on olemas, peab keegi sellega tegelema. Oleme juba v\u00e4lja selgitanud, et need ei ole 'devopsinsenerid', siis kes? Tundub, et \u00f5igem on seda formuleerida mitte ametikohtade terminoloogia, vaid konkreetsete t\u00f6\u00f6alaste suundade kaudu.<\/p>\n

<\/p>\n

Esiteks, v\u00f5ib tegeleda DevOpsi s\u00fcdamega \u2014 protsesside ja kultuuriga. Kultuur on aeglane ja keeruline asi, ja kuigi see on traditsiooniliselt juhtide vastutus, osaleb selles k\u00f5ik, alates programmeerijatest kuni adminnideni. M\u00f5ni kuu tagasi \u00fctles Tim Lister intervjuus<\/a><\/noindex>:<\/p>\n

<\/p>\n

\"Kultuur on m\u00e4\u00e4ratud organisatsiooni p\u00f5hiv\u00e4\u00e4rtustega. Tavaline on, et inimesed ei pane sellele t\u00e4hele, kuid me, olles t\u00f6\u00f6tanud konsultatsioonis juba aastaid, oleme harjunud sellele t\u00e4helepanu p\u00f6\u00f6rama. Sa astud ettev\u00f5ttesse ja juba m\u00f5ne minuti p\u00e4rast hakkad tundma, mis toimub. Me nimetame seda 'l\u00f5hnaks'. M\u00f5nikord on see l\u00f5hn t\u00f5eliselt hea. M\u00f5nikord tekitab see iiveldust. (...) Sa ei saa kultuuri muuta enne, kui on selgitatud v\u00e4lja v\u00e4\u00e4rtused ja uskumused, mis seisavad konkreetsed tegevused. K\u00e4itumist on lihtne j\u00e4lgida, aga uskumiste otsimine on keeruline. DevOps on just suurep\u00e4rane n\u00e4ide sellest, kuidas k\u00f5ik muutub \u00fcha keerulisemaks.\"<\/p><\/blockquote>\n

On the technical side of things, of course, there's a question. If your new code arrives for testing in a month, but it only gets released a year later, and physically speeding this up is impossible, then you might not even reach good practices. Good practices are supported by good tools. For example, by holding the concept of Infrastructure-as-Code in mind, one can use anything from AWS CloudFormation and Terraform to Chef-Ansible-Puppet. It is essential to know and be able to use all of this, and that is already a genuine engineering discipline. It's vital not to confuse cause and effect: first, you work according to SRE principles, and only then do you implement these principles in the form of specific technical solutions. Moreover, SRE is a very comprehensive methodology, which doesn't just tell you how to configure Jenkins, but rather about five main principles:<\/p>\n

<\/p>\n