Ambiente de DR: sua empresa está realmente preparada?

Como a maioria dos profissionais de TI sabem, ambiente de contingência ou ambiente de DR (Disaster Recovery) é a infraestrutura que entrará em uso caso um problema grave ocorra por causa de incêndios, enchentes, quedas de energia, erro humano ou caso um malware/ransonware prejudique os servidores ou um datacenter. O ambiente de DR  permitirá que a empresa se mantenha em funcionamento enquanto o problema no ambiente produtivo está sendo solucionado.

Entendido o que é um ambiente de DR, precisamos ter em mente que não é consenso entre muitos gestores se devemos usar ou não usar um ambiente de DR, já que na maior parte do tempo ele não será usado. Mas esta não é a pergunta correta a ser feita. Eles deveriam estar se perguntando “qual será o prejuízo que a minha empresa terá se tivermos uma parada inesperada em algum sistema crítico para o negócio?

A palavra prejuízo neste texto nos leva a refletir sobre diversos aspectos. Dentre eles podemos citar danos à imagem, impacto na reputação do ambiente, perda de clientes, penalidades para o fechamento de contratos, riscos de ciberataques, ausência de treinamento para uma recuperação rápida e muitos outros pesadelos que tiram o sono de qualquer diretor financeiro.

De acordo com a empresa BackBox, especializada em backup e recuperações, 50% de todos os negócios já tiveram algum desastre ruim o bastante para interromper alguma aplicação, sendo 18,5 horas a média para o tempo de inatividade de uma aplicação (downtime). A mesma empresa afirma que pequenos negócios podem enfrentar perdas de US$ 8.000,00 por hora, enquanto empresas médias sofrem perdas entre US$74,000 a US$90,000 por hora. Já empresas de grande porte podem ter perdas que variam de US$700,000 a até US$800,000 por hora que a aplicação crítica ficou sem funcionar.

O estudo da BackBox aponta que cerca de 81% das paralizações duram pelo menos um dia e apenas 35% das pequenas empresas possuem planos de recuperação contra desastres. É impressionante observar que 75% das empresas pesquisadas informaram que seus planos contra paradas inesperadas (desastres) são inadequados. Comecei a me questionar quais passos estariam sendo desenhados de maneira errada?

Insatisfeito com os números, decidi examinar o que revelava o relatório “The State Of Disaster Recovery Preparedness 2017”, feito com a participação da Forrester Research e  o Disaster Recovery Journal. O relatório mostra diversos estudos, envolvendo estratégias para Continuidade de Negócio (BC-Business Continuity) e Recuperação de Desastres (DR-Disaster Recovery). O relatório entrevistou 73 tomadores de decisão, mostrando que:

Note que 45% (34%+11%) dos entrevistados não estão contentes com suas estratégias e sentem-se inseguros. Se realmente uma falha em seus sistemas críticos ocorrer estará em risco não só o impacto nos negócios, mas a reputação e a carreira de todos os responsáveis.

A mesma pesquisa revela que diversos motivos foram revelados para a criação de um ambiente para DR dentre eles podemos citar: competitividade e necessidade de permanecer online, motivos legais, custos das próprias empresas paradas, elevação de riscos naturais ou riscos causados pelo homem, elevação da disponibilidade de uma aplicação crítica, responsabilidade legal, ambiente de DR identificado como prioridade máxima pela diretoria.

Independente do motivo, desenvolver uma estratégia para a contratação de um ambiente de contingência é inevitável para qualquer empresa. Mas se a justificativa for custos, basta olharmos os valores que serão gastos com os prejuízos de uma parada inesperada em um ambiente crítico. Claramente estes custos são superiores do que os custos da grande maioria dos ambientes de contingência. É esta conta que os responsáveis pelo negócio de uma instituição devem fazer, sendo o papel dos gerentes de infraestrutura primordial para que esta visão seja considerada pela diretoria.

Ok, vamos assumir que a contratação do ambiente de DR é prioritária e foi aprovada pela diretoria, é importante destacar que frequentemente um ambiente de Backup é confundido com um ambiente de DR e isto pode trazer sérias complicações.

Pode-se dizer que Backup é a cópia de dados em um disco, fita ou em um ambiente de Cloud e o retorno desta informação em caso de necessidade pode ser muito longo e o tempo cíclico para elaborar a atualização dos dados tende a ser muito longo. Outro ponto importante é o baixo uso de automação, além de grande carga de horas da equipe de TI para guiar a recuperação do ambiente produtivo. Resumindo: muito suor e elevada possibilidade para grandes perdas financeiras.

