"Guía práctica de DevOps": notas de lectura (7)

Parte 5 El tercer paso: práctica técnica de aprendizaje y experimentación continua.

En la Parte 3, analizamos las prácticas técnicas necesarias para establecer flujos de trabajo rápidos dentro del flujo de valor. En la Parte 4, nuestro objetivo es crear la mayor cantidad de retroalimentación posible de tantas áreas del sistema de trabajo como sea posible, y hacerlo de manera más inmediata, rápida y económica.

En la Parte 5, presentamos algunas prácticas que pueden crear más oportunidades de aprendizaje de la manera más rápida, frecuente y asequible posible. Esto incluye aprender de los accidentes y fallas, que son inevitables cuando trabajamos en sistemas complejos, y organizar y diseñar sistemas de trabajo para que podamos intentar y aprender continuamente a hacerlos más seguros. Los resultados deseados incluyen una mayor resiliencia y un conocimiento colectivo cada vez más rico sobre cómo funcionan realmente los sistemas, lo que nos permitirá alcanzar mejor nuestros objetivos. En los próximos capítulos, desarrollaremos sistemas para mejorar la seguridad, la mejora continua y el aprendizaje práctico:

• Construir una cultura justa donde las personas se sientan seguras;
• Mejorar la confiabilidad del entorno de producción mediante la inyección de fallas;
• Transformar el conocimiento empírico descubierto localmente en mejoras globales;
• Reserve espacios de tiempo dedicados a la mejora organizacional y a las actividades de aprendizaje.

19. Integrar el aprendizaje en el trabajo diario

Cuando se trabaja en sistemas complejos, es imposible predecir todos los resultados posibles. Incluso con herramientas preventivas estáticas, como listas de verificación y manuales de operación estandarizados, los accidentes todavía ocurren, a veces de manera catastrófica. Estas herramientas simplemente documentan nuestra comprensión actual del sistema.

Para trabajar de forma segura en sistemas complejos, las organizaciones deben ser capaces de autodiagnosticarse y mejorarse mejor, deben volverse expertas en identificar y resolver problemas y amplificar los efectos mediante la difusión de soluciones en toda la organización. Este enfoque crea un sistema de aprendizaje dinámico que nos permite comprender los errores y traducir esa comprensión en acciones para evitar que esos errores se repitan.

Esto es lo que el Dr. Steven Spear llama una “organización recuperable” que es “hábil para identificar problemas, resolverlos y amplificar el impacto de la experiencia al brindar soluciones en toda la organización”. Estos tejidos tienen la capacidad de curarse a sí mismos. "Para una organización así, responder a una crisis no es un trabajo especial, sino algo que se hace todo el tiempo. Esta capacidad de respuesta es la fuente de la confiabilidad".

El equipo de Netflix logra objetivos de recuperación operativa ejecutando "monos de resolución de problemas" para inyectar fallas continuamente en los entornos de preproducción y producción. Como puedes imaginar, cuando ejecutaron Troublemaker Monkey por primera vez en un entorno de producción, el servicio falló más allá de lo imaginable. Al detectar y resolver continuamente estos problemas durante el horario comercial normal, los ingenieros de Netflix iteraron rápidamente en un servicio resistente y al mismo tiempo crearon aprendizaje organizacional (¡durante el horario comercial habitual!) que les permitió desarrollar un sistema que supera a todos los competidores.

Troublemaker Monkey es sólo un ejemplo de cómo incorporar el aprendizaje al trabajo diario. Esta historia también muestra cómo las organizaciones que aprenden piensan en las averías, los accidentes y los errores, como oportunidades para aprender, no como castigo. Este capítulo explora cómo crear sistemas de aprendizaje, cómo construir una cultura justa y cómo acelerar el aprendizaje mediante simulacros regulares y fallas simuladas artificialmente.

19.1 Construir una cultura de justicia y aprendizaje

Uno de los requisitos previos de una cultura de aprendizaje es que cuando ocurre un incidente (y no hay duda al respecto), la respuesta debe ser "justa". El Dr. Sidney Dekker ha recopilado algunos elementos clave de la cultura de seguridad y utiliza el término cultura justa . Escribe: “Si las respuestas a incidentes e incidentes se perciben como injustas, pueden impedir las investigaciones de seguridad, inducir miedo en lugar de atención plena entre quienes realizan trabajos críticos para la seguridad y hacer que las organizaciones sean más burocráticas en lugar de cautelosas, e inducir al secreto profesional. evasión y autoprotección”.

El Dr. Sidney Dekker llama a esta idea de eliminar errores eliminando a los perpetradores la teoría de la manzana podrida . Afirma que esto no es válido porque "el error humano no es la causa del problema; más bien, es el resultado de un problema de diseño con las herramientas que proporcionamos".

Teoría de la manzana podrida (Ley de la manzana podrida): Si dejas una manzana podrida en una canasta de manzanas buenas, terminarás con una canasta de manzanas podridas. Esta es la Ley de la manzana podrida.

