Classificação de criticidade de sistemas de informação

"O banco Alfa é tão confiável quanto um tanque,

e o Gamma-banco é tão confiável quanto um banco!"



Victor Pelevin, "Números"

Quando a frase "sistema bancário" aparece nas conversas, a imaginação desenha um sistema superconfiável construído sobre o equipamento mais caro, agrupado em todos os níveis possíveis e isolado do mundo exterior por meios de proteção acessíveis e inacessíveis. Na verdade, esses sistemas existem. Mas ...







Se você olhar as vagas de desenvolvedores no banco, então é bem possível ver ali entre os requisitos de conhecimento do Cassandra, MongoDB e outras plataformas, que de forma alguma inspiram pensamentos sobre 100% de disponibilidade. E DBMS como Oracle ou Microsoft SQL Server são instalados em algum lugar em um cluster de servidores caros conectados aos arrays mais confiáveis ​​e de alto desempenho, e em algum lugar em uma máquina virtual regular em um farm da própria commodity.



As razões são óbvias - soluções redundantes são caras. Mas como encontrar um meio-termo entre o custo da plataforma e sua confiabilidade?



Era uma vez, quando havia poucos sistemas de informação na empresa, a infraestrutura de cada sistema era uma obra de arte. Com o tempo, surgiram mais sistemas, tornou-se caro dar suporte a várias centenas de configurações diferentes de hardware e software e os departamentos de infraestrutura passaram a padronizar. Por exemplo, um conjunto de soluções de infraestrutura RDBMS que os aplicativos podem usar pode ter a seguinte aparência:

• servidores de classe hi-end com matrizes de disco de classe hi-end mais replicação síncrona;
• servidores midrange com matrizes de disco midrange mais replicação síncrona;
• servidores de classe midrange com matrizes de disco midrange mais replicação assíncrona;
• servidores commodity com matrizes de disco de médio porte sem replicação.

Agora, como você escolhe uma configuração para um banco de dados específico pertencente a um aplicativo específico?



Você pode fazer uma lista dos "aplicativos mais importantes que devem funcionar a todo custo". Isso levanta dois problemas:



A configuração de hardware para os aplicativos restantes depende do "peso" do proprietário do sistema. Como resultado, algum serviço de licença médica eletrônica funciona no equipamento mais caro, porque esta é a ideia favorita do contador-chefe, com quem ninguém quer brigar. Este é um desperdício de dinheiro irracional.



Alguns aplicativos podem não estar incluídos na lista "mais importante" porque não foram considerados. Por exemplo, todos se lembram do processamento de cartões bancários, mas ninguém se lembra de checar clientes em "listas negras", que deveriam funcionar em todas as operações. Como resultado, a falha de tal sistema se torna uma surpresa desagradável e leva a sérios problemas.



Existe uma metodologia formal que permite que você faça a escolha certa e proteja o que precisa de proteção sem pagar a mais pelo que você não pode pagar a mais.



Para começar, é apresentada uma classificação das aplicações de acordo com o nível de criticidade. Via de regra, existem quatro desses níveis. Eles podem ser chamados, por exemplo, assim:

• Platina;
• Ouro;
• Prata;
• Bronze.

Ou assim:

• Missão crítica;
• Negócio crítico;
• Operacional de negócios;
• Produtividade do escritório.

Essas quatro camadas se encaixam perfeitamente em quatro configurações de infraestrutura diferentes. A única coisa que resta a fazer é classificar cada aplicativo conforme necessário.



Ao avaliar, é importante observar duas regras:



O sistema é avaliado pelo negócio, e não pelo departamento de TI que o atende. A criticidade não deve ser determinada por quanto tempo ou trabalho intensivo o sistema deve manter. O único critério são as perdas que a empresa incorrerá devido ao tempo de inatividade do sistema.



A formulação das questões que compõem a avaliação deve prever a possibilidade de verificação das respostas. É claro que os critérios ainda se baseiam na opinião de especialistas, mas o especialista, pelo menos, pode explicar por que fez essa avaliação.



O que determina o nível de criticidade?

• . , , , .
• SLA (service level agreement). , – , .
• . , , .

Na prática mundial, algo como isto se desenvolveu:







Isso não significa que em sua empresa a distribuição de sistemas por classes deva ser exatamente a mesma. Mas, em qualquer caso, se mais de 15% dos sistemas operacionais entraram na classe de missão crítica, esse é um motivo para pensar seriamente.



À pergunta "quanto é necessário este ou aquele sistema", qualquer proprietário responderá "muito". Portanto, outra pergunta precisa ser feita: o que acontece se o sistema parar? A classe de criticidade do sistema depende da gravidade das consequências do desligamento do sistema e da velocidade de sua ocorrência.



Vamos dar uma olhada em vários sistemas bancários.



O sistema de liquidação oferece (surpresa!) Liquidações entre clientes - pessoas jurídicas. Se, repentinamente, um grande cliente corporativo não puder fazer um pagamento a uma contraparte, o banco perderá uma quantia muito significativa, de modo que o sistema de liquidação sem dúvida cairá na classe mais alta de criticidade.



Vamos analisar o processamento do cartão. Se cem ou dois clientes não puderem pagar com cartão, as perdas do banco serão pequenas, mas essa negação de serviço massiva é inaceitável por si só.



Agora vamos pegar um sistema que mantém depósitos. Se esse sistema parar, as perdas do banco serão novamente pequenas e a negação de serviço não será tão grande como no caso de processamento. Mas precisamos de um editorial de jornal com o título "O banco se recusa a emitir depósitos"? A pergunta é retórica.



Finalmente, vamos analisar o livro-razão geral. Se de repente algo acontecer com ela, os clientes não perceberão nada, já que este sistema não participa do atendimento de forma alguma. Mas vale a pena atrasar a entrega do balanço, pois as sanções do Banco Central não tardarão a chegar.



Portanto, as consequências negativas do tempo de inatividade do sistema podem ser divididas em 4 classes:

• Econômico (perdas diretas);
• Cliente (negação de serviço);
• Reputacional (reações negativas na mídia);
• Legal (desde advertências e multas a ações judiciais e revogação de licença).

Para cada classe de consequências, os critérios de gravidade devem ser formulados e pontuações atribuídas de 0 a 4. Por exemplo, a tabela pode ter a seguinte aparência:





É claro que todos os números são arbitrários, todos os métodos de cálculo são baseados exclusivamente no julgamento de especialistas e o escopo para debate sobre o que considerar como "mídia regional" e como tratar artigos negativos em blogs populares é realmente ilimitado. Mas, em uma grande empresa, certamente haverá um departamento jurídico e um serviço de RP que expressará prontamente uma opinião competente.



O próximo passo é escolher os intervalos de tempo em que estimaremos as perdas. Por exemplo, hora, 4 horas, 8 horas, 24 horas. Esses intervalos são arbitrários e não têm nenhuma relação com os SLAs dos sistemas avaliados. Embora no futuro seja correto vincular o SLA típico exatamente a esses intervalos.



Agora o dono de cada sistema preenche uma matriz de 16 células. Os números na tabela abaixo são dados como exemplos. A única coisa que é fundamentalmente importante é que a estimativa das consequências para um intervalo mais longo não pode ser menor do que a estimativa para um intervalo mais curto.





Existem três etapas restantes para obter a pontuação final desta matriz.

Etapa um - para cada intervalo de tempo, selecione a estimativa máxima:





Etapa dois: traduzimos as estimativas obtidas nas classes de criticidade usando a matriz:





Para este sistema, obtemos as seguintes estimativas:





E, por fim, de todas as estimativas obtidas, escolhe-se a máxima - neste caso, o sistema em avaliação deve ser classificado como Business Critical.



Tendo recebido essas estimativas, podemos escolher razoavelmente uma ou outra solução de infraestrutura para cada sistema.



Restam várias nuances, sem as quais a metodologia descrita estaria incompleta.



Se o sistema garante a operabilidade de outro sistema, então sua classe de criticidade não pode ser inferior à classe do sistema dependente. Por exemplo, o Active Directory não tem nada a ver com negócios. Mas se aumentar repentinamente, as consequências para muitos aplicativos de negócios serão as mais terríveis e, portanto, o AD definitivamente pertence à classe de missão crítica.



As perdas incorridas como resultado do tempo de inatividade do sistema não podem ser menores do que as perdas incorridas pela interrupção do processo de negócios que este sistema fornece. À luz dessa regra, é muito interessante avaliar o sistema de e-mail corporativo, pois de repente descobre-se que a troca de informações críticas está atrelada a ele.



Se uma empresa usa vários blocos no mesmo sistema e as estimativas desses blocos para o sistema diferem, então a estimativa máxima deve ser usada. Além disso, mesmo os critérios de avaliação podem ser diferentes. Assim, por exemplo, a avaliação da impossibilidade de atender um cliente pode diferir muito dependendo do tipo de cliente - um "físico" comum, VIP ou um grande cliente corporativo.



Identifique seus sistemas - e que sua infraestrutura seja tão confiável quanto precisa ser, mas não mais cara do que pode ser!