Se imaginarmos os conceitos ligados a um ambiente de DR, veremos que o tempo entre replicações ou atualização das informações é chamado de RPO (Recovery Point Objective) e que o tempo para recuperar as informações e ativar o ambiente ou recuperar a aplicação prejudicada é chamado de RTO (Recovery Time Objective). Nem sempre isto é compreendido pelas empresas e o resultado é um projeto incompleto ou confuso. Importante destacar que:

 

“Não existem melhores práticas para serem usadas, tudo vai depender do negócio de cada empresa.”

 

Em um ambiente envolvendo o conceito de Disaster Recovery (DR) veremos que é indispensável a presença de mecanismos para a automação, estejam eles ligados a replicação de informações ou estejam eles ligados a orquestração para que as máquinas e bancos de dados sejam ligados na ordem correta.  Resumindo: temos aqui baixíssimo suor usando ferramentas para obter mínimas perdas financeiras.

Com isto em mente, muitas empresas acreditam que é suficiente, mas isto é um grande engano. É necessário ter uma equipe bem treinada, sendo apoiada por um bom run book. Um run book é um documento com a sequência de procedimentos e rotinas que devem ser seguidas por cada equipe envolvida no ambiente de DR.

Para finalizar, vamos imaginar um ambiente produtivo virtualizado que necessita ser protegido com a presença de uma estrutura de DR operando em um Data Center remoto. Quais as atividades recomendadas para a construção deste ambiente?

  • Primeiro deve-se mapear todas as aplicações realmente críticas para o negócio, juntamente com o impacto caso estas aplicações parem inesperadamente o seu funcionamento;
  • Depois é importante analisar se as aplicações identificadas estão devidamente configuradas, sem a configuração excessiva de disco, processamento ou memória RAM;
  • Com a validação do size correto das aplicações, é necessário analisar o impacto financeiro. Quanto tempo o negócio aceita ficar com suas principais aplicações sem atividade? O resultado desta análise é a definição do RPO e RTO;
  • Definidos o RTO e RPO, basta criar o run book;
  • O quinto ponto é o mais importante, estando ele centrado em pessoas. Sendo necessário:

I. Nomear uma equipe multidisciplinar para a elaboração das atividades quando for decretado o uso do ambiente de DR. Importante considerar não só membros da equipe técnica, mas também membros da diretoria ou da equipe jurídica. Deve-se nomear uma pessoa que será a representação da empresa para elaborar comunicados aos jornalistas e a mídia eletrônica, reduzindo as perdas na imagem da instituição;

II. Capacitar e treinar a equipe para elaborar simulações validando as atividades contidas com testes de DR. O resultado dos testes deve gerar um relatório com todos os pontos de melhoria;

III. Com os resultados das simulações, a equipe deve elaborar testes de DR duas vezes no ano. O resultado dos testes deve gerar um relatório apontando as evidências de cada atividade feita proporcionando auxílio ao processo de auditoria ou aos investidores da empresa;

Tenha em mente que as atividades “a” e “b” possuem o objetivo de reduzir custos do ambiente de DR. Este ambiente deve impactar minimamente a equipe envolvida, sem abrir mão de transparência, simplicidade operacional e deve-se ter suporte de uma equipe externa devidamente capacitada sempre que necessário.

 

Denis Souza

 

Links Recomendados:

 

Alavancando a performance do seu e-commerce com TI

O número de profissionais dedicados exclusivamente ao planejamento e gestão de infraestrutura de E-Commerce está crescendo. E existem motivos de sobra para isso: cada vez mais percebe-se o valor de pessoas especialistas numa área que é missão crítica para muitas empresas, sejam elas dedicadas ou não ao varejo online. Um cliente disposto a comprar que não encontra o site disponível naquele momento pode não voltar mais tarde.

O objetivo do trabalho do Gestor de Infraestrutura de e-Commerce é projetar, desenvolver e manter o business rodando de forma a atender alguns objetivos essenciais:

  • Trabalhar para ter uma infraestrutura de padrões abertos, segura, e escalável para futuras necessidades;
  • Ter bem definido o modelo de sustentação do negócio;
  • Ter a visão da correta estratégia de Cloud que melhor se adequa ao seu negócio para os próximos anos

