Método de preparación operativa de Atlassian

Nivel 0: infraestructura central crítica

Un servicio de nivel 0 proporciona infraestructura de apoyo y componentes de servicio compartidos en los que se basan los servicios de nivel 1 para funcionar. Los componentes se consideran críticos si se cumple una de las siguientes condiciones:

• Son necesarios para que un servicio de nivel 1 funcione o sus usuarios puedan acceder a él.
• Son necesarios para que un cliente se suscriba a un servicio de nivel 1.
• Son necesarios para que el personal respalde o desempeñe funciones operativas clave en un servicio de nivel 1, como:

- Iniciar, detener o reiniciar el servicio.
- Realizar una implementación, mejora, reversión o corrección inmediata.
- Determinar el estado actual (activo/inactivo/degradado).

Nivel 1: servicios esenciales

Un servicio de nivel 1 proporciona una función empresarial, de cliente o de producto vital. Se trata de servicios orientados al cliente o servicios internos críticos para la empresa. Cuando el servicio se degrada o no está disponible, la empresa pierde dinero o no puede realizar funciones empresariales críticas, o se pierde la funcionalidad principal desde la perspectiva del cliente. Los servicios de nivel 1 requieren un turno de soporte ininterrumpido y tienen SLA de alto nivel para las métricas clave y un conjunto estricto de requisitos de puesta en marcha.

Nivel 2: servicios no fundamentales

Un servicio de nivel 2 es un servicio orientado al cliente que no forma parte de la funcionalidad principal. Los servicios de nivel 2 ofrecen un valor añadido o una experiencia de usuario adicional que pueden considerarse opcionales o que "está bien tener".

Un servicio de nivel 2 incluye servicios públicos que funcionan principalmente en el ámbito del marketing, como los sitios web de empresas públicas. No ofrecen servicios directos de nivel empresarial a los clientes ni servicios internos que los equipos utilizan para desempeñar aspectos de sus funciones, como las herramientas de colaboración, el seguimiento de actividades y más.

Los servicios de nivel 2 pueden o no requerir un turno de soporte ininterrumpido y tener SLA de menor nivel y menos requisitos de puesta en marcha.

Nivel 3: funciones únicamente internas o no críticas

Un servicio de nivel 3 proporciona funcionalidad interna a la empresa o servicios beta experimentales. Esta clase también puede incluir servicios que actualmente son una función experimental para las primeras personas en probarlos y en los que se espera que la calidad del servicio se degrade en la versión beta. Este nivel proporciona una categoría de SLA de nivel bajo para servicios que solo se sostienen con los mejores esfuerzos.

Pérdida de datos (RPO)

Este número representa la cantidad máxima de datos que el servicio perderá en caso de fallo. Un servicio de nivel 0 perderá menos de una hora de datos en caso de fallo.

Restauración del servicio (RTO)

Este número representa el tiempo máximo antes de que el servicio vuelva a estar operativo. Un servicio de nivel 0 se recuperará por completo en menos de cuatro horas.

Copias de seguridad

Cuando un servicio se interrumpe, es posible que los equipos tengan que usar copias de seguridad para restaurar los datos a un momento determinado. Es importante realizar copias de seguridad de los datos con frecuencia, implementar un proceso de restauración y probar el proceso de copia de seguridad y restauración de manera rutinaria. El proceso de copia de seguridad y restauración debe ser fiable y eficaz. En este punto, la documentación y las pruebas son fundamentales.

Definición de hecho

• Implementar un proceso de copia de seguridad y restauración.
• Documentar y probar el proceso de copia de seguridad y restauración.
• Probar con regularidad el proceso de copia de seguridad y restauración.
  

Gestión de capacidad

Describe claramente las capacidades que el servicio ofrece a los consumidores. En particular, identifica los límites que el servicio impone a los consumidores. Implementa pruebas de rendimiento para garantizar que el servicio funciona dentro de los límites previstos.

Estos son algunos ejemplos de información que probar y poner a disposición de los consumidores.

