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!

 

Qual é a nova posição do CIO na era digital?

Tenho me deparado muito com essa indagação: qual é a nova posição do CIO nesse mundo digital?

O mundo digital abre possibilidades enormes para todos os profissionais: marketing, vendas, mas especialmente para o executivo de TI.

Para continuar sendo importante, o CIO precisa deixar de ser visto como centro de custo e precisa passar a ser visto como gerador de receita.

Esta característica fica muito clara em pesquisas constantemente publicadas pelo Gartner que mostra que, especialmente em países latino-americanos, a otimização de custos está entre as principais preocupações destes profissionais. Questão importante, mas que não estão relacionadas a estratégias de crescimento de uma empresa.

Para assumir o papel de líder de inovação e impulsionador do negócio, o executivo deve encarar essa nova etapa como uma enorme oportunidade e não como uma ameaça a sua posição atual.

A grande vantagem que o CIO tem é o enorme conhecimento, muitas vezes acumulado por anos de aprendizado e prática, que os novatos ou os oriundos de outras áreas não possuem. A “mão na graxa” nessas horas faz a diferença para conectar o negócio com a tecnologia.

Nunca se abriu um universo tão amplo de oportunidades como na era digital.

Toda a indústria está se transformando, das tradicionais gravadoras de música, varejo e até bancos estão sendo reinventados. Aplicativos são criados a todo momento para alegria, e ao mesmo tempo, arrepio de muitos.

E é justamente nesse cenário que o CIO pode e deve ter papel fundamental.

Agora, a postura tem que seguir o mesmo ritmo das mudanças. O profissional além de continuar se aprimorando deve se desapegar do jeito antigo de fazer as coisas.

É preciso se manter atento às negociações de SLA que correspondem à qualidade adequada ao serviço prestado, acompanhe os resultados (KPI), que devem estar disponíveis na maioria das vezes em real time, mas acima de tudo se manter focado no negócio.

Se o CIO não fizer isso, certamente alguém da organização fará.

Boa sorte e conte conosco!

 

Do you WannaCry? Veja por que este ransomware é só a ponta do Iceberg

O tema ransomware não é nada novo, mas o que realmente significa? Podemos dizer que ransomware é um código malicioso usado por criminosos digitais para sequestrar dados e orquestrar ataques com o objetivo de desvio financeiro ou extorsão (cyber extorsão). O motivo para o ataque de ransomware é sempre monetário, onde a vítima é informada que o ataque está ocorrendo e é detalhadamente instruída de como o pagamento deve ser feito para obter sua as informações novamente. Importante deixar claro que não existe nenhuma garantia de que esta devolução vai realmente ser feita. Geralmente é usada moeda virtual (bitcoin) para proteger a identidade dos criminosos e dificultar o rastreamento do dinheiro pago.

 

O modelo padrão de funcionamento do ransomware baseia-se em mudar a senha do logon da vítima e criptografar o disco do computador infectado. Após esta atividade o computador é reiniciado com o objetivo de mostrar a mensagem indicando as instruções para pagamento. Segundo a Carbon Black, um importante fornecedor de hardwares e softwares de segurança, o ano de 2016 demonstrou um crescimento de 50% nos ataques de ransomware a industrias quando comparado ao ano de 2015. Empresas de manufaturas demonstraram um crescimento de 21,8% e empresas de energia e utilitários apresentaram um aumento de 16,4%. Este crescimento foi baseado em diversos fatores, dentre eles temos:

  • Grande quantidade de frameworks ou kits para desenvolvimento de variações de ransomware existentes ou para a criação de novas famílias de ransomware encontrados facilmente na Deep/Dark Web;
  • Uso a preços irrisórios de programas focados em Ransomware as a Service (RaaS) objetivando a elaboração de um ataque com pouquíssimo esforço;
  • Empresas continuam sem política para atualização de sistemas operacionais, deixando que funcionem com falhas muito antigas em seus ambientes;
  • Ausência de proteções adequadas para o correio eletrônico. Grande parte dos ataquem entram no ambiente corporativo pelo correio eletrônico iludindo o destinatário a abrir arquivos anexados ou a instalar aplicativos em seus computadores;
  • Não elaboração de treinamento dos usuários destacando as armadilhas dos criminosos cibernéticos ou mesmo a inexistência de política de segurança nos ambientes corporativos.

 

Infelizmente a tendência de 2016 foi mantida não só para ransomware, mas também para as ameaças disfarçadas, também conhecida como trojans. Segundo o relatório Desenvolvimento de ameaças de computador, elaborado pelo Kaspersky Lab, uns dos mais respeitados centros de estudos de ameaças digitais, foram identificadas 11 novas famílias de trojans e 55.679 novas modificações foram identificadas só no primeiro trimestre de 2017. Os maiores vetores de ataques são os navegadores Web, em segundo lugar o sistema operacional Android, em terceiro lugar estão os ataques focados em documentos do Microsoft Office. Os próximos vetores de ataques são as aplicações feitas com a linguagem de programação Java, aplicações envolvendo Adobe Flash e documentos em PDF.

 

Realmente o ano de 2017 foi a concretização de uma tendência de crescimento que começou em 2014. Época quando o número de dispositivos móveis começou a crescer assustadoramente em comparação com os anos anteriores e hoje não temos só a possibilidade de contaminar dispositivos móveis, mas também de atacar dispositivos ligados ao conceito de IoT. Segundo um estudo da GSMA Intelligence, o braço de pesquisa da GSMA, em 2020 teremos quase três quartos da população mundial conectada. Imagine o que aconteceria se estes dispositivos forem dominados por atacantes digitais.

 

E a cada ano as surpresas são mais devastadoras, estejam elas focadas em ransomware ou não. No final de 2016 vivenciamos o maior ataque digital deixando diversas empresa sem acesso internet atingindo 665Gbps de tráfego e mais de 130 milhões de pacotes por segundo para contaminar ambientes em mais de 164 países. Este ataque foi associado ao malware Mirai que envolveu mais de 500.000 dispositivos sob domínios dos atacantes digitais. O Brasil foi o segundo pais com maior concentração de computadores contaminados com o Mirai nesta época. A falha foi na ausência de procedimentos adequados que deveriam guiar a mudança da senha padrão dos usuários administrativos. Algo básico que deveria ser orientado de maneira automática pelos fabricantes de hardwares.

 

Muitas vezes para olhar o presente e validar o futuro devemos olhar para o passado. Em 2003, o mundo sofreu com o malware SQL Slammer, criado para explorar uma vulnerabilidade em ambientes Microsoft SQL Server 2000 desatualizados. No final de 2016 este ataque retornou a ocorrer com origem fundamentada nos países China, Vietnã, México e Ucrânia.

 

