Dev vs Ops team and DevOps anti patterns

In this video from Puppet conf Roy Tyler talks about important aspects and rules that sysadmin, engineering and devops teams do and follow. He gives many examples and tries to explain the principles that lead into many bad ideas within organisations when it comes to run operation, engineering or devs teams. He calls the bad ideas ops anti patterns. The full video can be found here: We'll Do It Live - Operations Anti-Pattern. Below are couple of notes I took when watching it :).

• ~4.20m; use configuration management; we are in transition and your infrastructure should be treated not different than a software code
• ~6.00m; use automatic testing
• ~7.40m; if your infrastructure is treated as code please do implement a release management process
• ~8.40m; scripts written by ops team are a great way to start but without some good software engineering practices it doesn't work in long time
• ~9.20m; don't use root user for code deployments into production but rather a well known good tools design for it 
• ~11.40m; Ops team tends to be reactive instead of proactive; this is dangerous because your SPOF (single point of failures) are changing as your application matures and gets more complex
• ~14.30m; dev team may take care of HA in software but there is a lot more that needs to be done on the infrastructure level as well; dedicate resources or highly skilled contractors to work on it as soon as possible
• ~14.40m; HA is never extensively tested so failures should be expected
• ~15.30m; when building in cloud you have to assume that everything, I mean everything is going to fail
• ~16.00m; make sure that your alerting system is not over logging
• ~18.45m; this sysadmin attitude is wrong: never touch a running system
• ~19.30m; use continues integration to minimize long-term risk
• ~21.40m; isolated silos like a separate dev and ops team that don't talk to each other is wrong
• ~24.30m; share the necessary information about your production to developers
• ~25.00m; strict control is an enemy of creativity
• ~25.30m; too much IT and ops control will lead to wrong and bad workarounds
• ~26.50m; silos and poor communication will lead to waist of resources
• ~29.00m; don't jump and use the hype-bla products/tools only because they are popular on Internet; by choosing the right tools you have to evaluate a risk between:
• from personal experience knowing the bad design and limitations the old tools have vs
• knowing the advantages the new products have from only reading about them
• ~30.40m; don't invent tools in house before you evaluate potential solutions
• ~33.50m; don't build your own packaging system; use the one that opensource or some vendors offer
• ~36.40m; don't netboot all our hardware; there is a reason the servers have local disk that can be used
• ~39.20m; don't delete your production data to test your backup
• ~40.30m; don't trust your vendor
• ~43.00 don't use multi data center deployments if your application is not ready for it; use other methods to implement disaster recovery if needed
• ~45.00 have a centralized location for code that is used for production deployments

References

1. http://www.agileweboperations.com/devops-anti-patterns
2. http://unethicalblogger.com/2012/10/09/video-well-do-it-live.html