Database and Systems Administrators
Design, develop, install and maintain operating systems, software and server hardware to support secure and reliable database management systems.
The morning the server went quiet
You are a systems administrator at a regional council, and the main server has just stopped responding. It is 7:40am on a Tuesday. The council office opens at 8:30. Staff are starting to arrive and cannot open the records system. Your phone is ringing, and so is the front desk's.
Choose what you would do. Then see what happens. There are often good reasons for each choice.
We cannot get into any of the property records, and we have people waiting at the counter. How long is this going to take? I need to tell my team something before we open.
Tell her it will be fixed in twenty minutes so she can reassure her team and open the counter on time
You hoped it would be quick. It is not, and by 9am the front desk has told customers twice that it is almost fixed. Promises you cannot back up cost trust.
Say you do not know yet, you will update her at 8:15, and suggest what her team can do meanwhile
Beth is not happy, but she can plan. Her team switches to paper forms and tells customers honestly. An honest update at a set time is worth more than a quick guess.
Ask her to stop ringing, because the fastest way to fix it is to be left alone to work
You get an hour of quiet to work, but Beth's team hears nothing and rumours spread. A short, regular message would have cost you a minute.
I need access to the records database right now to pull a report for the councillors. I'm the CFO. Give me the admin login and I'll sort it myself.
Give him the admin login, since he is senior and it is an emergency and the councillors are waiting
He gets his report. But you now have no record of who changed what, and Dave accidentally alters a setting while the server is fragile. Seniority is not a reason to share a key.
Refuse to give any access at all until the server is fixed, however senior the person asking is
You are strictly right, but Dave takes it as obstruction and escalates it to the chief executive. A flat no without a path forward costs you allies.
Explain why you can't share the login, and offer to run his report once the server is stable
Dave grumbles, then accepts a time. You keep control of the access, and the report is ready by early afternoon. Saying no with a useful yes beside it keeps the relationship intact.
I think I know what's wrong, but fixing it means taking the system offline for an hour and possibly losing a few of this morning's entries. We could instead restore the backup from last night. Your call.
Try the fast fix straight away, because it might save everyone time
It works, but you lose some of the morning's entries and nobody had been warned. Staff have to redo work, and you wish you had told them before starting.
Restore last night's backup without telling anyone, since that is the safest known path
The restore works, but staff keep working through it and lose more entries than expected. Safe for the data is not the same as safe for the people using it.
Choose the fix, tell Beth and the managers what will happen and when, and note which entries might be lost
People know exactly what to expect and re-enter a few records afterward. The system is back well before lunch. Telling the people affected is part of the technical fix.
How it went
By midday the server is stable and a short written account of what happened has gone to the managers. Systems administrators keep the dull-looking machinery running, and are noticed mostly when it does not. It asks for patience, calm and a willingness to explain. Would you be happy being the invisible hero?
This is a simplified, fictional situation to help you explore. It is not professional instruction or a test of your ability.
Case study: The backup that nobody had tested
A fictional case set in the small IT team of a fictional regional council that runs its own servers and databases.
The situation
Ravi was the systems administrator for Tarrawong Shire Council, a small fictional council. Every night, the system ran a backup of the rates and records database, and the green tick came up each morning. Ravi had been in the job six months and realised nobody had ever tried to restore from those backups. If something broke, the council would find out then whether they worked. Testing it would take a weekend and would slow down his other jobs.
What they did
Ravi told his manager what he wanted to do and why, and got agreement to spend a Saturday on it. He set up a separate test machine and tried to restore the database from the last three backups. Two worked and one did not, because of a setting that had been changed during an earlier upgrade. He fixed the setting, wrote down how to restore step by step, and booked a test for every three months.
How it turned out
A few months later, a disk failed on a Tuesday afternoon. The team brought the records back within a couple of hours and most staff barely noticed. Ravi's manager mentioned the weekend's work at the next team meeting, and the restore test became a standing job.
What would you do?
- Why might a green tick not be enough to trust something?
- How would you feel about spending a weekend on a problem that has not happened yet?
- What does it take to be the person everyone relies on but nobody thinks about?