> 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."
You should read the Phoenix Project, the security manager basically has a nervous breakdown. And then they bring him into the fold. On Wed, Jun 24, 2015 at 6:02 AM Mark McCullough <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 [email protected] <mailto:[email protected]> > 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 [email protected] <mailto:[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] > <mailto:[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/ > > > - -- > 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 > [email protected] > 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 > [email protected] > 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 > [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/ >
_______________________________________________ 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/