Com tudo isto em mente, como foi o ataque digital guiado pelo WannaCry criou cerca de 200.000 infecções em mais de 150 países e como ele continua a se espalhar? Primeiro precisamos observar que os computadores afetados exibiam mensagens com pedidos de resgate entre US$ 300 e US$ 600. O segundo elemento importante é que pesquisadores estimam a criação do WannaCry baseada na divulgação de uma vulnerabilidade (EternalBlue) pelo grupo de atacantes digitais Shadow Brokers. A vulnerabilidade possibilita a execução remota de código e foi corrida pela Microsoft em 14 de março de 2017 (MS17-010). Nesta época, a própria Microsoft considerou-a como crítica, afetando sistemas operacionais como Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8.1/8.1 TR, Windows Server 2012/2012 R2, Windows 10 e Windows Server 2016.

 

Sem dúvida que é um cenário mais do que crítico. Se olharmos com cuidado, veremos que existe algo em comum entre o os malwares SQL Slammer e o Mirai com o ransomware WannaCry. Vejo que além do componente humano, que por padrão adiciona centenas de falhas, existe a ausência de procedimentos para a análise e correção de vulnerabilidades. Observe que temos 14 anos desde a criação do SQL Slammer e o problema continua o mesmo, sendo tratado da mesma maneira por grande parte das empresas em diversos países ao redor do mundo. Esta é a verdadeira explicação de termos hoje algo tão devastador.

 

Por esta razão diversas empresas posicionadas na Espanha, Taiwan, Rússia, Portugal, Ucrânia, Turquia e Reino Unido foram afetadas pelo WannaCry. Segundo a própria Telefônica, 85% dos seus computadores em Madri foram contaminados, fazendo com que seus funcionários retornassem para casa a pedido da própria empresa. Imagine o prejuízo financeiro! Segundo o jornal valor Econômico, mais de 220 companhias com mais de 1,1mil computadores comprometidos foram alvo do WannaCry no Brasil.

 

Em 2014 escrevi um artigo descrevendo algumas ameaças presentes em SmartPhones e o mais incrível é que o discurso para a proteção pode ser aplicado ao cenário que temos hoje, mesmo sendo ele algo muito pior do que o existente em 2014. Segundo a Nokia Threat Intelligence Report, o mercado de malware para mobile banking está tão aquecido que cresceu 400% em 2016. Junte isto com a pesquisa da FGV mostrando que o Brasil já tem um smartphone para cada habitante (208 milhões de smartphones) e teremos um oceano de possibilidades para os terroristas digitais.

 

Se você está ainda não está preocupado com o WannaCry, deveria. E também deveria estar preocupado com o malware Adylkuzz, pois as previsões apontam para algo muito pior do que o WannaCry. Apesar de explorar as mesmas vulnerabilidades, o comportamento é diferente, não havendo bloqueio do acesso ao computador, usando o ambiente infectado como parte da sua botnet. Botnets podem conter centenas de milhares de computadores controlados remotamente com computadores prontos para responder a pedidos dos atacantes digitais.

 

Os desafios não são os mesmos, são bem maiores, mas os erros sim, são exatamente os mesmos cometidos no passado. Os erros cometidos pelas empresas de hoje são os mesmos cometidos a 14 anos atrás. Continuamos fornecendo artefatos, criando possibilidades gigantes para os atacantes digitais. Se você sente que vive em um momento de calmaria, possivelmente você se encontra no olho do furacão.  Vejo mais do que uma tempestade se aproximando, vejo um verdadeiro furação!

 

Denis Souza

 

Links indicados:

Ransomware móvel triplicou no primeiro trimestre de 2017

Ransomware e phishing estão no topo das ameaças corporativas

51% das empresas brasileiras foram vítimas de ataques ransomware no ano passado

O Adylkuzz é mais perigoso do que o WannaCry

Relatório sobre desenvolvimento de ameaças de computador

Grupo de atacantes ShadowBrokers

Prejuizo financeiro para as empresas com o WannaCry

Mais de 220 companhias são alvo de vírus no país

 

 

Como inserir Design Thinking na sua empresa

Olá,

Sou idealizador do Congresso Nacional de Design Thinking (CONATHINK) realizado durante o último mês de março. Ao total reunimos 29 experts de Design Thinking que ministraram 38 palestras ao longo de 7 dias.

Este evento me proporcionou contato com milhares de pessoas interessadas em inovação e um dos questionamentos que mais escutei durante os 7 dias do congresso foi referente a dificuldade de inserir a inovação dentro das empresas. Em 100% dos casos o maior ofensor apontado pelas pessoas foi a cultura avessa aos valores defendidos pelo Design Thinking.

Ok, nós sabemos que a cultura da maioria das empresas foi forjada no passado, onde os valores praticados eram outros, muitas vezes contrários aos valores defendidos pelo Design Thinking. Isto realmente acaba sendo uma barreira muito grande e difícil de ser superada pela maioria dos Design Thinkers que se aventuram nesta missão.

Mas existe um caminho ainda pouco praticado que pode te levar ao sucesso, mesmo que a cultura da sua empresa não esteja 100% alinhado com os valores defendidos pelo Design Thinking.

O segredo está em não tentar mudar a empresa e sim trabalhar a forma como você está tentando introduzir o Design Thinking neste ambiente. Quer saber como?

EXERCITE OS 3 PILARES DO DESIGN THINKING: empatia, colaboração e experimentação.

A minha sugestão para você conseguir realizar isto é aplicar o Design Thinking para implantar o Design Thinking?

Pode parecer estranho, mas este é um bom caminho a se seguir.

Vamos iniciar pelo 1º pilar, a empatia.

Se você avaliar um pouco mais a fundo verá que os stakeholders da sua empresa não são contrários ao Design Thinking ou a inovação em si. Você só deve identificar qual o verdadeiro motivo que está travando o processo, a famosa segunda camada.

Defina sua persona e aplique o mapa da empatia. Provavelmente você irá se deparar com problemas como alocação de pessoas, demandas que já chegam com uma solução definida, o medo de que as falhas da fase de prototipação tornem o projeto mais caro ou impacte na credibilidade do time, a dificuldade para garantir uma data já acordada com stakeholders e por aí vai.

A grande questão é que você tem que conhecer exatamente qual é a tua barreira, pois ter essa clareza que possibilitará planejar um plano de ação para superá-la.

É possível puxar esta frente sozinho, mas se você encontrar entusiastas da inovação que possam te apoiar nesta caminhada será muito bem-vindo. Aqui você estará trabalhando o 2º pilar, a colaboração.

Assim como em um projeto padrão do Design Thinking a colaboração gera um ambiente muito propício a inovação, pois a diversidade estimula a criatividade. Mas atenção, é fundamental que as pessoas recrutadas sejam entusiastas da inovação.