Si los accidentes no son causados ​​por "manzanas podridas", sino por problemas de diseño inevitables en los complejos sistemas que construimos, entonces no debería "nombrarse, culpar y avergonzar" a quienes causaron las fallas. Nuestro objetivo siempre debe ser maximizar las oportunidades de aprendizaje organizacional, enfatizando continuamente la importancia que damos a descubrir y comunicar ampliamente los problemas en nuestro trabajo diario. Esto mejora la calidad y seguridad de los sistemas en los que trabajamos y fortalece las relaciones entre todos dentro de ellos.

Cuando los ingenieros cometen errores, si pueden sentirse seguros dando información detallada, no sólo estarán dispuestos a asumir la responsabilidad del asunto, sino que también estarán entusiasmados por ayudar a otros a evitar el mismo error. Esto crea aprendizaje organizacional. Por el contrario, si se castiga al ingeniero, todos ya no estarán motivados para proporcionar los detalles necesarios y será imposible comprender el mecanismo, el principio y el funcionamiento de la falla, entonces la falla definitivamente volverá a ocurrir.

Dos prácticas efectivas ayudan a crear una cultura de aprendizaje imparcial: autopsias sin culpas e introducción de fallas humanas controladas en entornos de producción para crear oportunidades para abordar problemas inevitables en sistemas complejos.

19.2 Celebrar reuniones post mortem sin culpas

Para ayudar a construir una cultura de justicia, cuando ocurren incidentes e incidentes críticos (por ejemplo, fallas de implementación, incidentes de producción que afectan a los clientes), debe haber una autopsia sin culpas después de que se resuelva el problema . "No sólo el accidente en sí, sino también el mecanismo y las circunstancias en las que ocurrió, así como el proceso de toma de decisiones de las personas involucradas en el accidente".

Esta práctica también se conoce como análisis post mortem o reflexión post mortem. Vale la pena señalar que existe una revisión de rutina similar que forma parte de muchas prácticas de desarrollo ágiles e iterativas.

Para hacer esto, necesitamos programar reuniones post mortem lo antes posible después de que ocurra el accidente, antes de que los recuerdos se desvanezcan, la causalidad se vuelva borrosa y las circunstancias cambien. (Por supuesto, esperamos hasta que se resuelva el problema para no molestar a nadie que todavía esté trabajando activamente en el problema). En una sesión post mortem libre de culpas, hacemos lo siguiente:

• Construir una línea de tiempo para recopilar todos los detalles sobre la falla desde múltiples ángulos, asegurando que la persona que cometió el error no sea castigada;
• Permitir que todos los ingenieros mejoren la seguridad pidiéndoles que detallen cómo contribuyeron a la falla;
• Permitir y alentar a quienes cometen errores a convertirse en expertos en educar a otros para que no cometan los mismos errores en el futuro;
• Crear un espacio para la libre toma de decisiones, permitiendo a las personas decidir si actúan y dejando un juicio sobre las decisiones a posteriori;
• Desarrolle contramedidas para prevenir incidentes similares y asegúrese de documentar estas contramedidas, las fechas objetivo y las personas responsables para fines de seguimiento.

Para lograr una comprensión adecuada, las siguientes partes interesadas deben estar presentes en la reunión:

• Personas involucradas en la toma de decisiones sobre temas relevantes;
• La persona que identifica el problema;
• personas que responden preguntas;
• la persona que diagnostica el problema;
• personas afectadas por el problema;
• Cualquier persona interesada en asistir a la conferencia.

Se debe prestar atención a la documentación detallada y a reforzar una cultura en la que la información pueda compartirse sin temor a castigos o represalias. Debido a esto, puede resultar útil contar con una persona capacitada que no esté involucrada en el incidente para organizar y dirigir la reunión, especialmente durante las primeras reuniones post mortem.

En el curso de reuniones y resoluciones debe prohibirse expresamente el uso de palabras como " 原来应该" o " ", por tratarse de afirmaciones contrafácticas derivadas de la tendencia humana a crear posibles alternativas a acontecimientos ya ocurridos. Declaraciones contrafácticas como "Podría haber..." o "Si hubiera sabido esto, debería haber..." son formas imaginativas de definir el problema en lugar de basarse en hechos . Necesitamos limitarnos a tales contextos.原本可以

La reunión debe permitir tiempo suficiente para intercambiar ideas y decidir respuestas. Una vez identificada una contramedida, se debe priorizar el trabajo, asignar una persona responsable y establecer un cronograma para su implementación. Esta es una prueba más de que valoramos mejorar nuestras rutinas diarias más que las rutinas mismas.

Ejemplos de estas respuestas incluyen agregar pruebas automatizadas que detecten anomalías en el proceso de implementación, agregar métricas de telemetría de producción más profundas, identificar los tipos de cambios que requieren una revisión adicional por pares y realizar días de simulacro regulares para abordar tales fallas.

19.3 Hacer que los resultados de las reuniones post-mortem estén lo más ampliamente disponibles posible

