O documento discute como melhorar a relação entre desenvolvedores e operações, propondo que equipes adotem automação, testes, educação sobre arquitetura e segurança, além de gestão de orçamento e limites de performance. Ele também lista algumas "Regras de engenharia" como não ter problemas, que hacks são permanentes e que segurança, disponibilidade e performance não são negociáveis.

1. Arquitetura Emergente
(é sobre cultura)

2. https://github.com/gleicon
https://twitter.com/gleicon

3. O que você faz mesmo ?

11. Como azedar a relação entre dev e ops

12. "Aqui funciona..."

13. "Eu só trabalho aqui"

14. "Vamos fazer na mão agora e depois priorizamos a automação/testes"

15. "Está lento ? Defina lento. (Ou defina performance)"

16. "Ajuda com problemas em produção ? Vamos discutir no planning e te falo."

17. "Vou trocar você por um script."

18. Angustias
Velocidade -> Modelo tradicional: cada coisa que preciso = 10 tarefas/tickets
Independencia -> Segurança para tentar algo novo, resolver incidentes
$$ -> Avisos quando passarmos do limite seguro, gestão de budget
Segurança só diz não -> Educação para se proteger
Só pode usar o que é homologado -> Educação sobre arquitetura para todos
(tech talks, projetos opensource, hackdays)

19. Regras de engenharia
1. A melhor solução para um problema é não tê-lo
2. Hacks são permanentes (principalmente os feios)
3. Não existe infraestrutura em stand-by: existe o que você usa e o que não vai
funcionar quando você precisar
4. A primeira falácia de automação é fazer máquinas executar passos de um
processo manual humano
5. Não são features (não são negociáveis): Segurança, Disponibilidade e
Performance.
(http://blog.b3k.us/2012/01/24/some-rules.html)

20. What would you do if you weren't afraid ?