Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

DevOps - Es Como Trabajamos

Presentación en español en Informática Habana 2018 sobre DevOps
http://www.informaticahabana.cu/en/NODE/2481

DevOps is much more about culture and organization than about technology and tools. In this talk, the speaker's experiences will be analyzed by leading high-performance engineering teams on Google, eBay and Stitch Fix, and suggestions will be offered for other organizations to level up their work with DevOps. Modern software service models take advantage of the great benefits of having the same equipment to build the software and operate it in production: "You build it, you run it" is the Amazon mantra. What does this mean in practice? Organizationally, it means small teams with well-defined areas of responsibility, directly aligned with the business. The teams are multifunctional, which means that each team has all the skill sets it needs to do its job, while at the same time it depends on other teams to support services, tools and libraries. In terms of the process, it means duplicating practices such as evidence-based development and continuous delivery. Using continuous delivery practices, high-performance teams can launch their applications and services several times a day. This allows them to iterate quickly, experiment bravely, and fail more quickly. Culturally, it means end-to-end ownership. Each team has end-to-end software, from design to development, from implementation to retirement. The same engineers who are responsible for the functions are responsible for quality, performance, operations and maintenance. This property puts the incentives in the right place to encourage the construction of sustainable, observable and operable systems from the start. All of these techniques and approaches are available to everyone, and the practical examples of this talk will help other organizations on their journey.

  • Identifiez-vous pour voir les commentaires

