¿Cuál es el rol en DevOps para la gente de operaciones?
En un mundo DevOps, puede ser difícil saber dónde termina Dev y dónde empieza Ops. El experto Tim Western explica cuáles pueden y deben ser los diferentes roles DevOps.
Para entender el rol DevOps en una compañía, uno debe entender los problemas que debía resolver. En una empresa tradicional, el desarrollo –y posiblemente las pruebas– residía en equipos separados. Ellos trabajaban diariamente, construyendo software, lanzándolo a la pared hacia los examinadores, quienes luego daban su aprobación al estar listo para su lanzamiento. Allí era donde los «tipos de operaciones» entraban. Ellos «probarían» el lanzamiento en la medida en que probaban el despliegue para indicar entornos –eso significa todos los comandos de SQL que son ejecutados, todos los archivos zip que deben ser transferidos y extraídos, todos los DLL que necesitan ser registrados, y cada comando de instalación que necesita ser ejecutado. Luego, ellos monitorean todos los contadores de desempeño, tiempo de ejecución, uso de CPU y registros de error. Era mucho trabajo y un proceso muy manual.
Operaciones clásicas
El rol de DevOps llevó a operaciones hacia el equipo, incluyendo la propiedad de los servidores de prueba, preocupaciones sobre el despliegue y manejo del despliegue en sí mismo. Un equipo que está persiguiendo DevOps probablemente tiene la propiedad de los servidores de producción, incluyendo el monitoreo y manejo de esos servidores.
Esto se manifiesta conforme el equipo toma más responsabilidad sobre cómo construir el producto, cómo entregarlo para las pruebas, cómo transferirlo y desplegarlo para indicaciones, y luego la producción. Más adelante, también puede incluir cómo manejar la escala del producto conforme la base de clientes crece, lo que significa gestionar la infraestructura virtual y barebone en las pruebas y la producción.
¿Así que cuál es el rol DevOps para operaciones en las pruebas? El lado de operaciones de DevOps empieza con los servidores, haciendo que existan y sigan funcionando, incluyendo después de un cambio (despliegue) y al hacer realmente el despliegue. La gente tradicional de operaciones hizo mucho para gestionar y probar la infraestructura antes de un despliegue –incluyendo los ambientes de desarrollo y pruebas–, pero no les preocupaba mucho los detalles de la aplicación. Esto incluye asegurarse de que los puntos finales de la interfaz de programa de la aplicación se mantienen activos, regresan resultados significativos, están conectados a las bases de datos fuente correctas, son razonablemente rápidas y son transparentes.
El viejo término para crear un nuevo servidor era «aprovisionar»; involucraba comprar algo de un proveedor y configurarlo. La virtualización de servidores hizo esto más fácil. Los probadores pueden poner un tiquet, y los de operaciones pueden tener un servidor corriendo más tarde durante ese día o el siguiente. Con DevOps, la parte de desarrollo (programación, automatización) puede escribir código para permitir giros por demanda; los probadores pueden crear un ambiente con el clic de un botón.
Hablando de construcciones, el foco de operaciones en un rol DevOps se mantiene en hacer que las construcciones sucedan de manera más confiable, más frecuente y con alguna atención hacia la buena automatización de despliegues que hace posible no solo crear un servidor, sino actualizar los servidores existentes. También, hacen las revisiones automáticas a través de código para verificar que el despliegue haya tenido éxito. También pueden jugar un rol en el monitoreo, así como algunos de los aspectos más complejos de la gestión de configuración.
Qué significan la nube, DevOps y la velocidad del desarrollador para los equipos de operaciones
GitHub nos proporciona una lista específica de qué involucra hoy en día ser un equipo de operaciones con DevOps:
- Habilitar el autoservicio para desarrolladores. Para respaldar la velocidad del desarrollador y minimizar los riesgos que se derivan de las «operaciones en la sombra», donde los desarrolladores buscan sus propias soluciones, los equipos de operaciones trabajan más de cerca con los desarrolladores para brindar acceso a pedido a herramientas y entornos seguros y compatibles.
- Herramientas y procesos estandarizados en toda la empresa. La mejor manera de habilitar un modelo de autoservicio sostenible y empoderar a los equipos para que trabajen juntos de manera más eficiente es estandarizando las herramientas que se utilizan. Las herramientas y los procesos que se comparten en toda la unidad de negocio permiten la unidad organizativa y una mayor colaboración. A su vez, esto reduce la fricción que experimentan los desarrolladores y los equipos de operaciones al compartir responsabilidades.
- Llevar la automatización extensible a las tareas de operaciones tradicionales. A medida que los equipos de operaciones se enfocan más en capacitar a otros equipos a través del autoservicio y la colaboración, hay menos tiempo para manejar otros trabajos. Las tareas de operaciones tradicionales, como resolver incidentes, actualizar sistemas o escalar la infraestructura, aún deben abordarse, solo que de manera más inteligente. Cuando el desarrollo y las operaciones se unen bajo DevOps, los equipos de operaciones recurren a la automatización para más tareas repetibles e impulsan la coherencia en toda la organización. Esto también permite a los equipos y unidades de negocio realizar un seguimiento y medir los resultados de sus esfuerzos.
- Trabajar y enviar como desarrolladores. A medida que los equipos de operaciones cambian más hacia una mayor automatización, ‹X› como código se convierte en la nueva normalidad. Al igual que el código fuente de la aplicación, el código que controla los sistemas de operaciones debe almacenarse, versionarse, protegerse y mantenerse. Como resultado, la relación desarrollo-operaciones comienza a sentirse más equilibrada en ambos lados: los especialistas en operaciones se vuelven más como los desarrolladores y se familiarizan más con sus modelos de trabajo, y en algunas organizaciones, los desarrolladores se vuelven más como operaciones, compartiendo la responsabilidad de depurar problemas con su propio código en producción.
