Working as a Principal DBA in Coeo’s Remote DBA Team, I’m occasionally asked to talk to a prospective customer about how our team operates and to give them a technical overview of Coeo’s Remote DBA service. I’m often struck by how pleasantly surprised they are with what they hear about how we operate. Predominantly, this comes from the realisation that we support far more than they originally anticipated. This would indicate that their original expectation of what a Remote DBA Service offers is a little pessimistic.
I thought it would a good idea to provide a post in which I summarised the key things that you should be looking for when selecting a Remote DBA Service to manage your SQL Server environment.
Before I start, I want to clarify the meaning of a couple of terms:
A Managed Service is what is provided when you outsource the responsibility of proactively managing an IT service to a third party.
A Remote DBA Service, in the context that I discuss, is a Managed Service where the administration of a business’s database platform is being outsourced. The term “Remote” refers to the fact that service is provided remotely from that business’s premises.
I’d now like to dispel some myths that I've often come across about Remote DBA services:
I’ll often hear comments like “I’m not sure about a remote DBA, I’d like my DBA to be on-site”. In my view, all DBAs are “remote” DBAs in the sense that DBAs don’t sit in the server room next to the database server. Where they connect from (i.e. home, the office) is broadly irrelevant. The only difference you’ll find with having an “on-site” DBA is the ability to walk to their desk and ask them a question, face-to-face. That’s not to say that this difference is unimportant; but it shouldn’t necessarily detract from the effectiveness of an operational DBA.
Picking up the phone, sending an email or a chat message (choose your favourite messaging tool) is equally effective. And let’s face it, the times when you’ll need your operational DBAs the most will be in the middle of the night when your DBA in all probability won’t be sat at their desk so you’ll need to pick up the phone anyway.
In some respects, the remoteness does tend to enforce a stronger emphasis on clear, written communication, which can sometimes be otherwise overlooked in terms of importance.
The thinking behind this is that small companies have less of a requirement for a full-time DBA (and quite possibly may not provide enough of a challenge for one either), yet their business relies heavily on the availability and performance of SQL Server. A good Remote DBA Service provider should be capable of providing the same level of mission critical support for small, medium and enterprise-level customers. Whether the company has no DBA or 20 it should make no difference to the quality of service provided.
One of the major benefits of a managed service provider are the proactive parts of the service. Where a Remote DBA Service should really come into its own is in the provision of proactive monitoring that captures potential issues before they become incidents.
You'll need to know whether their monitoring can be configured specifically for your needs. For example, you may have a very important scheduled job and you need someone to investigate any failure or execution time that deviates from the norm - at any time of the day or night.
Asking this question is no different to evaluating the level of experience of an internally recruited DBA. However, what you should hopefully discover is that the collective experience of a team is far greater than what any one person could have, plus the deep specialist knowledge that exists across the whole team covers a far broader set of specialist areas (e.g. replication, disaster recovery, performance tuning, etc...)
This is quite important as you want to establish whether you'll be paying extra for long-running issues or for "burning" more than a certain amount of hours over the course of the year. A fixed price service inherently means that the service provider will be motivated in ensuring that your environment is stable and secure to begin with, thus continuously trying to minimise the number of issues that occur. This, essentially means that the service provider's priorities are directly aligned with yours (i.e. reducing issues, fixing them as soon as possible and preventing them from re-occurring).
It is surprising how this point is often overlooked or not considered important. However, determining the root-cause of issues is essential to an effective Remote DBA Service to prevent such issues from re-occurring. The answer to this question will also tell you a lot about the values of the service provider.
The number of support team levels that exist helps you understand how quickly issues can be turned around. If a provider has 2 or 3 levels then you can expect that the lowest tier might consist of a junior DBA who'd be capable of dealing with the initial triage of an issue and possibly resolve most of the simple cases. However, as the complexity of the problem increases, the problem might then need to be escalated. With each escalation, the time to resolution tends to be extended. On the other hand, a provider with only one tier of support means that the first DBA that picks up the call is most likely to already be familiar with your environment and is going to be the same DBA that resolves the issue.
This is becoming increasingly important, so you need to understand whether your service provider can work with you if the payment card industry’s PCI-DSS compliance is important to your organisation. This may include integrating with your existing security technologies and processes or providing their own to match your ways of working.
What you essentially want to understand with this question is whether the Remote DBA service is waiting for problems to happen, or proactively seeking out potential issues before they become incidents. Not only is being proactive important (to your needs and the service provider's) but it informs you about the maturity of the support organisation you could be dealing with.
Can you call up your Remote DBA service and ask them to investigate a performance issue that occurred at 6am last Saturday morning? Or can you ask them to compare the performance of your SQL Server between two separate dates or time periods? This relates to the previous monitoring question and shows whether the service provider is set up just to respond to alerts after they happen or whether there is continuous, background and detailed monitoring deployed to resolve issues that may never cause alerts to be generated.
A good service provider should be able to tailor their service to fit your needs. No single customer is the same and it's important to understand if you can have a say in what the SLAs around response and fix times are, rather than have them dictated to you.
Data Protection is a key concern for many organisations so knowing what data is going to be stored (if any), how it is used and stored, and where it is stored could be important to you. For example, many European countries have far more stringent data protection laws than other countries in the world. So the country in which the data is stored is also important to evaluate.
In an ideal situation, your Remote DBA service should be just an extension of your team rather than some external support provider that you call up whenever you have a problem. With this question you want to try to gain an understanding of how this integration would work.
This is very subjective question that only you can answer and you'll have to take into consideration the opportunity costs involved. For example, your existing DBAs may be able to focus on project-related efforts, knowing that the operational day-to-day management of the environment is been looked after. Alternatively, the simple provision of 24x7 support is exactly the value that you're looking for.
It is important to understand how the working relationship between your DBA and the service provider’s DBAs would work. Ideally, the Remote DBA team should become just an extension of your own DBA team.