Este artigo é o primeiro de uma série de artigos intitulada "Como controlar a infraestrutura de rede". Você pode encontrar o conteúdo de todos os artigos da série e os links. .
É bem possível que haja um número suficiente de empresas onde uma rede simples em uma hora ou mesmo em um dia não seja crítica. Infelizmente ou felizmente, eu não tive a oportunidade de trabalhar em tais lugares. Mas, claro, as redes são variadas, as exigências são diferentes, e as abordagens variam, ainda assim, de uma forma ou de outra, a lista abaixo será, em muitos casos, um verdadeiro "must-do".
Então, as condições iniciais.
Você está em um novo emprego ou recebeu uma promoção ou decidiu olhar para suas responsabilidades sob uma nova perspectiva. A rede da empresa é de sua responsabilidade. Para você, isso é, em muitos aspectos, um desafio e algo novo, o que um pouco justifica o tom mentor desta artigo :). Mas espero que o artigo também possa ser útil para qualquer engenheiro de rede.
Seu primeiro objetivo estratégico é aprender a resistir à entropia e manter o nível de serviço fornecido.
Muitas das tarefas descritas abaixo podem ser resolvidas por diferentes meios. Eu intencionalmente não abordo o tema da implementação técnica, pois muitas vezes não importa como você resolveu uma tarefa específica, mas sim como você a utiliza e se a utiliza de fato. Por exemplo, não adianta nada ter um sistema de monitoramento profissionalmente estruturado se você não olha para ele e não reage aos alertas.
Hardware
Primeiro, você precisa entender onde estão os maiores riscos.
Novamente, isso pode variar. Posso supor que em algum lugar isso envolverá questões de segurança, enquanto em outro lugar pode estar relacionado à continuidade do serviço, ou talvez algo mais. Por que não?
Suponhamos, para fins de clareza, que será realmente a continuidade do serviço (como foi em todas as empresas em que trabalhei).
Então, você deve começar pelo equipamento. Aqui está uma lista de tópicos a serem considerados:
- classificação do equipamento por grau de criticidade
- redundância do equipamento crítico
- suporte, licenças
Você deve considerar as possíveis falhas, especialmente com o equipamento que está no topo da sua classificação de criticidade. Frequentemente, subestiman-se as chances de problemas duplos, caso contrário, sua solução e suporte podem se tornar injustificadamente caros, mas no caso de elementos realmente críticos da rede, cuja falha pode impactar significativamente o negócio, você deve pensar nisso também.
Exemplo
Suponha que estamos falando sobre o switch principal no data center.
Como concordamos que a continuidade do serviço é o critério mais importante, é razoável garantir a redundância ‘ativa’ (redundância) desse equipamento. Mas isso não é tudo. Você também deve decidir quanto tempo, no caso da falha do primeiro switch, é aceitável ficar apenas com um switch restante, já que existe o risco de que ele também falhe.
Importante! Você não deve resolver essa questão sozinho. Você deve descrever os riscos, as soluções possíveis e os custos à sua diretoria ou à administração da empresa. As decisões devem ser tomadas por eles.
Assim, se foi decidido que, com uma pequena probabilidade de falha dupla, operar por 4 horas com um switch é, em princípio, aceitável, você pode simplesmente escolher o suporte adequado (pelo qual o equipamento será trocado em até 4 horas).
Mas existe o risco de que não entreguem. Infelizmente, já estivemos em tal situação. Em vez de quatro horas, o equipamento levou uma semana!!!
Portanto, esse risco também precisa ser discutido e, talvez, seja mais adequado para você comprar um switch extra (o terceiro) e mantê-lo em reserva (reservas ‘ frias’) ou usá-lo para fins de laboratório.
Importante! Crie uma tabela de todos os suportes que você possui, com as datas de expiração, e adicione-as ao calendário, para que, pelo menos um mês antes, você receba um aviso de que deve começar a se preocupar com a renovação do suporte.
Você não será perdoado se esquecer de renovar o suporte e, no dia seguinte ao término, seu equipamento quebrar.
Trabalhos de emergência
Independentemente do que acontecer em sua rede, idealmente, você deve garantir o acesso ao seu equipamento de rede.
Importante! Você deve ter acesso console a todo o equipamento e esse acesso não deve depender da funcionalidade da rede de transmissão de dados.
Além disso, você deve antecipar possíveis cenários negativos e documentar as ações necessárias. A disponibilidade deste documento também é crítica, portanto, deve ser não apenas disponibilizado em um recurso compartilhado do departamento, mas também salvo localmente nos computadores dos engenheiros.
Devem obrigatoriamente estar lá
- informações necessárias para abrir um chamado de suporte com o vendedor ou integrador
- informações sobre como acessar qualquer equipamento (console, gerenciamento)
Além disso, pode conter qualquer outra informação útil, como uma descrição do procedimento de upgrade de diversos equipamentos e comandos diagnósticos úteis.
Parceiros
Agora você precisa avaliar os riscos associados aos parceiros. Normalmente, isso inclui
- provedores de internet e pontos de troca de tráfego (IX)
- provedores de canal de comunicação
Quais perguntas você deve se fazer? Assim como no caso do equipamento, você precisa considerar diferentes cenários de falha. Por exemplo, para provedores de internet, isso pode ser algo como:
- o que acontecerá se o provedor de internet X deixar de fornecer o serviço por algum motivo?
- sua largura de banda com os outros provedores será suficiente?
- qual será a qualidade da conectividade?
- quão independentes são seus provedores de internet e uma falha grave em um deles causará problemas com os outros?
- quantas entradas ópticas você tem no seu data center?
- o que ocorrerá se uma das entradas for completamente destruída?
Sobre as entradas, em minha experiência em duas empresas diferentes, em duas situações diferentes, , o que garante: um escavador destruiu poços e por um milagre nossa fibra óptica não foi danificada. Não é um caso tão raro.
E, é claro, você não deve apenas fazer essas perguntas, mas, novamente, com o apoio da gerência, garantir que haja uma solução aceitável em qualquer situação.
Backup
O próximo prioridade pode ser o backup das configurações do equipamento. De qualquer forma, este é um ponto muito importante. Não vou listar os casos em que você pode perder a configuração, é melhor fazer backup regularmente e não se preocupar com isso. Além disso, backups regulares podem ser muito úteis ao controlar mudanças.
Importante! Faça backup diariamente. Não é um grande volume de dados, para economizar nisso. De manhã, o engenheiro de plantão (ou você) deve receber um relatório do sistema, que indique claramente se o backup foi bem-sucedido ou não, e caso o backup não tenha sido bem-sucedido, o problema deve ser resolvido ou um ticket deve ser criado (veja os processos do departamento de rede).
Versões de software
A questão de atualizar o software do equipamento não é tão simples. Por um lado, versões antigas possuem bugs e vulnerabilidades conhecidas, mas por outro lado, um novo software não é sempre um procedimento de atualização indolor e pode trazer novos bugs e vulnerabilidades.
Aqui, é preciso encontrar a opção mais otimizada. Algumas recomendações evidentes
- instale apenas versões estáveis
- ainda assim, não é aconselhável usar versões de software muito antigas
- elabore uma tabela com informações sobre qual software está instalado em cada equipamento
- leia periodicamente relatórios sobre vulnerabilidades e bugs em versões de software, e em caso de problemas críticos, considere a atualização
Nesta fase, tendo acesso ao console do equipamento, informações sobre suporte e uma descrição do processo de atualização, você está basicamente preparado para esse passo. O ideal é ter equipamentos laboratoriais onde você possa testar todo o procedimento, mas, infelizmente, isso não é comum.
Em caso de equipamentos críticos, você pode entrar em contato com o suporte do fornecedor solicitando assistência na atualização.
Sistema de tickets
Agora você pode olhar ao redor. Você precisa estabelecer processos de interação com outros departamentos e dentro do próprio departamento.
Pode não ser obrigatório (por exemplo, se sua empresa for pequena), mas eu recomendaria fortemente organizar o trabalho de forma que todas as tarefas externas e internas passem pelo sistema de tickets.
O sistema de tickets é essencialmente sua interface para comunicações internas e externas, e você deve descrever essa interface com um grau suficiente de detalhamento.
Vamos usar como exemplo uma tarefa importante e frequentemente encontrada sobre a abertura de acesso. Vou descrever um algoritmo que funcionou muito bem em uma das empresas.
Exemplo
Começamos pelo fato de que, muitas vezes, os clientes formulam seu desejo em uma linguagem incompreensível para o engenheiro de rede, ou seja, na linguagem do aplicativo, por exemplo, “me abra o acesso ao 1C”.
Portanto, nunca aceitamos solicitações diretamente de tais usuários.
E essa foi a primeira exigência
- as solicitações para fornecimento de acessos devem vir dos departamentos técnicos (no nosso caso, eram engenheiros de unix, windows e helpdesk)
A segunda exigência é que
- esse acesso deve ser protocolado (pelo departamento técnico que recebeu a solicitação) e como solicitação devemos receber um link para esse acesso protocolado
A forma dessa solicitação deve ser clara para nós, ou seja,
- a solicitação deve conter informações sobre de qual e em qual sub-rede o acesso deve ser aberto, bem como sobre o protocolo e (no caso de tcp/udp) as portas
Deve também ser indicado
- uma descrição para que esse acesso está sendo aberto
- temporário ou permanente (se temporário, até que data)
E um ponto muito importante são as aprovações
- do chefe do departamento que iniciou o acesso (por exemplo, o departamento financeiro)
- do chefe do departamento técnico, de onde essa solicitação veio para o departamento de rede (por exemplo, helpdesk)
Neste caso, o "proprietário" desse acesso é considerado o chefe do departamento que iniciou o acesso (a contabilidade no nosso exemplo), e ele é responsável por manter a página com os acessos protocolados desse departamento atualizada.
Registro
Isso é algo em que se pode se perder. Mas se você deseja implementar uma abordagem proativa, precisará aprender a lidar com esse fluxo de dados.
Aqui estão algumas recomendações práticas:
- os logs devem ser revisados diariamente
- em caso de revisão planejada (e não durante situações emergenciais), você pode se limitar aos níveis de criticidade (severity) 0, 1, 2 e adicionar padrões selecionados de outros níveis se achar necessário
- escreva um script que analise os logs e ignore aqueles cuja padrões você adicionou à lista de ignorados
Essa abordagem permitirá, com o tempo, criar uma lista de logs que não lhe interessam e deixar apenas aqueles que você realmente considera importantes.
Isso funcionou muito bem para nós.
Monitoramento
Não é incomum que uma empresa não tenha um sistema de monitoramento. Você pode, por exemplo, depender dos logs, mas o equipamento pode simplesmente 'morrer' sem avisar nada, ou um pacote UDP do protocolo syslog pode se perder e não chegar ao destino. Em suma, o monitoramento ativo é, sem dúvida, importante e necessário.
Dois exemplos mais comuns na minha prática:
- monitoramento da carga dos canais de comunicação, links críticos (por exemplo, conexão com provedores). Permitem visualizar proativamente um potencial problema de degradação do serviço devido à perda de tráfego, evitando assim que ele ocorra.
- gráficos elaborados com base no NetFlow. Eles permitem encontrar facilmente anomalias no tráfego e são muito úteis para detectar alguns tipos simples, mas significativos, de ataques hackers.
Importante! Configure notificações SMS para os eventos mais críticos. Isso se aplica tanto ao monitoramento quanto à logação. Se você não tem uma equipe de plantão, as SMS também devem ser enviadas fora do horário de trabalho.
Planeje o processo de modo a não acordar todos os engenheiros. Para isso, tínhamos um engenheiro de plantão.
Controle de mudanças
Na minha opinião, não é necessário controlar todas as mudanças. Mas, de qualquer forma, você deve ser capaz, se necessário, de encontrar facilmente quem e por que fez determinadas alterações na rede.
Algumas dicas:
- use um sistema de tickets para descrever detalhadamente o que foi feito no âmbito desse ticket, por exemplo, copiando a configuração aplicada para o ticket
- use as possibilidades de comentários nos equipamentos de rede (por exemplo, commit comment no Juniper). Você pode registrar o número do ticket
- use o diff dos seus backups de configuração
Você pode introduzir isso como um processo, revisando diariamente todos os tickets em busca de mudanças.
Processos
Você deve formalizar e descrever os processos em sua equipe. Se você chegou a esse ponto, a sua equipe já deve estar trabalhando, pelo menos, com os seguintes processos:
Processos diários:
- trabalho com tickets
- trabalho com logs
- controle de mudanças
- lista de verificação diária
Processos anuais:
- renovação de garantias, licenças
Processos assíncronos:
- reação a diversas situações de emergência
Conclusão da primeira parte
Você percebeu que tudo isso ainda não é sobre configuração de rede, design, protocolos de rede, roteamento ou segurança... É algo em torno disso. Mas, embora possa parecer chato, são, com certeza, elementos muito importantes do funcionamento do departamento de redes.
Por enquanto, como você pode ver, não melhorou nada na sua rede. Se havia vulnerabilidades de segurança, elas permanecem; se havia um design ruim, ele ainda existe. Até que você aplique suas habilidades e conhecimentos como engenheiro de redes, nos quais provavelmente foram investidos muito tempo, esforço e, às vezes, dinheiro. Mas primeiro é necessário criar (ou fortalecer) a base antes de começar a construção.
Nas próximas partes, falaremos sobre como buscar e resolver erros, e depois aprimorar sua infraestrutura.
Claro, não é necessário fazer tudo em sequência. O tempo pode ser crítico. Faça paralelamente, se os recursos permitirem.
E uma adição importante. Comunique-se, pergunte, consulte sua equipe. Afinal, são eles que irão manter e realizar tudo isso.
Fonte: habr.com
