 Every day is a good day for enjoy a good coffee at the bar, before starting the morning work. But every IT administrator knows that a good day is a day where all that happens, it a predicted stuff. “If I have a plan, I can manage everything without pain” I say to myself. When we started to have Workload Automation offered as a Service (Try it!), we have started to be customer of our product. And I was suffering of the same pains… What happens if I need to upgrade an agent? Can I deliver the build to the test before the start of the day? If I don’t my boss will blame me: the test team will declare to be late! Stressful things. Stressful because I was not knowing enough! But today, with the new enhancement we have made for predictive analysis in the 9.3 release, I can say that my life has changed, and I hope it will change the life of all the other IWS administrators. How this happened? The IWS build, is driven by IWS! Just a bit introduction on how we build the product: the IWS product is built for 11 different platforms: we need a build for each platform, and we have several components built in parallel, but some other common parts. Of course, we use the IWS to orchestrate all the build processes, with several different jobs, and we need to ensure that the build will be available before 8 AM to test team to be installed.  The IWS build process Gantt view. We have one agent for each build platform, and we build every day in the night time. The entire build process takes in average 7 hours, if everything goes well. But of course we need to quickly assess impact of any changes to the build process. Enhanced job duration prediction With the new 9.3 version, the new enhanced algorithms for the job duration prediction, was better estimating the end time of the builds: during the week-ends, the builds was taking less time because of less work on the build machines: so I was able to estimate more accurately when I was able to deliver to test team the build on Monday, on Tuesday and so on. In fact the new enhanced algorithms for the job duration prediction can easily understand job duration patterns (weekly, monthly, by Run Cycle, etc), based on historical data, and so now they can give a different estimation of jobs on Monday, on Friday, but they can also detect of a job normally at first day of the month takes more time than usually. My job duration was predicted well with this built-in algorithms, but for who needs more you can also configure SPSS (http://en.wikipedia.org/wiki/SPSS) predictor, that can provide more accurate prediction and provides more recognition patterns.  Job estimations are taken per week, monthly and per Run Cycle, and can be overridden. What happens if I change the start time of a job of the build? Last week one of the developer of the team was late in developing a task, but the code was absolutely needed to be in the next day build. The build process starts at 11.00 PM (well, who writes code after 11 PM???). He contacted me, at 10.30 PM saying he was needing just one hour, and said if I was able to postpone the build. If this happened in the 2014 I was just saying: no! While with the new what-if analysis I was quickly able to see what happens if I change the start time of the component he was working on (the java component):  After changing the start time of Java job. By using drag and drop, I was able to simulate the change in the start time of the java job: in the figure 2 you can see all the changes compared with the baselines (the striped boxes). Finally I realized that moving the start time of the java job of one hour, it was impacting the time of the entire build of 37 minutes. The build had no issues in this change to be ready for 8 AM.  After java job one hour change, impact was of 37 mins. What happens if one build agent is down? One other need I had in the past, was to deal with unavailability of the build machines. Due to maintenance, I often receive a mail regarding the unavailability of one of the workstation of the build. Now I can easily simulate what happens in this case:  And see impacts on build:  Some jobs moved due to workstation unavailability.  Issues highlight for workstation unavailability.  Issues alerting a critical job not matching deadline. So now, when I receive the mail from the IT department, I can quickly send an email to the test team saying “Today the build will be late…” Or I can try to change the workload: with the what-if analysis I can easily understand what the critical path of any job is. The critical path means the list of the job that are currently impacting the start time of the job:  Critical path of the job TWSBLD_DAILY_COPY_JARS. Using this feature, I can quickly found what job I can drop, to speed up the build process. For example someday I trade the availability of the windows platform for having quickly the build! So I simulate the cancel of the job, and I see the results.  The new critical path after dropping the windows build. The better I know, the better I feel! The unpredictable is always something that we have to deal every day. But having the ability to quick understand impact of changes, is something that is very valuable in any IT environment. Working at 9.3 release it was very challenging: we applied a new methodology (IBM design thinking) to deliver features that are more near to who will really use our code. But now that I’m also a “customer” of our product, I can touch with hand what means using IWS, and I can really feel IWS administrator’s pains. With the enhanced job duration and what-if analysis my life as IWS admin has started to be better; I really hope that every IWS admin life will be made better by this new features!
Luca is currently the UI Architect of IBM Workload Scheduler (Dynamic Workload Console), acting also as Scrum Master for product offered as on-premises solution but also as SaaS and PaaS (Bluemix).
0 Comments
Leave a Reply. |
RSS Feed
