Close

Cómo gestiona Atlassian los datos de los clientes


Método de resistencia de Atlassian

Los productos de la nube de Atlassian están diseñados para ofrecer un gran rendimiento. Se han desarrollado con las mejores tecnologías para garantizar que tus datos y servicios se encuentren a tu disposición cuando los necesites. En Atlassian, nos preocupamos mucho por la resistencia de los datos y servicios de nuestros clientes, sobre todo porque nosotros mismos dependemos de la misma gama de productos.

Con este fin, trabajamos para minimizar el impacto en el cliente en caso de que se produzcan interrupciones. Aprovechamos varios centros de datos geográficamente diversos, contamos con un programa completo de copias de seguridad y obtenemos garantías al probar con regularidad nuestros planes de recuperación ante desastres y continuidad empresarial.

En esta página se proporciona una visión general de la forma en la que controlamos el ciclo de vida completo de la gestión de datos de clientes, en la que se incluyen la realización de copias de seguridad con funciones nativas en Amazon Web Services (AWS) para garantizar la disponibilidad de nuestros servicios, la forma en la que probamos con regularidad nuestros planes de recuperación ante desastres y nuestro enfoque para la mejora continua de dichos planes y los de continuidad empresarial.

Cómo gestionamos las copias de seguridad

Lo primero es lo primero: infraestructura y bases de datos

En términos generales, Atlassian se divide en dos conjuntos principales de infraestructuras en las que funcionan nuestros productos: un entorno de plataforma como servicio (PaaS), conocido internamente como “Micros”, y “no Micros”. Entre los productos que se ejecutan en nuestra plataforma Micros se incluyen Jira, Confluence, Statuspage y Atlassian Access; entre los que se ejecutan en entornos no Micros podemos encontrar Bitbucket, Opsgenie y Trello. Con el fin de que todo resulte sencillo, en este documento nos centraremos en gran medida en nuestros productos principales: Jira, Confluence y Bitbucket.

Jira y Confluence Cloud se encuentran alojados en varias regiones de AWS, y utilizan la oferta de la infraestructura de AWS como servicio (IaaS) (en concreto en el este y oeste de EE. UU., Irlanda, Fráncfort, Singapur y Sídney, con planes de expansión a otras regiones según sea necesario). Jira y Confluence Cloud utilizan bases de datos relacionales separadas de manera lógica para cada instancia de producto, mientras que los archivos adjuntos que se guardan en Jira o Confluence Cloud se almacenan en nuestra plataforma de almacenamiento de documentos (“Media Platform”), que, a su vez, se almacena en Amazon S3.

Un conjunto de servicios que se ejecutan en el centro de datos de NTT Communications (NTT) en Ashburn (Virginia) se encarga de proporcionar los servicios y las funciones de Bitbucket Cloud, y las copias de seguridad se almacenan tanto en el centro de datos de NTT en Santa Clara (California) como en AWS. Los datos de los clientes de Bitbucket Cloud se almacenan en archivadores de PostgreSQL y NetApp.

Copias de seguridad

Atlassian se da cuenta de que, independientemente de la actividad de tu empresa, esta crea datos, y sin ellos, no tienes empresa. En línea con nuestro principio de no #$%! al cliente, nos preocupamos mucho por proteger los datos contra las pérdidas y contamos con un amplio programa de copias de seguridad.

En el caso de Jira y Confluence Cloud, Atlassian utiliza la función de instantánea de Amazon RDS (Amazon Relational Database Service) para crear copias de seguridad diarias automatizadas de cada instancia de RDS. Las instantáneas de Amazon RDS se conservan durante 30 días con compatibilidad con recuperación al momento dado y se cifran mediante cifrado AES-256.

En el caso de Bitbucket, las copias de seguridad se almacenan tanto en centros de datos físicos de NTT como en AWS.

Atlassian prueba trimestralmente las copias de seguridad para la restauración; además, para cualquier incidencia que se identifique en estas pruebas se genera un ticket de Jira para garantizar que se realiza un seguimiento de todas las incidencias hasta que se solucionen.

Si deseas más información, consulta nuestras preguntas frecuentes sobre almacenamiento de datos.

