Boas Praticas para Politicas de Manutencao de Software de Ativos de Rede

De Wiki BPF
Ir para navegação Ir para pesquisar

Boas Práticas para Políticas de Manutenção de Software de Ativos de Rede

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

Este artigo dissemina alguns conceitos de boas práticas para que o ISP possa lidar de maneira apropriada com as questões relacionadas a manutenção de software dos equipamentos de redes. Este artigo está estruturado em dois conceitos bem definidos:

  1. O que você deve saber para escolher um software para o seu equipamento. E, de certa forma, envolvendo a escolha da plataforma HW+SW como um todo.
  2. O que você precisa compreender sobre ações de manutenção de software (udpates e upgrades).

A cultura atual do profissional de redes no que diz respeito aos termos de manutenção de software

Muitos profissionais de redes, tanto os que atuam em ISPs quanto aqueles que atuam em outros segmentos, podem ser enquadrados em uma das situações destacadas a seguir:

Opera com software mais recente e em sua última revisão ou versão

O critério neste caso é manter o software sempre em sua última versão ou revisão, pois há um entendimento implícito que um software na última versão vá alcançar os objetivos vislumbrados que são:

  1. A menor exposição contra vulnerabilidades
  2. A maior estabilidade com relação a bugs,
  3. A maior disponibilidade de recursos/facilidades.

Embora seja verdade em muitos casos, me atrevo até mesmo a citar "a maioria dos casos", isto, no entanto, não está integralmente correto. E, por não estar integralmente correto, não devemos correr este risco. Não há quaisquer garantias que um software na sua última versão vá atender aos objetivos 1, 2 ou 3 supracitados. Isto será explicado ao longo deste artigo.

Opera com software que acompanhou o equipamento durante a sua aquisição

O critério neste caso aqui foi "pagar para ver", literalmente. O analista comissiona a plataforma ou o equipamento em um ambiente de testes onde pôde validar o funcionamento dos recursos e o comportamento geral do equipamento. Não havendo problemas identificados neste estágio, o equipamento é posicionado para o ambiente de produção e tende a permanecer desta forma até que um problema aconteça ou quando um recurso for desejado posteriormente mas que não está disponível na versão vigente em operação no equipamento.

Opera com software que foi selecionado diretamente para o estágio de implantação do equipamento

O profissional em alguns casos é mais criterioso aqui, pois busca selecionar com mais cuidado o software que deverá funcionar no equipamento no ambiente de produção. Os critérios de seleção de software podem ser "rasos" ou mais aprofundados, dependendo da capacidade, conhecimento ou pressa do profissional. Todavia, o problema aqui é a ausência de controles de revisão e manutenção de software, mesmo em ambientes onde não há o surgimento de quaisquer incidentes, problemas ou indisponibilidades. E é justamente isto que pode comprometer a integridade da infraestrutura da empresa em muitas situações.

Opera com software em alinhamento com um regime de política de adoção e manutenção

A situação realmente bem menos frequente, infelizmente. Poucas empresas de fato possuem processos claros para a revisão e seleção de software, tanto para novos dispositivos/equipamentos quanto para aqueles que estiverem operando em produção.

Será o foco deste artigo exatamente disseminar esta cultura, a qual considero indiscutivelmente mais segura e apropriada para a sustentação de níveis elevados de disponibilidade, estabilidade, confiabilidade e integridade do ambiente de redes, assim como do parque tecnológico como um todo.

Quais são as diferenças entre Update e Upgrade de software

Parecem ser a mesma coisa, mas as diferenças não são tão sutis assim. Compreendamos estas diferenças.

Update de software

Um update tem como proposta primária efetuar correções na arquitetura de software embarcada no equipamento. Estas correções podem ser o saneamento de bugs de determinados recursos que podem comprometer a disponibilidade parcial ou total da infraestrutura, dependendo de como o projeto técnico tiver sido construído, e de quais tecnologias tiverem sido embarcadas neste projeto para maximizar a sua disponibilidade e/ou reduzir impactos, assim como os aspectos de redundância física, lógica e de resiliência. Ou seja, o foco aqui é fornecer o "patching" necessário para corrigir um defeito nível software - na maioria dos casos - ou até mesmo as instruções lógicas executadas por silício especializado (um CPLD, FPGA ou ASIC da nova geração de reprogramáveis).

Outro objetivo dos updates é fornecer as correções devidas para "tapar buracos" de segurança identificadas no software. Ou seja, quando vulnerabilidades são identificadas pelo fabricante em seu ambiente de engenharia, P&D e/ou QA, ou quando componentes de código aberto embarcados no software do equipamento (ex: OpenSSL e muitos outros) são identificados como vulneráveis pela indústria no geral e, posteriormente, documentados em bases púbicas de vulnerabilidades, forçando o fabricante a incorporar as correções devidas ou necessárias. Ou ainda quando um componente de natureza proprietária do fabricante possui alguma vulnerabilidade que foi encontrada ou internamente ou numa ação de terceiros que promoveu a sua publicação em uma base de vulnerabilidades de domínio público.

Concluindo: updates normalmente atendem as questões de correção de bugs (disponibilidade por conta do mal funcionamento de protocolos ou serviços) ou especificamente para lidar com questão de vulnerabilidades, ou ainda as duas coisas juntas e na mesma oportunidade.

Em alguns casos, algo que não aprecio nem um pouco, o update incorpora um recurso novo, tal como um novo serviço, protocolo, funcionalidade ou capacidade.

Upgrade de software

O foco do upgrade de software está bem mais associado a introdução de novos recursos e funcionalidades. Se o upgrade for realizado sobre a mesma classe de software, o fabricante tende a portar toda a estabilidade e correções dos updates relacionados com a versão antecessora, ou seja, preservando as características de disponibilidade, integridade e segurança, etc., para esta nova versão. A diferença aqui é que o time de P&D e Engenharia do fabricante passa a introduzir novos recursos, facilidades e capacidades para novo software.

Em outros casos, quando o upgrade muda radicalmente a arquitetura do software e toda a sua abordagem, o trabalho do fabricante é bem mais complexo neste sentido. Se você pedir a minha opinião aqui sobre "devo usar um software na nova versão", eu diria que (ainda) não. Aguarde. Mesmo sendo um software cuja versão seja baseada nos mesmos pilares da versão anterior, e, principalmente, quando tratando-se de um software com alicerces completamente modificados. Eu, neste caso, aguardaria. Talvez exceto se alguma tecnologia indispensável para o meu projeto técnico estivesse disponível somente nesta nova versão, algo que já ocorreu algumas vezes comigo.

Uma pausa para explicar a dinâmica das linhas de desenvolvimento de software dos fabricantes

Os "vendors" desenvolvem e disponibilizam as suas arquiteturas de software com foco nos seguintes resultados:

  • Desenvolvimento do conceito de solução como um todo

As divisões comerciais e estratégicas do fabricante tratam dos temas relacionados a Pesquisa & Desenvolvimento, cenário de competitividade do mercado, transições de mercado, necessidades e demandas de clientes "premium", demandas naturais do mercado e dos demais usuários, convergência de tendências tecnológicas, planos de derivação de outcomes em função de desafios de negócios, alinhamento de outcomes com foco no contexto de negócios de seus clientes, Critical Success Factors (CSFs), Key Performance Indicators (KPI), e muitos fundamentos associados aos princípios de adoção tecnológica para necessidades identificadas nos negócios das empresas.

Aqui são exercitados os conceitos de "product roadmapping" e por uma infinidade de ferramentas, frameworks e modelos, incluindo 3 Horizon Model, Product Canvas, Technology Trend Capitalization, Kano Model, Market/Technology Alignment e muitos outros. Enfim, vou parar por aqui.

O esboço de toda a arquitetura de software é iniciado logo após o projeto de conceito de solução. Isto é o que ditará a arquitetura combinada de hardware + software daquele fabricante, a missão e/ou classe do equipamento, suas tecnologias, recursos, funcionalidades (protocolos, serviços, etc.), capacidades, características de performance, disponibilidade, resiliência e todo o resto.

  • Alinhamento tecnológico entre a arquitetura do hardware e o próprio software

Os equipamentos embarcam uma diversidade de componentes, alguns de classe mais "genérica" e outros de classe mais "especializada" e/ou "específica". Muitos destes componentes são projetados para controlar aspectos computacionais tais como o plano de controle e o plano de serviços, enquanto, para o plano de dados, arquiteturas de silício de mercado ou de silício customizado, ou ainda ambos simultaneamente, são empregados para o o chamado pipeline de processamento de pacotes.

Os times do fabricante procuram "costurar" um projeto de software que permita maximizar o potencial e as capacidades destes componentes embarcados no equipamento. Em outras palavras, times de desenvolvimento e de engenharia de software trabalham nas especificações funcionais de software, especificações de projeto de software, planos de testes de unidades, planos de integração de unidades, além de toda a área e testes de desenvolvimento tais como master test plans, functional test plans, automação, regressão, commit/FCS, roadmap e etc.

FCS de uma solução de hardware e software (Fonte: Cisco)

Agora que você compreende um pouco melhor o conceito de solução do fabricante e envolvendo o seu software, ficará mais suave orientar as melhores práticas quanto aos processos de manutenção de software que você deve considerar para o seu provedor.

Antes mesmo de prosseguirmos com o tema "updates" ou "upgrades": você sabe escolher o software ideal para o seu equipamento?

Talvez a coisa mais importante que você deva saber e fazer, e observando isto para toda a sua infraestrutura, no que diz respeito à escolha do software para os seus equipamentos.

Tipifique a missão do seu equipamento

Em conformidade com o seu projeto técnico, caracterize a classe da solução envolvida (hardware e software). Isto norteará algumas coisas importantes tais como "se você está usando a ferramenta certa para o trabalho certo".

Derive os indicadores-chave de performance desejados da solução

Em matrimônio com o plano de negócios e com o projeto técnico, e com ênfase nas áreas de Disponibilidade, Resiliência, Escalabilidade, Desempenho, Gerenciamento, Segurança e afins.

Categorize as funcionalidades a serem utilizadas no seu equipamento e conforme o seu projeto técnico

A categorização de funcionalidades e recursos a serem considerados para as configurações do seu equipamento é importante e por diversas razões:

  • Ficará mais fácil para você derivar os KPIs comentados acima.
  • Ficará mais fácil para você selecionar os recursos de software que melhor exploram o potencial do hardware.
  • Ficará mais fácil para você selecionar os recursos de software mais aderentes no que diz respeito às áreas funcionais do seu projeto técnico.
  • Ficará mais fácil você fidelizar e tangibilizar o seu projeto técnico, pois os componentes e recursos terão um propósito documentado, e cada um destes terá um roteiro de adoção e manutenção, além de uma métrica auditável.
  • Ficará mais fácil você separar o que é um recurso primário do que é um recurso secundário. Em outras palavras, você saberá identificar os recursos indispensáveis e vitais, assim como aqueles que, apesar de poderem agregar algum valor para o seu projeto, não são indispensáveis para a viabilidade da solução fim-a-fim sobre a infraestrutura.
    • De todos o recursos e facilidades disponíveis no software, quais de fato você precisa e, portanto, deverá utilizar nas suas configurações?
  • Ficará bem mais fácil para você ultimamente selecionar o software a ser considerado para o equipamento.
  • Ficará mais tranquilo para você validar os modelos de licenciamento necessários e disponíveis para aquele software e seus recursos embarcados que você utilizará.
  • Ficará muito mais fácil para você investigar a linha de desenvolvimento de software do fabricante, em particular nas seguintes áreas:
    • Roadmap e inovação tecnológica: para qual direção o fabricante está indo para aquela classe de produto e quais recursos (ainda não disponíveis) estão sendo vislumbrados nos cenários de curto/médio/longo prazos?
    • Bug scrubbing: compreender se para o software selecionado há recursos atualmente apresentando...
      • Defeitos ("bugs") ainda não saneados.
        • O que por sua vez permite tomar uma decisão de adoção do software (caso o recurso não afete o seu projeto porque não é algo necessário/exigido) ou de não seguir adiante com aquele software (caso você necessite do recurso de fato). Ou ainda optar por correr o risco ou então implementar algum workaround eventualmente fornecido pelo fabricante para você não "acertar" aquele bug.
      • Vulnerabilidades: identificar se os recursos que serão adotados no projeto e em suas configurações possuem vulnerabilidades existentes na versão pretendida. Caso afirmativo, se estas vulnerabilidades podem ser saneadas por meios de boas práticas (de configuração), ou se há atualizações (patches, "updates") disponíveis capazes de sanear estas vulnerabilidades e, consequentemente, viabilizar a redução ou eliminação do risco.
  • Permitirá você padronizar as configurações destes recursos sobre os equipamentos da rede, cada qual posicionado em sua respectiva camada de função (Acesso, Agregação, Core, Borda, etc.).
O processo de seleção de software para um equipamento de rede

Boas práticas para a seleção do software para o seu equipamento

Como citado no vídeo BPF: caracterização das funcionalidades e recursos para projetos de redes no ISP (off-topic aqui), a última coisa que devemos fazer em um projeto é escolher a "ferramenta". Ou, neste caso, o "equipamento".

Portanto assumo aqui que você já tenha escolhido o tipo de equipamento e quais recursos de software+hardware e demais capacidades você precisará para o seu projeto. Ok?

Após ou durante a conclusão do estágio "Antes mesmo de prosseguir com 'updates' ou 'upgrades': você sabe escolher o software ideal para o seu equipamento?" supracitado, o que você pode e deve fazer a respeito:

Utilize as ferramentas de autosserviço do fabricante

Alguns fabricantes disponibilizam ferramentas para permitir a seleção mais criteriosa e segura de software. Alguns exemplos aqui:

OBS: consulte o seu fabricante sobre a disponibilidade de ferramentas similares. Caso encontre e caso deseje incorporá-las ao artigo, entre em contato com o autor deste artigo e/ou o comitê de programa do BPF.

Utilize as documentações disponibilizadas pelo fabricante

Alguns papers que acho extremamente úteis para estes propósitos:

Release Notes

São documentos que destacam características muito importante para a escolha de um software. Dentre os quais posso destacar as seguintes:

  • Bugs corrigidos com relação ao release anterior
  • Bugs identificados mas ainda não corrigidos nesta release
  • Vulnerabilidades saneadas/corrigidas
  • Vulnerabilidades ainda não corrigidas (em muitos casos, a maioria mesmo, isto não é divulgado para proteger os próprios clientes/usuários)
  • Novos recursos de hardware introduzidos nesta versão (as vezes um silício pode receber um novo firmware capaz de executar ou viabilizar um novo recurso, ou um novo módulo foi lançado para aquele equipamento e que exige esta versão como release mínimo de software)
  • Eventuais recursos de software que foram descontinuados, seja apenas uma transição de sintaxe (legacy CLI vs. new CLI) ou por qualquer outro motivo.
  • Eventual descontinuação de módulos de hardware legados (ex: a nova versão deixa de suportar uma determinada geração/série de line cards)
  • Questões relacionadas a interoperabilidade de recursos no mesmo equipamento ou entre equipamentos do mesmo vendor ou de outro vendors na planta
  • Pré-requisitos de instalação desta release.
    • Cuidados a serem observados.
    • O que pode dar errado e o que deve ser evitado.
    • Se o update ou upgrade pode ser direto, ou se update/upgrades intermediários devem ser executados primeiro.
    • Requerimentos mínimos de firmware de módulos de hardware.
    • Etc.
  • Dentre outras instruções e recomendações muito importantes.

Primeiro conselho que forneço aqui no aspecto mais prático da palavra: N Ã O A T U A L I Z E O S E U S O F T W A R E S E M A N T E S C O N S U L T A R O R E L E A S E N O T E S !

Guias de Configuração de Software e Guias de Referências de Comandos

