Aínda que sexa unha inundación, 1C debería funcionar! Estamos de acordo co negocio en DR

Imaxina: estás prestando servizo á infraestrutura informática dun gran centro comercial. Comeza a chover na cidade. Choivas de choiva atravesan o tellado, a auga enche os locais comerciais ata o nocello. Agardamos que a súa sala de servidores non estea no soto, se non, os problemas non se poden evitar.  

A historia descrita non é unha fantasía, senón unha descrición colectiva dun par de acontecementos de 2020. Nas grandes empresas, un plan de recuperación ante desastres (DRP) sempre está a man para este caso. Nas empresas, esta é responsabilidade dos especialistas en continuidade do negocio. Pero nas medianas e pequenas empresas, a solución deste tipo de problemas recae nos servizos informáticos. Necesitas comprender a lóxica empresarial, comprender o que pode fallar e onde, crear protección e implementala. 

É xenial que un especialista en TI poida negociar coa empresa e discutir a necesidade de protección. Pero vin máis dunha vez como unha empresa escatimaba nunha solución de recuperación ante desastres (DR) porque a consideraba redundante. Cando ocorreu un accidente, unha longa recuperación ameazaba con perdas e o negocio non estaba listo. Podes repetir canto queiras: "Díxencho", pero o servizo informático aínda terá que restaurar os servizos.

Desde a posición dun arquitecto, vouche dicir como evitar esta situación. Na primeira parte do artigo, mostrarei o traballo preparatorio: como discutir tres preguntas co cliente para escoller ferramentas de seguridade: 

• Que estamos protexendo?
• De que estamos protexendo?
• Canto protexemos? 

Na segunda parte, falaremos das opcións para responder á pregunta: como defenderse. Vou poñer exemplos de casos de como diferentes clientes constrúen a súa protección.

O que protexemos: identificar funcións empresariais críticas 

É mellor comezar a prepararse discutindo o plan de acción posterior á emerxencia co cliente comercial. A principal dificultade aquí é atopar unha linguaxe común. Ao cliente normalmente non lle importa como funciona a solución informática. Impórtalle se o servizo pode realizar funcións comerciais e traer diñeiro. Por exemplo: se o sitio funciona, pero o sistema de pago está caído, non hai ingresos dos clientes e os "extremistas" seguen sendo especialistas en TI. 

Un profesional de TI pode ter dificultades nestas negociacións por varias razóns:

• O servizo de TI non comprende completamente o papel do sistema de información nos negocios. Por exemplo, se non hai unha descrición dispoñible dos procesos de negocio ou un modelo de negocio transparente. 
• Non todo o proceso depende do servizo de TI. Por exemplo, cando parte do traballo é realizado por contratistas e os especialistas en TI non teñen influencia directa neles.

Estruturaría a conversa así: 

1. Explicámoslles ás empresas que os accidentes suceden a todos e que a recuperación leva tempo. O mellor é demostrar as situacións, como isto ocorre e que consecuencias son posibles.
2. Demostramos que non todo depende do servizo informático, pero estás preparado para axudar cun plan de acción na túa área de responsabilidade.
3. Pedimos ao cliente empresarial que responda: se ocorre o apocalipse, que proceso debería restaurarse primeiro? Quen participa nel e como? 

   Requírese unha resposta sinxela da empresa, por exemplo: o centro de chamadas ten que seguir rexistrando as solicitudes 24 horas ao día, 7 días a semana.

4. Pedimos a un ou dous usuarios do sistema que describan este proceso en detalle. 
   É mellor involucrar a un analista para que axude se a túa empresa ten un.

   Para comezar, a descrición pode verse así: o centro de chamadas recibe as solicitudes por teléfono, por correo e mediante mensaxes do sitio web. Despois introdúceos en 1C a través da interface web e a produción lévaos desde alí deste xeito.

