As the general population becomes more app-savvy and less patient, app performance has become a major issue for any company needing to keep the customer’s attention. Need statistical proof? 47% of consumers expect a page to load in two seconds or less, and 40% will abandon a website that takes more than three seconds to load. Three seconds is of course an eternity in the age of 5G and IoT. A LOT can happen in those three seconds.
According to Gartner, the average cost of IT downtime is $5,600 per minute and typically ranges from $140,000 per hour on the low end to $540,000 per hour at the higher end. And that’s not even taking into account the “hidden” costs of downtime, such as erosion of trust—something that can happen especially fast when it comes to financial services applications.
As DevOps teams release and automate with increasing frequency, performance and availability problems have soared, leading to more time troubleshooting and less time developing amazing apps. This means reducing Mean Time to Identify (MTTI) and Mean Time to Resolve (MTTR) is more important than ever, especially in the financial services industry where massive disruption has become the norm.
97% of Logged Errors are Caused by 10 Unique Errors It’s 2021 and one thing hasn’t changed in 30 years. DevOps teams still rely on log files to troubleshoot application issues. We trust log files implicitly because we think the truth is hidden within them. If you just grep hard enough, or write the perfect regex query, the answer will magically present itself in front of you.
Three OverOps engineers answer the question, “What is OverOps?” OverOps automates issue root-cause analysis at run-time, eliminating the detective work of scanning logs to identify critical errors. OverOps quickly pinpoints why critical issues arose with context-rich insight into complex backend Java and .NET environments. No code changes are required.
Here we go again, the development team gets a bug report from a customer experiencing an issue in production. The report has insufficient information to actually engage on the issue. No logs attached to the case, a barely usable reproduction path, and no information on the data that led to the issue. Sound familiar? Suppose a nightly job starts randomly failing about 12% of the time without any explanation.
Ever since Oracle, in 2018, split its JDK build licensing into two tiers—commercial, which can be used for free in development and testing but you have to pay to use it in production, and open-source, which is free in any environment—quite a few open-source builds based on the OpenJDK source code have appeared. With all these choices, we felt like it was a good time to review the currently available OpenJDK builds.
A relatively new user of OverOps was examining exceptions in their production environment and noticed an AmazonS3Exception. What surprised the user was that the exception had been seen for the first time 4 years ago, and since then it had happened 2.6 million times.
A recent report by the Consortium for Information & Software Quality (CISQ) revealed the economic impact of poor software quality in the US. Below, we outlined our favorite takeaways and recommended solutions. Following a year where digital experiences were thrust into the spotlight, CISQ has released The Cost of Poor Software Quality in the US: A 2020 Report, an update to their 2018 analysis.
The Consortium for Information & Software Quality (CISQ) recently released a report about the cost of poor quality software (CPSQ) in the US in 2020. Reading between the lines, we can see how the COVID-19 crisis contributed to making this problem even worse. This past January, CISQ released The Cost of Poor Quality Software in the US: A 2020 Report and presented a webinar covering the key findings.
