Antipadrão: em produção, mas com ajustes manuais!

Servidores

É comum a equipe de operação manter o ambiente de configuração reativo. Uma mudança, atende ao pedido de ajuste para a publicação de uma nova versão do sistema, contudo, não garante o ambiente homogêneo.

Erros mais comuns!

Abaixo irei enumerar alguns riscos comuns, recorrentes em diferentes empresas por manter o hábito de gerenciar os servidores individualmente.

  1. Implantei o aplicativo diversas vezes no ambiente de homologação, mas quando fiz em produção falhou.
  2. Temos uma equipe operando o cluster, conforme o turno e por conta disso, cada um tem sua configuração preferida. Isso torna o cluster irregular, tendo nos que respondem mais requisições que os outros.
  3. A equipe de operações nunca entrega o ambiente no prazo, demorando muito tempo para liberar o ambiente para teste.
  4. Quando o erro  na configuração, seja no sistema operacional, aplicações ou web, não consigo voltar para a versão anterior, funcional.
  5. Servidores em clusters tendem a hospedar infraestrutura de terceiros, levando a patches irregulares, plugins inseguros e sistemas operacionais em versões diferentes.
  6. Estou em produção e vou modificar direto em produção

Não seria melhor, ter um controle sobre a configuração, similar ao versionamento do código para manter os ambientes de testes, homologação, produção e componentes de terceiros com todos os aspectos reprodutíveis?

Meu controle é no word ou excel

Você deve estar pensando na gerencia de configuração e seu protocolo. Particularmente, bem escrito é possível reproduzir manualmente a infraestrutura para hospedar sua aplicação.

Para manter auditável você precisa controlar todos os registros contendo as mudanças feitas, de forma que ao reproduzir, chegue ao mesmo momento, inclusive observando as dependências entre as aplicações.

Considerações finais

Com isso, passamos a observar os processos necessários para a configuração deles e buscamos gradativamente automatizar, visto que nosso objetivo deve ser reduzir o risco, torna-lo barato, rápido e previsível.

Infra as Code é muito mais que aprender a automatizar algumas rotinas, visto que envolve resolver velhos problemas conhecidos.

 

Konia
www.konia.com.br

OWASP, novos membros e parceiros

Logo da OWASP

O grupo de trabalho OWASP em São Paulo, procura por pessoas interessadas em aplicar segurança da informação em suas atividades diárias, no meio acadêmico ou empresarial.

OWASP

Acreditamos que a OWASP tem contribuído com diversos trabalhos para aprimorar a segurança. Ela divulga diversos documentos abertos que podemos utilizar em projetos e como referencia em artigos.

Meetup

O Meetup terá encontros presenciais em São Paulo, mas não se restringe a pessoas dessa localidade. Usamos outras ferramentas para realizar reuniões e seminários virtuais.

Whats Up

Para discussões diárias, noticias ou networking, temos um grupo no Whats Up para troca de informações e desenvolvimento da área de segurança da informação.

Nossa ideia é reduzir o GAP sobre ameaças divulgadas para grandes empresas e CSIRTs, propondo medidas que sejam acessíveis para profissionais de TI, de forma a proteger o negocio da empresa e sua reputação.

Considerações finais

Consideremos importante ter pessoas engajadas com a comunidade OWASP-SP. Não é obrigatório ser membro da OWASP e os temas são escolhidos por maioria simples.

Usaremos o idioma português como referencia para comunicação, lembrando que há outros países que usam o mesmo idioma.

 

Quais lições eu aprendo, após cancelar uma Sprint?

 

Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master (Ken Schwaber and Jeff Sutherland, 2013)

Naturalmente, ninguém gosta de falhar e esse é o sentimento que fica, quando o Product Owner e o Scrum Master pensam em cancelar a  Sprint. Por um lado, motivado pela falta de habilidades necessárias ao time para trabalhar no backlog do produto. Por outro lado, no uso incorreto do SCRUM, mesmo sabendo que variação geram improdutividade.

Como surgiu o time?

