Menú

Colaboración en DevOps

collaboration devops

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

Colaboración en DevOps:

Pequeños incrementos de entregas en DevOps se explicó en detalle en nuestro tutorial anterior.

Sabemos que el mantra clave de DevOps es la colaboración y, de ahí, llegó la palabra DevOps.

Leer a través => Tutoriales detallados de DevOps

La colaboración consiste en unirnos como un solo equipo para abordar cualquier problema del programa, que entorpezca el programa de tener en cuenta el enfoque en el cliente y resolverlos haciéndolos dueños como su propio problema lo más rápido posible, sin ningún juego de culpas.

Colaboración en DevOps

La colaboración enseña a todos a hablar entre ellos, a encontrarse cara a cara, a involucrarse en sus reuniones, discusiones, a comprender las tareas de los demás, a la dependencia y a tener transparencia en el trabajo y a trabajar de forma proactiva para prevenir los problemas.

VIDEO Parte 2 Bloque 5: Colaboración - 15 minutos 36 segundos

Transcripción:

El término colaboración se repite una y otra vez en DevOps y el mantra de Devops es colaboración. Entonces, entendamos qué significa realmente 'colaboración' en el contexto del desarrollo de software y DevOps.

Según yo, tan pronto como una organización dice que estamos implementando DevOps, automáticamente el pensamiento de colaboración que se adjunta a la práctica de devops se inicia en la mente de todos y los hace más enfocados y alertas hacia la colaboración y comienzan a sentir que necesitan colaborar. . Esa es la magia de la colaboración.

Por lo tanto, iniciar la colaboración DevOps desde el comienzo del proyecto es muy esencial para la organización y el equipo. Me refiero al equipo, miembros del equipo del programa.

Voy a explicar un par de casos en los que he visto a Dev colaborar con Operaciones y operaciones colaborando con el equipo de desarrollo para que sepamos lo que realmente significa colaborar en el contexto de DevOps.

Esta es la representación de la instancia uno.

Hubo una instancia en la que hubo un problema desconocido en el script de instalación o en el script de configuración que el equipo de operaciones estaba encontrando un desafío al instalar el software en una configuración particular de un clúster en una geografía particular.

Preguntas y respuestas de la entrevista de Oracle pl / sql por 7 años de experiencia

Estaba arrojando un error desconocido y era un problema de producción puro, que nunca ocurrió en el entorno de desarrollo y el equipo de operaciones realmente dedicó mucho esfuerzo a resolverlos por sí mismos pensando que es algo relacionado con la configuración, y que necesitan resolver que no se resolvió durante bastante tiempo.

Luego, de inmediato, el equipo de desarrollo intervino sin ni siquiera haber sido invitado a ayudar, aunque la zona horaria era diferente, tomó el control del sitio de producción, usted sabe que generalmente el acceso a la producción no se le dará a todos, Ops solo comparte el error detalles o cualquier otra información que el equipo necesite para fines de depuración.

Pero esta situación es necesaria para dar acceso a uno de los miembros del equipo de desarrollo, que dedicó unas horas a analizar el problema en vivo y proporcionó una solución inmediata y, por lo tanto, el problema se resolvió rápidamente.

Esta es la instancia de la colaboración en la que el equipo de desarrollo asumió voluntariamente el problema y ayudó al equipo de operaciones a resolverlo. Este es un ejemplo puro de colaboración.

De manera similar, en otra instancia, permítanme mostrar eso esquemáticamente, que he dibujado. Otro caso es que las cosas estaban funcionando bastante bien después de la actualización del software en un sitio en particular durante unos días, de repente, el rendimiento de la aplicación comenzó a disminuir.

Los usuarios finales comenzaron a enfrentar graves pérdidas transaccionales debido a esta desaceleración. Comenzaron a llegar muchas llamadas de reclamos a los representantes de servicio al cliente de CSR, es decir, y ellos, a su vez, comenzaron a hacer un seguimiento con el equipo sobre el tema.

En este caso, inmediatamente tanto el equipo de desarrollo como el de operaciones se reunieron, y con la información y los detalles de telemetría proporcionados por el equipo de operaciones al equipo de desarrollo, pudieron depurar el problema e identificar que había algún problema en el aspecto de carga compartida y por lo tanto, el rendimiento fue lento.