• El servicio está limitado a X requisitos por segundo.
• El servicio garantiza un tiempo de respuesta de X.
• La función X del servicio se replica o no en todas las regiones.
• El consumidor no debe hacer X:
  - sobrecargar el servicio
  - subir archivos de un tamaño superior a X

Definición de hecho

• Los límites del servicio están identificados y documentados.
• Se realizan pruebas de rendimiento para verificar que se cumplen los límites.
  

Conocimiento del cliente

La capacidad de soporte es un aspecto importante de la calidad del servicio que va unida a la fiabilidad y la facilidad de uso. Los equipos deben crear procesos de soporte para un servicio o una nueva función de un servicio antes de su puesta en marcha. La compatibilidad puede incluir un proceso de atención al cliente, un proceso de control de cambios, runbooks de soporte y otros elementos centrados en el soporte.

Proceso de atención al cliente

Los desarrolladores deben entender lo que ocurre cuando los clientes contactan con el equipo de soporte para solicitar asistencia y deben entender sus responsabilidades con respecto al proceso de soporte. Esto puede incluir formar parte de una rotación de guardia o que se les pida que solucionen los problemas de producción cuando se produzcan.

Proceso de control de cambios

No todos los cambios afectan a los clientes de la misma manera. Algunos cambios son imperceptibles para los clientes, como la corrección de un pequeño error. Otros, en cambio, implican que los clientes tengan que hacer un gran esfuerzo para adoptarlos, como la reescritura completa de una API. El control de cambios ayuda a evaluar la magnitud del impacto que los cambios pueden tener en el cliente.

Runbooks de soporte

Los runbooks ofrecen un resumen de alto nivel del funcionamiento de un servicio, así como explicaciones detalladas de los problemas que pueden surgir y de cómo resolverlos. Es importante actualizar los runbooks con frecuencia y verificar que los procedimientos de soporte documentados son precisos a medida que el servicio va cambiando con el tiempo.

Definición de hecho

• Documentación que responda a la mayoría de las preguntas que el equipo de soporte requeriría para investigar una incidencia.
• Un proceso de control de cambios que funcione.
  
  

Recuperación ante desastres

Perder una zona de disponibilidad es parte de un desastre. Los servicios deben ser lo suficientemente resilientes para funcionar con normalidad en caso de que se produzca un fallo en una zona de disponibilidad. La recuperación ante desastres tiene dos componentes: en primer lugar, desarrollar y documentar un proceso de recuperación ante desastres y, en segundo lugar, realizar pruebas continuas del proceso documentado. La recuperación ante desastres debe probarse con frecuencia. Prueba la capacidad de gestionar un fallo en una zona de disponibilidad mediante el plan de recuperación ante desastres documentado.

Definición de hecho

• El plan de DR está documentado.
• El plan DR está probado.
• Hay pruebas periódicas del plan DR planificadas.
  

Registro

Los registros son útiles por muchos motivos, como la detección de anomalías, la investigación durante o después de una interrupción del servicio y el rastreo de la actividad maliciosa al conectar eventos relacionados entre servicios mediante identificadores únicos. Hay muchos tipos de registros. Un par de registros muy útiles que la mayoría de los servicios deberían incluir son:

• Registros de acceso
• REGISTROS DE ERRORES

Definición de hecho

• Se generan los registros correspondientes.
• Los registros se almacenan en algún lugar donde se pueden encontrar y buscar fácilmente.
  

Comprobaciones de acceso lógico

Las comprobaciones de acceso lógico se centran en gestionar el acceso de los usuarios internos, el acceso de los usuarios externos, el acceso de servicio a servicio y el cifrado de datos. ¿Cómo impedirá el servicio el acceso no autorizado a la funcionalidad y los datos? ¿Cómo se definen, verifican, actualizan y dejan en desuso los permisos de usuario? ¿Estos controles protegen lo suficiente los datos confidenciales?

Usuarios internos