O 3º pilar é um dos mais importantes no processo de introduzir o Design Thinking em uma empresa e geralmente é ignorado. Antes de ‘vender’ o Design Thinking para sua empresa, experimente.

A melhor forma de experimentar neste caso é identificar um problema conhecido na tua empresa e trabalhar em sua solução aplicando o Design Thinking. E atenção, todas empresas possuem problemas conhecidos. Esta é a oportunidade que você terá para aplicar o Design Thinking sem ninguém te cobrar por uma data. Nesta fase isto é importante, pois o time ainda está se habituando ao Design Thinking e você precisará prototipar e testar quais caminhos deve seguir. Também é nesta etapa que você deve eliminar todas as objeções mapeadas no mapa da empatia.

Ao finalizar este projeto você terá seu 1º case de sucesso, que deverá ser usado para abrir portas para o Design Thinking na sua empresa, e deverá eliminar todas as objeções que seus stakeholders possuíam.

De forma breve este são os passos que eu indico para introduzir o Design Thinking na sua empresa.

 

Grande abraço,

Rodrigo Muniz

Como administrar melhor o tempo e prioridades

Nos dias atuais temos cada vez mais nos dedicado ao trabalho full time. Temos que nos policiar para não ficarmos o tempo todo olhando e-mails, redes sociais, através do celular, tablets etc..

O grande desafio que se coloca é como nesse mundo de informações e comunicação bidirecional, podemos selecionar o que de fato interessa.

Eu tenho um hábito de ler jornais todas as manhãs, primeiramente olho a 1ª. página para justamente selecionar as reportagens que me interessa. Depois vou direto nas seções que costumo ler diariamente.

Ora, essa mesma disciplina ao ler jornais, adoto ao selecionar as notícias que me interessam durante o dia. Entre uma reunião e outra, costumo olhar para o clipping de notícias para me atualizar.

Outra questão fundamental no dia a dia agitado que vivemos, é dar “prioridade ao prioritário”. Não perca tempo com questões periféricas ou de menor importância. Foque no que de fato interessa para o seu negócio.

Pense sempre antes de avaliar ou expor uma ideia em ser o mais sucinto possível, indo direto ao ponto. As vezes essa atitude pode ser interpretada como arrogante ou prepotente, mas nada mais é do que ganhar o que há de mais precioso: “tempo”.

Quando analisarmos oportunidades de negócio, aquisições ou novos produtos/serviços, buscamos sempre olhar benchmarks e trabalhar um business plan realista, mesmo porque se o negócio andar, certamente aquela base de informação e resultado previstos se tornarão metas a serem alcançadas objetivamente. Ou seja, essa mesma praticidade e realidade deve ser aplicada em avaliação de oportunidades.

A mensagem importante aqui é tente sempre se policiar para não desperdiçar tempo com coisas inúteis ou de pouca importância. Foque de fato naquilo que é fundamental e relevante, até para sobrar tempo para nós mesmos.

Alterando as permissões e notificações do seu projeto no JIRA

No post anterior já mostrei como customizar tipos diferentes de Issue para o projeto, assim como customizar ou melhorar os Workflows e também associá-los aos diferentes tipos de Issue.

Neste post, mostrarei algumas dicas para customizar permissões e notificações do projeto.

Assim como nos Schemes anteriores (Issue Type e Workflows), ao criar um projeto as permissões e notificações assumem uma configuração padrão, porém é possível alterá-las de acordo com a necessidade. A forma de criação de Permissões e Notificações é muito semelhante, portanto, ao visualizar a forma de adicionar permissões, basta “trocar” para a parte de notificações que o conceito será basicamente o mesmo.

  1. Visualizando as permissões

Ao acessar a administração do seu projeto, do lado direito vá até o item Permissions e clique no Scheme que estará como “Default Permission Squeme”. Na tela apresentada, perceba que o Scheme associado ao projeto, poderá estar compartilhado com vários outros projetos, veja:

 

 

Ao observar que há itens compartilhados com outros projetos, o cuidado na alteração de regras de permissões é redobrado, pois isso afetará os outros projetos que compartilham esse Scheme. É aí onde entra a customização de permissões específicas para o seu projeto.

  1. Criando um Squeme específico

Para criar um Scheme para o seu projeto, clique na engrenagem do canto superior direito do JIRA e logo após em Issues.

No menu esquerdo e no canto inferior, clique em Permission Schemes:

No fim da página exibida, clique no botão Add Permission Scheme Para mudar o Scheme, clique do lado direito superior no botão Actions e na próxima tela dê um nome e descrição para o Scheme a ser criado e clique em Add.

 

  1. Associando o Scheme criado ao projeto

Com o Scheme de permissões adicionado, você precisará agora associá-lo ao seu projeto e depois partir para a edição das permissões. Retorne a administração do projeto, e clique novamente no item Default Permission Scheme (conforme exibido no item 1). Ao lado direito superior, clique na engrenagem, clique em Actions e logo após em “Use a different Scheme”. Na tela exibida, selecione o Scheme criado anteriormente e clique em Associate.

 

 

  1. Editando as permissões

Após ter associado o Scheme de permissões criado, já é possível fazer a edição das permissões. Perceba que a tela exibida é semelhante à do Scheme default, mas agora é sua que está sendo apresentada. Para editar, na mesma engrenagem do lado direito superior, clique em “Edit Permissions”.

 

Para cada permissão há uma descrição de qual é a função da mesma. Para adicionar uma permissão clique do lado direito em Add. As permissões poderão ser adicionadas para Grupos, usuários específicos, Líder do projeto no JIRA, entre outros.

 

 

Adicionadas as permissões do projeto, você poderá alterar as notificações do mesmo conforme a sua necessidade também. A forma de fazer a criação e também a associação das permissões é muito semelhante, bastando voltar à administração do projeto e ao invés de ir na parte de permissões ir na parte de Notificações do projeto.

Espero mais uma vez que essas dicas o ajudem caso esteja utilizando essa ferramenta para o controle de suas atividades.

Até o próximo post 😉

[ ]´s

Melo

Oracle – O Lock TX

Falamos superficialmente sobre como os locks funcionam no Oracle, também de problemas frequentes com eles relacionados, como o lost update, block e o deadlock.

Agora é hora de olhar com um pouco mais de detalhe como as coisas funcionam internamente. Neste artigo vamos focar no lock TX e sua relação com as ITLs.

Mostraremos também uma nova feature do Oracle 12c com relação a permissão de leitura x lock.

DML Lock

Basicamente temos 3 classes de lock no Oracle que se subdividem:

– DML Lock

– DDL Lock

– Internal Lock e Latch.

DML (Data Manipulation Language) são instruções SQLs que se propõem a alterar determinado dado. Os locks deste tipo visam manter estas alterações consistentes mesmo que ocorram de forma “concorrente”. Mas note que não há alteração concorrente, então o melhor a se dizer é que os locks apenas gerenciam, de certa forma, a alteração por ordem de chegada.

