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

-- 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

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

jallspaw

Adrian -

I appreciate that you spent time in writing this post. I know I've been up until 2am writing similarly long ones as well. I will take responsibility for having what is likely an irrational response (I blame Twitter for that) to the term "NoOps", but I invite you to investigate why that might be. I'm certainly not the only one who feels this way, apparently, and thus far have decided this issue is easily the largest distraction in my field I've encountered in recent years. I have had the option to simply ignore my opposition to the term, and just let the chips fall where they may with how popular the term "NoOps" may or may not get. I have obviously not taken that option in the past, but I plan to in the future.

You're not an analyst saying "NoOps". Analysts are easy (for me) to ignore, because they're not practitioners. We have expectations of engineering maturity from practitioners in this field of web engineering, especially those we consider leaders. I don't have any expectations from analysts,

jallspaw

--- wireshark-1.7.0/gtk/main_menubar.c 2011-11-08 16:11:43.000000000 -0500
+++ wireshark-1.7.0-etsy/gtk/main_menubar.c 2012-04-06 13:08:46.000000000 -0400
@@ -1634,8 +1634,8 @@
    { "/Analyze/DecodeAs", WIRESHARK_STOCK_DECODE_AS, "Decode _As...", NULL, NULL, G_CALLBACK(decode_as_cb) },
    { "/Analyze/UserSpecifiedDecodes", WIRESHARK_STOCK_DECODE_AS, "_User Specified Decodes...", NULL, NULL, G_CALLBACK(decode_show_cb) },
 
- { "/Analyze/FollowTCPStream", NULL, "Follow TCP Stream", NULL, NULL, G_CALLBACK(follow_tcp_stream_cb) },
- { "/Analyze/FollowUDPStream", NULL, "Follow UDP Stream", NULL, NULL, G_CALLBACK(follow_udp_stream_cb) },
+ { "/Analyze/FollowTCPStream", NULL, "Zoom and Enhance! (TCP)", NULL, NULL, G_CALLBACK(follow_tcp_stream_cb) },
+ { "/Analyze/FollowUDPStream", NULL, "Zoom and Enhance! (UDP)", NULL, NULL, G_CALLBACK(follow_udp_stream_cb) },

jallspaw

# Give a little warning about what is required before we start.
msg="Before running this script, make sure:
  1. You are not on ${THIS_HOST}.
     This backup was generated on ${THIS_HOST}. It cannot be applied to
     ${THIS_HOST}.
  2. You have removed the broken mysql server from the prod conf via
     deployinator.
  3. There is no data on this host. THIS SCRIPT WILL DESTORY THE CURRENT MYSQL
  INSTALLATION. THERE WILL BE NO GOING BACK.

jallspaw

"Jazz Improvisation and Organizing: Once More from the Top" http://web.cba.neu.edu/~mzack/articles/jazzorg/jazzorg.htm

"Resilience, Adaptation and Improvisation: increasing resilience by organising for successful improvisation" http://www.sintef.no/project/Building%20Safety/Publications/3rd%20RE%20symposium,%20resilience_adaptation_improvisation,%20TOG.pdf

"Space Operations Officers As Jazz Musicians" http://www.smdc-armyforces.army.mil/Pic_Archive/ASJ_PDFs/ASJ_VOL_9_NO_1_008.pdf

"Supporting Improvisation Work in Inter-Organizational Crisis Management"

jallspaw

Pinterest (Velocity Santa Clara)
Tumblr (Velocity Berlin)
Box (Velocity London)
Etsy (Percona)
Flickr (MySQL Conf)

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

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”