Después de una reunión post mortem sin culpas, las actas y toda la documentación relacionada (por ejemplo, cronogramas, registros de chat de IRC, comunicaciones externas) deben estar ampliamente disponibles. Idealmente, la información disponible públicamente debería estar en una ubicación centralizada, de fácil acceso para todos en la organización para aprender de incidentes pasados. La reunión de análisis post-mortem es muy importante, e incluso podemos considerar la finalización de la reunión de análisis post-mortem como una señal del final de todo el proceso de manejo de accidentes de producción. Hacerlo ayuda a traducir el aprendizaje y las mejoras dentro del proyecto en aprendizaje y mejoras en toda la organización.

19.4 Reducir la tolerancia a los accidentes y buscar señales de fallo más débiles

A medida que las organizaciones aprenden a ver y resolver problemas de manera efectiva, es necesario reducir el umbral para identificar fallas para permitir un aprendizaje más profundo. Para ello, queremos amplificar esas débiles señales de fallo.

Esto lo demuestra la forma en que la NASA manejó las señales defectuosas durante la era del transbordador espacial. En 2003, el transbordador espacial Columbia explotó al reingresar a la atmósfera terrestre en el día 16 de su misión. Ahora sabemos que un trozo de espuma aislante perforó el tanque de combustible externo durante el despegue. Sin embargo, algunos ingenieros de nivel medio de la NASA habían informado del incidente antes del regreso del Columbia, pero sus opiniones no fueron tomadas en serio. Observaron el impacto del bloque de espuma en un monitor durante una sesión de revisión posterior al lanzamiento e inmediatamente informaron de ello a los directivos de la NASA. Pero les dijeron que el problema de las burbujas no era nada nuevo. La deriva de la espuma ha dañado naves espaciales en lanzamientos anteriores, pero nunca ha provocado un accidente importante. La NASA caracterizó el incidente como un problema de mantenimiento y no tomó ninguna medida. Hasta que finalmente ocurrió el accidente, todo era demasiado tarde.

Observan: “Las empresas se meten en problemas cuando aplican el tipo de pensamiento equivocado en sus organizaciones (lo que determina cómo abordan amenazas poco claras, que en los términos de este libro son señales débiles de fracaso)… Hacia los 20 años, en la década de 1970, la NASA creó un cultura rígida de estandarización y promovió el transbordador ante el Congreso como una nave espacial reutilizable y económica". La NASA se adhiere estrictamente al cumplimiento del proceso en lugar de a los modelos experimentales, y cada pieza de información se evalúa para confirmar que no se han producido desviaciones. Las consecuencias de la falta de aprendizaje y experimentación continuos son nefastas. El autor concluye que la cultura y la mentalidad son cruciales y que la "precaución" por sí sola no es suficiente. "La vigilancia por sí sola no puede evitar que amenazas poco claras (débiles señales de fracaso) se conviertan en costosos accidentes (y a veces en tragedias)", escribieron.

Nuestro trabajo en el flujo de valor de la tecnología es como los viajes espaciales: debe tratarse como un esfuerzo experimental fundamental y gestionarse como tal. Todo lo que hacemos es una fuente de suposiciones y datos potencialmente importantes, no una rutina repetitiva o una validación de prácticas pasadas. El trabajo técnico no puede considerarse completamente estandarizado y esforzarse por lograr el cumplimiento del proceso. En lugar de ello, hay que buscar continuamente señales de fallo cada vez más débiles para comprender y gestionar mejor el sistema en funcionamiento.

19.5 Redefinir el fracaso y fomentar la evaluación de riesgos

Ya sea intencionalmente o no, los líderes organizacionales toman acciones para reforzar la cultura y los valores organizacionales. Los expertos en auditoría, contabilidad y ética han sostenido durante mucho tiempo que las "voces desde arriba" pueden significar fraude y otras prácticas poco éticas. Para fortalecer una cultura de aprendizaje y evaluación de riesgos, los líderes deben enfatizar continuamente que todos deben sentirse cómodos y responsables del fracaso y ser capaces de aprender de él.

"Estaba hablando con un colega sobre una interrupción masiva que acaba de sufrir Netflix, que, francamente, fue causada por un simple error. De hecho, el ingeniero que causó este incidente había derribado Netflix en los últimos 18 meses. Máquina dos veces. Sin embargo "Es alguien a quien nunca despediremos. En los últimos 18 meses, este ingeniero ha mejorado enormemente el estado de las operaciones y la automatización, y el progreso no se mide en 'kilómetros' sino en 'años luz'. Medidos, los resultados son sobresalientes. Los resultados de su trabajo nos permiten implementar de forma segura todos los días, y él personalmente realiza una gran cantidad de implementaciones de producción".

Concluyó: "DevOps debe permitir este tipo de innovación y aceptar los riesgos que conlleva. Sí, habrá más fallos en la producción. Pero esto es algo bueno y no debería ser castigado".

19.6 Inyectar fallas en producción para recuperar y aprender

Como se introdujo al principio de este capítulo, inyectar errores en el entorno de producción (como el uso de "monos de resolución de problemas") es una forma de mejorar la capacidad de recuperación. Esta sección describe el proceso de ensayar e inyectar fallas en un sistema para garantizar que el sistema esté diseñado y construido correctamente para que las fallas ocurran de manera específica y controlada. Nos aseguramos de que el sistema falle correctamente realizando pruebas con regularidad (o incluso de forma continua).