5. Despois observamos que solucións de hardware e software admiten o proceso. Para unha protección integral, temos en conta tres niveis: 
   • aplicacións e sistemas dentro do sitio (nivel de software),   
   • o propio sitio onde se executan os sistemas (nivel de infraestrutura), 
   • rede (moitas veces esquécense diso).

6. Descubrimos posibles puntos de fallo: nodos do sistema dos que depende o rendemento do servizo. Observamos por separado os nodos que son compatibles con outras empresas: operadores de telecomunicacións, provedores de hospedaxe, centros de datos, etc. Con isto, pode volver ao cliente empresarial para o seguinte paso.

Do que protexemos: riscos

A continuación, descubrimos polo cliente comercial de que riscos nos protexemos primeiro. Todos os riscos pódense dividir en dous grupos: 

• perda de tempo por inactividade do servizo;
• perda de datos por impactos físicos, factores humanos, etc.

As empresas teñen medo de perder tanto datos como tempo; todo isto leva á perda de diñeiro. Así que de novo facemos preguntas para cada grupo de risco: 

• Para este proceso, podemos estimar canto custa en diñeiro a perda de datos e a perda de tempo? 
• Que datos non podemos perder? 
• Onde non podemos permitir tempo de inactividade? 
• Que acontecementos son máis probables e máis ameazantes para nós?

Despois da discusión, entenderemos como priorizar os puntos de falla. 

Canto protexemos: RPO e RTO 

Cando os puntos críticos de falla están claros, calculamos os indicadores RTO e RPO. 

Déixeme recordar iso RTO (obxectivo de tempo de recuperación) — É o tempo permitido desde o momento do accidente ata que se restablece totalmente o servizo. Na linguaxe empresarial, este é un tempo de inactividade aceptable. Se sabemos cantos cartos supuxo o proceso, podemos calcular as perdas de cada minuto de inactividade e calcular a perda aceptable. 

RPO (obxectivo do punto de recuperación) - punto de recuperación de datos válido. Determina o tempo durante o que podemos perder datos. Desde o punto de vista empresarial, a perda de datos pode resultar en multas, por exemplo. Tales perdas tamén se poden converter en diñeiro. 

O tempo de recuperación debe ser calculado para o usuario final: canto tempo poderá iniciar sesión no sistema. Entón, primeiro sumamos o tempo de recuperación de todos os elos da cadea. Aquí adoita cometerse un erro: toman o RTO do provedor do SLA e esquécense dos termos restantes.

Vexamos un exemplo específico. O usuario inicia sesión en 1C, o sistema ábrese cun erro de base de datos. Póñase en contacto co administrador do sistema. A base de datos está situada na nube, o administrador do sistema informa o problema ao provedor de servizos. Digamos que todas as comunicacións levan 15 minutos. Na nube, unha base de datos deste tamaño restaurarase a partir dunha copia de seguridade nunha hora, polo tanto, o RTO no lado do provedor de servizos é dunha hora. Pero este non é o prazo final; para o usuario engadíronlle 15 minutos para detectar o problema. 
 
A continuación, o administrador do sistema debe comprobar que a base de datos é correcta, conectala a 1C e iniciar os servizos. Isto require outra hora, o que significa que o RTO do administrador xa é de 2 horas e 15 minutos. O usuario necesita outros 15 minutos: inicie sesión, comprobe que apareceron as transaccións necesarias. 2 horas e 30 minutos é o tempo total de recuperación do servizo neste exemplo.

Estes cálculos mostrarán á empresa de que factores externos depende o período de recuperación. Por exemplo, se a oficina está inundada, primeiro debes atopar a fuga e solucionala. Levará tempo, que non depende de TI.  

Como protexemos: escollendo ferramentas para diferentes riscos

Despois de discutir todos os puntos, o cliente xa comprende o custo dun accidente para a empresa. Agora podes escoller ferramentas e discutir o orzamento. Usando exemplos de casos de clientes, mostrarei que ferramentas ofrecemos para diferentes tarefas. 

Comecemos polo primeiro grupo de riscos: as perdas por tempo de inactividade do servizo. As solucións a este problema deberían proporcionar un bo RTO.

