[SATLUG] Rackspace

typedeaf at yahoo.com typedeaf at yahoo.com
Fri Nov 13 11:50:39 CST 2015


>You are correct, that some (many?) book authors are clueless.  But that’s not the case for O’Reilly authors from the mid-90s....Not making any inference at all about their real knowledge and experience. That's just my point. I am sure that many people that write books are true experts in that subject/field.

> Do you know what a lame delegation is?  Do you know a script to automatically detect lame delegations and notify the appropriate admins?  Do you know of a script to automatically detect other types of typical delegation errors?  Who is the original author of both of these programs?  Who is the current maintainer of these two programs?  When were they first contributed to the BIND source code, and when was the most recent update?
Those are intended to be asinine, right? Yes, if someone asked me a question like that, I would crack up. 

>That's fine; but rather than tell me what I can't do, or how unqualified I am for some positions, what I was really hoping for from sending this email, was some Ideas of what i can do. Some ideas on career path options I can pursue.
I apologize. I probably was not very clear. My points are:1) When applying for a place like Rackspace, or other large IT shops, be prepared for brutal interviews. 
2) Make sure your resume is accurate. If you list 'networking', but have no experience with Cisco, then rather than listing 'networking' as a skill, explain your professional experience. Be as specific as you can in your resume, but be succinct.3) Decide what size of company you want to work for. There are difference pros and cons for working at start-ups vs. large IT shops vs. small shops. This will really determine how much the company pidgin holes and how much opportunity you will have to branch out. Also, know that start ups and large IT shops are going to expect you to be on-call.4) You didn't list many skills. What was listed would indicate that you have an interest in Linux and Networking. If you are going the networking route, Cisco has a majority of the market, so going with a CCNA is your best bet. If you want to go the Linux admin route, then you should be able to apply for any entry level admin role. 
5) You were asking people for their opinion on Rackspace, and all I can say is that its not the worst place to work. 

Also,  you could also look at L1 roles, like Network Operations. Its a easy way to get your foot in the door, and from there you can decide what your next path is going to be DBA, SA, middle-ware, networking, etc.  
Here are some things to be aware of. Most companies logically divide their operations staff into tiers. Tier 1 is customer facing support. Usually via phone and chat clients. Tier 2 is the first escalation point. These are usually the 'admins'. Their job is day to day operational tasks. Tier 3 is the escalation point for admin, and they are generally called 'engineers'. Its up to an engineer to find solutions for larger problems and after implementing those solutions, they hand off the day to day responsibility to the admins. Tier 4 are the architects, sometimes grouped into R&D departments. Architects are the ones planning the next new thing for the department. They hand off the plans to the engineers, the engineers fill in the lower level detail and implement the solution, and the admin add it to their day to day support. Of course, everyone wants the coolest name they can get, so don't expect job titles to ever accurately reflect their job role. I have seen Customer Support Architects, but that doesn't even make sense.

Another way IT operations creates islands is by application type or skill set. Examples: Network Admin, DB Admin,  Systems Admin, Middle-Ware Admin, Monitoring Admin, Storage Admin, Security Admin, Automation Tools Admin, etc. 

Finally, a lot of larger IT shops divide their operations into internal vs production. Internal support will support all the tools that the company uses to do their jobs, and production support will support the environment that is necessary to provide the product. 

I think this information is useful when wading through job openings. For instance, if you want to be working on bleeding edge technology that is massively scalable, i seriously doubt you will be finding those roles in the Internal Operations teams. Also, if the job title specifics tier1 support, then don't be surprised if the role does not include root access on all the servers.
Try to find out what job skills you would like to have or what tools you would like to work with, and plug those keywords into your job searches. 

Chad Wilson 


     On Thursday, November 12, 2015 4:50 PM, Brad Knowles <brad at shub-internet.org> wrote:
   

 On Nov 11, 2015, at 1:38 AM, typedeaf at yahoo.com wrote:

> I worked with a guy that published a book on IT security. That guy didn't even know what an RBAC was, couldn't describe the purpose of a single non-general purpose register, or couldn't describe a single common web based attack vector. I worked with a guy that wrote the book on how to tune Oracle RAC for Linux, and that guy didn't know the difference between user and kernel address space mappings (talking 32-bit x86 era) or even what a I/O scheduler was. In my opinion, being the author or editor of a book qualifies you to be an author or editor of a book, and nothing more.

You are correct, that some (many?) book authors are clueless.  But that’s not the case for O’Reilly authors from the mid-90s.  Cricket Liu was (and is) widely regarded by the DNS community as one of the leading experts in the field, and he brought a great deal of depth with him when he was working at Men & Mice.  I did some consulting for them at the time, and they had some top-notch tools, as well as good training materials.  Cricket has since moved on to Infoblox, where I think he has continued to do some pretty good work.