Ainda, o profissional deve estar muito familiarizado com alguns conceitos básicos e funcionalidades de componentes de Hardware e Software, especificação de níveis de serviço (SLA’s), gerenciamento da operação e uma noção de todos os componentes e ambientes satélites do seu e-Commerce (ERP, Gateway de Pagamento, Antifraude, Recomendações, Service Center, Emissão de NF-e, Gestão de Conteúdo, etc).

Além disso, é muito importante que o Gestor de Infraestrutura conheça os componentes de Hardware e Software do seu ecossistema (Middleware, Banco de Dados, Servidores Web, Balanceadores, Storage) e sua forma de escalonamento. Conhecer como esses componentes podem ser escalados é informação crucial para preparar o seu ambiente para eventos sazonais que certamente exigirão de seus componentes a manutenção dos níveis de resposta razoáveis para o usuário final.

Como avaliar uma infraestrutura de e-Commerce? Existem diversas maneiras e indicadores para auxiliar nesta tarefa. Alguns que podemos citar:

  • Flexibilidade:a capacidade de responder rapidamente à necessidade de up e downscaling com base na necessidade do negócio;
  • Custos:CapEx e OpEx relacionados aos custos de aquisição e manutenção para servidores, licenças e outros itens de hardware e software. Não esquecer a parte relativa à manutenção/suporte anual dos fornecedores da plataforma & implementação
  • Segurança e Compliance de TI:de que forma as informações sensíveis armazenadas pela plataforma estão protegidas? Estou inserido em uma indústria regida por leis específicas e/ou políticas de privacidade particulares? É possível que, dado o contexto, as informações geridas pela plataforma precisem estar regidas por algum tipo de regulamentação
  • Confiabilidade:como meus clientes são afetados por fatores como disponibilidade de serviços e cumprimento dos SLA’s internos da minha plataforma? Normalmente o cliente final (usuário do site) é impactado em medida equivalente à entregue pelos nossos fornecedores
  • Gerenciamento de serviços centralizado e Cloud-ready:fatores como suporte oferecido pelos fabricantes e funções para controle e monitoramento com visão 360º dos componentes da plataforma

O desempenho e-Commerce é outro fator bastante importante. Mais importante ainda é poder diagnosticar com rapidez eventuais relatos de lentidão no acesso ao site, seja via monitoramento do usuário real ou de monitores de pontos vitais específicos, e agir mitigando a má experiência de navegação do usuário naquele momento no site. Alguns exemplos:

  • Monitoramento contínuo dos tempos de resposta das principais páginas do site (TTFB | Time-to-First-Byte e Load Time)
  • Desempenho de rede com foco em tempos de resposta ponta a ponta (interno e externo), bem como a banda internet disponível
  • Monitoramento dos sinais vitais dos componentes da plataforma (CPU/memória/disco)
  • Monitoramento DNS
  • Avaliação de serviços de terceiros, principalmente aqueles que são executados de forma síncrona

A Compasso – uma empresa UOLDIVEO – é especialista na implementação de Plataformas de E-Commerce, tendo entregue dezenas de projetos nesta área ao longo dos últimos 5 anos. A Compasso atua no planejamento, design, implementação e sustentação de projetos de E-Commerce. Além disso, hoje sustenta e gere a infraestrutura de E-Commerce de grandes varejistas no Brasil.

Neste ano, a Compasso prestigia cinco de seus clientes que estão concorrendo ao Prêmio E-Commerce Brasil, a maior e mais importante premiação do segmento. Encerra hoje (19/07) a fase de votação popular.

  • Inovação em Tecnologia: Loja Natura
  • Inovação em Tecnologia: Profissional Rony Meisler, Reserva
  • Inovação em Vendas: Lojas Renner
  • Inovação em Operação: Livraria Cultura
  • Inovação em Experiência: Loja Farm

Sentimos muito orgulho do sucesso dos nossos clientes, mais ainda por fazer parte dele!

 

Garanta suas Datas – Parte 4

Olá pessoal,

Dando sequência ao artigo ‘Garanta suas Datas – Parte 3’ publicado no dia 23 de novembro hoje entraremos na 4 e última etapa deste estudo. Caso você não tenha lido os posts anteriores sugiro voltar lá, pois poderá ter dificuldades de entender a lógica do estudo de caso.

GESTÃO POR INDICADORES

Gosto muito de realizar gestão baseado em indicadores. Quando realizamos gestão pelos números certos nossas decisões e estratégias se tornam muito mais assertivas.

Quando comecei a estudar Lean me deparei com um mundo de indicadores totalmente novos e meu impulso inicial foi querer medir tudo que fosse possível.

