{"id":38521,"date":"2019-10-31T22:24:16","date_gmt":"2019-10-31T19:24:16","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kto-takie-devops\/"},"modified":"2019-10-31T22:24:16","modified_gmt":"2019-10-31T19:24:16","slug":"kto-takie-devops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/kto-takie-devops","title":{"rendered":"Kes on DevOps?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Praegu on see peaaegu kallim positsioon turul. Heli DevOps inseneride \u00fcmber \u00fcletab k\u00f5ik m\u00f5eldavad piirid ja seda hullem on olukord Senior DevOps inseneridega.
\nMa t\u00f6\u00f6tan integratsiooni ja automatiseerimise osakonna juhina, arvake \u00e4ra ingliskeelne l\u00fchend \u2014 DevOps Manager. Kas ingliskeelne l\u00fchend peegeldab meie igap\u00e4evaseid \u00fclesandeid \u2014 ei, aga vene variant on antud juhul t\u00e4psem. Minu t\u00f6\u00f6 iseloomust tulenevalt pean ma loomulikult intervjueerima tulevasi tiimiliikmeid, ja m\u00f6\u00f6dunud aasta jooksul on minu kaudu k\u00e4inud umbes 50 inimest, lisaks on sama palju k\u00f5rvaldatud minu t\u00f6\u00f6tajate esialgsetest intervjuudest.<\/p>\n

<\/p>\n

Meie oleme endiselt kolleegide otsingul, kuna DevOps sildiga peitub v\u00e4ga suur hulk erinevat t\u00fc\u00fcpi insenere.<\/a><\/noindex><\/p>\n

<\/p>\n

K\u00f5ik, mis allpool on kirjutatud, on minu isiklik arvamus, te ei pea sellega n\u00f5ustuma, kuid usun, et see v\u00f5ib teie suhtumist teemasse m\u00f5jutada. V\u00f5ttes arvesse riski j\u00e4\u00e4da halba valgusesse, avaldan oma arvamuse, kuna usun, et sellel on oma koht.<\/p>\n

<\/p>\n

Ettev\u00f5tted m\u00f5istavad erinevalt, kes on DevOps insenerid ja kiire v\u00e4rbamise nimel riputavad nad selle sildi igasugustele inimestele. Olemuselt on olukord \u00fcsna kummaline, kuna ettev\u00f5tted on valmis maksma neile uskumatuid h\u00fcvesid, saades enamasti selle eest administraator-t\u00f6\u00f6riista.<\/p>\n

<\/p>\n

Kellele siis tegelikult kuuluvad DevOps insenerid?<\/h2>\n

<\/p>\n

Alustame ajaloost \u2014 Development Operations tekkis veel \u00fche sammuna, et optimeerida koost\u00f6\u00f6d v\u00e4ikestes meeskondades tootmisprotsessi kiirusel, mis oli oodatud tagaj\u00e4rg. Idee oli selles, et arendustiim saaks tugevdada oma teadmisi tootehalduse protseduuridest ja l\u00e4henemistest. Teisis\u00f5nu, arendaja peab m\u00f5istma, kuidas tema toode erinevates tingimustes t\u00f6\u00f6tab, olema teadlik selle toote kasutuselev\u00f5tust ja teadma, milliseid keskkonna omadusi kohandada, et parandada j\u00f5udlust. Nii tekkis mingi aja p\u00e4rast DevOps l\u00e4henemisega arendajaid. DevOps arendajad kirjutasid kogumise ja pakendamise skripte, et lihtsustada oma tegevust ja tootlikku keskkonda. Siiski, lahenduste arhitektuuri keerukus ja infrastruktuurikomponentide vastastikune m\u00f5ju hakkasid aja jooksul halvendama keskkondade t\u00f6\u00f6j\u00f5udlust; iga iteratsioon n\u00f5udis \u00fcha s\u00fcgavamaid teadmisi erinevatest komponentidest, v\u00e4hendades arendaja tootlikkust, kuna tekkisid lisakulud komponentide m\u00f5istmiseks ja s\u00fcsteemide s\u00e4timiseks konkreetse \u00fclesande jaoks. Arendaja enda hind t\u00f5usis, toote hind koos sellega; uutele arendajatele meeskonnas esitati \u00e4\u00e4rmiselt k\u00f5rgeid n\u00f5udmisi, sest neil tuli ka katta<\/p>\n

<\/p>\n

Osaliselt v\u00f5i t\u00e4ielikult, aja jooksul hakkasid need s\u00fcsteemiadministraatorid aru saama selle konkreetse arendusteami vajadustest, et lihtsustada arendajate ja testijate elu, kuidas rakendada v\u00e4rskendusi ning mitte j\u00e4\u00e4da reedeti \u00f6\u00f6bima kontorisse, parandades juurutusvigu. Aeg m\u00f6\u00f6dus, n\u00fc\u00fcd said s\u00fcsteemiadministraatoritest 'staarsed tegijad', kes m\u00f5istsid, mida arendajad tahavad. H\u00e4irete minimeerimise eesm\u00e4rgil hakati kasutama haldustooted, meenutati k\u00f5iki vanu ja usaldusv\u00e4\u00e4rseid OS-taseme isolatsioonimeetodeid, mis v\u00f5imaldasid minimeerida turvalisuse, v\u00f5rguhalduse n\u00f5udeid ning ka hosti konfiguratsiooni, mis omakorda v\u00e4hendas uute \u201estaaride\u201d n\u00f5udeid. <\/p>\n

<\/p>\n

Ilmus 'suurep\u00e4rane' asi \u2014 docker. Miks on see suurep\u00e4rane? Ainult sellep\u00e4rast, et isolatsiooni loomine chroot'is v\u00f5i jail'is, samuti OpenVZ n\u00f5udis t\u00f5siseid OS- teadmisi, samas kui t\u00f6\u00f6riist v\u00f5imaldas lihtsalt luua rakenduste isoleeritud keskuse mingis hostis koos k\u00f5ikide vajalike elementidega ning anda juhtimise arendusele tagasi, andes s\u00fcsteemiadministraatorile v\u00f5imaluse hallata vaid \u00fchte hosti, tagades selle turvalisuse ja k\u00f5rge k\u00e4ttesaadavuse \u2014 loogiline lihtsustamine. Kuid teadus ei seisa ja s\u00fcsteemid muutuvad j\u00e4rjest keerulisemaks, komponente on \u00fcha rohkem ja rohkem, \u00fcks host enam ei rahulda s\u00fcsteemi vajadusi ja klastreid tuleb ehitada, naaseme j\u00e4lle s\u00fcsteemiadministraatorite juurde, kes suudavad neid s\u00fcsteeme \u00fcles ehitada.<\/p>\n

<\/p>\n

Ts\u00fcklist ts\u00fcklisse ilmnevad erinevad s\u00fcsteemid, mis lihtsustavad arendust ja\/v\u00f5i haldust, ilmuvad orkestreerimiss\u00fcsteemid, mis on sama kaua, kui ei pea standardprotsessist k\u00f5rvale kalduma, lihtsad kasutada. Mikroteenuste arhitektuur ilmnes samuti eesm\u00e4rgiga lihtsustada k\u00f5ike \u00fclaltoodut \u2014 v\u00e4hem vastastikuseid seoseid, lihtsam haldamine. Oma kogemuses ei ole ma t\u00e4ielikult n\u00e4inud mikroteenuste arhitektuuri, \u00fctleksin 50-50 \u2014 50% mikroteenuseid, mustad kastid, mis saadeti sisse, v\u00e4ljund t\u00f6\u00f6tlemine, teised 50% \u2014 rebestatud monoliit, teenused, mis ei suuda t\u00f6\u00f6tada eraldi teistest komponentidest. K\u00f5ik see pani taas piiranguid nii arendajate kui ka administraatorite teadmiste tasemele.<\/p>\n

<\/p>\n

Sarnased \"kiiged\" teatud ressursi ekspertteadmise tasemel kestavad t\u00e4naseni. Kuid oleme veidi k\u00f5rvale kaldunud, on veel palju asju, mida tasub k\u00e4sitleda.<\/p>\n

<\/p>\n

Ehitusinsener \/ V\u00e4ljalaskeinsener<\/h2>\n

<\/p>\n

\u00c4\u00e4rmiselt kitsas spetsialiseerumine, mis tekkis tarkvaraarenduse ja selle v\u00e4ljalaskmise protsesside standardiseerimise vahendina. Agile'i laialdase sisseviimise t\u00f5ttu n\u00e4is, et neist on saanud v\u00e4hem n\u00f5utud, kuid see on kaugel t\u00f5est. See spetsialiseerumine tekkis just tarkvaraarenduse ja tarne standardiseerimise vahendina t\u00f6\u00f6stuslikus mastaabis, s.t. kasutades k\u00f5igi ettev\u00f5tte toodete jaoks standardp\u00e4raseid tehnikaid. DevOps'i tekkimisega kaotasid arendajad osaliselt oma \u00fclesandeid, kuna just nemad hakkasid tootetarnet ette valmistama. Muutuvate infrastruktuuri ja l\u00e4henemisviisi t\u00f5ttu maksimaalselt kiirele tarnimisele, ilma kvaliteedi peale m\u00f5tlemata, muundusid nad ajaga justkui muudatuste piduriteks, kuna kvaliteedistandardite j\u00e4rgimine aeglustab paratamatult tarnet. Nii on j\u00e4rk-j\u00e4rgult osa Build \/ Release inseneride funktsioonidest langenud s\u00fcsteemsete administraatorite \u00f5lgadele.<\/p>\n

<\/p>\n

Ops'id on nii erinevad<\/h2>\n

<\/p>\n

Liigume edasi ja taas, suur hulk kohustusi ja kvalifitseeritud t\u00f6\u00f6tajate puudus sunnib meid ranged spetsialiseerumised v\u00e4lja t\u00f6\u00f6tama nagu seened p\u00e4rast vihma, ilmuvad erinevad Operations:<\/p>\n

<\/p>\n