Parte 5 Paso 3: Práctica Técnica de Experimentación y Aprendizaje Continuo
Capítulo 19 Integración del aprendizaje en su trabajo diario 180
prefacio
Tienen un objetivo de diseño específico, que es garantizar que el servicio de Netflix pueda seguir funcionando incluso si falla toda la zona de disponibilidad de AWS, como este accidente en la región Este de EE. UU. Para lograr esto, la arquitectura del sistema debe estar débilmente acoplada y cada componente tiene un diseño de tiempo de espera particularmente sensible, para garantizar que un componente fallido no arrastre todo el sistema. En cambio, cada característica y componente de Netflix está diseñado para ser completamente degradable. Por ejemplo, cuando el uso de la CPU se dispara debido a un fuerte aumento en el tráfico, en lugar de mostrar una lista personalizada de recomendaciones de películas al usuario, solo se muestra el contenido estático que se ha almacenado en caché, lo que reduce la demanda de recursos informáticos.
Se llama "Mono problemático". Elimina de forma continua y aleatoria los servidores de producción para simular fallas en el entorno de AWS. Lo hacen con la esperanza de que todos los "equipos de ingeniería estén acondicionados para trabajar en niveles regulares de falla" para que el servicio pueda "recuperarse automáticamente sin intervención humana". Trouble Monkey continuamente inyecta fallas en los entornos de preproducción y producción, logrando así los objetivos de recuperación operativa.
Al investigar y abordar continuamente estos problemas durante el horario comercial normal, se crean simultáneamente resultados de aprendizaje organizacional.
Rascal Monkey es solo un ejemplo de cómo incorporar el aprendizaje en el trabajo diario. La historia también muestra cómo las organizaciones de aprendizaje piensan acerca de las fallas, los accidentes y los errores, viéndolos como oportunidades para aprender, no como oportunidades para castigar.
19.1 Construyendo una cultura de justicia y aprendizaje 181
Debido a los problemas de diseño inevitables en los sistemas complejos que construimos, no debería haber necesidad de "nombrar, culpar y avergonzar" a los responsables de las fallas. El objetivo siempre debe ser maximizar las oportunidades para el aprendizaje organizacional, con el objetivo de ver errores, errores, errores garrafales, deslices, etc. desde una perspectiva de aprendizaje.
Cuando los ingenieros cometen errores, si pueden brindar información detallada con una sensación de seguridad, no solo estarán dispuestos a asumir la responsabilidad de las cosas, sino que también ayudarán con entusiasmo a otros a evitar que ocurran los mismos errores. Esto crea aprendizaje organizacional.
Hay dos prácticas efectivas que ayudan a crear una cultura de aprendizaje imparcial: el análisis post-mortem libre de culpas y la introducción de fallas humanas controladas en entornos de producción para crear oportunidades para problemas inevitables en sistemas complejos.
19.2 Celebrar una reunión post mortem libre de culpas 182
Para ayudar a crear una cultura de justicia, cuando ocurren accidentes e incidentes críticos (p. ej., fallas en la implementación, incidentes de producción que afectan a los clientes), debe haber una autopsia sin culpa después de que se haya resuelto el problema.
En una reunión post-mortem sin culpa, hacemos lo siguiente:
Construimos una línea de tiempo que reúne todos los detalles sobre la falla de
múltiples Permitimos
y alentamos a aquellos que cometen errores a convertirse en expertos en educar a otros para que no cometan los mismos errores en el futuro;
Crear un espacio libre de toma de decisiones donde las personas decidan La toma de decisiones se juzga después de los hechos;
Desarrollar contramedidas para prevenir incidentes similares y garantizar que estas contramedidas, las fechas objetivo y las personas responsables estén documentadas para que puedan ser rastreadas.
Para obtener suficiente comprensión, las siguientes partes interesadas deben estar presentes en la reunión:
Personas involucradas en la toma de decisiones sobre el problema;
Personas que identifican el problema;
Personas
que responden al problema;
Personas que diagnostican el problema ;
Cualquier persona interesada en asistir a la conferencia.
Es útil tener a alguien capacitado y no relacionado con el incidente para organizar y dirigir la reunión
, especialmente durante las primeras reuniones post mórtem. El uso de "debería haber" o "debería haber sido" debe prohibirse explícitamente durante las reuniones y resoluciones. Podría han sido", porque son declaraciones contrafácticas,
La reunión debe permitir suficiente tiempo para intercambiar ideas y decidir sobre las respuestas. Una vez que se han identificado las contramedidas, se deben priorizar los esfuerzos, asignar las personas responsables y programar la implementación.
19.3 Poner a disposición del público los resultados de la autopsia lo más ampliamente posible184
Después de la reunión post-mortem de no culpabilización, las actas y toda la documentación relacionada deben estar ampliamente disponibles.Idealmente, la información publicada debe estar en una ubicación centralizada y de fácil acceso para toda la organización, de los accidentes anteriores.
Hacer que estos documentos post mórtem estén ampliamente disponibles y animar a otros en la organización a leerlos puede mejorar el aprendizaje organizacional.
19.4 Reducir la tolerancia a los accidentes y buscar señales de falla más débiles 185
Cuando se trabaja en sistemas complejos, la amplificación de señales de fallas débiles es fundamental para protegerse contra fallas catastróficas. En 2003, el transbordador espacial Columbia explotó al volver a entrar en 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 cuando despegó.
Algunos ingenieros de la NASA de nivel medio habían informado del incidente antes de que Columbia regresara, pero sus comentarios no se tomaron en serio. Los problemas de burbujas no son nada nuevo. La deriva de espuma ha dañado naves espaciales en lanzamientos anteriores, pero nunca causó un accidente importante. La NASA caracterizó el incidente como un problema de mantenimiento y no tomó ninguna medida. Era demasiado tarde hasta que ocurrió el accidente.
19.5 Redefiniendo el fracaso para fomentar la evaluación de riesgos 186
19.6 Inyectando fallas en producción para recuperar y aprender 186
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 mediante la realización de pruebas de forma regular (incluso de forma continua).
La capacidad de recuperación 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 ensayar las fallas a escala. Esto permite confiar en que el sistema se recuperará solo en caso de un incidente, idealmente sin siquiera afectar a los clientes.
19.7 Crear un día de simulacro de falla 187
El objetivo del día de simulacro es ayudar al equipo a simular y ensayar incidentes para que sean capaces de operar. Primero, planifique para un evento catastrófico, como simular la destrucción de un centro de datos completo en algún momento en el futuro. Luego, dé tiempo al equipo para eliminar todos los puntos únicos de falla y cree los procedimientos de monitoreo necesarios, los procedimientos de conmutación por error, etc.
Los equipos definen y ejecutan varios simulacros en los días de simulacro. Por ejemplo, realizando una conmutación por error de la base de datos o interrumpiendo una conexión de red crítica, exponiendo un problema en un proceso definido.
Al crear gradualmente servicios más resistentes y un mayor grado de certeza durante los días de simulacro, podemos reanudar las operaciones normales en caso de un evento inesperado mientras creamos más oportunidades de aprendizaje y una organización más resistente.
Podemos practicar, construir el manual de operaciones requerido. Otro resultado del día de práctica fue que la gente realmente sabía a quién llamar y hablar.
19.8 Resumen 189
La única ventaja competitiva sostenible que tiene una organización es la capacidad de aprender más rápido que sus rivales.
Capítulo 20 Convertir la experiencia local en una mejora global 190
20.1 Uso de salas de chat y chatbots para acumular automáticamente conocimiento organizacional 190
20.2 Procesos automatizados y estandarizados en software para facilitar la reutilización 192
20.3 Creación de un único repositorio de código fuente compartido en toda la organización 192
Lo que mantenemos en el repositorio de código fuente compartido no es solo el código fuente, sino también artefactos que contienen otras experiencias de aprendizaje y conocimiento:
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;
Estándares y herramientas de prueba, incluidos los aspectos de seguridad;
Herramientas de canalización de implementación;
Herramientas de monitoreo y análisis;
Tutoriales y estándares.
20.4 Uso de documentación de pruebas automatizadas y prácticas de comunicación para transferir conocimientos 194
El beneficio de adoptar la práctica del desarrollo basado en pruebas (TDD), que consiste en escribir pruebas automatizadas antes de escribir el código, es que las pruebas están casi completamente automatizadas. Este principio convierte un conjunto de pruebas en una especificación de sistema activa y actualizada. Cualquier ingeniero que quiera saber cómo usar el sistema puede consultar el conjunto de pruebas para encontrar ejemplos prácticos del uso de la API del sistema.
20.5 Diseño de operaciones mediante la identificación de requisitos no funcionales 194
Los siguientes son ejemplos de requisitos no funcionales que deben implementarse:
Telemetría adecuada para diversas aplicaciones y entornos;
Capacidad para realizar un seguimiento preciso de las dependencias;
Servicios que sean resistentes y se degraden con gracia; Capacidad para archivar datos para administrar conjuntos de datos de producción; Capacidad para buscar y comprender fácilmente la información de registro de varios servicios; Capacidad para realizar un seguimiento de las solicitudes de los usuarios a través de múltiples servicios; Facilidad de uso utilizando interruptores de funciones u otros métodos, Configuración centralizada del tiempo de ejecución.
20.6 Incorporación de historias de usuario de operaciones reutilizables en el desarrollo 195
20.7 Asegurar que la selección de tecnología ayude a lograr las metas organizacionales 195
Por ejemplo, solo un equipo tiene la experiencia de un servicio crítico, y solo este equipo puede realizar cambios o soluciones al problema, lo que forma un cuello de botella. En otras palabras, es posible que hayamos optimizado la productividad del equipo pero, sin darnos cuenta, obstaculicemos el logro de los objetivos de la organización.
Para garantizar una investigación profunda sobre ciertas tecnologías específicas, esperamos que el equipo de operación y mantenimiento participe en la selección de tecnología del entorno de producción,
Todas las ventajas de las bases de datos sin esquema se ven superadas por los problemas operativos que causan. Estas preocupaciones incluyen el registro, la creación de gráficos, la supervisión, la telemetría de producción, la copia de seguridad y la recuperación, etc., y una gran cantidad de problemas que, por lo general, no necesitan preocupar a los desarrolladores. El resultado final es que renunciamos a MongoDB,
20.8 Resumen 197
Capítulo 21 Reservar tiempo para el aprendizaje y la mejora organizacional 198
21.1 Prácticas institucionalizadas para el pago de la deuda técnica 199
Una de las formas más fáciles de hacer esto es programar y realizar bombardeos kaizen durante días o semanas en los que todos los miembros del equipo (o la organización en su conjunto) se organizan para abordar las inquietudes; no se permite el trabajo funcional. Puede centrarse en un punto problemático de código, entorno, arquitectura, herramientas, etc. Estos equipos a menudo están formados por ingenieros de desarrollo, operaciones y seguridad de la información, que abarcan todo el flujo de valor.
El objetivo durante estos blitzk no es simplemente experimentar e innovar para probar nuevas tecnologías, sino mejorar el trabajo diario, como encontrar soluciones en el trabajo diario. Si bien la experimentación conducirá a ciertas mejoras, el enfoque de Improvement Blitz es resolver problemas específicos que se encuentran en el trabajo diario.
Cada pocos meses se lleva a cabo un hackathon, donde todos
crean prototipos de su nueva idea. Finalmente, todo el equipo se reúne para revisar todo el trabajo realizado. Muchos de nuestros productos más exitosos provienen de hackatones, incluidos Timeline, chat, video, marcos de desarrollo móvil y algunas de las infraestructuras más importantes, como el compilador HipHop. ", convirtió todos los servicios de producción de Facebook de archivos de programa PHP interpretados a binarios C++ compilados. HipHop permitió que la plataforma de Facebook manejara cargas de producción 6 veces más altas que los programas PHP nativos.
A través de Kaizen Blitz y Hack Weeks regulares, todos en el flujo de valor se enorgullecen de apropiarse de las innovaciones, incorporando continuamente mejoras en el sistema, aumentando aún más la seguridad, la confiabilidad y el aprendizaje.
21.2 Enseñanza y aprendizaje para todos 200
Tiempo de estudio semanal programado para los compañeros. Durante el tiempo de estudio de dos horas, cada compañero tiene que aprender por sí mismo y enseñar a los demás. Los temas trataban sobre lo que querían aprender, algunos sobre tecnología, otros sobre desarrollo de software nuevo o métodos de mejora de procesos, y algunos incluso sobre cómo administrar mejor sus carreras.
21.3 Compartir experiencias en conferencias DevOps 201
21.4 Consultores internos y coaches de prácticas de comunicación 203
Google tiene una política de tiempo de innovación del 20 % que permite a los desarrolladores dedicar un día a la semana a proyectos relacionados con Google fuera de su responsabilidad principal. Algunos ingenieros con ideas afines forman grupos espontáneos para enfocarse en mejorar el blitz usando este 20% de su tiempo.
21.5 Resumen 204
En este capítulo se describe cómo establecer un conjunto de rutinas que ayuden a reforzar el aprendizaje permanente y una cultura que valore mejorar el trabajo del día a día. Esto se puede lograr reservando tiempo para pagar la deuda técnica, creando foros donde las personas puedan aprender y ser mentoras entre sí tanto dentro como fuera de la organización, y permitir que los expertos ayuden a los equipos internos a través del entrenamiento, la consultoría o simplemente estableciendo una reunión cara a cara. -cara el tiempo.
21.6 Resumen de la Sección 5 204
Parte VI Prácticas técnicas para integrar la seguridad de la información, la gestión de cambios y el cumplimiento
Capítulo 22 Hacer que la seguridad de la información forme parte del trabajo diario de todos 207
22.1 Integración de la seguridad en demostraciones de iteraciones de desarrollo 207
22.2 Integración de la seguridad en el seguimiento de errores y las sesiones post mórtem 208
Un sistema de seguimiento de problemas para los equipos de desarrollo y operaciones para administrar todos los problemas de seguridad conocidos para garantizar la visibilidad del trabajo de seguridad y la capacidad de priorizarlo junto con otros trabajos.
Incorporamos todos los temas de seguridad al sistema JIRA. Este es un sistema que todos los ingenieros usan a diario para etiquetar los problemas como P1 y P2,
Cada vez que surge un problema de seguridad, hacemos una sesión post mórtem porque educa mejor a los ingenieros sobre cómo evitar que los problemas vuelvan a ocurrir y es un mecanismo excelente para transferir conocimientos de seguridad a los equipos de ingeniería.
22.3 Integración de controles de seguridad preventivos en repositorios de código fuente compartido y servicios compartidos 208
Agregue cualquier mecanismo y herramienta que ayude a garantizar la seguridad de la aplicación y el entorno al repositorio de código fuente compartido. Agregaremos bibliotecas seguras que cumplan con objetivos específicos de seguridad de la información, como bibliotecas y servicios de autenticación y cifrado.
Podemos brindar capacitación en seguridad a los equipos de desarrollo y operaciones, y ayudarlos a revisar los productos del proyecto para garantizar que los objetivos de seguridad se implementen correctamente, especialmente cuando el equipo utiliza estas herramientas por primera vez.
22.4 Integración de la seguridad en la canalización de implementación 209
Las pruebas de seguridad de la información se automatizarán tanto como sea posible en este paso. Las pruebas de seguridad se pueden ejecutar junto con todas las demás pruebas en la canalización de implementación siempre que un desarrollador u
operador confirme el código, incluso en las primeras etapas de un proyecto de software.
El objetivo es proporcionar comentarios rápidos a Dev y Ops para que puedan recibir una notificación cuando envíen un cambio con un riesgo de seguridad. Esto permite una rápida detección y solución de problemas de seguridad,
22.5 Garantizar la seguridad de la aplicación 210
Estas pruebas se ejecutan continuamente en la canalización de implementación. Esperamos incluir lo siguiente como parte de las pruebas.
Análisis estático: se examinarán todos los posibles comportamientos en tiempo de ejecución del código del programa y se buscarán fallas de codificación, puertas traseras y código potencialmente malicioso Análisis dinámico
: las pruebas dinámicas supervisan elementos como la memoria del sistema, el comportamiento funcional, el tiempo de respuesta y el rendimiento general del sistema .
Análisis de componentes dependientes: realiza un inventario de todos los paquetes y bibliotecas de los que dependen los archivos binarios y ejecutables y garantiza que estos componentes dependientes (a menudo fuera de nuestro control) estén libres de vulnerabilidades o archivos binarios maliciosos.
Integridad del código fuente y firma de código: todos los desarrolladores deben tener su propia clave PGP y todo lo comprometido con el sistema de control de versiones debe estar firmado
Deberíamos definir patrones de diseño que ayuden a los desarrolladores a escribir código que evite el abuso, como establecer un límite de velocidad en un servicio, convertir un botón de envío presionado en un estado en el que no se puede hacer clic. OWASP publica una gran cantidad de orientación útil, que incluye lo siguiente:
Cómo almacenar contraseñas;
Cómo lidiar con contraseñas olvidadas;
Cómo lidiar con el registro;
Cómo prevenir vulnerabilidades de secuencias de comandos entre sitios (XSS).
22.6 Protección de la cadena de suministro de software 214
Al seleccionar software, detectamos si los proyectos de software se basan en componentes o bibliotecas con vulnerabilidades conocidas y ayudamos a los desarrolladores a elegir cuidadosamente qué componentes utilizar.
22.7 Protección del medio ambiente 215
Utilice pruebas automatizadas para asegurarse de que todas las configuraciones necesarias se hayan aplicado correctamente, incluida la configuración de refuerzo de la seguridad, la configuración de seguridad de la base de datos, la longitud de la clave y más. Además, utilizaremos la prueba para escanear el entorno en busca de vulnerabilidades conocidas.
22.8 Integración de la seguridad de la información en la telemetría de producción 216
Implementamos los sistemas necesarios de monitoreo, registro y alerta, y al integrar la telemetría de seguridad en las herramientas utilizadas por el desarrollo, el control de calidad y las operaciones, todos en el flujo de valor pueden ver cómo se comportan las aplicaciones y los entornos frente a amenazas maliciosas, incluidos: atacantes intenta constantemente explotar vulnerabilidades, obtener acceso no autorizado, plantar puertas traseras, realizar fraudes, denegación de servicio y otras actividades destructivas.
22.9 Integración de un sistema de telemetría seguro en la aplicación 217
Para que se produzca la detección, se debe crear un sistema de telemetría asociado en la aplicación.
Ejemplos de esto incluyen:
Inicios de sesión de usuario exitosos y no exitosos;
Restablecimientos de contraseña de usuario;
Restablecimientos de dirección de correo electrónico de usuario;
Cambios de tarjeta de crédito de usuario.
Por ejemplo, los inicios de sesión de fuerza bruta son una señal temprana de intentos de obtener acceso no autorizado, por lo que se puede mostrar la proporción de inicios de sesión fallidos y exitosos. Por supuesto, debemos establecer una estrategia de alerta para estos eventos importantes para garantizar que los problemas se puedan detectar y corregir rápidamente.
22.10 Establecimiento de un sistema de telemetría seguro en el entorno 217
Cree sistemas de telemetría completos en entornos, especialmente para componentes que se ejecutan en una infraestructura no administrada (p. ej., entornos alojados, nube). Ciertos eventos requieren monitoreo y alerta, que incluyen:
Cambios en el sistema operativo (p. ej., en producción, construcción de infraestructura);
Cambios en el grupo de seguridad;
Cambios en la configuración (p. ej., OSSEC, Puppet, Chef, Tripwire);
Cambios en la infraestructura de la nube (p. ej., VPC, grupos de seguridad, usuarios y permisos);
Intentos de XSS (es decir, “ataques de secuencias de comandos entre sitios”);
Intentos de SQLi (es decir, “ataques de inyección de SQL”);
Errores del servidor web (por ejemplo, 4×× y 5×× errores).
También confirmemos que el registro está configurado correctamente para que toda la telemetría se envíe al lugar correcto. Al monitorear ataques, además de registrar eventos, también puede optar por bloquear el acceso,
En lugar de formar un departamento de seguridad de la información o antifraude separado para lograr estos objetivos, estas responsabilidades se integran en el flujo de valor de DevOps. Se creó un sistema de telemetría relacionado con la seguridad para mostrarlo junto con las métricas de monitoreo orientadas a desarrollo y operaciones que todos los ingenieros de Etsy se preocupan a diario, incluidas las siguientes.
Terminación anormal de los programas de producción (p. ej., fallas de segmento, volcados del núcleo, etc.): "De particular preocupación es por qué ciertos procesos constantemente tienen volcados del núcleo a lo largo de la producción que se activan
todo repetidamente. También son motivo de preocupación los mensajes de error HTTP '500 Internal Server Error'. Estos indicadores indican que se está explotando una vulnerabilidad, alguien quiere obtener acceso no autorizado a nuestro sistema y la aplicación necesita parchearse con urgencia". Errores de sintaxis de base de datos: "Siempre estamos buscando errores de sintaxis de base de datos
en código: errores que están abiertos a ataques de inyección SQL o ataques continuos. Por lo tanto, no podemos tolerar errores de sintaxis de base de datos en el código, aún se usa para comprometer los principales vectores de ataque del sistema". Señales de ataques de inyección SQL: "
Hay es una prueba absurdamente simple: solo necesitamos configurar una alarma en el campo de entrada del usuario con la palabra clave UNION ALL, porque casi siempre indica un ataque de inyección SQL. También agregamos pruebas unitarias para asegurarnos de que este tipo de entrada de usuario no controlada nunca se realice en una consulta de base de datos".
22.11 Protección de la tubería de implementación 219
Para proteger las canalizaciones de compilación, integración o implementación continuas, las mitigaciones también pueden incluir:
Reforzar los servidores de integración y compilación continua y garantizar que se puedan reconstruir en un sistema automatizado Los servidores de compilación e integración están comprometidos;
Revisar cualquier cambio realizado en el sistema de control de versiones - programar en pares en el momento de la confirmación o configurar un proceso de revisión
de código entre la confirmación y la combinación troncal, lo que evita que los servidores de integración continua se ejecuten sin protección o red) se registra en el código base
Garantizar que cada proceso de CI se ejecuta en su propio contenedor aislado o máquina virtual;
Asegurar que las credenciales de control de versiones utilizadas por el sistema de CI son de solo lectura.
22.12 Resumen 219
Capítulo 23 Protección de la canalización de implementación 220
23.1 Integración de la seguridad y el cumplimiento en el proceso de aprobación de cambios 220
23.2 Reclasificación de numerosos cambios de bajo riesgo como cambios estándar 221
23.3 Cómo se manejan los cambios de rutina 222
23.4 Reducción de la dependencia de la separación de funciones 224
La segregación de funciones ralentiza y reduce la capacidad de los ingenieros para obtener comentarios sobre su trabajo, lo que podría dificultar los requisitos anteriores. Esto impide que los ingenieros asuman toda la responsabilidad por la calidad de su trabajo y reduce la capacidad de las empresas para generar aprendizaje organizacional.
Siempre que sea posible, debe evitarse el uso de la separación de funciones como control. Deberíamos optar por la programación por pares, el check-in de códigos de inspección continua y la revisión de códigos, etc., que pueden proporcionar la garantía necesaria para la calidad del trabajo.