1. Aloxa a aplicación na nube 

   Para comezar, pode simplemente pasar á nube: o provedor xa pensou nos problemas de alta dispoñibilidade. Os hosts de virtualización reúnense nun clúster, a enerxía e a rede resérvanse, os datos gárdanse en sistemas de almacenamento tolerantes a fallos e o fornecedor de servizos é o responsable financeiro do tempo de inactividade.

   Por exemplo, pode aloxar unha máquina virtual cunha base de datos na nube. A aplicación conectarase á base de datos externamente a través dunha canle establecida ou desde a mesma nube. Se aparecen problemas cun dos servidores do clúster, a máquina virtual reiniciarase no servidor veciño en menos de 2 minutos. Despois diso, o DBMS iniciarase nel e, en poucos minutos, a base de datos estará dispoñible.

   OTR: medido en minutos. Estes termos pódense especificar no acordo co provedor.
   Custa: calculamos o custo dos recursos na nube para a súa aplicación. 
   Do que non che protexerá: de fallos masivos no sitio do provedor, por exemplo, debido a accidentes a nivel da cidade.

2. Agrupar a aplicación  

   Se queres mellorar RTO, podes reforzar a opción anterior e colocar inmediatamente unha aplicación agrupada na nube.

   Pode implementar un clúster en modo activo-pasivo ou activo-activo. Creamos varias máquinas virtuales en función dos requisitos do provedor. Para unha maior fiabilidade, distribúímolos en diferentes servidores e sistemas de almacenamento. Se o servidor cunha das bases de datos falla, o nodo de copia de seguridade asume a carga en poucos segundos.

   OTR: medido en segundos.
   Custa: un pouco máis caro que unha nube normal, necesitaranse recursos adicionais para a agrupación.
   Do que non che protexerá: aínda non protexerá contra fallos masivos no lugar. Pero as interrupcións locais non durarán tanto.

   Da práctica: A empresa de venda polo miúdo tiña varios sistemas de información e sitios web. Todas as bases de datos estaban localizadas localmente na oficina da empresa. Non se pensou en ningún DR ata que a oficina quedou sen enerxía varias veces seguidas. Os clientes non estaban satisfeitos coas fallas do sitio web. 
    
   O problema coa dispoñibilidade do servizo resolveuse tras pasar á nube. Ademais, conseguimos optimizar a carga das bases de datos equilibrando o tráfico entre os nodos.

3. Pasa a unha nube a proba de desastres

   Se precisas asegurarte de que nin sequera un desastre natural no sitio principal interfira co teu traballo, podes escoller unha nube resistente a desastres. Nesta opción, o provedor espalla o clúster de virtualización en 2 centros de datos. A replicación síncrona constante ocorre entre os centros de datos, un a un. As canles entre os centros de datos están reservadas e van por diferentes rutas, polo que un clúster deste tipo non ten medo aos problemas de rede. 

   OTR: tende a 0.
   Custa: A opción de nube máis cara. 
   Do que non che protexerá: Non vai axudar contra a corrupción de datos, así como do factor humano, polo que se recomenda facer copias de seguridade ao mesmo tempo. 

   Da práctica: Un dos nosos clientes desenvolveu un plan completo de recuperación ante desastres. Esta é a estratexia que escolleu: 

   • Unha nube tolerante a desastres protexe a aplicación de fallos a nivel de infraestrutura. 
   • A copia de seguridade de dous niveis ofrece protección en caso de erro humano. Hai dous tipos de copias de seguridade: "frías" e "quentes". Unha copia de seguranza "fría" está desactivada e leva tempo a implementarse. Unha copia de seguranza "quente" xa está lista para o seu uso e restaurase máis rápido. Gárdase nun sistema de almacenamento especialmente dedicado. A terceira copia está gravada en cinta e gárdase noutra sala. 

   Unha vez á semana, o cliente proba a protección e comproba a funcionalidade de todas as copias de seguridade, incluídas as de cinta. Todos os anos a empresa proba toda a nube resistente a desastres. 