Entonces, ambos equipos trabajaron juntos para solucionar el problema y volver a la normalidad en unas pocas horas. Entonces, aquí, tanto el desarrollador como el de operaciones juntos se dieron a conocer y colaboraron juntos para resolver el problema en lugar de que el desarrollador dijera su problema de operaciones y el de operaciones pensara que es un problema de desarrollo y el equipo de desarrollo debe analizarlo y solucionarlo.

implementar el árbol de búsqueda binaria en java

Este es el ejemplo claro de colaboración en el que todos son dueños de los problemas, en lugar de jugar el juego de la culpa, independientemente de quién sea el problema o perder el tiempo para descubrir de quién es el problema, teniendo en cuenta que el usuario final está sufriendo y el problema necesita se arreglará pronto.

Entonces, nuevamente aquí, el problema no tiene que ser solo de producción, podría ser cualquier simple problema de desarrollo de software interno, tan simple como el problema del día a día, o un problema de diseño, o un problema de arquitectura, o incluso un simple problema de la herramienta.

Cualquier problema relacionado con el programa o cualquier problema que el equipo sepa que está causando daños al cliente o ralentizando el programa debe ser propiedad de todos, en lugar de aislar el problema de que es un problema de desarrollo o un problema de operaciones o un problema de prueba. y contribuir a abordarlo lo antes posible, es una colaboración.

Entonces, la colaboración en el contexto de DevOps es que el desarrollo y las operaciones se unen y trabajan juntos para resolver el problema lo antes posible, teniendo en cuenta el enfoque del cliente.

La colaboración es tanto para el desarrollo como para las operaciones de lo que está sucediendo en vivo, el monitoreo y el registro y la verificación del rendimiento están en la cima para resolver el problema que ocurre especialmente en la producción en interés del usuario final.

O simplemente, puedo decir, que todo el equipo, trabajando constantemente en conjunto para resolver el problema para lograr los objetivos del programa, teniendo en cuenta el enfoque al cliente es la colaboración. Repito, trabajar juntos constantemente para resolver los problemas con el fin de lograr los objetivos del programa teniendo en cuenta el enfoque del cliente es la colaboración.

Entonces surge una pregunta, ¿cómo desarrollamos esta colaboración y cuándo debemos iniciar la colaboración entre el equipo, que está sentado a millas de distancia el uno del otro?

Obviamente, sabemos que tanto Dev como Ops no pueden coubicarse. El equipo de operaciones debe estar más cerca del sitio de trabajo o los centros de datos, y el desarrollador debe estar más cerca del centro de desarrollo de software. Entonces, ¿cómo logramos la colaboración constante entre ambos equipos?

En primer lugar, iniciar la colaboración DevOps desde el principio del proyecto es muy esencial para la organización y el equipo. El equipo al que me refiero aquí, son los miembros del equipo del programa.

Practicar un par de las siguientes cosas ayudaría a cerrar la brecha entre el equipo y superar las limitaciones de los equipos virtuales y ayudaría a lograr la colaboración.

Entonces, veamos cuáles son esas prácticas que ayudan a lograr la colaboración.

Involucrar al Desarrollo en todas las reuniones y discusiones relevantes del equipo de Operaciones y viceversa.

Esto no solo los une, sino que también ayuda a comprender cada una de sus áreas de trabajo, sus problemas del día a día y cómo su trabajo se está impactando entre sí, y cuáles son las cosas críticas de las que cada uno debe ocuparse para evitar los problemas más adelante y por lo tanto, los acerca e inicia una discusión cómoda entre ellos cada vez.

Antes de la introducción de la práctica de DevOps, el equipo de desarrollo nunca solía preocuparse por la entrega del software a Operaciones. Sabes que solían ser ignorantes o nunca se preocupaban por cosas como infraestructura, configuraciones, configuraciones de servidor, configuraciones de red, monitoreo de presentaciones en vivo, etc.

Solían pensar que todas estas actividades son responsabilidad del equipo de Operaciones y el equipo de desarrollo nunca solía saberlo. Anteriormente, la entrega para el equipo de desarrollo tenía la intención de entregarse solo al equipo de operaciones, pero con la práctica de DevOps, la entrega significa para la producción y no solo para las operaciones.

Del mismo modo, a las operaciones nunca les importaba el código que estaba produciendo el equipo de desarrollo. Cualquier problema al que se enfrentan durante la instalación del software, la funcionalidad o los problemas de rendimiento en la producción, simplemente solían pasar la pelota al equipo de Desarrollo y pedirles que la arreglen y la devuelvan.

