Aprimorando a Disponibilidade da rede do ISP

Introdução

Neste artigo discutiremos informações bastante relevantes para o correto dimensionamento de uma das torres funcionais mais primárias da infraestrutura de redes do ISP. Dentre os principais indicadores-chave de performance do negócio (do inglês “KPI”) do provedor, dois destes são tidos como primários: Performance (ou “Desempenho”) e Disponibilidade. E as razões para isto são bem simples, e faço a seguinte reflexão aqui:

• De que adianta uma Internet rápida ou muito rápida, mas cujo serviço fica indisponível para o cliente com razoável ou muita frequência?
• De que adianta uma Internet muito disponível ou com excepcional índice de disponibilidade, se o seu desempenho é ruim ou péssimo?

Como podemos perceber, estes dois indicadores são os primários, pois o assinante/cliente consegue percebê-los fácil e amplamente durante a utilização dos serviços de comunicação de dados ou do serviço de Internet.

Este artigo concentrará na torre funcional de Disponibilidade, e, em outro artigo, discutiremos o de Desempenho.

Definição do Conceito de Disponibilidade e das Torres Funcionais Periféricas

Eu particularmente trato a Disponibilidade como uma “torre funcional”, pois é possível identificar, tipificar, categorizar e agrupar conjuntos de especificações técnicas que fomentam o aumento (ou a diminuição) deste indicador, e isto inclui características físicas e eletromecânicas (ex: hardware em configuração ou disposição redundante) além de abordagens sistêmicas que incluem serviços, recursos, facilidades, tais como protocolos e afins, de nível software, e que maximizam o conceito de Disponibilidade.

A Disponibilidade tem como objetivo fornecer o óbvio: idealmente, toda vez que um usuário (cliente ou assinante, como preferir chama-lo) desejar utilizar o serviço ou o produto contratado, este encontra-se disponível, pronto para quaisquer que sejam os interesses do usuário. Da mesma forma, toda a vez que o usuário tentar acessar o serviço ou o produto e este encontrar-se indisponível, temos então a caracterização de um serviço com algum padrão de frequência desta indisponibilidade.

O indicador de Disponibilidade é afetado pela combinação de outras torres funcionais que participam da mesma missão proposta, que é a de fazer o usuário satisfeito com o serviço contratado. Estas disciplinas seriam Confiabilidade e Resiliência, respectivamente.

A Confiabilidade de uma rede por si só é também um indicador em uma torre funcional própria, mas que agrega positivamente para o aumento da disponibilidade de uma rede. Quando estudando os conceitos de confiabilidade, podemos identificar questões tais como qualidade/confiabilidade de manufatura dos componentes do produto ou dispositivo, características e a presença de componentes em configuração sistêmica redundante, tanto física quanto lógica, além de mecanismos ou recursos periféricos que participam para agregar o conjunto confiabilidade + disponibilidade pretendidos.

A Resiliência, por sua vez, tem relação com a forma em que o dispositivo e/ou a rede como um todo reage em situações onde ocorrem falhas na infraestrutura, sejam estas falhas de um componente de um equipamento ou incidentes de contexto lógico.

Eu particularmente gosto de tratar estes três da seguinte forma: o indicador balizador pretendido é a Disponibilidade, a qual pode ser calculada e aprimorada por conjuntos de especificações tecnológicas derivadas a partir de princípios de Confiabilidade e Resiliência.

Os Desafios dos Provedores na Questão da Disponibilidade

Os provedores de acesso à Internet precisam compreender com absoluta clareza os fundamentos de disponibilidade + confiabilidade + resiliência para que as suas infraestruturas sejam modificadas com o objetivo de atender ou exceder as expectativas de seus clientes. Dentre os tantos desafios, podemos elencar algumas situações ou verdades sobre o tema:

1. A disponibilidade do dispositivo não tem relação direta com a disponibilidade de uma rede. São coisas distintas!
2. A disponibilidade de um dispositivo e a sua devida redundância são frequentemente conflitantes, pois alguns dispositivos mais simples podem ser mais confiáveis enquanto alguns dispositivos mais confiáveis tendem a não ser simples!
3. Os altos Custos são uma eterna dúvida, e precisam ser bem equacionados.

O quanto de Disponibilidade a sua infraestrutura de redes precisa e o quanto você está disposto a pagar por isto?

Uma coisa que pode parecer óbvio mas absolutamente não é: muita redundância é ruim, pois, além de aumentar muito os custos do projeto e da infraestrutura como um todo, torna as funções lógicas da rede demasiadamente complexas e pode inclusive ser um tiro contra o próprio pé! A escolha da quantidade ou qualidade da redundância em uma rede não pode ser tratada que nem o “ponto da carne do churrasco” (cru, mal passado, ao ponto, bem passado), analogias aqui, ou seja, não é uma questão de escolha ou de preferência pessoal. Os projetos de infraestrutura visando melhor disponibilidade precisarão contar com um determinado e ideal padrão de redundância física e lógica, o qual não pode ser escasso e nem demasiadamente excessivo. Talvez um dos maiores desafios aqui está na projeção de uma infraestrutura redundante, confiável e resiliente para que se tenha o indicador de Disponibilidade desejado/ideal, mas fazendo isto de forma que os Custos de adoção destas abordagens sejam compreendidos e compatíveis com a missão do negócio e a realidade financeira do operador de redes.

Nesta questão, segue a minha primeira dica:

Determine os custos de DOWNTIME primeiro, para depois determinar e balancear os custos de Disponibilidade. Será mais fácil você aceitar a dura realidade do investimento necessário quando se compreende com clareza os impactos do negócio decorrentes de uma falha, seja esta uma falha simples e de baixo espectro de aborrecimento, ou uma catástrofe na rede do seu provedor.

• O quanto você está disposto a perder financeiramente com uma falha na sua rede?
• O quanto você está disposto a perder em termos de base de clientes, participação de mercado / market share, reputação e afins, como consequências de desastres na sua rede?
• O quanto você está disposto a investir para mitigar corretamente os tantos riscos que podem provocar desde pequenas, mas inconvenientes, indisponibilidades, até grandes dores de cabeça com falhas e impactos massivos?

Exercite precisamente as três questões acima antes mesmo de tentar elaborar o seu próximo projeto de infraestrutura!

Compatibilizando os Custos de Downtime versus os Custos de Disponibilidade

Acima de tudo, procure identificar e quantificar os seguintes impactos para o negócio do seu provedor:

• Impactos de natureza imediata
  • Perda de receitas
  • Custos com reparos e manutenções corretivas
  • Penalidades dos SLA contratados
  • Insatisfação de clientes
  • Atrasos em projetos internos e externos
  • Distrações negativas no negócio
• Impactos de natureza de longo prazo
  • Danos à imagem da empresa/ISP
  • Churn de clientes, evasão de assinantes
  • Favorecimento indesejável do concorrente
  • Ações e reparações judiciais
  • Perda de confiança, tanto dos funcionários/colaboradores do ISP, quanto do mercado e clientes

Compreendendo a Derivação do Indicador de Disponibilidade

Nesta seção do artigo apresentarei os fundamentos de cálculos de disponibilidade de uma rede.

Um dos principais objetivos nesta questão é permitir ao ISP estabelecer um nível de disponibilidade quantificável matematicamente, ou seja, a disponibilidade de sua rede possuir um índice de disponibilidade quantificável e comunicado para seus clientes nos acordos de SLA. Este índice de disponibilidade é fornecido através de um valor percentual conforme demonstrado a seguir:

Quantificação da confiabilidade e disponibilidade de uma rede

Para chegarmos a esta conta de disponibilidade, temos que primeiro medir a confiabilidade de uma rede, pois a Confiabilidade é um conceito mensurável e, para este cálculo, usamos dois indicadores primários:

Mean Time Between Failures (MTBF)

É o tempo total de operação do dispositivo e/ou da rede como um todo (mas comecemos aqui com o dispositivo/equipamento primeiro, antes de considerarmos o ambiente como um todo) dividido pela quantidade de falhas.

Em outras palavras: "quando isto (o componente) falha?".

Mean Time to Repair (MTTR)

É o tempo que inclui todas as ações de manutenção da falha, incluindo o tempo para o recebimento e detecção do incidente ou falha, tempo gasto para o diagnóstico efetivo do problema, e o tempo gasto para o conserto, podendo ser uma configuração, reinicialização do equipamento, substituição de algum módulo físico com problemas, ou tempo de reparo de um enlace/link de comunicação de dados.

Em outras palavras: "quando tempo leva para conserta-lo?".

A confiabilidade de uma rede e, consequentemente, a sua disponibilidade, podem ser computadas com base nesta simples fórmula:

Cálculo da disponibilidade de uma rede

Confeccionando o seu Diagrama de Blocos de Confiabilidade

Do inglês Reliability Block Diagram (RBD), este diagrama é extremamente útil para que consigamos iniciar todo o trabalho de cálculos da confiabilidade + disponibilidade de uma rede. Essencialmente o RBD serve para, através de um método diagramático, compreender como a confiabilidade dos componentes citados contribuem para o sucesso ou a falha de um sistema complexo, onde, no nosso caso, seria o equipamento da rede.

Os fabricantes de equipamentos de redes, em especial os fabricantes de "primeira linha" aqui, são absolutamente criteriosos na gestão de qualidade de manufatura de seus produtos. Muito do que comentarei aqui não é realmente da alçada do provedor, pois são conceitos presentes na esfera do próprio fabricante, mas, enfim, também não considero um desperdício de tempo citar um pouco do que acontece nestes casos. Vamos lá?

Quando concebendo um novo equipamento no mercado - suprimirei a iniciação e processos disto - focando aqui na questão da confiabilidade dos componentes, diversos artefatos que detalham os requerimentos são produzidos para o controle de qualidade de manufatura. Na questão da confiabilidade, por si só, mais de 150 requerimentos técnicos são injetados em matrizes gerenciáveis e através de mais de 15 disciplinas de confiabilidade. Exemplos de disciplinas aqui incluem Integridade de Sinais, Diagnósticos, Mecânica, Térmica, Elétrica, CAD, Engenharia de HW, Silício (ASIC, FPGA e afins), Ópticos, Manufatura, Engenharia de Componentes, e tantos outros. Diversos estágios nestas disciplinas são trabalhados sobre os mais de 150 requerimentos técnicos do projeto do equipamento. Ultimamente, isto percorrerá uma extensa esteira de Qualidade e Confiabilidade (PQE) para que o produto e todos os seus componentes embarcados sejam testados contra uma extensa lista de situações e em pleno funcionamento/operação, tais como temperatura de operação e armazenamento, altitude de operação, humidade condensada, vibração, choque, interferência EMI e RFI, e dezenas de outros casos. Após todos estes procedimentos o fabricante consegue confirmar os valores de MTBF de seus componentes.

E é justamente aí no MTBF que você, profissional de redes de um ISP, poderá finalmente fazer uso disto. A primeira coisa que você precisará fazer é consultar o fabricante para obter as figuras de confiabilidade (MTBF) do seu equipamento. O fabricante obviamente não fornecerá o MTBF de cada "parafuso" do equipamento, pois isto é absolutamente desnecessário, mesmo! Ao invés disto, o fabricante fornecerá valores agrupados por conjuntos de componentes que perfazem o produto/equipamento. Por exemplo:

• MTBF da fonte de alimentação elétrica
• MTBF do módulo de ventilação
• MTBF do módulo e supervisão e controle (ex: RSP, RP, RE, Supervisor, etc.)
• MTBF do módulo de portas (line card)
• Etc.

