A escolha certa para empresas que estão iniciando no mundo da Internet.

Mais informações clique aqui.

Para empresas que já estão na Internet porém querem mais: Visibilidade, Recursos, Estabilidade e Segurança.

Mais informações clique aqui.

Todo o poder de um servidor dedicado somente para a sua empresa.

Mais informações clique aqui.

“Quantas pessoas você conhece que são capazes de dizer a seguinte frase: Eu só trabalho aqui.

Eu espero que poucos e espero também que você não compartilhe desse pensamento, obvio… e que corra dessas pessoas como quem corre de um tsunami.

Nosso trabalho só consegue ser bem feito quando estamos envolvidos emocionalmente com ele.

Enquanto o relacionamento com seu trabalho for baseado no número da sua conta corrente e tiver seu auge nos dias 5, 15 ou 30, nada, repito, NADA que você fizer vai mudar o mundo, nem que seja somente o SEU mundo.

Paixão é a palavra aqui. Paixão pelo que você faz.

Não adianta dizer-se apaixonado, você precisar SER apaixonado e ai que chego no que considero o maior problema.

Caramba, pensa bem, você vai conseguir se apaixonar sempre por toda empresa em que entrar para realizar um projeto?

Claro que não. Não tente se enganar sobre isso.

Ninguém se apaixona por uma empresa logo que entra, e a maioria sai da empresa depois de anos sem nunca ter se apaixonado por ela.

Em parte isso é culpa das empresas, que com uma visão estranha da realidade, disparam uma torrente de tarefas encadeadas para você fazer, quando na realidade deveriam disparar uma torrente de tarefas sim, mas para você se envolver.

Eu não vou falar de empresas aqui, só achei necessário usar a palavra empresa no parágrafo acima para poder conectar as coisas na ordem certa, que acho não ser a ordem atual.

Você não deve se apaixonar por uma empresa antes de se apaixonar por você, pelo seu trabalho, pelo seu resultado. Pela sua obra prima.

Se apaixone pelo que você faz meu caro. E se você tentar e não conseguir se apaixonar, esta mais que claro que você esta fazendo isso errado e talvez o caminho seja procurar outra profissão ou outra maneira de se apaixonar.

Pense como um artista, que apaixonado pela sua arte, não se importa de brigar por ela, discutir e se necessário, chorar por ela.

As melhores coisas que realizei não vieram de uma estrutura fixa Top Down clássica, elas nasceram como resultado da minha paixão pelo que faço junto a grande sorte de encontrar pessoas também apaixonadas pela sua arte.

Quando você é apaixonado pelo que faz as pessoas que também o são percebem, acredite em mim, e se aproximam, trocam ideias. Enquanto as que “só trabalham aqui” procuram te evitar, por que você mexe na situação, estraga a porcaria da zona de conforto e os que “só trabalham aqui” amam esse pedacinho do NADA.

Eu tenho um nome para esse pedacinho do NADA chamado “zona de conforto”. Eu gostaria de chama-lo de concha. Um treco que serve pra te proteger e tem que ser justo ao seu tamanho.

Se a concha for grande demais, atrapalha se movimentar e se for pequeno demais, vai te causar dores horríveis. Um treco que você imagina que te tras segurança, mas que não vai servir em você(para você) a vida inteira.

Não entre na concha meu amigo. Não entre na maldita concha. Viva como um artista, aja como um artista, viva como um artista. Seja você mesmo.

E se onde você trabalha não houver espaço para arte, tente criar um mural discreto nos bastidores. Talvez você descubra mais artistas como você, pessoas apaixonadas pelo que fazem, mas que entraram na concha sem querer mesmo, ou por que ali parecia seguro ou por que do lado de fora dela era muito mais perigoso.

E se nada funcionar, procura uma empresa que procure por artistas. Elas existem, exatamente da mesma maneira como existem as conchas.”

Texto original: TI precisa de mais artistas

A partir dessa idéia, a equipe responsável pelo estudo recomenda que o mercado procure se preparar contra o contínuo crescimento no número de aplicativos maliciosos para dispositivos móveis; ficar alerta quanto aos criminosos, que atacam e infectam lojas de aplicativos de smartphones e tablets; ter maior atenção a conectividade demasiada levando a maiores desafios de privacidade e segurança; enfrentar novos riscos de ataque aos serviços públicos de saúde digitalizados, especialmente nos Estados Unidos e na Europa e outros tipos de ocorrências que possam afetar negativamente a área da segurança da informação.

Foram ressaltados também, os fatores positivos para a segurança em 2012, como o aperfeiçoamento e implementação dos “scoring systems”, para garantir as novas aplicações desenvolvidas e a evolução dos sistemas “smart grid”.”

