![]() ![]() Organizations that efficiently prioritize performance work look to these and other signals from both pre-production and in-production systems to see where to apply more of their efforts. Other ways to view system performance, such as rate-error-duration (RED) signals and looking towards business metrics in analytics platforms, ensure that critical path and revenue-generating user experiences are working as expected. ![]() Often, examples that rank high on one or more of these vectors include user/consumer authentication, cart checkout, claims processing, etc. Errors From a perspective of “process error,” how many times has a specific service update or patch been held up by long-cycle performance reviews? Which systems do we need fast time-to-deploy or where slow feedback cycles cause the product teams to slip their delivery deadlines (immediate or planned)?.Saturation Which services have experienced “overflow” - the need for additional VMs/costs to horizontally scale - or are constantly causing SEV-n incidents that require “all hands on deck” to get back into reasonable operational status?.Utilization Which core APIs or microservices are at the nexus of many other business processes, thereby ballooning their usage as a shared enterprise architecture component?.If we adapt this method to help us prioritize which systems under test (SuT) for which to automate performance feedback loops, it would look something like this: One book that every performance-minded engineer should read is System Performance: Enterprise and the Cloud by Brendan Gregg, wherein he provides useful mental models such as Utilization-Saturation- Errors (USE) for system analysis. ![]() By “easy,” I don’t necessarily mean the path that is perceived as least complex I mean easy in the project management sense of low hanging fruit or obvious to business owners - in other words, “easy to agree upon, easy to see the importance of.” It’s a lot easier to make a case for performance testing systems in the critical path than services that are far removed from what others think is important. Prioritization is at the heart of what’s often missing with the statement “early and often.” That’s why I tend to include “easy” to the list to remind us that, if we have picked a path that includes high resistance, we’re likely to fail. Automation is key, but so is prioritizing which areas of architecture to “left shift” performance testing into. In a nutshell, late-stage performance fixes are too costly to do anyone good and there are a few elements that need to be in place to expect to get performance feedback early in development cycles. The modern mantra: early, often, and easyįeedback loops for performance are a critical step for modern continuous delivery practices. ![]() Those SMEs are then able to apply their expertise to PI planning, process automation, and DevOps teams who need more help than others. Many Tricentis NeoLoad customers are now providing their product teams “self-service” resources and training in order to scale the performance mindset beyond a small band of subject matter experts (SMEs). Particularly for a topic like performance testing, “easier is likely better” goes not only for test scripting but also for automating processes and infrastructure requirements, and for consuming the results of testing. If you make it easy to do something right (e.g., provide templates, good practices instructions, and informed process guardrails, as so many SREs do for product teams) and hard to do the wrong thing, you’re likely to improve software quality far more than expecting someone who’s already too busy to become an expert in performance overnight. But think about that for a minute in the context of all the DevOps tools and technologies. Things that are easy to do are easier to expect people to take up and make part of their process. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |