Trabajo para una pequeña empresa de desarrollo a la que cada vez se le pide más que elabore acuerdos de nivel de servicio formales para nuestros productos en función de configuraciones particulares.
Desde el punto de vista del desarrollo, me siento cómodo con esto, sin embargo, no tiene sentido decir que cumpliremos objetivos particulares desde una perspectiva de software si no son realistas desde una perspectiva de hardware/plataforma: los clientes solo se preocupan por lo general. disponibilidad del sistema.
¿Qué debería mirar desde la perspectiva de la plataforma? ¿Qué tipo de métricas y niveles?
Además, ¿cuáles son los errores (por ejemplo, desde la perspectiva del software, nunca me comprometería a fijar un tiempo de reparación? No tengo idea de si tendré que reescribir todo el producto para corregir algo y decir que podemos solucionarlo en 5 días es potencialmente imposible: ¿a qué debo evitar comprometerme desde el punto de vista del hardware/SO/plataforma)?
Respuesta1
Tengo amplia experiencia en este espacio; Trabajo mucho para un par de empresas Fortune 5 que operan sus centros de datos como lo haría un ISP para los distintos departamentos de la empresa que necesitan servicios de alojamiento y soporte.
Por lo general, tienen dos métricas llamadas SLA (Acuerdo de nivel de servicio) y OLA (Acuerdo de nivel operativo).
Los SLA se cumplen según el tipo de hardware utilizado. Cuando hablamos de SLA utilizamos niveles para describirlos. SLA-1 es tiempo de inactividad cero, SLA-2 es algo así como hasta 1 hora de tiempo de inactividad, SLA-3 es 8 horas, etc... Los SLA se cumplen mediante el uso de equipos redundantes. En una empresa utilizamos mucho Cisco para crear alta disponibilidad (Cisco CSM y equipos GSS). Cuando hablamos de niveles de SLA generalmente hablamos de HA (alta disponibilidad) y DR (recuperación ante desastres). En situaciones en las que una empresa tiene varios centros de datos, el componente HA suele ser un atributo por centro de datos, mientras que DR es un atributo entre centros de datos; ambos medidos en términos de RPO (objetivo de punto de recuperación) y RTO (objetivo de tiempo de recuperación) para referirse al nivel de SLA.
Los OLA son, en términos realmente básicos, la rapidez con la que alguien (un ser humano) responde a un evento que requiere intervención manual/acción correctiva. Los OLA también suelen medirse en términos de tiempos de respuesta; utilizan los mismos objetivos RTO/RPO. Una empresa a la que consulto utiliza 6 niveles para sus métricas OLA. Los primeros 3 niveles aquí son un ejemplo de esto:
OLA-1: RTO 0 < 2 horas OLA-2: RTO >= 2 y <= 4 horas OLA-3: RTO >= 24 horas y <= 30 días si no es una falla del centro de datos, si una falla de CC > 30 días.
Lo que impulsa las métricas de OLA y SLA es algo que se llama calificación de la CIA. CIA = Confidencialidad, Integridad y Disponibilidad. Los datos de una solicitud deben ser clasificados por la unidad de negocio que paga por dicha solicitud. La CIA ayudará a impulsar lo que deberían ser OLA y SLA. A cada parte del nivel de la CIA se le asigna un número del 1 al 3. Entonces, por ejemplo, una calificación de la CIA de 1-1-1 sería Altamente confidencial, Nivel de integridad más alto y Nivel de disponibilidad más alto. Una calificación de la CIA de 3-3-3 es lo más bajo que puede llegar. Por lo tanto, una calificación CIA de 3-3-3 generalmente se corresponde con un nivel SLA y OLA de 6, donde un SLA-6 y OLA-6 es el más bajo (el mayor tiempo de respuesta) garantizado.
La forma de obtener una calificación de la CIA generalmente equivale a calcular cuánto dinero perderá una empresa si los datos son robados (Confidencialidad), comprometidos (Integridad) o cuando los sistemas no funcionan (Disponibilidad). Por lo tanto, una empresa que puede perder 10 millones de dólares si se roban datos confidenciales puede tener una calificación C de 1 o si esa pérdida de datos no es crítica y solo le costaría a la empresa, digamos, 1000 dólares, entonces puede tener una calificación C de 3. .
Normalmente, así es como las grandes empresas para las que he consultado manejan este tipo de cosas.
Respuesta2
Tardaría en comprometerme a fijar un tiempo para solucionar los problemas de hardware, al igual que los de software. Nunca se sabe cuándo estará esperando que un proveedor solucione un error crítico en algo. En términos de niveles de SLA, descubrí que tienden a ser del tipo "alguien estará trabajando en su problema dentro de X horas". X, por supuesto, depende de cuánto paguen, pero en mi experiencia, entre 1 y 8 horas parecería normal.
Respuesta3
Si se le solicita que proporcione un SLA para la restauración de problemas de hardware donde está instalado su software, la respuesta es "no". Puede comprometerse con un tiempo de respuesta, pero sin controlar toda la pila de hardware/sistema operativo/software no puede comprometerse con un tiempo de resolución.
¿Quizás su cliente le está diciendo de manera incómoda que realmente necesita una oferta alojada para su producto? De esa manera pueden evitar cualquier problema interno que les preocupe y simplemente emitirle un cheque.
Respuesta4
Una cosa a considerar al contratar un SLA es que el SLA por sí solo no significa absolutamente nada, debe cumplirse junto con las penalizaciones en caso de que el SLA no se cumpla.
Por ejemplo, nuestro ISP nos otorga un SLA del 100% en la red, pero la cantidad máxima que podemos recuperar es nuestra factura mensual, que es realmente baja ya que hoy en día el ancho de banda es barato y no se acerca a la cantidad de dinero que perdemos cuando la red no funciona. .
Además, lo que normalmente está escrito en los contratos es la rapidez con la que alguien responderá al problema, nunca cuánto tiempo llevará solucionarlo. Entonces, si te obligan a comprometerte con tiempos de respuesta cortos, simplemente coloca a un pasante en el turno de noche para que baraje los boletos por ti hasta que te despiertes y listo.
En mi experiencia, todo este negocio de SLA prácticamente significa muy, muy poco o nada.