Databases
cancel
Showing results for 
Search instead for 
Did you mean: 

Servcie Level Agreement between SA's and DBA's

Servcie Level Agreement between SA's and DBA's

Hi,

I have been tasked with creating an SLA between DBA's and SA's. I am a DBA, have been an SA in the past. The SA's have some policies and procedures (change controls) in place but no firm SLA. I would like to know if anyone out there has created an SLA from the DBA perspective. In other words what should we require of our SA's.

Would you be willing to share your SLA, or just your thoughts?

Thanks,

Steve
13 REPLIES
Tom Geudens
Honored Contributor

Re: Servcie Level Agreement between SA's and DBA's

Hi,
Just the point of view from a former DBA (now SA).
We had the same problem, but if you look at it from some distance, making a SLA from either point is wrong ! Let's face it, what are you bringing "down" when your modifying systems or databases ? Your bringing down applications. Who are using these applications ? EndUsers. Who is paying for the uptime of both databases and machines ? EndUsers. Who should (logically) be making the SLA requests ? Right :-).

For our retail-servers, SLA is during retail hours, for internet-servers it's 24x24,7x7, and so on. All depending on the requested SLA (and they are PAYING for it offcourse) of the EndUsers.

Just my 0,02???
Tom Geudens
A life ? Cool ! Where can I download one of those from ?

Re: Servcie Level Agreement between SA's and DBA's

Agreed and we are working on those as well. However we are having great difficulties with our SA group agreeing to perform the work we request.

We need some agreement in place that outline our deliverables to the SA's and theirs to the DBA's.
A. Clay Stephenson
Acclaimed Contributor

Re: Servcie Level Agreement between SA's and DBA's

Hi Steve,

I've never drafted a SLA between DBA's and SA's and I doubt that I ever will. It seems to me when things have reached that point that both groups have missed the boat. The groups should be complementary rather than adversarial. A few points need to accepted by both sides: 1) There is a need for scheduled downtime - pay me now or pay me big later. 2) Violate Rule 1 and there will be unscheduled downtime. 3) Each group MUST know what the other is doing. 4) Scheduled downtimes should last no longer than the time requested. 5) DBA's should know some UNIX; SA's should know some database. 6) In many cases, no amount of OS/DB tuning will fix the real problem - bad SQL code.

It's usually Rule 4 that leads to the most trouble. You ask for 2 hours and you are not back to production 8 hours later. Nobody really cares if it the the DBA's fault or the SA's fault. The stuff ain't working. Here is my solution for that (it sounds expensive but it's cheaper than almost anything else).

You need a 3-tiered approach: 1) A Sandbox - anything goes on this puppy. New OS's, patches, new Oracle releases, wild and crazy code and backup schemes. 2) A Test box - this is where you keep a fairly recent copy of production for code development and problem resolution. 3) Production - keep your hands off unless agreed by all. Only after changed are bubbled up from the sandbox and test are they allowed on the production box and only when scheduled.

Food for thought, Clay


If it ain't broke, I can fix that.
Krishna Prasad
Trusted Contributor

Re: Servcie Level Agreement between SA's and DBA's

I am glad that I have been asked to both roles in the past. So, when I need the SA to do something. I call myself. When I need the DBA I dial my extension.

I was also lucky that when I wasn't wearing both hats. Both the SA's and DBA's both report to the same boss.

I know this does post gives you nothing of value, but just my two cents. The two groups should work for the same boss.
Positive Results requires Positive Thinking
Tom Geudens
Honored Contributor

Re: Servcie Level Agreement between SA's and DBA's

Hi,
Seems I misunderstood the question :-). The particular situation you're talking about is known to me as well. I have no idea what the actual situation is at your site but over here it gets pretty "hairy" now and then.
Let's see what we got over here to solve this :
- For tasks that are part of a bigger project the problem is solved by making sure the projectleader is neither SA or DBA. It's then up to that "third" party to say when a task should be done.
- For tasks that take less than 2 hours, we've got a "speedy" in both groups. Speedy does those tasks within the very same week (and most things the very same day). The person that is the "Speedy of the week" does NOTHING else but speedytasks. Important is strict rules about the tasks that are "caried" to the next week / the next speedy.
- Tasks that take more than 2 hours (as well as the bordercases) are bumped up to the SA-boss and the DBA-boss. They have a meeting (at least once every week) where those tasks are brought up, are given a "date ready" and assigned to a specific SA / DBA.

Another approach that we are trying is dividing the DBA function in Infrastructure / Application. The I-DBA's are still DBA's, but also get a SA-course. They make their own machines, create their own filesystems, mount their own CD's, are responsible for DB-performance, DB-creations, DB backup and recovery, ... and so on. The A-DBA's are responsible for the data in the database.

Hope this helps,
Tom Geudens
A life ? Cool ! Where can I download one of those from ?
Ravi_8
Honored Contributor

