>> Hello and welcome to the session featuring CarMax, driving efficiency and innovation with Ansible. I'm your host Christian Emery. I've been at CarMax for over 18 years in several roles ranging from operations to engineering. And in my current role, I'm responsible for CarMax's private cloud and continuous integration, continuous delivery pipelines. Now, my journey with automation started many years ago when I was a Unix and a Linux admin. Day after day, there was always that routine of manual tasks and processes like backups and routine maintenance. Each tasks had a lot of value to the business, but also required consistency, reliability and completion, and demanded quality for system stability. However, it was really boring to carry out the same thing every day. And personally I had a hunger to do more, bring greater value to the business, and need to realize greater satisfaction through my contributions in my career. And this is where automation came into my life. But before we jump into the presentation, I do want to share a little bit about CarMax. For those who may not know, CarMax has been a unique force in the used car industry since 1993. Through innovation and integrity, we've revolutionized the way people buy and sell used cars. We pride ourselves on the experience we provide our customers and our associates to make it possible. And by changing the way we assist our customers, we've also changed the journey of our associates, providing careers in exciting collaborative work environments. In today's presentation, I'm going to cover the early chapters of the CarMax Ansible story. Topics discussed will highlight business need, why we selected Ansible, rapid adoption and our results. And throughout the presentation, I'm also going to share a lot of thoughts and lessons learned to help you with your automation journey. And while listening to the story, I'd like to challenge you to think about your own business needs, technology challenges, and how your team organizes or organization improves approaches automation. Now in our first year, I was challenged to achieve 5,000 hours in efficiency using Ansible. That was a really intimidating number. But we met the challenge and exceeded it. And since then, we've continued to expand our automation through incremental improvements in everyday work to tackling larger operational challenges like regular changes to the environment, routine upgrades and improved infrastructure delivery. Additionally, we expanded automation adoption across multiple teams. We increased our user and contributor base by over five times. And some of that growth was through organic cross team collaboration. However, the greatest growth we had seen was through hackathons, innovation days where we're able to actively collaborate with other teams using Ansible to solve a business problem. And across all those users, we crossed over 15,000 hours of efficiency gain. And I use that term efficiency gained as a measurement to show not only just labor savings, but also tell the story behind other work we accomplished. And keep in mind, this is work that we wouldn't have been able to achieve without automation. And through that user base and hours of efficiency realized, we implemented over 150,000 successful changes. So how do we get there? Earlier I told you about my personal interest in automation and how I've carried that into my current role. And as a leader, I challenge my team to standardize processes and automate as much as possible. We started initially with really repetitive tasks, much like a game of whack-a-mole, but more importantly, through our experimentation, we quickly found we could get better and more consistent results. We soon applied the same approach to our automation for even greater success. But before Ansible, we started to run into issues where team members were taking a more siloed approach to the work. And in an early retrospective, we came to realize that there is a need for a bigger picture mindset. And from that point on, we agreed to standards to increase quality in our code. However, we still occasionally ran into quality issues. Some of these challenges were from homegrown technology, lack of integration and general infrastructure. Now, this is all compounded by the fact that we were using different scripting and programming languages, and not everyone on the team was familiar with Python when compared to say Bash or PowerShell. And while our homegrown solutions made a difference, we thought there could be better ways to meet that demand from the business to do more, better and faster. But like most things in technology, there's always a different tool and approach to get something done. However, some of these other tools required agents on servers making a deployment, a major effort on its own. And additionally, the learning curve was steeper for systems admins and engineers that don't have as much development experience. But this is where Ansible came into the picture. It was easy to use with human readable code. It was an agentless solution allowing us to get started without as much ramp up time. We also liked the fact that it was built on an open standard and a growing user community with an increasing engagement base from partner in vendor integrators. Even better, it had an API we could use to integrate our other platforms as needed. Most recently with the introduction of Ansible collections, we can use community content with greater focus on our automation while worrying less about building new tools. Now, once we select an Ansible as our automation platform, we took a three part approach to implementation and building a foundation for its use. And as I discuss each of these areas, I just like you to consider how to best prepare your teams or organizations for using Ansible. And while planning the transformation, be sure to identify any sort of constraints, roadblocks, and how you plan to measure those results. People, arguably people are the most important part of the equation. You can have all the processes and ways to measure return, but at the end of the day, you need your teams to make that work happen. Start by asking yourself, how well does the team handle change? Are there resource challenges with aligning people and work? Do the people have the right level of knowledge? Do they need training? And how do you start with one team to quickly begin or expand automation? Processes, documentation, standards. Processes are those great ingredients for success in any technology organization. How well are your existing processes documented? Are there any sort of defined standards methods to approaching work? What about your environments? How well does your organization handle executing processes or changes? And lastly, technology. We always need to show results for our investments and technology can help us show that math. Does your organization use metrics and measurements to track progress and results? How do you define or measure success for a project? How should return on investment be measured or quantified? Like I mentioned before, I can't stress it enough, your people, your teams are the most important part of implementing Ansible. They'll be responsible for implementing and developing, maintaining the platform as well as following standards to execute that transformation. And to be successful, they need to have tools, environments, and knowledge. But one of the great things about Ansible is its comparatively easy learning curve. Ansible playbooks are written in a human readable markup language. And I found that most systems admins and engineers are able to pick up Ansible relatively quickly. And for our adoption, some folks were able to pick it up and begin development, while others were a little bit more comfortable and confident with just a little bit of training. Now, Ansible also democratizes technology, freeing up admins and engineers from traditional OS defined silos. Additionally, Ansible playbooks can be consumed by teams without explicit knowledge of the systems or the underlying technology. That's only if a playbook is well written and returns consistent results each time. For us, we first used Ansible to improve our delivery and reduce repeatable manual tasks. Then we turned our attention to shifting left self-service and we're now focused on enabling developers by getting out of the way. These improvements afforded our teams more time to deliver new capabilities to the business. But another benefit to that is teams were able to devote more time to learning and experimenting. When teams first started automating, there's always that impulse or need to go after that biggest win. I would always caution folks to start simple, find small wins to build that experience. These incremental gains are going to feel small, but they quickly add up over time. And as you're going to see, the work should always be done in those smaller increments to return value faster while allowing the ability to quickly make corrections or change course all together. Now, another huge benefit of using that smaller code increment is reuse. These smaller building blocks can and will be used time and time again, reducing future development efforts. And as we quickly learned, one of the best places to start with automation are documented processes. Each step in a process is already documented, it's a huge opportunity to convert it to code and step through those manual processes. And at CarMax, one of the first places we started out was our server checklist process. The process was really thorough, had over a hundred steps to validate systems, make sure they have the right configuration security and specs for each build. And while that process really gave us good consistent results, it was time consuming. It was also prone to human error. But once we automated each of those steps in validations, we were able to turn our focus to the next bottleneck in the process to speed up delivery. And this is why it's always important to strive for quality through consistent predictable results. Automation is just another tool to help make that vision a reality. And when working with teams, it's also important to understand development best practices, keep it simple, and always use version control with code. Better yet, if you're from an ops background, I'd say partner with your development teams to help with this part of the journey. And lastly, when it comes to integrations between platforms and systems, use a modular design, be flexible because technology changes, and over time, so are your integrations. And when it comes to Ansible or just automation in general, there's always that need for efficiency, consistency, reliability, and flexible integrations. And to make this become a reality, you really need to take both a low tech and a high tech approach. If you recall earlier, I mentioned starting with documented processes. That low tech road involves using process mapping value stream analysis tools where you lay out processes end to end to determine the amount of time it takes to execute a process. These processes can be mapped out using whiteboard, sticky notes or by software tools. And from there, more importantly, you can visualize the process bottlenecks and the areas of improvement should be pretty visible. So for CarMax, what we did was we mapped out our infrastructure delivery. We found it was a huge opportunity. But it was also an area we were more comfortable automating given our deep knowledge of the process. So years ago, when we started the process, our time to deliver virtual environments was about two days. Fast forward to now, we can consistently deliver the same infrastructure in just minutes. And in turn, we reuse portions of that process and code for OS refreshes, virtual machine rehydration, system recovery and hypervisor upgrades, just to name a few. And by freeing up team members to do more knowledge work and spend less time on operations, we're able to pivot more resources on the team to align with the business on strategic initiatives. Team members also had more time to do training, research and development for new capabilities, and other areas for future innovation. Now, Ansible gave us a tool where we need to think more like a DevOps organization. And admittedly, a lot of what I've talked about so far has been very operation centric, but systems engineers were all of a sudden writing a testing code, building tools, delivering infrastructure via code, pipelines and API integrations. And as a result, we instantly had to build and strengthen the collaborative relationship between traditional development and operations teams, we had to break down those silos. But the developers appreciate it because they can focus on developing code and not necessarily worry about environments being ready in time or configured correctly. Conversely, operations teams can be focused more on improvements, new capabilities, and spending less time on firefighting. But regardless of the outcomes, you need data to tell that story. And these data elements can start with the hard numbers from reduced cycle times when we were mapping out processes, you can use delivery and SLA metrics. Those were some easy go to numbers. But also consider how you tell that efficiency story. And remember, ROI isn't always about money or the time savings. So as an example, metrics we used included the number of teams using the platform, active contributors, workflows, processes run, and efficiency gain calculations. And as we evolve our journey, the metrics may change along with that story that we need to tell. So to recap, at CarMax, we put people first and you should too. Think about the resources and knowledge your teams are going to need to be successful. And like I said earlier, remember to start small, reuse code as much as possible. This is going to help teams realize faster return on their efforts and start that snowball effect where gains quickly compound over time. Have a vision and decide on targeted outcomes for your team or organization. Then build ROI metrics to help tell that story. But a big part of innovation is experimenting and learning from mistakes. So take a chance, try something new. And in closing, I'd like to thank you for your time. I sincerely hope our results and lessons learned will help you on your automation journey wherever it takes you.