¿Por qué el desarrollo se opone a las operaciones?

Todavía soy estudiante, pero no conozco las operaciones y mi inglés sigue siendo malo.

Mi pregunta es: ¿Por qué el desarrollo se opone a las operaciones ? ¿Cuándo el desarrollo se opone a las operaciones?

El objetivo de DevOps es que el desarrollo no debería oponerse a las operaciones, sino que deberían apoyarse mutuamente.

Tradicionalmente, debido a los despliegues en cascada y las actualizaciones a gran escala, el desarrollo causaría a las operaciones una variedad de problemas durante el despliegue debido a pruebas inadecuadas, cambios en los entornos del servidor, la lista sigue y sigue. Esencialmente, las actualizaciones fueron demasiado grandes para que el equipo de operaciones pudiera implementarlas de manera efectiva sin que surjan algunos problemas en el proceso. Estos problemas podrían ser la razón por la que cree que el desarrollo se opone a las operaciones .

Por otro lado, DevOps trabaja para reducir el tamaño de la actualización, disminuir los entornos rígidos y, en general, mejorar la transferencia de la aplicación entre el desarrollo y las operaciones al aumentar la cantidad de veces que ocurre la transferencia cada año. Con el aumento en el número de implementaciones, vienen menos dolores de cabeza para las operaciones, ya que han automatizado una gran cantidad de trabajo requerido para actualizar los productos, o mejor anticipan y se preparan para las actualizaciones.

Tldr: DevOps tiene como objetivo anular la teoría de que el desarrollo se opone a las operaciones mediante la creación de una mentalidad donde las operaciones y el desarrollo trabajan juntos para implementar con frecuencia productos de manera oportuna y fácilmente reproducible.

Creo que ya obtuviste algunas respuestas completas, pero dijiste que tu inglés no es bueno, así que intentaré darte una respuesta muy breve y comprensible:

• El objetivo principal del desarrollo es hacer cambios.
• El objetivo principal de las operaciones es mantener el entorno estable.

Estas dos cosas entran en conflicto. Dicho esto, el desarrollo y las operaciones no deben oponerse entre sí. Deben trabajar juntos para asegurarse de que se puedan alcanzar ambos objetivos. Este es el propósito de DevOps.

La tensión entre el desarrollo y las operaciones a menudo es causada por la desalineación de los incentivos y los intentos de optimización dentro del equipo.

Los desarrolladores a menudo son juzgados por la velocidad y la cantidad de problemas que pueden superar y fusionarse en el repositorio de código y su recompensa a menudo no está vinculada a que el código realmente funcione o funcione correctamente. Mucho menos escala, rendimiento y otros factores.

Las operaciones a menudo se juzgan por la estabilidad del entorno y qué tan bien funciona el código en la producción, pero rara vez por la calidad del proceso para introducir cambios rápidamente.

Esto crea el problema de que los desarrolladores están incentivados para crear una gran cantidad de código y arrojarlo por la pared al equipo de operaciones y el equipo de operaciones tiene incentivos para aceptar el menor cambio posible para garantizar la estabilidad del entorno.

DevOps es en cierto modo el conjunto de soluciones a este problema:

• Algunos de ellos pueden ser organizacionales, donde los procesos e incentivos de los equipos pueden cambiar. Por ejemplo, si el trabajo de los desarrolladores solo se marca como terminado cuando se ha estado ejecutando en producción durante algún tiempo, no hubo problemas y el equipo de operaciones acuerda hacerse cargo del código. Del mismo modo, las operaciones se pueden juzgar más en función de la velocidad con la que se acepta el código, mientras que el entorno aún se encuentra dentro de algunos límites de estabilidad.
• Otra parte de la solución puede ser la comunicación y la polinización cruzada, donde se integran las personas de operaciones en el equipo de desarrollo y viceversa. Rompe el muro entre esos equipos y los ingenieros de DevOps a menudo son el resultado de este tipo de puente.
• Las herramientas que respaldan procesos como la integración continua y la implementación continua son otra parte de la solución, que puede aumentar la velocidad de los cambios, al tiempo que conserva la alta calidad y la recuperación rápida del entorno de producción en caso de cualquier problema a través de la reversión del código o el rápido progreso de una solución en producción