Algunas preguntas importantes que hay que responder son: ¿Cómo se autentican los usuarios internos? ¿Cómo se concede o aprovisiona el acceso? ¿Cómo se deniega? ¿Cómo funciona una escalación de privilegios? ¿Cuál es el proceso para las revisiones y auditorías periódicas del acceso?

Usuarios externos

¿Cómo se gestiona la autenticación para los clientes? ¿Cómo se concede o aprovisiona el acceso? ¿Cómo se deniega? ¿Cómo funciona una escalación de privilegios? ¿Cuál es el proceso para las revisiones y auditorías periódicas del acceso?

De servicio a servicio

Esto es similar a los usuarios internos y externos. Los equipos deben determinar cómo se van a autenticar los servicios entre sí. Por ejemplo, configurando OAuth 2.0.

Cifrado

Es probable que los equipos quieran cifrar sus datos en reposo y en tránsito. Explica cómo el servicio gestiona el cifrado de los datos. ¿Cómo gestiona el equipo las claves? ¿Cuál es la política de rotación de claves?

Definición de hecho

• Las comprobaciones de acceso lógico están documentadas, implementadas y probadas para los usuarios internos, los usuarios externos y de servicio a servicio.
• Cifrado de datos en reposo.
• Los datos se cifran en tránsito.
• El cifrado está implementado y probado.
  

Publicaciones

La implementación de una nueva versión del servicio no debe interrumpir el tráfico de clientes más allá de lo definido en el SLA del servicio. Todos los cambios deben revisarse por pares, probarse e implementarse mediante canalizaciones de CI/CD. Tras cada implementación, verifica que la implementación se haya realizado correctamente y que no haya interrumpido ninguna funcionalidad. Es preferible la verificación automática posterior a la implementación. Dispón de varios entornos, p. ej., de prueba, ensayo, preproducción y producción, para poder probar las implementaciones.

Definición de hecho

• El servicio tiene una implementación sin tiempo de inactividad.
• Hay entornos en los que el servicio debe implementarse y probarse antes de pasar a la producción.
  

Checklist de seguridad

La checklist de seguridad es un conjunto de prácticas y estándares para desarrollar y mantener una infraestructura y software seguros. Estos estándares reducen la probabilidad de que se produzcan infracciones de la privacidad y vulneraciones de datos y, a su vez, aumentan la confianza de los clientes. Los equipos deben desarrollar una checklist de seguridad que aborde la naturaleza del servicio que están creando. Estos son algunos ejemplos de requisitos:

Definición de hecho

• Pruebas de que no hay vulnerabilidades críticas o altas abiertas para el servicio
• Uso del cifrado de datos en reposo para todos los almacenes de datos
• Pruebas de que el servicio no permite conexiones HTTP no seguras
  

Métricas de servicio

Las métricas de servicio proporcionan información de estado y diagnóstico esencial sobre un servicio y permiten a los equipos supervisar los incidentes y responder ante ellos. Empieza por definir un conjunto de métricas que se supervisen para cada servicio. Después, crea un panel con estas métricas en una herramienta como Datadog o New Relic. Haz sonar alarmas cuando una métrica se salga de los límites y genera tickets de problemas en caso de alarma.

Definición de hecho
Estos son algunos ejemplos de cosas a medir:

• Latencia: el tiempo necesario para gestionar una solicitud
• Tráfico: lugares de carga en el servicio por parte de usuarios externos
• Errores: número de errores o fallos que afectan a los usuarios
• Saturación: cómo de ocupado está el servicio y cuánto más puede gestionar
• Uso de recursos subyacentes: CPU, memoria, disco
• Elementos internos de la aplicación, como colas, intervalos y flujo
• Uso y funcionalidad esencial del servicio: usuarios activos, acciones por minuto
  

Resiliencia del servicio

Los requisitos de resiliencia del servicio determinan si un servicio puede gestionar los cambios de carga o los fallos de varios componentes. Es probable que un servicio resiliente se escale automáticamente y sea resistente al fallo de un solo nodo.

