Recentment, aquests anuncis han inundat Internet. Malgrat el sou agradable, un no pot evitar avergonyir-se que hi hagi escrit una heretgia salvatge a dins. Al principi, se suposa que "DevOps" i "enginyer" es poden enganxar d'alguna manera en una paraula, i després hi ha una llista aleatòria de requisits, alguns dels quals es copien clarament de la vacant d'administrador del sistema.
En aquest post m'agradaria parlar una mica de com hem arribat a aquest punt de la vida, què és realment DevOps i què fer-hi ara.
Aquestes vacants es poden condemnar de totes les maneres possibles, però la realitat és que n'hi ha moltes, i així funciona el mercat en aquests moments. Vam fer una conferència devops i vam declarar obertament: " - no per als enginyers de DevOps". Això semblarà estrany i salvatge per a molts: per què la gent que està fent un esdeveniment completament comercial va en contra del mercat. Ara ho explicarem tot.
Sobre cultura i processos
Comencem pel fet que DevOps no és una disciplina d'enginyeria. Tot va començar amb el fet que la divisió de rols establerta històricament no funciona per a la qualitat dels productes. Quan els programadors només programen, però no volen escoltar res sobre proves, el programari està ple d'errors. Quan als administradors no els importa com o per què s'escriu el programari, el suport es converteix en un infern.
Per exemple, descrivint la diferència entre un administrador del sistema i un enfocament SRE per a la gestió del servei . S'han fet estudis interessants dins — Està clar que els millors desenvolupadors aconsegueixen d'alguna manera implementar nous canvis a la producció més ràpid que una vegada per hora. Es fan proves amb les mans no més del 10% (això es pot veure des de ). Com ho fan? "Excel o mor", diu un dels encapçalaments de l'informe. Per a una discussió detallada d'aquestes estadístiques en el context de les proves, podeu consultar la nota magistral de Baruch Sadogursky a la nostra altra conferència, Heisenbug.
“Quan no hi ha acord entre companys,
Les coses no els aniran bé,
I no en sortirà res, només un turment.
Hi havia una vegada un cigne, un cranc de riu i un lluç..."
Quina part dels programadors web creus que entén realment les condicions en què s'utilitzen les seves aplicacions en producció? Quants d'ells aniran als administradors i intentaran esbrinar què passarà si la base de dades falla? I quin d'ells anirà als examinadors i els demanarà que els ensenyin a escriure les proves correctament? I també hi ha guàrdies de seguretat, gestors de producte i un munt d'altres persones.
La idea general de DevOps és crear col·laboració entre rols i departaments. En primer lloc, això no s'aconsegueix amb un programari intel·ligentment configurat, sinó amb la pràctica de la comunicació. DevOps tracta de cultura, pràctiques, metodologia i processos. No hi ha cap especialitat d'enginyeria que pugui respondre aquestes preguntes.
Cercle viciós
D'on va sorgir llavors la disciplina de "enginyeria devops"? Tenim una versió! Les idees de DevOps eren bones, tan bones que es van convertir en víctimes del seu propi èxit. Alguns reclutadors ombrívols i traficants d'éssers humans, que tenen la seva pròpia atmosfera, van començar a girar per tot aquest tema.
Imagineu-vos: ahir vas fer shawarma a Khimki, i avui ja ets un home gran, un reclutador sènior. Hi ha tot un procés de recerca i selecció de candidats, no tot és fàcil, cal entendre-ho. Suposem que el cap d'un departament diu: busqueu un especialista en X. Assignem la paraula "enginyer" a X i ja hem acabat. Necessites Linux? Bé, definitivament aquest és un enginyer Linux, si voleu DevOps, llavors un enginyer DevOps. La vacant consisteix no només en un títol, sinó que també s'ha d'introduir algun text al seu interior. La manera més senzilla és introduir un conjunt de paraules clau de Google, segons la vostra imaginació. DevOps consta de dues paraules: "Dev" i "Ops", el que significa que hem d'enganxar paraules clau relacionades amb desenvolupadors i administradors, tot en un sol munt. Així apareixen les vacants sobre la competència en 42 llenguatges de programació i 20 anys d'ús de Kubernetes i Swarm simultàniament. Diagrama de treball.
Així és com la imatge sense sentit i despietat d'un cert superheroi "devops" ha arrelat a la ment de la gent, que configurarà tothom per desplegar-se a Jenkins, i arribarà la felicitat. Oh, si tot fos tan senzill. "I així és també com pots perseguir els administradors de sistemes", pensa RRHH, "és una paraula de moda, les paraules clau són les mateixes, haurien de prendre l'esquer".
La demanda crea l'oferta, i totes aquestes vacants d'escombraries s'han omplert amb un nombre boig d'administradors de sistemes que es van adonar: podeu fer-ho tot igual que abans, però obtenir-ne diverses vegades més fent-se dir "devops". De la mateixa manera que heu configurat els servidors mitjançant SSH manualment un a la vegada, continuareu configurant-los, però ara suposadament això és una pràctica devops. Es tracta d'una mena de fenomen complex, en part relacionat amb la subestimació dels administradors clàssics i el bombo al voltant de DevOps, però, en general, va passar el que va passar.
Així que tenim oferta i demanda. Un cercle viciós que s'alimenta. Això és el que estem lluitant (incloent-hi la creació de la conferència DevOops).
Per descomptat, a més dels administradors del sistema que s'han rebatejat com a "devops", hi ha altres participants, per exemple, SRE professionals o desenvolupadors d'Infraestructura com a codi.
Què fa la gent a DevOps (de debò)
Per tant, voleu avançar en l'aprenentatge i l'aplicació de pràctiques de DevOps. Però, com fer-ho, en quina direcció mirar? Òbviament, no hauríeu de confiar cegament en paraules clau populars.
Si hi ha feina, algú ho hauria de fer. Ja hem descobert que aquests no són "enginyers devops", llavors qui ho són? Sembla més correcte formular-ho no en termes de posicions, sinó en termes d'àmbits concrets de treball.
Primer, podeu abordar el cor de DevOps: processos i cultura. La cultura és un negoci lent i difícil, i encara que tradicionalment és responsabilitat dels directius, tothom hi està implicat d'una manera o altra, des dels programadors fins als administradors. Fa un parell de mesos Tim Lister :
“La cultura està determinada pels valors fonamentals de l'organització. Normalment la gent no se n'adona, però havent treballat molts anys en consultoria, estem acostumats a notar-ho. Entres en una empresa i, literalment, en pocs minuts comences a sentir el que està passant. A això l'anomenem "sabor". De vegades, aquesta olor és molt bona. De vegades provoca nàusees. (...) No pots canviar una cultura fins que no s'entenen els valors i creences que hi ha darrere d'accions concretes. El comportament és fàcil d'observar, però la recerca de creences és difícil. DevOps és només un gran exemple de com les coses són cada cop més complexes".
També hi ha una part tècnica del problema, és clar. Si el vostre codi nou es prova en un mes, però només es publica un any després i és físicament impossible accelerar-ho tot, és possible que no estigueu a l'altura de les bones pràctiques. Les bones pràctiques es recolzen amb bones eines. Per exemple, tenint en compte la idea d'Infrastructure-as-Code, podeu utilitzar qualsevol cosa, des d'AWS CloudFormation i Terraform fins a Chef-Ansible-Puppet. Cal saber i poder fer tot això, i això ja és una disciplina d'enginyeria. És important no confondre causa amb efecte: primer treballeu segons els principis de SRE i només després implementeu aquests principis en forma d'algunes solucions tècniques específiques. Al mateix temps, SRE és una metodologia molt completa que no us indica com configurar Jenkins, sinó uns cinc principis bàsics:
- Millora de la comunicació entre rols i departaments
- Acceptar els errors com a part integral de la feina
- Fer canvis de manera gradual
- Ús d'eines i altres automatitzacions
- Mesurant tot el que es pot mesurar
Això no és només un conjunt d'afirmacions, sinó un concret . Per exemple, en el camí per acceptar errors, haureu d'entendre els riscos, mesurar la disponibilitat i indisponibilitat dels serveis mitjançant alguna cosa com SLI () i SLO (), apreneu a escriure autopsies i feu que escriure-les no faci por.
En la disciplina SRE, l'ús d'eines és només una part de l'èxit, encara que important. Hem de desenvolupar-nos tècnicament constantment, mirar què passa al món i com es pot aplicar a la nostra feina.
Al seu torn, les solucions Cloud Native s'han tornat molt populars. Tal com defineix la Cloud Native Computing Foundation avui, les tecnologies Cloud Native permeten a les organitzacions desenvolupar i executar aplicacions escalables en els entorns dinàmics actuals, com ara núvols públics, privats i híbrids. Alguns exemples inclouen contenidors, malles de servei, microserveis, infraestructura immutable i API declaratives. Totes aquestes tècniques permeten que els sistemes poc acoblats siguin elàstics, manejables i altament observables. Una bona automatització permet als enginyers fer grans canvis amb freqüència i amb resultats previsibles sense fer-ho una tasca. Tot això està recolzat per una pila d'eines conegudes com Docker i Kubernetes.
Aquesta definició força complicada i àmplia es deu al fet que la zona també és força complexa. D'una banda, s'argumenta que s'han d'afegir nous canvis a aquest sistema de manera senzilla. D'altra banda, esbrinar com crear una mena d'entorn en contenidors en el qual els serveis poc acoblats viuen en una infraestructura definida per programari i s'hi lliuren mitjançant CI/CD contínues, i crear pràctiques DevOps al voltant de tot això, tot això requereix més que un es menja el gos.
Què fer amb tot això
Cadascú resol aquests problemes a la seva manera: per exemple, podeu publicar vacants normals per trencar el cercle viciós. Podeu esbrinar què signifiquen paraules com DevOps i Cloud Native i utilitzar-les correctament i fins al punt. Podeu desenvolupar-vos a DevOps i demostrar els enfocaments adequats amb el vostre exemple.
Estem fent una conferència , que ofereix una oportunitat per aprofundir en les coses de les quals acabem de parlar. Hi ha diversos grups d'informes per a això:
- Processos i cultura;
- Enginyeria de fiabilitat del lloc;
- Núvol natiu;
Com triar on anar? Aquí hi ha un punt subtil. D'una banda, DevOps tracta d'interacció, i volem que assistiu a presentacions de diferents blocs. D'altra banda, si sou un gestor de desenvolupament que va venir a la conferència per concentrar-vos en una tasca específica, ningú us limitarà; òbviament, aquest serà un bloc sobre processos i cultura. No oblidis que tindreu gravacions després de la conferència (després d'omplir el formulari de comentaris), de manera que sempre podreu veure presentacions menys importants més endavant.
Òbviament, a la mateixa conferència no es pot anar per tres pistes alhora, per això organitzem el programa de manera que cada franja horària tingui temes per a tots els gustos.
Només queda entendre què fer si sou enginyer de DevOps! Primer, intenta determinar què fas realment. Normalment els agrada anomenar aquesta paraula:
- Desenvolupadors que treballen en infraestructures. Els grups d'informes sobre SRE i Cloud Native són els més adequats per a tu.
- Administradors de sistemes. Aquí és més complicat. DevOops no tracta de l'administració del sistema. Afortunadament, a Internet hi ha moltes conferències, llibres, articles, vídeos, etc. excel·lents sobre el tema de l'administració del sistema. D'altra banda, si us interessa desenvolupar-vos pel que fa a la comprensió de la cultura i els processos, aprendre sobre les tecnologies del núvol i els detalls de la vida amb Cloud Native, ens encantaria veure-us! Penseu en això: esteu fent administració i, aleshores, què fareu? Per evitar trobar-te de cop en una situació desagradable, hauries d'aprendre ara.
Hi ha una altra opció: persistiu i continueu afirmant que ho sou concretament un enginyer de DevOps i res més, sigui el que signifiqui. Aleshores us hem de decebre, DevOops no és una conferència per a enginyers de DevOps!
Llisca des de a Munic
DevOops 2020 Moscou se celebrarà del 29 al 30 d'abril a Moscou, les entrades ja estan disponibles .
Alternativament, pots fins al 8 de febrer. Tingueu en compte que en omplir el formulari, heu de seleccionar el públic objectiu que es beneficiarà més del vostre informe (hi ha una sorpresa enterrada a la llista).
Font: www.habr.com