Virtus Junxit Mors Non Seperabit

Integridade de arquivos

Calculo do hash do arquivo original e comparar com o hash do arquivo baixado.

O cálculo de hashes de arquivos tem sido utilizado desde há muito tempo para verificar se um arquivo está íntegro ou não. O mais famoso deles é o MD5.

Provavelmente já encontrou pela internet quando você estava prestes a baixar o instalador de uma aplicação.

O conceito e simples. Juntamente com o arquivo que será baixado, o fabricante ou desenvolvedor disponibiliza também a representação em texto do hash daquele arquivo.

Depois do download ser concluído, o usuário que baixou o arquivo pode utilizar algum utilitário (online ou programa desktop) para calcular o hash do arquivo baixado e, se ele for idêntico com o hash disponibilizado na hora do download,  significa que o arquivo foi baixado de forma íntegra. Este processo serve para detectarmos que o arquivo não foi modificado maliciosamente no meio do caminho.

Lembrando que uma falha no algoritmo do MD5 descoberta em 2012 fez com que esse tipo de hash fosse descartado para fins de criptografia e integridade. Apesar disso, ele ainda continua sendo muito utilizado.

Por exemplo, se você algum dia precisar baixar o Apache Server, verá que eles ainda disponibilizam o hash MD5 para verificação da integridade dos arquivos.

MD5 foi substituído pelo SHA (SHA-1 e SHA-256).

Independente do algoritmo de hash utilizado, a ideia é sempre a mesma. Em algum lugar junto com o download do arquivo nós temos o seu hash. Uma vez concluído o download, podemos então calcular o hash do arquivo baixado para verificarmos se ele bate com o disponibilizado pela fonte do download. E assim sabemos se o arquivo foi baixado integralmente ou não.

Existem diversas ferramentas que fazem o cálculo do hash de arquivos. Em ambientes Unix, a ferramenta mais conhecida é a hashdeep. Já no Windows, se você quiser uma ferramenta confiável, eu recomendo o Microsoft File Checksum Integrity Verifier. E se você não quiser instalar ferramenta nenhuma, você pode utilizar também o neste site TGB, que faz o cálculo dos hashes via web tendo opção de baixar versão desktop (offline).

Imprimir Email

16 dicas para uma mudança suave para Agile

Se a sua empresa está interessada em mudar para o gerenciamento ágil de projetos, aqui estão algumas estratégias para ajudar a suavizar a transição

Mudar para um gerenciamento ágil de projetos pode aumentar consideravelmente as perspectivas de sucesso. A metodologia, que utiliza ciclos curtos para fornecer melhoria contínua no desenvolvimento de um produto ou serviço, está sendo usada em muitos setores devido a seus processos altamente colaborativos e eficientes.

Mas, uma vez que sua organização tenha avaliado as opções e tomado a decisão de mudar para a Agile, como garantir uma transição tranquila, que beneficie tanto a própria empresa quanto seus clientes? As dicas e estratégias a seguir ajudarão, aumentando consideravelmente as chances de sua organização realizar uma mudança sem traumas.

1 - Identifique e documente seus objetivos de negócios

Antes de adotar uma nova metodologia de gerenciamento de projetos é importante identificar e documentar suas metas de negócios e estabelecer como a mudança para uma nova metodologia permitirá que você atinja essas metas. A análise de negócios garante que as metodologias empregadas sejam eficazes para ajudar a alcançar os objetivos da empresa. Deve haver uma linha clara entre as metodologias usadas e como elas ajudam as equipes de projeto a atingir as metas de negócios.

2 - Analise a hierarquia e a cultura da sua empresa

Nem todas as organizações podem se beneficiar de metodologias ágeis, por isso é importante mapear a hierarquia da sua empresa para entender melhor sua capacidade de oferecer suporte a uma mudança para o ágil. Determine primeiro se você tem o talento necessário para atender aos compromissos de desenvolvimento ágil e uma hierarquia que possa suportar práticas ágeis.

Outro fator importante é a sua cultura . Sua cultura atual pode apoiar a metodologia ágil? Isso pode se tornar um dos maiores obstáculos em fazer a troca. Se a sua empresa estiver executando projetos usando a metodologia waterfall  por um período de tempo significativo, pode haver uma certa relutância por parte de vários grupos em mudar para o ágil. A cultura da sua empresa precisará suportar essa mudança. É aqui que especialistas em gerenciamento de mudanças e uma comunicação clara e frequente podem facilitar o caminho.