Bryan Costales knew as much or more about Sendmail than just about anyone on the planet, short of Eric Allman himself.  And Eric contributed heavily to the book, but it was still ultimately Bryan’s book.  I came close to working for Eric and Bryan at MercuryMail, but that deal ended up not working out, and Eric later transitioned to Sendmail, Inc.  When I was working at Belgacom Skynet SA/NV, we brought in Nick Christenson from Sendmail, and he and I ended up creating an architecture that I later turned into an invited talk at LISA, where I stood up in front of a room full of hundreds of people to explain what we had done.  I was pleased to find that they extensively used my LISA slides to present their large-scale systems architecture to their customers — there was more than one job interview I walked in to where they showed me the architecture document that described how their systems were set up, and I was able to turn around and show them the latest versions of those same slides — from my talk.

> Are you saying that you have never met a single Linux admin that knows network services? That is crazy. I can not relate.

Sadly, I have met very few.

> You say you were asked absurd questions about DNS. This is the first question I asked about DNS every time, and still ask today. "Name 5 record types and describe what they are used for." 99% of the people who put DNS on their resume could not answer that question. If you have EVER added a new server to your DNS records, chances are extremely high that you added an A record, PTR record, maybe a CNAME record, and updated the serial in the SOA record. That leaves one more record to get the answer correct, and every admin worth his salt has performed a nslookup/dig to find the MX record when working with mailers. I don't think that is an absurd question, but hundreds of people would disagree with me.

No, that isn’t absurd.  It is basic.

I would go into the differences between AAAA and A6 records.  And why you need both TCP and UDP for DNS.  And why you never, ever want to do DNS debugging with “nslookup”, but instead use a tool like “dig”.

Or maybe why does in-addr.arpa exist?  Why is it formatted in that weird way?  What other second-level domains have existed inside of .arpa?

Do you know what a lame delegation is?  Do you know a script to automatically detect lame delegations and notify the appropriate admins?  Do you know of a script to automatically detect other types of typical delegation errors?  Who is the original author of both of these programs?  Who is the current maintainer of these two programs?  When were they first contributed to the BIND source code, and when was the most recent update?

How much of a book do you want me to write?

> I used to say, "On a scale of 1-10, how well do you know Perl? 1 being, what is a pearl and 10 being I am Larry F'ing Wall" Invariably people would answer 7. Never 5. Never 6. Never 10. 7. So I would ask, "What the the three built in data type in perl?" If they were quiet, I would say, "Okay, I mean data types like scalars and arrays. Can you name one more?" 99% of the time, they couldn't say "hash", and when questioned further, they would say they have never used hashes. How could you be a 7:10 in Perl and never have had used a hash? Point is, know what you don't know, and do not BS your skill level.

I’ve used a bit of Perl over the decades, and about the only thing I really recall using much in Perl was hashes.

But I never would have been able to name those three data types.

>> Well, at least until I got into this DevOps thing, because so many places had decided overnight they could cut their staff in half by replacing all their “admins” with “DevOps” guys and make the people involved do twice as much work.

> You realize that statement is equivalent to saying, 'they cut their staff in half by replacing their "developers" with "Agile" guys', right? DevOps is a methodology for SA, not a job title.

You might know that.  But apparently a large amount of people in this world do not.  I can’t tell you the number of people who see “DevOps” in my profile on LinkedIn and who get the concept 100000% wrong.

I worked at AOL before Gene Kim did, and when I started there we effectively actually did DevOps in our group because both the Internet Mail developers and the one and only Internet Mail operations person (me) both reported to Jay Levitt, who was head of Internet Mail Development.  Internet Mail Operations got split out later, and the whole thing ended up devolving into the mess that Gene wrote about in his book “The Phoenix Project".

I was in Belgium before Kris Buytaert thought up the concept.  I knew John Willis during his days at what was then called “Opscode”.

I’ve had discussions with both Gene and Kris as to how did we not cross paths all those many years ago.

> Most jobs hiring, "DevOps Engineers" are actually looking for people with experience in tools that aid in continuous integration and automation, like Chef/Puppet/Ansible. Some companies looking for "DevOps Engineers" are actually looking for SA that specialize in writing or heavily modifying existing automation tools written in HLL like Python, Ruby, Perl, Go, or even Bash. Unfortunately, that has mislead a lot of people into thinking that "DevOps" means a developer that also does operations.

If you’re a “Developer” and you’re part of an interdisciplinary group doing DevOps, then you damn well better be ready to be woken up at os-shit-dark-thirty in order to be able to debug some sort of operational problem with your code.

The days of you working on your code in your own private cave in the corner and then throwing your code over the wall when you’re done — those days are over.

--
Brad Knowles <brad at shub-internet.org>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>

-- 
_______________________________________________
SATLUG mailing list
SATLUG at satlug.org
http://alamo.satlug.org/mailman/listinfo/satlug to manage/unsubscribe
Powered by Rackspace (www.rackspace.com)

  


More information about the SATLUG mailing list