Unfortunately, we don't live in a perfect world, sometimes small errors or accidentally overlooked things can create bigger problems down the road. And while it’s difficult to go back in time to fix foundational code, organizations in the IBM i ecosystem now have a way to proactively identify and repair the possibly hidden problems that can create a cascade of issues as system load evolves.
Modern DevOps results in a continuous stream of small changes. But changes to even a few lines of code can significantly influence system behaviour. To maintain performance benchmarks, IBM i DevOps teams need a way to safely introduce changes while keeping an eye on operations volume and possible interactions with other parts of their IT stack.
This is next-to impossible with traditional methods. A developer writing code for one module has no idea what the final effect of will be on the system as a whole. In heavily multithreaded environments, there are simply far too many dependencies to analyze. To theoretically estimate behavior in a real system consisting of thousands of threads is tough enough. Add in other jobs, file structures, and the hardware configuration and it becomes clear why engineers often struggle.
The quirks of the IBM i operating system also add to the puzzle. Forget about CPU overload — the key to diagnosing IBM i performance bottlenecks is the system’s wait accounting tool. Wait accounting allows teams to track the actual run-wait time signature of software in development. The only problem is that the number of interactions to trace and analyze far exceeds the capacity of a human developer, especially in real time.
This is where AI can save the day. i-Rays uses an AI/machine learning engine built specifically for IBM i to digest wait/run-time data and deliver a clear, human-readable understanding of the outcome of code changes. First, i-Rays maps application code into corresponding system structures. Then the machine learning model learns the behavioral patterns of both the system as a whole and these structures. This allows i-Rays to determine whether a set of changes keep the system within best practices or cause it deviate.
The key to i-Rays’ technology is its time signature (or footprint) analysis at the microcode level. i-Rays analyzes timing patterns because that’s where dependencies come into play. By examining the code footprint in the actual software and hardware stack with all its dependencies, i-Rays is able to present a detailed view of behavioral patterns that clue DevOps teams into potential problem areas.
i-Rays leverages that knowledge to inform IBM i DevOps teams in real time about what they need to do to keep system operations safe, stable, and optimized. Teams have access to two critical streams of information:
The Anomaly Detection module alerts teams about unexpected phenomena in the system, such as an increased number of conflicts or a change in lock time.
The Advisor (best practices) module offers recommendations for optimizing memory management, IO structure, and job runtime parameters to reduce conflicts and achieve smooth system operations.
Put simply, i-Rays places all application context into a single pane of glass, keeping teams aware of the holistic picture. Teams can see all the jobs involved in an application, plus its inter-process or inter-system communications objects. i-Rays enables not only before-after analysis, but also direct code optimization, including what-if analysis and multithreaded sweet spot-setting. The result is a shorter MTTD and MTTR.
If you want, we can review 2-3 recent incidents and map which behavioural patterns would have been tected - and what data you need to reduce time-to-root-cause.
