Que se necesita para que unha empresa de TI teña éxito en 2019? Os profesores de conferencias e encontros din moitas palabras en alto que non sempre son comprensibles para a xente normal. A loita polo tempo de implantación, os microservizos, o abandono do monolito, a transformación de DevOps e moito, moito máis. Se descartamos a beleza verbal e falamos directamente e en ruso, todo se reduce a unha simple tese: facer un produto de alta calidade e facelo con comodidade para o equipo.
Este último pasou a ser de importancia crítica. O negocio chegou finalmente á conclusión de que un proceso de desenvolvemento cómodo aumenta a produtividade e, se todo se depura e funciona como un reloxo, tamén dá marxe de manobra en situacións críticas. Érase unha vez, polo ben desta manobra, unha certa persoa intelixente inventou copias de seguridade, pero a industria está a desenvolverse, e chegamos aos enxeñeiros de DevOps, persoas que converten o proceso de interacción entre o desenvolvemento e a infraestrutura externa en algo adecuado e non relacionado co xamanismo.
Toda esta historia "modular" é marabillosa, pero... Aconteceu que algúns dos administradores foron bautizados bruscamente como DevOps, e os propios enxeñeiros de DevOps comezaron a ser obrigados a ter polo menos as habilidades de telepatía e clarividencia.
Antes de falar dos problemas modernos de proporcionar infraestrutura, imos definir o que entendemos por este termo. No momento actual, a situación desenvolveuse de tal xeito que chegamos á dualidade deste concepto: a infraestrutura pode ser condicionalmente externa e condicionalmente interna.
Por infraestrutura externa entendemos todo o que garante a funcionalidade do servizo ou produto que está a desenvolver o equipo. Trátase de servidores de aplicacións ou sitios web, hospedaxe e outros servizos que garanten a funcionalidade do produto.
A infraestrutura interna inclúe servizos e equipamentos que son utilizados polo propio equipo de desenvolvemento e outros empregados, dos que adoita ser moitos. Trátase de servidores internos de sistemas de almacenamento de código, un xestor de tarefas implantado localmente e todo, todo, todo o que existe dentro da intranet corporativa.
Que fai un administrador de sistemas nunha empresa? Ademais do traballo de administración desta intranet tan corporativa, adoita soportar a carga das preocupacións económicas para garantir a operatividade dos equipos de oficina. O administrador é o mesmo tipo que arrastrará rapidamente unha nova unidade do sistema ou un portátil de reposto listo para o seu uso desde o lavadoiro, entregará un teclado novo e arrastrará a catro patas polas oficinas, estirando o cable Ethernet. Un administrador é un propietario local e gobernante non só dos servidores internos e externos, senón tamén dun executivo empresarial. Si, algúns administradores só poden traballar no plano do sistema, sen hardware. Deben estar separados nunha subclase separada de "administradores de sistemas de infraestruturas". E algúns están especializados no servizo exclusivamente de equipos ofimáticos, afortunadamente, se a empresa ten máis de cen persoas, o traballo nunca remata. Pero ningún dos dous son devops.
Quen son os DevOps? Os devops son rapaces que falan da interacción do desenvolvemento de software coa infraestrutura externa. Máis precisamente, os devops modernos están implicados nos procesos de desenvolvemento e despregamento moito máis profundos que os administradores que simplemente cargaron actualizacións a ftp. Unha das tarefas fundamentais dun enxeñeiro de DevOps agora é garantir un proceso de interacción cómodo e eficazmente estruturado entre os equipos de desenvolvemento e a infraestrutura do produto. Son estas persoas as que se encargan de implementar sistemas de retroceso e implantación; son estas persoas as que quitan parte da carga aos desenvolvedores e se concentran o máximo posible na súa tarefa extremadamente importante. Ao mesmo tempo, os devops nunca executarán un cable novo nin emitirán un novo portátil desde a sala de atrás (c) KO
Cal é a trampa?
Á pregunta "Quen é DevOps?" a metade dos traballadores do campo comezan a responder algo así como “Pois, en fin, este é o administrador quen...” e máis alá no texto. Si, unha vez, cando a profesión de enxeñeiro DevOps xurdía dos administradores máis talentosos en canto ao mantemento do servizo, as diferenzas entre eles non eran obvias para todos. Pero agora, cando as funcións dos devops e do administrador no equipo se fan radicalmente diferentes, é inaceptable confundilos entre eles, ou incluso igualarlos.
Pero que significa isto para as empresas?
Contratar, é todo.
Abre unha vacante de "Administrador de Sistemas" e os requisitos que se enumeran son "interacción co desenvolvemento e os clientes", "Sistema de entrega CI/CD", "mantemento dos servidores e equipos da empresa", "administración de sistemas internos", etc. on; entendes que o empresario está a dicir tonterías. O problema é que, en lugar de "Administrador do sistema", o título da vacante debería ser "Enxeñeiro de DevOps" e, se se cambia este título, todo queda no seu lugar.
Non obstante, que impresión se produce ao ler unha praza así? Que a empresa busca un operador de varias máquinas que despregue tanto un sistema de control de versións como un sistema de vixilancia e que aprete o twister cos dentes...
Pero para non aumentar o grao de drogodependencia no mercado laboral, abonda con chamar as prazas polos seus nomes propios e comprender claramente que un enxeñeiro de DevOps e un administrador de sistemas son dúas entidades diferentes. Pero o desexo irrefreable dalgúns empresarios de presentar a lista de requisitos máis ampla posible a un candidato leva a que os administradores de sistemas "clásicos" deixen de entender o que está a suceder ao seu redor. Que, a profesión está mutando e están atrás dos tempos?
Non non e unha vez máis non. Os administradores de infraestruturas que xestionarán os servidores internos da empresa, ou ocuparán postos de apoio L2/L3 e axudarán a outros empregados, non se foron nin van.
Estes especialistas poden converterse en enxeñeiros de DevOps? Por suposto que poden. De feito, este é un entorno relacionado que require habilidades de administración do sistema, pero ademais diso, engádese o traballo con sistemas de monitorización, entrega e, en xeral, unha estreita interacción co equipo de desenvolvemento e probas.
Outro problema de DevOps
De feito, todo non se limita só á contratación e á confusión constante entre administradores e devops. Nalgún momento, a empresa enfrontouse ao problema de entregar actualizacións e a interacción do equipo de desenvolvemento coa infraestrutura final.
Quizais foi cando un tío con ollos brillantes levantouse no escenario dunha conferencia e dixo: "Facemos isto e chamámoslle DevOps. Estes mozos resolverán todos os teus problemas" - e comezou a contar o boa que é a vida na empresa despois de implementar as prácticas de DevOps.
Non obstante, non é suficiente contratar un enxeñeiro de DevOps para que todo funcione como debería. A empresa debe sufrir unha transformación completa de DevOps, é dicir, o papel e as capacidades do noso DevOps tamén deben entenderse claramente por parte do equipo de desenvolvemento e proba de produtos. Temos unha historia "marabillosa" sobre este tema que ilustra plenamente toda a brutalidade que está a suceder nalgúns lugares.
Situación. Requírese DevOps para implementar un sistema de recuperación de versións sen profundar realmente en como funcionará. Supoñamos que dentro do sistema Usuarios hai campos separados para nome, apelidos e contrasinal. Sae unha nova versión do produto, pero para os desenvolvedores, unha "reversión" é só unha variña máxica que arranxará todo e nin sequera saben como funciona. Así, por exemplo, no seguinte parche os desenvolvedores combinaron os campos de nome e apelidos, lanzárono á produción, pero a versión é lenta por algún motivo. Que pasa? A dirección chega aos devops e di "Pull the switch!", é dicir, pídelle que volva á versión anterior. Que fai os devops? Volve á versión anterior, pero como os desenvolvedores non querían descubrir como se fixo esta recuperación, ninguén lle dixo ao equipo de devops que a base de datos tamén debía ser restaurada. Como resultado, todo falla para nós e, en lugar dun sitio web lento, os usuarios ven un erro "500", porque a versión antiga non funciona cos campos da nova base de datos. Devops non sabe disto. Os desenvolvedores están en silencio. A dirección comeza a perder os nervios e o diñeiro e lembra as copias de seguridade, ofrecéndolles retirarlas para que "polo menos algo funcione". Como resultado, os usuarios perden todos os seus datos durante un período de tempo.
As noces, por suposto, van aos devops, que "non fixeron un sistema de retroceso axeitado", e a ninguén lle importa que os alces desta historia sexan desenvolvedores.
A conclusión é sinxela: sen un enfoque normal de DevOps como tal, de pouco serve.
O principal que hai que lembrar: un enxeñeiro de DevOps non é un mago, e sen comunicacións de calidade e interacción bidireccional co desenvolvemento, non fará fronte ás súas tarefas. Os desenvolvedores non poden quedar sós cos seus "problemas" ou recibir o comando "non se entromete cos desenvolvedores, o seu traballo é codificar" e despois esperar que nun momento crítico todo funcione como debería. Non é así como funciona.
Esencialmente, DevOps é unha competencia na fronteira entre xestión e tecnoloxía. Ademais, está lonxe de ser obvio que debería haber máis tecnoloxía que xestión neste cóctel. Se realmente queres crear procesos de desenvolvemento máis rápidos e eficientes, debes confiar no teu equipo devops. Coñece as ferramentas adecuadas, puxo en marcha proxectos similares, sabe como facelo. Axúdao, escoita os seus consellos, non intentes illalo nalgún tipo de unidade autónoma. Se os administradores poden traballar por si mesmos, entón os devops son inútiles neste caso; non poderán axudarche a mellorar se ti mesmo non queres aceptar esta axuda.
E unha última cousa: deixar de ofender aos administradores de infraestruturas. Teñen a súa propia, moi importante fronte de traballo. Si, un administrador pode converterse en enxeñeiro de DevOps, pero isto debería ocorrer a petición da propia persoa e non baixo presión. E non hai nada de malo no feito de que un administrador do sistema queira seguir sendo administrador do sistema: esta é a súa profesión separada e o seu dereito. Se queres sufrir unha transformación profesional, non debes esquecer nunca que terás que construír non só habilidades tecnolóxicas, senón tamén de xestión. Probablemente, será a ti como líder reunir a todas estas persoas e ensinarlles a comunicarse no mesmo idioma.
Fonte: www.habr.com