Formación escrita en DevOps

¿Cómo facilitar el aprendizaje continuo con DevOps?

Por sus proyectos de software ya sabe que, incluso con listas de comprobación, revisiones entre pares y mecanismos de control, auditoría y cumplimiento, seguirá habiendo problemas. Es inevitable. Es hora de que el equipo y la organización DevOps desarrollen una cultura capaz de diagnosticar sus propios problemas, aprender de ellos y mejorar por sí misma. Esa cultura acepta que haya problemas y prepara a sus equipos para afrontarlos. Resolverlos debe formar parte del trabajo diario y contribuir al aprendizaje y la mejora continua de la organización. Multiplique el efecto de las soluciones haciéndolas visibles y accesibles para toda la organización DevOps.

Netflix, una destacada organización DevOps, creó software interno, Chaos Monkey, para simular eventos catastróficos en sus centros de datos en la nube. Chaos Monkey elimina servidores de producción al azar para que Netflix pueda comprobar mejor su resiliencia, estabilidad y capacidad de ofrecer un servicio de calidad sin interrupciones. El equipo extrae lecciones de cada fallo y las aprovecha para que sus sistemas sean aún más estables y resilientes.

Por qué importa crear una cultura de aprendizaje

Si tras los incidentes se buscan culpables, se crea una cultura de miedo entre los ingenieros. La organización se vuelve lenta, burocrática y llena de maniobras internas. En lugar de aprender deliberadamente de los errores, volverse más resistentes a ellos y actuar con más atención y cuidado para evitarlos, todos se preocupan de protegerse. El trabajo, los problemas y hasta las soluciones nunca son del todo transparentes.

Because problems are inevitable in complex systems, instead of finger-pointing, blaming and shaming the ones who cause problems, your organization should value actions to make problems visible in your daily work. It should encourage organizational learnings from errors and inefficiencies, so everyone in your DevOps organization can also learn and profit from these problems, solutions and knowledge.When engineers in your DevOps organization feel safe about giving details about mistakes, they voluntarily go extra mile and spend a lot of energy to make sure that a similar problem will not happen again in their own work center and in other work centers in your organizational value stream. If engineers are punished or even if they feel that they are punished when they do mistakes, then they will be afraid of making mistakes, so

1. Hacen menos trabajo para cometer menos errores.
2. No son transparentes sobre el trabajo, los problemas y las soluciones.
3. No tienen incentivos para convertir las soluciones a los problemas en aprendizaje para la organización.
4. Es seguro que volverá a ocurrir el mismo problema o uno muy parecido porque nadie dedica tiempo ni esfuerzo a aprender, compartir y enseñar lo relativo a los problemas y sus soluciones, ni a hacerlos visibles.

Revise los incidentes en cuanto ocurran, antes de que se olviden sus causas

Los objetivos de una revisión de incidentes son muy sencillos:

• Identificar lo que hizo bien para recordar que puede repetirlo en situaciones parecidas.
• Anotar lo que debería haberse hecho de otra manera para perfeccionar sus técnicas en el futuro.
• Anotar lo que hizo mal y proponer enfoques alternativos o medidas de seguridad que debería aplicar la próxima vez que se enfrente a un problema similar.
• Averiguar por qué tenía sentido tomar (o no tomar) la medida que provocó el incidente.

Examinar lo que hizo mal da miedo y, en algunas organizaciones, es peligroso. Si admitir los errores le expone a críticas o sanciones, difícilmente los reconocerá. Esta estrategia acaba siendo contraproducente: no entender un error del pasado suele condenarle a repetirlo. Las organizaciones que se toman en serio la mejora lo entienden y se esfuerzan por crear un proceso y una cultura en los que sea seguro analizar los errores.

Cuando participe en una revisión de incidentes, acepte algunas premisas básicas:

• Todo el mundo intenta hacer las cosas lo mejor que sabe.
• Tomamos decisiones bajo presión y con información incompleta.
• A menudo se nos pide que hagamos tareas para las que no hemos recibido formación con las herramientas y recursos que tenemos a mano.
• En esas situaciones es inevitable cometer errores.
• El objetivo del proceso es examinar lo que ocurrió y extraer lecciones, sin buscar defectos en ninguna persona ni en su actuación.
• El resultado del proceso será una evaluación de nuestros procesos y de cómo mejorarlos, sin evaluar a ninguna persona ni grupo.

Es fundamental que todas las personas implicadas acepten plenamente este modelo: «Sin culpas. Estamos aquí para aprender». Muchas organizaciones se esfuerzan por crear entornos seguros de este tipo. Por ejemplo, la FAA cuenta con un sistema de notificación de seguridad aérea (Aviation Safety Reporting System) mediante el cual los pilotos que cometan «errores» pueden quedar exentos de sanciones reglamentarias si notifican los incidentes.

Las revisiones deben definir siempre medidas concretas para evitar que el incidente se repita. Algunos ejemplos son nuevas métricas de telemetría, nuevos casos de prueba automatizados, la identificación de cambios que exijan revisiones adicionales de código, la refactorización de código y el desacoplamiento de componentes complejos que provocan problemas frecuentes.

Difunda en toda la organización las actas de las revisiones y las lecciones aprendidas. Así, lo aprendido en un centro de trabajo del flujo de valor se convierte en aprendizaje para toda la organización. También transmite un mensaje claro a su organización DevOps para fomentar la transparencia, la apertura y la cultura de aprendizaje.

Organice simulacros para mejorar sus sistemas

Un simulacro no es uno de esos eventos de equipo aburridos en los que los extrovertidos disfrutan del espectáculo y los introvertidos se entretienen con el móvil para que pase el tiempo.

En un simulacro se reproducen fallos catastróficos en los sistemas de pruebas. Los equipos de DevOps trabajan para resolverlos y aprender de ellos.

Por ejemplo, se detiene un servidor crítico para comprobar que el mecanismo de conmutación por error funciona sin interrumpir el servicio. Después, el equipo de DevOps comprueba si funciona la recuperación a partir de copias de seguridad o de la infraestructura como código (IaC), y cómo lo hace. Detectar problemas en esos escenarios ayuda a crear sistemas resilientes y tolerantes a fallos y a extraer lecciones.

Al resolver el problema, el equipo entabla relaciones con otros departamentos mientras ensaya fallos sin presión. Podrá poner a prueba y mejorar los procesos de comunicación y resolución de problemas en el conjunto de su organización.

También podrá detectar señales débiles de problemas mayores que podrían aparecer en el futuro. Los incidentes de baja prioridad que se repiten durante estos simulacros o un pequeño efecto secundario que casi provoca el fallo de otro componente crítico son señales importantes que debe tener en cuenta y abordar para mejorar sus sistemas.

CONCLUSIÓN

Anime a su equipo a asumir riesgos calculados. Las organizaciones DevOps de alto rendimiento, como la suya, cometen errores con más frecuencia. Es normal y, además, es lo que la organización necesita para aprender y rendir mejor.

Frente a las organizaciones típicas, las de alto rendimiento tienen un 80 % menos de fallos críticos en producción. En otras palabras, tienen 5 veces menos incidentes que afectan a sus clientes. Por eso, los ingenieros de su organización DevOps deben sentirse libres de cometer errores y aprender de ellos.