Header Ads Widget

Ticker

6/recent/ticker-posts

Evite caminar sobre cáscaras de huevo y use DevOps

 

Evite caminar sobre cáscaras de huevo y use DevOps


Humpty Dumpty se sentó en una pared,
Humpty Dumpty tuvo una gran caída.
Todos los caballos del rey y todos los hombres del rey
no pudieron juntar a Humpty de nuevo .

Seguro que suena como la última vez que su sitio se cayó y todos los equipos de la oficina comenzaron a entrar en pánico, ¿verdad?

Cuando las cosas van mal, todo el mundo empieza a señalar con el dedo. “Los desarrolladores dicen que es un problema del servidor, TI dice que es un problema de código. Es un caos absoluto ”, dice Emily Dowdle, de Wazee Digital.

¿La verdad real? Nadie está muy seguro de qué pasa. De lo contrario, ya estarían haciendo lo necesario para solucionar el problema y volver a poner el sitio en línea. En muchos casos, el problema es la falta de comunicación : la persona A sabe algo que la persona B no sabe y eso impide que la persona B encuentre una solución.

La idea detrás de DevOps es que facilitar las interacciones entre los equipos, en particular el desarrollo, las operaciones y el control de calidad, puede aliviar parte de ese caos.

Los silos son malos para los negocios

Hay un problema con el lugar de trabajo moderno del que no habla mucha gente. Es decir, que todo el mundo trabaja en silos . Y, donde ese es el caso, ninguna cantidad de ejercicios de trabajo en equipo o espacio de oficina abierto cambiará las cosas.

Hablemos de desarrolladores y operaciones : no siempre se llevan bien. Emily Dowdle, de Wazee Digital, describe la situación así:

"Hay tensión, podría describirse como una fricción o una actitud ... una incapacidad general para tolerarse sin poner los ojos en blanco y suspiros audibles".

Ella habla de cómo el lado de Operaciones se evalúa no por las características que lanzan, como lo hacen los desarrolladores, sino por parámetros cuantificables como el tiempo de actividad del sitio. Los equipos de operaciones se esfuerzan por lograr un tiempo de actividad de cinco nueves (o mejor), es decir, un sitio que está activo el 99,999% del tiempo , lo que equivale a 5 minutos al año de tiempo de inactividad.

“Fundamentalmente, tenemos diferentes prioridades. Significa que tenemos conflicto, nos enfrentamos. No es de extrañar que seamos enemigos naturales ".

Pero no tiene por qué ser así.


Vea a Emily Dowdle de Wazee Digital inculcar la mentalidad de DevOps en la Cumbre de Plataformas de APIs nórdicas 2016

Conceptos clave de DevOps

Con el aumento del desarrollo ágil , que, por supuesto, da como resultado lanzamientos más frecuentes, adoptar DevOps como concepto no solo es una ventaja, sino una necesidad.

Pero, como "big data", "desarrollo ágil" y otros mots du jour, DevOps es un concepto tan grande, a menudo mal definido, en el que es fácil perderse.

Dowdle tiene algunas ideas para la implementación práctica de DevOps en el lugar de trabajo:

1. Cerrar la brecha de habilidades

Reconocer que los equipos de desarrollo y operaciones no funcionan de la misma manera y que no tienen las mismas prioridades es clave para realizar cambios.

Ningún desarrollador llegará a comprender por completo los entresijos de las operaciones, y viceversa, pero algo de comprensión de por qué el otro equipo querría adoptar un enfoque determinado es extremadamente valioso.

2. Compartir información

Todo el mundo odia las reuniones, pero tienen su utilidad.

Si se está trabajando en una nueva característica , es importante para el desarrollo y las operaciones discutir la forma más segura de iterar sin romper… bueno, todo.

Por otro lado, es útil para los desarrolladores tener acceso a registros de solo lectura que les permitan ver el impacto de sus implementaciones y cualquier otro cambio que hayan realizado. Agregar ChatOps , llamado así por GitHub, podría ser un medio para mejorar la comunicación entre equipos.

3. Coherencia

Ya sea que estemos hablando del proceso de implementaciones en sí, que debería ser un proceso tan intuitivo que cualquier miembro del equipo pueda hacerlo, o qué tan cerca un área de preparación replica su equivalente en vivo, la consistencia es clave.

Hacer cambios pequeños e incrementales, no más lanzamientos de funciones infladas, es la mejor manera de asegurarse de que todo se mantenga reconocible mientras se avanza con los cronogramas de desarrollo.

La integración / entrega continua está, como hemos escrito antes , aquí para quedarse. Una piedra angular del desarrollo ágil, también es increíblemente útil para tratar de mantener las cosas lo más consistentes posible.

4. Mayor responsabilidad

En la mayoría de los lugares de trabajo, los equipos a veces son culpables de pasar la pelota.

Los equipos de ventas y marketing pueden cerrar acuerdos en proyectos que técnicamente aún no existen en el producto (¡pero los desarrolladores pueden encargarse de todo eso!), Mientras que los desarrolladores pueden realizar una implementación que realmente necesita más control de calidad para cumplir con una fecha límite.

Incluir a los desarrolladores en la rotación de guardia, es decir, involucrarlos en la conversación de las 4 am "el sitio está caído", es un ejemplo de una forma de cambiar la forma en que los desarrolladores piensan sobre las implementaciones.

Una vez más, esto es tanto una cuestión de cultura como de proceso: en su presentación, Dowdle habla sobre el miedo a que las cabezas se muevan cuando algo sale mal, y ese miedo hace que la gente quiera desviar la responsabilidad.

Asegurarse de que todos estén al día con las mejores prácticas (por ejemplo, seguridad) en el lugar de trabajo es clave, pero es igualmente vital asegurarse de que los empleados puedan hacer su trabajo sin preocuparse de que un error les cueste.

