En primer lugar, me gustaría enfatizar que DevOps es una cultura y no un rol. En mi opinión, uno podría compararlo con un equipo de comandos que tienen su propia experiencia, por ejemplo, francotiradores, marinos, zapadores (piense en la serie de comandos). La combinación de estas experiencias, básicamente trabajando juntas, hace posible cumplir misiones o crear valor comercial lo antes posible.
LowOps y NoOps
Desde hace un par de semanas descubrí que después de muchas conversaciones con la gente, es bastante hablar sobre LowOps en estos días. Si implemento una solución, esto significa que está completamente automatizada y que un colega puede implementar máquinas por sí mismo en lugar de preguntarme. A veces no es posible automatizarlo por completo de inmediato, pero luego me aseguro de que esté automatizado por mí mismo para asegurarme de que solo tengo que ejecutar un comando para hacer el trabajo (LowOps), en lugar de perder un par de horas. Si he creado dicha solución, me aseguro de que se haya creado un ticket para que un colega automatice mi solución personal para todos. Ejemplo: un colega mío transformó uno de mis script de bash en un bot que ahora se ejecuta todas las noches.
Figura 1: https://www.gslab.com/blog-post/what-is-noops/
"Cómo comenzar con devops"
Asegúrese de formar parte de un equipo con competencias mixtas y de que el equipo tenga que implementar el software ellos mismos. Hable con todos los miembros del equipo y comience con tareas que nadie quiere hacer ya que hay una falta de conocimiento o voluntad. Si comienzas con una tarea, te toparás con cosas que no sabes. Comience a mirar videos, asista a reuniones , compre y lea libros, lea blogs y documentación oficial sobre herramientas, solicite a sus colegas que revisen sus solicitudes de extracción y se comuniquen y escuchen bien a las personas, documenten bien las cosas y preparen y demuestren soluciones a los colegas (intercambio de conocimientos) . La última sugerencia es vigilar el equilibrio entre el trabajo y la vida .