Outro ponto importante é que, durante o tempo em que estamos alterando os dados, não seja permitido alterações estruturais ou em mesmo drop da tabela. O Oracle irá cuidar de tudo isso sem que você perceba ou, pelo menos, que você quase não perceba.

Lock TX

O termo TX está geralmente ligado a expressão “transaction” e é com isto que este tipo de lock está relacionado. Um lock TX é adquirido sempre que uma transação inicia e ela se inicia sempre que modificamos um dado (INSERT, UPDATE, DELETE, …) ou declaramos a intenção de alterá-lo (SELECT FOR UPDATE). Ela finalizará com um COMMIT ou um ROLLBACK.

Haverá apenas um lock TX independentemente do número de linhas, blocos ou tabelas que sua transação envolva. É importante notar que, mesmo assim, esta não é uma operação custosa. Diferente de outras implementações, o Oracle não centraliza a gestão de locks em estruturas como “lock manager”. Como dito no artigo anterior, o Oracle se baseia nas ITL (Interested Transaction List) de cada bloco para fazer esta gestão.

Desta forma, o lock estará sempre junto com o dado e ao consultá-lo (ou tentar alterá-lo) será possível descobrir se está livre. O melhor disto é que o caminho para ler ou modificar é o mesmo e direto, sem precisar passar por algum lock manager, diminuindo assim o overhead em momentos em que há muita alteração e muito locks.

Usaremos o famoso SCOTT para demonstração dos casos que veremos aqui. Então, se quiser reproduzir nosso teste, basta criá-lo em seu DB. Lembrando que estamos usando o 12c, que traz uma importante mudança com relação a permissão de leitura de dados e que citaremos ainda neste artigo.

Primeiro teste que faremos será verificar o número de linhas na v$lock versus o número de linhas alteradas. Vamos lockar uma linha da dept e em seguida todas as linhas.

SCOTT@orcl > select * from dept;

DEPTNO DNAME          LOC

———- ————– ————-

10 ACCOUNTING     NEW YORK

20 RESEARCH       DALLAS

30 SALES          CHICAGO

40 OPERATIONS     BOSTON

Ao realizar uma alteração (sem commit), podemos ver o lock.

SCOTT@orcl > update dept set loc = ‘SAO PAULO’ where DEPTNO = 40;

1 row updated.

SYS@orcl >

SELECT s.username,

l.sid,

trunc(l.id1 / power(2, 16)) undoseg,

bitand(l.id1, to_number(‘ffff’, ‘xxxx’)) + 0 slot,

l.id2 seq,

l.lmode,

l.request,

l.type,

l.block

FROM   v$lock     l

JOIN   v$session  s

ON     l.sid      = s.sid

WHERE  l.type     = ‘TX’

AND    s.username = ‘SCOTT’;

 

USERNAME      SID    UNDOSEG       SLOT        SEQ LMODE REQUEST TYPE  BLOCK

———- —— ———- ———- ———- —– ——- —– —–

SCOTT         245          5         13       2729     6       0 TX        0

 

E ao alterar todas as linhas com a mesma sessão:

SCOTT@orcl > update dept set DNAME = lower(DNAME);

4 rows updated.

 

Consultando a fila de locks:

SYS@orcl >/

USERNAME      SID    UNDOSEG       SLOT        SEQ LMODE REQUEST TYPE  BLOCK

———- —— ———- ———- ———- —– ——- —– —–

SCOTT         245          5         13       2729     6       0 TX        0

 

Ou seja, independente de alterar uma linha ou várias, o lock é feito por transação. Além disso, você deve ter notado que a query traz alguns campos “estranhos”. Eles servem exatamente para identificar a transação[1]. Veja só:

SYS@orcl >select XIDUSN, XIDSLOT, XIDSQN from v$transaction;

XIDUSN    XIDSLOT     XIDSQN

———- ———- ———-

5         13       2729

 

Não vamos entrar em muitos detalhes, mas para não deixar tão inexplicável, o Oracle possui duas colunas para registrar 3 informações: Undo segment number, slot e sequence, por isso precisamos desta manipulação.

O importante aqui é notar que o lock aponta para os mesmos valores de USN, SLOT e SQN da transação, então uma transação, um lock.

 

BLOCKs

 

Agora vamos conferir como os blocks funcionam. Alteramos (sem COMMIT) todas as linhas da tabela DEPT.

SCOTT@orcl > update dept set loc = ‘SAO PAULO’;

4 rows updated.

 

Temos todas as linhas lockadas, o que ocorre se outra transação tentar alterar alguma linha da DEPT?

Bom, como já era esperado, a sessão fica aguardando:

SCOTT@orcl > update dept set loc = ‘SAO PAULO’ where DEPTNO = 10;

Como fica a fila de locks na v$lock?

USERNAME      SID    UNDOSEG       SLOT        SEQ LMODE REQUEST TYPE  BLOCK

———- —— ———- ———- ———- —– ——- —– —–

SCOTT         421          4         24       2469     0       6 TX        0

SCOTT         244          4         24       2469     6       0 TX        1

 

Vemos uma informação interessante: A sessão com SID 244 que já possuía o lock, agora consta com BLOCK = 1 identificando que ela está fazendo alguém esperar.

A nova sessão (SID=421) fez um request de lock, mas sem sucesso. Veja que as informações a respeito da transação apontam para aquela que possui o lock.

É desta forma conseguimos identificar quem está locando quem.

SQL>

SELECT a.sid, ‘ is blocking ‘, b.sid

FROM   v$lock a

JOIN   v$lock b

ON     a.id1 = b.id1

AND    a.id2 = b.id2

WHERE  a.block = 1

AND    b.request > 0;

SID ‘ISBLOCKING’         SID

———- ————- ———-

244  is blocking         421

 

 

ITLs

 

E as ITLs, o que tem a ver com isso? Bom, agora o assunto fica um pouco mais interessante. Vamos precisar de um dump do bloco onde estão os dados da DEPT para entender. Além disso, para ilustrar o valor default do INITRANS, vamos ver como está na tabela:

SYS@orcl >

SELECT owner,

table_name,

ini_trans

FROM   dba_tables d

WHERE  d.table_name = ‘DEPT’

AND    d.owner      = ‘SCOTT’;

OWNER        TABLE_NAME       INI_TRANS

———— ————— ———-

SCOTT        DEPT                     1

 

Vamos identificar o block/datafile:

SYS@orcl >

SELECT DISTINCT dbms_rowid.rowid_block_number(ROWID) blk,

dbms_rowid.rowid_relative_fno(ROWID) file_no

FROM   scott.dept;

BLK    FILE_NO

———- ———-