Cómo utilizamos varios centros de datos y zonas de disponibilidad para lograr una gran disponibilidad

Los huracanes, terremotos y tsunamis son riesgos muy remotos, pero reales al fin y al cabo; por ello, es imprescindible llevar a cabo copias de seguridad (y réplicas) de los datos en varias ubicaciones geográficas para que se puedan recuperar, independientemente de lo que pueda suceder.

Atlassian lo hace utilizando los servicios de centros de datos de gran disponibilidad de AWS en varias regiones de todo el mundo. Cada región de AWS es una ubicación geográfica separada, que dispone de diversas ubicaciones aisladas conocidas como “zonas de disponibilidad” (AZ, por sus siglas en inglés). Por ejemplo, EE. UU. oeste (la costa oeste de Estados Unidos) es una región, dentro de la cual hay dos AZ, us-west-1a (localizada en el norte de California) y us-west-1b (localizada en Oregón), las cuales se encuentran en la misma región en general, pero están geográficamente aisladas.

Todas las AZ se han diseñado de forma que se puedan aislar de los fallos que se produzcan en otras AZ y con el fin de proporcionar conectividad de red barata y de baja latencia a otras AZ en la misma región. Esta gran disponibilidad multizona constituye la primera línea de defensa y supone que los servicios que se ejecutan en implementaciones multi-AZ deben ser capaces de resistir el fallo de las AZ.

Jira y Confluence utilizan el modo de implementación multi-AZ para Amazon RDS. En una implementación como esta, Amazon RDS provee y mantiene una réplica síncrona en espera en una AZ distinta de la misma región para proporcionar redundancia y capacidad de conmutación por error. La conmutación por error de una AZ está automatizada y, por lo general, tarda entre 60 y 120 segundos, por lo que las operaciones de la base de datos se pueden reanudar con la mayor rapidez posible sin intervención administrativa. Estos conceptos de región, AZ y replicación se destacan en los siguientes diagramas. Opsgenie, Statuspage, Trello y Jira Align utilizan estrategias de implementación similares, con pequeñas variaciones en el tiempo de replicación y de conmutación por error.

En el caso de Bitbucket, todos los servidores de bases de datos principales residen en centros de datos de NTT con nodos de replicación y copias de seguridad que se almacenan tanto en los centros de datos de NTT como en AWS. Los datos de producción se replican constantemente en los centros de datos de NTT de Ashburn (Virginia) y Santa Clara (California) mediante la tecnología mirroring. Los datos de producción de Bitbucket se replican cada 2 horas desde su sitio primario al secundario, con un retardo medio de entre 10 y 20 minutos y un máximo de 4 horas.

Cómo determinamos el tiempo de recuperación y los objetivos de los puntos de recuperación

En un mundo ideal, nunca perderíamos ningún dato empresarial vital. En la práctica, sin embargo, un sistema sin riesgos de pérdida de datos es inalcanzable o presenta un precio prohibitivo. Aunque en la cultura empresarial de Atlassian se ha establecido la expectativa de apuntar a este supuesto de cero pérdidas de datos y a la capacidad de sobrevivir automáticamente a un fallo en una zona de disponibilidad, en la planificación de la continuidad empresarial se deben establecer “objetivos de tiempo de recuperación” y “objetivos de punto de recuperación” (RTO y RPO, respectivamente, por sus siglas en inglés) que busquen el equilibrio adecuado entre coste, beneficio y riesgo.

El RTO es el período que transcurre tras un incidente, en el cual el proceso (o sistema) empresarial se debe recuperar y debe ponerse en marcha de nuevo. El RPO es, en la práctica, la cantidad de datos que la organización acepta que puede perder en una operación de recuperación. Veámoslo en un ejemplo sencillo: si realizas copias de seguridad a diario, en caso de que se produzca un incidente al final del día y se lleve a cabo la recuperación a partir de la copia de seguridad (que se realizó ayer), vas a perder un día de datos. Ese es el RPO.

Nuestras evaluaciones de impacto y riesgo empresarial ayudan a nuestros equipos a establecer objetivos RTO y RPO personalizados en función de los requisitos de los usuarios del cliente y del posible impacto de una interrupción.