O texto original do Under-linux.org: Possíveis Ameaças de Segurança para 2012

1. Novo datacenter principal: Antes de planejar um datacenter secundário (remoto), você deve certificar se todos os componentes em seu datacenter primário são altamente redundante. Seu foco deve ser em projetar um datacenter primário tão resistente quanto possível, que você consiga se recuperar rapidamente da maioria dos desastres (exceto desastres naturais) sem ter que usar sempre o datacenter secundário. Por exemplo, ter um banco de dados standby no mesmo datacenter do seu banco de dados de produção, configurar placas de rede e placas HBA dupla em todos os servidores de produção, configurar servidores de web múltiplos com balanceamento de carga, conectar o servidor em dois circuitos de energia usando fontes redundantes, etc;
2. Datacenter secundário (remoto): Se você implementar um novo datacenter primário, o objetivo de um datacenter remoto é principalmente para as catástrofes naturais como terremotos, incêndios, inundações, etc. Embora isso possa ser muito óbvio, vale dizer, já que eu já vi algumas empresas fazerem isso, que tem tanto datacenter primário quanto o secundário na mesma cidade, o que compromete o propósito da Recuperação de Desastre;
3. Replicar componentes de produção no datacenter secundário: Você não precisa replicar todo o hardware e aplicativos de datacenter primário para o secundário. Um administrador de sistemas, técnicos ou qualquer pessoa pode rapidamente identificar todo o hardware e software crítico que precisa ser replicado no site remoto, mas você pode precisar de ajuda de outros departamentos para identificar as aplicações que são críticas para o negócio. Você tem de mapear as funções críticas de negócios em função dos componentes da infraestrutura de TI, se certificando que realmente todos os componentes de infraestrutura juntamento com a aplicação e os dados foram replicados para o site remoto;
4. Plano de armazenamento – Storage: Se você tiver algum tipo de storage SAN (ou storage NAS) que suporta a aplicação crítica no datacenter primário, você precisa ter um solução similar em seu site remoto também. Por motivos de desempenho, os servidores no datacenter remoto devem ter as mesmas características dos servidores de produção do datacenter primário. No entanto, para o storage, se você tiver um storage SAN high-end de um grande fornecedor no site principal, pode-se considerar o uso de um storage SAN high-end de um fornecedor de pequeno porte, que pode custar-lhe muito menos, com configuração e desempenho semelhante;
5. Replicar dados para o site remoto da base em uso: Sincronizar os dados entre o datacenter primário e o remoto é um aspecto crítico de uma implementação bem sucedida de Recuperação de Desastre. Uma vez que você listou todas as aplicações que precisam ser replicadas para o site remoto, você agora precisa descobrir como sincronizar os dados entre estes dois locais para todas essas aplicações. Por exemplo, você pode replicar o banco de dados Oracle usando as tecnologias de replicação fornecidas pelo fabricante do storage ou você pode usar o dataguard para replicar estes dados. Ambas soluções tem suas vantagens e desvantagens e você tem que analisá-las cuidadosamente e escolher aquela que se encaixa no seu orçamento e escopo do plano de Recuperação de Desastre;
6. Replicar os dados iniciais usando um método manual: Quando você estiver configurando o site remoto pela primeia vez, você tem que decidir como será a sincronização inicial dos dados. Por exemplo, se você for replicar um banco de dados de tamanho enorme, você não pode copiar o backup do banco de dados através da rede para o site remoto, pois irá utilizar toda banda de rede. Em vez disso, você poderia realizar um backup em fita no datacenter primário e usá-lo no datacenter secundário para configurar o banco de dados. Uma vez que a configuração inicial é feito, você pode implementar alguma forma de sincronização automática entre os sites;
7. Tempo de Recuperação – Recovery Time Objective: Você deve identificar, junto com os gerentes de negócio, qual o Tempo de Recuperação aceitável. Por exemplo, sua organização pode decidir que o Tempo de Recuperação deve ser de 8 horas, ou seja, após um desastre, no prazo máximo de 8 horas todas as aplicações críticas devem estar plenamente operacionais no site remoto. O Tempo de Recuperação tem um impacto direto sobre quanto valor deve ser gasto na implementação da solução de Recuperação de Desastre. Por exemplo, um Tempo de Recuperação de uma hora pode exigir uma solução mais sofisticada que será muito mais cara do que uma solução com o Tempo de Recuperação de 24 horas;
8. Ponto de Recuperação – Recovery Point Objective: Assim como Tempo de Recuperação, você deve decidir, junto com os gerentes de negócios, um Ponto de Recuperação aceitável. Por exemplo, sua organização pode decidir que o Ponto de Recuperação aceitável é de 2 horas, ou seja, depois de um desastre, quando você recuperou o serviço no datacenter remoto, 2 horas de perda de dados é aceitável para o negócio. Por exemplo, se o desastre aconteceu às 15:00h, depois de restaurar o sistema no site remoto, este irá conter dados de produção somente a partir das 13:00h. O que significa que você perdeu os dados desde às 13:00 até às 15:00h. Em termos simples, se seu Ponto de Recuperação é de 2 horas, a sua empresa deve estar disposto a perder 2 horas de dados durante um desastre;
9. Failover – Transferência em caso de falha – automático ou manual? Você tem decidir se você quer que o failover ocorra automaticamente ou manualmente após um desastre. Na maioria dos casos, uma intervenção manual é aceitável, pois você não quer uma transferência automática para o datacenter remoto em caso de um falso-positivo. Tenha em mente que, depois de um failover, há muito trabalho para voltar para o datacenter principal;
10. Failover da rede: Tenho visto que os planos de Recuperação de Desastres dão muito foco para replicação de dados, mas menos foco para os aspectos da rede. Junto com sua equipe de rede, é preciso identificar todas as infraestruturas de rede que precisam ser replicadas. Por exemplo, se certificar de que os endereços de produção (URL) estão apontando para o site remoto após o failover. Se você tiver estabelecido conexões VPN com seus clientes, identificar como restabelecer estas conexões VPN. Quando você criar/modificar as regras de firewall (ou qualquer coisa relacionada a segurança) no datacenter principal, você precisa identificar como estas políticas de segurança podem ser replicadas para o site remoto de forma contínua;
11. Configuração no lado remoto: Você precisa ter um plano adequado para acessar o datacenter remoto para depurar todos os problemas. Você pode configurar um KVM no site remoto para acessar o console do hardware remoto do seu escritório. Ou, você precisa planejar algum tipo de manual de serviços no lado remoto, onde alguém pode ir para o datacenter de contingência e executar suas instruções;
12. Testes anuais de Recuperação de Desastre: Várias organizações gastam muito tempo e dinheiro na criação de um site de contingência apenas para descobrir que ele realmente não funciona como esperado quando se está em uma situação real de Recuperação de Desastre. Uma vez por ano, você deve validar suas configurações atuais para garantir que o site remoto funciona corretamente e cumpre o objetivo original. Se tudo estiver configurado corretamente, você deve ser capaz de transferir manualmente suas aplicações críticas do datacenter principal para o remoto, e deixá-las funcionando por alguns dias. Isso também ajuda a ver como o site remoto lida com uma situação com carga em tempo real;
13. Datacenter remoto como uma plataforma de Garantia de Qualidade – Quality Assurance: Em vez de usar o site remoto só para a situação de desastre, você pode usá-lo como uma plataforma de Garantia de Qualidade, fazendo testes de carga e desempenho de seus aplicativos. Isso pode ser útil, pois você não precisa investir em infraestrutura de testes adicional no datacenter primário. Quando você tomar essa atitude, você estará sincronizando os dados do site primário para o site remoto de forma contínua. No entanto, sempre que você fizer um teste de carga, você precisa implementar uma solução adicional, onde você precisa marcar um ponto de verificação do estado atual do site remoto, realizar seu teste de qualidade, e logo em seguida voltar a situação anterior para continuar a sincronização dos dados com o site primário;
14. Plano de resposta: Uma vez que você implementou o site remoto, você precisa ter um plano de Recuperação de Desastre sobre como você e sua equipe devem agir em uma situação real. Colaborar com vários departamentos em sua organização, identificando os recursos chaves que farão parte da equipe de resposta a incidentes e identificar o seu papel específico no plano de resposta. O plano de resposta a incidentes é um simples passo-a-passo sobre o que precisa ser feito quando há uma desastre, quem irá realizar as tarefas e em que sequência as tarefas serão executadas;
15. Não tem um site de contigência? Muitas organizações não têm um site remoto. Se você está trabalhando para um delas e você é responsável pelas aplicações críticas e infraestrutura de TI, é de sua responsabilidade elaborar um plano de Recuperação de Desastre, orientar a sua gerência sobre a importância de gastar tempo e dinheiro em Recuperação de Desastre e obter a sua aprovação. Mostre três diferentes planos, um que custa muito, outro de custo razoável e um com custo pequeno. Como explicado anteriormente, o plano de Recuperação de Desastre pode variar dependendo de vários fatores, onde o custo é um deles. Depois de ter apresentado o seu plano detalhado para a sua gerência, e se este plano não foi aprovado, pelo menos você vai se sentir bem, já que deu o seu melhor na preparação de um bom plano;
16. Quando declarar um desastre? Você precisa identificar claramente isso o quanto antes. Você precisa ter um critério muito claro, escrito, sobre quando você vai mudar para o site remoto. Quais os critérios que desencadeiam a transferência? Quando você inicia uma Recuperação de Desastre? Em que ponto você declarar um desastre e começar a trabalhar na transferência para o site remoto? A resposta para estas questões devem ser claramente definidas e revisadas por todos os departamentos em sua organização, e finalmente, esses critérios devem ser aprovados pela alta administração. Quando o ambiente de produção fica “fora do ar”, porque alguém excluiu algum arquivo por engano, este evento pode ou não desencadear um desastre. Para algumas empresas, a recuperação dos dados do backup no próprio datacenter principal provavelmente será a melhor solução. Para outras, que não podem esperar esta restauração do backup, é necessário mudar para o site remoto;
17. Backup, backup e backup: Backups são muito importantes em um plano de Recuperação de Desastre. Como mencionamos anteriormente, seu objetivo deve ser nunca usar o site remoto, a menos que um desastre natural real aconteça. Assim, uma forte estratégia de backup em seu site principal é muito crítico. Você deve fazer backup de todos os seus aplicativos críticos. Quando fizer o backup de seu banco de dados, deve armazenar este backup em quatro locais. Backups são praticamente inúteis se você não restaurá-los em um servidor de teste para confirmar que estão funcionando corretamente;
18. Aplicação de patches: Quando você aplica uma correção de sistema operacional, atualização de firmware ou realiza qualquer tipo de gerenciamento de configuração do hardware no site principal, você precisa ter uma estratégia para fazer estas mudanças no site remoto de forma contínua. Você não quer uma situação, onde a configuração do sistema operacional em seu site principal é diferente do site remoto;
19. O sucesso depende de muitos fatores: Gestão a partir do topo, alocação adequada do orçamento, envolvimento de todas as divisões de negócios, um forte plano de Recuperação de Desastre, recursos técnicos, teste total da solução de desastre, etc. Mais importante, um escopo bem definido de Recuperação de Desastre alinhado com o objetivo de negócio é o mais importante para uma solução de sucesso;
20. Documentação: Um planejamento de Recuperação de Desastre adequado requer vários processos estabelecidos. Todos estes processos devem ser documentados de forma adequada. Por exemplo, um documento que explica o processo de escalonamento quando um desastre ocorre. A documentação técnica que explica o que precisa ser feito para fazer a transferência em caso de falha para o site remoto. Um documento de comunicação que listas todos os membros da equipe envolvidos na Recuperação de Desastre, suas responsabilidades e como eles podem ser contatados durante o desastre. Um documento para a equipe de suporte ao cliente, para saber o que precisa ser comunicado ao cliente e como encontrar os clientes durante um desastre. Um documento que lista todos os testes que uma equipe de qualidade precisa realizar depois que o site remoto foi ativado, etc.