Muitos Scrum Masters herdam o time, por tanto, não sabem como o time foi formado. Isso geralmente compromete a produtividade, pois nem sempre as habilidades individuais somadas, endereção a necessidade do projeto a ser entregue.

O foco não deve ser nas especializações, mas na oportunidade de estudo continuo para motivar o desenvolvimento profissional.  Inclusive é muito comum visualizar os subgrupos criados, agrupando desenvolvedores ou testadores. Depois, notamos as ilhas individualizadas, com as tarefas caindo na fila quando se trata de DBA e Requisitos.

Em geral, a formação do time aconteceu ao acaso, por afinidade e empatia, visto que a empresa encontra-se desorganizada. Por isso, não investiu na gestão de pessoas usando Kaisen.

De PMO para PO, o novo desafio

Tenho tropeçado em alguns Product Owners com formação em PMI. Entram com a missão de gerar resultados, com menos planejamento.  Contudo, eles ainda estão lutando contra o hábito de controlar as datas e estimar o tempo, ignorando os desenvolvedores no processo. Podemos então imaginar que se perdemos os prazos, podemos não ter as habilidades ou pessoas necessárias para tocar o projeto.

Então, como reorganizar o time e validar o que nos falta? No marco zero, ao montar o Product Backlog não visualizamos as historias, somente alguns EPICs  com uma linha de descrição. O risco é grande e não sabemos tecnicamente quais recursos iremos construir no sistema. Ironicamente, já temos um time e o desafio técnico pode ser inviável para eles. Por isso, a aprendizado continuo por meio de plataformas on-line  é fonte de estimulo para alavancar o desenvolvimento de novas habilidades no time.

Geralmente, a equipe é formada sem ter isso em mente o desafio e como ajudar as empresas a encantarem seus clientes por meio da nova ferramenta. O  PO precisa facilitar a comunicação, orientando o Time Scrum como fazer o contato com o cliente, envolvendo-o no processo.  Algo completamente diferente da separação proposta pela hierarquia do plano de comunicação do PMI, ditando quando e como faze-la.

Destruindo os indicadores

Em alguns momentos, o autogerenciamento é confundido com a ausência de registro e atualização dos status para as tarefas. E tudo isso fica mais confuso, quando recebo do time o pedido de aumentar o intervalo entre as reuniões diárias ou simples abandonar a prática. É obvio que os 15 minutos para reunir e avaliar  progresso não é o problema.

Medo em dizer a verdade…

Atualizar o status das atividades ajuda a identificar os impedimentos e quesitos técnicos que atrasam o projeto. A causa raiz de um atraso no projeto pode ser a falta de automação nos testes. Assim, como o aumento na cobertura de testes leva no registro maior de falhas ou defeitos.

Se as atividades foram alinhadas e seus status atualizados, o cliente ficará feliz em ver o gráfico de burndown e o avanço do backlog. Com base nessa informação de capacidade do time e progresso, o PO intensifica a revisão dos itens que geram valor para o cliente e antecipa as entregas, marcando preciosos pontos com o cliente.

Distorcendo as responsabilidades!

Retrospectiva produtiva é aquela que ao visualizar um desperdício pensamos em um processo para combate-lo, aplicando na próxima sprint. Vejo uma carga extra sobre o Scrum Master em convencer sobre algo que faz bem a todos.  A colaboração e parceria entre os membros deve ser constantemente estimulada.

E agora? Cancelei.

Evidente que se o mercado muda  e com isso o negocio é afetado, o escopo da sprint é modificado. Ninguém deseja trabalhar em algo que não representa mais valor para a empresa.

Lembro que os itens produzidos e validados pelo cliente podem ser colocados em produção. Não precisa  ignorar o trabalho feito até o momento. Não é correto remover os itens e adiciona-lós sem tratar a causa raiz, reagindo aos dissabores e críticas que se multiplicam.

Considerações Finais

Dessa forma, se participa de um time que cancela as sprints com certa frequência, chamo a atenção para o fato desse evento ser incomum e reflete problemas na formação do perfil do time ou na aceitação dos valores do SCRUM pela cultura da empresa.