De forma más específica, dividimos nuestros servicios en tres segmentos de fácil comprensión a los que llamamos “niveles”: para productos y servicios orientados al cliente, para sistemas empresariales de Atlassian y para herramientas internas (niveles 1, 2 y 3); además, existe un nivel subyacente (nivel 0) que proporciona un estándar de disponibilidad aún mayor para los componentes críticos de los cuales depende todo lo demás.

For each tier, we’ve defined mandatory targets by reviewing, amongst other things, business impact assessments and typical usage scenarios for the services we build. Our service tiers help determine availability, reliability, RTO and RPO targets as set out in the table below.

Nivel 0 Nivel 1 Nivel 2 Nivel 3
Componentes de servicio e infraestructura críticos Nuestros servicios de Nivel 0 son los que forman la base de los demás servicios y son críticos para ofrecer nuestros productos. Nuestros servicios de Nivel 1 suelen ser nuestros productos, o están directamente relacionados con el ofrecimiento de nuestros productos. Los servicios de Nivel 2 no son críticos o no son de cara al exterior. Los servicios de Nivel 3 no son críticos o no son de cara al exterior.
Servicios de ejemplo:

Servicios de ejemplo

· Plataforma AWS

· Micros Server

· Networking Core

Servicios de ejemplo

· Jira y Confluence Cloud

· Bitbucket

Servicios de ejemplo

· Image Effects

· CAC

Servicios de ejemplo

· Recepción de análisis o datos de BI

RPO* <1 hora <1 hora <8 horas <24 horas
RTO** <4 horas <6 horas <24 horas <72 horas

*RPO: objetivo de punto de recuperación, pérdida de datos en caso de desastre

**RTO: objetivo de tiempo de recuperación, servicios de restauración en caso de desastre

En Atlassian, determinamos que es responsabilidad de los propietarios del servicio garantizar que el servicio correspondiente cumple su objetivo de RPO y RTO.

Cómo realizamos las pruebas de recuperación ante desastres

En Atlassian, llevamos a cabo pruebas periódicas de recuperación ante desastres y nos esforzamos por mejorar continuamente como parte de nuestro programa de recuperación ante desastres (DR, por sus siglas en inglés). Con ello se pretende garantizar que los datos y servicios de los clientes sean fiables y resistentes. Realizamos pruebas tanto programadas como ad hoc, en las que se incluyen los siguientes elementos:

Documentación: en el caso de los servicios críticos u orientados al cliente (incluidos los de nivel 0 y 1), se llevan a cabo revisiones trimestrales de la documentación de respaldo para garantizar su exactitud, integridad y vigencia. Se documenta cualquier incidencia que se haya identificado y se registra en un ticket interno de Jira para que se le realice un seguimiento hasta que se solucione.

Proceso: también se llevan a cabo pruebas trimestrales de los procesos reales de copias de seguridad técnicas y recuperación para los servicios críticos y orientados al cliente (incluidos los de nivel 0 y 1) con el fin de determinar si se cumplen los objetivos de RTO y RPO (basados en la clasificación del nivel de servicio). Para cualquier incidencia que se identifique en estas pruebas se genera un ticket de Jira para realizar un seguimiento de esta hasta que se solucione.

Resistencia y conmutación por error: se realizan pruebas periódicas y ad hoc de los niveles de resistencia en todas las AZ para garantizar que Atlassian pueda gestionar el fallo de una de ellas con un tiempo de inactividad mínimo. Aunque entendemos que el hecho de que se produzca un fallo en una región completa es muy poco probable, también comprobamos con periodicidad la conmutación por error de la región y continuamos mejorando nuestra capacidad de recuperación regional.

Sistemas: los equipos de ingeniería de fiabilidad del sitio (SRE, por sus siglas en inglés) y los de ingeniería de producto supervisan continuamente una amplia variedad de métricas de los servicios para contribuir a garantizar que los usuarios disfruten de experiencias excelentes. Se configuran alertas automatizadas para notificar a los miembros del equipo de SRE cuando se cruzan determinados umbrales de las métricas de servicio, de modo que se puedan tomar medidas inmediatas dentro de nuestros procesos de respuestas a incidentes.