181          6

 

Agora o dump do block:

SYS@orcl >alter session set tracefile_identifier=’ABONACIN’;

Session altered.

SYS@orcl >alter system dump datafile 6 block 181;

System altered.

 

O arquivo de trace será gerado no mesmo diretório do seu alert.

-rw-r—–. 1 oracle oinstall  197 Feb 26 13:30 orcl_ora_9742_ABONACIN.trm

-rw-r—–. 1 oracle oinstall 5.0K Feb 26 13:30 orcl_ora_9742_ABONACIN.trc

 

[oracle@hostlab trace]$ cat orcl_ora_9742_ABONACIN.trc

 

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc

0x01   0x0009.003.000005db  0x01000a41.00c1.21  C—    0  scn 0x0000.0018b4fb

0x02   0x0005.00d.00000aa9  0x0100073b.0254.34  —-    4  fsc 0x0000.00000000

 

Pode ser utilizado uma calculadora comum do Windows para constatar que AA9 hexa corresponde a 2729 decimal, 00d -> 13, 0005 -> 5, valores associados ao undo segment number, slot e sequence.

 

 

E o número 4 na coluna Lck, o que significa? Vamos seguir com os testes. Feito ROLLBACK, vamos alterar uma linha e fazer um dump.

SCOTT@orcl > update dept set loc = ‘Sao Paulo’ where deptno = 10;

1 row updated.

 

Locks:

USERNAME      SID    UNDOSEG       SLOT        SEQ LMODE REQUEST TYPE  BLOCK

———- —— ———- ———- ———- —– ——- —– —–

SCOTT         244          4         24       2469     6       0 TX        0

 

ITL:

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc

0x01   0x0009.003.000005db  0x01000a41.00c1.21  C—    0  scn 0x0000.0018b4fb

0x02   0x0004.018.000009a5  0x010007de.02a7.25  —-    1  fsc 0x0000.00000000

 

Vamos fazer o update na mesma transação, em outra linha.

SCOTT@orcl > update dept set loc = ‘Maringá’ where deptno = 20;

1 row updated.

 

Locks (continuamos com apenas um):

USERNAME      SID    UNDOSEG       SLOT        SEQ LMODE REQUEST TYPE  BLOCK

———- —— ———- ———- ———- —– ——- —– —–

SCOTT         244          4         24       2469     6       0 TX        0

 

ITL:

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc

0x01   0x0009.003.000005db  0x01000a41.00c1.21  C—    0  scn 0x0000.0018b4fb

0x02   0x0004.018.000009a5  0x010007de.02a7.26  —-    2  fsc 0x0000.00000000

 

E assim por diante. Veremos que esta coluna representa a quantidade de linhas deste bloco que estão lockadas por esta transação. Ao fazer um update nas 4 linhas:

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc

0x01   0x0009.003.000005db  0x01000a41.00c1.21  C—    0  scn 0x0000.0018b4fb

0x02   0x0004.018.000009a5  0x010007de.02a7.27  —-    4  fsc 0x0000.00000000

 

 

Como vimos, há duas ITLs neste bloco. O que significa que apenas duas transações podem alterá-lo simultaneamente. O que acontece se uma terceira transação tentar alterar uma linha da DEPT?

SCOTT@orcl > update dept set loc = ‘São Paulo’ where DEPTNO = 10;

1 row updated.

SCOTT@orcl > update dept set loc = ‘Maringá’ where deptno = 20;

1 row updated.

SCOTT@orcl > update dept set loc = ‘Salvador’ where deptno = 30;

1 row updated.

 

Os locks foram obtidos, como é possível?

USERNAME      SID    UNDOSEG       SLOT        SEQ LMODE REQUEST TYPE  BLOCK

———- —— ———- ———- ———- —– ——- —– —–

SCOTT         421          7         23       2490     6       0 TX        0

SCOTT         244         10         19       3574     6       0 TX        0

SCOTT         127          8         17       2844     6       0 TX        0

 

Vamos ver novamente o dump do bloco. Com isso, vemos que agora temos três ITLs.

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc

0x01   0x0007.017.000009ba  0x01000504.02bb.12  —-    1  fsc 0x0000.00000000

0x02   0x000a.013.00000df6  0x010006fc.035e.2a  —-    1  fsc 0x0000.00000000

0x03   0x0008.011.00000b1c  0x01000c33.02a1.05  —-    1  fsc 0x0000.00000000

 

Pontos importantes sobre isso são:

– As ITLs não sofrem shrink. Uma vez criadas, permanecerão no bloco.

– O bloco é criado com duas (ou o valor definido pela INITRANS) e utilizam o espaço livre do bloco caso mais transações concorram no mesmo bloco.

– O valor máximo é de 255, independentemente de haver espaço livre ou não.

Vamos ilustrar também este último ponto. Criamos uma tabela com linhas curtas para que ocupem apenas um bloco e uma tablespace com bloco de 32k.

SQL> alter system set db_32k_cache_size=100M;

System altered.

 

SQL> create tablespace TESTEITL datafile ‘/u01/app/oracle/oradata/orcl/testeitl01.dbf’ size 100M BLOCKSIZE 32K;

Tablespace created.

 

SCOTT@orcl >

CREATE TABLE tb_itl

(col_id  INT,

col_txt VARCHAR2(10)) TABLESPACE TESTEITL;

Table created.

 

SCOTT@orcl >

INSERT INTO tb_itl

SELECT rownum, ‘A’

FROM   dual

CONNECT BY LEVEL <= 300;

300 rows created.

 

SCOTT@orcl > COMMIT;

Commit complete.

 

SCOTT@orcl >

SELECT dbms_rowid.rowid_block_number(ROWID) blk,

dbms_rowid.rowid_relative_fno(ROWID) file_no,

count(*)

FROM   scott.tb_itl

GROUP  BY dbms_rowid.rowid_block_number(ROWID) ,

dbms_rowid.rowid_relative_fno(ROWID);

BLK    FILE_NO   COUNT(*)

———- ———- ———-

35          7        300

Ou seja, as 300 linhas estão no mesmo bloco. Um dump inicial irá mostrar apenas 2 ITLs e após nosso teste, veremos 255.

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc

0x01   0x0020.002.00000002  0x01000772.0000.04  –U-  300  fsc 0x0000.0032f0aa

0x02   0x0000.000.00000000  0x00000000.0000.00  —-    0  fsc 0x0000.00000000

 

Agora vamos fazer uma “manobra” para que sejam alteradas 300 linhas por transações diferentes. O teste consiste em abrir recursivamente uma AUTONOMOUS TRANSACTION. Esperamos que após 255 transações não seja mais possível que isto ocorra. Usaremos a procedure abaixo para isso.

CREATE OR REPLACE PROCEDURE do_update(pnLinha IN NUMBER) AS

