Funcionamiento de Microsoft de sistemas confiables con DevOps

Microsoft ha estado operando plataformas en línea complejas desde los primeros días de internet comercial. A lo largo del camino, hemos evolucionado un conjunto sustancial de prácticas para mantener los sistemas disponibles, correctos y seguros. Estas prácticas forman parte de una iniciativa más grande para mantener y mejorar una cultura de sitio activa.

Referencia cultural del sitio activo

La cultura del sitio activo es el foco de una organización para priorizar la experiencia y la confiabilidad del sitio activo en todo lo demás. Después de todo, los clientes pueden moverse a través de proveedores de servicios de forma bastante sencilla hoy en día con los servicios basados en internet y en la nube, ampliando considerablemente la importancia de la confianza del cliente. El sitio activo siempre debe estar disponible y realizar lo prometido a los clientes.

Hay varios factores que contribuyen a una cultura de sitio activa correcta.

Sitio activo primero

Colocar primero la experiencia del sitio activo es integral para una plataforma correcta. Teams no puede centrarse en las características nuevas y brillantes y ignorar la avenida en la que se presentan esas características a los usuarios. Nos basamos en prácticas de implementación seguras que ayudan a garantizar que nuestros clientes disfruten del 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 características

A medida que implementamos a través de nuestros niveles y fases, controlando la exposición con marcas de características, ocasionalmente detectamos un problema en producción. A pesar de toda nuestra automatización y opiniones, las cosas a veces siguen sucediendo. Como dicen, no hay lugar como producción!

Normalmente, la supervisión de estado y la telemetría nos alertan cuando algo no es correcto. Un desarrollador puede crear una rama de main, realizar una corrección y solicitarle la incorporación de cambios en main. Mantener el mismo flujo de trabajo general significa que los desarrolladores no tienen que cambiar el contexto ni aprender un proceso diferente para un cambio de código diferente.

Para abordar una implementación de revisiones, se requiere un paso más, que consiste en seleccionar el cambio en la rama de versión. Ejecutamos una implementación de revisiones fuera de la rama de versión actual cada día de la semana, aunque también podemos hacerlo a petición para correcciones urgentes. La corrección realmente alcanza la producción fuera de la rama de versión primero. Pero dado que desarrollamos en main primer lugar, sabemos que no retrocedará el 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 niveles de implementación y las fases. 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 versión y poner el producto en manos de los clientes.

La seguridad debe tomarse personalmente

El objetivo es hacer que las vulnerabilidades sean reales y personales. Esto garantiza que la gente realmente se preocupa. También hacemos un amplio uso de juegos de guerra para encontrar y abordar riesgos de seguridad en todo el sistema, ya sea en código o no. Cuando el equipo rojo puede mostrar que entraron en código al activar un cuadro de diálogo al revés, realmente motiva al propietario del código para solucionar el problema y asegurarse de que no se vuelva a producir en ningún otro lugar. Ese tipo de competencia es mucho más real y personal que una advertencia de análisis estático 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 se enorgullece de piratear el código de los demás o de ser capaz de bloquear los intentos. Esto infunde una referencia cultural de código segura.

No podemos planear todos los vectores de ataque, pero lo que podemos hacer es suponer que va a haber una infracción y planear la rapidez con la que podemos reaccionar ante esa infracción. Muchos de los trabajos de seguridad han estado en torno a eso para nuestros equipos.

Por último, los humanos cometen errores. A veces se diferencen y hacen cosas como almacenar contraseñas en recursos compartidos de archivos. Podemos decirles que no y podemos enviarlos a la formación de seguridad y podemos hacer todo tipo de cosas. La mayoría de las personas aprenden, pero solo se necesita una persona para romper el sistema. Puede tener todo tipo de listas de procedimientos recomendados, pero a menos que esté haciendo eso real, debe asumir que las personas van a cometer errores. Esto requiere un cierto nivel de supervisión para garantizar que se siguen los procesos críticos.

La ingeniería es más que un asociado de operaciones

Hemos aprendido pronto para hacer que el sitio en directo sea una parte importante de las responsabilidades del equipo de ingeniería. Eso fue enorme para nosotros porque, en el pasado, una persona podría ir a implementar algo, salir para el fin de semana y volver el lunes para encontrar 900 problemas de clientes que los equipos de atención al cliente y de operaciones estaban tratando con todo el fin de semana. Es importante que la ingeniería pague el precio de los problemas del sitio activo. De lo contrario, no hay ningún incentivo para crear sistemas que eviten esos problemas. Cuando te llames a las 2 A.M. para arreglar algo que rompiste, recuerdas.

A medida que evolucionamos esta responsabilidad, Live site es lo más importante que hacemos se convirtió en el mantra de todo el equipo. Es la experiencia del cliente que tienen ahora mismo y no es solo un impuesto. En realidad es algo que la gente cuenta de nosotros y nos enorgullecemos de ello. Debe ser una característica diferenciadora de nuestro producto.

La telemetría de producción es el latido del servicio.

Para sobrevivir en el mundo de ritmo rápido donde prácticamente cualquier cosa puede ir mal, necesitamos sistemas de alertas excelentes. Las alertas no autorizadas, las alertas redundantes o los volúmenes de alertas abrumadores hacen que se omitan todas las alertas. Es fácil crear demasiadas alertas, por lo que el proceso realmente se destila a una pregunta sencilla: ¿Es esta alerta procesable? Esto garantiza que estamos participando en los problemas adecuados del cliente y los trataremos lo más rápido posible.

Como el equipo de ingeniería se ha centrado en alertas accionables, observaron que muchos problemas que surgen, especialmente en medio de la noche, tienden a tener correcciones similares, al menos temporalmente. Esto dio lugar a un enfoque en los sistemas que estaban mejor en la conmutación por error y la recuperación automática. Ahora los problemas se producen, generan alertas y, a continuación, se corrigen lo suficiente para que el equipo de ingeniería espere hasta la mañana para corregir. Esto no habría ocurrido si el equipo de ingeniería acaba de empujar los bits que mantuvieron a otras personas en la noche. Ahora trabajan para equilibrar estas mejoras como parte de la velocidad de las características, pero la velocidad de mejora de la ingeniería.

Resumen

La adopción de una cultura de sitio activa ha afectado a la forma en que Microsoft compila y entrega software. Al convertir a los equipos de ingeniería en una parte clave de la seguridad y las operaciones, la calidad de nuestro código y la experiencia del usuario final han mejorado drásticamente. Ser un participante completo en las operaciones ha hecho que la ingeniería sea una parte interesada clave, lo que da lugar a sistemas diseñados para mejorar las operaciones.