Ideally, for an operational production database, you don't want developers having any access to the server or any database on it at all. That sort of thing is one of the first things you'll have to do for SOX compliance.
For the sort of rights that userIDs run under, the only rights they really should have are
db_datawriter and explicit
GRANT EXECUTE ON x TO y (for each stored proc and user defined function
x for the userID
If you need to be running traces in production, you have some problems and it will take a Great Wall of Text™ to explain it all. My first recommendation is to have a QA environment that is locked down just like production and if traces need to be run, restore a back-up of the prod db to QA and run the traces there. Again, if you have SOX, HIPAA or PCI-DSS requirements, then you better sanitize the prod data before restoring it to QA.
We currently have a windows group for DBAs that has rights to all of our servers and databases.
Give them logon and view data rights; however to perform DBAly duties, use a separate login with elevated privileges. I know one financial customer that does this - the regular windows authentication based logins were limited in the damage they could inadvertantly do. Restores and running DML required running with the separate SQL authentication login.
One government agency I worked with used 2 separate logins for each server/db admin. So if
Tangurena was my domain login (this login would have regular
User privileges), then
TangurenaAdmin would be my separate
Administrator login. You get into trouble if you use your admin account all the time, but then it lacks permissions to other things (like no email. Oh, you say that like it is a bad thing...).
The current government agency I'm working with has each server/db admins having privileges elevated above the standard user, but not quite admin (think of it as the
PowerUser group). Domain admin functions are performed with a shared domain admin account.
A common error is restoring the wrong database (like QA restored over the production server), and this isn't going to be solved via restricted rights or multiple logins. Doing potentially destructive things in pairs is one way to minimize the risks.
I'm guessing we'd need elevated privs to run traces as sa
No. You only need ALTER TRACE permissions: