DevOps converteuse nun tema moi popular nos últimos anos. Moita xente soña con unirse a el, pero, como mostra a práctica, moitas veces só polo nivel dos salarios.
Algunhas persoas enumeran DevOps no seu currículo, aínda que non sempre saben nin entenden a esencia do termo. Algunhas persoas pensan que despois de estudar Ansible, GitLab, Jenkins, Terraform e similares (a lista pódese continuar segundo o seu gusto), converterase inmediatamente nun "devopsista". Isto, por suposto, non é certo.
Durante os últimos anos, participei principalmente na implementación de DevOps en varias empresas. Antes diso, traballou durante máis de 20 anos en cargos que van desde administrador de sistemas ata director de TI. Actualmente enxeñeiro principal de DevOps en Playgendary.
Quen é DevOps
A idea de escribir un artigo xurdiu tras outra pregunta: "quen é DevOps?" Aínda non hai un termo establecido para que ou quen é. Algunhas das respostas xa están nisto . En primeiro lugar, destacarei os puntos principais e despois compartirei as miñas observacións e pensamentos.
DevOps non é un especialista que se poida contratar, nin un conxunto de utilidades nin un departamento de desenvolvedores con enxeñeiros.
DevOps é unha filosofía e unha metodoloxía.
Noutras palabras, é un conxunto de prácticas que axudan aos desenvolvedores a interactuar activamente cos administradores do sistema. É dicir, conectar e integrar procesos de traballo entre si.
Coa chegada de DevOps, a estrutura e os roles dos especialistas seguiron sendo os mesmos (hai desenvolvedores, hai enxeñeiros), pero as regras de interacción cambiaron. Os límites entre departamentos difumináronse.
Os obxectivos de DevOps pódense describir en tres puntos:
- O software debe actualizarse regularmente.
- O software debe facerse rapidamente.
- O software debe implementarse de forma cómoda e en pouco tempo.
Non hai unha única ferramenta para DevOps. Configurar, entregar e estudar varios produtos non significa que DevOps aparecese na empresa. Hai moitas ferramentas e todas úsanse en diferentes etapas, pero teñen un propósito común.
E isto é só parte das ferramentas de DevOps
Levo máis de 2 anos entrevistando a xente para o posto de enxeñeiro de DevOps, e deime conta do importante que é comprender claramente a esencia do termo. Acumulei experiencias, observacións e pensamentos específicos que quero compartir.
Pola experiencia da entrevista, vexo a seguinte imaxe: os especialistas que consideran DevOps un título de traballo adoitan ter malentendidos cos compañeiros.
Houbo un exemplo rechamante. Un mozo chegou a unha entrevista con moitas palabras intelixentes no seu currículo. Nos seus últimos tres traballos, tiña 5-6 meses de experiencia. Deixei dúas startups porque "non despegaron". Pero sobre a terceira empresa, dixo que ninguén o entende alí: os desenvolvedores escriben código en Windows e o director obriga a que este código se "envolve" en Docker normal e se integre na canalización CI/CD. O mozo dixo moitas cousas negativas sobre o seu lugar de traballo actual e os seus compañeiros; só quería responder: "Entón non venderás un elefante".
Entón fixenlle unha pregunta que está na miña lista para todos os candidatos.
- Que significa DevOps para ti persoalmente?
- En xeral ou como o percibo?
Interesábame a súa opinión persoal. Coñecía a teoría e a orixe do termo, pero non estaba de acordo con eles. Cría que DevOps era un posto de traballo. Aquí radica a raíz dos seus problemas. Así como outros especialistas coa mesma opinión.
Os empresarios, xa que escoitaron moito sobre a "maxia de DevOps", queren atopar unha persoa que veña crear esta "maxia". E os candidatos da categoría "DevOps é un traballo" non entenden que con este enfoque non poderán cumprir as expectativas. E, en xeral, escribiron DevOps no seu currículo porque é unha tendencia e pagan moito por iso.
Metodoloxía e filosofía DevOps
A metodoloxía pode ser teórica e práctica. No noso caso, é o segundo. Como mencionei anteriormente, DevOps é un conxunto de prácticas e estratexias utilizadas para acadar os obxectivos establecidos. E en cada caso, dependendo dos procesos comerciais da empresa, pode diferir significativamente. O que non o fai mellor nin peor.
A metodoloxía DevOps é só un medio para acadar os obxectivos.
Agora sobre cal é a filosofía DevOps. E esta é probablemente a pregunta máis difícil.
É bastante difícil formular unha resposta breve e sucinta, porque aínda non se formalizou. E dado que os seguidores da filosofía DevOps están máis implicados na práctica, simplemente non hai tempo para filosofar. Non obstante, este é un proceso moi importante. Ademais, está directamente relacionado coas actividades de enxeñería. Incluso hai unha área especializada de coñecemento - .
Non había esa materia na miña universidade, tiven que estudar todo pola miña conta utilizando os materiais que puiden atopar nos anos 90. O tema é optativo para as ensinanzas de enxeñaría, de aí a falta de formalización da resposta. Pero aquelas persoas que están seriamente inmersas en DevOps comezan a sentir un certo "espírito" ou "comprensión inconsciente" de todos os procesos da empresa.
Usando a miña propia experiencia, tentei formalizar algúns dos “postulados” desta filosofía. O resultado é o seguinte:
- DevOps non é algo independente que se poida separar nunha área de coñecemento ou actividade separada.
- Todos os empregados da empresa deben guiarse pola metodoloxía DevOps á hora de planificar as súas actividades.
- DevOps afecta a todos os procesos dentro dunha empresa.
- DevOps existe para reducir os custos de tempo para calquera proceso dentro dunha empresa para garantir o desenvolvemento dos seus servizos e a máxima comodidade do cliente.
- DevOps, en linguaxe moderna, é a posición proactiva de cada empregado da empresa, dirixida a reducir custos de tempo e mellorar a calidade dos produtos de TI que nos rodean.
Creo que os meus "postulados" son un tema separado para o debate. Pero agora hai algo sobre o que construír.
Que fai DevOps
A palabra clave aquí é comunicación. Hai moitas comunicacións, cuxo iniciador debería ser exactamente o mesmo enxeñeiro de DevOps. Por que é iso? Porque isto é filosofía e metodoloxía, e só entón coñecemento de enxeñería.
Non podo falar cun 100% de confianza sobre o mercado laboral occidental. Pero sei moito sobre o mercado DevOps en Rusia. Ademais de centos de entrevistas, durante o último ano e medio participei en centos de preventas técnicas para o servizo "Implementación de DevOps" para grandes empresas e bancos rusos.
En Rusia, DevOps aínda é un tema moi novo, pero xa de moda. Polo que sei, só en Moscova a escaseza deste tipo de especialistas en 2019 foi de máis de 1000 persoas. E a palabra Kubernetes para os empresarios é case como un trapo vermello para un touro. Os seguidores desta ferramenta están preparados para usala aínda que non sexa necesario e rendible economicamente. O empresario non sempre entende en que casos o que é máis apropiado utilizar, e cunha implantación adecuada, manter un clúster de Kubernetes custa 2-3 veces máis que implantar unha aplicación mediante un esquema de clúster convencional. Úsao onde realmente o necesites.
Implementar DevOps é caro en termos de diñeiro. E só se xustifica onde trae beneficios económicos noutros ámbitos, e non por si só.
Os enxeñeiros de DevOps son, de feito, pioneiros: son os que deberían ser os primeiros en implementar esta metodoloxía na empresa e construír procesos. Para que isto teña éxito, o especialista debe interactuar constantemente cos empregados e colegas de todos os niveis. Como adoito dicir, todos os empregados da empresa deberían estar implicados no proceso de implementación de DevOps: desde a muller da limpeza ata o CEO. E este é un requisito previo. Se o membro máis júnior do equipo non sabe e comprende o que é DevOps e por que se realizan determinadas accións organizativas, a implementación exitosa non funcionará.
Ademais, un enxeñeiro de DevOps necesita utilizar un recurso administrativo de cando en vez. Por exemplo, para superar a "resistencia ambiental" - cando o equipo non está preparado para aceptar ferramentas e metodoloxía DevOps.
O programador só debe escribir código e probas. Para iso, non necesita un portátil superpotente no que despregará e apoiará localmente toda a infraestrutura do proxecto. Por exemplo, un desenvolvedor front-end mantén todos os elementos da aplicación no seu portátil, incluíndo a base de datos, o emulador S3 (minio), etc. É dicir, dedica moito tempo ao mantemento desta infraestrutura local e loita en solitario con todos os problemas de tal solución. En lugar de desenvolver código para a fronte. Estas persoas poden ser moi resistentes a calquera cambio.
Pero hai equipos que, pola contra, están encantados de introducir novas ferramentas e métodos, e participan activamente neste proceso. Aínda que mesmo neste caso, a comunicación entre o enxeñeiro de DevOps e o equipo non foi cancelada.
Cando DevOps non é necesario
Hai situacións nas que DevOps non é necesario. Este é un feito: hai que entendelo e aceptalo.
En primeiro lugar, isto aplícase a calquera empresa (especialmente pequenas empresas), cando o seu beneficio non depende directamente da presenza ou ausencia de produtos informáticos que proporcionan servizos de información aos clientes. E aquí non estamos a falar da páxina web da empresa, xa sexa unha “tarxeta de presentación” estática ou con bloques de noticias dinámicos, etc.
DevOps é necesario cando a satisfacción do teu cliente e o seu desexo de volver a ti dependen da dispoñibilidade destes servizos de información para a interacción co cliente, da súa calidade e orientación.
Un exemplo sorprendente é un banco coñecido. A empresa non dispón de oficinas tradicionais de clientes, o fluxo de documentos realízase por correo ou mensaxería, e moitos empregados traballan desde casa. A empresa deixou de ser só un banco e, na miña opinión, converteuse nunha empresa de TI con tecnoloxías DevOps desenvolvidas.
Outros moitos exemplos e conferencias pódense atopar nas gravacións de encontros e conferencias temáticas. Visitei algúns deles persoalmente - esta é unha experiencia moi útil para aqueles que queren desenvolverse nesta dirección. Aquí tes ligazóns a canles de YouTube con boas conferencias e materiais sobre DevOps:
Agora mira o teu negocio e pensa nisto: canto depende a túa empresa e os seus beneficios dos produtos informáticos para permitir a interacción co cliente?
Se a túa empresa vende peixe nunha pequena tenda e o único produto informático son dous 1C: configuracións empresariais (Contabilidade e UNF), entón non ten sentido falar de DevOps.
Se traballas nunha gran empresa comercial e de fabricación (por exemplo, produces rifles de caza), deberías pensar niso. Podes tomar a iniciativa e transmitir á túa dirección as perspectivas para implementar DevOps. Ben, e ao mesmo tempo, lidera este proceso. Unha posición proactiva é un dos principios importantes da filosofía DevOps.
O tamaño e o volume da facturación financeira anual non é o principal criterio para determinar se a súa empresa necesita DevOps.
Imaxinemos unha gran empresa industrial que non interactúa directamente cos clientes. Por exemplo, algúns fabricantes de automóbiles e empresas de fabricación de automóbiles. Agora non estou seguro, pero dende a miña experiencia pasada, durante moitos anos toda a interacción do cliente realizouse por correo electrónico e teléfono.
Os seus clientes son unha lista limitada de concesionarios de automóbiles. E cada un ten asignado un especialista do fabricante. Todo o fluxo de documentos internos ocorre a través de SAP ERP. Os empregados internos son esencialmente clientes do sistema de información. Pero este IS está controlado por medios clásicos de xestión de sistemas de clúster. O que exclúe a posibilidade de utilizar prácticas de DevOps.
De aí a conclusión: para tales empresas, a implementación de DevOps non é algo de importancia crítica, se lembramos os obxectivos da metodoloxía desde o inicio do artigo. Pero non descarto que usen algunhas ferramentas DevOps hoxe.
Por outra banda, hai moitas pequenas empresas que desenvolven software utilizando a metodoloxía, filosofía, prácticas e ferramentas DevOps. E cren que o custo de implementación de DevOps é o custo que lles permite competir con eficacia no mercado do software. Pódense ver exemplos deste tipo de empresas .
O criterio principal para comprender se é necesario DevOps: que valor teñen os teus produtos de TI para a empresa e os clientes.
Se o principal produto da empresa que xera beneficios é o software, necesitas DevOps. E non é tan importante se gañas diñeiro real usando outros produtos. Isto tamén inclúe tendas en liña ou aplicacións móbiles con xogos.
Calquera xogo existe grazas ao financiamento: directo ou indirecto dos xogadores. En Playgendary, desenvolvemos xogos gratuítos para móbiles con máis de 200 persoas directamente implicadas na súa creación. Como usamos DevOps?
Si, exactamente igual ao descrito anteriormente. Comunícome constantemente con programadores e probadores e realizo formación interna para os empregados sobre a metodoloxía e ferramentas DevOps.
Agora estamos a usar Jenkins activamente como ferramenta de canalizacións CI/CD para executar todas as canalizacións de montaxe con Unity e a posterior implantación na App Store e Play Market. Máis do xogo de ferramentas clásico:
- Asana - para a xestión de proxectos. Configurouse a integración con Jenkins.
- Google Meet: para videoconferencias.
- Slack: para comunicacións e varias alertas, incluídas as notificacións de Jenkins.
- Atlassian Confluence - para documentación e traballo en grupo.
Os nosos plans inmediatos inclúen a introdución de análise de código estático mediante SonarQube e a realización de probas automatizadas de IU usando Selenium na fase de integración continua.
En vez de unha conclusión
Gustaríame rematar coa seguinte reflexión: para converterse nun enxeñeiro de DevOps altamente cualificado, é vital aprender a comunicarse en directo coa xente.
Un enxeñeiro de DevOps é un xogador de equipo. E nada máis. A iniciativa para comunicarse cos compañeiros debe vir del, e non baixo a influencia dalgunhas circunstancias. Un especialista en DevOps debe ver e propoñer a mellor solución para o equipo.
E si, a implementación de calquera solución requirirá moito debate e, ao final, pode cambiar por completo. Desenvolvendo de forma independente, propoñendo e aplicando as súas ideas, esa persoa ten un valor cada vez maior tanto para o equipo como para o empresario. O que, en definitiva, se reflicte no importe da súa retribución mensual ou en forma de gratificacións adicionais.
Fonte: www.habr.com