Não atualizamos nosso RDBMS ou sistema operacional de servidor há quase uma década. Outro pacote de software de missão crítica tem quase duas décadas e não é suportado pelo fornecedor por grande parte desse tempo. Alguns membros da nossa administração parecem pensar que isso é uma coisa boa - economizamos muito dinheiro ao não comprar as atualizações! Agora, uma parte crítica do software precisa de uma atualização, mas a nova versão não suporta o material de uma década. Agora, um punhado de nós está perdendo o cabelo tentando descobrir como atualizar tudo de uma só vez com um tempo de inatividade mínimo.
Em um esforço para evitar isso no futuro, alguns de nós estão considerando a criação de um documento de plano estratégico de TI (que se encaixará no plano estratégico da organização, detalhando os itens no documento maior relacionado a TI ... talvez isso torna o documento de TI uma táticaplano?) na esperança de que possamos adotá-lo como parte do plano estratégico geral da agência. Ofereci-me para tentar montar a seção "Gerenciamento do ciclo de vida de software" (ou algo parecido) para solucionar o problema observado acima (com as tachas de latão provavelmente em um documento separado do plano estratégico). Quase todos os fornecedores de software publicam ciclos de vida e planos de suspensão de uso de seus produtos, e é fácil determinar um "ponto ideal" para cada peça de software, considerando essas informações juntamente com as necessidades de nossa organização. A parte complicada (para mim, de qualquer maneira) é colocar o plano de cada peça em algo mais coeso.
Como posso documentar que os clientes de desktop A, B, C ... dependem do OS X e RDBMS Y da área de trabalho, que por sua vez dependem do servidor OS Z e, em seguida, veja como mantemos todos eles em seus "pontos positivos"? Deve haver livros por aí, mas todo o meu trabalho no Google só me levou a pensar nas táticas de atualizar um único pedaço de software, em vez da estratégia para determinar quando implementar essas táticas.
fonte
$CURRENT-version minus 20 yearspara$CURRENT-versionetc. e você provavelmente chegará à conclusão: NÃO foram economias reais, mas DESPESAS que terão de ser pagas em uma data futura .Respostas:
Parece que você está tentando resolver muitos problemas de uma só vez (e não parece uma boa ideia).
Pelo que li:
Atualizando "parte crítica do software"
Sua infraestrutura está desatualizada devido à decisão de alguém e fácil de entender. Provavelmente parecia uma boa ideia em algum momento do passado. Isso se resume ao que Michael Hampton escreveu nos comentários: Para a gerência, você está falando de prós e contras (riscos). Portanto, se a gerência estiver disposta a correr um risco, tudo bem (o que você pensa sobre isso pessoalmente) e é responsabilidade deles a partir de agora. Mas alguém da equipe de TI precisa dizer a eles quais são os riscos.
Então, a primeira coisa que procuraria é: os gerentes sabiam sobre os riscos de software desatualizado? Eles foram informados?
Sinceramente, acho que você provavelmente não encontrará nada útil sobre isso, para que eu não gaste muito tempo com isso. É apenas algo que pode ajudá-lo na linha de "estávamos lhe dizendo nos últimos cinco anos".
Eu simplesmente faria uma análise do que realmente significa realizar essa atualização. Prepare uma planilha simples com as atividades e quanto tempo elas levarão (se você não souber, adivinhe e enfatize explicitamente que não sabe ao certo). Mas lembre-se de que esta "tarefa de atualização" não está bem especificada, é impossível fazê-lo como tempo fixo / preço fixo.
Fazer essas listas também ajudará você a detalhar todo o problema. O próximo passo é criar um registro de riscos e uma lista de recursos necessários.
No final, você deve ter uma lista de atividades, lista de riscos, material / pessoas que você precisa. Em uma palavra, não lide com a atualização como um problema diário, faça-o como um PROJETO. Isso permitirá que você tenha pelo menos algum controle sobre a necessidade aguda de sua empresa.
Se você tiver problemas para analisar quais atividades precisam ser realizadas, tente um mapa mental (meu sw favorito é xMind) e depois converta-o em um documento mais formal.
Observe que, se você tem algumas opções de como fazer a atualização, deve fornecer a seus gerentes um resumo das possíveis soluções (se houver mais), resumidas em algumas frases, incluindo custo, resultado e risco; mencionar idealmente a opção que você recomenda e por quê. Porque a escolha final é deles - eles são gerentes, afinal.
Talvez neste caso em particular: mencione que a atualização pode não ser possível.
Nenhuma estratégia de longo prazo
Criar um plano estratégico não o ajudará agora. Não ajudará em nada se for um documento produzido dentro do seu departamento de TI. Plano estratégico é algo que precisa estar vinculado às necessidades do negócio.
Exemplo de necessidade comercial: Em dois anos, abriremos novos escritórios na China e na Austrália.
Tarefas de TI derivadas: Esteja preparado para obter novos piores funcionários, criar infraestrutura em escritórios estrangeiros, fornecer treinamento para novos funcionários (possivelmente usando seu idioma nativo), fornecer conectividade segura desses escritórios à central, ...
Se tudo correr bem, você pode ter uma estratégia, talvez ... em alguns meses? Então, cerca de meio ano até que tudo esteja de acordo?
Manutenção e documentação de sua infraestrutura
Esta é uma herança do passado e agora você tem que mudar as coisas. Prioritizar. Faça uma lista das coisas que você deseja / precisa fazer agora para atualizar a maioria das coisas. Escolha o que pode esperar, faça um roteiro bruto. (Este roteiro deve fazer parte da sua estratégia de TI quando você tiver uma.)
Se você estiver atualizando algo que correu bem, trate-o como um negócio diário. Se você estiver lidando com algo que pode dar errado (é "grande" em termos de tempo gasto, pessoas alocadas etc.), lide com isso como um projeto.
Existem ferramentas que podem ajudá-lo com dependências de documentação e serviço - CMDBs (iTop, por exemplo). Mas fazê-lo funcionar pode levar algum tempo e você ainda precisa de alguma ferramenta de documentação. A melhor idéia é configurar um wiki para a documentação em que todos possam começar a documentar / fazer anotações a partir de agora. Você pode configurar um wiki em meia hora, por isso é uma maneira muito eficaz de começar.
Nota pessoal: Atualizar o SO antigo seria um enorme PITA, sem mencionar a documentação (provavelmente ruim / ausente). Não é mais fácil instalar servidores novamente, migrar aplicativos e documentar tudo desde o início?
fonte