De posse dessa informação, o que você faz? Desenha o RBD - mesmo que relativamente simplificado - daquele equipamento e calcula a confiabilidade + disponibilidade daquele equipamento. Utilizemos um exemplo bem simples aqui a título de exemplificação de um RBD contendo figuras de escalabilidade fornecidas pelo fabricante de um equipamento:

OBS: ao conduzir este procedimento, certifique-se de validar os componentes com redundância em série e também o componentes com redundância em paralelo. Por exemplo, a falha do único módulo de supervisão e controle de um roteador interromperia por completo o funcionamento deste equipamento, mesmo que o referido roteador possuísse duas fontes de alimentação elétricas instaladas (ou seja, redundância em paralelo para a parte elétrica), pois há a disposição em "série" entre os blocos funcionais "alimentação elétrica" e "supervisão e controle", onde um depende do outro para manter o equipamento em operação.

Calculando a disponibilidade de um dispositivo

O exemplo acima indica que o equipamento possui uma disponibilidade levemente superior a 99,99%., ou seja, "4-Nines", o que se traduziria matematicamente em 50 minutos de downtime por ano.

Após validar o índice de confiabilidade + disponibilidade de cada equipamento da sua rede, e estendendo esse trabalho também para os enlaces/links, o seu próximo passo deverá ser a derivação completa da confiabilidade + disponibilidade de toda a rede. Um exemplo de como isto poderia ser feito:

Disponibilidade de um cenário de rede

Disponibilidade de um cenário de rede com componentes em SÉRIE (Fonte: Juniper Networks)

Disponibilidade de um cenário de rede com componentes em PARALELO (Fonte: Juniper Networks)

Ao término, você terá compreendido os níveis de disponibilidade de cada dispositivo, de cada enlace, e de toda a infraestrutura de redes. E, consequentemente, poderá finalmente conhecer o Service Level Agreement (SLA) de sua rede, mesmo que ainda e apenas, por enquanto, na questão do MTBF.

Uma Observação Importante quanto ao MTBF

Há algo interessante quando lidando com as figuras de confiabilidade (MTBF) fornecidas pelos fabricantes: são valores estáticos. Os componentes são eletrônica e mecanicamente estressados e testados e em diversas condições (temperatura, altitude, pressão, humidade, vibração, choque/impacto, etc.), e, consequentemente, os níveis de confiabilidade dos componentes são matematicamente validados, ficando disponíveis para o usuário do equipamento. Muitas vezes, claro, os valores não ficam publicamente disponíveis, portanto você deverá solicita-los junto ao fabricante. Todavia, são valores estáticos e não há nada que você possa fazer para aprimora-los.

Os únicos “ajustes” que você pode realizar nestes casos é a melhor seleção da composição do equipamento no que diz respeito a sua redundância física e ações correlatas.

Fatores que Afetam o MTBF de um Dispositivo e/ou da Rede

Chassi: é um elemento primariamente passivo, assim como o seu backplane.

Módulo de Supervisão e Controle (ex: RP, RSP, RE, Supervisor): pode ser único ou em configuração redundante. Ao inserir dois módulos destes no chassi, você, através da redundância em "paralelo" desse bloco apenas, melhora substancialmente o MTBF deste bloco como um todo.

Fontes de alimentação elétrica: um equipamento com uma única fonte fica completamente refém da disponibilidade desta fonte. Alguns equipamentos permitem a inserção de duas ou mais fontes de alimentação. No entanto, fique atento que equipamentos mais “parrudos” possuem requerimentos elétricos mais exigentes, e podem necessitar de um mínimo de fontes presentes/instaladas para manter todos os módulos em funcionamento. Ou seja, nestes casos, a redundância não seria 1 + 1, e sim N + 1 ou N + N, etc.

