In technology environment, keeping things simple takes lot more effort and maturity than keeping it complex. These 10 items are guidelines more than rules, that I have learned over the years doing intensive work on the IT infrastructure. These guidelines are mostly common sense and can be helpful for anybody who administers an IT system, including Linux/Windows Administrator, Network Administrator and DBA.
1. Yes, as simple as you can be and still get the job done. Although security is never simple and not something you should keep simple(because that means no passwords!)
2. Yes.
3. Having a backup you haven’t tested is better than nothing at all. Although you should absolutely test it.
4. Yes.
5. Oh god yes, for the sake of whoever comes after you and maybe even for your own sanity.
6. Sure. But problems will arise.
7. No. Just typing crap into a command line won’t necessarily teach you anything just like compiling a program in freebsd won’t teach you anything about *nix. “I see scrolling compiler text, I’m a hackerz!!one”
8. Yes.
9. Yes. Complain about them later while you’re having a beer.
As always in regards of security, you’re not alone. If everything would just depend on yourself, well, you could guarantee almost 99% security. But there usually are other users who don’t understand why their password can’t just be their name or empty.
Backups. I should have known earlier… 🙁 (Total desaster here on July 2nd.)
When you’re making backups, your disks will never fail. But they will as soon as you leave out one backup session. It’s the same as with umbrellas and rain. 🙂
More here: http://www.rinkworks.com/stupid/cs_backups.shtml
If the backup works if needed, it doesn’t matter if you’ve tested it. But when you insist on having a backup, and it won’t work, then…
It’s good when you do documentation on paper. Electronic media can always fail (maybe due to the media itself or due to a malfunctioning drive), but paper can be read with only using your eyes.
Of course, no matter how good you think you’ve planned. But I think it’s about how you manage upcoming problems, too.
Hehe, that’s right. Using the command line properly involves learning. The CLI is just a means to get work done, nothing more, nothing less. It’s not a holy grail to make you any smarter. But in most cases, you can see an implication the other way round: Those who use the command line usually have skills that are valuable.
Involves number 7, in most cases.
Or put this onto your wall: http://web.gnuer.org/blog/uploads/pictures/stupidamouse.jpg 🙂
You forgot number 10, in my opinion one of the most important things. You can only keep up in business if your knowledge is up to date, and you can stand all the problems, all the learning and all the typing if you’re really having fun doing these things. A saying I’ve heared on this topic: “A system administrator is a person who is paid to do the things he would do anyway at home without payment.” If you don’t like the job, it will make you sick one day, and you don’t want to see these stupid computers anymore. 🙂
1. Know your limits: and never try things you have not worked on before and have no experience with. Call for help from more experienced administrators
2. Only implement and maintain what you have successfully tested and done for more than 10 times with 0 errors.
3. Write down what your customers and clients refuse to do from what you have suggested, so that you can show them in the future what they did to themselves.
4. Don’t go with cheap hardware/software as its instability will affect your reputation.
5. Don’t give too much details about what you have done to fix problems…those guys are buisy with their businesses and don’t have enough pain to endure.
6. Don’t undercharge: because next time they will ask if you can come and do it for free.
and many more
This is easily the worse list I’ve ever read. I don’t agree with a single point.
Well, except for not using cheap hardware.
So when your boss asks you to do something, your answer should be “No I won’t do that, I don’t know how? I don’t think that’ll work somehow.
A competent admin should be able to what’s needed and do it well, even if they’ve never done it before.
Then how do you learn anything new? I understand the rationale, but IMO it’s better to take the attitude of “don’t make promises / commitments until you know for certain that you can deliver on them.”
I think that only applies to a very narrow range of IT work – viz. jobs where your employers encourages & pays for regular training, or if you’re working in a field that never changes.
And in many cases, the client doesn’t care / wouldn’t understand the specific details anyway.
That’s one of the things that soured me on volunteer work: dealing with people who were even more demanding and less grateful than most paying customers (that, and the folks who apparently got into volunteering as way to bolster an already-inflated sense of self-importance).
The number one rule that I’d love to see system admins follow is this; if you don’t know something, be honest and learn. Don’t think that you’re bullshitting anyone by trying to hide your ignorance. We are all ignorant about something things – acknowledging what you don’t know demonstrates a degree of humility.
With that comes a sub point to it; make sure you’re up on the play in regards to the latest trends and technology. I remember talking to some system admins who were atleast 10 years behind the curve in some topics. Come on, unless you have a keen interest in IT – don’t even waste anybodies time getting into the field unless you’re willing to do your homework.
11. If you are planning a project make sure your time line meets the deadline of your customers (other departments). I have seen more then one CIO violate this rule and have it cost them their job. Someone else gets to figure out how to make something work while the customer is screaming because their department has ground to a halt as they wait for a project that is behind.
11a. If things work now in the real world. Think twice, no three times before you cross bridges that are one way. Nothing like getting halfway through a project and discovering that the goal can’t be achieved with your current path or time line. Then you get the joy of telling departments they have to redo work to get back to where they were.
In case you were wondering, at my place of employment both are taking place. The townspeople are at the IT doors with torches and pitchforks….. and they are not smiling. The CIO looks nervous and twitchy.
Documenting and automating CLI commands is so much easier than documenting and automating GUI commands!
It’s a good one.