This webinar may be of interest in light of this thread... I has mad respect for Gene Kim.
Join us on July 11 at 10 am PDT for "Next Steps toward DevOps: A Game Plan for Adoption and Implementation <http://email.puppetlabs.com/trk?t=2&mid=MzA3LVFMQS05OTE6NjIzNzoyNzkxOjg zNTA6MDozMzY3Ojc6Mjc1NzgzODp3ZGVubmlzQG5lYy1sYWJzLmNvbQ%3D%3D&&&http://g o.gigaom.com/PuppetLabs_webinar.html?WebinarSource=PuppetLabs&mkt_tok=3R kMMJWWfF9wsRokvKXIZKXonjHpfsX67OkqUaS%2BlMI%2F0ER3fOvrPUfGjI4CT8RlI%2BSL DwEYGJlv6SgFSbDCMbFs27gEUhA%3D> ," a GigaOm analyst webinar featuring Puppet Labs CTO Nigel Kersten and DevOps luminary Gene Kim. The hour-long event will be a panel discussion moderated by Dave Ohara, with Paul Duvall and Cormac Foster from GigaOm. Topics of discussion will include: * What is DevOps and why does it matter? * How can IT quantify the value of DevOps? * How can businesses overcome common barriers to DevOps adoption? * How can DevOps champions promote awareness and adoption? * What are the first steps toward adopting a DevOps methodology? * How can businesses attract and retain employees with DevOps skills? * How have other successful businesses transitioned to DevOps? Reserve your seat today <http://email.puppetlabs.com/trk?t=2&mid=MzA3LVFMQS05OTE6NjIzNzoyNzkxOjg zNTA6MDozMzY3Ojc6Mjc1NzgzODp3ZGVubmlzQG5lYy1sYWJzLmNvbQ%3D%3D&&&http://g o.gigaom.com/PuppetLabs_webinar.html?WebinarSource=PuppetLabs&mkt_tok=3R kMMJWWfF9wsRokvKXIZKXonjHpfsX67OkqUaS%2BlMI%2F0ER3fOvrPUfGjI4CT8RlI%2BSL DwEYGJlv6SgFSbDCMbFs27gEUhA%3D> ! Thanks, John Grim Puppet Labs, Inc. 503-575-9784 [email protected] From: [email protected] [mailto:[email protected]] On Behalf Of Joseph Kern Sent: Wednesday, July 03, 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/
