jallspaw

- Metrics collection
- PaaS/IaaS evaluation/investigation
- Automation (auto-build, auto-recovery)
- Fault tolerance 
- Availability
- Monitoring
- Performance
- Capex and Opex forecasting
- Outage response

jallspaw

-- Problems that need solving in order to make a real-world Angry Birds game --

Questions by Sadie

1. How to get numbers on the bird's heads when they cheer?

2. How do we make the pigs disappear? 

3. How can we make the pigs look all squished-up with black eyes?

jallspaw

For shits and giggles, I ran (http://code.google.com/p/byte-unixbench/) on a c1.xtralarge EC2 instance:

   BYTE UNIX Benchmarks (Version 5.1.2)

   System: ip-ec2.thing.com: GNU/Linux
   OS: GNU/Linux -- 2.6.21.7-2.ec2.v1.2.fc8xen -- #1 SMP Fri Nov 20 17:48:28 EST 2009
   Machine: x86_64 (x86_64)
   Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
   CPU 0: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz (4669.8 bogomips)
          Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSCALL/SYSRET, Intel virtualization

jallspaw

Myth: during a retrospective investigation, something is waiting to be “found”

I’ll cut to the chase: there is nothing waiting to be found, or “revealed.” These “causes” that we’re thinking we’re “finding”? We’re constructing them, not finding them. We’re constructing them because we are the ones that are choosing where (and when) to start asking questions, and where/when to stop asking the questions. We’ve “found” a root cause when we stop looking. And in many cases, we’ll get lazy and just chalk it up to “human error.”

As Erik Hollnagel has said (Hollnagel, 2009, p. 85):

“In accident investigation, as in most other human endeavours, we fall prey to the What-You-Look-For-Is-What-You-Find or WYLFIWYF principle. This is a simple recognition of the fact that assumptions about what we are going to see (What-You-Look-For), to a large extent will determine what we actually find (What-You-Find).”

More to the point: “What-You-Look-For-Is-What-You-Fix”

jallspaw

This is excerpted from: http://rotorlab.tamu.edu/me489_SP11/README/2010%20ASME%20Unwritten_Laws_of_Enginering.pdf


Promises, schedules, and estimates are necessary and important instruments in a well-ordered business.

Many engineers try to dodge making commitments. You must make promises based upon your best estimates
for your part of the job, together with estimates obtained from contributing departments for theirs. No one
should be allowed to avoid the issue by saying, “I can’t give a promise because it depends upon so many
uncertain factors.” Of course it does. You must account for them, estimating best and worse cases, and then
provide neither laughably padded nor unrealistically optimistic schedules. Both extremes are bad; good