It’s even worse in security. I haven’t yet seen even a claim of DevOps that didn’t actively exclude security until "Oh, it’s too late to change that now." Security is supposed to be involved from the beginning, but even the high level descriptions of DevOps pushes security to the side "in the name of efficiency" rather than making security an integral part of the process from the beginning.
I’ve seen numerous "devops" tools that fundamentally violate rules in individual accountability (a big one for Sarbanes-Oxley). When I point these issues out "Oh, that’s not really a problem," when yes, it is, and it should be a show stopper, and was before the devops craze. > On 2015-06-23, at 11:51 , David Lang <da...@lang.hm> wrote: > > I think that a large part of the problem is that long established SysAdmins > are seeing DevOps implemented badly and are not jumping on the bandwagon > enthusiastically enough for folks. > > As noted, DevOps all to frequently is interpreted as "we don't need no > stinkin sysadmins" or "give all the developers root in production", or "no > specialities, everyone needs to be able to do everything" and the experienced > SysAdmins understand exactly how big a disaster those sorts of attitude will > lead to. > > If you talk to the same SysAdmins about teamwork, where the developers > include them when they are designing new software rather than just throwing > it over the fence for them to somehow run and scale, you would get > enthusiastic agreement. > > But what's talked about online, or at conferences, and what's implemented in > businesses have very little resemblence to each other (outside of the tems > that are used) > > David Lang > > On Mon, 22 Jun 2015, Derek J. Balling wrote: > >> >> I just want to chime in and "+1" this entire post, because it >> parallels a mental journey I've been going through the last few weeks. >> >> This past year, I attended LISA, a day of Velocity-NY, and all of >> Velocity-CA, and came away from Velocity feeling like it was a culture >> that was forward-looking, collaborative, diverse, embracing new ideas, >> while LISA was (with a few notable exceptions) chock-a-block full of >> angry old white dudes (including to some part myself, admittedly), >> stuck in the past, and seemed to want to shout at the DevOps folks to >> get off their lawn. >> >> I say this only because it caused me to deeply re-examine what culture >> *I* wanted to be a part of, and -- like Stephen -- I had almost no >> exposure to a really quality DevOps environment first-hand, so my >> perspective was tainted by years of exposure to a community which >> seemed more interested in shunning "those upstart kids" than embracing >> them. I picked up Phoenix Project (on several people's recommendation) >> and it's next in line to be read after I finish TAL's new Cloud book. >> >> I watched a video that gave me a lot of clarity around the varying >> DevOps "meanings" to different people, and figured I would share it as >> part of this discussion. I'll freely admit, Stephen's post is the >> first in this thread that I've read start to finish, so if someone >> else already posted this, well, shoot me. :-P >> >> https://www.youtube.com/watch?v=_DEToXsgrPc >> >> It's longish (hour-plus) so download it and watch it somewhere >> comfortable. You won't regret it. >> >> D >> >> >> >> On 6/22/2015 11:12 AM, Stephen Potter wrote: >>> Over the weekend, I also read "The Phoenix Project" >>> (http://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988 >> 262509/). >>> DevOps has become a huge buzzword recently, and several colleagues >>> had been recommending this book. >>> >>> I admit, I had been resisting studying up on DevOps because of all >>> the misinformation out there, particularly the notion that DevOps >>> was about developers running operations/production and that it was >>> tied up in all these specific Agile tools (jenkins, docker, >>> openstack) or methods (scrum, sprints, XP). Reading this book and >>> doing a little more research over the weekend, I've started to gain >>> an understanding of the underlying DevOps philosophy. >>> >>> I really like an old blog post by John Willis >>> (https://www.chef.io/blog/2010/07/16/what-devops-means-to-me/) I >>> found that, similar to the book, gets to the heart of the >>> philosophy rather than getting tied up in specific methods, >>> practices, or tools. He breaks it down in to CAMS - Culture, >>> Automating, Measuring, Sharing. I would almost suggest that you >>> could change that to just CAM - Culture (of Collaborating and >>> Sharing), Automating, and Measuring. To many of us, the DevOps >>> philosophy isn't new, it's things we've tried to do all along but >>> may not have had the backing or the state of the technology and >>> tools didn't allow for it. >>> >>> A lot of people, when talking about DevOps and culture, talk about >>> collapsing silos as if that means you have to get rid of >>> traditional teams ("you can't have a network team and a storage >>> team and an OS team - they all have to be one"), but it isn't that. >>> It's collapsing barriers that stop teams from working with each >>> other - territory building, rigid processes, the blame game - and >>> embracing flexibility that allow for that collaborating and >>> sharing. They talk about getting rid of traditional project >>> management (it's all Agile), but I believe there's still a need for >>> some traditional project management. >>> >>> I was interviewing with someone a few weeks ago and they asked me >>> about my project management style (even though I'm not a project >>> manager, they were expecting some project management out of the >>> leadership role I was looking at). They asked me whether I was >>> more of a traditionalist/control PM or more of a collaboration >>> person (I believe they were thinking about Agile methodologies). I >>> expressed some confusion, because I didn't see the specific >>> distinction between the two. I said that no matter what you were >>> doing, you always knew there were certain project phases and tasks >>> that needed to be rigidly tracked while sub-tasks and individual >>> steps could be done without such rigor. I said you may spend some >>> time up front collaborating to make sure everyone agreed on the >>> phases and tasks, but eventually I (if I was managing the >>> operation) would have to ensure they were done. >>> >>> Automation and self-service is nothing new for any of us either. I >>> was setting up automated build systems and allowing people to >>> re-image desktops and workstations back in the early '90s. Before >>> Sun's Jumpstart was developed, we combined network boot with a >>> bunch of back-end tools and scripts (like swdepot) that allowed us >>> to re-build our lab every semester and fairly simply rebuild broken >>> or new systems. When I moved on to a FT job at a software >>> development company, I used similar technologies (including >>> Jumpstart, which was then available) to allow the QA team to >>> rebuild their QA systems whenever they needed. What we didn't have >>> then was the ability to create virtual machines (no VMware, no >>> Zones, no Containers) that would allow for self-service of entirely >>> new environments (we still had to go through budgeting and >>> procurement to get the hardware, there were many pieces that still >>> required manual work like racking/stacking, networking, storage, >>> etc). Over time, we've gotten those tools (along with deployment >>> management, configuration management, systems monitoring, capacity >>> management) and capabilities (networking, security, storage, and >>> others) that are now allowing some of these older ideas to come to >>> fruition. Even more recently, we're finally starting to get the >>> final pieces that were needed. In particular, we're starting to >>> get real policy and governance tools that enable safe and secure >>> self-service. >>> >>> -spp >>> >>> On 6/17/2015 2:14 AM, Joseph Kern wrote: >>>>> Surprisingly, it isn't that difficult to learn as much as you >>>> need. Yes, there's a lot about business you can learn, but you >>>> really don't need to learn that much of it. I got an MBA several >>>> years ago, but honestly, I could have read a basic >>>> accounting/financing textbook, a basic management textbook, and a >>>> basic business law textbook and gotten pretty much everything >>>> I've used since then. Most of what you need to understand is the >>>> basics, the terminology, and some of the newer buzzwords. >>>> >>>> Well now that you've put yourself out there ... which books would >>>> you recommend? >>>> >>>> I have read the Phoenix Project, and loved the book. Started >>>> reading The Goal (the book that Phoenix Project based itself off >>>> of), and find myself wanting more. >>>> >>>> On Wed, Jun 17, 2015 at 1:51 AM, Stephen Potter <s...@unixsa.net >>>> <mailto:s...@unixsa.net>> wrote: >>>> >>>> Surprisingly, it isn't that difficult to learn as much as you >>>> need. Yes, there's a lot about business you can learn, but you >>>> really don't need to learn that much of it. I got an MBA >>>> several years ago, but honestly, I could have read a basic >>>> accounting/financing textbook, a basic management textbook, and >>>> a basic business law textbook and gotten pretty much everything >>>> I've used since then. Most of what you need to understand is >>>> the basics, the terminology, and some of the newer buzzwords. >>>> >>>> Once you've got that, you just need to be willing to listen to >>>> people and ask a few questions. And, quite often, the questions >>>> you have to ask are "what would it mean if...." or "how could >>>> you see that happening" when someone tells you something; just >>>> turning their question around on them to get more information. >>>> It is amazing how people can see 90% of a solution, but miss the >>>> last step. And, if you can provide the last step, you're a >>>> genius, even when it is something really simple. I once - many >>>> years ago - got a $500 bonus (from a director) because I was >>>> willing to ask him if I could move an external disk from one >>>> machine in one town to another machine in another town and >>>> explain to him how it related to his business (when one system >>>> ran out of disk space, it killed one or more long running jobs >>>> that cost several hundred dollars in lost productivity each). I >>>> was in my early-20s then, and simply a contractor who didn't know >>>> any better than to ask! >>>> >>>> -spp >>>> >>>> >>>> On 6/16/2015 2:50 PM, Atom Powers wrote: >>>>> >>>>> +1 million. I wish I had the time to learn that skill. >>>>> >>>>> >>>>> On Tue, Jun 16, 2015, 11:13 Stephen Potter <s...@unixsa.net >>>>> <mailto:s...@unixsa.net>> wrote: >>>>> >>>>> Several others have already mentioned that it sounds like >>>>> there's management problems at several levels and titles won't >>>>> help. Some have mentioned the split management/technical track >>>>> with management roles such as Lead, Supervising, Managing, etc >>>>> and technical advancement through Distinguished, Principal, >>>>> Fellow, etc titles. >>>>> >>>>> What I see as the underlying problem is that no one has been >>>>> able to relate what IT does to the business goals and values to >>>>> help the executives really understand where IT fits. You >>>>> mention that IT falls under the VP of Administration, which >>>>> generally contains groups like real estate, facilities, >>>>> logistics, HR, and perhaps regulatory compliance. This is all >>>>> just overhead and costs of doing business. None of these have >>>>> anything to do with revenue and enabling the business. >>>>> >>>>> If you really want IT to start to get some respect, you need to >>>>> have someone who can talk the language of the executives and >>>>> tie their goals into what IT can provide. Business will talk >>>>> about market share (acquiring/retaining customers), competitive >>>>> differentiation, business innovation, and profitability. You >>>>> need someone who can take those and show how IT can help >>>>> develop multichannel (buzzword: omni-channel) services that >>>>> provide competitive differentiation and attract new customers. >>>>> Someone needs to talk about continuous delivery of IT services >>>>> that enable other business units (R&D, sales, etc) to change >>>>> the way they do business (mobility, supply chain management, >>>>> etc) and speed up sales (buzzword: "inventory turn", "sales >>>>> close cycle") or even enable entirely new products and services >>>>> (buzzword: "time to market", "go-to-market strategy"). And, >>>>> finally, you need to be able to show how IT can help reduce >>>>> costs across the entire company (not just reducing IT costs), >>>>> reducing SG&A (sales, general, and administration), and how >>>>> the other things I've already mentioned can reduce unit costs >>>>> (development cycle, manufacturing costs, etc). >>>>> >>>>> A couple of examples I can think of, which wouldn't necessarily >>>>> be relevant to your specific company. One large fashion >>>>> retailer I worked with used to ship store layout, discount >>>>> information and sales reports to each of its several thousand >>>>> stores weekly. They were spending hundreds of thousands of >>>>> dollars a month on FedEx shipping alone. IT was able to work >>>>> with the store operations teams to figure out how all that >>>>> information could be safely shared through remote access across >>>>> the network. The savings to the company was millions per >>>>> year. >>>>> >>>>> Another company had dozens of desktops in their distribution >>>>> facility where product pickers went to print off pick lists >>>>> for packaging and shipping. The conditions in the DF were such >>>>> that the desktops and printers crashed regularly, requiring >>>>> pickers to search for a working desktop/printer combination, >>>>> and slowing them down. IT had a person onsite in the DF full >>>>> time, just to handle desktop/printer issues. Orders were >>>>> batched every couple of hours, so there were often times when >>>>> the pickers had nothing to do. IT was able to work with >>>>> distribution to come up with a combination of thin-clients, >>>>> touch screens, and tablets that enabled more real time access >>>>> to the lists, reduced errors, reduced outages (to the point >>>>> they pulled the IT guy back to the office and redeployed him to >>>>> do higher value activities), and reduced costs. It also >>>>> enabled the distribution to collect efficiency data, which >>>>> subsequently led to re-arranging how products were stored in >>>>> the DF. >>>>> >>>>> In order for IT to get respect in many companies, there needs >>>>> to be a strong leader who can tie IT to the business, rather >>>>> than just being another SG&A cost. >>>>> >>>>> -spp >>>>> >>>>> On 6/9/2015 9:52 AM, Tim Kirby wrote: >>>>>> I'm not sure if this is actually a repeat of past threads, >>>>>> we spend a lot of time talking about this sort of thing >>>>>> within "IT organizations" but I'm not sure I've seen this >>>>>> one. >>>>>> >>>>>> $WORK is a computer system manufacturer. Thus it is largely >>>>>> technical with an R&D component building software and >>>>>> hardware. Within our IT organization we have two or three >>>>>> highly experienced sysadmin/devop/engineer types that could >>>>>> hold their own against any of the R&D "Principal Engineers" >>>>>> and do, at time, consult for R&D. >>>>>> >>>>>> The politics and handling of "IT" is every bit as >>>>>> dysfunctional as you might expect, however, and the job >>>>>> titles and "official status" of these IT guys make them >>>>>> almost indistinguishable from a front line help desk tech >>>>>> (no, I'm not dissing the help desk tech, don't go there). >>>>>> >>>>>> I am interested in hearing from anyone who works with or has >>>>>> worked with companies that have actually recognized such >>>>>> senior folks within their organizations. One term I've heard >>>>>> the term "IT Fellow", but I'm really not hung up on the name >>>>>> so much as the perceived role within the company and how >>>>>> such people might appear in the company ranks. >>>>>> >>>>>> I suppose I should add that the "VP of Administration" who >>>>>> is the ersatz CIO (in terms of corporate position) denies >>>>>> all CIO responsibility, indicating that the Director of IT, >>>>>> his immediate report, has all IT responsibility. There is an >>>>>> "Office if the CTO", I don't know if it would be possible to >>>>>> hang these highly senior IT people off that instead. I do >>>>>> realize that the de-emphasis of IT at the VP level probably >>>>>> means we're all screwed. Sigh. >>>>>> >>>>>> Thanks for any input... >>>>>> >>>>>> Tim >>>>> >>>>> _______________________________________________ Discuss mailing >>>>> list Discuss@lists.lopsa.org <mailto:Discuss@lists.lopsa.org> >>>>> https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This >>>>> list provided by the League of Professional System >>>>> Administrators http://lopsa.org/ >>>>> >>>> >>>> >>>> _______________________________________________ Discuss mailing >>>> list Discuss@lists.lopsa.org <mailto:Discuss@lists.lopsa.org> >>>> 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 joseph.a.k...@gmail.com >>>> <mailto:joseph.a.k...@gmail.com> >>> >>> >>> >>> _______________________________________________ Discuss mailing >>> list Discuss@lists.lopsa.org >>> https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list >>> provided by the League of Professional System Administrators >>> http://lopsa.org/ >>> >> >> - -- >> I prefer to use encrypted mail. My public key fingerprint is FD6A 6990 >> F035 DE9E 3713 B4F1 661B 3AD6 D82A BBD0. You can download it at >> http://www.megacity.org/gpg_dballing.txt >> >> Learn how to encrypt your email with the E-Mail Self Defense Guide: >> https://emailselfdefense.fsf.org/en/ >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0 >> Comment: GPGTools - https://gpgtools.org >> >> iQIcBAEBCgAGBQJViCiPAAoJEGYbOtbYKrvQni0QAIHJfPF7cw3XsKodVzTbirYH >> 0La9FlAwBzogLc4WwdP7Nihh/uazk/ARDkyCYS7J4XfAcKFQWOL6IZz8LBKvrKKc >> Ew3vxsiahoknSrtoueMTKpVkpIQ2fRP4hysUIhs87J1Wq+tthO1o/141qVuv6ZnZ >> wZB7aZ1kgeATyVVy4EoVLB7kHl/tnwV+YJLwv8u91RV9KsGHb6v8UIoirlSprZ1s >> Xo3kLXlv/Nl/EQ31tM0qym5iFG3Tvo+/EgVo4j67Q0FLHjhNUQH1MRVdQPZNqRSl >> NYjH/QCcgqgumfV4VS1ojuxM5iHhM4hswTAzO7NQoR3N3Iu3A5neGX9pRnANVHZ9 >> mUw7+sEz3mIcJG4RZIMlN6zBP7MrQaTCxKLX+AgZPnvKJ8IItEUbeSmzSDdrVgBQ >> 31B0KHuARGRBCdgeuHZf0SGGHKxN66IJPPoQvD4j5yFXr9O1kB2jxuZPRjPURb3N >> M7kQYPkRuVywG4B6g1shfVY+oG/BUvOsuDbXv3N8Y4sa7VFi3B/bPJvt5UPGCC4i >> p3+WC0PVsSU2g1Te9gT6ZTT16uHY5ohct6+jPBLhp1qfZguNMLibT7rZD+6KsznM >> JW9FQbNkhUo3wl8kCqdv9lH+TTVvh/4BsFMxYZKYgkMbbzMVMiHtL5Ch68/mLHWO >> euKiPc+65aam6bPbx48c >> =JbCx >> -----END PGP SIGNATURE----- >> _______________________________________________ >> Discuss mailing list >> Discuss@lists.lopsa.org >> https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss >> This list provided by the League of Professional System Administrators >> http://lopsa.org/ >> > _______________________________________________ > Discuss mailing list > Discuss@lists.lopsa.org > https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss > This list provided by the League of Professional System Administrators > http://lopsa.org/ ---- "The speed of communications is wondrous to behold. It is also true that speed can multiply the distribution of information that we know to be untrue." Edward R Murrow (1964) Mark McCullough mark.mc...@gmail.com
_______________________________________________ Discuss mailing list Discuss@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