La recuperabilidad requiere que primero definamos los modos de falla y luego realicemos pruebas para garantizar que estos modos de falla funcionen según lo diseñado. Un enfoque es inyectar fallas en el entorno de producción y practicar fallas a gran escala. De esta manera, puede estar seguro de que el sistema podrá recuperarse automáticamente en caso de un incidente, idealmente sin afectar siquiera a los clientes.

Un enfoque proactivo en la recuperabilidad significa que las empresas pueden manejar eventos que desencadenarían una crisis en la mayoría de las organizaciones de una manera rutinaria y mundana.

Los patrones arquitectónicos específicos que implementaron incluyen falla rápida (establecer tiempos de espera proactivos para que un componente fallido no deje caer todo el sistema), respaldo (diseñar cada característica para que pueda degradarse o volver a un rendimiento de menor calidad) y eliminación de características ( eliminar funcionalidades no críticas de cualquier página específica que esté funcionando con lentitud para evitar que la experiencia del usuario se vea afectada). Además de mantener la continuidad del negocio durante la interrupción de AWS, existe un ejemplo sorprendente de resiliencia creado por el equipo de Netflix. Seis horas después de que ocurriera la interrupción de AWS, Netflix anunció un incidente de Nivel 1 (Sev 1), suponiendo que los servicios de AWS eventualmente volverían a la normalidad ("AWS se recuperará... ese suele ser el caso, ¿verdad?"). Iniciaron todos los procedimientos de continuidad del negocio solo 6 horas después de que se interrumpiera el servicio de AWS.

19.7 Crear un día de simulacro de falla

Esta sección describe un simulacro especial de recuperación ante desastres llamado Game Day. El concepto de días de perforación proviene de la disciplina de la ingeniería elástica. La ingeniería de resiliencia se define como "ejercicios diseñados para mejorar la recuperabilidad mediante la inyección de fallas a gran escala en sistemas críticos".

El objetivo del día de simulacro es ayudar a los equipos a simular y ensayar incidentes para que adquieran capacidad operativa. Primero, planifique un evento catastrófico, como simular la destrucción de todo el centro de datos en algún momento en el futuro. Luego, déle al equipo tiempo de preparación para eliminar todos los puntos únicos de falla y crear los procedimientos de monitoreo, procedimientos de conmutación por error, etc.

Al hacer esto, comenzamos a exponer posibles fallas en el sistema. Es la inyección de fallas en el sistema lo que permite que estos problemas surjan. "Es posible que ciertos sistemas de monitoreo o administración que son críticos para el proceso de recuperación terminen apagándose como parte de un paso de orquestación de fallas", explica Robbins. "[O] puede encontrar algún punto único desconocido de falla". Los ensayos se realizan de maneras cada vez más profundas y complejas para que la gente sienta que esto es parte de su rutina diaria.

Las cosas aprendidas durante estos desastres incluyen:

• Cuando se interrumpe la conexión de red, no es posible utilizar la estación de trabajo del ingeniero para la conmutación por error;
• Los ingenieros no saben cómo acceder a un puente de conferencias telefónicas o a un puente que solo puede acomodar a 50 personas, o necesitan un nuevo proveedor de conferencias telefónicas para poder deshacerse del ingeniero que hace esperar a todos los participantes en la conferencia telefónica;
• Cuando los generadores de respaldo en el centro de datos se quedaron sin diésel, nadie conocía el proceso de compra de emergencia a través del proveedor, lo que resultó en que alguien usara una tarjeta de crédito personal para comprar diésel por valor de 50.000 dólares.

Introduciendo fallos en situaciones controladas podemos practicar y establecer el manual de funcionamiento requerido. Otro resultado del día de práctica es que la gente realmente sabe a quién llamar y con quién hablar. Esto les permitirá establecer relaciones con personas de otros departamentos para trabajar juntos en caso de un incidente, convirtiendo las acciones conscientes en acciones subconscientes y luego en rutina.

19.8 Resumen

Para crear culturas justas que permitan el aprendizaje organizacional, debemos replantear lo que llamamos fracaso. Cuando los manejamos correctamente, los errores inherentes a los sistemas complejos pueden crear un entorno de aprendizaje dinámico donde todas las partes interesadas se sienten lo suficientemente seguras como para generar ideas y conocimientos, y los equipos pueden pasar más fácilmente de un fracaso a otro. Reanudar el proyecto según lo programado.

Las reuniones post mortem sin culpas y la inyección de fallas en la producción refuerzan una cultura en la que todos deben sentirse cómodos con las fallas, asumir responsabilidades y aprender de ellas. De hecho, cuando el número de accidentes disminuye significativamente, la tolerancia también disminuye, permitiéndonos seguir aprendiendo. Como dijo Peter Senge: "La única ventaja competitiva sostenible de una organización es su capacidad para aprender más rápido que sus competidores".

20. Transformar la experiencia local en mejora global