PRAGMA        AUTONOMOUS_TRANSACTION;

vrItl         tb_itl%ROWTYPE;

veResBusy     EXCEPTION;

PRAGMA        EXCEPTION_INIT(veResBusy, -54);

BEGIN

–fazemos select for update para lockar a linha com col_id = pnLinha

SELECT *

INTO   vrItl

FROM   tb_itl

WHERE  col_id = pnLinha

FOR    UPDATE NOWAIT;

 

–chamamos recursivamente para update da linha com col_id = pnLinha + 1

do_update(pnLinha + 1);

 

COMMIT;

EXCEPTION

WHEN veResBusy THEN

dbms_output.put_line(‘Nao conseguimos lockar a linha de col_id: ‘ || pnLinha);

COMMIT;

WHEN no_data_found THEN

dbms_output.put_line(‘Todos os registros foram lockados.’);

COMMIT;

END;

/

 

Resultado:

SCOTT@orcl > exec do_update(1);

Não conseguimos lockar a linha de col_id: 256

PL/SQL procedure successfully completed.

 

E por fim, conferindo as ITLs:

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc

0x01   0x0033.002.00000002  0x010008a2.0000.03  –U-    1  fsc 0x0000.0032f7a1

0x02   0x0032.002.00000002  0x01000892.0000.03  –U-    1  fsc 0x0000.0032f7a3

0xfe   0x00fe.000.00000002  0x010017d2.0000.01  –U-    1  fsc 0x0000.0032f645

0xff   0x00ff.000.00000002  0x010017e2.0000.01  –U-    1  fsc 0x0000.0032f643

 

GRANT READ

 

Por fim, vamos falar de um privilégio novo do Oracle 12c relacionado com lock, o GRANT READ. Em versões passadas, tínhamos apenas o grant de SELECT. O problema é que o privilégio de SELECT permite o SELECT FOR UPDATE e embora alguém pudesse apenas “ler” o registro, podia declarar o interesse de alterá-lo, causando o lock.

O Oracle 12c traz esta new feature. Vejamos como funciona, de forma simples. Concedemos privilégio de SELECT para um user e de READ para outro e comparamos o resultado.

SCOTT@orcl > grant select on dept to hr;

Grant succeeded.

 

SCOTT@orcl > grant read on dept to oe;

Grant succeeded.

 

SCOTT@orcl > conn hr/hr

Connected.

 

HR@orcl > select * from scott.dept for update;

 

DEPTNO DNAME          LOC

———- ————– ————-

10 ACCOUNTING     SAO PAULO

20 RESEARCH       DALLAS

30 SALES          CHICAGO

40 OPERATIONS     BOSTON

 

HR@orcl > conn oe/oe

Connected.

 

OE@orcl > select * from scott.dept for update;

select * from scott.dept for update

*

ERROR at line 1:

ORA-01031: insufficient privileges

 

CONCLUSÃO

 

Finalizamos mais uma parte da nossa análise e ainda temos bastante assunto pela frente. Falamos de propriedade de ITL e qual a relação entre os locks TX e ITL.

 

Ficarão para os próximos artigos o lock TM e os de DDL, além de outras coisas como leitura consistente, multi versões que uma linha pode ter.

 

 

[1] https://docs.oracle.com/database/121/REFRN/GUID-FAE908F8-24B1-4B90-8FC5-86FCB532431C.htm#REFRN30291

[2] Oracle Database Transactions and Locking Revealed, Thomas Kyte, Darl Kuhn, 2014

 

 

4 fatores importantes sobre nuvem e continuidade de negócios que você precisa saber agora mesmo

Os departamentos de TI estão sob constante pressão para disponibilizar novas tecnologias que permitam que a empresa mantenha dados críticos, aplicações, processos seguros e em funcionamento 24 x 7.

Some a isto ofertas de nuvem que permitem que a empresa terceirize parte da responsabilidade pela gestão e garantia de segurança e confiabilidade e temos o ambiente perfeito para a continuidade de negócios e recuperação de desastres ser deixada para segundo plano frente aos desafios do dia-a-dia de gerenciamento de TI.

Ao utilizar serviços baseados na nuvem é fácil perder de vista os principais riscos de continuidade de negócios e por isso listamos aqui 4 pontos importantes que você deveria ter em mente enquanto utiliza cloud computing para sua empresa.

 

1. Continuidade de negócios é mais que recuperação de desastres

A indústria é permeada com termos como “continuidade de negócios” e “recuperação de desastres”, o que pode torná-lo confuso para os líderes empresariais. Mesmo o termo “recuperação de desastres” leva a maioria dos profissionais de TI para o caminho errado.

Soluções de DR são normalmente utilizadas para “cenários de desastres” e “desastres” relacionados a causas naturais não são a causa mais comum de interrupção de TI.

Falhas de software, hardware e erro humano são as principais categorias responsáveis ​​por algum tipo de interrupção no negócio.

As empresas precisam de parar de pensar apenas em desastres e começar a considerar maneiras de evitar interrupções.

 

2. As nuvens nem sempre incluem alta disponibilidade e / ou garantia de continuidade de negócios

A todo momento o serviço de nuvem é entregue a partir de um Data Center.

Se esse Data Center tiver problemas, o fornecedor de nuvem pode mover suas cargas de trabalho rapidamente para um novo Data Center?

Sempre verifique como a empresa lida com isto para poder decidir como se preparar para isto.

Muitas vezes os players de nuvem pública disponibilizam maneiras de garantir a continuidade de negócios utilizando replicação de dados em Data Centers localizados em regiões distintas.

Fique atento: este recurso não é padrão na oferta de nuvem e precisa ser configurado individualmente na maioria dos casos.

 

3. A localização dos servidores garante mais do que latência

A nuvem não é um lugar mágico – onde seus arquivos são armazenados fisicamente realmente importa.

A localização dos servidores da nuvem pode afetar a velocidade de acesso e preços, mas é um erro pensar em localização apenas por este prisma.

Quando falamos em continuidade de negócios, localização em região diferente da principal e eventualmente o uso de fornecedores distintos realmente é algo a ser considerado.

 

4. Backup nem sempre é parte da oferta padrão

Fornecedores de nuvem nem sempre oferecem backup de dados armazenados dentro das métricas necessárias para o negócio de sua empresa.

Alguns fornecedores sequer oferecem backup dos dados como parte padrão de sua oferta.

Por padrão assuma que o fornecedor não oferece garantias e verifique com o mesmo como ele lida com backup, antes de definir um plano para isto.

 

Continuidade de negócios é um tema importante para você?

Se você quiser discutir os cenários de continuidade de negócios, com garantia de alta disponibilidade, segurança e conectividade integradas às ofertas em nuvem, entre em contato conosco pelo telefone (11) 3092 6161 ou pelo nosso formulário de contato.

 