Módulo de ventilação: alguns fabricantes de equipamentos mais simples possuem um módulo com ventoinhas integradas ao equipamento e que não é permitido a sua substituição sem o desligamento e desmontagem do equipamento (o que afetaria o MTTR). Outros modelos de equipamentos incluem até ventoinhas independentes, mas mantidas por uma única controladora (ou seja, este bloco fica em “série”). Outros modelos de equipamentos possuem bandejas independentes com múltiplas ventoinhas cada, mas que há um mínimo de exigência em termos de número de ventoinhas em pleno funcionamento e com thresholds nos RPM, os quais tem que operar corretamente conforme demandado pelos sensores de temperatura.

Módulo de portas/interfaces físicas (line cards): imagine que você possui dois uplinks críticos na sua rede, e ambos conectados a duas portas independentes, mas ambas do mesmo módulo line card. Há uma relação em “série” entre estes uplinks e o referido módulo, e isto significa que se o módulo falhar os dois uplinks ficarão indisponíveis. Aí eu pergunto: de que adiantou um chassi com 02 controladoras, 04 fontes de alimentação, 02 módulos de ventilação, 01 ou mais módulos de portas, se os uplinks conectam-se para um único módulo de portas? O problema aqui foi o design da sua conectividade. Ao espalhar as conexões físicas redundantes em módulos de portas independentes, você estará aumentando o MTBF do bloco de conectividade entre o equipamento e os uplinks.

Espero que você tenha compreendido isso.

Compreendendo o Mean Time to Repair (MTTR)

Ao contrário do MTBF, onde os valores são praticamente estáticos (variam apenas no projeto da redundância), o MTTR tem natureza absolutamente variável e dinâmica em muitos casos. O MTTR indica quanto tempo levará para reparar a falha ou o incidente, restabelecendo o funcionamento dos serviços afetados.

Outra diferença entre MTBF e MTTR está na interpretação dos valores: para o MTBF, o ideal é que os valores sejam numericamente grandes, o que indicaria uma menor frequência de falhas. Já o MTTR, quanto menor for o valor, melhor, pois, afinal de contas, você quer realmente encurtar o máximo possível o tempo gasto para sanear o problema e reestabelecer o serviço. Certo?

Fatores que Afetam o MTTR de um Dispositivo e/ou da Rede

O MTTR é severamente afetado e em uma variedade de situações que fica até difícil sintetiza-lo aqui. Citarei algumas destas situações:

Falha de componente físico (módulo, fonte...): se um módulo de um equipamento presente no seu datacenter vier a falhar e afetar serviços na sua rede, quanto tempo levaria para você restaurar o serviço?

• Notificação e detecção do problema
  • Quanto tempo levou entre o surgimento do problema e a sua efetiva detecção?
  • Quanto tempo levou para você diagnosticar o problema, compreende-lo e isolar a causa-raiz, possibilitando determinar a ação corretiva apropriada.
  • O MTTR aqui é afetado pela qualidade dos seus processos e ferramentas de gerenciamento de incidentes, e também pelo conhecimento/skill/habilidades de seus funcionários e colaboradores.
• Material sobressalente para reposição
  • Você possui um módulo a título de peça de reposição em estoque local?
  • Você precisa se deslocar até algum lugar para obter a peça de reposição, e retornar ao local de instalação para fazer a substituição?
  • Você não possui qualquer peça de reposição disponível.
    • Possui ao menos um contrato de assistência técnica estendida com o fabricante?
      • Caso afirmativo, qual seria o SLA deste RMA (próximo dia útil, 4 horas, 2 horas?)?
  • Você não possui qualquer peça de reposição disponível e não possui acesso/direito ao RMA, pois não possui um contrato de assistência técnica estendida. O que você faz?
    • Consegue comprar um módulo imediatamente e o melhor prazo possível para o seu recebimento (o que pode levar horas ou dias)?
    • Consegue obter emprestado com algum parceiro ou fornecedor, enquanto compra este módulo no mercado?
  • O MTTR aqui é afetado pelos seus processos de logística, pelo plano de contigenciamento e de recuperação de desastres. Se você não fez nada disso, espere um downtime bem prolongado e destrutível para o negócio.