La mayoría de las organizaciones se enfrentan a la complejidad dividiendo su organización en partes funcionales y exigiendo que cada parte descubra cómo mejorar. Esto a menudo se llama el enfoque "silo".

Es importante comprender por qué este enfoque de silo bloquea el éxito del negocio y, a menudo, no mejora la organización en su conjunto. Y no solo afecta el desarrollo y las operaciones: afecta a todos los demás silos funcionales dentro de una organización grande, como el equipo de garantía de calidad, las finanzas, la gestión de productos y proyectos.

A medida que se ordena a los gerentes de cada silo funcional que mejoren recortando costos o aumentando la velocidad, su reacción a menudo es:

• Estoy totalmente abrumado solucionando problemas del último esfuerzo de mejora. Déjame solo.
• ¿Qué quiere que haga, cumpla con mis responsabilidades o trabaje en proyectos de mejora? No tengo tiempo para hacer las dos cosas.
• ¡No otra vez! Aquí viene otro programa del mes.

Con estas reacciones típicas, cualquier ejecutivo que lanza un esfuerzo de mejora menor rara vez es recibido con entusiasmo. Los gerentes se encuentran en una competencia feroz con otras áreas funcionales sobre los recursos necesarios para ejecutar sus mejoras. Entonces, ¡no es de extrañar que el comando para mejorar intensifique las batallas interfuncionales!

Incluso cuando un gerente completa su parte de un proyecto de mejora, luego se encuentra con otras áreas funcionales y otras organizaciones (proveedores, contratistas, etc.) que no hicieron su trabajo. Esto disminuye o niega totalmente los resultados.

Esta tensión interfuncional no se limita a los esfuerzos de mejora. Está en el corazón mismo de la toma de decisiones cotidianas y el juicio de la efectividad de la gestión en toda una organización. Aquí hay un ejemplo de la vida real:

A un gerente de finanzas se le dijo, "mejora". Decidió bloquear la contratación de contratistas que cuestan más que el precio nominal aceptado en el mercado. Implementó la nueva política y afirmó haber ahorrado $ 1 millón de dólares este año. Los desarrolladores y el departamento de TI no pueden contratar contratistas para ayudarlos a usar el contenedor y la orquestación de contenedores, ya que estos contratistas son caros. El gerente de operaciones de TI de la misma compañía calculó que no mejorar su infraestructura le costaba a la compañía más de $ 100,000 en gastos adicionales cada mes. A ese ritmo, los ahorros anuales en la contratación de contratistas se consumieron antes de que finalice el año.

Puedes imaginar que la relación entre estas dos áreas funcionales no era exactamente amorosa.

Estos conflictos interfuncionales son impulsados ​​por el enfoque del silo, donde la organización mide cada silo en mejora de forma independiente. Si usted es un centro de costos, la mejora naturalmente significa mayor eficiencia o reducción de costos dentro de su silo.

En este marco de referencia, se considera que los costos obedecen la regla "aditiva". Los costos de cada silo sumados, equivalen al costo total de la organización. Por lo tanto, los gerentes ven cualquier reducción de costos en su área como "buena", ya que ven una traducción directa al ahorro de costos para la compañía en su conjunto. En este marco de referencia, los esfuerzos de mejora se extienden por todas partes para atacar los costos y el desperdicio en toda la organización.

Un gran ejemplo cuando el / los equipo (s) de desarrollo comienzan a trabajar Agile y envían código a QA y Operaciones cada dos semanas en lugar de cada trimestre como solían hacerlo. El control de calidad y las operaciones no están listos para tal cambio y se los culpa por aflojarse. Nuevamente, esto no contribuye mucho al amor entre las personas en el desarrollo y las operaciones.