Cómo opera Microsoft en sistemas fiables con DevOps

Microsoft ha estado operando en plataformas en línea complejas desde los primeros días del Internet comercial. Durante todo este tiempo, hemos ido evolucionado una serie de prácticas esenciales para que los sistemas estén siempre disponibles, gocen de un buen estado y sean seguros. Estas prácticas forman parte de una iniciativa más grande para mantener y mejorar una cultura de sitio activo.

Cultura de sitio activo

La cultura de sitio activo es la pieza central de una organización para priorizar la experiencia y la fiabilidad del sitio activo sobre todo lo demás. Después de todo, los clientes pueden tratar con proveedores de servicios de forma bastante sencilla hoy en día con los servicios basados en internet y en la nube, dando una considerablemente importancia a la confianza del cliente. El sitio activo siempre debe estar disponible y cumplir lo que promete a los clientes.

Existen varios factores que contribuyen a una cultura de sitio activa adecuada.

El sitio activo primero

Colocar primero la experiencia del sitio activo es integral para una plataforma de éxito. Los equipos no pueden poner toda su atención en las nuevas y más destacadas funciones e ignorar el entorno en el que se presenten dichas funciones a los usuarios. Basamos nuestro hacer en prácticas de implementación seguras que permiten garantizar que nuestros clientes disfruten de un acceso ininterrumpido a la plataforma. Esto puede resultar especialmente complicado cuando se trata de publicar actualizaciones de servicio con versiones sin tiempo de inactividad.

Controlar la exposición a través de marcas de funciones

A medida que implementamos a través de nuestros anillos y fases, controlando la exposición con marcas de funciones, ocasionalmente detectamos un problema en la fase de producción. A pesar de toda la automatización y comentarios, hay cosas que a veces siguen pasando. Como se suele decir, ¡la producción es lo que tiene!

Normalmente, los controles de estado y la telemetría nos avisa cuando hay algo que no está bien. Un desarrollador puede crear una rama de main, aplicar una corrección y solicitar la incorporación de cambios en main. Mantener el mismo flujo de trabajo general significa que los desarrolladores no tengan que cambiar el contexto ni aprender un proceso diferente para un cambio de código diferente.

Para hacer una implementación de revisiones, se necesita realizar un paso más, que consiste en seleccionar el cambio en la rama de la versión. Ejecutamos una implementación de revisión fuera de la rama de la versión actual cada día de la semana, aunque también esto lo podemos según se pida si existen correcciones urgentes. La corrección se aplica realmente primero en la producción fuera de la rama de la versión. Pero como desarrollamos primero en main, sabemos que no se retrocederá del siguiente sprint cuando se cree una nueva rama de versión a partir de main.

Las versiones de productos locales son en gran medida las mismas, aunque sin los anillos y las fases de implementación. Además, dado que realizamos más pruebas manuales en diferentes configuraciones y formas de datos, hay una cola más larga entre cortar la rama de la versión y poner el producto en manos de los clientes.

La seguridad es algo que hay que tomarse personalmente

El objetivo es hacer que las vulnerabilidades sean reales y personales. Esto garantiza que la gente se preocupe de verdad. También hacemos un amplio uso de juegos de guerra para detectar y evitar riesgos de seguridad en todo el sistema, ya sea en el código o no. Cuando el equipo rojo puede dar cuenta de han entrado en el código al activar un cuadro de diálogo al revés, esto motiva al propietario del código para solucionar el problema y asegurarse de que no se vuelva a producir en ningún otro aspecto. Ese tipo de competencia es mucho más real y personal que una advertencia de análisis estática sobre un riesgo de XSS potencial. Creamos este tipo de cultura y dinámica a través de juegos de guerra y otros ejercicios de seguridad. La gente tiene disposición a piratear el código de los demás o de ser capaz de bloquear los ataques de los otros. Esto infunde una cultura de código segura.

No podemos planear todos las formas de ataque, pero lo que podemos hacer es suponer que va a haber una vulneración y prever lo rápido que podemos reaccionar ante esta filtración. Muchos de las tareas de seguridad se han movido en torno a esta idea para nuestros equipos.

Además y por último, errar es humano. A veces son descuidados y hacen cosas como almacenar contraseñas en recursos compartidos de archivos. Podemos decirles que no lo hagan así y formarles en seguridad, así como muchas otras cosas. La mayoría de las personas aprenden, pero solo se necesita una persona para llevar al traste el sistema. Se puede tener todo tipo de listas de procedimientos recomendados, pero a menos que lo materialice de verdad, debe asumir que las personas van a cometer errores. Para esto se necesita un cierto nivel de supervisión para garantizar que se siguen los procesos más esenciales.

El equipo de ingeniería es más que un grupo de colaboradores de operaciones

Desde el principio, hemos aprendido que hacer que el sitio activo es una parte importante de las responsabilidades del equipo de ingeniería. Eso supuso un gran descubrimiento para nosotros porque, en el pasado, una persona implementaba algo, descansaba el fin de semana y al volver el lunes, había recibido 900 problemas de clientes que los equipos de atención al cliente y de operaciones tenían que solucionar todo el fin de semana. Es importante que el equipo de ingeniería se encargue de los problemas del sitio activo. De lo contrario, no hay ningún incentivo para crear sistemas que eviten esos problemas. Esto lo tiene muy presente, cuando le llaman a las 2 de la mañana para arreglar algo que rompió.

A medida fuimos desarrollando esta responsabilidad, la frase “El sitio activo es lo más importante que hacemos” se convirtió en la máxima de todo el equipo. Lo que tienen ellos ahora es la experiencia del cliente y no es solo algo impuesto. Es algo por lo que la gente cuenta con nosotros y nos enorgullecemos de ello. Debe ser un aspecto diferenciador de nuestro producto.

La telemetría en la producción es el latido que marca el servicio

Para sobrevivir en un mundo con un ritmo tan rápido donde prácticamente cualquier cosa puede ir mal, necesitamos sistemas de alertas excelentes. Las alertas poco funcionales, las alertas redundantes o los volúmenes de alertas abrumadores consiguen que se ignoren todas las alertas. Es fácil crear muchas alertas de más, por lo que el proceso se reduce en una simple pregunta: ¿Es viable responder a esa alerta? Esto garantiza que nos ocupemos de los problemas reales del cliente y los solucionemos lo más rápido posible.

Cuando el equipo de ingeniería respondía a alertas funcionales, observaban que muchos problemas de los que surgen, especialmente en mitad de la noche, suelen tener correcciones similares, al menos temporalmente. Esto daba lugar a que se centren más en los sistemas que estaban mejor en conmutación por error y recuperación automática. Ahora los problemas se producen, generan alertas y después se solucionan lo suficiente para que el equipo de ingeniería espere hasta la mañana para corregirlos. Esto no habría ocurrido si el equipo de ingeniería se hubiera ocupado de los pequeños elementos de código que hicieron que otras personas se quedaran en vela. Ahora trabajan para equilibrar estas mejoras, no para garantizar la velocidad de las funciones, sino por la velocidad de mejora del proceso de ingeniería.

Resumen

La aplicación de una cultura de sitio activa ha afectado a la forma en que Microsoft compila y entrega el software. Al convertir a los equipos de ingeniería en una pieza clave de la seguridad y las operaciones, la calidad de nuestro código y la experiencia del usuario final han mejorado significativamente. Participar de manera integral en las operaciones ha hecho que la ingeniería sea una parte interesada vital, lo que da lugar a sistemas diseñados para mejorar las operaciones.