I just came across Something is burning in the server room; how can I quickly identify what it is?. In the comments I found the following quote:
you don't let a developer anywhere near your root passwords
As a developer but also someone very interested in sysadmin stuff, I'm wondering if there's anything to this phrase more than just the standard for everyone - that is, don't give away passwords? The commentor states this as though it's fairly common knowledge in the sysadmin community. Is it?
Answer
I am not saying sysadmins are perfect, but there are a huge number of examples of developers that shouldn't even be developers. Let alone being permitted to having root access to systems with mission critical data.
But in any case it is mostly about taking responsibility for changes made. For many sysadmins it seems that developers will go do things on servers, and then they do not take responsibility for what they have done. Developers are often only focused on getting the single program/task they are working on going, and don't take the time to think about the big picture or long term state of the system they are touching. They haven't learned habits about how to make changes safely.
These aren't true for all developers, there are certainly some great developers that can maintain systems just fine. It just often seems like these are true 95% of the time.
Habits like:
- Don't make changes to a system without testing on dev systems first
- Don't make changes that you don't understand (blindly Googling, and doing things you don't understand)
- Don't make changes without verifying that you know that the backups systems are working, and how to roll back anything you do.
- Don't make changes that will make the system more difficult to maintain in the long term. (ie, don't add any technical debt)
- Don't compromise the security of the system
- Don't change the system in a way that will increase the potential regulatory risk (see PCI-DSS, HIPPA, FERPA, etc)
No comments:
Post a Comment