For nylig har sådanne reklamer oversvømmet internettet. Trods den behagelige løn kan man ikke undgå at være flov over, at der står vildt kætteri indeni. Først antages det, at "DevOps" og "engineer" på en eller anden måde kan limes sammen til ét ord, og så er der en tilfældig liste over krav, hvoraf nogle tydeligt er kopieret fra sysadmin-stillingen.
I dette indlæg vil jeg gerne fortælle lidt om, hvordan vi nåede til dette punkt i livet, hvad DevOps egentlig er, og hvad man skal gøre med det nu.
Sådanne ledige stillinger kan fordømmes på alle mulige måder, men faktum består: Der er mange af dem, og det er sådan markedet fungerer i øjeblikket. Vi holdt en devops-konference og erklærer åbent: " - ikke for DevOps-ingeniører." Dette vil virke mærkeligt og vildt for mange: hvorfor folk, der laver et helt kommercielt arrangement, går imod markedet. Nu vil vi forklare alt.
Om kultur og processer
Lad os starte med, at DevOps ikke er en ingeniørdisciplin. Det hele startede med, at den historisk etablerede rollefordeling ikke virker for produkternes kvalitet. Når programmører kun programmerer, men ikke ønsker at høre noget om test, er softwaren fyldt med fejl. Når administratorer er ligeglade med, hvordan eller hvorfor softwaren er skrevet, bliver support til et helvede.
For eksempel at beskrive forskellen mellem en systemadministrator og en SRE-tilgang til servicestyring . Interessante undersøgelser er blevet udført indenfor - det er klart, at de bedste udviklere på en eller anden måde formår at implementere nye ændringer til produktionen hurtigere end én gang i timen. De tester med deres hænder ikke mere end 10% (dette kan ses af ). Hvordan gør de dette? "Excel or die" siger en af rapportoverskrifterne. For en detaljeret diskussion af disse statistikker i forbindelse med test, kan du henvise til keynote af Baruch Sadogursky på vores anden konference, Heisenbug.
"Når der ikke er enighed blandt kammerater,
Det går ikke godt for dem,
Og der vil ikke komme noget ud af det, kun pine.
Der var engang en svane, en krebs og en gedde..."
Hvilken del af webprogrammører tror du virkelig forstår de forhold, hvorunder deres applikationer bruges i produktionen? Hvor mange af dem vil gå til administratorerne og forsøge at finde ud af, hvad der vil ske, hvis databasen går ned? Og hvem af dem vil gå til testerne og bede dem om at lære dem, hvordan man skriver prøver korrekt? Og der er også sikkerhedsvagter, produktchefer og en masse andre mennesker.
Den overordnede idé med DevOps er at skabe samarbejde mellem roller og afdelinger. Først og fremmest opnås dette ikke ved hjælp af smart konfigureret software, men ved kommunikationspraksis. DevOps handler om kultur, praksis, metodik og processer. Der er ingen ingeniørspeciale, der kan besvare disse spørgsmål.
Ond cirkel
Hvor kom disciplinen "devops engineering" fra dengang? Vi har en version! DevOps-ideer var gode – så gode, at de blev ofre for deres egen succes. Nogle lyssky rekrutterere og menneskesmuglere, som har deres egen atmosfære, begyndte at hvirvle rundt om hele dette emne.
Forestil dig: i går lavede du shawarma i Khimki, og i dag er du allerede en stor mand, en senior rekrutterer. Der er en hel proces med at søge og udvælge kandidater, alt er ikke nemt, du skal forstå. Lad os sige, at lederen af en afdeling siger: find en specialist i X. Vi tildeler ordet "ingeniør" til X, og vi er færdige. Har du brug for Linux? Nå, dette er bestemt en Linux-ingeniør, hvis du vil have DevOps, så en DevOps-ingeniør. Stillingen består ikke kun af en titel, men der skal også indtastes noget tekst indeni. Den nemmeste måde er at indtaste et sæt søgeord fra Google, afhængigt af din fantasi. DevOps består af to ord - "Dev" og "Ops", hvilket betyder, at vi skal lime nøgleord, der er relateret til udviklere og administratorer, sammen i én bunke. Sådan vises ledige stillinger om færdigheder i 42 programmeringssprog og 20 års brug af Kubernetes og Swarm samtidigt. Arbejdsdiagram.
Dette er, hvordan det meningsløse og nådesløse billede af en bestemt "devops"-superhelt har slået rod i folks sind, som vil konfigurere alle til at deployere til Jenkins, og lykken vil komme. Åh, hvis bare alt var så enkelt. "Og det er også sådan, du kan jage systemadministratorer," mener HR, "det er et modeord, nøgleordene er de samme, de burde tage lokket."
Efterspørgslen skaber udbud, og alle disse ledige stillinger i skraldespanden er blevet fyldt med et sindssygt antal systemadministratorer, der indså: du kan gøre alting på samme måde som før, men få flere gange mere ved at kalde dig selv "devops". Ligesom du konfigurerede servere via SSH manuelt én ad gangen, vil du fortsætte med at konfigurere dem, men nu er dette angiveligt en devops-praksis. Dette er en form for komplekst fænomen, delvist relateret til undervurderingen af klassiske administratorer og hypen omkring DevOps, men generelt skete det, der skete.
Så vi har udbud og efterspørgsel. En ond cirkel, der nærer sig selv. Det er det, vi kæmper imod (bl.a. ved at oprette DevOops-konferencen).
Udover de systemadministratorer, der har omdøbt sig selv til "devops", er der naturligvis andre deltagere - for eksempel professionelle SRE'er eller Infrastructure-as-Code-udviklere.
Hvad folk gør i DevOps (virkelig)
Så du ønsker at komme videre med at lære og anvende DevOps-praksis. Men hvordan gør man dette, i hvilken retning skal man kigge? Du skal naturligvis ikke stole blindt på populære søgeord.
Hvis der er et arbejde, bør nogen gøre det. Vi har allerede fundet ud af, at det ikke er "devops-ingeniører", hvem er det så? Det virker mere korrekt at formulere dette ikke ud fra stillinger, men ud fra specifikke arbejdsområder.
For det første kan du adressere hjertet af DevOps – processer og kultur. Kultur er en langsom og vanskelig forretning, og selvom det traditionelt er ledernes ansvar, er alle involveret på den ene eller anden måde, lige fra programmører til administratorer. For et par måneder siden Tim Lister :
"Kultur er bestemt af organisationens kerneværdier. Det lægger folk normalt ikke mærke til, men efter at have arbejdet med rådgivning i mange år, er vi vant til at lægge mærke til det. Du kommer ind i en virksomhed og bogstaveligt talt inden for et par minutter begynder du at mærke, hvad der sker. Vi kalder dette "smag". Nogle gange er denne duft rigtig god. Nogle gange giver det kvalme. (...) Du kan ikke ændre en kultur, før værdierne og overbevisningerne bag specifikke handlinger er forstået. Adfærd er let at observere, men det er svært at søge efter overbevisninger. DevOps er bare et godt eksempel på, hvordan tingene bliver mere og mere komplekse.”
Der er selvfølgelig også en teknisk del af problemet. Hvis din nye kode bliver testet om en måned, men kun udgives et år senere, og det er fysisk umuligt at fremskynde det hele, lever du muligvis ikke op til god praksis. God praksis understøttes af gode værktøjer. For eksempel, med ideen om Infrastructure-as-Code i tankerne, kan du bruge alt fra AWS CloudFormation og Terraform til Chef-Ansible-Puppet. Du skal vide og kunne alt dette, og det er allerede noget af en ingeniørdisciplin. Det er vigtigt ikke at forveksle årsag med virkning: først arbejder du efter principperne i SRE og først derefter implementerer du disse principper i form af nogle specifikke tekniske løsninger. Samtidig er SRE en meget omfattende metode, der ikke fortæller dig, hvordan du opsætter Jenkins, men om fem grundlæggende principper:
- Forbedret kommunikation mellem roller og afdelinger
- At acceptere fejl som en integreret del af jobbet
- At lave ændringer gradvist
- Brug af værktøj og anden automatisering
- Måler alt, hvad der kan måles
Dette er ikke bare et sæt udsagn, men et specifikt . For eksempel, på vejen til at acceptere fejl, bliver du nødt til at forstå risiciene, måle tilgængeligheden og utilgængeligheden af tjenester ved hjælp af noget som SLI () og SLO (), lær at skrive postmortems og gør det ikke skræmmende at skrive dem.
I SRE-disciplinen er brugen af værktøjer kun en del af succes, selvom en vigtig sådan. Vi skal hele tiden udvikle os teknisk, se på, hvad der sker i verden, og hvordan det kan anvendes i vores arbejde.
Til gengæld er Cloud Native-løsninger nu blevet meget populære. Som defineret af Cloud Native Computing Foundation i dag, gør Cloud Native-teknologier det muligt for organisationer at udvikle og køre skalerbare applikationer i nutidens dynamiske miljøer, såsom offentlige, private og hybride skyer. Eksempler omfatter containere, servicemasker, mikrotjenester, uforanderlig infrastruktur og deklarative API'er. Alle disse teknikker gør det muligt for løst koblede systemer at forblive elastiske, håndterbare og meget observerbare. God automatisering giver ingeniører mulighed for at foretage store ændringer ofte og med forudsigelige resultater uden at gøre det til en opgave. Alt dette understøttes af en stak velkendte værktøjer som Docker og Kubernetes.
Denne ret komplicerede og brede definition skyldes, at området også er ret komplekst. På den ene side argumenteres det for, at nye ændringer i dette system ganske enkelt bør tilføjes. På den anden side, for at finde ud af, hvordan man skaber en slags containeriseret miljø, hvor løst koblede tjenester lever på en softwaredefineret infrastruktur og leveres der ved hjælp af kontinuerlig CI/CD, og bygger DevOps-praksis omkring alt dette - alt dette kræver mere end man spiser hunden.
Hvad skal man gøre med alt dette
Alle løser disse problemer på deres egen måde: For eksempel kan du offentliggøre normale ledige stillinger for at bryde den onde cirkel. Du kan finde ud af, hvad ord som DevOps og Cloud Native betyder, og bruge dem korrekt og til sagen. Du kan udvikle dig i DevOps og demonstrere de rigtige tilgange ved dit eksempel.
Vi holder en konference , som giver mulighed for at dykke dybere ned i de ting, vi lige har talt om. Der er flere grupper af rapporter til dette:
- Processer og kultur;
- Site Reliability Engineering;
- Cloud Native;
Hvordan vælger man, hvor man skal hen? Der er en subtil pointe her. På den ene side handler DevOps om interaktion, og vi vil virkelig gerne have, at du deltager i præsentationer fra forskellige blokke. På den anden side, hvis du er en udviklingsleder, der kom til konferencen for at koncentrere dig om én bestemt opgave, så er der ingen, der begrænser dig – naturligvis vil dette være en blokering om processer og kultur. Glem ikke, at du vil have optagelser efter konferencen (efter at du har udfyldt feedbackformularen), så du altid kan se mindre vigtige oplæg senere.
På selve konferencen kan du naturligvis ikke gå på tre spor på én gang, så vi tilrettelægger programmet på en sådan måde, at hvert tidsrum har emner for enhver smag.
Det eneste, der er tilbage, er at forstå, hvad du skal gøre, hvis du er DevOps-ingeniør! Prøv først at finde ud af, hvad du rent faktisk gør. Normalt kan de lide at kalde dette ord:
- Udviklere, der arbejder med infrastruktur. Grupperne af rapporter om SRE og Cloud Native er bedst egnede til dig.
- Systemadministratorer. Det er mere kompliceret her. DevOops handler ikke om systemadministration. Heldigvis er der en masse fremragende konferencer, bøger, artikler, videoer på internettet osv. om emnet systemadministration. På den anden side, hvis du er interesseret i at udvikle dig selv i forhold til at forstå kultur og processer, lære om cloud-teknologier og detaljerne i livet med Cloud Native, så vil vi elske at se dig! Tænk over dette: du laver administration, og hvad vil du så gøre? For at undgå pludselig at stå i en ubehagelig situation, bør du lære det nu.
Der er en anden mulighed: du bliver ved og fortsætter med at hævde, at du er det specifikt en DevOps-ingeniør og intet andet, hvad det så end betyder. Så må vi skuffe dig, DevOops er ikke en konference for DevOps-ingeniører!
Slid fra i München
DevOops 2020 Moskva afholdes den 29.-30. april i Moskva, billetter er allerede tilgængelige .
Alternativt kan du indtil 8. februar. Bemærk venligst, at når du udfylder formularen, skal du vælge den målgruppe, der vil få mest gavn af din rapport (der er en overraskelse begravet inde på listen).
Kilde: www.habr.com