På det seneste har sådanne annoncer oversvømmet internettet. På trods af en attraktiv løn kan man ikke undgå at blive foruroliget over, at der ligger vildt vrøvl bag. I starten antages det, at 'DevOps' og 'ingeniør' på en eller anden måde kan sættes sammen til ét ord, hvorefter der følger en tilfældig liste af krav, hvoraf en del åbenlyst er kopieret fra en sysadmin-jobbeskrivelse.
I dette indlæg vil jeg gerne tale lidt om, hvordan vi er nået dertil, hvor vi er nu, hvad DevOps faktisk er, og hvad vi nu skal gøre ved det.
Disse jobopslag kan kritiseres på mange måder, men faktum er, at der er mange af dem, og det er sådan, markedet er i øjeblikket. Vi har lavet en DevOps-konference og erklærer åbent: ' — ikke for DevOps-ingeniører'. Dette vil virke underligt og bizart for mange: hvorfor går folk, der laver et helt kommercielt arrangement, imod markedet. Vi vil nu forklare alt.
Om kultur og processer
Lad os starte med at sige, at DevOps ikke er en ingeniørdisciplin. Det hele startede med, at det historisk etablerede rolleopdelinger ikke fungerer for produktkvaliteten. Når programmører kun programmerer, men ikke vil høre noget om testning - fyldes softwaren med fejl. Når administratorer ikke bryder sig om, hvordan og hvorfor softwaren er skrevet - bliver supporten til et helvede.
For eksempel begyndelsen på beskrivelsen af forskellen mellem sysadmin- og SRE-tilgangen til service management Interessante undersøgelser er blevet udført inden for — det ses, at de bedste udviklere somehow lykkes med at implementere nye ændringer i produktion hurtigere end én gang i timen. De tester heller ikke manuelt mere end 10% (det ses i ). Hvordan kan de gøre det? 'Excel or die' – siger en af overskrifterne i rapporten. For en dybere diskussion af disse statistikker med fokus på testning kan man henvise til keynoten af Baruch Sadogursky. på vores anden konference, Heisenbug.
'Når der ikke er enighed blandt kammerater,
gør deres arbejde ikke fremskridt,
og vil det ikke føre til noget, kun elendighed.
Engang var der en svane, en krabbe og en gedde…'
Hvad mener du, hvor mange webudviklere forstår virkelig de forhold, deres applikationer kører under i produktion? Hvor mange af dem vil gå til administratorerne og forsøge at finde ud af, hvad der sker ved databasefejl? Og hvem vil ind til testeren og bede om at lære, hvordan man korrekt skriver tests? Og der er også sikkerhedseksperter, produktmanagere og en masse andre folk.
Den overordnede idé med DevOps er at forbedre samarbejdet mellem roller og afdelinger. Dette opnås primært ikke med en smart konfigureret software, men gennem kommunikation. DevOps handler om kultur, praksis, metodologi og processer. Der findes ikke nogen ingeniørspeciale, der kan besvare disse spørgsmål.
Den rådne cirkel
Hvor stammer så disciplinen 'devops-ingeniør' fra? Vi har en teori! Idéerne bag DevOps var så gode, at de blev ofre for deres egen succes. Omkring dette emne begyndte nogle tvivlsomme rekrutteringsfolk og menneskehandlere at samle sig, med en helt særlig atmosfære.
Forestil dig: i går lavede du shawarma i Khimki, og i dag er du allerede en vigtig person, seniorrekrutterer. Her er der en hel proces til at finde og udvælge kandidater, det er ikke enkelt, man skal forstå det. Antag, at afdelingslederen siger: find en specialist i X. Så tilsætter vi 'ingeniør' til X, så er det klaret. Er det Linux? Så er det helt sikkert en Linux-ingeniør, vil du have DevOps – så er det en DevOps-ingeniør. Jobopslaget består ikke kun af en overskrift, men der er også brug for noget tekst. Det nemmeste er at skrive et sæt keywords fra Google, alt efter hvad man kan finde på. DevOps består af to ord – 'Dev' og 'Ops', så man skal samle keywords relateret til udviklere og administratorer, alt sammen i en bunke. Så opstår der jobopslag om at have kendskab til 42 programmeringssprog og 20 års erfaring med Kubernetes og Swarm samtidigt. Det er arbejdsmodellen.
Dermed har folk fået en meningsløs og ubarmhjertig opfattelse af en slags superhelt 'DevOps', der vil sætte alles deployment op på Jenkins, og så vil lykken være gjort. Åh, hvis bare det var så enkelt. 'Og man kan også jage systemadministratorer med det,' tænker HR, 'det er et moderne ord, de samme keywords, de må bidrage.'
Efterspørgsel skaber udbud, og et vanvittigt antal systemadministratorer har kastet sig over disse nonsensjob, da de indså: man kan gøre det samme som før, men få mange gange mere, ved at kalde sig selv "devopsere". Som du tidligere har konfigureret servere via SSH én ad gangen, vil du fortsætte med at konfigurere, men nu er det angiveligt en devops-praksis. Det er et komplekst fænomen, delvist knyttet til undervurdering af de klassiske administratorer og hypen omkring DevOps, men generelt — hvad der er, det er.
Så vi har efterspørgsel og udbud. En lukket cirkel, der nærer sig selv. Det er dette, vi kæmper imod (herunder ved at skabe konferencen DevOops).
Uden tvivl er der, udover systemadministratorer, der har omdøbt sig til "devopsere", også andre deltagere — for eksempel professionelle SRE'er eller Infrastructure-as-Code-udviklere.
Hvad laver folk i DevOps (i virkeligheden)
Så du ønsker at fremme din forståelse og anvendelse af DevOps-praksisser. Men hvordan gør man det, hvilken retning skal man kigge? Det er åbenlyst, at man ikke bør blindt følge populære nøgleord.
Hvis der er arbejde, er der nogen, der skal tage sig af det. Vi har allerede afklaret, at det ikke er "devopsingeniører", så hvem er det? Det virker mere korrekt at formulere det ikke i termer af stillinger, men i termer af specifikke arbejdsretninger.
For det første kan man arbejde med selve hjertet af DevOps — processer og kultur. Kultur er en langsommelig og vanskelig opgave, og selvom det traditionelt er ledernes ansvar, deltager alle, fra programmører til administratorer, på en eller anden måde. For et par måneder siden sagde Tim Lister :
"Kultur defineres af de grundlæggende værdier i organisationen. Folk lægger som regel ikke mærke til det, men vi, der har arbejdet i konsulentbranchen i mange år, er vant til at aflæse det. Du træder ind i en virksomhed, og bogstaveligt talt efter få minutter begynder du at føle, hvad der sker. Vi kalder det "duften". Nogle gange er denne duft virkelig behagelig. Nogle gange fremkalder den kvalme. (...) Du kan ikke ændre kulturen, før værdierne og overbevisningerne, der ligger bag de konkrete handlinger, er blevet bevidste. Adfærd er let at observere, men at finde overbevisninger er svært. DevOps er netop et glimrende eksempel på, hvordan alt bliver mere og mere kompliceret."
Der er selvfølgelig også en teknisk del af spørgsmålet. Hvis du får ny kode til testning om en måned, men den først bliver udgivet om et år, og det ikke er fysisk muligt at fremskynde det - så vil du ikke nå de gode praksisser. Gode praksisser støttes af gode værktøjer. For eksempel, ved at have idéen om Infrastructure-as-Code i tankerne, kan man bruge hvad som helst fra AWS CloudFormation og Terraform til Chef-Ansible-Puppet. Alt dette skal man kende til og kunne, og det er allerede en ingeniørdisciplin. Det er vigtigt ikke at forveksle årsag med virkning: Først arbejder du efter SRE-principperne, og derefter omsætter du disse principper i form af konkrete tekniske løsninger. SRE er en meget kompleks metode, der ikke handler om, hvordan man konfigurerer Jenkins, men om fem grundlæggende principper:
- Forbedring af samarbejdet mellem roller og afdelinger
- At acceptere fejl som en uundgåelig del af arbejdet
- Gradvis gennemførelse af ændringer
- Brug af værktøjer og anden automatisering
- At måle alt, hvad der kan måles
Dette er ikke bare et sæt udsagn, men en konkret . For eksempel, på vejen til at acceptere fejl, skal man forstå risici, måle tilgængelighed og utilgængelighed af tjenester med noget som SLI () og SLO (), lære at skrive postmortems og gøre det lettere at skrive dem.
I SRE-disciplinen er brugen af værktøjer kun én del af succesen, men dog en vigtig del. Vi skal konstant udvikle os teknisk, se hvad der sker i verden, og hvordan vi kan anvende det i vores arbejde.
På sin side er Cloud Native-løsninger nu blevet meget populære. Ifølge den moderne forståelse fra Cloud Native Computing Foundation gør Cloud Native-teknologier det muligt for organisationer at udvikle og implementere skalerbare applikationer i nutidens dynamiske miljøer, såsom offentlige, private og hybrid-clouds. Eksempler inkluderer containere, service meshes, mikroservices, uforanderlig infrastruktur og deklarative API'er. Alle disse teknikker gør det muligt for løst koblede systemer at forblive elastiske, administrerbare og velovervågede. God automatisering giver ingeniører mulighed for at lave store ændringer ofte med forudsigelige resultater uden at det bliver et mareridt. Alt dette understøttes af et stack af velkendte værktøjer som Docker og Kubernetes.
Denne ret omfattende og komplekse definition kommer fra, at området i sig selv også er komplekst. På den ene side hævdes det, at nye ændringer i dette system skal tilføjes relativt simpelt. På den anden side er det nødvendigt at forstå, hvordan man opretter et containeriseret miljø, hvor løst koblede services lever på software-defineret infrastruktur og distribueres derigennem ved hjælp af kontinuerlig CI/CD, samt at udvikle DevOps-praksis omkring det hele — der er mange nuancer at beherske.
Hvad skal man gøre med alt dette
Hver enkelt løser disse problemer på sin egen måde: for eksempel kan man annoncere normale stillinger for at bryde den onde cirkel. Man kan forstå, hvad ordene som DevOps og Cloud Native virkelig betyder, og bruge dem korrekt og relevant. Man kan udvikle sig inden for DevOps og gennem sit eget eksempel vise de rigtige tilgange.
Vi afholder en konference , som giver mulighed for at dykke dybere ned i emnerne, vi lige har talt om. Der er flere grupper af præsentationer til dette formål:
- Processer og kultur;
- Site Reliability Engineering;
- Cloud Native;
Hvordan vælger man, hvor man skal gå hen? Der er en fin nuance her. På den ene side handler DevOps om samarbejde, og vi ønsker virkelig, at du deltager i præsentationer fra forskellige spor. På den anden side, hvis du er en udviklingsleder, der er kommet til konferencen for at fokusere på én specifik opgave, er der ingen, der begrænser dig — det vil åbenlyst være et spor om processer og kultur. Husk, at efter konferencen vil du have optagelser (efter udfyldning af feedback-formularen), så du kan altid se mindre vigtige præsentationer senere.
Det er åbenlyst, at du ikke kan deltage i tre spor samtidigt på selve konferencen, derfor sætter vi programmet sammen, så der i hver tidsramme er emner for enhver smag.
Der er kun én ting tilbage at forstå: hvad gør man, hvis man er DevOps-ingeniør! Først og fremmest skal du prøve at definere, hvad det er, du faktisk arbejder med. Normalt bliver dette ord brugt til at betegne:
- Udviklere, der arbejder med infrastruktur. For dig passer grupperne med præsentationer om SRE og Cloud Native bedst.
- Systemadministratorer. Her er det mere kompliceret. DevOps handler ikke om systemadministration. Heldigvis er der masser af fremragende konferencer, bøger, artikler, videoer på internettet osv. om emnet systemadministration. På den anden side, hvis du er interesseret i at udvikle din forståelse af kultur og processer, lære om cloud-teknologier og detaljerne ved liv med Cloud Native, så vil vi glæde os over at se dig! Tænk over dette: du arbejder med administration, men hvad vil du gøre derefter? For ikke at ende i en ubehagelig situation, er det en god idé at lære allerede nu.
Der er også en anden mulighed: du holder fast og hævder, at du er netop DevOps-ingeniør og intet andet, hvad det nu end betyder. Så må jeg desværre skuffe dig, DevOps er ikke en konference for DevOps-ingeniører!
Slide fra i München
DevOops 2020 Moscow finder sted den 29.-30. april i Moskva, billetter kan nu .
Derudover kan du indtil 8. februar. Bemærk, at når du udfylder formularen, skal du vælge målgruppen, som din præsentation vil være mest nyttig for (der er en overraskelse gemt i listen).
Kilde: habr.com
