. Melhores práticas para a gestão da mudança no centro de dados - Tudo Sobre Tecnologia

A gestão da mudança pode ser um complexo caminho cheio de buracos. Aprenda algumas dicas de navegação para aplicar em sua organização. 
datacentercloud.png
A ironia de trabalhar no sistema ou a administração da rede é que você está lá para manter o status quo (ou como eu gosto de expressá-lo ", preservando a ordem em um mundo caótico"), e ainda gestão de mudanças cuidado também é o seu trabalho. Efetiva prestação de serviços e recursos exige que você mantenha o melhor possível o tempo de atividade durante a transição do velho para o novo, seja substituindo a tecnologia ou simplesmente melhorar em cima dele.
Gestão da mudança (também conhecido como gerenciamento de configuração), nem sempre é seguro ou fácil. Por outro lado, se nós só fizemos o que estava a salvo em TI podemos tudo ainda estar executando o Windows NT 4 SP6a. Implantação de novos sistemas e tecnologias parece estar chegando mais rápido e ainda mais furioso o tempo todo. Já vi sistemas implementados um ano e depois arrancado o próximo a pavimentar o caminho para algo melhor. O conservador fiscal em mim às vezes chocado com o desperdício possível envolver com isso, o lado técnico dos meus natureza revela na implantação de novas coisas.
Ao longo dos anos eu peguei algumas orientações para a gestão da mudança que eu queria compartilhar. Alguns vieram da experiência direta, outros de mentores, e um pouco mais de observar os piores cenários em ação nas empresas de amigos ou colegas.  
Quando me refiro a gestão da mudança, estou me referindo às instalações tecnológicas, atualizações, correções e migrações (como um servidor físico para uma máquina virtual).Note-se que há mudança de processos formais de gestão  , tais como aqueles relacionados à Infrastructure Library Tecnologia da Informação  (ITIL). Há também pacotes de software dedicados, como Evolven  e McCabe CM  que ajudam esses empreendimentos. Enquanto alguns desses materiais se sobrepõe com este artigo (e pode ser objecto de futuras colunas), o meu comentário aqui implica um conjunto mais casual de dicas baseadas nas boas práticas tenho observado ao longo empresas de sucesso.

Você pode nunca ter muita redundância

A maioria dos profissionais de TI não vai precisar ser vendido neste (o desafio pode estar em departamentos financeiros de forma convincente), mas nada de missão crítica tem um irmão gêmeo. Isso se aplica a servidores, equipamentos de rede e até mesmo de armazenamento.Se você precisa para executar o seu negócio, certifique-se que há dois de tudo. Se você não pode ter dois, descobrir como você pode remendar um sistema de substituição se o primário ficar indisponível. Por exemplo, alguns anos atrás eu configurar um servidor de arquivos do Windows com todos os dados compartilhados hospedados em um volume de SAN. Nós não temos o orçamento para um agrupamento oficial ou solução de balanceamento de carga, por isso desenvolveu um plano de failover com um servidor de backup:
Isso significa que o servidor de backup pode "tornar-se" o servidor primário muito facilmente apenas atualizar o registro DNS associados e os usuários podem ser redirecionados para que em pouco tempo (muitos nem sequer notar a interrupção). Isto incluiu mapeamentos de unidade e de acesso de compartilhamento de arquivos. Documentar que significava qualquer um dos meus colegas de trabalho poderia seguir os passos também.
Quando se trata de componentes redundantes, torná-los idênticos em todas as formas possíveis para fazer apoiá-los tão previsível quanto você pode - eles devem ser do mesmo fabricante / modelo, execute o mesmo sistema operacional, tem os mesmos drivers e hotfixes, ligado à mesma portos de diferentes switches ou PDUs, e assim por diante.
Não é outra dica importante envolvendo a redundância ...

Mudanças para fora do espaço entre os sistemas redundantes