Algumas pessoas usam o falso pretexto do cancelamento para evitar a mudança nos membros do time e ganhar tempo com as entregas vencidas, com os novos prazo renegociados. Mas, na verdade, se você é SCRUM Master de um time e não  participou da Sprint Zero, a falta de uma equipe genuinamente multidisciplinar e colaborativa é o seu real problema.

Konia
www.konia.com.br

O analista de requisitos no universo ágil

 

Equilibrando pratos!

O analista desenvolve os requerimentos e escreve testes de aceitação automatizados para eles. Os testadores também escrevem testes de aceitação automatizados. (Martim, 2012)

Na minha opinião, a melhor maneira de paralelizar atividades é dividindo as tarefas, observando afinidade com víeis técnico ou de negócios. Não espere a construção de teste a automatizado de quem faz teste manual, avalia risco e escreve requisitos.

Para onde eu vou?

Tenho visto o mercado encaixar o analista de requisitos na área de QA e depois se questionar: a) O numero de falhas aumenta e atrasa a publicação ou b) o numero de falhas diminui e o processo atrasa a publicação.  Nesse ponto, registro que fazer uso de boas práticas de ALM/DevOps não resolve questões como falta de habilidades ou olhares diferentes e processos incompletos.

Requisitos: funcionais ou não ?

Quando pensamos em segurança da informação precisamos entender que muitas mudanças acontecem em diferentes camadas. E muitos protocolos são criados com soluções de contorno ou definitivas que afetam a infraestrutura e aplicativos. Nesse momento, não consigo filtrar quais itens agregam valor ao cliente, visto que a lista de debito técnico é enorme.

Muitos não tem discernimento para julgar se a indisponibilidade é resultada de uma vulnerabilidade ou aumento de usuários. A diferença essencial entre eles é simples: um deixa o custo, pelo prejuízo com uso de recursos e o outro, lucro, com a adesão de novos usuários ao sistema. Então é natural esperar que a comunicação e o envolvimento com indicadores da infraestrutura seja diária, ao invés de um registro pontual, com a ultima verificação.

Metrificando…

Quando olhamos para um ambiente de produção parado ficamos tristes, por não usar de forma adequada as ferramentas de monitoramento. Inevitavelmente pensaremos sobre os papeis de cada um no processo e o motivo que nos levou a falhar. Costumo dizer que nenhuma arquitetura em papel sobrevive sem ajustes a um teste de stress. E talvez, pensando em sistemas robustos, na falta de um time especializado, muitas empresas tem migrado essa analise para fabricas de testes especializadas, com parti de sua estratégia de lançamento de novos produtos.

Não devemos por um analista para revisar o código sem identificar, com certa precisão, qual o conjunto mínimo de melhorias que pode ser feito e com isso aumentar a estabilidade da aplicação. O tempo é precioso e agora, colocamos o desenvolvedor mais próximo de onde os problemas acontecem.

Considerações finais

Dessa forma, espero que entendam. Dar novos nomes ao analista de requisitos sem prepara-lo para novos desafios, não ajudara com a produtividade. Recomendo fortemente um trabalho de conscientização, workshops envolvendo DevOps, engajamento com SpecFlow e uma dose de paciência. Bater a varinha mágica não irá resolver a questão.

Konia
www.konia.com.br

DevOps: Salvando-se da implantação manual

Papeis

 

Independente do tamanho da empresa, entregar uma versão da aplicação virou uma dor de cabeça. Cada passo, documentando, atômico, impreciso e por fim falho, muda ao sabor de quem o publica. O que deveria ser um processo reprodutível de sucesso, na pratica é diferente e dispendioso. Chato, mas você com certeza será chamado ao telefone no meio da madrugada.