Re: Servcie Level Agreement between SA's and DBA's

Hi,

I am doing both the jobs(SA and DBA) so whatever the problems comes i look in.
never give up

Re: Servcie Level Agreement between SA's and DBA's

Thanks everyone,

I think Tom is seeing where I'm coming from. We are separate groups managed by separate managers. Unfortunately the SA side sees us as more of a pain in the "A" then as their customers. I like the idea of an objective PM to manage crossfunctional tasks. If we had the resources to do it that would be great.

We have some significant Unix talent in the DBA group, several of us have worn both hats in the past, however our SA's insist on treating us like novice users. They don't seem to trust us to use the resources wisely.

For instance, we have a development system with database names hardcoded in the mount point names, the SA creates 6 new mount points of a predetermined size for every database added to the system, there are 70 mount points on the system currently. Is the db size changes the MP sizes do not. This results in a tremendous amount of wasted space, not to mention we need to give at least a one week lead time when creating new databases. That slows our developers down and adds needless complexity to the process. We have asked for a reduction in mount points in order to improve space usage.

We are trying to make better use of our systems and, I might add, make the SA's life easier in the long run.

This week we were asked to create and sign a document that stipulates we are to maintain all disk space by cleaning up unwanted files, accurately sizing our db's and maintain log files, all of which we already do. I'm sorry to say that this document is what is driving our desire to have an agreement in place between groups. It seems to us we are being asked to better maintain the systems by the same folks who made bad decisions about system resources in the first place. So we're wondering how to word an agreement that requires sound practices from the SA group as well.

I know that's a mouthful but you can see the unfortunate, adversarial position we're in with the two groups here.


Paula J Frazer-Campbell
Honored Contributor

Re: Servcie Level Agreement between SA's and DBA's

Hi Steve

Having seen it from both sides I am sure that you can appreciate the SA main role is to protect the machine from excessive downtime, and whilst you may have high Unix skills within the DBA team if the system falls over because of an error, then even if a DBA did it the SA will take the flack.

The SA normally works to an undocumented SLA to keep the servers up and running in a good state of health.

From the DBA point of view you require changes made to reduce mount points an release space and you see the SA as a barrier.

What I suggest you do is all go down the local drinking establishment and talk to each other and resolve this very silly state of affairs.

You are all working towards the same aim but pulling in opposite directions.

Two teams ??? yes but take to each other.

Sorry if this seams harsh, but I encountered this in my present company three years ago and it took me a long time to get to the very pleasant situation we have now.

Paula
If you can spell SysAdmin then you is one - anon
Paula J Frazer-Campbell
Honored Contributor

Re: Servcie Level Agreement between SA's and DBA's

Sorry
Should read:-


Two teams ??? yes but talk to each other.

Paula
If you can spell SysAdmin then you is one - anon

Re: Servcie Level Agreement between SA's and DBA's

Not harsh at all Paula. It's not that I disagree with anything being said here. It's just that I've been asked to create a document outlining the services the DBA's should expect of the the SA's. I am sure the reverse will be requested as well.

In all liklihood the document will generate some interest amongst management to solve the problem once and for all.

Thanks to everyone who contributed to this posting.

Steve
Krishna Prasad
Trusted Contributor

Re: Servcie Level Agreement between SA's and DBA's

Interesting that you stated management knows of the problem and they are asking you to reslolve the problem. My question is what is management doing to fix this problem?

Shouldn't management setup the structure for the two groups to work together and support your business and end-users?
Positive Results requires Positive Thinking

Re: Servcie Level Agreement between SA's and DBA's

That would certainly be true in a perfect world. I'm not going to go there though.

I'm just going to draft a document that is more roles and responsibilities related than service level related. I'll run it up the flagpole and see what comes of it.

I think if I define those terms then we can begin to talk about where there is cross-over and about areas where one side or the other has primary responsibility.

Thanks everyone!

Steve
Jon_7
Occasional Advisor

Re: Servcie Level Agreement between SA's and DBA's

Steve,
I recommend backing away from the DBA/SA trees so you can see the forest. Most SLA's are about percent up time, and response time. I see few people talking on this subject. Maybe they have never worked on an SLA document before but it entails: uptime percentage and what happens, if it is violated, provisions for all parties envolved clearly defining duties, before,during and after outage, including outage reports and accountability. A system in place to provide for scheduled downtime and people responsible for signing off on the downtime, if they sign off and complain later too bad. I recommend a structured aproach involving the customers, (end users), Management of all parties, and looking up what an SLA looks like for other more developed fields like networking/telcom. Also outages require Mean Time to Repair, and reports for preventing them in the future. I hope some of this was helpful. Good luck.

They don't have a certifications for being a creator, and just having the bigest IT magic wand, ccie is close, but not till they drop token ring and add, PoS, I designed asics/systems/code, implementation and training, from hw/ to sw, just do it.