Pythian has been a rapidly expanding company over the ten months I’ve been here. About a dozen new employees have come on during that time, making the total 40. I have a few observations on habits and qualities new DBAs can bring to their jobs.
Take on-call every day during business hours. During my first months, while I was not in the regular rotation schedule for evenings and weekends, I would make it my responsibility to take on-call during business hours as soon as I arrived at the office for every business day. As a new DBA, I didn’t necessarily know how to respond, but there was a whole team behind me that could help me out if I didn’t find an answer in our groupware. The practice of regularly taking on-call allowed me to learn the different client environments quickly.
Cultivate Judgment. Very useful. Unfortunately it is not something measurable. As a DBA in an environment new to you, you have to be conscious of your limitations. If you have the slightest doubt of what you are doing, confirm it with another DBA. When working on a client’s production system, precaution is better than error (if only we applied the same respect to our ecosystems). Judgment will also come in handy for evaluating whether you have researched all possible solutions before calling for help in the middle of the night. (A checklist can come in handy here, e.g., groupware, Metalink, Google, et cetera).
Keep a journal of acquired knowledge. The more methods you use (voice, writing, reading, doing) to try to learn something, the better you will recall it. Therefore, keep a journal of stuff you learned during the day. Better, ask your boss if you can keep two journals, one with client-sensitive data, another one without it which you can keep with you beyond your time with the company in question.
Do Linux. If you know GNU Linux (or BSD), and you are comfortable with Vim (or Emacs), shell scripting, SSH, Perl, et cetera, you have a great head start. Why? With your Linux experience, you will be able to quickly adapt to enterprise systems, of which many will be Unix variants with these other tools.
Master Backups. If you feel any uncertainty about the recoverability of backups, it is an emergency. In the world of on-line 24×7 service (a no-sleep world — doesn’t that sound mad to you?), backups are the spine that holds the rest. Think of them as potential time bombs. If they are not looked after — if recovery planning and testing are not done — they will blow up in your face. Maybe tomorrow, maybe in a month from now, maybe in six months. But they will blow up, resulting in someone (probably you) losing a job.
I think these above items, especially the on-call aspect, will greatly help your entry into any DBA environment.
2 Comments. Leave new
Hello Julien,
I think that is important to have a journal of acquired knowledge during a project or even after some investigation.
But the most important thing is to share this knowledge. Paper is a good thing but obviously it has no “find” capability and some other great features :)
So if it is not a company secret, how do you organize a knowledge base within a company and how do you share it between people not only within one specific branch but worldwide?
Do you have intranet web server with organized wiki pages? with RSS channels to get the latest information in time? Or might be you share knowledge during some weekly meetings?
Regards,
Andrey Goryunov
Response to comment so far:
– Our software Support Track allows us to track the the work that each member does for each client request. I take some time to comment what I am doing and then paste relevant shell lines, much like any HOWTO documentation. Access to this site is throughout the company and our clients also have access to the work we do on their DBs.
– We do use a wiki to document some techniques, scripts, internal software and, in my case, my learning journal. But our internally built Support Track is really *the* framework that allows to record and search previous knowledge.