>Education, LOPSA keeps coming back to this as a root problem. We ask ourselves >what good is DevOps? We have no clue as a group, because there's little group >consensus on what DevOps means. Can I DevOps a bunch of Windows 8 clients? >Or is DevOps strictly related to build-and-release? Or is it just a warm fuzzy cultural >tandard? Is it possible to even hire a DevOps like I can a system administrator? Can >I DevOps without specific tools?
I don’t think that anyone really knows what DevOps is. It’s a term that has been co-opted by different people, and entities to mean different things. My personal opinion is that we need to just get rid of the term all together and define what a SysAdmin is not what DevOps is. A SysAdmin should absolutely have a good deal of the original DevOps philosophy, but I honestly think the term is more harmful than helpful. Off the top of my head things like (in no particular order): · The use of version control · The use of continuous integration · Scripting/Coding/Automation ability · Strong use of documentation · Communication and flexibility in what you do These are all things that make a strong SysAdmin, not just a good DevOps person. >Where do we start? Do we make a list of things we all do everyday and find the most >common elements? Do we list frameworks and multi-level abstractions that are worth >knowing? Do we list worthwhile certifications (there are at least two)? Is there no need to do >any of this? These threads go round and round without resolution. We should start by defining _*what*_ a SysAdmin is. I think starting with something akin to the SAGE levels (or whatever they where called, I can’t find them right now). However, these should be much more simplified. I think a basic framework to start with would include a general description of what a SysAdmin is (1-2 paragraphs) and then a definition of skills expected at different levels – such as: · Entry Level (1-3 yrs experience, or demonstrating skill set a,b,c), · Mid Career (3-5 yrs experience or demonstrating skill set a,b,c,d,e,f) · Senior (5+ yrs experience or demonstrating skill set a-i) · Architect (Senior + Skill sets x,y,z) We could probably very easily build a list of knowledge, but that should really be step two. Step one should be defining where we want the knowledge to lead SysAdmins. *From:* [email protected] [mailto: [email protected]] *On Behalf Of *Joseph Kern *Sent:* Wednesday, July 3, 2013 2:24 AM *To:* Lawrence K. Chen, P.Eng. *Cc:* LOPSA Discuss List *Subject:* Re: [lopsa-discuss] Mark Burgess quote from April 2013 ;login: Back on topic, let's not make this thread a support group for disenfranchised CF users. That can be it's own thread, right next to the zmanda aroma-therapy thread. ;-) Education, LOPSA keeps coming back to this as a root problem. We ask ourselves what good is DevOps? We have no clue as a group, because there's little group consensus on what DevOps means. Can I DevOps a bunch of Windows 8 clients? Or is DevOps strictly related to build-and-release? Or is it just a warm fuzzy cultural standard? Is it possible to even hire a DevOps like I can a system administrator? Can I DevOps without specific tools? We need to come to common terms first within our own Body of Knowledge before we can even decide if we want to change it or add DevOps to an ever growing list of vague terms. Where do we start? Do we make a list of things we all do everyday and find the most common elements? Do we list frameworks and multi-level abstractions that are worth knowing? Do we list worthwhile certifications (there are at least two)? Is there no need to do any of this? These threads go round and round without resolution. Once we define the map, the territory will become easier to navigate. So ... do we need to have a LOPSA committee on building a BOK? What are they supposed to create? What do they get out of it? "But lo! men have become the tools of their tools." On Tue, Jul 2, 2013 at 8:58 PM, Lawrence K. Chen, P.Eng. <[email protected]> wrote: ----- Original Message ----- > On Mon, 1 Jul 2013, Corey Quinn wrote: > > > Agreed-- but the counterpoint is that ops folks have to get better > > at > > development than they currently are to continue to thrive in this > > kind > > of environment. > > As a former developer, I have this covered. I sometimes forget there > are > a number of sysadmins who aren't so good at writing code. > I'm a former developer too...and been dabbling on the side again recently... > > Whether it's easier to train an ops person to be better at > > development, > > or to instill an ops mentality in a developer, is left as an > > exercise > > for the reader. > > I wound up being a sysadmin because I was always the guy on the team > making sure all the little details were covered. I was the guy who > made > sure ALL of the stanza in a Makefile worked correctly. I was the guy > who > made sure the sandbox setups were completely correct, etc. > I was detail oriented, etc...but there was also a void that led me to wear the sysadmin hat. Until I found myself doing just sysadmin (and wanting to do more, there was a time that I wanted to know all areas here.... still would like to get to know our SAN, which is back to only one person know it....the original person, who has moved up where he's both coach and player $boss...he's asked a few times whether the sysadmin position he had before he became manager is available or not.) > > …but you can butter my biscuits and call me Sally if you think I'm > > about > > to sit and quietly take criticism of LOPSA from the guy who brought > > us > > the trainwreck that is CFengine (at least through version 2, > > haven't > > looked into 3). The picture he paints of the uninvolved sysadmin > > who > > forms the "Department of No" is *exactly* the kind of admins I've > > known > > in my career who recommend CFengine for deployment. > > > > The folks who "get it," the folks who are more disciplined in their > > approach, who learned to adapt? They're all deploying > > Chef/Puppet/Salt/Ansible and run screaming from CFengine. I'm not > > saying > > it's a causal relationship, but the correlation is definitely > > there. > > Most of the environments I've worked in have refused to even look at > any > kind of configuration management systems, including CFengine. I've > been > fighting for something in many of my previous jobs. Those are are > where a > lot of sysadmins we need to convert are working. Ones who think > "I've got > some Perl scripts. Why change?" > Our previous $boss had taking this stand....kept saying it would destroy systems. Which sure enough, it has. But, though all of them could've been avoid if the $admin causing it had paid better attention to the details. IE: add existing servers to firewall class, should come after ensuring firewall definitions are on policy server for existing servers. Replacing everything with generic firewall (closes everything except enough to do initial configuration from our admin range.) Which we discovered years later that he had cleaned up by disabling firewalls on a lot of hosts...which in one case had a server exposed that shouldn't have been, and where somebody had developed an app in his private VPS somewhere based on it being exposed (which he continued to maintain after he had left)....which I then got into trouble for breaking because I fixed the firewall. They eventually granted a policy exception for it to continue to work...before it was moved into the datacenter. It should never have been externally hosted, though for HIPPA reasons.... > I'm most interested in Chef. Salt looks worth watching, but I > wouldn't > deploy it in production yet. On the other hand, many of the > developers I > know are going nuts over Salt since it's the new shiney... That was how our $boss sold that he's scraping all the work in upgrading from CF2 to CF3, to go with Chef....even though he said right away, that a couple of key features in CFEngine that we depend on heavily aren't available in Chef. He had looked at Salt, but guess he never got it to go on Solaris. -- Who: Lawrence K. Chen, P.Eng. - W0LKC - Senior Unix Systems Administrator For: Enterprise Server Technologies (EST) -- & SafeZone Ally Snail: Computing and Telecommunications Services (CTS) Kansas State University, 109 East Stadium, Manhattan, KS 66506-3102 Phone: (785) 532-4916 - Fax: (785) 532-3515 - Email: [email protected] Web: http://www-personal.ksu.edu/~lkchen - Where: 11 Hale Library _______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/ -- Joseph A Kern [email protected]
_______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
