How can a small, mainly click-next-admin team/culture best get started on the journey toward Infrastructure-as-code, build-test-deploy / Release Pipeline? I see many blogs and books about more mainstream DevOps, but our shop is more like the one referred to in the Microsoft / Chef Release Pipeline whitepaper, where we only create and maintain our own infrastructure operations management files and scripts, mainly for internal corporate facing apps and systems. We don’t need to worry about any customer facing or other style of high visibility web pages or mobile apps, but I think we could definitely improve our efficacy of managing the on-premises environments we have, with a lean, properly trained, empowered staff. We have mainstream skills across VMware, Windows, NetApp, SQL, Exchange and Citrix technologies; all of which also play nice in a PowerShell-centric world. We have a few people with foundational PowerShell skills, but have not yet reached a tipping point where we really use it the way I think we could / should. Instead, we feel stuck in the rut of jumping through RDP to fix our Production ‘snowflakes’, instead of working out automated fixes in a ‘lab’, then using a DevSecOps style pipepine to get the fix to production.
Have a question of your own? Please ask.
DevOps is DevOps; the benefits potentially apply to anyone producing any code, for any reason, whether it’s customer-facing or not. So I agree with you – you can definitely achieve a lot.
You might not love this answer, Bryan, but it’s, “you just gotta do it.” The next time you need to just quickly fix something via RDP, don’t. Do it the way that you know is right. Yeah, it’ll take longer that time, but you’ll only have to make that investment once for that task. From then on, it’ll be easier and faster, and you’ll start to see a return. Over time, this’ll accrete to the point where not running a script to do something will feel odd.
When I worked for Bell Atlantic Network Integration, back in the day, I had a small team of four admins, a 3-person help desk, and a 4-person desktop support team. We supported a couple of thousand users spread across a dozen or so sites. The help desk and desktop team brought me problems all the time, but I almost never fixed them (unless it was a fire drill, of course). Instead, I wrote a script, gave it to them, and let them fix it. Sure, this was a lot of VBScript and KiXtart back then, but same thing applies.
You just have to make a cultural shift. We aren’t going to do it this way, anymore. We’re going to change. I mean, I know it’s super-easy to write that and very hard to make it stick, but that’s really the only thing you have to do. Decide to change. And then stick with the decision.
Start small. Pick one task, work on that, and then pick up another task. Start logging your tasks in a ticket system or something; you’ll want to know how much time these things take to do manually, how much time it takes to write the script, and how much time you save. Take your salary. Multiply it by 1.4. Divide that by 2,000. That’s your fully-loaded hourly rate. Multiply that by the amount of time you save per year by automating a task, and that’s how much money you save. Multiply your hourly rate by how long it took to write the script, and that’s how much money you spent. So long as the savings is bigger than the spending, you’re #winning. Doing that math can be a big help in making the cultural shift, because it represents a business outcome, whereas, “we’re just going to write scripts instead of manually facing problems” is a little abstract from a business perspective.
Good luck! Let me know how it goes!