La traducción del artículo fue preparada especialmente para estudiantes del curso de Prácticas y herramientas de DevOps , que comienza hoy.
¿Alguna vez has lanzado un nuevo servicio en producción? ¿O tal vez comprometido en el mantenimiento de tales servicios? Si es así, ¿qué seguiste? ¿Qué es bueno para la producción y qué es malo? ¿Cómo capacita a los nuevos miembros del equipo para liberar o mantener los servicios existentes?
La mayoría de las compañías en términos de prácticas de explotación industrial finalmente llegan a los enfoques del "Salvaje Oeste". Cada equipo, a través de prueba y error, determina de forma independiente las herramientas y las mejores prácticas. Pero esto a menudo afecta no solo el éxito de los proyectos, sino también a los ingenieros.
El método de prueba y error crea un entorno en el que la búsqueda de perpetradores y la transferencia de responsabilidad son comunes. Con este comportamiento, se vuelve cada vez más difícil aprender de los errores y no repetirlos nuevamente.
Organizaciones exitosas:
- reconocer la necesidad de pautas para la producción,
- aprender las mejores prácticas
- iniciar una discusión sobre la preparación para la producción al desarrollar nuevos sistemas o componentes,
- Garantizar el cumplimiento de las normas de preparación para la producción.
La preparación para la producción incluye un proceso de revisión. Una revisión puede ser en forma de una lista de verificación o un conjunto de preguntas. Una revisión se puede hacer de forma manual, automática o ambas. En lugar de listas de requisitos estáticos, se pueden hacer plantillas de listas de verificación que se pueden adaptar a necesidades específicas. De esta manera, los ingenieros pueden recibir una forma de heredar conocimiento y suficiente flexibilidad cuando sea necesario.
¿Cuándo verificar la disponibilidad del servicio para la producción?
Es útil realizar una verificación de preparación para la producción no solo inmediatamente antes del lanzamiento, sino también cuando se transfiere a otro equipo operativo o nuevo empleado.
Verificar cuando:
- Lanzamiento de un nuevo servicio en producción.
- Transfiera la operación del servicio de producción a otro equipo, como SRE.
- Transfiera la operación del servicio de producción a nuevos empleados.
- Organizar soporte técnico.
Lista de verificación de preparación de producción
Hace algún tiempo, como ejemplo,
publiqué una lista de verificación para verificar la preparación para la producción. Aunque esta lista apareció mientras trabajaba con clientes de Google Cloud, será útil y aplicable fuera de Google Cloud.
Diseño y desarrollo
- Diseñe un proceso de compilación reproducible que no requiera acceso a servicios externos y no dependa de la falla de los sistemas externos.
- Durante el período de diseño y desarrollo, defina e instale SLO para sus servicios.
- Documente las expectativas de disponibilidad de servicios externos de los que depende.
- Evite un solo punto de falla eliminando las dependencias de un recurso global. Replicar el recurso o usar la opción alternativa cuando el recurso no esté disponible (por ejemplo, valor codificado).
Gestión de la configuración
- Las configuraciones estáticas, pequeñas y no secretas se pueden pasar a través de las opciones de línea de comandos. Por lo demás, use los servicios de almacenamiento de configuración.
- La configuración dinámica debe tener configuraciones de respaldo en caso de que el servicio de configuración no esté disponible.
- La configuración del entorno de desarrollo no debe estar relacionada con la configuración de producción. De lo contrario, puede conducir al acceso a los servicios de producción desde el entorno de desarrollo, lo que puede causar problemas de privacidad y pérdida de datos.
- Documente lo que se puede configurar dinámicamente y describa el comportamiento alternativo si el sistema de entrega de configuración no está disponible.
Gestión de lanzamientos
- Documente el proceso de lanzamiento en detalle. Describa cómo las versiones afectan los SLO (por ejemplo, un aumento temporal en la latencia debido a errores de caché).
- Documentar las liberaciones canarias.
- Desarrolle un plan para analizar las liberaciones canarias y, si es posible, mecanismos automáticos de reversión.
- Asegúrese de que las reversiones puedan usar los mismos procesos que la implementación.
Idoneidad para el monitoreo (Observabilidad)
- Asegúrese de estar compilando el conjunto de métricas requeridas para SLO.
- Asegúrese de poder distinguir entre los datos del cliente y del servidor. Esto es importante para la resolución de problemas.
- Establecer alertas para reducir los costos laborales. Por ejemplo, elimine las alertas causadas por las operaciones de rutina.
- Si usa Stackdriver, incluya las métricas de la plataforma GCP en sus paneles. Configure alertas para dependencias de GCP.
- Distribuya siempre la traza entrante. Incluso si no participa en la traza, esto permitirá que los servicios de nivel inferior depuren problemas de producción.
Protección y seguridad
- Asegúrese de que todas las conexiones externas estén encriptadas.
- Asegúrese de que sus proyectos de producción tengan la configuración correcta de IAM.
- Use redes para aislar grupos de instancias de máquinas virtuales.
- Use una VPN para conectarse de forma segura a redes remotas.
- Documente y monitoree el acceso del usuario a los datos. Asegúrese de que todo el acceso de los usuarios a los datos esté marcado y registrado.
- Asegúrese de que los puntos finales de depuración estén limitados por las ACL.
- Desinfectar la entrada del usuario. Configure los límites de tamaño de la carga útil para la entrada del usuario.
- Asegúrese de que su servicio pueda bloquear selectivamente el tráfico entrante para usuarios individuales. Esto bloqueará las infracciones sin afectar a otros usuarios.
- Evite puntos finales externos que inician una gran cantidad de operaciones internas.
Planificación de la capacidad
- Documente cómo se escala su servicio. Por ejemplo: número de usuarios, tamaño de la carga útil entrante, número de mensajes entrantes.
- Documente los requisitos de recursos para su servicio. Por ejemplo: el número de instancias de máquinas virtuales asignadas, el número de instancias de Spanner, equipos especializados como una GPU o TPU.
- Restricciones de recursos de documentos: tipo de recurso, región, etc.
- Documente los límites de cuota para crear nuevos recursos. Por ejemplo, limitar el número de solicitudes de API de GCE si usa la API para crear nuevas instancias.
- Considere realizar pruebas de estrés para analizar la degradación del rendimiento.
Eso es todo ¡Nos vemos en el aula!