Seu redundância lhe dará uma enorme influência quando se trata de aplicar as alterações, pois você pode levar metade de um par redundante para baixo para mover ou atualizá-lo, em seguida, fazer o mesmo para a outra metade. No entanto, nunca fazer isso sem deixar uma lacuna de tempo entre a certificar-se da primeira mudança foi bem sucedida. Quando os servidores de aplicação de patches, por exemplo, não corrigir o segundo conjunto de sistemas até vários dias se passaram para dar-lhe algum tempo para detectar e corrigir quaisquer problemas ... durante o qual você vai precisar contar com os sistemas que ainda são funcionais.

Use uma solução centralizada para implantar atualizações

Para o gerenciamento de mudança de qualidade, você deve sempre optar por o mínimo de complexidade, o que significa um sistema de in-house centralizado para empurrar para fora patches, atualizações de software, antivírus e configurações. Isto irá permitir que você a melhor oportunidade de acompanhar os seus sistemas e planejar as suas alterações, bem como relatórios sobre os resultados. Exemplos incluem o Microsoft Windows Server Update Services, da Microsoft System Center Configuration Manager , Microsoft Diretiva de Grupo  (parte do Active Directory), o Symantec Endpoint Protection  gerente e Dell Management Console . Estes produtos irão dar-lhe um único ponto de referência e garantir que seus clientes e servidores não são apenas baixar as atualizações à toa da internet (ou pior, deixando de fazê-lo e não informá-lo).

Nunca use uma bola de demolição

Eu vi um monte de filmes de terror no meu dia, mas nenhum deles era tão assustador quanto o conceito de arrancar um sistema existente para substituí-lo por um novo. Se um servidor de arquivos, servidor de e-mail, dispositivo de armazenamento, ou qualquer outra coisa, você sempre deve migrar para um novo sistema de deixar o antigo intacto até que você tenha pronunciado a mudança completa. Não desmantelar qualquer coisa até que ele é obsoleto.
Por exemplo, se atualizar um servidor de arquivos Windows 2008 para um 2012 de cópia do sistema do Windows todos os dados (com permissões!) Da caixa antigo para o novo e que os usuários testar o acesso. Em uma ocasião durante este esforço eu encontrei alguns problemas com o driver de rede no novo servidor que me obrigou a cortar os usuários de volta ao antigo sistema. Eu não me importava este passo desde que eu senti a sorte de ter o antigo sistema disponível para uso!
Eu cresci na década de 1970 e gostei muito do show eu gostei especialmente as cenas onde os bons e velhos rapazes Duke saltou um rio ou cânion do General Lee "The Dukes of Hazzard." - Uma vez que a polícia costuma persegui-los eles geralmente não tinha escolha a não ser tentar fazer esse salto. Eu gosto da vida real a ser menos emocionante do que a TV.Subindo pela janela do General Lee não é maneira de começar um projeto de mudança do centro de dados.

Elaborar planos de mudança com a entrada múltipla

Assim como você nunca pode ter redundância suficiente, você nunca pode ter medidas suficientes em seu plano de mudança e, como qualquer boa festa, os participantes mais você tiver, melhor serão as suas chances.  
Obter o máximo de entrada de outros, como você pode identificar quaisquer contratempos que aparecem. No entanto, fazer o seu plano inicial tão completo como você pode para que os outros não têm de preencher as lacunas para você. Então, você está atualizando o firmware que switch Cisco, em seguida, reiniciar-lo? Como é que você tenha certeza este é bem sucedido? Bem, você poderia ping-lo e, em seguida, pronunciar a atualização completa se ele responde ... mas eu acho que é apenas arranhando a superfície. Entrar, verifique os logs de erro e testar todas as funções. Entrar mais tarde e se certificar de que não travar devido a um vazamento de memória. Reiniciá-lo. Reiniciá-lo novamente. Conectá-lo a partir de outra sub-rede. Talvez após análise alguém vai sugerir testar alguns aplicativos core rodando em um servidor que conecta através desse switch, economizando, assim, a partir de um "Gotcha!" Momento. Todos estes são exemplos do que deve estar na sua lista passo-a-passo - e, idealmente, você veio com esta lista, trabalhando em um sistema de teste, apesar de ter aviso: resultados em seu ambiente de teste nem sempre são garantidos para ser repetido na produção.
Não assuma, porque você pode fazer alguma coisa, então ele deve estar funcionando. Ter alguém faça o login e tente. Tenho visto muitas das questões em que alguém com direitos de administrador pode executar uma função de direitos de usuário muito bem, mas regular não funcionou como o esperado, pelo menos até que eles foram alterados.
Um último ponto sobre esta: "Sim, que trabalhou duas vezes já então porque se preocupar" descendo sua lista várias vezes em diferentes sistemas será tedioso e chato, e você pode ser tentado a pular etapas ou cantos cortados, pensando, a Lei de Murphy ama essa tentação: resistir.