3 - Analise o impacto em seus clientes

Se mudar as metodologias de gerenciamento de projetos é algo que provocará um impacto negativo em seus clientes, não vale a pena fazê-lo. Portanto, você precisará identificar as necessidades e metas de seu cliente e determinar se e como a agilidade ajudará suas equipes de projeto a atender melhor às necessidades desse cliente. Para fazer isso, você precisará responder a estas perguntas:

  1. Como a mudança para Agile melhora a experiência do cliente?
  2. A mudança para Agile produzirá maior qualidade e melhores resultados?
  3. A agilidade ajudará a criar uma melhor colaboração entre sua equipe e os clientes?

4 - Faça um balanço de todos os recursos disponíveis

Identifique e documente todos os recursos do projeto disponíveis. Determine se sua empresa possui os conjuntos de talentos e as habilidades necessários para agilizar o trabalho. Identifique as tecnologias disponíveis e os fornecedores que podem suportar a mudança para Agile com sucesso. Sem as pessoas e as tecnologias certas, é muito improvável que a mudança para Agile produza os benefícios previstos.

5 - Determine como a mudança para Agile mudará os processos

Depois de identificar suas metas, hierarquia e cultura de negócios, as necessidades das partes interessadas e os recursos, é hora de detalhar exatamente como sua equipe fará a transição da metodologia atual para Agile e como isso afetará seus processos internos. Lembre-se de aproveitar o conhecimento e a experiência de um especialista em gerenciamento de mudança desde o início e durante todo o processo.

6 - Mapeie suas estratégias e execução de gerenciamento de projetos existentes

Faça uma comparação entre suas metodologias atuais de gerenciamento de projetos e o gerenciamento ágil. Identifique possíveis pontos de risco e analise o estado de preparação da sua equipe de projeto para lidar com problemas que possam surgir com a troca.

7 - Construa um caso de negócio e receba sugestões das principais partes interessadas

Agora que você cobriu os benefícios do negócio, do projeto e do cliente, bem como os riscos e a logística em torno da migração para o ágil, será necessário criar um caso de negócios que garanta que outras partes interessadas tenham uma oportunidade de entrada. Sem informações suficientes dos principais interessados, insights valiosos necessários para transformar a mudança para Agile podem ser perdidos.

8 - Documente o plano de transição e solicite feedbacks

Uma vez que o sinal verde tenha sido dado para mudar para Agile, monte um plano abrangente de gerenciamento de projeto e, mais uma vez, receba feedbacks das principais partes interessadas, incluindo áreas funcionais, antes de prosseguir. Isso dá aos principais participantes a oportunidade de fornecer informações adicionais que podem afetar como e quando a transição para Agile ocorre e oferece aos patrocinadores e às partes interessadas uma maior sensação de garantias de que a mudança para Agile será bem-sucedida.

9 - Recorra à ajuda de um especialista em gerenciamento de mudança desde o início

Mudar para uma nova metodologia é um passo importante que impactará pessoas, processos e como a tecnologia é alavancada. Certifique-se de envolver um especialista em gerenciamento de mudanças desde o início para ajudá-lo a determinar quais são essas mudanças e como lidar melhor com elas, sem que questões vitais fiquem pelo caminho.

10 - Aproveite as experiências de empresas ou especialistas que migraram para Agile

Antes de mudar para o gerenciamento ágil de projetos, pode ser uma boa ideia conversar com outros profissionais sobre suas experiências. Isso pode poupar muita frustração e reduzir as chances de cometer erros caros no processo.

Agile

11 - Monte uma equipe de projeto multifuncional
Certifique-se de envolver especialistas e principais partes interessadas de várias áreas funcionais ao fazer uma mudança significativa como essa. Sua contribuição será necessária para ganhar o buy-in e evitar problemas imprevistos.

12 - Pilote alguns projetos diferentes antes de pular com os dois pés

Considere pilotar um projeto ou dois primeiro. Isso permite que você veja se suas equipes estão suficientemente preparadas para executar projetos usando metodologias ágeis antes de fazer a troca completa. Isso ajudará você a fazer os ajustes necessários em uma escala menor antes de uma transição completa.

