🥇DevOps ose si po humbasim pagën dhe të ardhmen e industrisë IT

Më e trishtueshmja në situatën e sotme është se IT po bëhet gradualisht një industri ku pothuajse nuk ka fjalën “stop” në sasinë e detyrave për një person.

Duke lexuar shpalljet për punë, ndonjëherë edhe shohim jo 2-3 njerëz, por një kompani të tërë në një person, të gjithë po nxitohen, borxhi teknik po rritet, legjenda e vjetër përballë produkteve të reja duket perfekte, sepse në të paktën ka dokumentacion dhe komente në kod, produktet e reja shkruhen me shpejtësi të madhe, por përfundimisht nuk mund të përdoren ende për një vit pas shkruan, dhe shpesh ky vit nuk sjell fitime. Për më tepër, shpenzimet për “cloud” janë më të larta se shitjet e shërbimit. Paratë e investitorëve shpenzohen për mbështetje të një shërbimi që ende nuk funksionon, por që tashmë është lëshuar në rrjet si i tillë.
Si një shembull: një kompani e njohur, e cila remasterizoi një lojë të vjetër që mori vlerësimet më të ulta në historinë e industrisë. Unë isha një nga ata që bleva këtë produkt, por ende tani ky produkt punohet tmerrësisht, dhe në parim nuk dukej se duhej të dilte në shitje në këtë formë. Kthimet e parave, rënia e vlerësimit, një numër i madh bllokimesh për përdoruesit në forume për ankesat mbi performancën e shërbimeve. Numri i patcheve nuk ngazëllehet, por të qan, por përmbajtja mbetet jo e përdorshme. Nëse ky qasje sjell rezultate të tilla për një kompani, e cila merret me zhvillimin që nga viti 91, atëherë situata për kompanitë që sapo po fillojnë aktivitetin e tyre është edhe më e keqe.

Por ne e pamë këtë qasje nga perspektiva e përdoruesit të shërbimit, tani le të shohim problemet që kanë dalë për punonjësit.

Shumë herë dëgjoj pretendimin se nuk duhet të ekzistojnë grupe DevOps, që kjo është një metodologji etj., por ja që kompanitë kanë pushuar së kërkuari noka, DBA, infrastrukturistë dhe inxhinierë ndërtimi – tani gjithçka është një inxhinier DevOps në vetmi. Natyrisht, në disa kompani të veçanta ekzistojnë akoma këto vende, por ato bëhen gjithnjë e më pak. Shumë e quajnë këtë zhvillim, unë personalisht e shoh si degradim, është e pamundur të mbash një nivel të mirë njohurish në të gjitha drejtimet dhe në të njëjtën kohë të punosh jo më shumë se 8 orë. Sigurisht – kjo janë fantazi. Në realitet, shumë IT-ista janë të detyruar të punojnë 12 ose 14 orë, nga të cilat paguhen 8. Dhe shpesh edhe pa ditë pushimi, sepse "më është caktuar një detyrë, dokumentet mungojnë ose janë të pasakta, dhe shërbimi ka kosto", dhe për një gabim në re nuk mund të marrësh pagën për disa muaj, veçanërisht nëse punon me IP. Në fakt, ne po humbasim fjalën në biznes, së bashku me ndarjen e përgjegjësive, gjithnjë e më shumë përballem me menaxherë që ndërhyjnë në proceset e zhvillimit, duke mos kuptuar asgjë nga to, ata ngatërrojnë të dhënat e biznesit dhe punën e aplikacionit, si rezultat fillon haosi.

Kur fillon haosi, biznesi dëshiron të gjejë fajtorin, dhe këtu nevojitet një fajtor universale, të hedhësh fajin mbi më shumë se 10 njerëz është e vështirë, prandaj menaxherët bashkojnë pozitat, sepse sa më shumë detyra të ketë një specialist, aq më e lehtë është të dëshmohet neglizhenca e tij. Dhe në kushtet Agile, gjetja e "fajtorit" dhe ndëshkimi - është baza e metodologjisë së menaxhimit të biznesit. Agile ka dalë prej kohësh nga IT, dhe koncepti i tij kryesor është – kërkesa për rezultate të përditshme. Problemi është se një specialist i specializuar ngushtë nuk do të ketë gjithmonë rezultate të përditshme, që do të thotë se do të jetë më e vështirë për të raportuar, dhe kjo është një tjetër arsye pse biznesi dëshiron "specialistë për gjithçka". Por arsyeja kryesore natyrisht është FOT – ai është arsyeja kryesore e të gjitha ndryshimeve, për rikompensë njerëzit pranuan të punojnë për veten dhe atë djalin tjetër. Por në fund, ashtu si në fusha të tjera, kjo u bë thjesht një detyrë, për një pagë më të ulët për një numër më të madh shërbimesh të ofruara.

Sot tani, është e zakonshme të shihen artikuj që thonë se zhvilluesit duhet të dinë të bëjnë deployment dhe të merren me infrastrukturën përkrah inxhinierëve DevOps, por çfarë rezultati sjell kjo? Përgjigjja është - një rënie në cilësinë e shërbimeve dhe në cilësinë e zhvilluesve. Të dy ditë më parë, i shpjegoja një zhvilluesi se mund të shkruhet dhe lexohet nga hoste të ndryshëm, ndërsa ai insistonte që nuk e kishte parë kurrë një gjë të tillë, kishte vetëm në settings orm host, port, db, user, password dhe mjaft... Por zhvilluesi di të fillojë deployments, të shkruajë YAML... Ndërsa ka harruar për testet unitare dhe komentet në kod.

Si pasojë, shohim këtë – puna e vazhdueshme, kërkimi i zgjidhjeve për problemet jashtë orarit të punës, mësimi i vazhdueshëm gjatë fundjavave, nuk për rritjen e të ardhurave, por për mbajtjen e vetes në lëvizje. Zhvilluesit detyrohen të ndihmojnë inxhinierin DevOps me CI/CD, dhe nëse zhvilluesi nuk ka kohë, ai fillon të ndjehet i mbingarkuar, dhe menaxherët fillojnë të krijojnë presion, dhe nëse kjo nuk rrit dëshirën për të punuar jashtë orarit, atëherë fillojnë të aplikojnë sanksione dhe gjoba, duke e bërë personin të kërkojë një vend tjetër pune, duke lënë pas tij një borxh teknik sa Everest-i, si rezultat borxhi fillon të rritet edhe te zhvilluesit, sepse ata detyrohen të shkruajnë kod me më pak refaktoring, për t'u siguruar që ndihmojnë ose inxhinierin e vjetër ose të ri DevOps, ndërsa menaxherët janë gjithmonë të kënaqur, sepse fajtori është aty dhe duket menjëherë, që do të thotë se rregulli kryesor në Agile për menaxhimin është zbatuar, është identifikuar fajtori dhe rezultatet e ndëshkimit të tij janë të dukshme.

Njëherë kam mbajtur një prezantim në ITGM me titull "kur do të mësojmë të themi 'jo'" - rezultatet ishin shumë treguese. Një numër i madh njerëzish besojnë se ky fjalë është tabu, dhe derisa ne të ndalojmë së menduari kështu, problemet do të vazhdojnë të rriten.

Pjesërisht, ky artikull më frymëzoi ky artikull, por ndoshta më vonë do ta shkruaj atë më pak me një gjuhë të tillë rrethore.

Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. Hyni, ju lutem.