dev vs. ops

DEV VS. OPSDesenvolvendo para operação

Roberto Gaisergaiser@geekbunker.org@rgaiser

1

SITUAÇÃO ATUAL

2

“SIMPLES E DE FÁCIL MANUTENÇÃO”

3

“ISSO FICA PARA A SEGUNDA ENTREGA”

4

PLANNINGO começo

5

O COMEÇO

• “É fácil, está pronto na minha maquina”

• “Só fazer um serviço que responde <...>”

• “Colocamos tudo junto para facilitar”

• “Isso fica para a segunda entrega”

• “Depois a gente arruma”

• “Criamos uma <...> a mais no banco”

6

O QUE FAZER?

7

COMPONENTES

8

COMPONENTES

• “Um sistema é um sistema, outro sistema é outro sistema”

• Automação para criar o ambiente

• Ferramentas/Linguagens mais produtivas

• Isolar problemas e tornar serviços assíncronos

9

COMPONENTES

• Benefícios a longo prazo

• Flexibilidade para operação na alocação de recursos

• “code outlives its [developers] intentions”

• “All software is permanent”

10

LOGS

11

LOGS

• Logar tudo

• Log Driven Development

• Logs devem ser evidências de teste

• Syslog

• Formato padrão

• “Vou olhar no código...”

12

LOGS

• Stack trace não é log

• Identificador único de transação

• Vários níveis de log

• Em português

• Log deve de ser parte do desenvolvimento, não algo a ser acrescentado depois

13

DEPLOY

14

DEPLOY

• “É só pegar do <...> e jogar lá”

• Aplicação deve ser construída pensando no deploy

• Resolver dependências/requisitos sem criar conflitos com o repositório da distribuição

• Scripts de inicialização, rotacionar logs, etc

• Servidores de produção não tem acesso a internet

15

DEPLOY

• Evitar permissões incorretas

• Evitar arquivos em caminhos errados

• Evitar pacotes/arquivos desnecessários em produção

• Evitar versões diferentes dos mesmos módulos em caminhos diferentes

• Criar pacotes

16

TESTES

17

TESTES

•Máquinas de homologação e desenvolvimento na monitoração

• Usar gráficos de monitoração como evidência de teste

•Documentar para que outros possam reproduzir seu resultado

18

TESTES

• Tempo de teste

• Testar o que não funciona

• Testar com componentes fora do ar

•Quantidade de requests esperados em produção?

19

TESTES

• TCPDump

•Número de requests X Requests simultâneos

• Evidências de teste

•Métricas úteis, ex: tempo de resposta ao invés de CPU Idle

20

SEGURANÇA

21

SEGURANÇA

• Nunca rodar como ROOT

• Nunca colocar no sistema de versionamento informações como: credencias de acesso, logins, senhas, API Keys, etc

• Separação em componentes = Liberdade para Operação utilizar redes distintas

• Logs de auditoria, se necessários

• Regra de Apache != ACL

22

BANCO DE DADOS

23

BANCO DE DADOS

• Utilizar da melhor forma possível, não porque “é mais fácil”

• Separar leitura e escrita

• Utilizar o banco relacional para o que ele faz melhor: integridade e transação

• Envolver AD no projeto

• Stored procedure?

24

BANCO DE DADOS

• Usar ORM para tudo? (Black Magic)

•Otimizar query. Se o ORM não permitir... você está fazendo errado!

• Sua aplicação deve se adaptar ao modelo de dados

• Índices

• Atenção com colunas “auto increment” + replicação do MySQL

25

BANCO DE DADOS

• Alternar automaticamente para um banco de Stand-by

• Reconectar automaticamente

• Usar filas, o banco falha!

• Cache e Replicação: “The good, the bad and the ugly”

• “Architectural anti-patterns for data handling” - http://www.slideshare.net/gleicon

26

CONFIGURAÇÕES

27

CONFIGURAÇÕES

• Fora do jar, war, egg, gem...

• Possibilita automação

• Possibilita auditoria

• Possibilita versionamento

• Flexibilidade para operação

28

BACKUP

29

BACKUP

• “Minha aplicação precisa de backup”

•Qual a finalidade? Desastre? Restaurar um único registro?

• Teste de restore

• Segurança

• Tempo de retenção e vida útil da mídia

• dump/restore dentro da aplicação

30

FALHAS

31

FALHAS

• Falha elegante e rápida

• Apresentar menos funcionalidade ao invés de “Erro 500”

• Recuperação automática

• Conectar em múltiplos backend

•Distribuir carga

32

BALANCEAMENTO DE CARGA

33

BALANCEAMENTO DE CARGA

• Aplicações que respondam ao teste do SLB

• /status => 200

• Possibilita testar uma máquina sem que ela esteja ativa para o SLB

• Entender os algoritmos disponíveis

34

INTERFACE PARA OPERAÇÃO

35

INTERFACE PARA OPERAÇÃO

• REST + JSON

• Ferramenta CLI

• Limpar cache

• Reconectar no banco

36

INTERFACE PARA OPERAÇÃO

• Controlar processamento de fila

• Colocar aplicação em “read-only”

• Controlar recebimento de requests

• Controlar o /status

37

MONITORAÇÃO

38

MONITORAÇÃO

• REST + JSON

• Ferramenta CLI

• Versão da aplicação e das dependências

• Conexões com backend, banco, cache, uptime, etc

• /monit

39

MONITORAÇÃO

• Usuários ativos

•Operações com erro, sucesso, etc

• Tempo das operações: média e desvio padrão

• Tipos de requisição: get, post, etc

•Número de itens na fila, tempo de processamento, etc

40

EU NÃO PRECISO SABER...

41

VOCÊ PRECISA SABER QUE:

• Existe um sistema operacional embaixo do software

• Existe rede e storage fora do software

• “System” e similares somente em situações extremas ou de licença

• “Eu programo em <...>, roda em qualquer coisa”

•Memória, processamento e disco são recursos finitos

42

DICAS

• “Bringing a knife to a gunfight”

• Você define os requisitos

• “Quando você só tem martelo, tudo é prego”

• Framework?

•O universo conspira contra você

43

DICAS

•Discos mentem

•Memória mente

•Máquinas falham

• VM’s mentem mais ainda

• “Diminishing returns“

44

DICAS

• Gerar logs se a aplicação permitir, antes do restart

• Apagar incêndio = restart

• Testes simples: ping, date, route, dig e df identificam a maior parte dos problemas

45

PERGUNTAS?

46