{"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 tulevikku","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Kurbeltav on t\u00e4nases olukorras see, et IT muutub aeglaselt valdkonnaks, kus inimesel pole enam \"peatumise\" s\u00f5na oma kohustuste hulgas. <\/p>\n

T\u00f6\u00f6pakkumisi lugedes n\u00e4ed vahel juba mitte 2-3 inimest, vaid tervet ettev\u00f5tet \u00fches n\u00e4os. K\u00f5ik kiirustavad, tehnoloogiline v\u00f5lg kasvab, vana legacy paistab uute toodete k\u00f5rval nagu ideaalne lahendus, sest seal on v\u00e4hemalt dokumentatsioon ja kommentaarid koodis. Uued tooted kirjutatakse valguse kiirusel, kuid nende kasutamine v\u00f5ib v\u00f5tta aasta p\u00e4rast valmimist, ja sageli ei too see aasta kasumit. Veelgi enam, kulud 'pilve' peale on k\u00f5rgemad kui teenuse m\u00fc\u00fck. Investeerijate raha kulub veel mitte toimiva teenuse peale, mis on juba turule lastud kui t\u00f6\u00f6tav.<\/a><\/noindex>
\nN\u00e4idena: tuntud ettev\u00f5te, kelle vanema m\u00e4ngu remaster on saanud t\u00f6\u00f6stuse ajaloo madalaimad hinnangud. Ma olin \u00fcks neist, kes ostis selle toote, kuid isegi praegu t\u00f6\u00f6tab see toode kohutavalt ja ei oleks pidanud sellisel kujul m\u00fc\u00fcgile minema. Raha tagasimaksed, reitingu langus, suur hulk kasutajate b\u00e4nnimist foorumites teenuste t\u00f6\u00f6probleemide t\u00f5ttu. Pat\u0161ide arv ei ole muljetavaldav, vaid \u00f5udne, kuid ikkagi \u2013 toode pole kasutatav. Kui selline l\u00e4henemine toob selliseid tulemusi ettev\u00f5ttes, mis on tegelenud arendusega alates 91. aastast, siis algajate ettev\u00f5tetega on olukord veelgi halvem.<\/p>\n

Kuid n\u00fc\u00fcd vaatame, kuidas sellise l\u00e4henemise tulemusi tajub teenuse kasutaja pool, ning n\u00fc\u00fcd vaadakem probleemide poole, mis on tekkinud t\u00f6\u00f6tajatel. <\/p>\n

Ma kuulen sageli v\u00e4idet, et DevOps meeskondi ei peaks olema, et see on metodoloogia jne, kuid probleem on selles, et ettev\u00f5tted on kuidagi l\u00f5petanud nokade, DBA-de, infrastruktuuri ja build-inseneride otsimise \u2013 n\u00fc\u00fcd on see k\u00f5ik DevOps insener \u00fches isikus. Loomulikult on eraldi ettev\u00f5tetes selliseid vabu t\u00f6\u00f6kohti ikka veel, kuid neid on \u00fcha v\u00e4hem. Paljud on seda nimetanud arenguks, aga isiklikult n\u00e4en ma selles degradatsiooni, ei ole v\u00f5imalik k\u00f5igis valdkondades head taset teadmisi hoida ja samal ajal t\u00f6\u00f6tada mitte rohkem kui 8 tundi. Loomulikult \u2013 need on fantaasiad. Tegelikult peavad paljud IT-inimesed t\u00f6\u00f6tama isegi 12\u201314 tundi, millest makstakse 8. Ja sageli ka ilma n\u00e4dalavahetusteta, sest \"mulle pandi \u00fclesanne, dokumentatsiooni pole v\u00f5i see on vale, ja teenus maksab ka raha\", ning \u00fche vea t\u00f5ttu pilves v\u00f5ib t\u00f6\u00f6tasu kahe kuu jooksul lihtsalt saamata j\u00e4\u00e4da, eriti kui t\u00f6\u00f6tad FIE-na. Me kaotame \u00e4ritegevuses s\u00f5na, koos \u00fclesannete jagamisega, ma satun \u00fcha enam sellistesse olukordadesse, kus juhid sekkuvad arendusprotsessidesse, m\u00f5istmata neist absoluutselt midagi, nad segavad \u00e4riandmeid ja rakenduse t\u00f6\u00f6d, mille tagaj\u00e4rjel algab kaos. <\/p>\n

Kui kaos algab, tahab \u00e4ri leida s\u00fc\u00fcdlase, ja siin on vajalik universaalne s\u00fc\u00fcdlane, 10+ inimese s\u00fc\u00fc omistamine on keeruline, seet\u00f5ttu koondavad juhid positsioone, sest mida rohkem kohustusi on \u00fchel spetsialistil, seda lihtsam on t\u00f5estada tema hooletust. Ja Agile'i tingimustes on \"s\u00fc\u00fcdlase\" leidmine ja karmi karistuse m\u00e4\u00e4ramine p\u00f5hialus selle \u00e4ri juhtimise metodoloogias. Agile on juba ammu v\u00e4lja kasvanud IT-st, ja selle p\u00f5hikontseptsioon on muutunud \u2013 igap\u00e4evaste tulemuste n\u00f5udmine. Probleem on selles, et kitsas spetsialist ei pruugi igap\u00e4evaselt tulemusi saavutada, seega on arvestamine keerulisem, ja see on veel \u00fcks p\u00f5hjus, miks \u00e4ri soovib \"spetsialiste k\u00f5igis valdkondades\". Kuid peamine p\u00f5hjus on loomulikult palgafond \u2013 see on peamine muutuste p\u00f5hjus, lisatasu nimel n\u00f5ustusid inimesed t\u00f6\u00f6tama enda ja veel kellegi eest. Kuid tulemuseks on, nagu ka teistes valdkondades, et sellest on n\u00fc\u00fcd saanud lihtsalt kohustus, madalama tasu eest pakutud suurema hulga teenuste eest. <\/p>\n

Praegu n\u00e4eb j\u00e4rjest enam artikleid, kus r\u00e4\u00e4gitakse sellest, et arendajad peavad oskama teha deploy'e, et nad peavad tegelema infrastruktuuriga koos DevOps inseneriga. Kuid kuhu see viib? T\u00e4pselt \u2013 teenuste kvaliteedi langusesse, arendajate kvaliteedi langusesse. Alles kaks p\u00e4eva tagasi seletasin ma arendajale, et kirjutada ja lugeda saab erinevatest hostidest, kuid tal oli tungiv vajadus t\u00f5estada, et ta ei ole kunagi seda n\u00e4inud, ning seaded on ORM-is: host, port, db, kasutaja, parool ja just sellega l\u00f5pp. Kuid arendaja oskab k\u00e4ivitada deploy'e, kirjutada YAML-e... K\u00fcll aga unustab ta unit-testid ja kommentaarid koodis.<\/p>\n

M\u00f5tte tulemusena n\u00e4eme j\u00e4rgmist \u2013 pidevad \u00fcletunnid, probleemide lahendamise otsingud v\u00e4ljaspool t\u00f6\u00f6aega, pidev \u00f5ppimine n\u00e4dalavahetustel, mitte tulude kasvuks, vaid elus p\u00fcsimiseks. Arendajad on sunnitud aitama DevOps inseneri CI\/CD-ga, ja kui arendajal ei ole aega, siis ta hakkab \u00fclekoormatud olema, ning juhid hakkavad segama pead. Kui see ei suurenda sooviga t\u00f6\u00f6tada \u00fcletundidel, siis rakendatakse karistusi ja trahve, inimene otsib uut t\u00f6\u00f6kohta, j\u00e4ttes maha tehnilise v\u00f5la, mis on nagu Everest, tulemuseks on see, et v\u00f5lg hakkab kasvama ka arendajatel, kes on sunnitud kirjutama koodi v\u00e4hese refaktooringuga, et j\u00f5uda kas vana v\u00f5i uue DevOps inseneriga appi minna. Juhte rahuldab see t\u00e4ielikult, sest s\u00fc\u00fcdlane on olemas ja teda on kohe n\u00e4ha, seega on j\u00e4rgitud Agile juhtimise p\u00f5hireeglit \u2013 s\u00fc\u00fcdlane on leitud ja tulemused tema karistamisest on n\u00e4htavad. <\/p>\n

Kunagi esinesin ITGM-is ettekandega \"kui me \u00f5pime \u00fctlema 'ei'\" \u2014 selle tulemused olid v\u00e4ga n\u00e4itlikud. Suur hulk inimesi arvab, et see s\u00f5na on tabu, ja kuni me ei lakka nii uskumas, probleeme ainult kasvavad.<\/p>\n

Osaliselt motiveeris mind selle artikli kirjutamiseks see artikkel<\/a><\/noindex>, kuid ma kirjutan selle hiljem v\u00f5ib-olla v\u00e4hem ringikujuliselt.<\/p>\n

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

Kas olete oma t\u00f6\u00f6s kokku puutunud sellega, et t\u00f6\u00f6andja p\u00fc\u00fcdis teid asendada mitme inimesega?<\/h2>\n