Resetting the trial license ESX 6.0
December 28, 2015 § Leave a comment
The following resets the trial license in ESX 6.0
[root@ns3009753:~] rm -r /etc/vmware/license.cfg
[root@ns3009753:~] cp /etc/vmware/.#license.cfg /etc/vmware/license.cfg
[root@ns3009753:~] /etc/init.d/vpxa restart
I then needed to restart ESX to get it to work.
Source: http://esxi.oeey.com/2013/11/how-to-reset-esxi-trial-license.html
RHEL 7.0 without registering with Red Hat
September 24, 2014 § Leave a comment
I wanted to get Red Hat Enterprise Linux 7.0 running without an account with Red Hat. Below is the method to copy the DVD and register it’s content with yum:
First copy the content of the DVD into a new directory
mount /dev/cdrom /media
cd /home/ascknd
mkdir repo
cd repo
cp -ar /media/. .
Now create the file “/etc/yum.repos.d/RHEL_7.0.repo” with the following content:
[RHEL_7.0_Disk]
name=RHEL_7.0_x86_64_Disk
baseurl=”file:///home/ascknd/repo/”
gpgcheck=0
LinkedIn Control Chart
July 16, 2014 § Leave a comment
I’ve been thinking about doing a control chart post for a while now. Control charts go back to the 1920’s and one normally encounters them in the context of W. Edwards Deming, though they were actually originated by Walter A. Shewhart, and Quality Assurance. They are used to examine variation in the output of processes, principally with the aim of determining whether the process is in a state of “statistical control”.
In a process that is in statistical control, the causes of variation are in the system all the time and one may predict, within statistical bounds, the future performance of the system. A typical example from Deming might be normal variation in raw materials from a supplier, though it could equally apply to the difficulty of helpdesk calls entering a service desk.
For a system that is not in statistical control variation is introduced from causes that are external to the system and are not present at all times. A Deming example would perhaps be a change in the supplier of raw materials. An IT example might be a major system change resulting in a sudden increase in calls of a certain type. Clearly this undermines ones ability to reliably predict future process performance.
I thought it might be nice to see if my LinkedIn presence was in statistical control. That way, if I now make some changes to my profile, it should be possible to determine whether the effect is significant, or lost in the statistical noise of LinkedIn. This is possible because if the process is in statistical control, we can use the past behavior to come up with an expectation of what the system would produce in the future, in the absence of external sources of variation
The LinkedIn “Who’s Viewed Your Profile” graph gives weekly profile views going back 90 days. To begin with, let’s look at the relatively small number of views that I’ve been getting:
To turn this into a control chart, we calculate the mean (2.6) and the standard deviation (1.4). We now plot two lines at mean +/- three standard deviations:
So, two things are clear.
1. The process is in statistical control. Based on the past 90 days, we can expect to see profile views between 0 and 7 with a mean of 2.6.
2. The process is not very tightly bounded.
3. I could use more traffic to my profile.
In my next post I’m going to update my profile with some of the various things LinkedIn suggest, and see what happens.
An Observation On Teams
June 26, 2014 § Leave a comment
I found the following quote in a book on Crew (or Cockpit as it used to be called) Resource Management (CRM). In this context, CRM is a methodology originally developed in the airline industry to improve the effectiveness of teamwork in the cockpit and reduce/mitigate error.
The quote is about a study on fatigue on air crews:
Crews in the post-duty condition had less pre-simulation sleep and reported significantly more fatigue, as expected from the research design. The surprising finding, however, was that fatigued crews were rated as performing significantly better and made fewer serious operational errors than the rested, pre-duty crews. This finding was counterintuitive but had major implications relevant to the importance of team formation and experience. By the nature of the scheduling of flight operations, most crews in the post-duty condition had just completed three days of operations as a team, while those in the pre-duty condition normally did not have the benefit of recent experience with the other crewmember. When the data were reanalyzed on the basis of whether or not crews had flown together recently, the performance differences became even stronger. The findings suggest that crew scheduling practices that result in continuing recomposition of groups and a need for frequent formation of new teams can have significant operational implications. For example, three recent takeoff accidents in the United States (one involving a stall under icing conditions, one an aborted takeoff with an over-run into water, and one a runway collision after the crew became lost in dense fog) involved crews paired together for the first time.1 The implications of crew pairings are discussed further in the chapter by Hackman.
p.13 Crew Resource Management
Copyright 2010, by Elsevier Inc.
In other words, regardless of how competent people are as individuals, to be an effective team, people need to get to know each other. The positive impact of familiarity was strong enough to more than cancel out the, presumably, negative impact of fatigue.
Merging Helpdesks, A Performance Analysis
June 23, 2014 § 2 Comments
I recently encountered a scenario where two helpdesks were to merge. One large, with relatively poor response times, and a smaller one, with relatively good performance. The question was, what would be the impact of merging the call queues on the current customers of the smaller helpdesk? It might seem that the performance of the smaller helpdesk would necessarily be significantly harmed. I’m going to show that that isn’t necessarily the case.
Neil Gunther’s PDQ::Perl1 can be used to do a Mean Value Analysis and predict the impact of combining the queues. That is to say, work out the average performance. I wrote a small Perl script to do this, documented here:
https://ascknd.com/2014/06/23/helpdesk-queue-analyser-pdqperl/
Paradoxically, what we find is that, under certain circumstances, merging the two queues delivers better performance than either helpdesk was capable of delivering on its own:
Example:
Site A has 4 staff working on their queue (e.g. NetApp support), with a call coming in on average every 12.5 minutes. It takes them 30 minutes to deal with each case (excluding time spent in the queue waiting for an operative to become free). At site B they have 6 staff dedicated to a similar queue, who also take 30 minutes to deal with each case, but have an incoming call rate of one call every 5.6 minutes.
Using the previously mentioned script, the behaviour of these helpdesks can be analysed with the following parameters:
perl ./helpdesk_response.pl 4 30 0.08 6 30 .18
What we find is that Site A is 60% utilized and typically only keeps calls waiting in the queue for just over 5 minutes. Site B is 90% utilized and keeps callers waiting in the queue for 37 minutes. When the two queues are combined both sites are 78% utilized and experience waiting times in the queue of <5 minutes. So both sites experience better performance.
How did merging the work of a site with good performance and a site with relatively poor performance lead both sites to improve? Two things are going on:
1. The impact of utilization on performance is non-linear. Moving from 60% utilization to 78% utilization does relatively little harm to site A compared to the benefit experienced by site B.
2. More helpdesk operators are more efficient, from a queueing perspective, than fewer helpdesk operators given the same utilization. That is to say, 6 workers at 60% busy will be more responsive than 4 workers at 60% busy even though in both cases the individual helpdesk operators are performing identically. This is because the more operators there are, the greater the chance that one of them will be free when a call comes in.
Conclusion:
In the general case, one can’t assume that combining the queues of the two helpdesks will necessarily cause the performance of a smaller high performing helpdesk significant harm.
ascknd 