Este artigo é o primeiro de uma série de artigos intitulados "Como colocar a infraestrutura de rede sob seu controle". O conteúdo de todos os artigos da série e os links podem ser encontrados aqui .
Admito plenamente que haja um número suficiente de empresas em que uma rede simples de uma hora ou até um dia não é crítica. Infelizmente ou felizmente, não tive a oportunidade de trabalhar nesses lugares. Mas, é claro, as redes são diferentes, os requisitos são diferentes, as abordagens são diferentes e, no entanto, de uma forma ou de outra, a lista abaixo será, em muitos casos, realmente "mast-do".
Então, as condições iniciais.
Você está em um novo local de trabalho ou tem uma promoção ou decide dar uma nova olhada em suas responsabilidades. A rede da empresa é sua área de responsabilidade. Para você, esse é, em grande parte, um desafio e um novo, que justifica o tom de orientação deste 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 prestado.
Muitas das tarefas descritas abaixo podem ser resolvidas por vários meios. Eu intencionalmente não levanto o tópico da implementação técnica, como em princípio, muitas vezes não é tão importante como você resolveu um problema específico, mas como você o usa e se é realmente importante. É de pouca utilidade, por exemplo, no seu sistema de monitoramento desenvolvido profissionalmente, se você não olhar para lá e não responder a alertas.
Equipamento
Primeiro você precisa entender onde estão os maiores riscos.
Novamente, poderia ser diferente. Admito que em algum lugar, por exemplo, haverá problemas de segurança, e em algum lugar relacionado à continuidade do serviço, e em algum lugar, talvez, em outra coisa. Porque não
Suponhamos, com toda a certeza, que isso seja uma continuidade de serviço (esse foi o caso em todas as empresas em que trabalhei).
Então você precisa começar com o equipamento. Aqui está uma lista de tópicos a serem observados:
- classificação de criticidade do equipamento
- redundância de equipamentos críticos
- suporte, licenças
Você deve considerar possíveis falhas, especialmente com equipamentos no topo da sua classificação de criticidade. Geralmente, a probabilidade de problemas duplos é negligenciada; caso contrário, sua solução e suporte podem se tornar excessivamente caros, mas no caso de elementos de rede realmente críticos, cuja falha pode afetar significativamente os negócios, você deve pensar nisso.
Exemplo
Suponha que estamos falando de um switch raiz em um data center.
Como concordamos que a continuidade do serviço é o critério mais importante, é razoável fornecer uma "redundância" deste equipamento. Mas isso não é tudo. Você também deve decidir quanto tempo, no caso de uma interrupção do primeiro comutador, é aceitável que você viva com apenas um comutador restante, porque existe o risco de que ele se quebre.
Importante! Você não precisa resolver esse problema sozinho. Você deve descrever os riscos, as possíveis soluções e o valor para sua gerência ou gerência da empresa. Eles devem tomar decisões.
Portanto, se foi decidido que, dada a pequena probabilidade de uma quebra dupla, trabalhar por 4 horas em um switch é, em princípio, aceitável, então você pode apenas ter o suporte adequado (para o qual o equipamento será substituído dentro de 4 horas).
Mas existe o risco de que eles não sejam entregues. Infelizmente, uma vez que nos encontramos em tal situação. Em vez de quatro horas, o equipamento durou uma semana !!!
Portanto, esse risco também precisa ser discutido e, talvez, seja mais correto comprar outro comutador (terceiro) e mantê-lo em peças de reposição (backup a frio) ou usá-lo para fins de laboratório.
Importante! Faça uma tabela de todos os suportes que você possui com as datas de término e adicione-os ao calendário para que, pelo menos um mês depois, receba uma carta informando que você deve começar a se preocupar em estender o suporte.Você não será perdoado se esquecer de estender o suporte e, no dia seguinte ao término, seu equipamento irá falhar.
Trabalho de emergência
O que quer que aconteça na sua rede, idealmente, você deve manter o acesso ao seu equipamento de rede.
Importante! Você deve ter acesso ao console de todos os equipamentos e esse acesso não deve depender da operabilidade da rede de transmissão de dados do usuário (dados).Você também deve prever possíveis cenários negativos e documentar as ações necessárias. A disponibilidade deste documento é crítica, portanto, ele não deve ser compartilhado apenas em um recurso compartilhado pelo departamento, mas também armazenado localmente em computadores de engenheiros.
Deve haver
- informações necessárias para abrir um aplicativo em suporte a um fornecedor ou integrador
- informações sobre como chegar a qualquer equipamento (console, gerenciamento)
Obviamente, qualquer outra informação útil pode estar contida, por exemplo, uma descrição do procedimento de atualização para vários equipamentos e comandos úteis de diagnóstico.
Parceiros
Agora você precisa avaliar os riscos associados aos parceiros. Geralmente
- Provedores de serviços de Internet e pontos de troca de tráfego (IX)
- fornecedores de canais de comunicação
Que perguntas você precisa fazer a si mesmo? Como no caso de equipamentos, é necessário considerar várias opções para situações de emergência. Por exemplo, para provedores de serviços da Internet, pode ser algo como:
- O que acontecerá se o ISP X deixar de fornecer um serviço por algum motivo?
- Você tem largura de banda suficiente para outros provedores?
- quão boa será a coerência?
- Quão independentes são seus ISPs e um grave acidente em um deles causará problemas com os outros?
- Quantas entradas ópticas para o seu data center?
- O que acontece se uma das entradas for completamente destruída?
Quanto aos insumos, na minha prática em duas empresas diferentes, em dois centros de dados diferentes, a escavadeira destruiu os poços e apenas por um milagre nossas ópticas não foram afetadas. Este não é um caso tão raro.
Bem, é claro, você precisa não apenas fazer essas perguntas, mas, novamente, com o apoio da liderança, para fornecer uma solução aceitável em qualquer situação.
Backup
A próxima prioridade pode ser um backup das configurações de hardware. De qualquer forma, este é um ponto muito importante. Não vou listar os casos em que você pode perder a configuração, é melhor fazer um backup regular e não pensar nisso. Além disso, o backup regular pode ser muito útil no controle de alterações.
Importante! Faça um backup diariamente. Esta não é uma quantidade tão grande de dados para economizar nisso. De manhã, o engenheiro de serviço (ou você) deve receber um relatório do sistema que indica claramente se o backup foi bem-sucedido ou não e, no caso de um backup malsucedido, o problema deve ser resolvido ou um ticket deve ser criado (consulte os processos do departamento de rede).Versão do software
A questão de atualizar ou não o software de hardware não é tão clara. Por um lado, as versões antigas são bugs e vulnerabilidades conhecidas, mas, por outro lado, o novo software é, em primeiro lugar, nem sempre um procedimento de atualização indolor e, em segundo lugar, novos bugs e vulnerabilidades.
Aqui você precisa encontrar a melhor opção. Algumas recomendações óbvias
- apenas versões estáveis
- Ainda assim, você não deve viver com versões muito antigas do software
- faça um sinal com informações onde qualquer software é
- leia periodicamente relatórios sobre vulnerabilidades e bugs nas versões de software e, no caso de problemas críticos, vale a pena pensar em uma atualização
Nesse estágio, tendo acesso ao equipamento, informações de suporte e uma descrição do procedimento de atualização, você está, em princípio, pronto para esta etapa. A opção ideal é quando você possui equipamento de laboratório, onde pode verificar todo o procedimento, mas, infelizmente, isso não acontece com frequência.
No caso de equipamento crítico, você pode entrar em contato com o suporte do fornecedor com uma solicitação para ajudá-lo na atualização.
Sistema de bilhetes
Agora você pode olhar em volta. Você precisa estabelecer processos de interação com outros departamentos e dentro do departamento.
Talvez isso não seja obrigatório (por exemplo, se sua empresa é pequena), mas eu recomendo organizar o trabalho de forma que todas as tarefas externas e internas passem pelo sistema de tickets.
Um sistema de ticket é essencialmente sua interface para comunicações internas e externas, e você deve descrevê-la com um grau suficiente de detalhes.
Vamos dar um exemplo de uma tarefa importante e frequentemente encontrada de abrir acesso. Vou descrever um algoritmo que funcionou muito bem em uma das empresas.
Exemplo
Para começar, os clientes de acesso frequentemente articulam seu desejo em um idioma incompreensível para um engenheiro de rede, ou seja, no idioma do aplicativo, por exemplo, “me dê acesso ao 1C”.
Portanto, nunca aceitamos solicitações diretamente desses usuários.
E esse foi o primeiro requisito
- solicitações de acesso devem vir dos departamentos técnicos (no nosso caso, eram unix, windows, engenheiros de helpdesk)
O segundo requisito é que
- esse acesso deve ser registrado (pelo departamento técnico do qual recebemos essa solicitação) e, como solicitação, obtemos um link para esse acesso registrado
A forma desta solicitação deve ser clara para nós, ou seja,
- a solicitação deve conter informações sobre qual e em qual acesso à sub-rede deve ser aberto, bem como sobre o protocolo e (no caso de tcp / udp) portas
Também deve ser indicado
- descrição de por que esse acesso é aberto
- temporário ou permanente (se temporário, até que data)
E um ponto muito importante é
- do chefe do departamento que iniciou o acesso (por exemplo, contabilidade)
- do chefe do departamento técnico, de onde essa solicitação chegou ao departamento de rede (por exemplo, suporte técnico)
Ao mesmo tempo, o “proprietário” desse acesso é considerado o chefe do departamento que iniciou o acesso (contabilidade em nosso exemplo) e é responsável por manter a página com acesso registrado para esse departamento atualizada.
Registo
Isso é algo para se afogar. Mas se você deseja implementar uma abordagem proativa, precisa aprender a lidar com esse fluxo de dados.
Aqui estão algumas sugestões práticas:
- visualizar os logs necessários diariamente
- no caso de uma visualização agendada (e não de emergência), você pode limitar-se a níveis de gravidade de 0, 1, 2 e adicionar seus padrões favoritos de outros níveis, se considerar necessário
- escreva um script que analise os logs e ignore os logs cujos padrões você adicionou à lista de ignorados
Essa abordagem permitirá, com o tempo, compilar uma lista de ignorados de logs nos quais você não está interessado e deixar apenas aqueles que realmente considera importantes.
Funcionou muito bem para nós.
Monitoramento
Não é incomum quando uma empresa não possui um sistema de monitoramento. Você pode, por exemplo, confiar nos logs, mas o equipamento pode simplesmente "morrer" sem ter que "dizer" nada, ou o pacote do protocolo udp syslog pode ser perdido e não alcançar. Em geral, é claro, o monitoramento ativo é importante e necessário.
Dois exemplos mais exigidos na minha prática:
- monitorar o carregamento de canais de comunicação, links críticos (por exemplo, conectar-se a provedores). Eles permitem que você veja proativamente o potencial problema de degradação do serviço devido à perda de tráfego e, consequentemente, evite-o.
- Gráficos baseados em NetFlow. Eles facilitam a localização de anomalias de tráfego e são muito úteis para detectar alguns tipos simples, mas significativos, de ataques de hackers.
Importante! Configure a notificação por sms para os eventos mais críticos. Isso se aplica ao monitoramento e ao log. Se você não tiver um turno de plantão, o SMS também deve aparecer após o expediente.Pense no processo de forma a não despertar todos os engenheiros. Tínhamos um engenheiro de plantão para isso.
Controle de mudança
Na minha opinião, não é necessário controlar todas as alterações. Mas, em qualquer caso, você poderá, se necessário, encontrar facilmente quem e por que fez essas ou outras alterações na rede.
Algumas dicas:
- use o sistema de ticket para obter uma descrição detalhada do que foi feito como parte desse ticket, por exemplo, copiando a configuração aplicada ao ticket
- Use os recursos de comentário no hardware da rede (por exemplo, confirme o comentário no Juniper). Você pode gravar o número do bilhete
- use diff dos seus backups de configuração
Você pode inserir isso como um processo, pesquisando todos os tickets diariamente para alterações.
Os processos
Você deve formalizar e descrever os processos em sua equipe. Se você chegou a esse ponto, pelo menos os seguintes processos já devem funcionar em sua equipe:
Processos diários:
- trabalhar com tickets
- trabalhar com logs
- controle de mudança
- folha de verificação diária
Processos anuais:
- extensão de garantias, licenças
Processos assíncronos:
- resposta a várias emergências
Conclusão da primeira parte
Você notou que tudo isso não tem a ver com configuração de rede, design, protocolos de rede, roteamento ou segurança ... Isso é algo em torno. Mas estes, embora talvez chatos, mas, é claro, elementos muito importantes da unidade de rede.
Até agora, como você vê, você não melhorou nada na sua rede. Se havia vulnerabilidades de segurança, elas permaneciam; se havia um design inadequado, ele permanecia. Até você aplicar suas habilidades e conhecimentos de um engenheiro de rede, que provavelmente gastou muito tempo, esforço e, às vezes, dinheiro. Mas primeiro você precisa criar (ou fortalecer) a base e depois fazer a construção.
As partes a seguir são sobre como procurar e corrigir erros e, em seguida, melhorar sua infraestrutura.
Obviamente, não é necessário fazer tudo sequencialmente. O tempo pode ser crítico. Faça em paralelo se os recursos permitirem.
E uma adição importante. Comunique, pergunte, consulte sua equipe. No final, cabe a eles apoiar e fazer tudo isso.