LOCKS – Oracle

Quem trabalha com banco de dados relacionais já deve ter tido problema com Locks diversas vezes. Podem deixar apps lentas, deixá-las completamente paradas, e naturalmente vem a dúvida: por que precisamos deles?

Eles não são tão ruins assim e ao final espero que entenda que eles são, na verdade, indispensáveis. São quem permitem que sistemas multi-users possam ser escaláveis de forma consistente. Atuam para que apenas uma transação de cada vez possa alterar um determinado dado, formando uma fila com todos que tem esta intenção.

Imagine você alterando uma linha da tabela de empregados. Enquanto pretendia alterar o “salário”, outra pessoa foi e alterou o “nome” do mesmo registro. Embora não pareça algo muito preocupante, você consegue imaginar a “bagunça” quando várias sessões tentam alterar o dado ao mesmo tempo? E no caso de alguém que queira aumentar 1.000 no salário e outra aumentar 10%: a ordem de execução vai afetar o resultado final.

Enfim, para começar é importante entender que Lock é a forma que o banco de dados tem de organizar as transações e se manter consistente. Alterações nas tabelas respeitam a ordem de chegada. Chegou primeiro, atualiza primeiro. Chegou depois e tem alguém atualizando? Espere até a conclusão. E aqui nascem os problemas.

Neste artigo tentaremos mostrar um pouco de como os Locks funcionam. Não dá para se falar de maneira global porque cada banco de dados acaba implementando de forma diferente, então focaremos na implementação do Oracle. Há, obviamente, vários conceitos relacionados e vamos tratando deles no decorrer do artigo. Como tem assunto para um livro, vamos dividir em uma pequena série de artigos.

Aqui falaremos de conceitos como transações e seu papel no contexto da aplicação. Também abordaremos um problema comum de apps multi-users, os chamados lost updates. Em seguida vamos para os problemas relacionados ao banco de dados como bloqueios, uma estrutura do cabeçalho do bloco de dados chamado ITL e deadlock.

Nos próximos artigos desta série, vamos mergulhar um pouco mais para descobrir como o Oracle trabalha internamente para gestão de Locks e transações e também como ele trata as multi versões de uma linha.

 

TRANSAÇÃO

 

Primeiramente, vamos entender como um banco de dados é alterado e o que há de especial nesta mudança. Parece simples, não?

SQL> update hr.employees set FIRST_NAME = ‘Adriano’, LAST_NAME = ‘Bonacin’ where EMPLOYEE_ID = 206;

1 row updated.

Neste momento (até o commit ou rollback) o banco de dados, de maneira simplificada:

– Está protegendo esta linha para que ninguém a altere;

– Protegendo a tabela para que ninguém a drope;

– Criou uma forma de desfazer a alteração;

– Criou uma forma para refazer.

E tudo isto depois de verificar se havia espaço livre na tabela, se eu tinha permissão para fazer a alteração, entre outras coisas.

Por default, o Oracle não confirma a alteração, embora seja otimizado para isso (e não para rollbacks). Assim, é importante garantir que o commit seja efetuado para não deixar o registro bloqueado. Que fique claro, porém, que as apps também podem ter uma arquitetura que já faça a alteração e o commit automaticamente.

Quando efetuado o commit e recebido o OK do banco de dados, um DB (A C I D) garante que a partir daquele momento seu dado não será mais perdido (Durabilidade). Você ainda pode perder o banco de dados inteiro, mas aí é outra conversa.

Resumindo, chamamos de transação esta operação de iniciada com um update (ou insert, delete, …) e finalizada com commit (ou rollback) que leva o DB de um estado consistente a outro.

 

LOST UPDATES

 

Tratando de transações e Locks do ponto de vista da aplicação, um problema comum ocorre quando vários usuários podem alterar o mesmo dado, o chamado de lost update (alteração perdida). Considere o cenário abaixo como exemplo:

1 – O usuário A consulta os dados do cliente 1 para ajustar seu endereço.

2 – O usuário B consulta os dados do mesmo cliente 1 para também ajustar o endereço.

3 – O usuário A altera o endereço para “Av Brigadeiro Faria Lima”.

4 – O usuário B altera o endereço para “Av Brigadeiro F Lima”.

Qual o resultado final? O último? O primeiro? Um mix?

Para aumentar a possibilidade trabalhar em concorrência (escalabilidade) sem estes conflitos (de perder alterações), geralmente apps usam diferentes metodologias: “Lock Pessimista” e “Lock Otimista”.

Basicamente:

– Pessimista: declaramos (Lock) que vamos alterar o dado (select for update) quando o consultamos. O próximo que tiver intenção de alterar, fica aguardando.

– Otimista: lemos o dado sem o Lock e garantimos na hora da alteração que ele estava exatamente como lemos (outra sessão pode ter alterado entre ler e alterar).

 

BLOCKs

 

Este é o principal efeito negativo, quando uma sessão possui um Lock de determinado dado e outra faz o request do mesmo. A sessão que chegou depois ficará aguardando (completamente congelada) até que o dado solicitado seja liberado.

Os bloqueios podem ocorrer com SELECT FOR UPDATE, quando duas sessões consultam alguma linha em comum. Neste caso, há uma cláusula NOWAIT que pode ser adicionada e a segunda sessão tomará um erro ao invés do block.

No caso dos INSERTS, há dois cenários em que ocorrem comumente. No primeiro, a tabela deve ter PK ou algum outro índice único e ambas as sessões estão tentando inserir a mesma chave. No segundo, duas tabelas devem ter FK e o insert na filha ocorre enquanto outra sessão inseriu na tabela pai (mas ainda não comitou).

Com UPDATEs, DELETEs e MERGEs, a prevenção seria a melhor forma estar livre. Tentar lockar a linha antes da alteração com SELECT FOR UPDATE NOWAIT e só então concluir a manipulação do dado.

 

LOCK ESCALATION

 

Um outro termo que talvez você veja por aí, mas que não ocorre com o Oracle, é o Lock Escalation. Em alguns DBs a forma de gestão de lock depende de um Lock Manager. Uma estrutura de tabela em memória que registra as alinhas que estão lockadas.

Porém, quando o número de linhas lockadas de uma mesma tabela é consideravelmente grande, o DB prefere escalar o lock para o bloco/tabela inteira. Fica mais fácil para gestão, mas provavelmente teremos linhas lockadas sem a real necessidade.

O Oracle não usa este tipo de gerenciamento de lock. Para lockar uma linha, o Oracle vai até o DB Block e armazena ali a transação que alterou (ou tem a intenção de) a linha, independentemente do número de linhas. Será sempre assim, nunca haverá o Lock Escalation.

 

ITL

 

