Aprimorando a Disponibilidade da rede do ISP

Aprimorando a Disponibilidade da Rede do ISP

Nota sobre direitos autorais, termo de uso e isenção de responsabilidade

Consulte os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional.

Autor: Leonardo Furtado

Introdução

Neste artigo abordaremos informações essenciais para o correto dimensionamento de uma das torres funcionais mais básicas da infraestrutura de redes do ISP. Entre os principais indicadores-chave de desempenho do negócio (KPI) do provedor, destacam-se dois como primários: Performance (ou "Desempenho") e Disponibilidade. As razões são simples, como podemos ver na seguinte reflexão:

• De que adianta uma Internet rápida ou muito rápida se o serviço fica indisponível para o cliente com frequência?
• De que adianta uma Internet com alta disponibilidade se seu desempenho é ruim?

Estes dois indicadores são considerados primários justamente porque o assinante consegue percebê-los facilmente durante a utilização dos serviços de comunicação de dados ou de Internet.

Este artigo focará na torre funcional de Disponibilidade, enquanto o tema Desempenho será abordado em outro artigo.

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

Eu trato a Disponibilidade como uma "torre funcional", pois é possível identificar, categorizar e agrupar especificações técnicas que contribuem para o aumento (ou diminuição) deste indicador. Isso inclui características físicas e eletromecânicas (como hardware em configuração redundante), além de abordagens sistêmicas que englobam serviços, recursos e facilidades, como protocolos e outros elementos de software, que maximizam a Disponibilidade.

A Disponibilidade tem um objetivo simples: garantir que o serviço ou produto esteja pronto para uso sempre que o cliente (ou assinante) precisar. Quando o usuário não consegue acessar o serviço, caracterizamos uma indisponibilidade, que pode ocorrer com diferentes frequências.

O indicador de Disponibilidade é influenciado por duas outras torres funcionais essenciais para a satisfação do usuário: Confiabilidade e Resiliência.

A Confiabilidade, embora seja um indicador independente, contribui diretamente para aumentar a disponibilidade da rede. Ela engloba aspectos como qualidade de manufatura dos componentes, presença de redundância sistêmica (física e lógica) e recursos complementares que fortalecem o conjunto confiabilidade + disponibilidade.

A Resiliência se refere à capacidade do dispositivo ou da rede de reagir a falhas na infraestrutura, sejam elas físicas (em componentes) ou lógicas.

É importante frisar que resiliência não é redundância. Resiliência é a capacidade de cada componente, individualmente, responder a diversas situações que afetem sua disponibilidade, considerando seu papel em uma comunicação fim-a-fim e sua posição em um diagrama de bloco de confiabilidade, seja em série ou em paralelo.

Em síntese: a Disponibilidade é nosso indicador principal, que pode ser calculado e aprimorado através de especificações tecnológicas baseadas nos 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 não parecer óbvia: excesso de redundância é prejudicial. Além de aumentar significativamente os custos do projeto e da infraestrutura, torna as funções lógicas da rede demasiadamente complexas - podendo até se tornar contraproducente.

A escolha da quantidade ou qualidade da redundância em uma rede não pode ser tratada como uma simples questão de preferência pessoal, como escolher o ponto da carne no churrasco (cru, mal passado, ao ponto, bem passado…).

Os projetos de infraestrutura que visam melhor disponibilidade precisam estabelecer um padrão ideal de redundância física e lógica, evitando tanto a escassez quanto o excesso. Um dos maiores desafios está em projetar uma infraestrutura redundante, confiável e resiliente para atingir o indicador de Disponibilidade desejado, garantindo que os Custos sejam 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 aceitar a realidade do investimento necessário quando se compreende claramente os impactos de uma falha no negócio, seja ela simples 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

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ção corretiva
  • Penalidades contratuais de SLA
  • Insatisfação dos clientes
  • Atrasos em projetos internos e externos
  • Impactos negativos na operação do negócio
• Impactos de natureza de longo prazo
  • Danos à imagem da empresa/ISP
  • Churn e evasão de assinantes
  • Fortalecimento indevido da concorrência
  • Processos e reparações judiciais
  • Perda de confiança dos funcionários, colaboradores, mercado e clientes

Compreendendo a Derivação do Indicador de Disponibilidade

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

O principal objetivo é permitir que o ISP estabeleça um nível de disponibilidade matematicamente quantificável. Isso significa que a rede terá um índice de disponibilidade mensurável, que será comunicado aos clientes nos acordos de SLA. Este índice é expresso através de um valor percentual, como demonstrado a seguir:

Quantificação da confiabilidade e disponibilidade de uma rede

Para calcular a disponibilidade, precisamos primeiro medir a confiabilidade de uma rede, pois a Confiabilidade é um conceito mensurável. Para este cálculo, utilizamos dois indicadores primários:

Mean Time Between Failures (MTBF)

É o tempo total de operação do dispositivo e/ou da rede dividido pela quantidade de falhas. Para simplificar, começamos analisando um dispositivo individual antes de considerar o ambiente completo.

Em outras palavras: "quando o componente falha?"

Mean Time to Repair (MTTR)

É o tempo total necessário para resolver uma falha, incluindo: detecção do incidente, diagnóstico do problema e reparo efetivo. O reparo pode envolver configuração, reinicialização do equipamento, substituição de módulos ou conserto de enlaces de comunicação.

Em outras palavras: "quanto tempo leva para consertá-lo?"

A confiabilidade de uma rede e, por consequência, sua disponibilidade, podem ser calculadas através de uma fórmula simples:

Cálculo da disponibilidade de uma rede

Confeccionando o seu Diagrama de Blocos de Confiabilidade

Do inglês Reliability Block Diagram (RBD), este diagrama é uma ferramenta essencial para iniciar os cálculos de confiabilidade e disponibilidade de uma rede. O RBD utiliza um método diagramático para demonstrar como a confiabilidade dos componentes contribui para o sucesso ou falha de um sistema complexo. No nosso caso, o equipamento da rede.

Os fabricantes de equipamentos de redes, especialmente os de primeira linha, são extremamente criteriosos na gestão de qualidade de manufatura de seus produtos. Embora muitos dos conceitos que abordarei estejam na esfera do fabricante e não do provedor, vale a pena entender um pouco desse processo. Vamos lá?

No desenvolvimento de um novo equipamento, e deixando de lado os processos iniciais, a confiabilidade dos componentes é rigorosamente avaliada.

São mais de 150 requisitos técnicos distribuídos em mais de 15 disciplinas de confiabilidade, incluindo Integridade de Sinais, Diagnósticos, Mecânica, Térmica, Elétrica, CAD, Engenharia de Hardware, Silício (ASIC, FPGA e afins), Ópticos, Manufatura e Engenharia de Componentes.

Todos esses requisitos passam por uma extensa esteira de Qualidade e Confiabilidade (PQE), onde o produto e seus componentes são testados em diversas condições: temperatura de operação e armazenamento, altitude, umidade condensada, vibração, choque, interferência EMI e RFI, entre outros. Só após esses testes o fabricante determina os valores de MTBF dos componentes.

É com esses valores de MTBF que você, profissional de redes de um ISP, poderá trabalhar. O primeiro passo é solicitar ao fabricante as figuras de confiabilidade (MTBF) do seu equipamento. O fabricante não fornecerá o MTBF de cada componente individual, já que isso seria desnecessário. Em vez disso, você receberá valores agrupados por conjuntos funcionais do equipamento. Por exemplo:

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

Com essas informações em mãos, você deve desenhar o RBD (mesmo que simplificado) do equipamento e calcular sua confiabilidade e disponibilidade. Vamos usar um exemplo simples para demonstrar um RBD com as figuras de escalabilidade fornecidas pelo fabricante:

OBS: durante este procedimento, é essencial validar tanto os componentes com redundância em série quanto em paralelo. Por exemplo: mesmo que um roteador possua duas fontes de alimentação instaladas (redundância em paralelo para a parte elétrica), a falha de um único módulo de supervisão e controle interromperia completamente seu funcionamento. Isso ocorre porque existe uma 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 operacional.

Calculando a disponibilidade de um dispositivo (Fonte: Cisco)

O exemplo acima mostra que o equipamento possui uma disponibilidade ligeiramente superior a 99,99% (conhecida como "4-Nines"), o que representa matematicamente cerca de 50 minutos de downtime por ano.

Após validar o índice de confiabilidade e disponibilidade de cada equipamento da sua rede, incluindo também os enlaces/links, seu próximo passo será determinar a confiabilidade e disponibilidade completa de toda a rede. Veja um exemplo de como isto pode ser feito:

Disponibilidade de um cenário de rede (Fonte: Cisco)

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 final desse processo, você terá uma compreensão clara dos níveis de disponibilidade de cada dispositivo, enlace e toda a infraestrutura de rede. Como resultado, poderá definir o Service Level Agreement (SLA) de sua rede, mesmo que inicialmente apenas em relação ao MTBF.

Uma Observação Importante quanto ao MTBF

Há um aspecto interessante sobre as figuras de confiabilidade (MTBF) fornecidas pelos fabricantes: elas são valores estáticos.

Os componentes são submetidos a testes rigorosos de estresse eletrônico e mecânico sob diversas condições (temperatura, altitude, pressão, umidade, vibração, choque/impacto, etc.). Como resultado, os níveis de confiabilidade dos componentes são validados matematicamente e disponibilizados ao usuário do equipamento.

Na maioria dos casos, esses valores não são publicamente disponíveis, sendo necessário solicitá-los diretamente ao fabricante. É importante notar que, por serem estáticos, não há como aprimorá-los.

Os únicos "ajustes" possíveis nestes casos são a seleção criteriosa da composição do equipamento quanto à sua redundância física e ações relacionadas.

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

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

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

Fontes de alimentação elétrica: um equipamento com fonte única depende totalmente da disponibilidade desta fonte. Alguns equipamentos aceitam duas ou mais fontes. Porém, equipamentos mais robustos têm requisitos elétricos mais exigentes e podem necessitar de um número mínimo de fontes instaladas para manter todos os módulos funcionando. Nesses casos, a redundância não seria 1 + 1, mas sim N + 1 ou N + N.

Módulo de ventilação: alguns fabricantes de equipamentos mais simples usam módulos com ventoinhas integradas que não podem ser substituídas sem desligar e desmontar o equipamento (afetando o MTTR). Outros modelos têm ventoinhas independentes controladas por uma única placa (ficando em "série"). Há ainda modelos com bandejas independentes com múltiplas ventoinhas, mas exigem um número mínimo delas funcionando com thresholds de RPM específicos, conforme demandado pelos sensores de temperatura.

Módulo de portas/interfaces físicas (line cards): considere um cenário com dois uplinks críticos conectados a portas independentes do mesmo módulo line card. Existe uma relação em "série" entre estes uplinks e o módulo - se ele falhar, ambos os uplinks ficam indisponíveis. De que adianta ter um chassi com duas controladoras, quatro fontes de alimentação e dois módulos de ventilação se os uplinks dependem de um único módulo de portas? O problema está no design da conectividade. Ao distribuir as conexões físicas redundantes em módulos diferentes, você aumenta 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)

Diferentemente do MTBF, cujos valores são praticamente estáticos (variando apenas no projeto da redundância), o MTTR possui natureza altamente variável e dinâmica. O MTTR indica o tempo necessário para reparar uma falha ou incidente e restabelecer o funcionamento dos serviços afetados.

A interpretação desses valores também difere: para o MTBF, quanto maior o valor, melhor, pois indica menor frequência de falhas. Já para o MTTR, quanto menor o valor, melhor, pois o objetivo é minimizar o tempo necessário para resolver o problema e restaurar o serviço.

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:

O MTTR é significativamente afetado por diversas situações, das quais destacaremos as principais:

Falha de componente físico (módulo, fonte...): se um módulo em seu datacenter falhar e afetar serviços na rede, qual seria o tempo necessário para restaurar o serviço?

• Notificação e detecção do problema
  • Qual foi o intervalo entre o surgimento do problema e sua detecção efetiva?
  • Quanto tempo foi necessário para diagnosticar o problema, compreendê-lo e isolar a causa-raiz, permitindo determinar a ação corretiva adequada? O MTTR aqui é afetado pela qualidade dos seus processos e ferramentas de gerenciamento de incidentes, além do conhecimento e habilidades de seus funcionários e colaboradores.
• Material sobressalente para reposição
  • Você possui peça de reposição em estoque local?
  • Precisa se deslocar para obter a peça de reposição e retornar ao local de instalação?
  • Você não possui peça de reposição disponível.
    • Possui contrato de assistência técnica estendida com o fabricante?
      • Caso afirmativo, qual é o SLA deste RMA (próximo dia útil, 4 horas, 2 horas)?
  • Na ausência de peças de reposição e sem acesso ao RMA por falta de contrato de assistência técnica estendida, quais são suas opções?
    • É possível comprar um módulo imediatamente, considerando o melhor prazo de entrega (que pode variar de horas a dias)?
    • Existe a possibilidade de empréstimo com algum parceiro ou fornecedor enquanto aguarda a compra do módulo? O MTTR é diretamente impactado pelos seus processos de logística, plano de contingenciamento e recuperação de desastres. Sem essas medidas preventivas, prepare-se para um downtime prolongado e prejudicial ao 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

Agora que você compreendeu melhor o MTBF e o MTTR, bem como os modelos de redundância em série e em paralelo, vamos consolidar estes conceitos através de um modelo didático:

Disponibilidade Calculada

A disponibilidade calculada pode ser determinada observando-se os seguintes critérios:

• Projeto da rede: classe dos equipamentos, componentes em configuração redundante, hierarquia da rede (como o modelo hierárquico + estruturado + modular e as "camadas de função"), entre outros.
• MTBF e MTTR dos componentes: é importante destacar que existem 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", relacionados às especificações de requisitos de produtos e metas de confiabilidade estabelecidas pelo mercado e clientes.

O cálculo básico da disponibilidade pode 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 sua medição. Alguns exemplos:

• Testes de conectividade com ferramentas padrão como o protocolo ICMP (ping, traceroute e similares).
• Testes de conectividade com ferramentas específicas como Cisco Service Level Agreement (IP SLA), Cisco Service Assurance Agent (SAA) e ferramentas equivalentes de outros fabricantes.
• Testes de disponibilidade com consultas a objetos gerenciados (OID) via SNMP.
• Testes com sondas externas para medição de desempenho conforme RFCs específicos (exemplo: JDSU).
• Análise e interpretação de registros de chamados técnicos e logs de indisponibilidade.
• Métodos observáveis como o acompanhamento de RMA de componentes defeituosos.

Disponibilidade Planejada

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

• Realização de auditoria para análise qualitativa de riscos e gerenciamento de riscos, visando identificar e mensurar os riscos de indisponibilidade e seus impactos nos indicadores de performance da organização.
• Desenvolvimento de plano de contingência e recuperação de desastres para mitigar riscos críticos do negócio, reduzindo o MTTR e aprimorando o SLA.
• Implementação de processos operacionais robustos e seguros, alinhados aos modelos consagrados da indústria para gerenciamento de mudanças, configurações e incidentes.
• Investimento em treinamento e capacitação da equipe para atuação eficiente em falhas, tanto em ações preventivas quanto corretivas.

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

O Service Level Agreement (SLA) é o principal indicador que você fornece ao mercado e aos seus clientes. Ele é determinado pela combinação da Disponibilidade Calculada, Mensurada e Planejada. Em outras palavras, o SLA é governado pela torre funcional de "Disponibilidade" do seu projeto técnico, que se baseia na Confiabilidade e na Resiliência. Para facilitar o tratamento das áreas de disponibilidade, é importante separar as áreas-foco da resiliência de uma rede:

Resiliência Nível Sistêmico

São considerados aqui aspectos como a confiabilidade do hardware e software, bem como ações para redução do MTTR em falhas de componentes físicos e lógicos (RP/RSP/RE, line cards, módulos de software etc.). A arquitetura de software tem papel fundamental na resiliência do equipamento. Veremos isso nos exemplos a seguir, utilizando um roteador Cisco ASR 1000 e os softwares Cisco IOS XE e Cisco IOS XR.

Exemplo de recursos de disponibilidade de um equipamento (Fonte: Cisco)

Exemplo de arquitetura de disponibilidade de software (Fonte: Cisco)

Exemplo de arquitetura de disponibilidade de software (Fonte: Cisco)

Observação: consulte o fabricante de sua escolha para conhecer as características de disponibilidade sistêmicas da arquitetura do equipamento pretendido.

Resiliência Nível Rede

São considerados aqui aspectos como as propriedades do projeto técnico, a hierarquia e as camadas de função da rede, além da adoção de mecanismos que forneçam uma convergência e recuperação de falhas mais rápida e ágil. Isso inclui tecnologias suplementares, protocolos de resiliência e mecanismos de proteção.

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 consideradas aqui todas as questões associadas à parte operacional do provedor, incluindo processos, métodos, boas práticas, capacitação de pessoal e ferramentas necessárias para ações de diagnóstico, correção e reparo. Futuros artigos no BPF abordarão este tema em detalhes.

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

Consulte a ilustração a seguir para compreender os principais elementos de confiabilidade em uma infraestrutura de forma consolidada. A lista não é exaustiva; diversos outros elementos importantes não puderam ser incluídos.

