Servcie Level Agreement between SA's and DBA's

[Steve Barlow_5]

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

[Tom Geudens]

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

[Steve Barlow_5]

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]

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

[Krishna Prasad]

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.

[Tom Geudens]

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

[Ravi_8]

Hi,

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

[Steve Barlow_5]

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]

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

[Paula J Frazer-Campbell]

Sorry
Should read:-


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

Paula