São essencialmente os manuais propriamente ditos. Uma coisa é o equipamento suportar um determinado recurso, outra é um mecanismo indispensável para a sua rede estar disponível para este recurso. Um exemplo aqui:

  • Você precisa suportar o MPLS. Aí você leu no datasheet que o equipamento suporta MPLS. Mas, na hora de você implementar (e após ter comprado a solução!), você descobre que somente labels estáticos são suportados (ou seja, sem suporte ao protocolo LDP). E agora?
    • Isto é o caso dos switches Cisco Nexus 3064PQ que muitos provedores compraram "refurbished" (usados) ainda por cima. O switch possui missão para Top of Rack (ToR) para conectividade de servidores em Data Centers! Não suporta o MPLS como estes ISPs gostariam, mas, bastava uma consulta nos manuais para eles saberem disto!
  • Você planeja migrar as tecnologias L2VPN tradicionais para o EVPN. Um consultor indica uma determinada linha de produto (hardware+software). Você faz o investimento para depois descobrir que aquela solução faz EVPN-VPWS (point-to-point) apenas, e não o EVPN All-Active Multi-Homing que você precisa. E agora?
  • Você precisa maximizar o uso dos links internos do seu backbone para fomentar melhor distribuição do tráfego L2VPN sobre regime ECMP. Você confirmou que o equipamento e/ou software suporta a L2VPN, mas esqueceu de validar se o mecanismo FAT Pseudowire é suportado. E acaba descobrindo que não é. Ou a necessidade pelo suporte do Entropy Label, enfim.
  • Eu poderia passar horas aqui descrevendo estes tipos de situações...

Ou seja, os manuais servem para muito mais do que apenas conhecer como se configura alguma coisa no ponto de vista mais prático de adoção do recurso. Os manuais ajudam muito na hora de você compreender se aquele recurso é suportado nos moldes vislumbrados pelo seu projeto técnico!

Cenários Validados dos Fabricantes

Alguns fabricantes disponibilizam conceitos de projetos "validados" - quase que homologados - para nortear os profissionais quanto ao funcionamento das soluções envolvendo os protocolos e recursos vislumbrados por eles em seus projetos técnicos. Muitos destes documentos mencionam as versões de software utilizadas na validação destes cenários. Dois exemplos de fabricantes que disponibilizam estes materiais:

OBS: consulte o seu fabricante sobre a disponibilidade de ferramentas similares. Caso encontre e caso deseje incorporá-las ao artigo, entre em contato com o autor deste artigo e/ou o comitê de programa do BPF.

Consulte os boletins de segurança para a identificação de vulnerabilidades no seu software pretendido

Alguns fabricantes são bem transparentes quanto a isto, e colocam à disposição de seus clientes diversos links contendo informações relacionadas aos problemas de segurança identificados e como estas vulnerabilidades podem ser evitadas ou saneadas. Como estamos falando de "seleção de software", você pode focar apenas nas tecnologias que pretende embarcar no seu equipamento/projeto. Alguns exemplos aqui:

E, não menos importante, consulte a própria base de vulnerabilidades - em especial a:

Considere a contratação de serviços de um parceiro especializado e/ou do fabricante

Entenda uma coisa e de uma vez por todas: tecnologia é coisa séria, especialmente em um ambiente de ISP. Por que? Porque a tecnologia é a missão primária do negócio! É onde o ISP terá a sua receita.

Sendo assim, não seja negligente desnecessariamente. Ter um time bom e bem qualificado tecnicamente para operar uma rede não significa em muitos casos que estes colaboradores estejam aptos para condução de certas atividades. A engenharia de redes pode e frequentemente exige conhecimentos mais aprofundados em muitas searas que inclusive pode desviar o foco dos seus colaboradores e provocar impactos negativos na operação do cotidiano. Procure compreender se não seria melhor contar com uma consultoria especializada junto a um parceiro ou ao próprio fabricante para que eles contribuam para o projeto, e isto inclui nas questões de seleção de hardware e software.

Todo este processo ou roteiro pode ser visualizado da seguinte forma:

Roteiro para a correta seleção de software

Extra: sobre as diferentes características das arquiteturas de software: isto pode influenciar não apenas o software que você escolhe, mas o tipo de solução!

Outro quase off-topic aqui. Este tema não será aprofundado neste artigo, pois foge substancialmente do foco do artigo. Apenas para reforçar aqui que há algumas abordagens dos fabricantes com relação às suas arquiteturas de software.

Alguns sistemas operacionais de roteadores, switches e outros, para simplificar aqui, possuem abordagem estritamente monolítica. O "problema" aqui está na baixa imunidade e resiliência do sistema como um todo em lidar com eventuais panes de um ou mais de seus processos de software. Por exemplo, imagine um processo menos importante (ex: syslogd) corrompendo dados de uma área de memória com endereços que não estavam alocados para este processo, os quais, na verdade, estavam sendo usados por outro processo... digamos o BGP. Isto seria desastroso e, pra ser honesto aqui, situações como estas não são raras nestes tipos de arquiteturas. Há pouca proteção nas regiões de memória, os mecanismos de IPC são mais próximos de serem meras trocas de mensagens, há muito bloqueio na comunicação entre os processos, os processos tem acesso diretamente à memória física em muitos casos, e um "crash" de processo só pode ser resolvido... com a reinicialização completa do equipamento!