Interested Transaction List (ITL) são estruturas do cabeçalho do bloco (DB block header) onde são armazenadas as transações que desejam alterar linhas daquele bloco. É ocupada uma entrada por transação e não por linha lockada. Assim, uma transação pode lockar 300 linhas do bloco que apenas uma entrada das ITLs será utilizada.

Associado a isso, estão os eventos de espera como o “enq: TX – allocate ITL entry” que ocorre quando a requisição de alterações no mesmo bloco por transações (sessões) diferentes é alta.

As ITLs estão diretamente relacionadas com os parâmetros INITRANS e MAXTRANS dos segmentos, que representam o número mínimo e máximo de transações ocorrendo no mesmo bloco. Após escolher o número mínimo, este valor pode crescer se houver espaço livro no bloco.

INITRANS: Número de entradas iniciais do bloco, cujo default é 2 (mesmo que você solicitar 1).

MAXTRANS: Número máximo de transações, que desde o Oracle 10g é 256.

Uma conclusão imediata disto é que não será possível mais que 256 transações por bloco, embora este seja um número mais do que adequado na grande maioria das vezes.

 

 

DEADLOCKs

 

Os deadlocks são no mínimo assustadores, mas é a forma que o DB tem de evitar locks cíclicos. Veja o cenário abaixo:

– Sessão A possui lock no empregado 200

SQL> select EMPLOYEE_ID, FIRST_NAME, LAST_NAME from employees where EMPLOYEE_ID=200 for update;

EMPLOYEE_ID FIRST_NAME           LAST_NAME

———– ——————– ————————-

200 Jennifer             Whalen

– Sessão B possui lock no departamento 200

SQL> select DEPARTMENT_ID, DEPARTMENT_NAME from departments where DEPARTMENT_ID = 200 for update;

DEPARTMENT_ID DEPARTMENT_NAME

————- ——————————

200 Operations

– Sessão A tenta lockar o departamento 200 (lockado por B)

SQL> select DEPARTMENT_ID, DEPARTMENT_NAME from departments where DEPARTMENT_ID = 200 for update;

… fica congelada

– Sessão B tenta lockar o empregado 200 (lockado por A)

SQL> select EMPLOYEE_ID, FIRST_NAME, LAST_NAME from employees where EMPLOYEE_ID=200 for update;

… fica congelada

 

Veja o que ocorreu com a sessão A:

select DEPARTMENT_ID, DEPARTMENT_NAME from departments where DEPARTMENT_ID = 200 for update

*

ERROR at line 1:

ORA-00060: deadlock detected while waiting for resource

No alert do DB é registrado este evento:
ORA-00060: Deadlock detected. See Note 60.1 at My Oracle Support for Troubleshooting ORA-60 Errors. More info in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_32577.trc.

E a informação no trace (apenas algumas partes):

*** 2017-02-12 10:21:29.714

*** SESSION ID:(241.57407) 2017-02-12 10:21:29.714

*** MODULE NAME:(SQL*Plus) 2017-02-12 10:21:29.714

*** CLIENT DRIVER:(SQL*PLUS) 2017-02-12 10:21:29.714

DEADLOCK DETECTED ( ORA-00060 )

See Note 60.1 at My Oracle Support for Troubleshooting ORA-60 Errors

[Transaction Deadlock]

The following deadlock is not an ORACLE error. It is a

deadlock due to user error in the design of an application

or from issuing incorrect ad-hoc SQL. The following

information may aid in determining the deadlock:

—– Information for the OTHER waiting sessions —–

current SQL:

select EMPLOYEE_ID, FIRST_NAME, LAST_NAME from employees where EMPLOYEE_ID=200 for update

—– End of information for the OTHER waiting sessions —–

 

Information for THIS session:

—– Current SQL Statement for this session (sql_id=1fu1jghcq3ydc) —–

select DEPARTMENT_ID, DEPARTMENT_NAME from departments where DEPARTMENT_ID = 200 for update

Como se pode ver, o trace traz algumas informações importantes na investigação do que pode ter ocorrido. A principal é o SQL que a minha sessão tentou executar e não conseguiu.

Em apps de grande porte, casos comuns de deadlock são com FK não indexadas. Quando se altera/exclui dados da chave na tabela pai, o Oracle coloca lock full nas tabelas filhas que não possuem índice nos mesmo campos. Com a tabela inteira lockada, a chance de alguém precisar destes dados é maior.

O fato que talvez cause uma certa estranheza em quem nunca se aprofundou no assunto é que este lock full ocorre apenas durante a execução do DML na tabela pai e não durante toda a transação.

Para ilustrar, vamos usar o seguinte cenário:

– Table pai: hr.departments (PK: department_id)

– Table filha: hr.employees (FK: department_id)

– por default, há um índice na hr.employees.department_id. Foi dropado: DROP INDEX EMP_DEPARTMENT_IX;

Se o lock durar apenas durante o DML na pai, poderemos lockar uma linha na filha após a conclusão.

SESSAO 1> DELETE departments d WHERE  d.department_id = 170;

1 row deleted.

Elapsed: 00:00:00.00

SESSAO 2> select EMPLOYEE_ID, FIRST_NAME, LAST_NAME from employees where EMPLOYEE_ID=200 for update;

EMPLOYEE_ID FIRST_NAME           LAST_NAME

———– ——————– ————————-

200 Jennifer             Whalen

Elapsed: 00:00:00.01

Ok, conforme esperado. E como podemos então perceber este lock que dura 00:00:00.00 s? Bom, neste caso, se já houver algum registro lockado na filha, não será possível concluir o DML na pai. Faremos rollback nas duas e começaremos na ordem inversa.

SESSAO 2> select EMPLOYEE_ID, FIRST_NAME, LAST_NAME from employees where EMPLOYEE_ID=200 for update;

EMPLOYEE_ID FIRST_NAME           LAST_NAME

———– ——————– ————————-

200 Jennifer             Whalen

Elapsed: 00:00:00.00

SESSAO 1> DELETE departments d WHERE  d.department_id = 170;

… aguardando

Sempre devemos indexar as colunas das FKs? Não necessariamente. De forma simplificada, se você faz join com pai e filha e/ou pensa em alterar a chave (ou excluir) de uma tabela pai, é importante que na filha exista um índice.

 

CONCLUSÃO

 

Falamos um pouco de pontos positivos e negativos do lock. Negativos quando nos geram problemas de performance, positivos quando nos garantem a consistência dos dados. Falamos também de alguns fenômenos relacionados como o Lost Update, Blocks e Deadlocks.

Após esta breve introdução sobre o conceito, nos artigos seguintes aprofundaremos um pouco. Falaremos do tipo de lock, modo de lock tanto para DML como DDL. Revisitaremos o assunto das FKs, com uma riqueza maior de detalhes.

Até lá!

Adriano Bonacin