DevOps - Es Como Trabajamos

  1. 1. DevOps Es Como Trabajamos Randy Shoup @randyshoup linkedin.com/in/randyshoup
  2. 2. Experiencia • VP de Ingeniería en WeWork o Espacios de trabajo como servicio • VP de Ingeniería en Stitch Fix o Revolucionando la venta de ropa usando ciencia de datos y “machine learning” • Director de Ingeniería en Google App Engine o Plataforma como servicio • Ingeniero Principal en eBay o Venta
  3. 3. Maximar Valor y Minimizar Tiempo
  4. 4. ¿Velocidad vs. Estabilidad?
  5. 5. Organizaciones que usan DevOps: Resultados de Velocidad 7m 1d <1h Pobre desempeño Alto desempeño Frecuencia de despliegue 1x mes 1x día 10x día
  6. 6. Organizaciones que usan DevOps: Resultados de Estabilidad >1d <1h Pobre desempeño Alto desempeño 55% 45% 100% 0% Frecuencia de éxitos vs fallas en el despliegue
  7. 7. ¡Velocidad y Estabilidad!
  8. 8. 2.5x oportunidad de superar sus metas o Productividad o Rentabilidad o Satisfacción del cliente Organizaciones que usan DevOps: Resultados
  9. 9. DevOps Es Como Trabajamos •¿Cómo Organizamos? •¿Qué Construimos? •¿Cuándo Construimos? •¿Cómo Construimos? •¿Cómo Gestionamos?
  10. 10. DevOps Es Como Trabajamos •¿Cómo Organizamos? •¿Qué Construimos? •¿Cuándo Construimos? •¿Cómo Construimos? •¿Cómo Gestionamos?
  11. 11. Organizaciones Tradicionales Idea Desarrollo Calidad Operación
  12. 12. Equipos Completos Idea Desarrollo Calidad Operación Idea Desarrollo Calidad Operación Idea Desarrollo Calidad Operación
  13. 13. Equipos Pequeños “de Dos Pizzas” 4-6 personas “El equipo debe ser suficientemente pequeño para ser satisfecho por dos pizzas grandes.” -- Jeff Bezos, Amazon
  14. 14. DevOps Es Como Trabajamos •¿Cómo Organizamos? •¿Qué Construimos? •¿Cuándo Construimos? •¿Cómo Construimos? •¿Cómo Gestionamos?
  15. 15. ¿Cuál problema tratamos de resolver?
  16. 16. “Construir el producto incorrecto es la mayor perdida en el desarrollo de software.” -- Mary and Tom Poppendieck, Lean Software Development
  17. 17. ¿Cuál Problema Tratamos de Resolver? • Nos enfocamos en lo que es importante por la empresa • En ocasiones, el problema puede ser resuelto sin tecnología o Redefiniendo el problema o Modificando los procesos o Automatizando el proceso luego de haberlo realizado muchas veces manualmente @randyshoup linkedin.com/in/randyshoup
  18. 18. “Un problema bien definido es un problema resuelto al 50%.” -- Charles Kettering, General Motors
  19. 19. Experimentar con Disciplina • Declaramos la hipótesis o ¿Cuáles métricas esperamos mejorar? ¿Por qué? o Establecemos una linea base • Efectuamos una prueba A | B rigurosa o Muestra representativa o Grupos aislados de “experimento” y “control” o No terminamos la prueba hasta final • Recopilamos todos los logs y mediciones o Analizar el comportamiento de los clientes y los sistemas o Analizar por que este experimento fue exitoso o fallido o Diseñar el próximo experimento
  20. 20. F(x) de Ordenamiento de Búsqueda en eBay • “F(x) de ordenamiento” determina el orden de resultados o ¿Cuál producto debe aparacer en la posición número 1, 10, 100 ? o Antes: Menos variables involucradas en la función construida manualmente o Despues: Miles de variables involucradas en la función construida por “machine learning” • Experimentación incremental o Cientos de pruebas A | B en paralelo o Un año de trabajo, continuamente mejorando la F(x)  2% incremento en las utilidades de eBay (~$120M / año)
  21. 21. Latencia de los Resultados de Búsqueda en eBay • Meta: Minimizar la latencia de los resultados observado por usuarios de eBay • Experimentación incremental o Implementamos una posible mejora o Desplegamos la mejora en una prueba A | B o Monitorizamos todas las métricas importantes – “tiempo de recepción del primer byte”, “tiempo transcurrido hasta el primer click”, “razón de click”, “razón de compra”  2% incremento en las utilidades de eBay (~$120M / año)
  22. 22. DevOps Es Como Trabajamos •¿Cómo Organizamos? •¿Qué Construimos? •¿Cuándo Construimos? •¿Cómo Construimos? •¿Cómo Gestionamos?
  23. 23. Priorizar • Siempre tenemos más tareas que recursos • Con insuficiente recursos, tenemos que priorizar tareas • Costo Menos Beneficio o Si elegimos A, debemos tener en cuenta los beneficios de B (que no elegimos) @randyshoup linkedin.com/in/randyshoup
  24. 24. Menos Tareas en Progreso
  25. 25. Funcionalidad 1 Funcionalidad 2 Funcionalidad 3 Funcionalidad 4 Funcionalidad 5 Organizaciones Tradicionales Mes 4
  26. 26. Funcionalidad 1 Funcionalidad 2 Funcionalidad 3 Funcionalidad 4 Funcionalidad 5 Despliegue Continuo: Menos Tareas, Más Tareas Completadas Mes 4Mes 2
  27. 27. Despliegue Continuo: Despliegue en Iteraciones Mes 4Mes 2 1a 1b 1c 1d 2a 2b 2c 3a 3b 3c 3d 4a 4b 4c 5a 5b
  28. 28. Menos Tareas en Progreso: Beneficios • Terminamos primero las tareas priorizadas o Producimos las funcionalidades en el orden de sus prioridades • Tiempo es valor o Producimos valor al cliente más temprano • Entregamos de forma incremental o Podemos adaptar nuestro camino por la retroalimentación temprana del cliente • Desarrollamos más eficientemente o Dos personas pueden colaborar @randyshoup linkedin.com/in/randyshoup
  29. 29. “Cuando se resuelve el primer problema, el segundo gana una promoción.”
  30. 30. DevOps Es Como Trabajamos •¿Cómo Organizamos? •¿Qué Construimos? •¿Cuándo Construimos? •¿Cómo Construimos? •¿Cómo Gestionamos?
  31. 31. Disciplina de Calidad • Calidad es una funcionalidad con “prioridad 0” o Si la aplicación no funciona, no importa que sea bonita • Los miembros de un equipo son responsables por: o Desarrollo o Calidad o Desempeño o Consistencia o Seguridad o Manejabilidad
  32. 32. Desarrollo Guiado por Pruebas (TDD) • Las pruebas producen mejores códigos o Cuando rompimos una funcionalidad, podemos identificar rápidamente el problema o Podemos refactorizar nuestro sistema con confianza • Las pruebas producen mejores sistemas o Detectamos bugs más temprano @randyshoup linkedin.com/in/randyshoup
  33. 33. TDD Mejora el Esfuerzo de Desarrollo @randyshoup linkedin.com/in/randyshoup • 75% leyendo códigos existentes • 20% modificando códigos existentes • 5% produciendo nuevos códigos https://blogs.msdn.microsoft.com/peterhal/2006/01/04/what-do-programmers-really-do-anyway-aka-part-2-of-the-yardstick-saga/
  34. 34. TDD Mejora el Esfuerzo de Desarrollo @randyshoup linkedin.com/in/randyshoup • 75% leyendo códigos existentes • 20% modificando códigos existentes • 5% produciendo nuevos códigos https://blogs.msdn.microsoft.com/peterhal/2006/01/04/what-do-programmers-really-do-anyway-aka-part-2-of-the-yardstick-saga/
  35. 35. “¿Tenemos tiempo para hacerlo dos veces?” “¡No tenemos tiempo para hacerlo mejor!”
  36. 36. Por muchas restricciones que tengamos de tiempo y recursos, lo más importante es construir correctamente desde el principio.
  37. 37. Construir Correctamente desde el Principio • Preferimos construir una funcionalidad completa en lugar de dos funcionalidades incompletas • Correcta no significa perfecta •  En Stitch Fix, basicamente no existe un sistema de gestión de bugs o Cuando encontramos un bug, priorizamos su solución o “Backlog” contiene nuevas funcionalidades para desarrollar o “Backlog” contiene tareas de “deuda tecnica” @randyshoup linkedin.com/in/randyshoup
  38. 38. DevOps Es Como Trabajamos •¿Cómo Organizamos? •¿Qué Construimos? •¿Cuándo Construimos? •¿Cómo Construimos? •¿Cómo Gestionamos?
  39. 39. “Usted lo construye, usted lo maneja.” -- Werner Vogels, CTO en Amazon
  40. 40. Despliegue Continuo • Pipeline Repetible de Despliegue o Rápida entrega o Rápida recuparación • Desplegamos múltiples aplicaciones muchas veces por día • Producimos sistemas más estables o Entregamos micro-funcionalidades o Más fáciles de reparar, de comprender, y de diagnosticar @randyshoup linkedin.com/in/randyshoup
  41. 41. Post-Mortems sin Culpable • Post-mortem después de cada incidente o Documentamos que pasó exactamente o ¿Qué sucedió? o ¿Qué fue mal? • Tenemos una discusión constructiva o ¿Qué contribuyó al incidente? o ¿Qué podríamos hacer mejor? Nuestros ingenieros compiten por asumir la responsabilidad (!) @randyshoup linkedin.com/in/randyshoup
  42. 42. La discusión es constructiva Quisiera mejorar mi sistema
  43. 43. Post-Mortems sin Culpable • Producimos un listado de acciones o ¿Cómo cambiaremos el proceso, la tecnología, la documentación, etc. o ¿Cómo podríamos automatizar la solución? o ¿Cómo podríamos diagnosticar más rápido? o ¿Cómo podríamos restablecer el servicio más rápido? • Aseguramos su implementación @randyshoup linkedin.com/in/randyshoup
  44. 44. DevOps Es Como Trabajamos •¿Cómo Organizamos? •¿Qué Construimos? •¿Cuándo Construimos? •¿Cómo Construimos? •¿Cómo Gestionamos?
  45. 45. ¡Gracias! • @randyshoup • linkedin.com/in/randyshoup

×