• Execução de manobras corretivas
  • A reposição do módulo exigirá esforços com configurações/reconfigurações?
    • Você por acaso possui cópias de segurança (backup) vigentes/recentes do equipamento referentes ao módulo que falhou e de seus serviços dependentes.
  • Você não possui backup das configurações ou o backup é relativamente antigo.
    • Caso tenha que reconfigurar, quanto tempo levaria para você refazer toda a configuração, testá-la e isentá-la de erros, e restaurar o serviço.
  • O MTTR aqui é afetado pela qualidade de seus processos operacionais, em especial as questões de antecipação de problemas, gerenciamento de riscos, gerenciamento de incidentes, gerenciamento de configurações, e skill de seus profissionais e colaboradores.
• Acionamento da convergência da infraestrutura
  • O MTTR é afetado aqui conforme a abordagem tecnológica de seu projeto técnico sobre a rede. Ou seja, o padrão de seu projeto, a hierarquia da sua rede, os protocolos de resiliência empregados, e os recursos adicionais que promovem maior confiabilidade para o projeto da rede.

Como podemos perceber, o MTTR é bastante modificado em função de uma série de contextos e situações, dentre os quais elenquei apenas alguns! A questão "operacional" é um dos mais importantes, e focaremos nisto em outro artigo aqui no BPF, assim como conceitos de gerenciamento FCAPS, TMN e afins., além da parte de skills/habilidades/competências, processos e outros temas.

O Cálculo Efetivo da Disponibilidade de uma Rede

A partir do momento em que você compreendeu melhor o MTBF e o MTTR, além dos modelos de redundância em série e em paralelo, consolidemos estes entendimentos através de um modelo didático:

Disponibilidade Calculada

A disponibilidade calculada pode ser derivada com certa facilidade observando-se critérios tais como:

• Projeto da rede: classe dos equipamentos da rede, componentes tais como módulos e afins em configuração redundante, hierarquia da rede (ex: modelo hierárquico + estruturado + modular; as "camadas de função"), etc.
• MTBF e MTTR dos componentes: é importante salientar aqui que há diversos modelos e simulações, incluindo Markov’s Modeling , Reliability Block Diagram (RBD), e "sensitivity analysis - Telcordia SR-1171 Methods and Procedures for System Reliability Analysis", sobre especificações de requerimentos de produtos e targets de confiabilidade motivas pelo mercado e clientes.

O cálculo básico da disponibilidade poderá ser representado da seguinte forma:

Fórmula do cálculo de disponibilidade em Série e em Paralelo

Disponibilidade Mensurada

A disponibilidade mensurada requer o emprego de elementos externos ou complementares para a sua aproximação. Alguns exemplos:

• Testes de conectividade com ferramentas padrão tais como o protocolo ICMP (ping, traceroute e afins).
• Testes de conectividade com ferramentas específicas tais como Cisco Service Level Agreement (IP SLA), Cisco Service Assurance Agent (SAA), e ferramentas equivalentes disponíveis em outros fabricantes.
• Testes de disponibilidade com consultas a objetos gerenciados (OID) via procedimento SNMP.
• Testes com probes externas, capazes de conduzir teste de performance conforme determinados RFC (ex: JDSU).
• Análise e interpretação de troubletickets e tratamentos de logs de indisponibilidades/downtime.
• Métodos observáveis tais como o rastreamento de RMA de componentes faltosos.

Disponibilidade Planejada

Em especial com foco na redução do MTTR:

• Auditoria para condução da análise qualitativa de riscos e demais áreas de gerenciamento de riscos para qualificar e quantificar os riscos de indisponibilidades e como estes afetam os indicadores de performance da organização.
• Elaboração de um plano de contingência e de recuperação de desastres, capaz de atender/sanear os riscos críticos para o negócio e, consequentemente, promover a redução do MTTR e o devido aprimoramento do SLA.
• Elaboração de processos operacionais consistentes e seguros, seguindo à risca os consagrados modelos de indústria para gerenciamento de mudanças, gerenciamento de configurações, gerenciamento de incidentes e afins.
• Realização dos investimentos necessários em treinamento e capacitação dos funcionários e colaboradores para a atuação em eventos de falhas, tanto preventiva quanto corretiva.

Elevando o SLA da sua Rede para o Próximo Nível

O Service Level Agreement (SLA) é ultimamente o indicador que você fornecerá para o mercado e para os seus clientes, e ele é ditado pela sua Disponibilidade Calculada + Disponibilidade Mensurada + Disponibilidade Planejada. Ou seja, o SLA é governado pela torre funcional de "Disponibilidade" de seu projeto técnico, o que, por sua vez, é alimentado pela Confiabilidade e pela Resiliência. No entanto, torna-se necessário separar as áreas-foco da resiliência de uma rede para que fique mais fácil você tratar as áreas de disponibilidade:

Resiliência Nível Sistêmico

São considerados aqui questões tais como a confiabilidade do hardware e do software e ações de redução do MTTR quanto a falhas de componentes físicos e lógicos (RP/RSP/RE, line cards, módulos software, etc.). A arquitetura de software também desempenha uma missão muito importante na questão da resiliência do equipamento. Nos exemplos a seguir, um roteador Cisco ASR 1000, e o software Cisco IOS XE e Cisco IOS XR.

Exemplo de recursos de disponibilidade de um equipamento

Exemplo de arquitetura de disponibilidade de software

Exemplo de arquitetura de disponibilidade de software

OBS: consulte o seu fabricante de escolha para conhecer as características de disponibilidade sistêmicas da arquitetura do equipamento pretendido.

Resiliência Nível Rede

São considerados aqui questões tais como as propriedades do projeto técnico, hierarquia e camadas de função da rede, e a adoção de mecanismos que forneçam uma convergência e recuperação de falhas mais rápido, ágil. Ou seja, tecnologias suplementares, protocolos de resiliência, mecanismos de proteção, etc.

Exemplos de tecnologias para o aumento da disponibilidade na rede (Fonte: Cisco)

Exemplos de tecnologias para o aumento da disponibilidade de serviços L3VPN MPLS (Fonte: Cisco)

Exemplos de tecnologias de alta disponibilidade para os planos de controle e de serviços (Fonte: Cisco)

Exemplos de tecnologias para a rápida detecção de falhas de enlaces (Fonte: Cisco)

Resiliência Nível Operacional

São considerados aqui todas as questões associadas a parte operacional do provedor, incluindo processos, métodos, boas práticas, capacitação de pessoal, além das ferramentas necessárias para ações de diagnósticos, correções e reparos. Futuros artigos no BPF tratarão bem deste tema.

Exemplos de Procedimentos, Tecnologias, Protocolos e Serviços de Confiabilidade da Infraestrutura

Consulte a ilustração a seguir para ter todo o entendimento consolidado acerca dos principais elementos de confiabilidade em uma infraestrutura. A lista obviamente não inclui tudo! Muita coisa teve que ficar de fora.

"Receita Secreta" para Elevar a sua Disponibilidade e SLA

Honesta e ironicamente, não há nada de secreto. Apenas siga estas dicas para elevar o padrão de disponibilidade + SLA para o próximo nível:

1. Documente toda a sua rede. Produza artefatos detalhando todo o L1, L2 e L3 de sua rede, assim como cada elemento ativo na rede. Utilize planilhas, bases de conhecimento internas, diagramas, etc.
2. Produza o Diagrama de Blocos de Confiabilidade (RBD). Inicialmente, de cada dispositivo. Depois, de toda a rede. Procure derivar corretamente o MTBF, MTTR e o MTD (Mean Down Time).
3. Localize os Single Points of Failure (SPOF) de sua rede. Cada ponto único de falha deve ser identificado e assinalado para posterior resolução e mitigação.
4. Exercite e documente o Mapa de Indisponibilidades. Saiba descrever como cada tipo de incidente poderá ocorrer, quais áreas de serviços serão impactadas, quais clientes e usuários ficarão indisponíveis, e por quanto tempo. Represente e confronte estes dados em noções de Categorias, Escopo, Perímetro, Volume, Temporal, etc.
5. Exercite a Análise (Qualitativa, Quantitativa) de Riscos. Até mesmo para poder ajudá-lo na aprovação do projeto que ditará as correções e investimentos necessários. Você precisará conhecer com detalhes todos o riscos que corre e como cada falha pode ocorrer, assim como cada distúrbio que isto provocará para o seu negócio (multas, reparação, reputação, fuga de clientes, etc.). Procure qualificar isto e quantificar financeiramente estes danos. É aqui que você poderá ser bem razoável na equação "quanto eu vou perder se a minha rede parar" vs. "quando vou gastar para a minha rede não parar e eu não ter estas perdas". Vale a pena investir ou vale a pena correr o risco?
6. Elabore um Projeto Executivo. Este artefato será muito útil para, de uma forma bem objetiva ("executiva"!), documentar as iniciativas que resolverão os riscos identificados. Procure acertar nem a mão aqui para buscar a aprovação do projeto no que diz respeito à sua viabilidade técnica.
7. Elabore um Projeto Técnico Detalhado. Se necessário. O PTD aborda miúdos do conceito de solução que podem ser exigidos para processos de integrações mais complexas.
8. Elabore um Plano Diretor de Investimentos. Não tenha vergonha em pedir a ajuda de fabricantes e de parceiros estratégicos. Evite apenas os consultores "achômetros" e pouco criteriosos. E evite também comprar soluções com vendedores de equipamentos que não possuem competência em lidar, eles mesmos, com as questões técnicas associadas ao projeto (implantação, suporte, etc.). Aqui você tentará viabilizar os investimentos contando com o apoio do fabricante (times de vendas, especialistas técnicos e times de serviços), canal de distribuição do fabricante, parceiro estratégico (VAR/revenda), instituições financeiras, etc.
9. Conte com uma empresa prestadora de serviços com as devidas credenciais e qualificações. Não tente fazer tudo sozinho. Saiba reconhecer que você precisa evoluir, e deixe na mão de quem conhece de fato este tipo de trabalho. Aproveite a oportunidade para fazer duas coisas: a) procure acompanhar tudo bem de perto e a aprender. b) foque em fornecer resultados para o seu negócio/empresa, e não distrações.
10. Mantenha a documentação da rede em dia. Isto inclui todo o tipo de artefato que mantém a documentação da rede bem consistente e vigente.
11. Revalide o seu plano de contingência e de recuperação de desastres.

Assista ao Vídeo "BPF: compreendendo os fundamentos de Disponibilidade da rede de um ISP"

Este vídeo com 41 minutos de duração explora os temas discutidos aqui através de uma linguagem bem fácil e objetiva. Assista aqui: https://youtu.be/e00Qs1H26Zo

BPF: compreendendo os fundamentos de Disponibilidade da rede de um ISP

Considerações Finais

Você sabia que a maior parte dos incidentes que provocam indisponibilidades em uma rede são decorrentes de falha humana? Ausência de processos seguros para gestão de mudanças, por exemplo? O artigo focou em comentar primariamente a parte da infraestrutura e menos na parte de "pessoal", mas, não se preocupe, o BPF em breve publicará artigos sobre o tema de processos e boas práticas operacionais para ambientes de provedores.

Espero que este artigo tenha sido útil. Até o próximo!

Autor: Leonardo Furtado