O que foi apresentado é apenas uma pequena parcela do que é Recuperação de Desastre. Há muito mais, além dos  itens acima. Se você é um administrador de sistema ou alguém que é responsável pelas aplicações de TI e infraestrutura e se não tiver um plano de desastre, considere isto como um lembrete para começar sua estratégia de Recuperação de Desastre.

O resultado não poderia ser pior, apenas 17% das aplicações passaram nos testes realizados, 44% ficaram em uma situação de alerta e 39% não passaram nos testes.

Referências:

Mobile App Security Study

Mobile App Security Findings Released – July 2011

Auditoria de AppWatchDog da ViaForensics revela um cenário porcino de segurança no mobile

Também estão documentados os procedimentos de integração entre o Apache e Tomcat, através do módulo Proxy AJP, além da configuração de domínios virtuais no Apache.

Servidor Apache com PHP e Tomcat

Nas distribuições openSUSE e CentOS o comando sar está presente no pacote sysstat, podendo ser instalado pelo YaST/zypper ou Yum, respectivamente.

Os principais usos do sar são:

1. Uso da CPU (sar -u)
2. Uso de memória (sar -r)
3. Uso do espaço de swap (sar -S)
4. Atividade individual de cada dispositivo de I/O (sar -d)
5. Atividade da fila de execução de processos e carga (sar -q)
6. Relatório de estatísticas da rede (sar -n [DEV|IP|TCP|UDP|ALL])

Obs.: Existem outras opções no monitoramento da rede.

Para maiores informações, aconselho a leitura da manpage do sar.

Referência:

10 Useful Sar (Sysstat) Examples for UNIX / Linux Performance Monitoring

Para ler a matéria completa e ver o vídeo, clique aqui.