Se ao longo do caminho você encontra:

  1. Reuniões constantes para reforça a necessidade de documentação, com passos detalhados que ao fim da execução, ainda há risco da publicação falhar;
  2. Mobiliza a equipe de QA para fazer testes manuais, quase sempre exploratórios, para determinar se a aplicação continua funcionando;
  3. Publica duas ou três vezes no dia a mesma aplicação, pois o processo de release foi falho;
  4. Vive preocupado com o ambiente, pois cada servidor no load balance tem sua configuração, sendo todos diferentes entre si;
  5. A publicação virou um evento que você avisa a família de sua jornada extra e a empresa para, enquanto você não publica a nova versão do aplicativo;

A solução é mergulhar no universo DevOps e ter um bom parceiro para guia-lo na jornada.

Konia
www.konia.com.br

Related Post

DevOps: O conto do fluxograma perfeito!

Fluxograma: Commit, Buil, Functional Test, Performance Test and Release
Fluxo DevOps

Qual o fluxograma perfeito?

Existem diversos modelos que além de descreverem o pipeline de automação, também sugerem uma conjunto de ferramentas para as etapas. Cada empresa tem seu fluxo de publicação definido e para isso dar certo é necessário escolher um modelo compatível com cada  realidade. Sem isso, haverá um ruptura ou resistência com falhas em processos que levaram ao fracasso na sua adoção.

Quebrando meu processo em etapas

Uma rotina comum seria composto por : Commit code, Buil, Funcional Teste, Performance Test e Release.  Se ao comparar com o processo abaixo e encontrar as  mesmas falhas, pare para revisar sua rotina.

Add missing libraries to build environment – As bibliotecas próprias ou de terceiros deveriam ser embutidas no NuGet privado. A condição para atualização pode ser a correção de uma vulnerabilidade ou otimização do seu código. Essa validação acontece tanto no ambiente quanto na aplicação.

Test takes too long increase timeout – A maior dificuldade é incluir testes automatizados para melhorar o código da aplicação. A medida que o projeto avança, os testes ficam mais complexos e muitas vezes, o bloco de validações supera o escopo necessário para o teste daquela feature. O tempo vai aumentando, a compilação desestimulando a equipe até que ela sucumbi a remoção dos testes automatizados. Com o tempo, aumenta a carga do time de QA com validações manuais e muito frequente se perdi os prazos com o roadmap do produto.

Environment can´t handle the number of virtual users generated – Uma das questões mais negligenciadas é o dimensionamento do ambiente para atender os clientes. Impor uma carga alta de acessos simultâneos que reproduzem as operações realizadas no sistema na fase de teste, permite antecipar quais itens são passiveis de falhas.  Com base nisso, em períodos chaves é possível reforçar os recursos computacionais para atender a demanda da empresa.

Get boss to sign off on more budget for more compute in AWS – Evidente que temos diversas plataformas na nuvem. As mais citadas são AWS, Azure, Google Cloud e DigitalOcean. No primeiro ano a politica de incentivos em créditos tornar o entendimento na nova arquitetura um debito técnico. As rotinas mal escritas acionam recursos de escalabilidade agregando novos servidores e incrementando os custos operacionais. Se não observar os indicadores do monitoramento, partirá para a solução mais fácil , aumentará a despesas, sem o bonus da transição para mascarar essa transição. Depois, pagará uma consultoria especializada para revisar o aplicativo, visto que não fez no início.

Boss on vaction – Em algumas empresas o Gerente de Produtos, mas na maioria dos casos, o desenvolvedor que faz dupla jornada, acumula o papel de ALM. Poucas fábricas usam o SCRUM e PO para atuarem nas publicações acompanhando a liberação de funcionalidades. O VSTS tem um excelente pipeline capaz de submeter o processo há aprovação, deixando sempre alguém informado da mudança no ambiente.

Have meeting to make sure that release won´t mess things up – O controle de mudanças é complicado, apenas pelo fato de não seguirmos os processos. Não há commit sem  um item da Sprint Backlog associado. Os builds tem controle na geração do pacote, listando todas as melhorias. Olhe o pacote e compare as funcionalidades prometidas. Já passei aperto pela diferença de funcionalidades ausentes ou quebradas, divergindo do ambiente de homologação para produção.

