A good defense against misconfiguration or unintended production operation (i.e. accidentally dropping the production database instead of test database) is indirection.
I'm not the world's biggest fan of configuration tools like Puppet or Chef, but what I like is that exclusive use of configuration management with version control provides the same level of introspection, history tracking, and review to infrastructure configuration changes as version control does for software projects.
With some work config management can also help teams of 2-20 with machine access, privileged or otherwise. Storing ssh public keys in config management, one per team member or using something like
locksmith or even LDAP to manage user access and keys means there's a paper trail of who has direct access to production systems and when.
There are situations where direct root access is necessary. Someone has to have the power to initiate configuration management when the system is brought up. And during operations incidents direct access may be required if the indirection layers are affected by the incident or the latency introduced by their use may be prohibitive.
Previous teams I've worked on allowed the development team to access production servers through a bastion host which, I expect, logs who accesses what.
In addition to good software protections having a culture that encourages "production buddies" (only access production when another team member can share your screen or sit behind you) can be really helpful in averting disaster because it puts two sets of eyes on production access.