El veterano de DevOps Chris Bytaert, quien fue pionero en DevOpsDays, comparte su experiencia y sus hallazgos te sorprenderán.
Hace diez años, de repente hicimos un viaje. Reunimos a algunos de nuestros buenos amigos en Gante (Bélgica) para hablar sobre experiencias ágiles, de código abierto y de computación en la nube temprana. En 2009, John Allspoe y Paul Hammond dieron una charla en Velocity sobre "Más de 10 implementaciones al día: Colaboración de desarrollo y operaciones en Flickr" (y vale la pena verla). Después de ver esta charla, Patrick Debois decidió fundar DevOpsDays.
¿Es cierto que el mundo de DevOps ha cambiado mucho en estos 10 años? He estado asistiendo a eventos de DevOpsDays desde el inicio de la conferencia y durante este tiempo he acumulado una experiencia significativa. En esta publicación, compartiré 10 tutoriales que también pueden serte útiles.
1. No existe un ingeniero de DevOps
Muchos equipos tienen una persona con el título de DevOps Engineer, y no a todos los especialistas les gusta este título. Este nombre de profesión da la falsa impresión de que DevOps es un trabajo que puede realizar una sola persona. La mayoría de las veces, un ingeniero de DevOps es un ingeniero de Linux que, con algo de suerte, puede resolver problemas de automatización. Cuando los reclutadores comienzan a buscar un ingeniero de DevOps, los solicitantes de empleo deben hacerse las preguntas correctas: “¿Qué es lo que realmente quiere la empresa del solicitante de empleo? ¿Están buscando un ingeniero de montaje? Señora que comprende los requisitos no funcionales? ¿Un especialista en el departamento de operaciones capaz de lidiar con la automatización o alguien más? " La mayoría de las veces, las empresas buscan un especialista que distraiga al resto de los empleados del incumplimiento de los principios y requisitos prácticos de Agile.
En organizaciones con grandes departamentos de DevOps, por regla general, nadie está involucrado en DevOps. La palabra "DevOps" solo habla de separación del resto del equipo, y el solicitante puede obtener un buen salario y aprender nuevas habilidades en el trabajo, pero no "hará DevOps".
2. Los equipos de DevOps no existen
A menudo hemos dicho en el pasado que el objetivo de DevOps es eliminar la confusión entre diferentes equipos. En particular, entre desarrolladores y empleados de los departamentos operativos. Sin embargo, recientemente nos hemos encontrado con un nuevo fenómeno: la aparición de muchos equipos de DevOps.
La construcción de un equipo de DevOps parece una práctica nueva, pero aquí hay contradicciones obvias. En una organización, este equipo se ocupará de las herramientas de desarrollo, en otra, es literalmente un muro entre el equipo de desarrollo y los especialistas en operaciones. El problema es que este muro crea confusión, frustración y reduce el nivel de interacción útil. El equipo que se llama "DevOps" en el mejor de los casos resuelve una variedad de problemas y tiene cierta responsabilidad por los servicios con los que trabaja. Por lo general, los equipos profesionales prefieren no tener la palabra "DevOps" en su nombre.
En mi experiencia, tener la palabra "DevOps" en el nombre de un equipo puede dificultar el logro de los resultados deseados.
3. Los proyectos de DevOps no existen
Todos los proyectos son finitos. Desarrolla, implementa su solución y sigue adelante. Además, durante los últimos 10 años, se ha hablado de que DevOps es una mejora continua y que la mejora continua es infinita. A su vez, el resultado de sus proyectos son servicios de larga duración, y el servicio implica la secuencia "Desarrollo -> Implementación -> Soporte de salud".
Solo después de analizar los servicios fuera de los proyectos, podemos ver aspectos que se olvidan fácilmente: requisitos no funcionales. Los requisitos no funcionales incluyen funcionalidad que no se ajusta a un comportamiento específico. Estos requisitos también determinan nuestra evaluación del rendimiento del sistema. Estos requisitos a menudo incluyen aspectos que se clasifican como DevOps: confiabilidad, usabilidad, mantenibilidad y escalabilidad. Todas estas características son importantes para lograr resultados comerciales.
Al trabajar con proyectos a corto plazo, existe el riesgo de que no preste suficiente atención a este trabajo. Cuando pases al siguiente proyecto, ya no pensarás en los requisitos no funcionales del anterior, ya que asumirás nuevos retos, y el resto de problemas ya no te molestarán. A su vez, cuando gestiona un servicio, realmente se mete en el trabajo, y lo mejor para usted es pulir todo para que todo funcione sin problemas.
4. Las herramientas de DevOps no existen
Si bien muchos proveedores intentarán venderle varias herramientas, incluida una que resolverá todos sus problemas, DevOps no se trata de herramientas. DevOps se trata de personas y sus interacciones. Algunas herramientas realmente ayudan a las personas a colaborar. A menudo, las herramientas pueden ayudar a personas de diferentes orígenes a compartir la misma terminología y ecosistemas. Sin embargo, con la misma frecuencia, las herramientas se interponen en el camino de una comunicación eficaz.
Una cultura basada en herramientas puede aislar a las personas en lugar de ayudarlas a interactuar. El hecho es que la gente se obsesiona con su cadena de herramientas y se aleja de quienes no la utilizan. Si bien ciertas herramientas pueden ser muy útiles desde un punto de vista técnico, varias herramientas nuevas (denominadas convencionalmente DevOps) han ampliado la brecha entre diferentes grupos. Por ejemplo, a menudo escucho la frase "esto funciona en mi contenedor". Los desarrolladores usan esta frase para indicar que "su" trabajo está hecho. Los contenedores por sí mismos no resuelven los problemas de interoperabilidad asociados con la ejecución de aplicaciones de manera eficiente. No podemos permitir que las herramientas nos distancien unos de otros.
5. No hay certificación en DevOps.
Ninguna prueba de opción múltiple puede confirmar que usted es capaz de interactuar eficazmente con sus colegas. Las organizaciones que ofrecen certificación pueden tener una experiencia técnica increíble (e incluso una comunicación eficaz), pero la certificación no puede demostrar que alguien sea bueno en DevOps.
Desafortunadamente, los equipos de gestión requieren certificaciones en un área que es difícil de certificar. Infórmese sobre su software y hardware favoritos y explore la nube. Estudie en una universidad local, lea libros de los que pueda aprender mucho, en particular, libros de Deming , Forsgren , Humble y muchos otros... Pero no espere ser el mejor en DevOps una vez que obtenga la certificación. Interactuar con colegas es mucho más importante.
6. La canalización de DevOps no existe
"¿DevOps ya ha funcionado?", "La canalización de DevOps está funcionando". "La canalización de DevOps está rota". Siempre que escucho estas declaraciones, me sorprende que se nos ocurriera esta terminología. ¿Cambiamos el nombre de la canalización de implementación o es que en algunas empresas los equipos de DevOps están trabajando en esta infraestructura? O tal vez es porque los desarrolladores están llamando equipo operativo si la tubería está rota?
A pesar de la inmensa importancia de las tecnologías CI / CD, soy escéptico sobre el uso del término "canalización de DevOps". Si la tubería de desarrollo se rompe, entonces el equipo de operaciones tiene la culpa. Los desarrolladores no piensan en la canalización mientras escriben las pruebas. El concepto en sí mismo también es engañoso. Las canalizaciones se crean para cada servicio o aplicación por separado, en lugar de en todo el dominio de DevOps. Al crear pipelines genéricos, corremos el riesgo de aumentar la brecha entre equipos, lo que no es en absoluto el objetivo de DevOps.
Recomiendo usar una técnica que he visto en cientos de organizaciones en todo el mundo: referirse a cada canalización individual como canalización de la Aplicación X. Esta terminología facilitará saber qué aplicación tiene problemas al probar, implementar o actualizar. También sabremos qué equipo trabajará en las correcciones en el Apéndice X (posiblemente con la ayuda de amigos del equipo de operaciones).
7. DevOps no tiene estándares
La más difícil de las miles de historias de DevOps es la estandarización. De la misma manera que no podemos certificar a las personas, no existe un estándar universal en DevOps. Cada organización tiene su propio camino, y estos caminos pueden ser muy diferentes. No existe una receta mágica que enumere las herramientas y describa los métodos para crear flujos de automatización que de repente se convertirán en DevOps en su organización.
Un estándar en DevOps significa que aplicas una metodología específica que permitirá a tu organización colaborar y alejarse de la política de la oficina, también debería mejorar la calidad del trabajo, aumentar la moral y permitirte lograr mejores resultados con menos interrupciones.
DevOps debe entenderse como un conjunto de prácticas similares a la metodologíaITIL . Recuerde que la L en ITIL significa Biblioteca. Y esta biblioteca no debe tomarse como una guía para la acción, sino como una lista de las mejores prácticas, entre las que debe elegir la más adecuada para usted. ITIL fue odiado precisamente debido a implementaciones fallidas, en las que la biblioteca se usó precisamente como una instrucción paso a paso. La estandarización en DevOps conducirá a los mismos resultados.
8. DevSecOps no existe
Comenzamos DevOpsDays en 2009 y esta conferencia estuvo abierta a todos. Por supuesto, inicialmente era un evento para desarrolladores y empleados de equipos operativos, pero todos acudían a nosotros: administradores de bases de datos, testers, analistas de negocio, financieros y, por supuesto, especialistas en seguridad. En 2012, hablamos en las reuniones de OWASP , hablando de lo que hemos hecho. Bromeamos diciendo que la "S" en DevOps significa seguridad, al igual que la "S" en HTTPS.
DevOps se trata de seguridad en su esencia. Descubrí que los principios de CD se adaptan mejor a los equipos de seguridad. El CD es un requisito de seguridad: debe poder implementar en cualquier momento, esto le dará la capacidad de implementar e implementar las actualizaciones requeridas por su negocio o preocupaciones de seguridad.
Por un lado, es triste que tengamos que pensar en palabras para incluir a los responsables de la seguridad. Por otro lado, es bueno que volvamos a discutir esto. Básicamente, no hay diferencia entre DevSecOps y DevOps. La seguridad siempre ha sido parte del desarrollo y las operaciones. Puedo usar el término DevSecOps para esto, pero es mejor usar el término DevOps.
9. No puede tomar DevOps y cambiarlo
¿Alguna vez ha conocido a una empresa que haga una declaración como "Estamos haciendo un proyecto de DevOps en el cuarto trimestre de este año y el próximo año pasaremos a DevOps por completo", que realmente tuvo éxito? Así que no me he encontrado.
La entrega de software nunca se detiene, la tecnología siempre cambia, siempre necesita soporte y (idealmente) el enfoque y la actitud hacia DevOps deberían seguir siendo los mismos. Una vez que perfeccione su enfoque de entrega, querrá seguir mejorando. No porque se haya implementado toda la funcionalidad de tu aplicación o porque el ecosistema en el que vive haya dejado de desarrollarse. Querrás seguir desarrollándote porque la calidad de tu trabajo está creciendo exponencialmente y, al mismo tiempo, la calidad de vida está creciendo. DevOps seguirá evolucionando incluso después de que alguna tarea obtenga el estado Completado.
10. Existe algo llamado Dev-oops
Desafortunadamente, muchas personas no comprenden la importancia de la colaboración. Construyen muros entre equipos, creen que las herramientas son más importantes que las prácticas, requieren la certificación de todo y de todos. También creen que las 9 declaraciones anteriores son incorrectas. Y esta gente siempre luchará por tener éxito en lo que yo llamo Dev-Oops.
DevOps se trata de herramientas de pensamiento y la separación de equipos es más importante que los verdaderos principios de DevOps que pueden mejorar su trabajo. Esforcémonos por hacer DevOps, no DevOops.
el objetivo principal
Llevamos 10 años ejecutando DevOpsDays y durante este tiempo miles de personas han aprendido muchas cosas interesantes entre sí en un entorno sencillo y abierto. Algunos de los conceptos que encuentro en conflicto con los objetivos de DevOps y ágil son populares. Concéntrese en conseguir que sus servicios ayuden a su empresa y no deje de aprender. Y no se trata de copiar herramientas e implementarlas en su organización. Se trata de centrarse en la mejora continua en todos los sentidos.
Descubra los detalles de cómo obtener una profesión de alto perfil desde cero o subir de nivel en habilidades y salario tomando los cursos en línea pagados de SkillFactory:
- Curso de DevOps (12 meses)
Más cursos
- - (8 )
- UX- (9 )
- Web- (7 )
- Machine Learning (12 )
- Data Science (12 )
- (9 )
- «Python -» (9 )