Management only, no developers – Se perceber que a publicação somente acontece com o engajamento de um desenvolvedor, precisa olhar mais de perto e analisar se há complexidade do merge que afeta a publicação. A liberação em produção é algo muito importante e se a equipe para até a release ser publica, a sua estratégia de branch provavelmente foi comprometida. É possível usar webhooks tanto no Slack como no Teams para acompanhar.

Considerações finais

São cenários comuns que acontecem  em diversas empresas, especialistas ou não em produzir software. Debaixo do tapete do debito técnico você verá que a agilidade será questionada pelo cliente. Como os incrementos não são frequentes e os resultados pequenos, tudo passa a ser questionado.

Você chegou aqui e talvez não tenha notado. Resiliência, redundância e programação defensiva são vários dos aspectos negligenciados na antecipação de lapsos de segurança. Acredite, ja rodei diversas rotinas e segui vários manuscritos para fazer o code review. Mas, se deseja ser diferente, sugiro um ponto de partida com VERACODE e DockerScan.

É preciso dedicar tempo para superar essas falhas. Sem isso,  não atingirá os resultados que empresas de alta performance tem conseguido. Ao implantar corretamente o fluxo DevOps na TI, você entregará mais valor e segurança para seus clientes.

DevOps e o seu verdadeiro propósito

DevOps

 

DevOps é a união de pessoas, processos e produtos para permitir a entrega contínua de valor para nossos usuários finais. (Brown,  2015)

Entregando valor

A transformação digital acontecerá pelo engajamento dos colaboradores em traduzir a operação da empresa em processos criativos, sem infringir normas, bloqueando código não testado, sem prejuízo a agilidade e disponível para uso em produção para seus clientes.

Errando a direção

O objetivo comum entre as áreas deve ser entregar  valor na ponta final, na mão do usuário final. Se você automatiza sem proposito, permitindo melhorias pontuais apenas no ambiente de desenvolvimento ou qualidade, continuaremos falhando, indo na direção errada.

Medir o débito técnico não é o único elemento para revisar.  Constantemente observamos desperdício com processos ou trabalho desnecessário. Isso também gera custo para empresa.

Quando você foca no feedback do cliente e promove sua satisfação, você não so encontra o caminho correto de fazer as coisas, mas um diferencial frente a seus concorrentes. Por isso, o desejo de publicar novos recursos o mais breve possível.

Tropeçando no valor

Para alguns DevOps é algo a ser implantado, como um passe de mágica. Para outros, automatização por meio da sua ferramenta preferida. Por fim, vemos um pipeline despejando código de forma veloz, mas não tão ágil como esperado.

Afinal, ser ágil é a capacidade do time em olhar para o backlog da sprint, associar os incrementos produzidos e assim que testados, liberados em produção. Quando não há esse conexão, fica difícil de saber o quanto o time está sendo produtivo a favor da empresa.

Construindo resultados

Na minha opinião é preciso lembrar que DevOps não é um produto, comprável na prateleira do supermercado. Automatizar sem construir indicadores relevantes,  não ajudará a obter bons resultados.

A ideia é reconstruir o ambiente de uma aplicação quando 1) componentes forem atualizados ou 2) a instabilidade for resultado do mau funcionamento. Isso produzirá um novo ambiente idêntico e seguro, ou agregará mais recursos (CPU, Rede, Storage) para a solução.

Outra rotina importante é apresentar as informações coletadas do NOC para transforma-las em oportunidades no backlog do produto. O Scrum Master agora precisar aproximar os dois times e ficar atento aos relatos do que acontece em produção. Isso derrubará o mito que ele observa a dinâmica do que acontece no projeto e renega os itens da sustentação.

Por fim, o ambiente de produção trará novas analises. Observando as consultas, atualizações de serviços ou sistema operacional, medindo o valor entregue ao cliente e quais ajustes necessita fazer para acomodar as melhorias no contexto da nuvem.

Considerações Finais