Este capítulo establecerá un mecanismo para compartir y aplicar nuevas experiencias y métodos de optimización adquiridos localmente en el alcance global de toda la organización, mejorando así en gran medida el conocimiento global y los efectos de mejora de la organización. Esto mejorará el estado de las prácticas en toda la organización para que todos en el trabajo se beneficien de la experiencia acumulada por la organización.

20.1 Acumulación automatizada de conocimiento organizacional mediante salas de chat y chatbots

Muchas organizaciones han establecido salas de chat para facilitar una comunicación interna rápida. Sin embargo, las salas de chat también se pueden utilizar para activar operaciones automatizadas.

GitHub inventó una aplicación de chat llamada Hubot para interactuar con el equipo de operación y mantenimiento en una sala de chat. Se pueden indicarle que realice determinadas operaciones operativas enviando comandos (por ejemplo, "@hubot implementar búho en producción"). Los resultados de la operación también se envían a la sala de chat. De manera similar, ya sea que se trate de una confirmación de código en el repositorio de código fuente o de un comando que desencadena una implementación de producción, se envía un mensaje a la sala de chat.

Automatizar acciones en una sala de chat tiene muchas ventajas (en comparación con ejecutar scripts de automatización desde la línea de comandos):

• Todos pueden ver todo lo que sucede;
• Los nuevos ingenieros también pueden ver el trabajo diario del equipo y su desempeño;
• También es más probable que las personas pidan ayuda cuando ven que otros se ayudan entre sí;
• Se establece el aprendizaje organizacional y el conocimiento se acumula rápidamente.

Además, además de los beneficios ampliamente demostrados mencionados anteriormente, las salas de chat registran y exponen inherentemente todas las comunicaciones. Por el contrario, las comunicaciones por correo electrónico son privadas por defecto y la información que contienen no se puede difundir fácilmente dentro de una organización.

Las acciones realizadas a través de Hubot incluyen verificar el estado de un servicio, realizar envíos de Puppet o implementar código en producción y silenciar las alertas de monitoreo de un servicio cuando ingresa al modo de mantenimiento. Las operaciones repetidas se pueden completar con Hubot. Por ejemplo, recuperar el registro de prueba de humo cuando falla la implementación, sacar el servidor de producción del clúster de servicios, revertir el servicio front-end de producción a la versión anterior e incluso disculparse con el ingeniero de turno.

GitHub crea un entorno colaborativo que transforma el conocimiento aprendido localmente en experiencias en toda la organización. Luego exploramos cómo crear y acelerar la difusión del aprendizaje organizacional.

20.2 Procesos automatizados y estandarizados en software para una fácil reutilización

A menudo documentamos los estándares y procesos de arquitectura, pruebas, implementación y gestión de infraestructura, los almacenamos como documentos de Word y los subimos a un servidor. Sin embargo, el problema es que los ingenieros que crean nuevas aplicaciones o entornos a menudo no saben que estos documentos existen, o simplemente no tienen tiempo para implementarlos de acuerdo con los estándares que contienen. Como resultado, crean sus propias herramientas y procesos que terminan decepcionantes: las aplicaciones y los entornos son frágiles, inseguros, imposibles de mantener y costosos de ejecutar, mantener y actualizar.

En lugar de escribir el conocimiento profesional en un documento de Word, varios estándares y procesos que abarcan completamente el aprendizaje y el conocimiento organizacional se pueden transformar en un formato ejecutable, lo que facilita su reutilización. Una buena manera de lograr este tipo de reutilización del conocimiento es mantenerlo en un repositorio de código fuente centralizado, convirtiéndolo en una herramienta utilizable y con capacidad de búsqueda para todos.

Crearon un mecanismo llamado ArchOps que "permite a los ingenieros ser constructores, no albañiles. Al transformar los estándares de diseño en planos que pueden automatizarse y ejecutarse fácilmente y ser utilizados por cualquiera, logramos coherencia en los subproductos".

Al convertir procesos manuales en código automatizable, el proceso se adopta ampliamente y proporciona valor a todos los usuarios. Arbuckle concluyó: "El cumplimiento real de una organización es directamente proporcional al grado en que expresa sus políticas en código".

Convertir los procesos automatizados en la forma más sencilla de lograr objetivos puede conducir a una adopción generalizada de la práctica, incluso considerando convertirla en un servicio compartido respaldado por la organización.

20.3 Crear un único repositorio de código fuente compartido en toda la organización

Establecer un repositorio de código fuente compartido en toda la empresa es un mecanismo poderoso para integrar todos los hallazgos locales dentro de la organización. Cuando se actualiza algo en el repositorio de código fuente (por ejemplo, una biblioteca compartida), se propaga automática y rápidamente a todos los demás servicios que lo llaman y se integra a través del proceso de implementación de cada equipo.

Almacenamos no solo el código fuente en el repositorio de código fuente compartido, sino también artefactos que contienen otras experiencias de aprendizaje y conocimientos:

• Estándares de configuración para bibliotecas, infraestructura y entornos (archivos de recetas de Chef, archivos de clases de Puppet, etc.);
• herramientas de implementación;
• normas y herramientas de prueba, incluidos los aspectos de seguridad;
• Herramientas de canalización de implementación;
• herramientas de seguimiento y análisis;
• Tutoriales y estándares

"El mecanismo más poderoso para evitar que Google se descomponga es una base de código única. Cada vez que alguien actualiza la base de código, se activa una nueva compilación y todas las dependencias que utiliza están actualizadas. Todo se genera desde la fuente código creado, en lugar de vinculado dinámicamente en tiempo de ejecución: siempre hay disponible una única versión de la biblioteca, la que se está utilizando actualmente, y está vinculada estáticamente durante el proceso de compilación".

Si no puede crear un único árbol fuente (biblioteca de código fuente), debe encontrar otra forma de mantener la biblioteca para garantizar que todas las dependencias de la biblioteca sean versiones conocidas y disponibles. Por ejemplo, puede configurar un repositorio para toda la organización, como Nexus, Artifactory o Debian o RPM, y luego actualizar tanto esos repositorios como los sistemas de producción para detectar vulnerabilidades de seguridad conocidas.

20.4 Utilizar documentación de prueba automatizada y prácticas de comunicación para difundir el conocimiento.

Cuando se utiliza una biblioteca compartida en toda una organización, deberíamos poder difundir rápidamente conocimientos y mejoras. Asegurarse de que estas bibliotecas tengan muchas pruebas automatizadas significa que registran y muestran automáticamente cómo las utilizan otros ingenieros.

Si adopta la práctica del desarrollo basado en pruebas (TDD), en la que escribe pruebas automatizadas antes de escribir el código, el beneficio es que las pruebas están casi completamente automatizadas. Este principio convierte el conjunto de pruebas en una especificación de sistema viva y actualizada. Cualquier ingeniero que quiera saber cómo utilizar el sistema puede consultar el conjunto de pruebas para encontrar ejemplos de uso funcional de la API del sistema.

Lo ideal es que cada biblioteca tenga un propietario o un equipo de soporte que tenga conocimientos y experiencia relevantes. Además, deberíamos (preferiblemente) permitir que solo se utilice una versión en producción, asegurando que todo lo producido utilice el mejor conocimiento colectivo de la organización.

En este modelo, el propietario de la biblioteca también necesita ayudar a cada equipo que depende de ella a migrar de forma segura de una versión a la siguiente. Esto, a su vez, requiere pruebas automatizadas integrales y una integración continua de todos los sistemas que dependen de ellas para descubrir rápidamente errores de regresión.

Para difundir el conocimiento más rápidamente, también se pueden establecer grupos de discusión o salas de chat para cada biblioteca o servicio. Cualquiera que tenga preguntas puede obtener comentarios de otros usuarios aquí, a menudo más rápido que los desarrolladores.

En lugar de tener experiencia dispersa por toda la organización, el uso de este tipo de herramienta de comunicación facilita el intercambio de conocimientos y experiencias, asegurando que los empleados se ayuden entre sí con problemas y nuevos modelos.

20.5 Diseñar operaciones identificando requisitos no funcionales

La implementación de estos requisitos no funcionales hará que nuestros servicios de producción sean más fáciles de implementar y mantener en funcionamiento, lo que permitirá detectar y solucionar rápidamente los problemas y garantizar una degradación gradual si fallan los componentes del servicio. A continuación se muestran ejemplos de requisitos no funcionales que deberían existir:

• Telemetría adecuada para una variedad de aplicaciones y entornos;
• La capacidad de rastrear con precisión las dependencias;
• Un servicio que sea resistente y pueda degradarse con gracia;
• Existe compatibilidad hacia adelante y hacia atrás entre versiones;
• La capacidad de archivar datos para gestionar conjuntos de datos de producción;
• La capacidad de buscar y comprender fácilmente información diversa del registro de servicios;
• La capacidad de rastrear las solicitudes de los usuarios a través de múltiples servicios;
• Utilice conmutadores de funciones u otros métodos para una configuración de tiempo de ejecución centralizada y sencilla.

Al identificar estos requisitos no funcionales, el conocimiento y la experiencia colectivos se pueden aplicar más fácilmente a servicios nuevos y existentes. Estas responsabilidades recaen en el equipo que construye el servicio.

20.6 Incorporar historias de usuarios operativas reutilizables en el desarrollo

Si algunas operaciones y trabajos de mantenimiento no pueden ser completamente automatizados o autoservicios, nuestro objetivo es intentar que este trabajo recurrente sea repetible y determinista. Hacemos esto estandarizando el trabajo requerido, automatizándolo tanto como sea posible y documentando el trabajo realizado para que el equipo de producto pueda contribuir mejor a esta actividad.

En lugar de configurar un servidor manualmente, luego verificarlo uno por uno según la lista de verificación y ponerlo en línea en el entorno de producción, es mejor automatizar estas tareas tanto como sea posible. Si ciertos pasos no se pueden automatizar (por ejemplo, colocar los servidores manualmente y luego hacer que un grupo de red conecte los cables), la entrega debe definirse lo más claramente posible para reducir el tiempo de entrega y los errores. Esto también hace que sea más fácil planificar y programar mejor los pasos más adelante.

