Since this is Leam and we know each other, I’ll pick him to target on this one because I know he won’t take it personally. ಠ_ಠ
I’ve seen a lot of things bandied about regarding DEVOPS on these current threads. Unfortunately, most seem to be missing the mark. Now, I’ll grant you, when you have a developer, and engineer, a sysadmin, and a manager in the same room and say the word “DEVOPS”, something like 40 different things pass through the collected minds represented. However, as a guy who goes around the country training Engineers/Admins in DEVOPS technologies (specifically Puppet), I’ve come to one conclusion: nobody seems to ever really be talking about the same thing when they use the buzzword. For me, (a career systems engineer and architect) who has grown up through several big shifts in technology and now does Puppet bootstraps and professional services, I think DEVOPS, properly implemented, is simply this: DEVOPS, n. - Operational Management of sites, systems, and applications from the Operational perspective employing ‘best of’ Development technologies and methods to facilitate deployment, repeatability, versioning, consistency, and rollback. Or, for short, “Development informed Operations” I’m certain there will be much in the way of disagreement here, but… well… this is what we’re teaching teams all over the country as we roll out Puppet for them, teach them revision control, automated deployment, versioning, build synchronization, etc. While some were decrying DEVOPS earlier as something along the lines of handing out root to developers, I can say that since January, I have not been to a single site where the DEVOPS methodology was implemented included a single developer, but instead taught development methodologies to Operations personnel in every single instance. Many of these sites will eventually work out a model for themselves whereby development teams will be able to write Puppet code and push into their environment in a controlled sort of way, but those who are retaining folks like us are getting a consistent message that this is not a technology whereby you hand out root access to developers… far from it. Had I not gone to Apple in 2011, I was slated to speak in Boston on DEVOPS (my working title was “DEVOPS nightmares”), but Apple made me drop out. (Sorry, Carolyn!!!!), but my stories were similar to yours… that the new buzzword was bing pushed around as a way to give developers root access to everything. Well, I was having none of it and built an environment for them where the “fix” was if they horribly messed everything up, I would re-roll the environment from templates in an automated fashion and put it back to pristine, as I didn’t have the time to troubleshoot the mistakes they made by having root on their boxes. In short, they destroyed the environment 6 times in a 30-day period to the point of not being functional at all, and mostly due to a lack of knowledge of operations, operations techniques, and security best practices. After this we went to a real DEVOPS environment, and they were happy from there forward, and the poor guy they gave the admin responsibilities to was much happier developing than living in our world. My point is this… None of us can define that term for everyone, but only in the context of our own environment. For, most of these implementations have to be tailored to the business rules of the organization and differ based on business + technical needs. It’s pretty much the same with everything you could use… whether it be Puppet, Chef, SALT, Opsware (shudder) or any other centralized management paradigm. Good, sound admin doctrine couple with good, sound development doctrine applied over a good, sound business and compliance doctrine will always be a quality environment. —j On Aug 12, 2014, at 10:15 AM, leam hall <[email protected]> wrote: > On Tue, Aug 12, 2014 at 1:01 PM, Michael Tiernan > <[email protected]> wrote: >> 'Develop and publish a document that defines what LOPSA considers >> "System Administration" to be' >> >> Thank the gods! I'm dying to see how this comes out. > > And perhaps "should be in the future". Some time back I took the SAGE > "what an SA should know at each level" and learned those tasks. The > landscape has changed greatly since then and is probably going to > change even more in the next 24-48 months. > > For the record, I'm not a DevOps fan based on the implementations I've > seen. A better union of Dev, Ops, and Eng is great, but so far it > seems more "Devs doing stupid crap and calling it system work". > > > > > > -- > Mind on a Mission > _______________________________________________ > 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/
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ 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/
