🥇DevOps või kuidas me kaotame sissetuleku ja IT-sektori tuleviku

Kurbeltav on tänases olukorras see, et IT muutub aeglaselt valdkonnaks, kus inimesel pole enam "peatumise" sõna oma kohustuste hulgas.

Tööpakkumisi lugedes näed vahel juba mitte 2-3 inimest, vaid tervet ettevõtet ühes näos. Kõik kiirustavad, tehnoloogiline võlg kasvab, vana legacy paistab uute toodete kõrval nagu ideaalne lahendus, sest seal on vähemalt dokumentatsioon ja kommentaarid koodis. Uued tooted kirjutatakse valguse kiirusel, kuid nende kasutamine võib võtta aasta pärast valmimist, ja sageli ei too see aasta kasumit. Veelgi enam, kulud 'pilve' peale on kõrgemad kui teenuse müük. Investeerijate raha kulub veel mitte toimiva teenuse peale, mis on juba turule lastud kui töötav.
Näidena: tuntud ettevõte, kelle vanema mängu remaster on saanud tööstuse ajaloo madalaimad hinnangud. Ma olin üks neist, kes ostis selle toote, kuid isegi praegu töötab see toode kohutavalt ja ei oleks pidanud sellisel kujul müügile minema. Raha tagasimaksed, reitingu langus, suur hulk kasutajate bännimist foorumites teenuste tööprobleemide tõttu. Patšide arv ei ole muljetavaldav, vaid õudne, kuid ikkagi – toode pole kasutatav. Kui selline lähenemine toob selliseid tulemusi ettevõttes, mis on tegelenud arendusega alates 91. aastast, siis algajate ettevõtetega on olukord veelgi halvem.

Kuid nüüd vaatame, kuidas sellise lähenemise tulemusi tajub teenuse kasutaja pool, ning nüüd vaadakem probleemide poole, mis on tekkinud töötajatel.

Ma kuulen sageli väidet, et DevOps meeskondi ei peaks olema, et see on metodoloogia jne, kuid probleem on selles, et ettevõtted on kuidagi lõpetanud nokade, DBA-de, infrastruktuuri ja build-inseneride otsimise – nüüd on see kõik DevOps insener ühes isikus. Loomulikult on eraldi ettevõtetes selliseid vabu töökohti ikka veel, kuid neid on üha vähem. Paljud on seda nimetanud arenguks, aga isiklikult näen ma selles degradatsiooni, ei ole võimalik kõigis valdkondades head taset teadmisi hoida ja samal ajal töötada mitte rohkem kui 8 tundi. Loomulikult – need on fantaasiad. Tegelikult peavad paljud IT-inimesed töötama isegi 12–14 tundi, millest makstakse 8. Ja sageli ka ilma nädalavahetusteta, sest "mulle pandi ülesanne, dokumentatsiooni pole või see on vale, ja teenus maksab ka raha", ning ühe vea tõttu pilves võib töötasu kahe kuu jooksul lihtsalt saamata jääda, eriti kui töötad FIE-na. Me kaotame äritegevuses sõna, koos ülesannete jagamisega, ma satun üha enam sellistesse olukordadesse, kus juhid sekkuvad arendusprotsessidesse, mõistmata neist absoluutselt midagi, nad segavad äriandmeid ja rakenduse tööd, mille tagajärjel algab kaos.

Kui kaos algab, tahab äri leida süüdlase, ja siin on vajalik universaalne süüdlane, 10+ inimese süü omistamine on keeruline, seetõttu koondavad juhid positsioone, sest mida rohkem kohustusi on ühel spetsialistil, seda lihtsam on tõestada tema hooletust. Ja Agile'i tingimustes on "süüdlase" leidmine ja karmi karistuse määramine põhialus selle äri juhtimise metodoloogias. Agile on juba ammu välja kasvanud IT-st, ja selle põhikontseptsioon on muutunud – igapäevaste tulemuste nõudmine. Probleem on selles, et kitsas spetsialist ei pruugi igapäevaselt tulemusi saavutada, seega on arvestamine keerulisem, ja see on veel üks põhjus, miks äri soovib "spetsialiste kõigis valdkondades". Kuid peamine põhjus on loomulikult palgafond – see on peamine muutuste põhjus, lisatasu nimel nõustusid inimesed töötama enda ja veel kellegi eest. Kuid tulemuseks on, nagu ka teistes valdkondades, et sellest on nüüd saanud lihtsalt kohustus, madalama tasu eest pakutud suurema hulga teenuste eest.

Praegu näeb järjest enam artikleid, kus räägitakse sellest, et arendajad peavad oskama teha deploy'e, et nad peavad tegelema infrastruktuuriga koos DevOps inseneriga. Kuid kuhu see viib? Täpselt – teenuste kvaliteedi langusesse, arendajate kvaliteedi langusesse. Alles kaks päeva tagasi seletasin ma arendajale, et kirjutada ja lugeda saab erinevatest hostidest, kuid tal oli tungiv vajadus tõestada, et ta ei ole kunagi seda näinud, ning seaded on ORM-is: host, port, db, kasutaja, parool ja just sellega lõpp. Kuid arendaja oskab käivitada deploy'e, kirjutada YAML-e... Küll aga unustab ta unit-testid ja kommentaarid koodis.

Mõtte tulemusena näeme järgmist – pidevad ületunnid, probleemide lahendamise otsingud väljaspool tööaega, pidev õppimine nädalavahetustel, mitte tulude kasvuks, vaid elus püsimiseks. Arendajad on sunnitud aitama DevOps inseneri CI/CD-ga, ja kui arendajal ei ole aega, siis ta hakkab ülekoormatud olema, ning juhid hakkavad segama pead. Kui see ei suurenda sooviga töötada ületundidel, siis rakendatakse karistusi ja trahve, inimene otsib uut töökohta, jättes maha tehnilise võla, mis on nagu Everest, tulemuseks on see, et võlg hakkab kasvama ka arendajatel, kes on sunnitud kirjutama koodi vähese refaktooringuga, et jõuda kas vana või uue DevOps inseneriga appi minna. Juhte rahuldab see täielikult, sest süüdlane on olemas ja teda on kohe näha, seega on järgitud Agile juhtimise põhireeglit – süüdlane on leitud ja tulemused tema karistamisest on nähtavad.

Kunagi esinesin ITGM-is ettekandega "kui me õpime ütlema 'ei'" — selle tulemused olid väga näitlikud. Suur hulk inimesi arvab, et see sõna on tabu, ja kuni me ei lakka nii uskumas, probleeme ainult kasvavad.

Osaliselt motiveeris mind selle artikli kirjutamiseks see artikkel, kuid ma kirjutan selle hiljem võib-olla vähem ringikujuliselt.

Ainult registreeritud kasutajad saavad küsitluses osaleda. Logige sisse, palun.