Dicas para Elevar a sua Disponibilidade e SLA

Na verdade, não há nada de secreto. Siga estas dicas comprovadas para elevar o padrão de disponibilidade e SLA ao próximo nível:

1. Documente toda a sua rede. Produza artefatos detalhando as camadas L1, L2 e L3, assim como cada elemento ativo. Utilize planilhas, bases de conhecimento internas e diagramas. A propósito, confira o artigo Boas Práticas para a Documentação de Infraestruturas de Redes e Serviços do Provedor em nossa Wiki!
2. Produza o Diagrama de Blocos de Confiabilidade (RBD). Comece com cada dispositivo individual e depois expanda para toda a rede. Determine com precisão o MTBF, MTTR e o MTD (Mean Down Time).
3. Localize os Single Points of Failure (SPOF) de sua rede. Identifique e marque cada ponto único de falha para posterior resolução e mitigação.
4. Elabore e documente o Mapa de Indisponibilidades. Detalhe como cada tipo de incidente pode ocorrer, áreas de serviços impactadas, usuários afetados e duração prevista. Classifique esses dados por categoria, escopo, perímetro, volume e aspectos temporais.
5. Realize a Análise de Riscos Qualitativa e Quantitativa. Isto auxiliará na aprovação do projeto e seus investimentos necessários. Conheça detalhadamente seus riscos, possíveis falhas e impactos no negócio (multas, reparações, reputação e perda de clientes). Quantifique financeiramente estes danos. Compare "quanto eu vou perder se a minha rede parar" versus "quando vou gastar para a minha rede não parar e eu não ter estas perdas". Vale mais investir ou correr o risco?
6. Elabore um Projeto Executivo. Este documento objetivo documentará as iniciativas para resolver os riscos identificados. Foque na viabilidade técnica para garantir a aprovação do projeto.
7. Elabore um Projeto Técnico Detalhado. Quando necessário, o PTD abordará especificações técnicas essenciais para integrações complexas.
8. Elabore um Plano Diretor de Investimentos. Busque apoio de fabricantes e parceiros estratégicos competentes. Evite consultores superficiais e vendedores sem expertise técnica em implantação e suporte. Procure viabilizar investimentos com apoio do fabricante, canais de distribuição, parceiros estratégicos (VAR/revenda) e instituições financeiras.
9. Contrate uma empresa de serviços qualificada. Reconheça suas limitações e confie em especialistas. Aproveite para: a) acompanhar de perto e aprender; b) concentrar-se nos resultados do negócio, não em distrações.
10. Mantenha a documentação atualizada. Garanta que todos os artefatos da rede permaneçam consistentes e vigentes.
11. Revalide o plano de contingência e 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/egrNHwwoaOY

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

Inovações recentes

Para elevar estas ideias ao próximo nível:

1. Redes Autocorretivas (Self-Healing Networks)

As redes autocorretivas representam um avanço significativo na automação. Elas permitem que a infraestrutura detecte, diagnostique e resolva problemas autonomamente, sem intervenção humana. Essa abordagem reduz o tempo de inatividade e melhora a resiliência operacional.

2. Operações de Rede Baseadas em IA (AIOps)

A integração de Inteligência Artificial nas operações de rede permite análises preditivas e automação de tarefas complexas.

3. Arquitetura de Automação Sem Limites (Boundless Automation)

A Emerson desenvolveu a arquitetura Boundless Automation™, integrando dados de dispositivos de campo, edge computing e nuvem em uma infraestrutura adaptável. Essa abordagem permite otimização em tempo real e resposta rápida a falhas, aumentando a disponibilidade da rede.

4. Plataformas de Automação Agnósticas a Fornecedores

Com redes cada vez mais complexas, cresce a adoção de plataformas de automação independentes de fornecedor único. Essas soluções integram diversos dispositivos e sistemas, simplificando a gestão e aumentando a flexibilidade operacional.

5. Redes Zero-Touch com AutoML

As redes Zero-Touch automatizam completamente a gestão de rede, usando aprendizado de máquina automatizado para adaptação dinâmica e otimização de desempenho. Essa abordagem é crucial para redes 5G e tecnologias futuras.

6. Redundância Transparente de Alta Disponibilidade (HSR)

O protocolo High-availability Seamless Redundancy oferece failover sem interrupções, garantindo continuidade mesmo durante falhas de componentes. É especialmente valioso em ambientes industriais que exigem alta disponibilidade.

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