Remote DBAs

  • SQL On Call

    There's still hope for all you DBAs out there looking for a telecommuting job that allows you to work in your pajamas. Someone sent me this case study about remote DBAs and I decided to pass it along. It's a one page PDF, and it's a fluff piece to some extent for Bluewolf, a company that has outsourced IT staffing, but has a section on remote DBA work as well.

    I've wanted a remote DBA company for a long time. It's something I thought was easy to do, most all DBA work is remote to the server anyway, and we tend to work alone. It's a specialized skill and for the most part, a production DBA is an insurance cost.

    Face it, as a production DBA, I've typically had periods of time where we work really hard on upgrades, stabilizing systems, responding to issues, etc. Then we have some fairly quiet periods where we work on tuning things that don't work well. There are definitely exceptions for environments that are understaffed and have perpetual problems, but a lot of the time we are insurance for the bad times.

    Which makes for a pretty good job.

    I've usually enjoyed my jobs; they haven't had too much stress on a daily basis, and I could handle the tedious nature of production systems. If I had 4 or 5 of these jobs I did from home, that would be amazing. I've just struggled finding managers that were comfortable with a DBA working from home 3 or 4 days a week. For some reason they just want to see you there every day.

    There are definitely jobs and companies out there making this work. A few friends of mine from Colorado Springs even have a company that does this: SQL On Call. They can help in many areas, but they're happy to fill in for a DBA on vacation. If you're a one-DBA shop, give them a call. I know, it's a plug, but I have no affiliation. They're friends of mine and good DBAs.

    If you want to telecommute, especially on a part-time basis, be sure you save the case study link along with any others you come across. A lot of preparation and good evidence that it works will go a long way to convincing your boss to let you try it.

  • quoteThen we have some fairly quiet periods where we work on tuning things that don't work well.

    Heh.. thought you didn't spend anytime tuning... thought you always bought hardware so you had time to ride your horse

    I agree... if you're a "Systems" DBA, then there's no reason why you can't tele-commute except for the obvious periods of duress...

    But, if you're what I call an "Applications DBA", then you need to be at work as a mentor to the Developers and Systems Analysts (the kind that define what a project will consist of).

    We have both... our main "Systems" DBA actually lives way out in Oregon (we're in Michigan and North Carolina) and our "Applications" DBAs are on site most of the time.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • I like to think that managers who can't manage people who are working from home are bad managers.

    In my former job, I had to take sick-leave one time because my wife's pregnancy wasn't going as planned and she had to be admitted to hospital. I had to be at home to watch over our oldest one (3 years old at the time). It was a bad time because we had several major projects going on at the same time and all the work culminated in this period. So I organized a VPN connection to our company network from my home PC and managed to setup the ODBC connections I needed. Luckily, the company had installed web-based e-mail a few weeks before and I was allowed an account. For three weeks, I did all the work I would normally do at the office just using MS Query. In fact, I got more of the structural work done because nobody was bugging me with issues all day and I was able to save those things for the evening hours. When I came back to the office, I discussed this with my manager but there was no way to convince him. He just didn't TRUST me doing my job remote and he wasn't able to define the criteria whether or not I had been productive enough.

    And that's the whole thing: It all depends on defining the right goals and the right criteria to measure if these goals are met.Typically, salespeople are allowed to work from home easier. Not just because they need to be mobile, but also because it's easy for them to demonstrate their effectiveness. Sales and profit are being measured everywhere. How do you define the effectiveness of a DBA ?

    A second point here is that salespeople are more used to having to account for their well doing. They can sell themselves as easy as the products or services they're selling. For us techies, that's not really part of our nature, at least not for most of us.

  • Let's not forget the issue of security.  Do you really want highly confidential information left on display in the kitchen of your remote DBA while he runs to help a child with a cut finger?  The simple fact of the matter is, people will have a more relaxed attitude to security when they work from their own home, because it is only human to believe that home is the most secure place on earth -- by definition.

    There is still no affordable and 100% reliable way to guarantee that when you see "Bill" remotely logged in on a server that it is in fact Bill sitting at the screen, whereas if Bill is in the office and you've implemented physical access controls, you just go and look.

  • I have worked from home in the UK (more systems DBA than applications) since 1999. It wasn't seen as a big deal as my work had become remote even when I was office based. I like working from home although it doesn't suit everyone in the long term. I still feel part of a team even though my closest colleagues are 3 hours away. The phone, IM and netmeeting type tools help, we've been using them for years with company approval, so there are some enlightened companies out there. Referring to the previous post I don't see security as being an issue providing there is appropriate technology in place  (VPNs / secureid cards etc) to track remote access. If I hacked my companies systems I would be traced.

  • I have been a DBA / Developer for about a decade.  During this time I have been on both sides of the fence - a manager of up to 14 people, and a (happily) simple employee with my head down doing work.  From a management perspective, I have never had a problem with people working from home on a regular basis.  I have one consultant workng for me now that is home three days a week.  He is good at it and gets his work done.

    However, I have found it difficult for myself to work from home more than one day a week.  I feel I lose a sense of urgency that comes with production issues.  Yes, from anywere I can see it is important when a server is down, but if I am not in the office listening to people, I don't get a good feel for which applications are not working well.

    Working remotely is a great perk for the type of work we do, but I think it really needs to be handled well and at least some time every week needs to be spent in the mix wih the users or work product degrades very quickly.

  • Works fine for a stable software enviromnent, but who has that?

    One problem is that, like it or not, most development projects include meetings with a mixed bag of systems engineers, developers, business managers, and a dba or two. Usually somebody gets up and starts drawing servers, databases, code, business processes, etc on a whiteboard.  OK, OK, there are technical workarounds, but having a dba physically present is a good thing.

    Another problem is that sometimes developers or systems folks need a very quick answer to a question to keep everybody else on a team working. My experience in working with remote consultants is that they are often committed to other customers as well. Phone calls, emails, IM's are not returned within a couple of hours. A couple of hours times each person working on a project equals a lot of team hours.

  • Remember...

    If your job can be done from home, it can be done from India.

    ...

    -- FORTRAN manual for Xerox Computers --

  • A remote DBA IMO is valid only for non-confidential *and* stable environments. Most places I have seen have one or the other but never *both*. The weakest point of hiring an "external" firm (in my view ) is that still you will have to train that DBA in the processes and workflows of the place and if the location is very dynamic the costs will be considerable. In otherwise very slowly changing environments it does makes sense *as long as confidentiality is *not* an issue.


    * Noel

  • In my past job for a large global company, I exclusively worked from home for 7 years.  I was both a development (application) DBA and a production DBA.  We also had development DBA's in India and all over the world.  The fact that we had many people in many places made it easier to work from home because the infrastructure was in place for security, conference calls, instant messaging...  I think that if the infrastructure is there and management supports it then it is worth it.  However many small companies do not have this benefit, so it all depends.

    The one drawback is that everyone knows you work from home so they always call you even when you are not supposed to be working.  However, I don't know many DBA's who are not supposed to be working.

  • I think remote DBA would be much better solution and I would trust them to do a good job than some internal DBA, at least they would response much faster, otherwise they would lose the contract. As for the confidential data concerned, they had to sign the confidential agreement just liked the rest of the internal employees.

    My former company had three SQL Server DBAs. They had a schedule that every week one DBA on call, one DBA worked at home for two days and another DBA worked at the office the whole week. So if something happened it was off hour, we called the on call DBA, since all the developers could not see touch the production database, that meant we could not even see the DTS packages, jobs and anything, we depended on the on call DBA to find out what happened, the average time that the on call DBA returned the call was 45 min to 1 hour !!!!! How efficient!!!!! The other two DBAs supposed to be the backup, you could never find them, especially the one worked at home, you could not even able to contact him even at office hour.

    One time the whole department had a "OFF SITE" team building meeting. One of my production job went down. We tried to call every DBA including the on call DBA for four hours, and no one returned any phone call. Of course I could not fix the production problem. The next day I went to complain to the DBA manager and he said I did not follow the production problem tracking procedure. I went to find the person who took care the problem tracking system and he said I did the right thing but the DBA manager insisted that I did something wrong.

    When the on call DBAs did not return the call, the DBA manager actually was on their side. Yes he was a good manager, lousy to the users though. Ironically the DBA manager wrote a book called 'You're Fired! Firing Computer Professionals: The IT Manager Guide for Terminating "With Cause" '.

  • Some great points being brought up and I agree there are definitely problems and challenges. However picking a remote DBA firm isn't like hiring an electrician or plumber for the day. It's something you enter into for the long term, with the idea you'd use the group regularly.

    And for smaller environments, even if they don't know everything, they can provide some valuable peace of mind for a DBA going on vacation (for both the company and employee), especially if he/she's one of 3 or 4 in the IT department.

  • I'm actually VERY interested in those on call DBAs.

     

    I'm a single DBA shop and when possible prefer to handle development more than administration.  I'm confident that my servers are safe and secure, but I KNOW that I'm working harder than I have to with tasks that should/could be automated and there are some areas related to analysis and integration services that I don't know nearly enough about.

    Has anyone used this consulting firm, or have a rough idea of their prices?

    I wouldn't be against calling them and having them remote in and go over some server configuration, and "double check" my servers to make sure I wasn't doing anything blindingly career endingly stupid

  • I know the people running the company and they're solid DBAs. No idea on rates, so ping them and see what they offer.

    Search on Google as well and call a couple others.

  • I've been working as a "Remote DBA" for the past nine months and we have clients across a very broad spectrum. Retail, Finance, Legal, Automotive, Travel, etc...

    Each client has their own requirements in terms of security. One client does not allow us to plug in any equipment or install any software. Another just hands us the proverbial keys to the server and expects us to deal with any issues that arise. We also use about five different VPN solutions, including ones with security tokens. A few of our clients also have us onsite on a regular basis.

    From my point of view this job has been the best move of my career. I've come across many varied installations of SQL Server, many of which I wouldn't have had exposure to in a regular DBA role. I get to look after a vast range of servers in many different environments. One client has a 24x7 db that is 100GB, another has 20 dbs with the largest being 2GB. Yet another client has servers in two countries with data replicated between them. We also act as a specialist support for companies that already have DBAs.

    --------------------
    Colt 45 - the original point and click interface

Viewing 15 posts - 1 through 15 (of 39 total)

You must be logged in to reply to this topic. Login to reply