If you teach system administration I highly recommend you take a look at USENIX's newest journal: Journal of Education in System Administration (JESA)
The journal can be read (for free) online: https://www.usenix.org/jesa/0101. I was honored to be asked to write a piece for the inaugural issue. You can read it online here.
Dear readers: I need your help. I feel like I've lost touch with what new sysadmins go through. I learned system administration 20+ years ago. I can't imagine what new sysadmins go through now.
In particular, I'd like to hear from new sysadmins about what their "rite of passage" was that made them feel like a "real sysadmin".
When I was first learning system administration, there was a rite of passage called "setting up an email server". Everyone did it.
This was an important project because it touches on so many different aspects of system administration: DNS, SMTP, Sendmail configuration, POP3/IMAP4, setting up a DNS server, debugging clients, and so on and so on. A project like this might take weeks or months depending on what learning resources you have, if you have a mentor, and how many features you want to enable and experiment with.
Nowadays it is easier to do that: Binary packages and better defaults have eliminated most of the complexity. Starter documentation is plentiful, free, and accessible on the web. DNS domain registrars host the zone too, and make updates easy. Email addressing has become banal, mostly thanks to uniformity (and the end of UUCP).
More "nails in the coffin" for this rite of passage include the fact that ISPs now provide email service (this didn't used to be true), hosted email services like Google Apps have more features than most open source products, and ...oh yeah... email is passe.
What is the modern rite of passage for sysadmins? I want to know.
If you became a sysadmin in the last 10 years: What project or "rite of passage" made you feel like you had gone from "beginner" to being "a real sysadmin!"
Yulia Sheynkman and Dave Zwieback are repeating their "Awesome Postmortems" workshop on July 10.
https://ti.to/mindweather/awesome-postmortems
It's a great way to get the team--and not just ops--offsite to experience a healthier way of dealing and learning from failure.
If you are in the NYC-area, this is a great opportunity to learn how to make postmortems an integrated part of how to improve reliability and prevent future outages.
When we wrote our "how to do postmortems" section of the upcoming The Practice of Cloud System Administration, we asked Dave for advice because we respect his expertise. Now you can get a full day of training directly from Yulia and Dave!
(full description below the fold)
Recently on a mailing list sysadmins were describing horrible management they've experienced. Here is my reply:
First, I want to say that my heart goes out to all of you describing terrible working conditions, bad management, and so on. I have huge amounts of sympathy for you all.
Health is more important than anything else. If your job is driving you crazy and giving you high BP, my prescription is, 'Try, try, then quit'. Try to change things, talk to management, work to create the workplace you desire. Try again, I'm sure you feel like you've tried a lot, but people aren't mind-readers... make sure you've had serious conversations with the right people. However step three is quit. Send resumes and get the hell out of there.
It is vitally important that we don't feel any guilt about leaving a bad job, especially if we've made a "good faith effort" to turn things around (as I'm sure you have). Just like when people being laid off are told, heartlessly, "Sorry, it was a business decision" there are times you have to tell a company, "Sorry, it was a personal decision". (I want to acknowledge that not everyone is in a position where they can just up and leave. Being able to do so is quite a privilege, but I think people that work in IT are more likely to be in this position than most fields.)
There are two reasons we shouldn't feel guilt about leaving these kind of "bad jobs". First, our health is more important than anything else. Second, it is important that we don't try to 'save' companies that are intrinsically bad at IT management. I say this not as a joke and I don't say it lightly. If you feel a company is incurably bad at IT, it makes the world a better place for that company to go out of business. IT is the lifeblood of companies. It is a requirement for nearly any facet of business to function in today's world. Companies that treat IT has an appendage are dinosaurs that need to be left to die.
IT is not a "speciality". It is a skill everyone should have. Any CEO, COO, or VP that doesn't understand IT and IT MANAGEMENT that ALSO thinks they don't need to understand it is fooling themselves. Expecting only the people in the IT department to have IT and IT management skills is insane. Expecting that IT and IT management astuteness only needs to be found in the IT department is insane. Companies don't have a 'math department' that people run to any time they need to add, subtract, multiply, and divide. They expect everyone to have basic math skill and only turn to mathematicians for advanced or specialized mathematics. Similarly a modern company must expect that every staff person understands the basics of IT and every manager, VP, and CxO executive should be expected to understand IT and IT management as it is a fundamental, essential, part of doing business.
IT and IT management is as essential to a business as accounting is. You don't expect your CEO and other managers to be experts at accounting, but you expect them to understand a lot more than just the basics. However if, during a job interview, you learned that the CEO didn't know that accountants existed, or thought financial statements "magically wrote themselves" you would run like hell as fast as possible, right? You would reject any job offers and hope, for the sake of the well-being of the economy, that such a company disappears as soon as possible.
Why wouldn't you do the same for a company that treats IT and IT management like that?
System Administration is maturing and, yet, there is no accepted standard curriculum. It is ironic, and somewhat scary, that a field that society is more and more dependent on has no formal, accepted, educational path. I propose a framework that is similar to that of the electrical/electronics industry.
To become a doctor there is a generally accepted educational path. Undergraduate "pre med" or biology program, medical school, internship, and so on. It gives me great comfort that the doctors that I see follow a formal path. Sysadmins, however, often "fall into" the career. I know many sysadmins whose formal education is in physics, for example, because it teaches them the rigors of mathematics, measurement, and thinking in terms of systems. I know many sysadmins who got their start with computers as a hobby by experimenting at home, possibly fixing friend's computers, and then "fell into" system administration as a job and are enjoying a highly successful career. Yet, I know of exactly zero doctors who got their start performing medical experiments at home. The medical profession went from "barbershops" to the scientific study and practice of medicine. System administration must make a similar journey.
Education of system administration is evolving into a 3-part framework similar to the electrical industry. If we are to mirror that industry it is important to first understand their framework.
The electrical industry has three tiers: the technician, the engineer, and the researcher.
The technician is someone you might hire to install a new electrical outlet in your home, or on a construction site installs the electrical infrastructure. People in this role follow the accepted practices of the industry, called "building codes". A technician literally might not know Ohm's Law. They do know, however, that the building code says every n feet of this there has to be one of that. That every 15 Amp circuit can have a certain number of outlets. They might not know, or care, why these rules exist, but they are rules to be followed. They know that if such a rule is violated the work will not pass when the building inspector checks their work. Technician jobs generally do not require a college education.
The engineer generally has formal college education. They have a depth of knowledge that enables them to design the systems that technicians install. They understand not just what building codes exist but they understand the science behind them. They are responsible not just for small designs such as the wiring for a new home, but also for large designs such as the power of a stadium lighting grid. More senior engineers write new building codes. Some engineers have a general practice while others specialize. Some are involved in relatively mundane projects while others are on the cutting edge.
The researcher invents. While engineers may design something that has never been designed before, researchers create entirely new categories. They may have a design approach and invent new components or they may take a physics approach and invent entirely new paradigms.
The field of system administration would benefit from a similar approach.
The system administrator technician deploys and maintains the systems as designed by others. They may not know all the details of why a standard exists but they know how to stay within those bounds. This already exists in terms of "vendor certifications". A technician learning a Red Hat, Cisco, or Microsoft certification is equivalent to an electrician learning the building codes. Rather than a government inspector providing a "certificate of occupancy" (C.O.), the pressure to follow the standards set out by the vendors who withhold support from designs that do not follow certain best practices. When designing a MS-Exchange environment one could choose to not use ActiveDirectory but it would be against the vendor recommendation and would not be a supported configuration. I've been told by network engineers that they were choosing one design idea over another because Cisco would not "certify" designs of such stripe. While vendors use the "carrot" of the promise of support, it is as powerful as the "stick" of a building inspector's "C.O."
The system administration engineer is less well defined. There is a serious need for University level degrees to fill this void. There should be BA/BS level degrees as well as degrees at the Masters level.
The systems administration researcher is the Ph.D level. This does not need much explanation. However, it should be pointed out that one does not need a Ph.D to invent in the world of systems administration. The industry is moving too quickly to isolate the creation of new paradigms to an ivory tower. The entire DevOps paradigm is a "found pattern" i.e. evolved organically and was given a name once many individuals all reached the same conclusion.
What should our next steps be?
Educating technicians is being taken care of by vendors. That's fine and appropriate.
PhD level education is something that will come in time.
The gap is at the University level. That should be the focus. To be more specific, the ultimate goal should be to define a 4-year degree in systems. To that end, we should begin by finding who is currently teaching "system administration" at a University level, catalog what they are doing, and bring them together to flesh out standards for curriculum.
I would be interested in talking with university-level instructors that would like to join forces and do such a project.
Tom Limoncelli
2012-06-04
This weblog is licensed under a Creative Commons License.