Espero com isso ter contribuindo para abrir horizontes e mostrar que a melhor maneira de visualizar todas essas possibilidades está ligada a composição do seu time.

Que feedback continuo vem do cliente e também da observação do ambiente de produção, gerando oportunidades de melhorias a serem inclusas no backlog do produto.

E a colaboração tem papel chave nesse processo, podendo ser estimulado nas reuniões e com ferramentas de comunicação, como o Slack e Teams.

Related Post

Smartphone: Melhor por uma senha, ao inves de nenhuma!

Digitar senha, antes de desbloquear celular

Atendendo as expectativas do mercado e as recomendações de especialista no mundo, os fabricantes de smartphones tem aumentado o  número de recursos com foco em segurança.

Evidente que algumas sugestões ajudam a prevenir essa exposição. São elas:

  1. Ligar o Bluetooth apenas para transferência de dados, desligando em seguida
  2. Manter o sistema operacional do aparelho atualizado, sempre
  3. Registar uma senha no aparelho, antes de desbloquear
  4. Combinar outros fatores, como o reconhecimento biométrico, token ou face
  5. Usar um aplicativo para recuperar o celular ou destruir os dados remotamente

Contudo, na contramão dessas recomendações o público brasileiro tem um perfil diferente. Ele utilizar muito para trocar mensagens, ter imagens pessoais, usa muito as redes sociais e faz muitas transações bancarias.

Segundo Kaspersky Lab,  com base nos entrevistados foi possível montar um perfil sobre atividades realizadas diariamente no aparelho.

  • 43% usam para realizar operações bancarias
  • 53% não usa senha no celular
  • 47% não faz backup das informações
  • 84% não tem criptografia ativada

Conclui-se com a pesquisa Not Logging On, But Living On que ainda falta conhecimento aos usuários sobre o risco de por tanta informação importante no smartphone e não ter os cuidados adequados se o aparelho for furtado.

Automatização com DevOps, sendo um SysAdmin

Automatização é um amplificador da energia que você investe em suas tarefas. Dedique tempo, invista nos primeiros passos, teste localmente, ganhe escalabilidade e use em produção. (Moraes, 2017)

Quando um SysAdmin focado em segurança participa de uma comunidade DevOps penso que ele tem alguns valores em mente. Tenho certeza que ao ver os benefícios, você passará pela provação de justificar ao mundo sua escolha. Dos questionamentos frequentes pelo meu interesse, resolvi contribuir com minha opinião.

Automatizar, DevOps e a fronteira final

A ideia é desbravar um pouco sobre ferramentas para desenvolvimento e administração de sistemas para alavancar a produtividade, empregando conceitos de DevOps.

Ansible, Chef, Jekinks, Terraform, Visutal Studio Team Services e Docker estão disponíveis para iniciar a jornada com Azure, mas não limitados a essa plataforma. Com a aquisição do GitHub pela Microsoft, ele estará cada vez mais presente no versionamento e no pipeline do seu build.

Alguns tem dúvidas por onde começar e se questionam qual trilha escolher com frequência no grupo #DevOpsProfessionals. Digo sempre jogue simples e use o que já sabe. Se possível, máxime seu conhecimento mudando para uma empresa focada na cultura DevOps. Você precisa construir uma base sólida e tem muita gente aplicando os conceitos errados.

Se você conviveu com Hyper-v, nada mais natural que usar Azure. Particularmente,  para aproveitar minha  jornada como Microsoft Certified System Administration fiz essa escolha.

É mais fácil garantir uma SLA de 99,9%

Estamos sempre ligados no ambiente de produção, observando ameaças e também sua disponibilidade. Reconstruir um ambiente para um sistema de informação tão logo seja possível é fundamental. Ter elementos redundantes para escalar horizontalmente, indispensável.

Tudo isso ao alcance de alguns cliques, bem distante das especificações, conversas com a equipe de compras e mandigas para a importação levar menos que 45 dias para chegar ao Brasil.

Isso poupa recursos financeiros para empresa