Utilizam vários métodos de aprovação

É ótimo se você pode obter feedback de outras pessoas sobre o que você deve adicionar ao seu plano de mudança. No entanto, as empresas inteligentes tornar os funcionários colocar seu dinheiro onde suas bocas são: aprovar um plano de método de aprovação para obter sanção de estas ou outras partes apropriadas. Isso pode incluir o seu chefe, o diretor de um departamento relacionado, ou o vice-presidente de sua base de clientes. Este processo de aprovação vai garantir toda a gente conhece, concorda em cima, e apoia a mudança proposta (s). Vamos enfrentá-lo: se eu sei que eu vou colocar meu nome em um plano que pode afetar a lucratividade da minha empresa, se as bombas, eu vou ter certeza que o processo é o som.
Não só este cobertor de segurança cobri-lo se algo der errado, mas vai manter as pessoas informadas, no caso de um fracasso e pode ajudar os grupos a trabalhar juntos para encontrar soluções.  

Formular um plano de devolução

Cada mudança deve ter um plano de devolução associada a ele. Como é que você vai colocar as coisas de volta para a forma como eles foram se algo falhar? Você vai usar instantâneos, como em um ambiente virtual? Você vai reimporte chaves de registro cruciais ou aplicar uma política de grupo de backup para voltar a configuração de servidor do Windows para seu estado anterior? Você precisa documentar este plano e torná-lo o mais limpo ainda elaborado possível.Sua criatividade pode muito bem ser prejudicada durante um fracassado mudança / upgrade e opções de pesquisa é a última coisa que você quer fazer durante esse tempo estressante. Seu plano de devolução pode muito bem ser uma apólice de seguro que você não vai precisar, mas o seguro também está lá para a paz de espírito.  
Se você tiver que fazer uma alteração, certifique-se de fazê-lo, obtendo o maior número de notas, screenshots ou outros elementos comprovativos de que você pode, então você pode descobrir o que deu errado e corrigir para a próxima vez. A estratégia de "tentar algo pela segunda vez e esperando que ele funciona" é uma receita para uma entrada desagradável.

Escolha sua programação mudança cuidadosamente

É quase desnecessário dizer que a maioria, se não todas as alterações no data center deve ser planejada depois de horas ou durante períodos não críticos. Mesmo atualizando sistemas redundantes pode representar um risco se o seu servidor secundário decide entrar em greve na 10:00 segunda-feira. No entanto, planejar o seu calendário com cuidado.
Você poderia realizar essa transição de banco de dados, às 11 horas de domingo. Mas o que se algo provoca um atraso ea transição ainda está em execução, quando os usuários chegam ao escritório de sete horas mais tarde?  
Talvez pegando 05:00 em uma sexta-feira seria uma idéia melhor. Uh, bem, só tome cuidado para você não encontrar-se envolto em sua vida em casa de tal forma que você se esqueça de verificar os resultados de atualização até chegar no trabalho na segunda de manhã.  
Talvez você tenha um site secundário que você usa para fins de recuperação de desastres (DR) e você fez o seu site principal para testar as suas capacidades de failover? Não se esforçam para atualizar os sistemas em seu site primário original 12 horas antes que você está programado para reverter o processo.
Como eu disse acima, sua agenda deve ser o produto das partes interessadas e grupos envolvidos com o uso, suporte e administração desses sistemas (quando aplicável).

