🥇DevOps eller hur vi förlorar vår lön och IT-sektorens framtid

Det mest sorgliga i dagens situation är att IT gradvis blir en bransch där det överhuvudtaget inte finns något ord som "stopp" när det kommer till antalet arbetsuppgifter för en person.

När man läser jobbbeskrivningar ser man ibland inte bara 2-3 personer utan en hel företag personifierat, alla har bråttom, den tekniska skulden växer, gammal legacy ser perfekt ut i jämförelse med nya produkter eftersom det åtminstone finns dokumentation och kommentarer i koden, nya produkter skrivs i ljusets hastighet men i slutändan kan de inte användas ännu ett år efter att de skrivits, och oftast ger det året inga intäkter, snarare att kostnaderna för "molnet" är högre än försäljningen av tjänsten. Investerarnas pengar går till att underhålla en tjänst som ännu inte fungerar men som redan har släppts online som en fungerande.
Ett exempel: ett välkänt företag vars remaster av en gammal spel fick de lägsta betygen i hela branschens historia. Jag var en av dem som köpte denna produkt, men även nu fungerar denna produkt förfärligt och borde egentligen inte ha släppts i detta skick. Återbetalningar, fallande betyg, ett stort antal användarbannlysningar på forum för klagomål på tjänsternas funktion. Antalet patchar imponerar inte, utan skrämmer, men ändå - produkten är inte användbar. Om denna metod leder till sådana resultat för ett företag som har utvecklat sedan 91, så är situationen ännu värre för företag som just har påbörjat sin verksamhet.

Men detta har vi sett ur användarens perspektiv, nu låt oss titta på de problem som har uppstått för de anställda.

Jag hör ofta påståendet att det inte borde finnas DevOps-team, att det är en metodologi osv., men här är problemet: företag har på något sätt slutat att söka efter nockar, DBA, infrastrukturtekniker och build-ingenjörer – nu är allt en DevOps-ingenjör i en och samma person. Självklart finns det fortfarande sådana tjänster i vissa företag, men antalet minskar. Många kallar detta en utveckling, jag ser personligen detta som en nedgradering, det är omöjligt att upprätthålla en hög kunskapsnivå inom alla områden och ändå kunna arbeta högst 8 timmar. Naturligtvis är det fantasier. I verkligheten tvingas många IT-anställda arbeta 12-14 timmar, varav 8 är betalda. Ofta även utan helger, eftersom "jag fick en uppgift, dokumentationen är bristfällig eller felaktig, och tjänsten kostar dessutom", och för ett enda misstag i molnet kan du i praktiken gå månader utan lön, särskilt om du arbetar som egenföretagare. Vi förlorar faktiskt röst i affärsverksamheten, tillsammans med arbetsfördelningen, jag stöter allt oftare på att chefer blandar sig i utvecklingsprocesser, utan att förstå något alls om dem, de förväxlar affärsdata med applikationsarbete, vilket leder till kaos.

När kaoset börjar vill företaget hitta den skyldige, och här behövs en universell skyldig, att lägga skulden på 10+ personer är svårt, därför slår chefer ihop positioner, ju fler ansvarsområden en specialist har, desto enklare är det att bevisa hans försummelse. Och under Agile-förhållanden är att hitta "den skyldige" och straffa honom – grunden för denna metodik och affärsledning. Agile har länge lämnat IT, och den grundläggande konceptet har blivit – krav på dagliga resultat. Problemet är att en smal expert inte alltid kommer att ha ett dagligt resultat, vilket gör det svårare att redovisa, och det är ytterligare en anledning till varför företaget vill ha "specialister på allt". Men den verkliga orsaken är förstås lönesumman – det är den huvudsakliga orsaken till alla förändringar, för att få bonusar gick folk med på att arbeta för sig själva och för den andra. Men i slutändan, precis som inom andra områden, har detta helt enkelt blivit en skyldighet för en lägre betalning för fler tjänster.

Numera kan man ofta se artiklar som säger att utvecklare också måste kunna deploya och arbeta med infrastrukturen tillsammans med DevOps-ingenjören, men vad leder det till? Rätt – en försämring av tjänsternas kvalitet och en minskning av utvecklarnas kompetens. För bara två dagar sedan förklarade jag för en utvecklare att man kan läsa och skriva från olika värdar, men jag fick höra, med stor övertygelse, att de aldrig har sett något sådant, att det bara finns i inställningarna: orm host, port, db, user, password och allt…. Men utvecklaren kan köra deployer, skriva YAML-filer…. Men de glömmer bort enhetstester och kommentarer i koden.

I slutändan ser vi följande – ständiga övertidsarbeten, sökande av lösningar på problem utanför arbetstid, konstant lärande på helger, och inte för att öka inkomsterna, utan för att hålla sig flytande. Utvecklare tvingas hjälpa DevOps-ingenjören med CI/CD, och om utvecklaren inte har tid börjar det bli för mycket att hantera, och cheferna börjar komplicera livet för dem, och om det inte hjälper att öka viljan att arbeta övertid, så tillämpas straff och böter, och personen söker sig till ett nytt arbete, vilket lämnar efter sig en teknisk skuld stor som Everest, som börjar växa även hos utvecklarna, eftersom de tvingas skriva kod med mindre refaktorering för att hinna hjälpa antingen den gamla eller den nya DevOps-ingenjören, och cheferna är nöjda, eftersom den skyldige finns och är synlig direkt, så det grundläggande regelverket i Agile-management är följt, den skyldige är funnen, och resultaten av deras bestraffning är tydliga.

En gång höll jag ett föredrag på ITGM med titeln "när lär vi oss att säga 'nej'" – dess resultat var väldigt tydliga. Ett stort antal människor anser att det ordet är tabu, och så länge vi fortsätter att tänka så kommer problemen bara att öka.

Delvis inspirerades jag till denna artikel av denna artikel, men senare kanske jag formulerar den med mindre omständliga termer.

Endast registrerade användare kan delta i omröstningen. Logga in, tack.