13 - Receba feedback sobre como as coisas estão indo

É importante obter feedbacks da equipe do projeto, dos grupos funcionais e de quaisquer outras partes interessadas para identificar como as coisas estão evoluindo e determinar se Agile é a metodologia certa para outros projetos.

14 - Revisite tecnologias e processos

Ao mudar para uma nova metodologia, revisite as tecnologias e processos que você usa atualmente para determinar as mudanças necessárias e envolva um especialista em gerenciamento de mudanças para garantir que nada seja perdido. Ambas as áreas afetarão a maneira como você executa os projetos e vice-versa. Uma mudança em uma nova metodologia exigirá revisitar as tecnologias que você usa, bem como adaptar seus processos existentes.

15 - Faça o movimento para Agile

Supondo que tudo tenha corrido bem, a migração foi finalizada e todos estão envolvidos, é hora de mudar completamente para o gerenciamento ágil de projetos. Para manter a adesão ao longo do switch, a comunicação frequente e transparente é fundamental para garantir a transição e assegurar que todas as partes interessadas estejam atualizadas com o progresso e os desenvolvimentos.

Imprimir Email

Aplicativo revela se seu PC está vulnerável às falhas Meltdown e Spectre

Chamada InSpectre, solução da Gibson Research faz uma varredura rápida para descobrir se o computador recebeu os patches necessários contra as ameaças.

As informações mais importantes que você precisa saber sobre as sérias falhas de CPU Meltdown e Spectre não são se o seu PC é inerentemente vulnerável a elas – porque ele é – mas se o seu sistema recebeu patches de proteção contra as falhas. No entanto, descobrir isso não é algo muito fácil. 

É preciso navegar por logs de updates, cruzá-los com identificadores de vulnerabilidades e códigos da Microsoft – ou pelo menos era assim. A Gibson Research lançou recentemente a InSpectre, uma ferramenta simples que detecta se o seu PC está vulnerável ao Meltdown e ao Spectre. 

O InSpectre é um programa “pequeno”, de 112kb, que não exige uma instalação formal e verifica o seu computador em busca de suscetibilidades em milissegundos. Quando finaliza o processo, o programa abre uma janela com informações claras e fáceis de serem lidas sobre o status de segurança do seu sistema. 

Descer a barra de navegação revela uma explicação mais profunda sobre a situação de segurança do seu PC, mais uma vez usando uma linguagem acessível para te ajudar a saber o que está protegido e o que não está. Assim como outros softwares da Gibson, o InSpectre apenas funciona. Esse é o tipo de app que a Microsoft e a Intel deveriam ter publicado para esclarecer a situação confusa sobre os patches para essas falhas devastadoras de CPU que vem tomando as manchetes nas últimas semanas.

inspectreapp01.jpg

O InSpectre ainda está em seus primeiros dias. A primeira versão da ferramenta disparou falsos positivos com software de antivírus, apesar desse problema ter sido solucionado em uma versão seguinte. A Gibson alerta os usuários para “POR FAVOR não pegar uma cópia do programa em qualquer outro site de terceiros, uma vez que pode ser malicioso”.

Apesar de o InSpectre fazer um ótimo trabalho em te dar informações de alto nível sobre se o seu sistema principal foi protegido contra o Meltdown e o Spectre, atualizar o seu sistema e CPU não são as únicas proteções que você deve adotar. Esses exploits afetam todos os aspectos do seu sistema. Confira nosso guia especial sobre o assunto para saber mais.

Imprimir Email

Quais serão as habilidades de TI em alta este ano?

Projeção para o primeiro semestre de 2018 aponta que a demanda por profissionais que dominem PHP e Drupal estão entre elas, segundo relatório da Hays

Desenvolvedores do PHP e do Drupal são apenas dois dos profissionais de TI mais demandados hoje, de acordo com um novo relatório a empresa de recrutamento Hays.

A projeção para o primeiro semestre de 2018 aponta que a demanda por profissionais que dominem PHP podem esperar um aumento de salário considerável.

Outras habilidades de TI em alta demanda até junho de 2018 incluem desenvolvedores nativos de iOS e Android, desenvolvedores de BI Microsoft SQL, engenheiros e arquitetos de Redes Definidas por Software (SDN), profissionais DevOps e com conhecimentos de virtualização de rede, além de especialistas em segurança.

