[GTER] Metodologia para atualização de imagens de roteadores

[Lucas Willian Bocchi]

Só complementando, acredito que no trecho final deveria ser colocado que
isto é um ciclo que deve ter prazo para ser re-iniciado. Não é só pela
questão de bugs mas também para você não manter equipamentos que não
possuam atualizações dentro da tua rede. Se você compra um equipamento que
demora anos e anos para lançar uma nova versão, tome cuidado, pois isso não
é bom sinal. Isso ajuda até mesmo na hora do comprador avaliar a qualidade
do equipamento em si, pois não é só o preço que conta, mas sim a qualidade
do quê tu bota na tua rede.

Em 28 de setembro de 2017 19:44, Shine <eshine at gmail.com> escreveu:

> O método varia de caso para caso. Em redes bem grandes o processo é muito
> mais complexo e até se paga consultorias para fazer esse trabalho.
>
> De uma forma geral, se adota um ramo (branch) adequado à aplicação, com as
> funcionalidades necessárias. Normalmente uma imagem recente, com qualidade
> de produção, estável. Nessa imagem são feitas as simulações mínimas da
> rede.
> Uma vez aprovada, se faz o "staging" da rede, um teste em ambiente de
> produção controlado.
> Com essa primeira implementação, a imagem é gradativamente adotada no
> restante da rede. E esta fica sendo a imagem padronizada. É desejável ter o
> mínimo de versões diferentes na rede, isso simplifica a operação e o
> processo de suporte (por exemplo um RMA e colocar a troca na imagem
> padronizada)
>
> Chegamos à sua situação atual. A atualização da imagem em um ambiente
> estável é geralmente motivado ou por uma implementação de uma nova
> funcionalidade ou pelo final do ciclo de vida da imagem.
> Em ambos os casos pode ser necessário revalidar a nova imagem, ou seja
> refazer todo o trabalho de certificação. Depende muito da qualidade do
> software da imagem que está sendo avaliada e da complexidade do ambiente.
> Uma terceira situação é a detecção de bugs e PSIRTs. Aqui se precisa fazer
> o processo de bug scrub para ver se o bug potencialmente pode afetar o
> ambiente de produção. Se o bug não se aplica ou se há um workaround sem
> panalidades em geral não se faz a atualização, pois pode gerar custos. No
> caso de PSIRT podem haver workarounds ou não e também precisa avaliar a
> aplicabilidade da vulnerabilidade na rede de produção, a decisão de fazer
> ou não um upgrade (ou um patching) vai sair daí.
>
> Espero que essas pequenas informações te ajudem.
>
> Em 28 de setembro de 2017 16:16, MDias <diasrnp at gmail.com> escreveu:
>
> > Pessoal, boa tarde.
> >
> > Gostaria de saber de vocês com tratam a homologação de SO para
> atualização
> > de roteadores ou switches.
> >
> > 1) Utilizam somente versões recomendadas dos fornecedores?
> >
> > 2) Utilizam versões superiores a recomendada mas em releases altos?
> >
> > 3) Homologam em algum ambiente de laboratório?
> >
> > Att,
> >
> > Marcelo Dias
> >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>