Panel de recuperación ante desastres: se mantiene internamente un panel de DR de modo que, para los servicios críticos y orientados al cliente (incluidos los de nivel 0 y 1), los tickets de Jira relacionados con la supervisión, el mantenimiento y las pruebas se puedan seguir de manera centralizada para garantizar que las revisiones de la documentación y los procesos de copia de seguridad y recuperación se realicen a tiempo.

Pruebas y simulaciones de DR: las pruebas de DR se llevan a cabo cada año y ad hoc. Como parte de nuestras pruebas de DR, realizamos ejercicios de simulación para ayudar a los equipos de DR a pasar por varias situaciones de posibles incidentes. En dichos ejercicios se prueban situaciones distintas y se identifican las brechas de nuestros procesos de recuperación. Entre dichas situaciones se incluyen los terremotos, los incendios, los desastres naturales, los simulacros de recuperación y las pruebas. Tras realizar las pruebas de DR, se recopilan, analizan y comentan los resultados para determinar el alcance de los siguientes pasos para la mejora continua. Para dichos esfuerzos de mejora se genera un ticket de Jira y se realiza un seguimiento de este hasta que se solucione.

Aunque nuestras pruebas y procesos son rigurosos desde el punto de vista técnico, también necesitamos a personas excepcionales para llevar a cabo dichos procesos. Por ello, en Atlassian contamos con los siguientes puestos en nuestro programa de DR:

Ingenieros de fiabilidad del sitio (SRE): los SRE asisten a las reuniones periódicas de DR y presentan sus servicios críticos. Junto con nuestro equipo de riesgo y cumplimiento, identifican las brechas de DR y se centran en la solución según sea necesario.

Defensor de la recuperación ante desastres: en cada equipo de producto o servicio (incluidos los servicios subyacentes) se nombran defensores de la DR para supervisar y ayudar a gestionar la implementación del proceso de DR en dicho producto o servicio, y garantizar así que se cumplan los requisitos del nivel de servicio.

Dirección: mantenemos la participación y el compromiso continuo de los ejecutivos y de la alta dirección en nuestros procesos de DR. Con la dirección implicada, en Atlassian hemos tenido en cuenta tanto los impulsos empresariales como los técnicos en la estrategia de resiliencia.

Otras medidas y planes de continuidad empresarial más amplios

En Atlassian nos esforzamos por contar con potentes funcionalidades de continuidad empresarial (BC, por sus siglas en inglés) y DR para garantizar que el efecto en nuestros clientes sea mínimo en caso de que se produzca una interrupción en nuestras operaciones. Entre los principios clave que guían nuestro programa de BC y DR se incluyen:

Mejora continua: en Atlassian nos esforzamos por garantizar mejoras en el crecimiento de la resiliencia a través de las eficiencias operativas, la automatización, las nuevas tecnologías y las prácticas probadas.

Garantía a través de pruebas: en Atlassian entendemos que a través de las pruebas programadas con regularidad y la aplicación de mejoras continuas, somos capaces de lograr una resistencia óptima.

Recursos especializados: en Atlassian contamos con personal y equipos especializados para garantizar que los productos orientados al cliente reciban la atención que requieren para hacer posible la BC y la DR. Disponemos del nivel adecuado de recursos en el terreno para prestar apoyo a nuestro comité directivo, a las evaluaciones de riesgos, a las pruebas de análisis de impacto empresarial y, por supuesto, para dedicar la atención necesaria a los incidentes del mundo real.

El resumen

En Atlassian combinamos las mejores tecnologías con pruebas y validaciones continuas para garantizar que los datos de nuestros clientes se encuentren disponibles y sean fiables y resistentes. Contamos con varios centros de datos geográficamente diversos, llevamos a cabo un amplio programa de copias de seguridad y obtenemos garantías a través de pruebas periódicas de recuperación ante desastres y planes de continuidad empresarial. Por si fuera poco, contamos con un personal excepcional y con recursos especializados para llevar a cabo dichos procesos.