5. Acepta el fracaso

Pensemos un poco más en esos errores. ¿Entonces el sitio se cayó? Eso es malo. Pero no tiene por qué ser el fin del mundo.

Es más importante averiguar qué salió mal, con qué alertas automáticas pueden ayudar seriamente y descubrir cómo asegurarse de que no vuelva a suceder. Asignar culpas personales no es útil, pero permitir que un equipo vea dónde se equivocaron definitivamente sí lo es.

Esperar errores o accidentes y prepararse para ellos, y no establecer objetivos de tiempo de actividad poco realistas del 99,99999%, puede ayudar a aliviar algo de la tensión entre el desarrollo y las operaciones.

Si (o tal vez debería ser cuando) realiza una autopsia de lo que salió mal, averiguar por qué y de quién fue la culpa, sin muchos señalamientos, es la mejor manera de asegurarse de que no vuelva a suceder.

Si disfrutas esta pieza, definitivamente echa un vistazo a nuestro libro electrónico gratuito: DevOps basado en API

DevOps y API

Algunos de los problemas descritos anteriormente se vuelven aún más importantes cuando las API se agregan a la mezcla: según Dowdle, en la mayoría de los casos de problemas de API, habrá al menos dos equipos de desarrollo y dos equipos de producción en la mezcla.

En ese sentido, las API en realidad ofrecen un gran punto de partida para un enfoque que toma DevOps más en serio; Cuando se trata de crear una gran API, los creadores desean evitar problemas porque saben que inevitablemente se involucrarán varios equipos.

Eso es especialmente cierto si hablamos de una API pública, en la que las operaciones y las pruebas son incluso más críticas que una diseñada para uso interno.

Como resultado, lo siguiente es clave para el desarrollo exitoso de la API:

  • Un enfoque muy específico de los requisitos, por ejemplo, parámetros, códigos de respuesta, etc.
  • Documentación completa para analizar una serie de problemas potenciales
  • Necesidad de marcos de prueba rígidos que funcionen exactamente como lo que está en vivo

Lo que los desarrolladores de API no necesariamente se dan cuenta es que todo lo que han aplicado al desarrollo de su API es la receta perfecta para un enfoque equilibrado al estilo DevOps para crear una oferta de software central también.

Entonces, la próxima vez que trabaje con su equipo en una nueva función, hágase la siguiente pregunta: "¿Así es como lo haríamos si hiciéramos cambios en nuestra API?" Si la respuesta es no, es posible que los conceptos anteriores le resulten útiles.

Dowdle no lo dice directamente, pero su fuerte enfoque en la documentación, la comunicación interdisciplinaria y la paridad entre entornos significa que es difícil no llegar a esta conclusión: la forma en que construimos API es un modelo de efecto para todo el ecosistema de software.

Guías para la gestión del desarrollo de API

Los desarrolladores de API no siempre tienen las mismas libertades que los desarrolladores de software tradicionales. O tal vez deberíamos expresarlo de otra manera: el desarrollo de API generalmente está dirigido por comentarios y requisitos, o una acumulación de productos.

En algunos, ¡pero no en todos! En los lugares de trabajo, los desarrolladores hacen adiciones en función de lo que marketing / ventas les pide que agreguen, qué características ELLOS creen que debería tener un producto y, a veces (seamos honestos aquí), las tendencias de esa semana en HackerNews o Reddit.

Consideremos los siguientes tres diagramas para modelos de desarrollo ligeramente diferentes:

Accenture-devops-deployment-schedule

Diagrama de DevOps de Accenture [ Fuente ]

teorías-de-integración-continua-de-ibm

Proceso de integración continua de IBM [ Fuente ]

microsoft-devops-management

Ciclo de gestión de desarrollo de Microsoft [ Fuente ]

El primero de los diagramas anteriores es un enfoque de DevOps para crear y probar características de API descritas por Brajesh De, de Accenture , y los dos últimos muestran enfoques de DevOps de integración / entrega / retroalimentación continuos utilizados en IBM y Microsoft, respectivamente.

Notará que, si bien el orden exacto y los detalles pueden ser un poco diferentes, las ideas generales son muy similares: los requisitos se diseñan, implementan, prueban y se recopilan comentarios, combinando los lados de desarrollo y operación en sincronía.

El hecho de que el marco de gestión de API de Accenture sea tan similar a otras plantillas de DevOps solo parece promover la idea de que el enfoque adoptado durante el desarrollo de la API, que normalmente implica pruebas rigurosas y comentarios continuos de Operaciones y / o de aquellos que usan la API, ofrece de manera efectiva un modelo de DevOps valioso.

Lea también: Cómo manejar la entrega continua de microservicios

Poniendo a Humpty nuevamente juntos

La conclusión es que gran parte de esto se reduce a la cultura: un enfoque DevOps , o uno que imita el estilo de desarrollo de API, no tendrá éxito si sus equipos de Desarrollo y Operaciones no están dispuestos a cooperar.

La mentalidad de DevOps no es nueva, pero es una que, si bien es muy valiosa, puede ser difícil de adoptar debido a problemas de coordinación o estructura de la empresa. Aún así, es uno que es cada vez más importante a medida que el desarrollo ágil y la entrega continua y la retroalimentación continua se vuelven la norma.

Adoptar un enfoque que funcione es aún más crítico cuando se trata de API porque, cuando el desarrollo de API se realiza mal, no es solo su propio negocio el que está en riesgo; también está comprometiendo los negocios de todos los que usan su API.

Y si hay algo más difícil que volver a armar a Humpty, es volver a armar a miles de Humpty con una multitud enojada gritándote todo el tiempo.

Publicar un comentario

0 Comentarios