Sempre dimensionamos o ambiente tendo em mente a capacidade de atender os usuários, com base no histórico de picos do acesso. Agora, realocamos os recursos, automaticamente, com base na leitura da flutuação de demandas. Você não ouvira mais que estocou dinheiro da empresa com recursos sem uso.

A aplicação funciona no servidor A e no B, também

Por algum motivo, muitas fabricas de software tem um processo de ALM incompleto. A maior parte do tempo estamos cuidando da publicação manual, uso de ftp e ajustes na configuração dos servidores.

Quando usamos o balanceado de carga, incrementamos o esforço administrativo, para equalizar servidores diferentes com a mesma configuração. Agora, podemos construir um baseline e garantir que os servidores tenham os mesmos componentes, patches, dependências, configurações e serviços. Não peça a um desenvolvedor para tomar conta disso, não faz parte do mindset dele.

É natural pensar em integração continua

A tarefa de merge ainda é o evento mais complexo da empresa. Por mais que a recomendação seja não estocar código, os desenvolvedores ainda atualizam o repositório com frequência irregular, potencializando conflitos ou quebra da aplicação. Pense na estratégia e arrume a estrutura da branch para aderir ao desafio da sua empresa.

Mais assertivo que esperar o retorno do cliente é configurar as notificações para o Slack informar ao time de operações que há algo errado no build. Isso poupa aborrecimento, tickets abertos e melhora o relacionamento com o cliente. Diferente do que imaginam, gostamos de dormir durante a madrugada e passear aos fins de semana.

Um ambiente novo em um piscar de olhos

Para muitos SysAdmins uma das rotinas mais importantes e improdutivas é a documentação dos ambientes. Após passar por alguns CPDs, segui um fluxo equivocado que me levou a usar e reproduzir um processo ruim.

Não é possível construir um ambiente sem ter a aplicação em mente. A arquitetura da aplicação muda, atualizamos o ambiente e registramos, quando possível, as modificações.

A demanda pelo serviço aumenta, revisamos o plano de capacidade, reconstruímos o ambiente e entregamos para o cliente usar em alguns dias.  Se for uma data comemorativa ou promoção sazonal, sempre haverá alguém insatisfeito com você.

Que tal gerar um servidor, configurar, validar o funcionamento da aplicação e gerar um template do que fez? Com Azure, AWS e CloundOcean podemos entregar novos ambientes em minutos.

E se a ideia for construir ou destruir ambientes conforme a necessidade? O  Kubernetes possui um recurso de healhcheck, recriando ambientes instáveis. Ele também entrega ambientes conforme necessidade da aplicação ou serviços, adequando-se a demanda. Além disso, testa de forma temporizada a estabilidade de seus componentes, valendo-se de métricas para destruir e reconstruir a solução usando Docker Swarm.

Considerações finais

Seja produtivo, use o arquivo de configuração para documentar e construir seu ambiente. Ele será reprodutível, autoexplicativo e fará o papel de documentação. Somados,  a automação converterá a improdutiva em oportunidades.

A regra geral é manter a infraestrutura minima. Monitore os picos das demandas com gatilhos sobre recursos (rede, memoria e processador). Essa analise ajudará a encontrar o melhor momento para incrementar com um ou mais servidores. Assim como remove-lós se não forem mais necessários.

 

 

 

Related Post

Malware: pegando pragas virtuais de lojas oficiais

Malware

O pesquisador Josh Pitts relatou que os sistemas de validação atuam de duas maneiras. A primeira considera seguro todo código que tenha um certificado digital da Apple, publicando automaticamente. A segunda é explorar o conceito de qualidade, inserido pequenos trechos de código maliciosos, malware, no contexto da aplicação. Uma vez atendido os critérios, consideram o código bom e autorizam compartilhar na loja (Microsoft, Apple, Google).

Uma pesquisa da Okta revelou que há diversos programas maliciosos do tipo malware mascarados como legítimos na loja da Apple, permitindo que recebam selos de segurança. Para evitar que isso aconteça também com seus aplicativos, a Google pretende impor que suas extensões tenham como fonte apenas o Chrome Web Store e melhorar o processo de certificação de seus aplicativos.

