April 22, 2015 at 9:38 pm
Comments posted to this topic are about the item Your Role Is Changing
April 23, 2015 at 6:30 am
We're so small our DBA is also a developer. Our collaboration is just fine.
April 23, 2015 at 7:35 am
I had to read this to understand what a DevOp is:
http://en.wikipedia.org/wiki/DevOps
I've consulted at many corporate headquarters and found most of their databases designed at a kindergarten quality level. The DevOps article seems to focus on stepping up that level of quality of delivered code while the editorial here seems to focus on collaboration. Both are necessary for a DBA to stand out today. In my opinion, a DBA that isn't generating most stored procedures is wasting their life on ugly details. Also I believe the Information Age is gone and we have been in a collaboration age for many years already. A DBA should be half individual and half team focused in order to maintain responsibility yet give some freedom to allow the team to evolve.
April 23, 2015 at 8:50 am
Bill Talada (4/23/2015)
In my opinion, a DBA that isn't generating most stored procedures is wasting their life on ugly details.
I couldn't disagree more. Our developers are perfectly capable of writing stored procedures. I am more than happy to help them tune them, but they can write there own. As a DBA I have more important things to do than spending even 10% of my time writing procedures. I have spend a lot of time automating tasks, but even when things are automated there are still a lot of things to look at.
April 23, 2015 at 10:12 am
Patrick Cahill (4/23/2015)
Bill Talada (4/23/2015)
In my opinion, a DBA that isn't generating most stored procedures is wasting their life on ugly details.I couldn't disagree more. Our developers are perfectly capable of writing stored procedures. I am more than happy to help them tune them, but they can write there own. As a DBA I have more important things to do than spending even 10% of my time writing procedures. I have spend a lot of time automating tasks, but even when things are automated there are still a lot of things to look at.
IMHO, I think Bill may have been saying that a DBA should write a lot of stored procs FOR automation, to automate all possible DBA jobs in order to give himself more time for the real, proactive problem-solving.
Sigerson
"No pressure, no diamonds." - Thomas Carlyle
April 23, 2015 at 12:44 pm
For many of us, the role hasn't changed, it's just been defined using a new acronym, which makes it a lot easier if someone asked what we do.
DevOps, I do that.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
April 23, 2015 at 1:45 pm
Either way, as a DBA, you have to adapt. So how can you start changing? Go to one of your developers, or heck, attend one of their meetings and ask them: "How would you like me to collaborate with you?"..
Did that once and they all wanted SA privs! Yeah,a s if that was going to happen!
April 23, 2015 at 1:56 pm
And did you ask what they want to be able to do?
April 23, 2015 at 1:59 pm
stakes (4/23/2015)
And did you ask what they want to be able to do?
"just in case we need it!"
Where/when would you let developers have SA privs?
April 23, 2015 at 1:59 pm
stakes (4/23/2015)
And did you ask what they want to be able to do?
I think every DBA should sit down with the application development team at least once a year and ask this question... just for kicks. 😛
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
April 23, 2015 at 2:11 pm
If a database architect, IT support, executive, or BI developer needs eleveated permissions to troubleshoot performance issues or run ah-hoc queries in production, you can setup something like a power user role, but NEVER grant them SYSADMIN or DBO membership.
use SpecificDatabase;
-- grant select on any table or view:
exec sp_addrolemember db_datareader, 'DBPowerUsers';
-- grant user permission to view execution plans:
grant showplan to 'DBPowerUsers';
-- server level permissions require that context be changed to [master] database.
use master
-- grant user permission to view object schemas:
grant view any definition to 'DBPowerUsers';
-- grant user permission to view system tables and views:
grant view server state to 'DBPowerUsers';
-- grant user permission to start sql profiler traces:
grant alter trace to 'DBPowerUsers';
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
April 23, 2015 at 2:40 pm
Steve JP (4/23/2015)
stakes (4/23/2015)
And did you ask what they want to be able to do?"just in case we need it!"
Where/when would you let developers have SA privs?
Nowhere/never. "just in case we need it!" is obviously no answer. You could have aswered something like "let me know when you have a case where you need sa privs and I'll grant them" in return. I'll bet they come up with whatever they can think of and you can then grant them the specific permissions they need for what they want to do.
In which environment(s) do they want sa privs?
April 23, 2015 at 2:46 pm
Eric M Russell (4/23/2015)
If a database architect, IT support, executive, or BI developer needs eleveated permissions to troubleshoot performance issues or run ah-hoc queries in production, you can setup something like a power user role, but NEVER grant them SYSADMIN or DBO membership.
use SpecificDatabase;
-- grant select on any table or view:
exec sp_addrolemember db_datareader, 'DBPowerUsers';
-- grant user permission to view execution plans:
grant showplan to 'DBPowerUsers';
-- server level permissions require that context be changed to [master] database.
use master
-- grant user permission to view object schemas:
grant view any definition to 'DBPowerUsers';
-- grant user permission to view system tables and views:
grant view server state to 'DBPowerUsers';
-- grant user permission to start sql profiler traces:
grant alter trace to 'DBPowerUsers';
Good point and thanks for sharing the script! Granting them access to a readable secondary can also work.
April 23, 2015 at 2:55 pm
If users demand access to the 'SA' account, then give it to them.
But first get rid of the default 'SA' and then create a new one having only the permissions you're willing to delegate. In the example below, we're renaming 'SA' to 'SA_BAK', and then re-creating 'SA' as a member of the 'DBPowerUsers' role.
They can now login using their vanity 'SA' account and feel important. Unless they attempt to create, drop, or update objects, they won't know the difference.
use MASTER
go
alter login sa DISABLE;
go
alter login sa with name = [sa_bak];
go
create login sa
with PASSWORD = 'F5G8T9V0K1'
, DEFAULT_DATABASE = master;
go
use Accounting;
go
drop user sa;
go
create USER sa for login sa;
go
exec sp_addrolemember 'DBPowerUsers', 'sa';
go
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
April 23, 2015 at 6:58 pm
My last DBA position was in the Operations part of a DevOps shop.
The company's implementation of DevOps was a colossal failure in several respects:
1. The ROI for the huge expansion of communication between departments was low,
2. The amount of energy expended on communicating was high (and mostly wasted), and
3. In general, the DevOps environment produced much frustration and hand wringing because real progress occurred at a snail's pace. We could talk much faster and farther then we could execute.
The shop claimed it was Agile, but only in name. Development was Agile, but nothing else. (But which version of Agile? That's a discussion in its own right.)
It had a CMS (Change Management System) in place that moved very slowly while the level of communication far outpaced it.
The email flood was unbelievable. With every new employee added, the explosion of emails increased exponentially because increased communication is a core tenant of the DevOps "model", and everyone communicated like they "were supposed to".
In summary, talking, writing, and hand wringing were substitutes and energy consumers for real progress. Communication was out of balance with other processes to meet objectives.
There are optimal levels of communication to accomplish real work. Communication for its own sake is not progress and ultimately, counter productive.
There may be other shops that have implemented DevOps successfully, but my last experience with it has left me very wary of it.
Like Agile, DevOps sounds good, but since it is poorly defined (like Agile), people make it up as they go (like Agile).
IMHO, both Agile and DevOps are good ways to avoid real planning which is hard work. Everyone is busy, busy, happy, happy, but doing what? Just busy.
In 30+ years in IT, I've seen many ideas come and go. Like a lot of things in I.T., I predict DevOps is a fad that will come and go, mostly go.
Viewing 15 posts - 1 through 15 (of 31 total)
You must be logged in to reply to this topic. Login to reply