"Os candidatos com experiência em operações web, móveis, aplicativos e segurança serão necessários", diz o relatório.

Os profissionais de segurança da informação que se concentram em governança, risco e conformidade serão muito solicitados por conta da preocupação das empresas em estar em conformidade o Regulamento Geral de Proteção de Dados da União Europeia (GDPR).

Os dados do Censo de 2016 revelaram que o salário médio para um especialista em segurança de TI cresceu 33% entre 2011 e 2016, de US $ 84,864 para US $ 112,996.

Os engenheiros de rede com certificados de nível superior também serão procurados em todo o setor público, de acordo com Hays.

Algumas das principais tendências no recrutamento serão alimentadas pela Ciência dos Dados e pelas tecnologias digitais, bem como pelo uso da Realidade virtual.

A Hays também apontou os profissionais que permanecerão relevantes, tais como desenvolvedores .Net, Java e JavaScript. "Há uma escassez de desenvolvedores que criaram aplicativos com essas tecnologias em um ambiente comercial, particularmente Node.JS, Angular.JS & React.JS", afirma o relatório.

Os desenvolvedores Azure/AWS, juntamente com os profissionais de UI/UX, continuarão a ser demandados, à medida que os empregadores continuem buscando melhorar a experiência do cliente. 

Os segmentos de finanças, seguros, utilities e indústrias de varejo estão concorrendo por especialistas em cibersegurança, de acordo com Hays.

Os dados valem para a Austrália, onde a pesquisa foi publicada,  mas também para outros países, uma vez que empresas de todo o mundo estarão cada vez mais empenhadas na sua transformação digital.

programacao

Imprimir Email

Cinco recomendações para a implementação de DevOps

Partir das metas corretas e contar com um ferramental de desempenho eficaz pode deixar você um passo mais próximo do nirvana do DevOps, o que significa aplicativos mais rápidos e inovação acelerada

Existem algumas maneiras de encarar o DevOps. Primeiro, como uma metodologia de desenvolvimento baseada na integração e na entrega contínuas, com o respaldo de um conjunto de ferramentas de gerenciamento de configurações, como Chef, Puppet, Salt e Ansible. 

Também podemos pensar no DevOps como um conjunto mais simples de princípios que orientam as práticas de desenvolvimento e de implantação (automatizar, monitorar e registrar tudo em log). Tudo com a meta de visualizar como cada alteração em um processo iterativo acelerado afeta o desempenho.

O desafio – além da complexidade envolvida na implementação dessas ferramentas, na criação de scripts e na transformação de todo o processo de desenvolvimento – é que o DevOps exige uma mudança de cultura e um novo conjunto de habilidades.

A principal pergunta é: por onde começar? Como as equipes podem começar a desfrutar dos benefícios do DevOps sem ter que esperar meses ou anos para que as novas habilidades, ferramentas e processos estejam prontos e a nova cultura tenha se arraigado?

Noções básicas
Talvez, o melhor forma seja começar pelas noções básicas. A ideia central por trás do DevOps é a de que os desenvolvedores e as equipes de operações devem trabalhar juntos, colaborando, para fornecer que os desenvolvedores possam ter, em tempo real, as informações sobre como os aplicativos são executados, a fim de melhorar o desempenho enquanto estão sendo criados. Um aspecto essencial do estabelecimento de uma cultura de DevOps é proporcionar às equipes de desenvolvimento e operações  a visualização imediata do desempenho dos aplicativos. 

Equipes só trabalham bem juntas quando compartilham um propósito e têm um entendimento comum da realidade. No âmbito do desenvolvimento de aplicativos isso significa que, para que o DevOps tenha algum impacto, todos estejam de acordo quanto a uma única versão da verdade, o que proporciona um entendimento comum do que está funcionando e do que não está.

 Embora isso pareça simples, a realidade é que, com bastante frequência, as diferentes equipes que trabalham em aplicativos estão organizadas em silos, com cada uma delas executando seu próprio painel, tendo a perspectiva de uma parte específica da pilha de aplicativos. 

Por isso, um grande primeiro passo rumo ao DevOps é trabalhar no sentido de proporcionar uma única versão da verdade para essas equipes – uma estrutura comum em que todos os membros da equipe possam compreender o que acontece nos aplicativos, sistemas de banco de dados, sistema operacional, hipervisor, servidor de host e armazenamento. Só assim é possível eliminar a troca de acusações, determinando com clareza onde estão os problemas, afastando a a ambiguidade, focando na ação.

Como implementar
Com isso em mente, apresentamos cinco recomendações para implementar uma cultura DevOps em sua organização:

 1.  Proporcione aos desenvolvedores uma visualização direta do monitoramento dos servidores de produção, preparo e teste. Até que o desenvolvedor veja o comportamento efetivo do código, ele não terá como saber como o aplicativo se comportará de fato.

2.  Torne as equipes autossuficientes com relação às observações sobre desempenho, eliminando gatekeepers e silos de informações. Quando os desenvolvedores têm informações diretas sobre o desempenho, a interação deles com o pessoal de operações são mais construtivas e eles não precisam implorar por informações.

3.  Torne o desempenho um requisito explícito logo de saída. Por muito tempo, o desempenho foi considerado algo secundário, com que se deve lidar apenas quando as especificações funcionais tiverem sido atendidas. Tornar requisitos de desempenho uma parte essencial do processo de design, com testes e avaliações de desempenho logo no início do ciclo de desenvolvimento, garante que eles não tenham que ser acrescentados posteriormente.

4.  Estabeleça métricas compartilhadas, de modo que o desenvolvimento, a produção e a gerência tenham uma base para comparação dos resultados, avaliação do progresso e rastreamento do impacto das alterações. Quando os engenheiros de software e de sistema têm uma base comum para discussão e avaliação do progresso, estão em melhor posição para  trabalhar por uma meta comum.

5.  Concentre o foco na experiência do usuário final, seja este um cliente externo ou o responsável por um aplicativo em uma unidades de negócio. Quando a TI se volta para o serviço, o nível de serviço proporcionado ao cliente torna-se a única métrica realmente importante para avaliação do departamento de TI. Com a meta comum de proporcionar um serviço responsivo e previsível para aplicativos  dirigidos ao usuário final, tanto a produção quanto o desenvolvimento podem colaborar para o seu cumprimento.

devops625cio

Mas isso não é tudo
Há mais duas considerações importantes. Primeiro, somente as ferramentas de monitoramento não são suficientes. O monitoramento baseado em integridade fornece o status ativo/inativo para dezenas ou centenas de componentes, em geral com foco em indicadores de status verde, amarelo ou vermelho. Eles são úteis para identificar quando algo não funciona, mas são muito limitados para identificar a causa raiz dos problemas apontados e a correlação entre os componentes. Um sistema pode ser totalmente ineficiente e, mesmo assim, o painel de monitoramento mostrar apenas luzes verdes, já que nada em especial está avariado. Por isso, é importante olhar para um sistema com uma visão de desempenho, para compreender os tempos de espera e os congestionamentos.

Segundo, muitas equipes DevOps tentam monitorar tudo. O resultado são logs de mais de um gigabyte que exigem ferramentas avançadas e muito tempo de análise. Embora os gráficos produzidos possam ser muito interessantes, sua utilidade é limitada à capacidade de produzir informações. Um terabyte de dados de log é algo inútil, a menos que possa especificar o que há de errado com o sistema.

Conclusão
Para resumir, as equipes de desenvolvimento e de operações podem trabalhar melhor em conjunto quando: 

1 - Compartilham uma mesma visão do sistema, que fornece visibilidade de todas as camadas da pilha e das dependências entre elas;

2 - Estão voltadas para o desempenho e seu foco se concentra em localizar congestionamentos e informações que resultem em ação;

Mesmo sem a complexidade de um sistema completo de gerenciamento de configurações, partir das metas corretas e contar com um ferramental de desempenho eficaz pode deixar você um passo mais próximo do nirvana do DevOps, o que significa aplicativos mais rápidos e inovação acelerada.

(*) Gerardo Dada é vice-presidente de marketing de produtos da SolarWinds

Imprimir Email

Pesquisar

Visualizações

Ver quantos acessos teve os artigos
188762

On-Line

Temos 37 visitantes e Nenhum membro online