{"id":89062,"date":"2020-07-18T07:41:57","date_gmt":"2020-07-18T05:41:57","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/devops-ili-kak-my-teryaem-zarabotnuyu-platu-i-budushhee-it-otrasli"},"modified":"2020-07-18T07:41:57","modified_gmt":"2020-07-18T05:41:57","slug":"devops-ili-kak-my-teryaem-zarabotnuyu-platu-i-budushhee-it-otrasli","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/devops-ili-kak-my-teryaem-zarabotnuyu-platu-i-budushhee-it-otrasli","title":{"rendered":"DevOps v\u00f5i kuidas me kaotame palka ja IT-sektori tuleviku","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

P\u00f5hjustav mure t\u00e4nases olukorras on see, et IT muutub j\u00e4rk-j\u00e4rgult valdkonnaks, kus s\u00f5na \u201epeatuma\u201d ei ole \u00fcldse, kuna \u00fche inimese kohustuste hulk suureneb pidevalt. <\/p>\n

T\u00f6\u00f6pakkumisi lugedes n\u00e4ed m\u00f5nikord juba mitte 2-3 inimest, vaid terve ettev\u00f5tte \u00fches isikus, k\u00f5ik kiirustavad, tehnoloogilised kohustused kasvavad, vana legacy tundub uute toodete taustal t\u00e4iuslikkuse kehastusena, sest seal on v\u00e4hemalt dokumentatsioon ja kommentaarid koodis, uued tooted kirjutatakse valguskiirusel, kuid l\u00f5puks ei saa neid kasutada enne aastat p\u00e4rast nende valmimist, ja k\u00f5ige hullem, et see aasta ei too kasumit, pigem on \u201epilve\u201d kulud suuremad kui teenuse m\u00fc\u00fck. Investorite raha l\u00e4heb veel mitte t\u00f6\u00f6tava teenuse \u00fcleval pidamiseks, mis on juba v\u00e4lja lastud kui toimiv.<\/a><\/noindex>
\nN\u00e4iteks: tuntud ettev\u00f5te, kelle vanema m\u00e4ngu remaster on saanud t\u00f6\u00f6stuse ajaloo madalaimad hinnangud. Ma olin \u00fcks neist, kes selle toote ostis, kuid isegi n\u00fc\u00fcd t\u00f6\u00f6tab see toode kohutavalt ning ei tohiks sellisel kujul m\u00fc\u00fcgile tulla. Raha tagastamine, reitingute langus, tohutu arv kasutajabaneeringuid foorumites seoses teenuste t\u00f6\u00f6ga. Patchide arv ei h\u00e4mmasta, vaid \u0161okeerib, kuid toode on ikkagi kasutamisk\u00f5lbmatu. Kui selline l\u00e4henemine toob selliseid tulemusi ettev\u00f5ttes, mis on arendamisega tegelenud alates 1991. aastast, siis alustavate ettev\u00f5tete olukord on veel halvem.<\/p>\n

Kuid vaatame n\u00fc\u00fcd seda l\u00e4henemist teenuse kasutaja vaatepunktist, n\u00fc\u00fcd aga vaadakem probleeme, mis on tekkinud t\u00f6\u00f6tajatele. <\/p>\n

Ma kuulen tihti v\u00e4idet, et DevOps meeskondi ei tohiks olla, et see on lihtsalt metodoloogia jne, aga probleem on selles, et ettev\u00f5tted on mingil p\u00f5hjusel l\u00f5petanud spetsialistide, dba-de, infrastruktuuriinseneride ja build-inseneride otsimise \u2013 n\u00fc\u00fcd on see k\u00f5ik \u00fcksik DevOps insener. Muidugi on m\u00f5nes ettev\u00f5ttes selliseid vabu ametikohti veel, kuid neid on j\u00e4rjest v\u00e4hem. Paljud on seda nimetanud arenguks, aga mina n\u00e4en selles allak\u00e4iku \u2013 on v\u00f5imatu hoida igas valdkonnas head teadmiste taset ja samas t\u00f6\u00f6tada mitte rohkem kui 8 tundi. Loomulikult on see vaid fantaasia. T\u00f5es, paljud IT-spetsialistid peavad t\u00f6\u00f6tama 12\u201314 tundi, millest makstakse ainult 8. Ja tihti ka ilma n\u00e4dalavahetusteta, sest \"minule anti \u00fclesanne, dokumente pole v\u00f5i need on vigased, ja teenus maksab liiga palju\", ning \u00fche vea puhul pilves v\u00f5id \u00fcldiselt palka mitu kuud mitte saada, eriti kui t\u00f6\u00f6tad FIE-na. Me kaotame tegelikult s\u00f5na \u00e4ris koos kohustuste jagamisega, ma sattun \u00fcha enam olukordadesse, kus juhid sekkuvad arendusprotsessidesse, m\u00f5istmata nendest \u00fcldse midagi, nad ajavad segamini \u00e4rilisi andmeid ja rakenduse t\u00f6\u00f6d, mille tulemusel algab kaos. <\/p>\n

Kui caos tekib, soovib ettev\u00f5te leida s\u00fc\u00fcdlase, ja siis on vaja universaalset s\u00fc\u00fcdlast; on keeruline s\u00fc\u00fc kanda 10+ inimesele, mist\u00f5ttu juhid \u00fchendavad ametikohti, kuna mida rohkem on \u00fche spetsialisti kohustusi, seda lihtsam on t\u00f5estada tema hooletust. Agile\u2019i kontekstis on 's\u00fc\u00fcdlase' leidmine ja karistamine \u00e4ritegevuse juhtimise meetodoloogia alused. Agile on ammu IT-st v\u00e4lja kasvanud ja selle peamine kontseptsioon on igap\u00e4evaste tulemuste n\u00f5udmine. Probleem on selles, et kitsas spetsialiseerumisega spetsialistil ei pruugi igap\u00e4evaselt tulemusi olla, seega on aruandlus keerulisem, ja see on veel \u00fcks p\u00f5hjus, miks ettev\u00f5tted soovivad 'k\u00f5iki ametikohti katvaid spetsialiste'. Kuid peamine p\u00f5hjus on siiski palgakulud \u2013 see on k\u00f5igi muutuste aluseks; lisatasu nimel n\u00f5ustusid inimesed t\u00f6\u00f6tama enda ja teiste eest. L\u00f5pptulemusena on see nagu teistes valdkondades \u2013 sellest on saanud kohustus, millega pakutakse rohkem teenuseid v\u00e4iksema tasu eest. <\/p>\n

Praegu n\u00e4eb sageli artikleid, kus v\u00e4idetakse, et arendajad peavad oskama kasutada deploy't ja tegelema infrastruktuuriga koos DevOps inseneriga. Kuid kuhu see viib? \u00d5igesti \u2013 teenuste kvaliteedi langusele ja arendajate kvaliteedi halvenemisele. Just paar p\u00e4eva tagasi selgitasin arendajale, et kirjutamine ja lugemine v\u00f5ib toimuda erinevatelt hostidelt, aga tema t\u00f5estas s\u00f5naselgelt, et ei ole kunagi sellist asju n\u00e4inud. Tal on olemas settings'is orm host, port, db, user, password ja k\u00f5ik\u2026 Kuid arendaja oskab k\u00e4ivitada deploy'sid ja kirjutada YAML'e\u2026 Kuid unustab juba \u00fchitestid ja kommentaarid koodis.<\/p>\n

Kokkuv\u00f5ttes n\u00e4eme j\u00e4rgmist \u2013 pidevad \u00fclet\u00f6\u00f6tamised, probleemide lahendamine v\u00e4ljaspool t\u00f6\u00f6aega, pidev \u00f5ppimine n\u00e4dalavahetustel, ja mitte suurtulu saavutamiseks, vaid enda pinnal p\u00fcsimiseks. Arendajad peavad aitama DevOps inseneri CI\/CD-s, ja kui arendajal pole aega, algab tal \u00fclekoormus, ning juhid hakkavad ajusid segama, ning kui see ei aita suurendada soovi teha \u00fclet\u00f6\u00f6d, v\u00f5ivad nad rakendada karistusi ja trahve. Inimene otsib uut t\u00f6\u00f6kohta, j\u00e4ttes maha tehnilise v\u00f5la, mis on suur nagu Everest, mille tulemusena v\u00f5lg hakkab suurenema ka arendajatel, kuna nad peavad kirjutama koodi v\u00e4hem refaktoorides, et j\u00f5uda kas iidse v\u00f5i uue DevOps insenerini aidata. Ja juhid on sellega t\u00e4iesti rahul, kuna s\u00fc\u00fcdistatava leidmine on lihtne ja n\u00e4htav, seega on peamine reegel Agile juhtimises t\u00e4idetud \u2013 s\u00fc\u00fcdlane on leitud, ja karistamise tulemused on n\u00e4htavad. <\/p>\n

Kordagi ITGM-is esitasin ettekande \"Kui me \u00f5pime \u00fctlema 'ei'\" \u2014 selle tulemused olid v\u00e4ga k\u00f5nekad. Suur hulk inimesi arvab, et see s\u00f5na on tabu, ja kuni me ei lakka nii arvamast, probleemid ainult kasvavad.<\/p>\n

Osaliselt inspireeris mind sellele artiklile see artikkel<\/a><\/noindex>, kuid hiljem kirjutan ma selle v\u00f5ib-olla v\u00e4hem \u00fcmber k\u00e4ivate terminitega.<\/p>\n

Ainult registreeritud kasutajad saavad k\u00fcsitluses osaleda. Logige sisse<\/a><\/noindex>, palun.<\/p>\n

Kas olete t\u00f6\u00f6 k\u00e4igus kokku puutunud olukordadega, kus t\u00f6\u00f6andja \u00fcritas teid asendada mitme inimesega?<\/h2>\n