DevOps s'ha convertit en un tema molt popular durant els últims anys. Molta gent somien unir-s'hi, però, com demostra la pràctica, sovint només pel nivell de sous.
Algunes persones enumeren DevOps al seu currículum, tot i que no sempre coneixen ni entenen l'essència del terme. Algunes persones pensen que després d'estudiar Ansible, GitLab, Jenkins, Terraform i similars (la llista es pot continuar segons el vostre gust), immediatament us convertireu en un "devopsista". Això, per descomptat, no és cert.
Durant els darrers anys, he participat principalment en la implementació de DevOps en diverses empreses. Abans d'això, va treballar durant més de 20 anys en llocs que van des d'administrador de sistemes fins a director de TI. Actualment enginyer principal de DevOps a Playgendary.
Qui és DevOps
La idea d'escriure un article va sorgir després d'una altra pregunta: "qui és DevOps?" Encara no hi ha un terme establert per a què o qui és. Algunes de les respostes ja estan en això . Primer, en destacaré els punts principals i després compartiré les meves observacions i pensaments.
DevOps no és un especialista que es pugui contractar, ni un conjunt d'utilitats ni un departament de desenvolupadors amb enginyers.
DevOps és una filosofia i una metodologia.
En altres paraules, és un conjunt de pràctiques que ajuda els desenvolupadors a interactuar activament amb els administradors del sistema. És a dir, connectar i integrar processos de treball entre si.
Amb l'arribada de DevOps, l'estructura i els rols dels especialistes van continuar sent els mateixos (hi ha desenvolupadors, hi ha enginyers), però les regles d'interacció han canviat. Els límits entre departaments s'han difuminat.
Els objectius de DevOps es poden descriure en tres punts:
- El programari s'ha d'actualitzar regularment.
- El programari s'ha de fer ràpidament.
- El programari s'ha de desplegar còmodament i en poc temps.
No hi ha una única eina per a DevOps. Configurar, lliurar i estudiar diversos productes no vol dir que DevOps hagi aparegut a l'empresa. Hi ha moltes eines i totes s'utilitzen en diferents etapes, però tenen un propòsit comú.
I això només és una part de les eines de DevOps
Fa més de 2 anys que entrevistem persones per al càrrec d'enginyer de DevOps i m'he adonat de l'important que és entendre clarament l'essència del terme. He acumulat experiències, observacions i pensaments concrets que vull compartir.
A partir de l'experiència de l'entrevista, veig la següent imatge: Els especialistes que consideren DevOps un títol de feina solen tenir malentesos amb els seus companys.
Hi havia un exemple sorprenent. Un jove va venir a una entrevista amb moltes paraules intel·ligents al seu currículum. En els seus últims tres llocs de treball, tenia 5-6 mesos d'experiència. Vaig deixar dues startups perquè "no van enlairar". Però sobre la tercera empresa, va dir que ningú l'entén allà: els desenvolupadors escriuen codi a Windows, i el director obliga aquest codi a "embolicar-se" a Docker normal i integrat al pipeline CI/CD. El noi va dir moltes coses negatives sobre el seu lloc de treball actual i els seus companys; només volia respondre: "Així que no vendràs un elefant".
Aleshores li vaig fer una pregunta que ocupava un lloc destacat a la meva llista per a cada candidat.
— Què significa DevOps per a tu personalment?
- En general o com ho percebo?
M'interessava la seva opinió personal. Coneixia la teoria i l'origen del terme, però estava molt en desacord amb ells. Creia que DevOps era un títol de feina. Aquí és on rau l'arrel dels seus problemes. Així com altres especialistes amb la mateixa opinió.
Els empresaris, després d'haver sentit parlar molt de la "màgia de DevOps", volen trobar una persona que vingui a crear aquesta "màgia". I els sol·licitants de la categoria "DevOps és una feina" no entenen que amb aquest enfocament no podran satisfer les expectatives. I, en general, van escriure DevOps al seu currículum perquè és una tendència i paguen molt per això.
Metodologia i filosofia DevOps
La metodologia pot ser teòrica i pràctica. En el nostre cas, és el segon. Com he esmentat anteriorment, DevOps és un conjunt de pràctiques i estratègies utilitzades per assolir els objectius establerts. I en cada cas, depenent dels processos de negoci de l'empresa, pot variar significativament. La qual cosa no ho fa ni millor ni pitjor.
La metodologia DevOps és només un mitjà per assolir els objectius.
Ara sobre què és la filosofia DevOps. I aquesta és probablement la pregunta més difícil.
És força difícil formular una resposta breu i sucinta, perquè encara no s'ha formalitzat. I com que els seguidors de la filosofia DevOps es dediquen més a la pràctica, simplement no hi ha temps per filosofar. No obstant això, aquest és un procés molt important. A més, està directament relacionat amb les activitats d'enginyeria. Fins i tot hi ha una àrea especialitzada de coneixement - .
A la meva universitat no hi havia aquesta assignatura, vaig haver d'estudiar-ho tot pel meu compte amb els materials que vaig trobar als anys 90. El tema és optatiu per als estudis d'enginyeria, d'aquí la manca de formalització de la resposta. Però aquelles persones que estan seriosament immerses en DevOps comencen a sentir un cert "esperit" o "comprensió inconscient" de tots els processos de l'empresa.
A partir de la meva pròpia experiència, vaig intentar formalitzar alguns dels “postulats” d'aquesta filosofia. El resultat és el següent:
- DevOps no és quelcom independent que es pugui separar en una àrea de coneixement o activitat separada.
- Tots els empleats de l'empresa s'han de guiar per la metodologia DevOps a l'hora de planificar les seves activitats.
- DevOps afecta tots els processos dins d'una empresa.
- DevOps existeix per reduir els costos de temps de qualsevol procés dins d'una empresa per garantir el desenvolupament dels seus serveis i la màxima comoditat del client.
- DevOps, en llenguatge modern, és la posició proactiva de cada empleat de l'empresa, orientada a reduir costos de temps i millorar la qualitat dels productes informàtics que ens envolten.
Crec que els meus "postulats" són un tema a part de discussió. Però ara hi ha alguna cosa per construir.
Què fa DevOps
La paraula clau aquí és comunicació. Hi ha moltes comunicacions, l'iniciador de les quals hauria de ser exactament el mateix enginyer de DevOps. Per què això? Perquè això és filosofia i metodologia, i només llavors coneixement d'enginyeria.
No puc parlar amb 100% de confiança sobre el mercat laboral occidental. Però sé molt sobre el mercat DevOps a Rússia. A més de centenars d'entrevistes, durant l'últim any i mig he participat en centenars de prevendes tècniques per al servei "Implementació de DevOps" per a grans empreses i bancs russos.
A Rússia, DevOps encara és un tema molt jove, però ja tendència. Pel que sé, només a Moscou l'escassetat d'especialistes d'aquest tipus el 2019 va ser de més de 1000 persones. I la paraula Kubernetes per als empresaris és gairebé com un drap vermell per a un toro. Els seguidors d'aquesta eina estan preparats per utilitzar-la fins i tot quan no sigui necessari i rendible econòmicament. L'empresari no sempre entén en quins casos el que és més adequat utilitzar, i amb un desplegament adequat, mantenir un clúster de Kubernetes costa entre 2 i 3 vegades més que desplegar una aplicació mitjançant un esquema de clúster convencional. Utilitzeu-lo on realment ho necessiteu.
Implementar DevOps és car en termes de diners. I només es justifica quan aporta beneficis econòmics en altres àmbits, i no per si sol.
Els enginyers de DevOps són, de fet, pioners: són els que haurien de ser els primers a implementar aquesta metodologia a l'empresa i construir processos. Perquè això tingui èxit, l'especialista ha d'interaccionar constantment amb els empleats i companys de tots els nivells. Com dic habitualment, tots els empleats de l'empresa haurien d'estar implicats en el procés d'implementació de DevOps: des de la dona de la neteja fins al CEO. I aquest és un requisit previ. Si el membre més jove de l'equip no sap i entén què és DevOps i per què es duen a terme determinades accions organitzatives, la implementació correcta no funcionarà.
A més, un enginyer de DevOps ha d'utilitzar un recurs administratiu de tant en tant. Per exemple, per superar la "resistència ambiental", quan l'equip no està preparat per acceptar les eines i la metodologia DevOps.
El desenvolupador només hauria d'escriure codi i proves. Per fer-ho, no necessita un ordinador portàtil superpotent on desplegarà i donarà suport localment a tota la infraestructura del projecte. Per exemple, un desenvolupador front-end manté tots els elements de l'aplicació al seu ordinador portàtil, inclosa la base de dades, l'emulador S3 (minio), etc. És a dir, dedica molt de temps a mantenir aquesta infraestructura local i lluita sol amb tots els problemes d'aquesta solució. En lloc de desenvolupar codi per al front. Aquestes persones poden ser molt resistents a qualsevol canvi.
Però hi ha equips que, per contra, estan encantats d'introduir noves eines i mètodes, i de participar activament en aquest procés. Encara que fins i tot en aquest cas, la comunicació entre l'enginyer de DevOps i l'equip no es va cancel·lar.
Quan DevOps no és necessari
Hi ha situacions en què DevOps no és necessari. Això és un fet: cal entendre-ho i acceptar-lo.
En primer lloc, això s'aplica a qualsevol empresa (especialment a les petites empreses), quan el seu benefici no depèn directament de la presència o absència de productes informàtics que proporcionen serveis d'informació als clients. I aquí no estem parlant de la web de l'empresa, ja sigui una “targeta de visita” estàtica o amb blocs de notícies dinàmics, etc.
DevOps és necessari quan la satisfacció del vostre client i el seu desig de tornar-vos-hi depenen de la disponibilitat d'aquests serveis d'informació per a la interacció amb el client, la seva qualitat i orientació.
Un exemple sorprenent és un banc conegut. L'empresa no disposa de les oficines habituals dels clients, el flux de documents es realitza per correu o missatgeria, i molts empleats treballen des de casa. L'empresa ha deixat de ser només un banc i, al meu entendre, s'ha convertit en una empresa informàtica amb tecnologies DevOps desenvolupades.
Molts altres exemples i conferències es poden trobar a les gravacions de trobades i conferències temàtiques. Vaig visitar alguns d'ells personalment: aquesta és una experiència molt útil per a aquells que volen desenvolupar-se en aquesta direcció. Aquí teniu enllaços a canals de YouTube amb bones conferències i materials sobre DevOps:
Ara mireu el vostre negoci i penseu en això: quant depenen la vostra empresa i els seus beneficis dels productes informàtics per permetre la interacció amb els clients?
Si la vostra empresa ven peix en una petita botiga i l'únic producte informàtic són dos 1C: configuracions empresarials (Comptabilitat i UNF), aleshores no té sentit parlar de DevOps.
Si treballeu en una gran empresa comercial i de fabricació (per exemple, produïu rifles de caça), hauríeu de pensar-hi. Podeu prendre la iniciativa i transmetre a la vostra direcció les perspectives d'implementació de DevOps. Bé, i al mateix temps, lidereu aquest procés. Una posició proactiva és un dels principis importants de la filosofia DevOps.
La mida i el volum de la facturació financera anual no és el criteri principal per determinar si la vostra empresa necessita DevOps.
Imaginem una gran empresa industrial que no interactua directament amb els clients. Per exemple, alguns fabricants d'automòbils i empreses de fabricació d'automòbils. Ara no estic segur, però des de la meva experiència passada, durant molts anys tota la interacció amb el client es va fer per correu electrònic i telèfon.
Els seus clients són una llista limitada de concessionaris d'automòbils. I a cadascun se li assigna un especialista del fabricant. Tot el flux de documents interns es produeix mitjançant SAP ERP. Els empleats interns són essencialment clients del sistema d'informació. Però aquest IS està controlat per mitjans clàssics de gestió de sistemes de clúster. La qual cosa exclou la possibilitat d'utilitzar pràctiques DevOps.
D'aquí la conclusió: per a aquestes empreses, la implementació de DevOps no és una cosa molt important, si recordem els objectius de la metodologia des del principi de l'article. Però no descarto que avui utilitzen algunes eines DevOps.
D'altra banda, hi ha moltes petites empreses que desenvolupen programari utilitzant la metodologia, la filosofia, les pràctiques i les eines DevOps. I creuen que el cost d'implementar DevOps és el cost que els permet competir amb eficàcia al mercat del programari. Es poden veure exemples d'aquestes empreses .
El criteri principal per entendre si es necessita DevOps: quin valor tenen els vostres productes informàtics per a l'empresa i els clients.
Si el producte principal de l'empresa que genera beneficis és el programari, necessiteu DevOps. I no és tan important si guanyes diners reals amb altres productes. Això també inclou les botigues en línia o les aplicacions mòbils amb jocs.
Qualsevol joc existeix gràcies al finançament: directe o indirecte dels jugadors. A Playgendary, desenvolupem jocs mòbils gratuïts amb més de 200 persones directament implicades en la seva creació. Com fem servir DevOps?
Sí, exactament el mateix que es descriu anteriorment. Em comunico constantment amb desenvolupadors i provadors, i realitzo formació interna per als empleats sobre metodologia i eines DevOps.
Ara estem utilitzant de manera activa Jenkins com a eina de canalitzacions CI/CD per executar totes les canalitzacions de muntatge amb Unity i el posterior desplegament a l'App Store i Play Market. Més del clàssic conjunt d'eines:
- Asana - per a la gestió de projectes. S'ha configurat la integració amb Jenkins.
- Google Meet: per a videotrucades.
- Slack: per a comunicacions i diverses alertes, incloses les notificacions de Jenkins.
- Atlassian Confluence - per a la documentació i el treball en grup.
Els nostres plans immediats inclouen la introducció de l'anàlisi de codi estàtic mitjançant SonarQube i la realització de proves automatitzades de la interfície d'usuari amb Selenium en l'etapa d'integració contínua.
En lloc d'una conclusió
M'agradaria acabar amb el següent pensament: per convertir-se en un enginyer DevOps altament qualificat, és vital aprendre a comunicar-se en directe amb la gent.
Un enginyer de DevOps és un jugador d'equip. I res més. La iniciativa per comunicar-se amb els companys ha de venir d'ell, i no sota la influència d'algunes circumstàncies. Un especialista en DevOps ha de veure i proposar la millor solució per a l'equip.
I sí, la implementació de qualsevol solució requerirà molta discussió i, al final, pot canviar completament. Desenvolupant-se de manera autònoma, proposant i implementant les seves idees, aquesta persona és de valor creixent tant per a l'equip com per a l'empresari. La qual cosa, en definitiva, es reflecteix en l'import de la seva retribució mensual o en forma de gratificacions addicionals.
Font: www.habr.com