Hvad er nødvendigt for en IT-virksomheds succes i 2019? Talere på konferencer og meetups bruger mange højtstående og ikke altid forståelige ord for almindelige mennesker. Kampen om deploy-tid, mikrotjenester, afvisning af monolitter, DevOps-transformation og meget, meget mere. Hvis vi fjerner den verbale skønhed og taler direkte og klart, så handler det det hele om en simpel tese: Lav et kvalitetsprodukt, og gør det samtidig behageligt for teamet.
Det sidste er blevet kritisk vigtigt. Virksomheden er endelig kommet til den erkendelse, at en behagelig udviklingsproces øger produktiviteten, og hvis alt er justeret og fungerer som en klokke, giver det også noget plads til manøvrering i kritiske situationer. Engang blev back-ups opfundet af en klog person for at give denne manøvrerum, men industrien udvikler sig, og vi er nået til DevOps-ingeniører – mennesker, der omdanner udviklingens interaktion med den eksterne infrastruktur til noget der er rimeligt og ikke forbundet med shamanisme.
Hele denne historie om 'moduler' er fantastisk, men… Sådan er det, at nogle administratorer pludselig blev kaldt DevOps, og fra selve DevOps-ingeniørerne kræves der som minimum færdigheder i telepati og klarsyn.
Før vi taler om nutidens problemer med at sikre infrastrukturen, lad os definere, hvad vi mener med dette begreb. På nuværende tidspunkt har situationen fået en dualitet: infrastrukturen kan være betinget ekstern og betinget intern.
Med ekstern infrastruktur menes alt, hvad der sikrer funktionaliteten af den service eller det produkt, som teamet arbejder på. Dette inkluderer applikationsservere eller webservere, hosting og andre tjenester, der sikrer produktets funktionalitet.
Intern infrastruktur omfatter de tjenester og udstyr, som udviklingsteamet og øvrige medarbejdere, som der normalt også er ret mange af, bruger. Det inkluderer interne servere til kodeopbevaringssystemer, lokalt deployerede task-managers og alt andet, der eksisterer inden for det virksomhedsinternettet.
Hvad laver en systemadministrator i virksomheden? Udover at administrere intranet systemet, har han ofte ansvaret for at sikre, at kontorudstyret fungerer. Admin er den fyr, der hurtigt henter en ny computer eller en klar til brug backup bærbar fra lageret, giver en ny tastatur og kravler rundt i kontorerne for at trække Ethernet-kabler. Admin er den lokale herre og hersker over ikke kun de interne og eksterne servere, men også over det praktiske arbejde. Ja, nogle administratorer arbejder kun med systemer uden hardware. De bør skelnes ud som en særskilt underklasse af "infrastrukturelle systemadministratorer". Og nogle specialiserer sig i udelukkende at servicere kontorudstyr; heldigvis, hvis firmaet har mere end hundrede ansatte, slutter arbejdet aldrig. Men hverken degenen eller de andre er devops.
Hvem er DevOps? DevOps er dem, der arbejder med interaktionen mellem softwareudvikling og den eksterne infrastruktur. Mere præcist er moderne devops dybere involveret i udviklings- og deployeringsprocesserne end administratorer nogensinde har været, som simpelthen uploadede opdateringer til FTP. En af de centrale opgaver for en DevOps-ingeniør nu om dage er at sikre en komfortabel og effektivt struktureret proces for samarbejdet mellem udviklingsteamene og produktinfrastrukturen. Det er netop disse mennesker, der er ansvarlige for implementeringen af systemer til tilbageførsler og deployment; det er disse mennesker, der fjerner en del af belastningen fra udviklerne og fokuserer maksimalt på deres yderst vigtige opgave. Samtidig vil devops aldrig trække et nyt kabel eller udlevere en ny bærbar fra lageret.
Hvad er fælden?
Når man stiller spørgsmålet "Hvem er DevOps?", begynder halvdelen af medarbejderne i branchen at svare noget i retning af "Nå, det er i bund og grund en administrator, der..." og så videre. Ja, engang, da professionen som DevOps-engineer lige var ved at tage form fra de mest talentfulde administratorer, der servicerede systemer, var forskellene mellem dem ikke klart definerede. Men nu, hvor DevOps-funktionerne og administratorens roller i teamet er blevet radikalt forskellige, er det uacceptabelt at forvirre dem med hinanden, eller værre, sætte lighedstegn imellem dem.
Men hvad betyder det for virksomheden?
Anslaget, det er det, det hele handler om.
Du opslår en stilling som "Systemadministrator", og i kravene står der "interaktion med udvikling og kunder", "CI/CD leveringssystem", "vedligeholdelse af servere og virksomhedens udstyr", "administration af interne systemer" og så videre; du forstår, at arbejdsgiveren taler om noget helt andet. Fallacy er, at i jobtitlen skal der stå "DevOps-ingeniør"; hvis den titel ændres, så falder alting på plads.
Men hvilket indtryk får man ved at læse sådan en jobannonce? At virksomheden leder efter en multitasking medarbejder, der både kan opsætte versionskontrol og overvågningssystemer, samt håndtere opgaver på en tandpasta-agtig måde...
Og for at undgå at hæve graden af forvirring på arbejdsmarkedet er det nok bare at kalde stillingerne deres rette navn og tydeligt forstå, at DevOps-ingeniør og systemadministrator er to forskellige enheder. Dog fører nogle arbejdsgiveres urolige ønske om at stille så brede krav som muligt til kandidaten til, at de "klassiske" systemadministratorer ikke længere forstår, hvad der sker omkring dem. Er professionen ved at mutere, og de er blevet forældede?
Nej, nej og atter nej. Infrastrukturadministratorer, der styrer virksomhedens interne servere eller besætter L2/L3-supportroller og hjælper andre medarbejdere, er ikke forsvundet og har ikke tænkt sig at gøre det.
Kan disse specialister blive DevOps-ingeniører? Selvfølgelig kan de det. Faktisk er det et beslægtet miljø, der kræver systemadministratorfærdigheder, men udover dette tilføjes arbejde med overvågning, distributionssystemer og generelt tæt samarbejde med udviklings- og testteamet.
Endnu et problem med DevOps
I virkeligheden begrænser problemerne sig ikke kun til ansættelse og konstant forvirring mellem administratorer og DevOps-specialister. På et tidspunkt stod virksomheden overfor problemet med levering af opdateringer og samarbejde mellem udviklingsteamet og den endelige infrastruktur.
Måske var det dengang, en onkel med brændende øjne trådte op på scenen på en konference og sagde: "Vi gør det på denne måde og kalder det DevOps. Disse fyrer løser alle dine problemer" — og begyndte at fortælle, hvor godt det er at arbejde i virksomheden efter implementering af DevOps-praksis.
Men det er ikke nok at ansætte en DevOps-ingeniør for at få alting til at fungere "som det skal". Virksomheden skal gennemgå en fuld DevOps-transformation, det vil sige, at vores DevOps's rolle og muligheder også skal være klart forstået af udviklings- og testteamet. Vi har en "fantastisk" historie om dette, som fuldt ud illustrerer alt det, der til tider sker.
Situation. The devops team is required to deploy a version rollback system without fully understanding how it will work. Let's assume, within the system, Users consist of separate fields for first name, last name, and password. A new version of the product is released, but for the developers, a 'rollback' is just a magic wand that will fix everything, and they have no idea how it functions. For example, developers in a recent patch combined the first name and last name fields, deployed this to production, and the version starts lagging for some reason. What happens next? Management comes to the devops and says, 'Pull the lever!', meaning they ask him to roll back to the previous version. What does the devops do? He rolls back to the previous version, but since the developers didn’t want to figure out how this rollback is done, no one told the devops that he should also roll back the database. As a result, everything crashes, and users see a '500' error instead of a lagging website because the old version doesn't work with the fields of the new database. The devops is unaware of this. The developers remain silent. Management starts losing their nerves and money and remembers the backups, suggesting rolling back from them so that 'at least something works.' Consequently, users lose all their data over a certain period.
Of course, it's the devops who gets blamed for 'not setting up the proper rollback system', while the developers, who are the culprits in this story, are not held accountable.
The conclusion is simple: without a proper approach to DevOps, it doesn’t yield much benefit.
The main thing to remember is that a DevOps engineer is not a wizard, and without quality communication and two-way interaction with development, he won’t manage his tasks. Devops cannot be left alone with their 'problems' or be given the order 'don’t interfere with the developers, their job is to code', and then expect that at a critical moment everything will work as it should. That’s not how it works.
I bund og grund er DevOps kompetencer på grænsen mellem ledelse og teknologi. Det er langt fra indlysende, at der i denne cocktail af teknologier bør være mere end ledelse. Hvis du virkelig ønsker at opbygge hurtigere og mere effektive udviklingsprocesser, skal du stole på din DevOps. Han kender de rette værktøjer, han har udført lignende projekter, han ved, hvordan man gør. Hjælp ham, lyt til hans råd, undgå at isolere ham i en autonom afdeling. Hvis administratorer kan arbejde for sig selv, er DevOps i så fald ubrugelige; de kan ikke hjælpe dig med at blive bedre, hvis du ikke selv ønsker at modtage denne hjælp.
Og til sidst: stop med at nedgøre infrastrukturadministratorer. De har deres egen, yderst vigtige arbejdsfront. Ja, en administrator kan blive DevOps-ingeniør, men det skal ske af egen vilje, ikke under pres. Og der er intet galt i, at en systemadministrator ønsker at forblive systemadministrator - det er hans separate erhverv og hans ret. Hvis der derimod er ønsket om en professionel transformation, skal man under ingen omstændigheder glemme, at man skal opbygge både teknologiske færdigheder og ledelseskompetencer. Det vil oftest være dig som leder, der skal samle disse mennesker og lære dem at kommunikere på et fælles sprog.
Kilde: habr.com