Outras arquiteturas de software de elementos de rede já possuem uma abordagem modularizada, e isto significa que boa parte dos processos envolvendo protocolos e serviços são modulares e com ótima proteção entre os processos, pois tendem a possuir as suas próprias alocações de áreas de memória protegida e sem acesso direto à memória "física", apresentam algum mecanismo de prioridade de scheduling, o emprego de IPCs bem sofisticados, dentre outras evoluções e sofisticações. E isto significa que problemas com um destes processos podem ser saneados com a reinicialização do processo problemático apenas (tanto manualmente quanto automaticamente, em alguns fabricantes). Mas nem tudo é perfeito e alguns destes sistemas ainda possuem muita dependência nos componentes mais "low-level" de infraestrutura, tais como kernel, drivers e pilhas de protocolos e afins, os quais não podem ser reinicializados.

Outras arquiteturas são hiper-modularizadas, onde quase tudo é "reinicializável" e inclusive em regime de "self-healing"!

E o que falar da nova geração de arquiteturas de software? Vão além: fornecem abstração completa entre o hardware e o software! Isto significa que o sistema operacional não é mais um sistema operacional, e sim um "container" (ex: LXC e similares) onde tudo aquilo que você configura em termos de serviços e protocolos é mantido por processos multithread bem modularizados, e tudo isto rodando sobre uma camada de abstração entre software e hardware onde não há uma interação direta entre o que você configura na sua rede/equipamento e o hardware onde o recurso está rodando no topo! Isto abre novas portas para soluções bastante confiáveis e flexíveis; um mar de novas possibilidades. Algumas plataformas permitem inclusive você hospedar em paralelo soluções de terceiros no equipamento!

Para concluir aqui, alguns sistemas operacionais embarcam serviços bem interessantes para a maximização da disponibilidade da rede quando lidando com as questões de update ou upgrade de software. Por exemplo, possibilitar manobras de atualização de software com o equipamento em serviço com zero ou mínimo impacto sobre o tráfego, no que chamamos de In-Service Software Upgrade (ISSU). Em combinação com outras tecnologias e recursos tais como Nonstop Routing (NSR), Nonstop Forwarding (NSF), Stateful Switchover (SSO), checkpointing, BFD, verificação e pre-deploy, commit e rollback de instalação de software, etc., o ISSU permite manobras mais confiáveis durante as janelas de manutenção para atualizações de software. Mas nem tudo é perfeito em todos o casos ou situações, portanto convém muito checar os release notes correspondentes durante estas manobras, pois podem haver algumas restrições.

Tá.. mas o que isto tem a ver com este artigo? (caso você esteja perguntando isto). Eu apenas acho que saber disto pode ser útil para você escolher melhor a arquitetura da sua solução, e isto inclui capacidades e recursos diferenciados disponíveis no software, você não acha?

A propósito, estude ou informe-se sobre os sistemas operacionais Cisco IOS XR, Cisco IOS XE, Juniper JUNOS, e Datacom dmOS, ou na ordem que que você preferir descreve-los, pois estes seguem a filosofia modularizada discutida acima, cada qual com as suas particularidades e diferenciais.

Talvez isto vire um tema para um próximo artigo aqui no BPF.

Quando você deve proceder com a atualização do software de um equipamento?

Agora que você compreende melhor os meus ensaios sobre como devemos escolher um software para os nossos equipamentos, foquemos em algumas recomendações práticas aqui envolvendo updates e upgrades.

Com o artigo chegando ao final, promovo este entendimento de forma bem curta e objetiva:

1) Se o fabricante possuir linhas de desenvolvimento de software dedicadas para "correção de defeitos" e "introdução de recursos", como regra geral faça sempre o update (correção apenas), pois, nestes casos, sabemos que novos recursos não foram introduzidos no software, apenas correções de bugs, e, portanto, o risco de você contrair um problema é muito mais baixo. Neste caso, estamos considerando aqui um UPDATE mesmo.

