> > > If you are looking for an Ops Engineer type role (you said it was one of > your options), in a lot of shops you'd be using Chef or Puppet in that type > of role. I'm partial to Puppet (I'm going to work there in a few weeks in > exactly this kind of role), but I know a ton of really smart people who use > Chef too. Also Ansible seems to be gaining in popularity. > > Other shops don't use these tools at all or are moving away from them as > they adopt containers. Learning things like Docker and Kubernetes could be > really helpful too. > > There are less defined learning paths for some of these things. The Devops > tool space is completely in flux right now and I'm really not sure where > things are going to end up. > > If you are interested in Puppet, there's a pretty awesome Puppet User's > Group here in Portland. Sometimes the actual engineers who wrote the code > for a given feature are the ones presenting at a meeting. > > You also mentioned Python and my impression is that it's very popular in > operations shops. A lot of the job nowadays seems to be about glueing > together different open source apps, so being able to interact with APIs is > important. The Requests library for Python is great. > > Puppet does have training classes and I'm sure Chef does too. I would be > surprised if they're not pretty expensive. But Puppet does have a VM you > can grab for free called the Learning VM and some exercises you can walk > through to get your feet wet. > > The Ops Engineer space is a lot more confusing than the traditional > sysadmin one now, but I'd make the argument that those jobs are probably > going to land you in more inseresting shops/roles. I think it's really > where the industry is heading. > > One of the big shifts in this kind of role from the traditional sysadmin is > writing unit tests/acceptance tests for your code. I've found it very > liberating. If your tests are good you can refactor and know pretty quickly > whether things are broken or not. Both Chef and Puppet have tools built on > top of Ruby's Rspec, that's another good thing to get your feet wet with. > And Python has its own testing tools. > > Sorry if this is kinda rambling and vague but that's honestly how this > space feels right now. I'm still going through this shift myself. I was the > sysadmin who hardly wrote any code for many years and now I think of myself > as an engineer (not a particularly great one). > > > Rich > > P.S. Perl makes my brain hurt too, it's not just you. > > P.P.S. My last PLUG talk was in something like 2000 (not kidding), but I > could possibly do something Puppet related if people are interested. I did > a talk at Puppet Camp Portland in January on how to get your feet wet with > module development and some of the testing tools for it. That one might be > helpful. I wouldn't be able to until at least October. > > Rich - I didn't find that vague and rambling. It's pretty good insight into the Sys Admin / DevOps space for someone who's not in it, looking at it from the outside and trying to make sense out of it all.
I especially liked to hear that you made the transition from a traditional Sys Admin role to more of a DevOps role as that'll be my path too. > Beyond that, however, the difficulties you've encountered trying to > outline a career-development path are due to the idiosyncratic way > employers think about the jobs they're posting. > > Few sysadmin jobs are best described as "support Linux." Linux is the > tool; it will be discarded when a new one proves its worth. Sysadmin > jobs are "support the tools (which happen to live in a Linux > infrastructure) that keep our enterprise viable." > > You won't be selling Linux skills. They're required -- and will help > you improve the situation at your future employer -- but what you > really need to sell is your skills at leveraging computer > infrastructure to help an organization move forward. > > That said, you can then think about the major markets for Linux > systems administrators: > > * Educational institutions: user support, research focus, diverse > computing environment, unclear lines of responsibilities. > > * Small businesses: absolutely everything related to the computer and > network lifecycle plus lots of tool-building on the cheap. > > * Nonprofits: similar to small businesses, with a lower budget. > > * Large enterprises: heavy specialization; probably need to know > someone to get a serious interview. > > * Government: similar to large enterprises with a slightly more open > hiring process. > > Take the time to learn the technical tools; they'll serve you well. > Unless you have deep knowledge of an unusual or difficult bit of > computing infrastructure (hardware or software), however, the tools > won't generally set you apart. > > What a valued sysadmin really does is help people survive and > thrive in their sector of the economy. > > That's how employers think about their sysadmin job postings, which is > why it can be tough to get a handle on what skills will get you an > interview. > > Paul - That's very good and useful insight. I agree and understand what you say abut "selling Linux skills", "leveraging computer infrastructure" and that the "Tools won't generally set me apart." I think that's more applicable to to people who have years of Linux Sys Admin work experience and not folks like me who are just trying to meet the minimum requirements just to get an interview. _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
