Vad krävs för att få en IT-företags framgång under 2019? Talare på konferenser och meetups pratar mycket om högljudda och inte alltid begripliga termer för vanliga människor. Kampen om deploymenttid, mikrotjänster, avsteg från monolit, DevOps-transformation och så mycket mer. Om vi bortser från den verbala skönheten och pratar rakt på sak, så handlar det om en enkel tes: skapa en kvalitetsprodukt och gör det på ett bekvämt sätt för teamet.
Detta har blivit kritiskt viktigt. Företagen har äntligen kommit till insikt om att en bekväm utvecklingsprocess ökar produktiviteten, och om allt är ordnat och fungerar som klockan, ger det dessutom viss handlingsfrihet i kritiska situationer. Nån klok person har en gång uppfunnit backup för detta manöverutrymme, men industrin utvecklas, och vi har kommit fram till DevOps-ingenjörer — personer som omvandlar samarbetet mellan utveckling och extern infrastruktur till något som är adekvat och inte kopplat till schamanism.
Denna historia om "modularitet" är vacker, men... Det har blivit så att en del administratörer hastigt har döpt om sig till DevOps, och från själva DevOps-ingenjörerna kräver man åtminstone telepatiska och clairvoyanta färdigheter.
Innan vi pratar om moderna problem inom infrastrukturförsörjning, låt oss först definiera vad vi menar med detta begrepp. I nuläget har situationen blivit sådan att vi har sett en dubbelhet i detta begrepp: infrastrukturen kan vara antingen extern eller intern.
Den externa infrastrukturen syftar på allt som säkerställer att tjänsten eller produkten fungerar, som utvecklingsteamet arbetar med. Det handlar om applikations- eller webbservrar, hosting och andra tjänster som säkerställer att produkten fungerar.
Den interna infrastrukturen inkluderar de tjänster och den utrustning som själva utvecklingsteamet och andra anställda använder, som oftast också är ganska många. Det handlar om interna servrar för kodlager, lokalt installerade uppgiftshanterare och allt, allt, allt som existerar inom ramen för företagsintranätet.
Vad gör egentligen en systemadministratör på företaget? Förutom att hantera administrationen av det interna intranätet ansvarar han ofta för att se till att kontorsutrustningen fungerar. Administratören är killen som snabbt kommer med en ny stationär dator eller en färdig laptop från lagret, delar ut ett nytt tangentbord och kryper runt i kontoren för att dra Ethernet-kablar. Administratören är den lokala chefen och härskaren över både interna och externa. servrar, men också en god förvaltare. Ja, vissa administratörer kan arbeta enbart på systemnivå, utan hårdvara. De ska särskiljas som en egen underklass av "infrastruktursystemadministratörer". Andra specialiserar sig på att endast underhålla kontorsutrustning, vilket är tur när företaget har fler än hundra anställda, eftersom arbetet aldrig tar slut. Men varken de eller andra är DevOps.
Men vem är DevOps? DevOps är killarna som jobbar med samverkan mellan programvaruutveckling och extern infrastruktur. Mer specifikt är moderna DevOps involverade i utvecklings- och distributionsprocesser mycket djupare än vad administratörer någonsin varit, de som bara laddade upp uppdateringar via ftp. En av DevOps-ingenjörens nyckeluppgifter idag är att säkerställa en bekväm och effektivt strukturerad process för samarbete mellan utvecklingsteam och produktinfrastruktur. Det är dessa personer som ansvarar för implementering av system för återställningar och distributioner, det är dessa som tar en del av bördan från utvecklarna och fokuserar maximalt på sin oerhört viktiga uppgift. Samtidigt kommer en DevOps aldrig att dra en ny kabel eller dela ut en ny laptop från lagret (c) KO.
Vad är hake?
När man ställer frågan "Vem är DevOps?" börjar hälften av arbetarna inom området svara något i stil med "Nåväl, det är typ en admin som..." och så vidare. Ja, för länge sedan, när yrket DevOps-ingenjör just hade börjat utvecklas från de mest begåvade servicerelaterade administratörerna, var skillnaderna mellan dem inte alltid uppenbara. Men nu, när DevOps- och admin-funktionerna inom teamet har blivit radikalt olika, är det oacceptabelt att blanda ihop dem eller till och med sätta likhetstecken mellan dem.
Men vad innebär det för företaget?
Det handlar om rekrytering.
Du publicerar en platsannons för "Systemadministratör", och där listas krav som "samarbete med utvecklare och kunder", "CI/CD-leveranssystem", "underhåll av företagets servrar och utrustning", "administration av interna system" och så vidare; du inser att arbetsgivaren pratar nonsens. Problemet är att istället för "Systemadministratör" borde rubriken för platsannonsen stå "DevOps-ingenjör", och om denna rubrik ändras, så faller allt på plats.
Men vilket intryck skapas när man läser en sådan platsannons? Att företaget letar efter en mångsysslare, som både kan sätta upp versionskontrollsystem och övervakning, samt klara av allt annat med tänderna…
För att inte höja trycket på den redan dysfunktionella arbetsmarknaden är det tillräckligt att kalla platserna med rätt namn och tydligt förstå att DevOps-ingenjör och systemadministratör är två olika entiteter. Det är just det, den ohejdade viljan hos vissa arbetsgivare att ställa så många krav som möjligt på kandidaterna leder till att de "klassiska" systemadministratörerna slutar förstå vad som händer runt omkring dem. Vad, yrket muterar och de har halkat efter?
Nej, nej och åter nej. Infrastrukturadministratörer, som kommer att styra företagets interna servrar, eller ta positioner som L2/L3-support och hjälpa andra anställda, har inte försvunnit och kommer definitivt inte att försvinna.
Kan dessa specialister bli DevOps-ingenjörer? Självklart kan de det. Faktum är att det är en släkting till deras miljö, som kräver systemadministrationsfärdigheter, men utöver detta, tillkommer arbete med övervakning, distributionssystem och generellt ett nära samarbete med utvecklings- och testteamet.
Ett annat problem med DevOps
I själva verket handlar det inte bara om rekrytering och den ständiga förvirringen mellan administratörer och DevOps:are. Vid något tillfälle stötte företaget på problemet med att leverera uppdateringar och samarbetet mellan utvecklingsteamet och den slutliga infrastrukturen.
Kanske var det då när en man med brinnande ögon klev upp på scenen på en konferens och sa: 'Vi gör så här och kallar det DevOps. Dessa killar kommer att lösa alla era problem' — och började berätta hur bra det är att arbeta på företaget efter att ha implementerat DevOps-praktiker.
Men det räcker inte med att anställa en DevOps-ingenjör för att allt ska fungera 'som det ska'. Företaget måste genomgå en fullständig DevOps-transformation, vilket betyder att rollen och möjligheterna för vår DevOps måste förstås tydligt även av utvecklings- och testteamet. Vi har en 'vacker' historia om detta, som fullt ut illustrerar hela det som ibland är kaos.
Situation. The devops team is asked to set up a version rollback system without really understanding how it will work. Let's assume that within the Users system, there are separate fields for first name, last name, and password. A new version of the product is released, but for the developers, "rollback" is just a magic wand that fixes everything, and they have no idea how it works. For instance, let's say the developers in the latest patch merged the first name and last name fields, pushed it to production, and for some reason, the version is lagging. What happens? The management approaches 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 bother to understand how this rollback works, no one told the devops that the database also needs to be rolled back. As a result, everything crashes, and users see the error "500" instead of a slowing website because the old version is incompatible with the fields of the new database. The devops is unaware of this. The developers are silent. The management starts losing nerves and money and remembers about backups, suggesting to roll back from them so that "at least something works." As a result, users lose all their data for some time.
Of course, the devops gets blamed for not creating the proper rollback system, while the fact that the developers are the real culprits in this story is of no concern to anyone.
The conclusion is simple: without a proper approach to DevOps as such, there's not much benefit from it.
The main thing to remember is that a DevOps engineer is not a magician, and without quality communication and two-way interaction with development, he will struggle with his tasks. DevOps cannot be left alone with their "problems" or be told, "Don’t bother the developers, that’s their job to code," and then hope that everything works as it should in a critical moment. That's not how it works.
I grund och botten är DevOps kompetenser som ligger i gränslandet mellan ledarskap och teknik. Dessutom är det långt ifrån uppenbart att det i denna mix av teknologier bör finnas mer än ledarskap. Om du verkligen vill bygga snabbare och mer effektiva utvecklingsprocesser måste du lita på din DevOps. Han vet vilka verktyg som behövs, har genomfört liknande projekt och vet hur man gör. Hjälp honom, lyssna på hans råd, försök inte isolera honom i en autonom enhet. Om administratörer kan arbeta på egen hand, då är DevOps i sådana fall värdelösa; de kan inte hjälpa er att bli bättre om ni inte själva vill ta emot hjälpen.
Det sista: sluta att nedvärdera infrastrukturadministratörer. De har sitt eget, extremt viktiga arbetsområde. Ja, en administratör kan bli DevOps-ingenjör, men detta måste ske av den personens eget val och inte under tvång. Det är inget fel med att en systemadministratör vill förbli systemadministratör — det är ett eget yrke och hans rätt. Om det finns ett önske om att genomgå en professionell transformation, måste man i ingen fall glömma att man också måste bygga upp ledarskapsförmågor förutom tekniska färdigheter. Det är troligt att det är du som ledare som måste få ihop alla dessa människor och lära dem att kommunicera på samma språk.
Källa: habr.com
