Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have just been promoted to Systems Administrator for our product. We are designing a application that communicates with the cloud(Amazon EC2). I will be in charge of maintaining all Instances and their underlying components. So far this involves a set of load balanced services instances that connect to a central DB in a multi-tennant DB design.

Im interested in what other Sys. Admins have discovered as invaluable tools or practices. Any resources provided will be greatly appreciated.

share|improve this question

closed as too broad by Zoredache, Rex, Jenny D, Ward, Katherine Villyard Mar 11 '14 at 18:58

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

You might be interested in Usenix & Sage... – Joe Internet Apr 1 '10 at 5:17

"The Practice of Systems and Network Administration" is a fantastic book for the fundamentals.

If you search questions by votes, you can learn a lot on a variety of topics that could be considered essential.

Unfortunately, without having a more specific question, there will not be a whole lot we can help you with.

Edit 1

Also, check out this earlier question, as it addresses largely what you're asking.

share|improve this answer
+1 for "The Practice of Systems and Network Administration" – lukecyca Mar 22 '10 at 18:18
Excellent, thank you Warner. I realize this is question is going to be lacking a definitive answer. However, answers like this one are just what I'm looking for. – Joshua Anderson Mar 24 '10 at 14:42
Glad you responded, I ran across an earlier question last time that should be helpful too. Check out the Edit. – Warner Mar 24 '10 at 14:51
Great Link, Lots of good information, thanks! – Joshua Anderson Apr 1 '10 at 20:14

One useful principle that I try to apply, and see violated regularly, is that a sysadmin should understand the boundaries of their reponsibility, and take care not to overstep the mark.

What I mean by this is that often in sysadmin duties, questions and problems will arise that actually require decisions to be made by other areas of the business, but IT may attempt to address the problem without seeking out those decisions from the business.

Some good but by no means exhaustive examples of this are:

  • Applying retention periods to email storage. IT should not configure this retention period without consulting the business' legal authority. Setting it to 3 years because your disks can't hold any more than that, is not good enough. If it later turns out that email must legally be retained for a longer time e.g. 7 years, you are up a creek.

  • Disposal of old servers and workstations and secure data deletiohn - IT needs to consult with the business executives or suitable delegations as to the data security and disposal requirements of their organisation.

Some folks see this as sloping-shoulders shrugging off responsibility, or are lulled into the notion that they must be able to answer any question authoritatively no matter the subject. Often as IT folks I think we get lulled into a sense that we are expected to answer authoritatively on any subject, and not just the one in which we're knowledgeable.

So yeah... Learn and apply appropriate boundaries of responsibility to your role, and the non-IT people in your organisation will appreciate and respect your understanding of how IT fits into the business. You'll avoid a reputation of being a loose cannon, difficult to control, or arrogant. Not to mention protecting yourself against any ramifications that may arise down-the-line if the decision that was taken leads to problems.

Oh and in conjunction with the above and as a seperate principle in its own right: Always establish an email trail of decisions so that they can later be traced back and proved.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.