É difícil comprender o punto principal cando se fala de DevOps? Recollemos para ti vívidas analoxías, formulacións rechamantes e consellos de expertos que axudarán incluso aos non especialistas a chegar ao punto. Ao final, a bonificación é o propio DevOps dos empregados de Red Hat.
O termo DevOps orixinouse hai 10 anos e pasou dun hashtag de Twitter a un poderoso movemento cultural no mundo das TI, unha verdadeira filosofía que anima aos desenvolvedores a facer as cousas máis rápido, experimentar e iterar cara adiante. DevOps quedou inextricablemente ligado ao concepto de transformación dixital. Pero como adoita ocorrer coa terminoloxía informática, durante os últimos dez anos DevOps adquiriu moitas definicións, interpretacións e conceptos erróneos sobre si mesmo.
Polo tanto, moitas veces podes escoitar preguntas sobre DevOps como, é o mesmo que áxil? Ou é esta unha metodoloxía especial? Ou é só un sinónimo máis da palabra "colaboración"?
DevOps inclúe moitos conceptos diferentes (entrega continua, integración continua, automatización, etc.), polo que destilar o que é importante pode ser un reto, especialmente cando che apaixona o tema. Non obstante, esta habilidade é moi útil, non importa se estás intentando transmitir as túas ideas aos teus superiores ou simplemente contando a alguén da túa familia ou amigos sobre o teu traballo. Polo tanto, deixemos de lado os matices terminolóxicos de DevOps polo momento e centrémonos no panorama xeral.
Que é DevOps: 6 definicións e analogías
Pedimos aos expertos que explicasen a esencia de DevOps da forma máis sinxela e breve posible para que o seu valor quede claro para os lectores con calquera nivel de coñecemento técnico. En base aos resultados destas conversas, seleccionamos as analoxías e as formulacións máis sorprendentes que che axudarán a construír a túa historia sobre DevOps.
1. DevOps é un movemento cultural
"DevOps é un movemento cultural no que ambas partes (desenvolvedores de software e especialistas en operacións de sistemas informáticos) recoñecen que o software non trae beneficios reais ata que alguén comeza a usalo: clientes, clientes, empregados, non o punto", di Eveline Oehrlich, investigadora senior. analista do Instituto DevOps. "Polo tanto, ambas as partes garanten conxuntamente unha entrega rápida e de alta calidade do software".
2. DevOps trata de potenciar aos desenvolvedores.
"DevOps permite aos desenvolvedores posuír aplicacións, executalas e xestionar a entrega de principio a fin".
"Normalmente, fálase de DevOps como unha forma de acelerar a entrega de aplicacións á produción mediante a construción e implementación de procesos automatizados", di Jai Schniepp, director de plataformas DevOps da compañía de seguros Liberty Mutual. "Pero para min é algo moito máis fundamental". DevOps permite aos desenvolvedores posuír aplicacións ou pezas específicas de software, executalas e xestionar a súa entrega de principio a fin. DevOps elimina a confusión de responsabilidade e guía a todos os implicados na creación dunha infraestrutura automatizada e impulsada polos desenvolvedores.
3. DevOps trata de colaborar na creación e entrega de aplicacións.
"Simplemente, DevOps é un enfoque para a produción e entrega de software onde todos traballan xuntos", di Gur Staf, presidente e xefe de automatización empresarial dixital de BMC.
4. DevOps é unha canalización
"A montaxe do transportador só é posible se todas as pezas encaixan entre si".
"Compararía DevOps cunha cadea de montaxe de coches", continúa Gur Staff. – A idea é deseñar e fabricar todas as pezas con antelación para que logo poidan ser montadas sen axuste individual. A montaxe do transportador só é posible se todas as pezas encaixan. Os que proxectan e constrúen un motor deben considerar como montalo na carrocería ou no cadro. Os que fan os freos deben pensar nas rodas, etc. O mesmo debería suceder co software.
Un desenvolvedor que crea unha lóxica de negocio ou unha interface de usuario debe pensar na base de datos que almacena a información do cliente, nas medidas de seguridade para protexer os datos dos usuarios e como funcionará todo isto cando o servizo comece a servir a unha audiencia de usuarios grande, quizais incluso multimillonaria. ."
“Conseguir que a xente colabore e pense nas partes do traballo que están a facer os demais, en lugar de centrarse só nas súas propias tarefas, é o maior obstáculo a superar. Se podes facelo, tes unha excelente oportunidade de transformación dixital", engade Gur Staff.
5. DevOps é a combinación correcta de persoas, procesos e automatización
Jayne Groll, directora executiva do Instituto DevOps, ofreceu unha gran analoxía para explicar DevOps. Segundo as súas palabras, "DevOps é como unha receita con tres categorías principais de ingredientes: persoas, procesos e automatización. A maioría destes ingredientes pódense extraer doutras áreas e fontes: Lean, Agile, SRE, CI/CD, ITIL, liderado, cultura, ferramentas. O segredo de DevOps, como calquera boa receita, é como obter as proporcións correctas e mesturar estes ingredientes para aumentar a velocidade e a eficiencia de crear e lanzar aplicacións.
6. DevOps é cando os programadores traballan como un equipo de Fórmula 1
"A carreira non está planificada de principio a fin, senón ao contrario, de final a comezo".
"Cando falo sobre o que esperar dunha iniciativa de DevOps, penso nun equipo de carreiras de NASCAR ou Fórmula 1 como exemplo", di Chris Short, director senior de mercadotecnia de plataformas na nube de Red Hat e editor do boletín informativo de DevOps. – O líder dun equipo así ten un obxectivo: ocupar o lugar máis alto posible ao final da carreira, tendo en conta os recursos dos que dispón o equipo e os retos que se lle enfrontaron. Neste caso, a carreira non está planificada de principio a fin, senón ao contrario, de final a comezo. En primeiro lugar, establécese un obxectivo ambicioso e despois determínanse as formas de logralo. Despois divídense en subtarefas e deléganse aos membros do equipo".
"O equipo pasa toda a semana antes da carreira perfeccionando a parada en boxes. Fai adestramento de forza e cardio para manterse en forma durante un día de carreira agotador. Prácticas de traballo conxunto para resolver os problemas que poidan xurdir durante a carreira. Do mesmo xeito, o equipo de desenvolvemento debería adestrar a habilidade de lanzar novas versións con frecuencia. Se tes tales habilidades e un sistema de seguridade que funciona ben, o lanzamento de novas versións en produción tamén ocorre con máis frecuencia. Nesta visión do mundo, aumentar a velocidade significa aumentar a seguridade", di Short.
"Non se trata de facer o 'correcto'", engade Short, "se trata de eliminar o máximo posible de cousas que obstaculizan o resultado desexado. Colabora e adáptase en función dos comentarios que recibas en tempo real. Estea preparado para as anomalías e traballe para mellorar a calidade para minimizar o seu impacto no progreso cara ao seu obxectivo. Isto é o que nos espera no mundo de DevOps".
Como escalar DevOps: 10 consellos de expertos
É só que DevOps e DevOps masivos son cousas completamente diferentes. Dirémosche como superar as barreiras no camiño do primeiro ao segundo.
Para moitas organizacións, a viaxe a DevOps comeza de xeito sinxelo e agradable. Créanse pequenos equipos apaixonados, substitúense procesos antigos por outros novos e os primeiros éxitos non se fan esperar.
Por desgraza, isto é só un falso brillo, unha ilusión de progreso, di Ben Grinnell, director xeral e xefe de dixital da consultora North Highland. As primeiras vitorias son certamente alentadoras, pero non axudan a alcanzar o obxectivo final da adopción xeneralizada de DevOps en toda a organización.
É fácil ver que o resultado é unha cultura de división entre "nós" e "eles".
"A miúdo, as organizacións lanzan estes proxectos pioneiros pensando que abrirán o camiño para o DevOps mainstream, sen ter en conta se outros poderán ou quererán seguir ese camiño", explica Ben Grinnell. – Os equipos para implementar este tipo de proxectos adoitan ser contratados entre "varangianos" seguros de si mesmos que xa fixeron algo semellante noutros lugares, pero que son novos na súa organización. Ao mesmo tempo, anímase a romper e destruír as regras que seguen sendo obrigatorias para todos os demais. É fácil ver que o resultado é unha cultura de "nós" e "eles" que inhibe a transferencia de coñecementos e habilidades".
"E este problema cultural é só unha das razóns polas que DevOps é difícil de escalar. Os equipos de DevOps enfróntanse a un aumento de desafíos técnicos típicos das empresas de TI de rápido crecemento", dixo Steve Newman, fundador e presidente de Scalyr.
“No mundo moderno, os servizos cambian tan pronto como xorde a necesidade. É xenial implementar e implementar novas funcións constantemente, pero coordinar este proceso e eliminar os problemas que xorden é un auténtico quebradizo de cabeza, engade Steve Newman. – Nas organizacións de crecemento moi rápido, os enxeñeiros dos equipos multifuncionais loitan por manter a visibilidade do cambio e dos efectos en cascada a nivel de dependencia que crea. Ademais, os enxeñeiros non están contentos cando se ven privados desta oportunidade e, como resultado, faise máis difícil comprender a esencia dos problemas que xorden”.
Como superar estes desafíos descritos anteriormente e pasar á adopción masiva de DevOps nunha gran organización? Os expertos piden paciencia, aínda que o seu obxectivo final sexa acelerar o ciclo de desenvolvemento de software e os procesos comerciais.
1. Lembra que o cambio de cultura leva tempo.
Jayne Groll, directora executiva do Instituto DevOps: "Na miña opinión, a expansión de DevOps debería ser tan incremental e iterativa como o desenvolvemento áxil (e igualmente afectando á cultura). Agile e DevOps fan énfase en equipos pequenos. Pero a medida que estes equipos crecen en número e integración, acabamos con máis persoas que adoptan novas formas de traballar e, como resultado, hai unha transformación cultural masiva”.
2. Dedique tempo suficiente a planificar e elixir unha plataforma
Eran Kinsbruner, evanxelista técnico líder en Perfecto: "Para que funcione, os equipos de DevOps deben aprender primeiro a combinar procesos, ferramentas e habilidades tradicionais, e despois alimentar e estabilizar lentamente cada fase individual de DevOps. Todo comeza cunha planificación coidadosa das historias de usuarios e dos fluxos de valores, seguido da escritura de software e control de versións mediante o desenvolvemento baseado en troncos ou outros enfoques máis axeitados para ramificar e fusionar código.
"Entón vén a fase de integración e proba, onde xa se require unha plataforma escalable para a automatización. Aquí é onde é importante que os equipos de DevOps elixan a plataforma correcta que se adapte ao seu nivel de habilidade e aos obxectivos finais do proxecto.
A seguinte fase é a implantación en produción e esta debería estar totalmente automatizada utilizando ferramentas e contedores de orquestración. É importante ter ambientes virtualizados en todas as fases de DevOps (simulador de produción, ambiente de control de calidade e ambiente de produción real) e utilizar sempre só os datos máis recentes para probas para obter conclusións relevantes. A analítica debe ser intelixente e capaz de procesar grandes datos con comentarios rápidos e procesables".
3. Quitar a culpa da responsabilidade.
Gordon Haff, evanxelista de RedHat: “Crear un sistema e unha atmosfera que permitan e fomenten a experimentación permiten o que se coñecen como fracasos exitosos no desenvolvemento áxil de software. Isto non significa que ninguén sexa responsable dos fallos. De feito, identificar quen é o responsable faise aínda máis sinxelo, xa que "ser responsable" xa non significa "causar un accidente". É dicir, a esencia da responsabilidade cambia cualitativamente. Catro factores vólvense críticos: o alcance da interrupción, os enfoques, os procesos de produción e os incentivos. (Podes ler máis sobre estes factores no artigo de Gordon Huff "Leccións de DevOps: 4 aspectos dos experimentos saudables").
4. Despeje o camiño cara adiante
Ben Grinnell, director xeral e xefe de dixital da consultora North Highland: "Para alcanzar escala, recomendo lanzar un programa de "desbroce de camiños" xunto con proxectos pioneiros. O obxectivo deste programa é limpar o lixo que deixan os pioneiros de DevOps, como regras obsoletas e cousas así, para que o camiño a seguir quede claro".
“Dálle á xente apoio organizativo e impulso a través dunha comunicación que vai moito máis alá do grupo pioneiro celebrando amplamente os éxitos das novas formas de traballar. Adestra ás persoas que están involucradas na seguinte onda de proxectos DevOps e están nerviosas por usar DevOps por primeira vez. E lembra que esta xente é moi diferente dos pioneiros”.
5. Democratizar ferramentas
Steve Newman, fundador e presidente de Scalyr: “As ferramentas non deben ocultarse á xente e deberían ser relativamente fáciles de aprender para quen queira dedicar o tempo. Se a capacidade de consultar os rexistros está restrinxida a tres persoas "certificadas" para usar unha ferramenta, sempre terás un máximo de tres persoas dispoñibles para xestionar o problema, aínda que teñas un entorno informático moi grande. Noutras palabras, aquí hai un pescozo de botella que pode levar a graves consecuencias (empresariais).
6. Crear condicións ideais para o traballo en equipo
Tom Clark, xefe da Plataforma Común de ITV: "Podes facer calquera cousa, pero non todo á vez. Así que establece grandes obxectivos, comeza con pouco e avanza en iteracións rápidas. Co paso do tempo, desenvolverás a reputación de facer as cousas, polo que outros tamén quererán usar os teus métodos. E non te preocupes por construír un equipo altamente eficaz. Pola contra, proporciónalles ás persoas condicións de traballo ideais e seguirá a eficiencia".
7. Non esquezas a Lei de Conway e os taboleiros Kanban
Logan Daigle, Director de Entrega de Software e Estratexia DevOps en CollabNetVersionOne: "É importante comprender as consecuencias da Lei de Conway. Na miña paráfrase vaga, esta lei establece que os produtos que creamos e os procesos que utilizamos para facelo, incluído DevOps, resultan estar estruturados do mesmo xeito que a nosa organización.
"Se hai moitos silos nunha organización e o control cambia de mans moitas veces ao planificar, construír e lanzar software, o efecto da escala será cero ou de curta duración. Se unha organización constrúe equipos multifuncionais en torno a produtos que se financian cun enfoque de mercado, as posibilidades de éxito aumentan drasticamente".
"Outro aspecto importante da escala é mostrar todo o traballo en curso (WIP, workinprogress) nos taboleiros Kanban. Cando unha organización ten un lugar onde a xente pode ver estas cousas, fomenta moito a colaboración, o que ten un impacto positivo na escala.
8. Busca vellas cicatrices
Manuel Pais, consultor DevOps e coautor de Team Topologies: "Levar as prácticas de DevOps máis aló de Dev e Ops e tentar aplicalas a outras funcións non é un enfoque óptimo. Isto certamente terá algún impacto (por exemplo, automatizando o control manual), pero pódese conseguir moito máis se comezamos por comprender os procesos de entrega e retroalimentación".
"Se hai vellas cicatrices no sistema informático dunha organización -procedementos e mecanismos de xestión que se implementaron como resultado de incidentes pasados, pero perderon a súa relevancia (debido a cambios nos produtos, tecnoloxías ou procesos)-, certamente hai que eliminalos. ou suavizadas, en lugar de automatizar procesos ineficientes ou innecesarios".
9. Non crea opcións de DevOps
Anthony Edwards, director de operacións de Eggplant: "DevOps é un termo moi vago, polo que cada equipo acaba coa súa propia versión de DevOps. E non hai nada peor cando unha organización ten de súpeto 20 variedades de DevOps que non se levan moi ben. É imposible que cada un dos tres equipos de desenvolvemento teña a súa propia interface especial entre desenvolvemento e xestión de produtos. Tampouco os produtos deberían ter as súas propias expectativas únicas para xestionar os comentarios cando se transfiren a un simulador de produción. Se non, nunca poderás escalar DevOps".
10. Predica o valor comercial de DevOps
Steve Newman, fundador e presidente de Scalyr: "Traballar para recoñecer o valor de DevOps. Aprende e non dubides en falar sobre os beneficios do que fas. DevOps é un aforro incrible de tempo e diñeiro (só pensa: menos tempo de inactividade, menor tempo medio para a recuperación) e os equipos de DevOps deben enfatizar (e predicar) incansablemente a importancia destas iniciativas para o éxito empresarial. Deste xeito, podes ampliar o círculo de adherentes e aumentar a influencia de DevOps na organización".
BONUS
En O noso propio DevOps chegará o 13 de setembro; si, Red Hat, como fabricante de software, ten os seus propios equipos e prácticas de DevOps.
O noso enxeñeiro Mark Birger, que desenvolve servizos de automatización interna para outros grupos da organización, contará a súa propia historia en ruso puro: como o equipo de Red Hat DevOps migrou as aplicacións dos contornos virtuais de Hat Virtualization xestionados por Ansible a un formato de contenedor completo en plataforma OpenShift.
Pero iso non é todo:
Unha vez que as organizacións trasladaron cargas de traballo aos contedores, os métodos tradicionais de seguimento de aplicacións poden non funcionar. Na segunda charla explicaremos a nosa motivación para cambiar a forma de rexistrar e mostraremos a continuación do camiño que nos levou aos modernos métodos de rexistro e seguimento.
Fonte: www.habr.com