2) Para UPGRADES, de acordo com as recursos ("features") que você usar, como estes recursos são ativados, e como devem interagir com outros recursos no mesmo equipamento ou com outros equipamentos que participam da solução na rede, você deverá fazer uma análise de probabilidade de acertar ("hit") o bug o qual planeja-se evitar, para, em seguida, optar por fazer o upgrade ou não. Idealmente, você faz o chamado bug scrubbing de acordo com as facilidades de seu projeto técnico e procura identificar se há bugs para cada um dos recursos que você usa, como estes bugs são (indesejavelmente) "ativados", e, de acordo com estas consultas, quais são as probabilidades e riscos de você "acertar" o bug. Se esta análise qualitativa de riscos apresentar um score médio para cima, recomenda-se planejar um upgrade em janela de intervenção apropriada (solicitação de GMUD, plano e comunicação com clientes, roteiro de testes e validação, e plano de rollback), e fazer todo o acompanhamento do caso.

Isto chama-se UPGRADE PREVENTIVO. Isto porque você tomou a decisão de fazer o upgrade como ação preventiva, já que o bug ou vulnerabilidade não estava afetando a sua rede.

3) Se você estiver sendo afetado por um problema e identificou um bug que qualifica o caso, seja por métodos próprios ou com auxílio do suporte do fabricante, você deverá usar o software correspondente para proceder com a atualização, e fazendo isto por update ou por upgrade (caso não haja um update disponível para a mesma linha de desenvolvimento). Convém obviamente fazer uma análise de bug scrubbing e de vulnerabilidades, especialmente se o tempo assim o permitir.

Isto chama-se UPGRADE CORRETIVO. Isto porque a ação de atualização do software foi reativa, e não preventiva.

Recomendações finais quanto ao software que você utilizará para o seu update ou upgrade

A linha de desenvolvimento e a engenharia de software de cada fabricante é única. Alguns fabricantes atuam de forma bem transparente e informam aos seus clientes o grau de maturidade do software com relação ao "termômetro" da companhia, em particular no que diz respeito aos acionamentos de clientes para os times de suporte (ex: TAC, JTAC, etc..), feedback dos desenvolvedores da companhia, dentre outras métricas.

Sintetizando aqui, software novo e que introduz recursos novos é menos "maduro" do que software que introduz apenas correções. É importante você saber disso na hora de escolher um software para um equipamento crítico da sua infraestrutura, pois você não desejará ser vítima de um problema novo, um bug novo, etc. Procure filtrar as versões que apresentam algum selo de maturidade do fabricante, ou converse com o seu fabricante ou o seu integrador para que você tenha maior êxito neste trabalho. Como regra geral, procure optar, na medida do possível, por software com declaração de estabilidade do fabricante para os equipamentos mais críticos para o seu negócio.

Para finalizar, nem todos os fabricantes recomendam uma versão específica de software sob demanda quando, por exemplo, você estiver abrindo um chamado no centro de serviços e suporte para a correção de um bug ou para tratar de algum problema, exceto se isto for um serviço agregado ao contrato de suporte. O máximo que o técnico do fabricante fará por você é indicar um software que corrigirá aquele bug em particular. Por mais absurdo que isto possa parecer, há um motivo: a recomendação de software obrigaria o fabricante a estudar todo o seu projeto técnico, quais tecnologias estão sendo utilizadas, como estão configuradas, o esmiuçamento de cada part number/módulo/equipamento da sua rede, como os recursos devem interoperar, etc. Nenhum fabricante desejará ser responsabilizado por recomendar um software "às escuras" e, lá na frente, quando você tiver um problema na rede, você mesmo acusar "mas foi o vendor que mandou usar esse software aqui!".

Ou você segue as dicas deste artigo, ou então contrata serviços adicionais do fabricante para este propósito. Tecnologia é coisa séria. Trate a sua empresa com cuidado e atenção!

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

Autor: Leonardo Furtado

Disponível em “https://wiki.brasilpeeringforum.org/index.php?title=Boas_Praticas_para_Politicas_de_Manutencao_de_Software_de_Ativos_de_Rede&oldid=2374”