Código mal escrito ou falho leva a um desempenho pobre, afeta a autonomia de bateria do equipamento e expõe um falha que pode ser emprega para furtar seus dados ou cometer delitos. Tanto a abordagem de equipe propria ou terceira, por meio de APIs não garantem que o aplicativo é isento de falhas. Outro aspecto é que a automação do processo, mostrou que publicar o aplicativo de forma ágil, pode facilitar que um malware seja incluso junto, se outras técnicas para testar a segurança não forem utilizadas.

Acredito que o primeiro passo dado foi assertivo, notificando as empresas que tiveram seu processo reprovado. Abaixo a lista que foram informadas sobre as falhas e se comprometeram a liberar novas versões. Google Santa

  • Facebook OSquery
  • Little Snitch
  • xFence
  • Yelp OSXColletor
  • Carbom Black Cb Response
  • Ferramentas do Objective See

Outro risco é que temos os programadores mal intencionados que compartilham o código de aplicativos em repositórios públicos. Eles incrementam o controle de versão apenas para instigar novos downloads com malwares ocultos. Com isso, a instalação dele é feita na máquina junto com a extensão. Por isso, faz sentido a estratégia Google em bloquear fontes alternativas para instalar aplicativos para Android.

Lembro que cada fornecedor também tem sua politica e conforme gravidade, escolhe quando ou se irá corrigir as falhas divulgadas pelos centros de pesquisa. Para esclarecer esse ponto, a Microsoft divulgou um documento chamado “Security Servicing Commitments for Windows” como trata os bugs e quais motivos afetam a priorização.  Essa informação é vital para um especialista em segurança lidar com os aplicativos. Entender quais são os recursos de segurança, limites, mitigações e quais os compromissos legais o fornecedor tem com seu cliente.

VPNFilter provoca mar de reboot no mundo

VPNFilter

Faz algum tempo que o FBI liberou comunicado a  população americana informando sobre o risco do malware VPNFilter, variação do BlackEnergy, responsável por paralisar a Ucrânia.

O malware explora falha de configuração de alguns fabricantes como Linksys, MikroTik, Netgear e TP-Link. Esses modelos são comuns no ambiente domestico e em conjunto, pode causar lentidão ou indisponibilidade da rede de internet de um pais.

Estima-se que 500 mil roteadores foram afetados no mundo e algumas características dificultam a identificam de roteadores infectados. Ele usa rede criptografada para mandar as informações capturadas dos usuários, roubar credencias e eventualmente torna-lós inoperantes.

No Brasil, após meses de investigação da Policia Civil do DF, a MPDFT (Comissão de Proteção dos Dados Pessoais do Ministério Público do DF e Territórios) emitiu aviso (07/06/2018) para população brasileira de como atuar frente a essa ameaça.

Na minha opinião, nosso tempo de resposta ainda é alto, comparado de outros países. E, pensando no investimento feito pelos contribuintes, imaginava que o CDCiber (Centro de Defesa Cibernética) teriam maior participação na emissão de alertas dessa natureza.

Alguns informações divulgadas são parcialmente corretas. Com isso, outros detalhes precisam ser abordados.

  1. O malware atua em 03 (estágios), por tanto nem sempre o reboot resolve.
  2. Modifica o serviço CRON ou a memoria NVRAM do router, persistindo após o reboot.
  3. Comuta a comunicação HTTPS para HTTP em sites que não impõem a comunicação segura, guardando informações dos usuários.
  4. Utiliza de plugins na fase 3 para ter acesso remoto aos equipamentos infectados, cometendo crimes por meio da maquina sequestrada.

Concluo que se a indícios de infecção na rede de computadores, a melhor opção ainda é a escolha do refactory. O equipamento voltará com recursos e configurações de fabrica instaladas. Um tempo para reconfigurar será gasto e aconselho ter isso documentado.