Así como creamos historias de usuarios en la fase de desarrollo, las colocamos en el trabajo pendiente y luego codificamos la implementación, también podemos crear "historias de usuarios de operaciones" bien definidas que describan aquellas que se utilizan en todos los proyectos (por ejemplo, implementación, planificación de capacidad, refuerzo sexual de seguridad, etc.) que pueden ser reutilizados en el trabajo. Al crear estas historias de usuario de operaciones claramente definidas, sacamos a la luz el trabajo de operaciones de TI repetible y el trabajo de desarrollo relacionado en conjunto, creando mejores planes de trabajo y resultados más repetibles.

用户故事Se refiere a la narrativa o descripción completa de funciones, rutas y servicios específicos diseñados por el equipo de desarrollo para satisfacer las necesidades específicas de un usuario para satisfacer su comportamiento y tareas en la aplicación. En general, las historias de usuario son un análisis jerárquico de información de software orientado a objetos, que incluye principalmente historias de usuario principales, historias derivadas y atributos del producto. La historia de usuario principal es un estado narrativo que se utiliza para describir el sistema que está utilizando el usuario y su funcionalidad principal. y usabilidad; las historias derivadas deben ser parte de la historia de usuario principal, y la implementación de historias derivadas puede mejorar la calidad de la historia de usuario base; los atributos del producto pueden definir categorías de atributos de complejidad. Esto se basa tanto en las sugerencias de los usuarios como en las sugerencias de los administradores, en base a estas dos partes, combínelas y luego expréselas en forma de historias para completar los requisitos de software requeridos de una manera más específica.

20.7 Garantizar que la selección de tecnología ayude a alcanzar los objetivos de la organización

Cuando utilizamos una arquitectura orientada a servicios y uno de los objetivos es maximizar la productividad de los desarrolladores, los equipos de servicios pequeños pueden crear y ejecutar servicios utilizando el lenguaje o marco que mejor se adapte a sus necesidades específicas. En algunos casos, esta es la mejor manera de lograr los objetivos organizacionales.

Si aún no existe una lista de tecnologías desarrolladas conjuntamente por desarrollo y operaciones y respaldadas por la organización, se debe realizar un estudio sistemático de la infraestructura y los servicios del entorno de producción, así como de las tecnologías subyacentes actualmente respaldadas, para identificar las tecnologías. que provocan fallas innecesarias y trabajos no planificados. Necesitamos identificar tecnologías que tengan las siguientes características:

• Bloquea o ralentiza el flujo de trabajo;
• Dando como resultado una cantidad desproporcionadamente grande de trabajo no planificado;
• Generar un número desproporcionadamente grande de solicitudes de soporte;
• Completamente inconsistente con nuestros resultados arquitectónicos deseados, como rendimiento, estabilidad, seguridad, confiabilidad y continuidad del negocio.

Al excluir estas infraestructuras y plataformas problemáticas de las tecnologías respaldadas por el equipo de operaciones, el equipo de operaciones puede centrarse en la infraestructura que mejor ayuda a lograr los objetivos generales de la organización.

20.8 Resumen

Las técnicas descritas en este capítulo pueden incorporar fragmentos de nuevos aprendizajes al conocimiento colectivo de una organización y multiplicar su impacto. Logramos este objetivo mediante la difusión proactiva y amplia de nuevos conocimientos, utilizando métodos como salas de chat, arquitectura como código, bibliotecas de código fuente compartidas y estandarización técnica. Hacerlo no solo mejora los equipos de desarrollo y operaciones, sino también a toda la organización, por lo que todos en la organización contribuyen a la experiencia colectiva.

21. Reserve tiempo para el aprendizaje y la mejora organizacional.

Existe una práctica llamada bombardeo de mejora (kaizen blitz), una parte importante del Sistema de Producción Toyota, que se refiere a resolver un problema específico en un período de tiempo dedicado y concentrado, generalmente de unos pocos días. El Dr. Steven Spear explica: “Los bombardeos Kaizen a menudo toman la forma de un pequeño grupo que se reúne para centrarse en un proceso problemático... Los bombardeos Kaizen suelen durar varios días y tienen como objetivo optimizar el proceso centrándose en mejorar el proceso fuera de las personas. dar consejos a personas que normalmente están en el proceso”.

Luego, el capítulo describe métodos para reservar tiempo para el aprendizaje y la mejora organizacional y para institucionalizar aún más la práctica de invertir tiempo en mejorar el trabajo diario.

21.1 Prácticas institucionalizadas para el pago de la deuda técnica