Escalación automática

Si el servicio tiene la capacidad de escalar automáticamente, asegúrate de que la escalación automática esté configurada correctamente y probada. Determina qué métrica activará la escalación automática y pruébala para asegurarte de que funciona. Por ejemplo, si el servicio requiere almacenar datos en disco, puede supervisar el porcentaje de espacio libre de los discos y escalar automáticamente añadiendo almacenamiento cuando el porcentaje de espacio libre esté por debajo de un umbral.

Prueba de fallos de un solo nodo

Es deseable tener servicios que puedan sobrevivir a los fallos de un solo nodo. Si un solo nodo de servicio deja de funcionar, el servicio debería seguir funcionando, posiblemente con una capacidad reducida. Pruébalo finalizando al menos un nodo del servicio y observa el comportamiento del sistema. Se espera que el servicio gestione el fallo de un solo nodo. Se debe supervisar el entorno en el que simularás el fallo de un solo nodo.

Definición de hecho

• Pruebas de escalación automática implementada y probada
• Pruebas de que los entornos de producción o de ensayo ejecutan varios nodos
• Pruebas de que el servicio resiste a un fallo de un solo nodo
  

Soporte

El soporte es el proceso de prestar asistencia a un servicio tras su publicación. Los equipos necesitan tener runbooks, herramientas de operaciones y rotaciones de guardia en funcionamiento antes de poner en marcha los servicios para que estos cuenten con un proceso para corregir los errores que puedan producirse.

Runbooks

Los runbooks proporcionan a los usuarios de respuesta de guardia el contexto y las instrucciones que necesitan para liderar el trabajo rápido de respuesta ante incidentes y corrección.

Herramientas de operaciones

Ejecutar un servicio con un estándar suficiente significa que hay un turno de guardia implantado y que hay una herramienta de operaciones, como Opsgenie, configurada para avisar al personal de guardia cuando el servicio tiene incidencias.

Guardias

Para un servicio de nivel 2 y de nivel 3, se requiere un turno de guardia.

Para un servicio de nivel 1 y de nivel 0, se requiere un turno de guardia ininterrumpido.

Definición de hecho

• Los runbooks están escritos por el equipo de soporte y se pueden encontrar a través de este.
• La herramienta de operaciones está configurada y probada.
• Hay rotaciones de guardia implementadas a las que se llama en caso de incidencias.
  

Comprobaciones de preparación operativa de nivel 3 sugeridas

• Copias de seguridad
• Registro
• Publicaciones
• Checklist de seguridad
• Métricas de servicio
• Soporte
  

Los servicios de nivel 3 comienzan con los requisitos de preparación operativa más básicos.

Comprobaciones de preparación operativa de nivel 2 y nivel 1 sugeridas

• Copias de seguridad
• Recuperación ante desastres
• Registro
• Publicaciones
• Checklist de seguridad
• Métricas de servicio
• Resiliencia del servicio
• Soporte

Los servicios de nivel 2 y nivel 1 añaden requisitos de preparación operativa de recuperación ante desastres y resiliencia de los servicios. Es importante tener en cuenta que los servicios de nivel 2 y nivel 1 pueden tener diferentes requisitos de preparación operativa. No es necesario que los niveles tengan requisitos diferentes. Si se considera necesario otro requisito de preparación operativa para un nivel de servicio específico, añádelo. El nivel 2 y el nivel 1 pueden diferir según las necesidades del equipo.

Comprobaciones de preparación operativa de nivel 0 sugeridas

• Copias de seguridad
• Gestión de capacidad
• Conocimiento del cliente
• Recuperación ante desastres
• Registro
• Comprobaciones de acceso lógico
• Publicaciones
• Checklist de seguridad
• Métricas de servicio
• Resiliencia del servicio
• Soporte

Los servicios de nivel 0 añaden comprobaciones de gestión de la capacidad, conocimiento del cliente y acceso lógico.