Use auditoria e contas individuais

Sempre que possível utilize sempre auditoria em seu ambiente (mesmo se você tem que ativá-lo temporariamente durante um projeto de mudança, em seguida, desligá-lo para preservar os recursos). Isso ajudará a manter o controle de comandos executados nesses sistemas eo impacto resultante.  
Em uma nota similar, não use contas compartilhadas ou genéricos como "administrador" se você pode evitá-lo, estes comandos devem ser ligados a contas individuais (contas de preferência privilegiadas usado apenas para realizar esse tipo de trabalho, você deve usar normalmente um limitado conta, sempre que possível). Na verdade, isso nem sempre é fácil em um ambiente Active Directory, onde muitas coisas ainda teimosamente exigir o uso da conta de "administrador" de domínio, mesmo quando os privilégios comparáveis ​​ter (aparentemente) foi concedido a um indivíduo chamado. No entanto, prosseguir esta política, tanto quanto você puder.
Eu admito esta dica traz à mente uma citação do comediante Bill Cosby, que me ensinou muito do que eu pratico na paternidade: "Se algo está quebrado em casa, você tem um filho, você sabe quem fez isso" No entanto, não se trata de apontar o dedo, mas sim de documentar o que aconteceu e em que conta. Se uma mudança precisa ser revertida ou um problema identificado você vai precisar desta informação.

Sempre programar o tempo de inatividade em seu sistema de monitoramento

Vou sair em um membro e assumir que você tem um ambiente de monitoramento abrangente criado para verificar a integridade e disponibilidade de seus sistemas críticos e notificá-lo de quaisquer problemas. Quando você está planejando fazer qualquer um destes sistemas offline para fins de gestão da mudança, você deve sempre programar um período de tempo de inatividade razoável em seu sistema de monitoramento de antemão por isso vai permanecer em silêncio. Pode ser uma dor de dar esse passo, especialmente para sistemas múltiplos, mas a estratégia de ignorar os alertas críticos é perigoso demais para prosseguir.  
Se você está no meio de uma atualização que você não sabe realmente o que está acontecendo além da tarefa imediata na mão e você pode encontrar-se enganado pelas circunstâncias. Por exemplo, se você receber uma página dizendo que seu Ironport Cisco não responde, você pode pensar: "Sim, eu sei que é indiferente, já que estou atualizando-o!" E se depois descobrir que página foi para o outro, supostamente, Ironport em boa condição de trabalho que já está morto há 30 minutos?

Trazendo tudo isso junto

Muitas vezes existe uma enorme quantidade de pressão (externos ou internos) sobre o pessoal de TI para concluir uma tarefa e correr para o lado para que eles possam continuar a demonstrar valor para a organização. No entanto, essa pressão é antitético ao conceito de TI em si: manter as coisas funcionando com um mínimo de tempo de inatividade e interrupções.  
Muitas técnicas boas de gerenciamento de mudanças resumem-se ao senso comum, sendo conservador, e jogar pelo seguro. Esperemos que estas diretrizes ajudarão a fazer a mudança em seu ambiente tão previsível e controlado quanto possível, para que possa abraçar as possibilidades, em vez de temê-los.
Autor:

Sobre Scott Matteson

Scott Matteson é um administrador de sistemas sênior e escritor freelance técnico que também realiza trabalhos de consultoria para pequenas organizações. Ele reside na área metropolitana de Boston com sua esposa e três filhos.

0 comentários Goocle+ 0 Facebook

Postar um comentário

 
Tudo Sobre Tecnologia © 2013-2020. Todos os direitos reservados. Tudo Sobre Tecnologia. Desenvolvido por TST
Topo