4. Organiza a replicación noutro sitio 

   Outra opción sobre como evitar problemas globais no sitio principal: proporcionar xeo-reserva. Noutras palabras, cree máquinas virtuais de copia de seguridade nun sitio doutra cidade. As solucións especiais para DR son adecuadas para iso: na nosa empresa usamos VMware vCloud Availability (vCAV). Coa súa axuda, pode configurar a protección entre varios sitios de provedores de nube ou restaurar a nube desde un sitio local. Xa falei con máis detalle sobre o esquema para traballar con vCAV aquí. 

   RPO e RTO: a partir de 5 minutos. 

   Custa: máis caro que a primeira opción, pero máis barato que a replicación de hardware nunha nube a proba de desastres. O prezo consiste no custo dunha licenza vCAV, as taxas de administración, o custo dos recursos na nube e os recursos de reserva segundo o modelo PAYG (10% do custo dos recursos de traballo para máquinas virtuales apagadas).

   Da práctica: O cliente mantivo 6 máquinas virtuais con diferentes bases de datos na nosa nube en Moscova. Nun principio, a protección ofrecíase mediante copias de seguridade: algunhas das copias de seguridade almacenáronse na nube de Moscova e outras gardáronse no noso sitio de San Petersburgo. Co paso do tempo, as bases de datos creceron en tamaño e a restauración a partir dunha copia de seguridade comezou a levar máis tempo. 
    
   Engadiuse ás copias de seguridade a replicación baseada na dispoñibilidade de VMware vCloud. As réplicas de máquinas virtuais almacénanse nun sitio de copia de seguridade en San Petersburgo e actualízanse cada 5 minutos. Se se produce un fallo no sitio principal, os empregados cambian de forma independente a unha réplica da máquina virtual en San Petersburgo e continúan traballando con ela. 

Todas as solucións consideradas ofrecen alta dispoñibilidade, pero non protexen contra a perda de datos debido a un virus de ransomware ou un erro accidental do empregado. Neste caso, necesitaremos copias de seguridade que proporcionen o RPO necesario.

5. Non esquezas a copia de seguridade

Todo o mundo sabe que cómpre facer copias de seguridade, aínda que teñas a solución máis xenial a proba de desastres. Entón, vouche lembrar brevemente algúns puntos.

En rigor, a copia de seguridade non é DR. E por iso: 

• É moito tempo. Se os datos se miden en terabytes, a recuperación tardará máis dunha hora. Debe restaurar, asignar unha rede, comprobar que se acende, ver que os datos están en orde. Polo tanto, só pode proporcionar un bo RTO se hai poucos datos. 
• É posible que os datos non se restauren a primeira vez e cómpre dar tempo para repetir a acción. Por exemplo, hai momentos nos que non sabemos exactamente cando se perderon os datos. Digamos que a perda se notou ás 15.00 horas, e fanse copias cada hora. A partir das 15.00 horas miramos todos os puntos de recuperación: 14, 00, etc. Se o sistema é importante, tentamos minimizar a antigüidade do punto de recuperación. Pero se a copia de seguridade nova non contiña os datos necesarios, tomamos o seguinte punto: este é un tempo adicional. 

Neste caso, a programación de copia de seguridade pode proporcionar o necesario RPO. Para as copias de seguridade, é importante proporcionar xeo-reserva en caso de problemas co sitio principal. Recoméndase almacenar algunhas copias de seguridade por separado.

O plan final de recuperación ante desastres debe conter polo menos dúas ferramentas:  

• Unha das opcións 1-4, que protexerá os sistemas de fallos e caídas.
• Copia de seguranza para protexer os datos da perda. 

Tamén paga a pena coidar unha canle de comunicación de copia de seguridade no caso de que o principal provedor de Internet caia. E - voila! — Xa está listo o DR nos salarios mínimos. 

Fonte: www.habr.com