Esta sección describe prácticas comunes que pueden ayudar a reforzar la práctica de reservar tiempo de desarrollo y operaciones para trabajos de mejora, como requisitos no funcionales y automatización. Una de las formas más sencillas de hacerlo es programar y realizar campañas de mejora durante unos días o semanas, permitiendo que todos los miembros del equipo (o toda la organización) se organicen para abordar los problemas de interés; no se permite trabajo funcional. Puede centrarse en un punto problemático en el código, el entorno, la arquitectura, las herramientas, etc. Estos equipos suelen estar formados por ingenieros de desarrollo, operaciones y seguridad de la información y abarcan todo el flujo de valor. Los equipos que normalmente no trabajan juntos pueden combinar sus habilidades y esfuerzos para mejorar áreas seleccionadas y luego demostrar los resultados a otros en la empresa.

Nuestro objetivo durante estos bombardeos no es simplemente experimentar e innovar con el fin de probar nuevas tecnologías, sino mejorar el trabajo diario, como identificar soluciones alternativas en nuestro trabajo diario. Aunque la experimentación también conducirá a ciertas mejoras, el objetivo de los bombardeos de mejora es resolver los problemas específicos que se encuentran en el trabajo diario.

21.2 Que todos aprendan unos de otros mediante la enseñanza

Ya sea a través de métodos didácticos tradicionales (por ejemplo, clases, capacitación) o métodos más experimentales o abiertos (por ejemplo, conferencias, talleres, tutorías), una cultura de aprendizaje dinámica no solo crea las condiciones para el aprendizaje para todos, sino que también puede crear oportunidades de enseñanza. Podemos dedicar tiempo organizacional dedicado a facilitar esta enseñanza y aprendizaje.

De este libro se desprende claramente que hay ciertas habilidades que todos los ingenieros, no solo los desarrolladores, necesitan cada vez más. Por ejemplo, es cada vez más importante que todos los ingenieros de operaciones y pruebas estén familiarizados con las tecnologías, prácticas y habilidades de desarrollo, como el control de versiones, las pruebas automatizadas, los canales de implementación, la gestión de la configuración y la automatización. La familiaridad con las tecnologías de desarrollo ayuda a los ingenieros de operaciones a mantenerse relevantes a medida que cada vez más flujos de valor tecnológico adoptan principios y patrones de DevOps.

Los equipos de desarrollo y operaciones pueden enseñar aún más habilidades en su trabajo diario realizando revisiones de código juntos, aprendiendo haciendo y resolviendo pequeños problemas juntos. Por ejemplo, los desarrolladores pueden demostrar al personal de operaciones cómo la aplicación autentica a los usuarios, inicia sesión en la aplicación y realiza pruebas automatizadas de componentes individuales para garantizar que los componentes clave funcionen correctamente (por ejemplo, la funcionalidad principal de la aplicación, transacciones de bases de datos, colas de mensajes). Esta nueva prueba automatizada luego se integra en el proceso de implementación y se ejecuta periódicamente, enviando los resultados de las pruebas a los sistemas de monitoreo y alerta para una detección temprana cuando fallan los componentes críticos.

21.3 Compartir experiencias en reuniones DevOps

En muchas organizaciones preocupadas por los costos, los ingenieros suelen ser reacios a asistir a reuniones y aprender de sus pares. Para construir una organización que aprende, debemos alentar a los ingenieros (de desarrollo y operaciones) a asistir a reuniones y, si es necesario, crear y organizar reuniones internas o externas.

21.4 Consultores internos y coaches para prácticas de comunicación

Formar una organización interna de coaching y consultoría es una forma común de difundir la experiencia dentro de una organización. Puede adoptar muchas formas. En Capital One, todos los expertos en el dominio tienen franjas horarias designadas en las que cualquiera puede consultar y responder preguntas.

Anteriormente en este libro, contamos cómo Testing Grouplet de Google comenzó a construir una cultura de pruebas automatizadas de clase mundial dentro de Google en 2005. Su historia continúa evolucionando: para mejorar integralmente las prácticas de pruebas automatizadas dentro de Google, utilizaron bombardeos kaizen, asesoramiento interno e incluso un programa de certificación interno.

21.5 Resumen

Este capítulo describe cómo establecer un conjunto de rutinas que ayuden a reforzar el aprendizaje permanente y una cultura que valore la mejora diaria en el trabajo diario. Esto se puede lograr reservando tiempo para pagar la deuda técnica; creando foros donde las personas puedan aprender y orientarse entre sí dentro y fuera de la organización; y permitiendo que los expertos ayuden a los equipos internos a través de coaching, consultoría o simplemente estableciendo reuniones cara a cara. tiempo.

Al hacer que todos aprendan unos de otros en su trabajo diario, aprendemos más que la competencia y ganamos en el mercado. Al mismo tiempo, nos ayudamos mutuamente a liberar todo nuestro potencial humano.

21.6 Resumen de la Parte 5

En la quinta parte, exploramos prácticas para crear una cultura de aprendizaje y experimentación en las organizaciones. Cuando trabajamos en sistemas complejos, aprender de los incidentes, crear bases de código compartidas y conocimientos compartidos son esenciales, lo que ayuda a que las culturas laborales sean más justas y los sistemas sean más seguros y resilientes.

En la Parte 6, exploramos cómo ampliar el flujo, la retroalimentación, el aprendizaje y la experimentación para ayudarnos simultáneamente a alcanzar nuestros objetivos de seguridad de la información.