Por lo tanto, conocer el trabajo de los demás y comprender su tarea y reconocer el problema de los demás a lo largo del ciclo ayuda al equipo a resolver los problemas rápidamente.

Porque saben dónde está el problema y qué está sucediendo en el programa y qué está causando el problema en la producción y, por lo tanto, pueden ir directamente y solucionarlo sin mucha dificultad.

Por lo tanto, la colaboración significa que el equipo de desarrollo debe comprender la infraestructura y la configuración, y el equipo de operaciones debe preocuparse por el código, la calidad, la entrega y los plazos.

Comprender la dependencia mutua ayudará a acelerar el trabajo y entregarlo a tiempo.

Al igual que durante la instalación del software, el equipo de operaciones depende de un equipo de desarrollo para resolver cualquier problema relacionado con la instalación. De manera similar, mientras que la codificación del equipo de desarrollo depende de muchas condiciones previas que existen en vivo para que el equipo de operaciones las proporcione para cuidar durante el proceso de codificación.

Otro Ejemplo El equipo de prueba depende del equipo de operaciones para proporcionar muestras de datos en vivo de producción para las pruebas. Detalles de configuración del entorno que se configurarán en el entorno de desarrollo, etc.

Por lo tanto, ambos equipos deben colaborar entre sí y comprender la dependencia entre ellos y proporcionar los datos o la información a tiempo sin causar ningún retraso teniendo en cuenta el factor de la zona horaria.

Mantenga la transparencia adoptando las prácticas de DevOps como el control de fuente o el control de versiones, lo que permite al equipo comprender todo sobre el programa y ayuda a evitar malentendidos.

Entonces, básicamente se trata de mantener la transparencia dentro del equipo.

Los miembros del equipo no tienen que depender de ningún individuo o información en particular, por ejemplo, si alguien quiere saber la configuración establecida en un nodo en particular en el clúster, por lo que no necesitan esperar a que el equipo de operaciones se despierte y proporcione estos detalles, en su lugar, pueden ir a la herramienta de control de versiones y obtener esta información y pueden completar su tarea sin demora.

Aprender unos de otros, especialmente del error de los demás, es la mayor característica de la colaboración. Para que no repitan estos errores cometidos por otra persona.

Entonces, el desarrollo es aprender de la operación y las operaciones son aprender del desarrollo, ya sea una nueva tecnología, herramienta o hacer algo de una manera mejor y más simple. Donde en ambos están en la misma página y, por lo tanto, colaboran entre sí aprendiendo el uno del otro.

Las operaciones siempre solían sentir que el equipo de desarrollo es muy lento y no pueden entregar a tiempo, ahora que están interactuando con el equipo de desarrollo en el día a día, entienden qué está causando el retraso, ya sea menos claridad en el requisitos, problema de diseño, problema de codificación o cualquier otro problema de herramienta.

Incluso ellos están colaborando y brindando sus valiosas sugerencias para mejorar.

Además, en caso de cualquier problema, ya sea desde la producción o desde el sitio de desarrollo, DevOps introduce una cultura de primero solucionar el problema que tratar de averiguar quién o qué equipo ha introducido este problema. Entonces, todos tratan de concentrarse en solucionar el problema en lugar de perder el tiempo para descubrir quién causó el problema.

Por lo tanto, dejar de culpar y considerar el problema de cada uno como propio y presentarse para resolverlos juntos y apoyar el problema, apoyarse mutuamente durante sus problemas es nuevamente una colaboración.

Entonces, puedo decir, deja de culpar a los juegos, culpar a los juegos es una característica de la colaboración una vez más.

Cuando todos comienzan a pensar en común en la misma dirección, la misma mentalidad y trabajar en los mismos aspectos y prácticas, es nuevamente una colaboración como cuando se desarrolla alguna característica nueva, todos pensando en cómo probar esto, cómo implementar esto, cómo monitorear esto, es una colaboración.

Entonces, pensar en común, dentro del equipo, es una característica de la colaboración una vez más.

Tomemos un descanso ahora y entendamos un poco más sobre la colaboración en nuestro próximo video.

ejemplo de caso de prueba para pruebas manuales

PREV Tutorial | SIGUIENTE Tutorial

Lectura recomendada

^