<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.2.1" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Quantifying The Impact Of Poor Performance</title>
	<link>http://ericgoldsmith.com/2008/10/28/quantifying-the-impact-of-poor-performance/</link>
	<description>Random thoughts on life and technology</description>
	<pubDate>Fri, 12 Mar 2010 11:31:34 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.2.1</generator>

	<item>
		<title>By: Mark Morscher</title>
		<link>http://ericgoldsmith.com/2008/10/28/quantifying-the-impact-of-poor-performance/#comment-308</link>
		<author>Mark Morscher</author>
		<pubDate>Sat, 08 Nov 2008 14:34:46 +0000</pubDate>
		<guid>http://ericgoldsmith.com/2008/10/28/quantifying-the-impact-of-poor-performance/#comment-308</guid>
		<description>What you end up representing is more of an "actual unavailability" of a site rather than a "wall clock" availability that a typical, synthetic monitoring provides (both have their purposes).  By determining the % of "missed page views" you are theoretically representing the % of failed requests by the user, or the perceived unavailability to them.  Thus, with this method, the impact of an outage near peak (like your example) is more than a maintenance outage at 4am.

The next step after calculating the revenue impact would be to calculate an operational support cost for addressing the incident.  This includes:

- On call time spent on addressing the issue
- NOC attention to the issue
- Additional monitoring/tools established to detect in the future
- Post Mortem meetings/attention
- Future dev/process work needed to fix the bug/root cause

In an ideal world, if adequate costing information exists, you should be able to correlate reduced TCO for operational support with improved Availability, in addition to improved customer sat and revenue.

Mark</description>
		<content:encoded><![CDATA[<p>What you end up representing is more of an &#8220;actual unavailability&#8221; of a site rather than a &#8220;wall clock&#8221; availability that a typical, synthetic monitoring provides (both have their purposes).  By determining the % of &#8220;missed page views&#8221; you are theoretically representing the % of failed requests by the user, or the perceived unavailability to them.  Thus, with this method, the impact of an outage near peak (like your example) is more than a maintenance outage at 4am.</p>
<p>The next step after calculating the revenue impact would be to calculate an operational support cost for addressing the incident.  This includes:</p>
<p>- On call time spent on addressing the issue<br />
- NOC attention to the issue<br />
- Additional monitoring/tools established to detect in the future<br />
- Post Mortem meetings/attention<br />
- Future dev/process work needed to fix the bug/root cause</p>
<p>In an ideal world, if adequate costing information exists, you should be able to correlate reduced TCO for operational support with improved Availability, in addition to improved customer sat and revenue.</p>
<p>Mark</p>
]]></content:encoded>
	</item>
</channel>
</rss>