Não cometa o mesmo erro!

Se você é um aficionado por números assim como eu, segure o impulso. Medir todos os indicadores possíveis sem uma ferramenta que lhe forneça estes números de forma automática irá lhe trazer uma carga extra de burocracia que irá impactar o dia a dia do seu time. Principalmente no momento em que estiver implantando esta nova cultura.

Encontrei a medida certa quando conheci o gráfico do Kanban (figura 16). Nele consigo extrair 3 indicadores que me permitem ter a visão necessária para realizar a gestão do time da forma correta.

Figura 16 – Gráfico de saída do processo do Kanban

Neste gráfico você consegue acompanhar as seguintes visões:

  • A camada roxa indica o tamanho do backlog, isto é, quantas histórias existem paradas na coluna ‘To Do’ do seu time;
  • A camada vermelha corresponde ao número de histórias vivas no seu board, no nosso exemplo corresponde as colunas WIP + Waiting + Review;
  • A camada azul indica quantas histórias seu time entregou.

Acompanhando o comportamento destas 3 camadas você é capaz de avaliar a saúde do processo. O ideal é que as camadas ‘In Progress’ e ‘Deployed’ tenham o mesmo comportamento, pois isto é reflexo do sistema puxado, ou seja, sempre que uma história é empurrada para fora (Deployed) uma nova história é puxada para execução (In Progress).

Também existem técnicas para tratar o backlog, onde você poderá apresentar no board apenas as atividades priorizadas. Neste caso o backlog deverá diminuir continuamente até que ocorra a carga de uma nova leva de histórias priorizadas. Esta carga costuma ocorrer antes do backlog zerar, garantindo assim que o time nunca fique sem demanda.

No próximo tópico irei lhes apresentar os principais indicadores deste gráfico e como você deve interpretá-los.

 

ENTENDENDO OS PRINCIPAIS INDICADORES

O gráfico do Kanban lhe fornece 3 indicadores básicos que lhe permitirá manter a gestão da sua equipe. Melhor que isto, permitirá que você melhore a relação com seu cliente, pois irá garantir transparência no alinhamento e manutenção de datas. Saiba como interpretar as informações fornecidas pelo gráfico do Kanban para extrair estes indicadores (figura 17).

Figura 17 – Principais indicadores do Kanban

Cycle Time (Cycle Time = Lead Time / WIP): corresponde ao tempo que o time leva para concluir uma história após ter iniciado sua execução. Com este número você terá condições de estimar a data de entrega de cada história viva no seu board.

Lead Time (Lead Time = Cycle Time * WIP): este indicador avalia o tempo que a história levará para ser entregue a partir da data em que ela foi inserida no seu backlog. Com ele é possível alinhar com o solicitante da tarefa qual a data estimada para sua entrega.

Throughput (Throughput = WIP / Lead Time): este indicador informa qual a vazão diária de histórias realizadas pelo time. Com esta informação você consegue estimar qual a data de entrega de uma determinada atividade, basta mapear o número de histórias que estão à sua frente e fazer a relação com o throughput da equipe.

Com apenas estes 3 indicadores consigo manter uma gestão que me permite:

  • Avaliar a produtividade da equipe;
  • Identificar desvios na execução do processo;
  • Analisar o impacto gerado por priorizações de histórias;
  • Apoiar renegociação de datas já definidas;
  • Manter a transparência com o cliente.

Trabalhe diariamente para manter estes indicadores saudáveis e lhe garanto que sua dor de cabeça irá reduzir significantemente.

 

DIVERSIFICANDO VISÕES

Você lembra que destacamos com cores diferentes as etapas que eram de responsabilidade de times terceiros na construção do fluxo de Implantação? Pois é, agora que você conhece os indicadores que podemos acompanhar através do gráfico do Kanban tenho certeza que você irá querer ‘brincar’ com visões diferentes.

Por exemplo. Não seria interessante conhecer o lead time e o cycle time para as histórias direcionadas às equipes terceiras? Saber o quanto atividades direcionadas às equipes fora da sua alçada estão impactando seu projeto é uma informação valiosa para traçar novas estratégias.

Isto pode ser feito de maneira fácil, basta você trabalhar com boards diferentes no Kanban. Note que não estou falando que todos os times devem utilizar esta metodologia para você ter esta visão. Entendo que este seria o melhor dos mundos, mas sei o quão difícil é mudar esta cultura para a empresa inteira e provavelmente você não conseguirá fazer isto de ‘bate pronto’.

Faça o seguinte. Crie 2 boards idênticos no Kanban, mas desta vez não adicione a coluna ‘Waiting’ (figura 18). Nomeie 1 board como Implantação e o outro board como Terceiros.

Figura 18 – Separando a visão de terceiros

A partir deste momento seu time poderá lançar as histórias que dependem exclusivamente deles no board ‘Implantação’ e lançar as histórias que envolvem equipes terceiras no board ‘Terceiros’. Faça esta divisão com base na classificação que realizamos no mapeamento do fluxo de Implantação.

Manter os boards separados lhe permite visualizar os indicadores referentes as atividades exclusivas do seu time e os indicadores referentes as atividades realizadas por times terceiros. Estas visões lhe permitem identificar como os times terceiros estão impactando seus projetos.

Se você conseguir automatizar a abertura das histórias nos boards, sugiro que crie um board para cada time envolvido no fluxo de Implantação, aprofundando ainda mais a visão e controle que você manterá sobre o processo.

Utilizando o mesmo conceito você poderá criar um board gerencial apenas com os épicos. Esta visão lhe permite conhecer os indicadores referentes ao projeto como um todo e não mais apenas as etapas mapeadas no fluxo.

 

O PODER DA INFORMAÇÃO

Com base em todo o trabalho que lhes apresentamos até aqui, você será capaz de gerar visões importantes para garantir a gestão do seu time e aumentar a transparência no relacionamento com as demais áreas que se relacionam com o processo de Implantação.

Veja algumas visões interessantes que você poderá acompanhar:

  • Através da visão gerencial você conseguirá estimar datas para entregas de projetos com uma assertividade muito alta. Isto é feito através do indicador de lead time do board gerencial.
  • Você conseguirá acompanhar os indicadores de cada equipe terceira e será capaz de identificar quando mudanças internas destas equipes impacta seus projetos. Isto é feito através do throughput de saída acompanhada no board de terceiros.
  • Impactos devido a priorizações de histórias poderão ser medidos com base nos indicadores de cycle time ou do throughput de saída. Isto é importante para repactuar as datas de épicos e histórias já existentes.
  • Será possível planejar o impacto na produtividade do time durante ausências programadas na equipe (período de férias por exemplo). Esta análise pode ser realizada através do throughput de saída.
  • Você poderá avaliar o indicador de throughput por analista. Esta informação permite você identificar analistas que estejam com uma produtividade muito baixa para poder providenciar ações como capacitação por exemplo.
  • Dependendo do nível de automação que seu processo possuí é possível extrair os indicadores para cada uma das etapas mapeadas no fluxo de Implantação. Isto é interessante para você identificar impactos referentes aos processos da empresa. Por exemplo, o indicador de Cycle Time da etapa ‘RFC’ pode sofrer mudança de comportamento caso o processo de GMUD foi alterado.

Estes são apenas alguns exemplos de análises possíveis neste cenário. Tenho certeza que você terá novos insights quando aplicar este trabalho na realidade da sua companhia.

 

CONCLUSÃO

Este estudo de caso lhes mostrou como estruturar um time de Implantações de forma a mitigar o risco de estouro de datas alinhadas com seus stakeholders. Você pode aplica-lo em qualquer fluxo de implantação, mas seu valor será maior em fluxos que envolvem mais de uma equipe.

Não tive o intuito de lhes entregar o passo a passo exato do que devem fazer, pois entendo que você encontrará particularidades em sua empresa que deverão ser superadas com criatividade, seja adaptando os conceitos que lhes apresentei ou integrando outros conceitos à sua solução.

O mais importante é lhes instigar a estruturar soluções para seus problemas encaixando as ‘peças’ de conhecimentos que você vem acumulado ao longo da sua jornada. Seja flexível, faça pequenas alterações ou adaptações para conseguir desenvolver soluções que atendam melhor suas necessidades.

Aproveite o conhecimento que te apresentei, pois você não precisa começar do zero, mas não se prenda somente a ele. Você já pensou em adaptar esta proposta para atender requisições da Operação? Antes de falar que não é possível avalie em um nível mais profundo, identifique os verdadeiros empecilhos e faça modificações na solução se for necessário. Mas não fale que não dá porque ninguém o fez ou porque a metodologia xyz não lhe indica fazer desta forma.

Pare de copiar e comece a criar! Pare de seguir e comece a puxar!

 

Rodrigo Muniz da Rosa