(machine turning on)
- Welcome to the Chaos
Community Broadcast.
I'm your host, James Wickett,
and I would like to welcome
the internationally recognized
travel writer, motorcycle expert...
- Whoa, whoa, whoa, wait,
wait, don't I do the intros?
I do the intros, right?
- I wanted to give him a "Cheerio!" Casey.
I forgot, yeah Casey,
you're doing the intros,
take over from here.
- Okay, welcome to the
Chaos Community Broadcast.
I'm your host Casey Rosenthal.
It's such a pleasure to
welcome Russ Miles to the show.
Russ, thank you for inviting
us into your lovely home
here in London and former Europe.
We should start by
explaining to our audience
that the UK mile is indeed
the same as the US mile.
So no need to refer to
you as Russ Kilometers.
- They're not gallons, they're different.
(Russ laughing)
- Russ kilometers, that's a good one.
- I've not heard that one before.
- I should also mention
that we are gonna be
doing the interview in English
if that's okay with you, Russ?
- If we must.
- You know one of the
things I've noticed about
travel writers today is that
much of the writing tries
to tell me as the reader, what to think,
what I should feel, yet
in your Motorcycle Diaries
you really told a story of your journey
and you allowed the reader to
come to their own conclusions.
How did you manage that kind of balance?
- It was absolutely caused by necessity.
I couldn't possibly make
anything up as I was writing
a chapter every day as I did the rides.
So it was usually get wherever I'm going,
recover, try not to drink too much beer,
and then go back to the
hotel and try and write
whatever had just happened down.
So it had to be just whatever was going
through my head at the time.
I couldn't possibly translate or interpret
any of it at the time, and it
works pretty well for that,
I've had some pretty good feedback.
But you have reminded me that
there's at least a chapter
missing from the end
of that book, I think,
where I bring it to a close
and meet people like Casey in Chicago.
I should probably...
Yeah, I've definitely got
photos of Casey from that.
So I think it will be a
good thing to include.
- They're in the book.
- All right, all right.
We'll get back to the Motorcycle Diaries.
First, so you are a Chaos
Engineering "Expert,"
and the author of the chapter
"Open Minds, Open
Science, and Open Chaos,"
in the Chaos Engineering
book from O'Reilly.
Congratulations on being
published yet again.
Now in the book, you stress the importance
of openness and collaboration.
To avoid chaos engineering
teams being perceived
as just an outsider that
wrecks havoc in the system.
Can you give the audience
at home a teaser,
and expand on why that's important?
- So I can certainly say why
I think it's important to me.
And that stems from when
I actually first read
one of your first books which was around
chaos engineering as well,
the Chaos Engineering Report for O'Reilly.
One of the striking things
that was put to me in that book
and reminded me in that book, really,
is the scientific nature
of what we're doing.
We don't do chaos engineering
because the actual
engineering of chaos or
turbulent conditions is fun,
although it can be,
but you have to be pretty sick
I think to find it fun.
We do these things because
we learn from them.
And I love actually
Nora's quote from the book
that we just put out around
"we're hunting surprises."
And for me that's what we were doing.
We were hunting surprises
through a controlled scientific process.
And because of my background,
which has been in science
in a couple of different domains,
I've always been sensitive
to the locking away of,
not just the results,
not just the outcomes,
but also the whole process
of what's been explored.
- I really appreciate that,
I really love that emphasis
on the scientific aspect in the learning.
But it's not all dry,
it can be fun too.
Can you tell me more about
this notion of a game day?
And, you know,
your Chaos Toolkit, can it
be used to run game days?
- Yes it can.
Actually there's a couple
of new features around it
that are specifically tuned to game days.
What would perhaps be a longer running
chaos experiment, so as
your probably familiar,
a game day, I'm sure your familiar Casey,
whether everyone else is.
A game day... I tend
to give you an analogy
to understand a game day if
you've not done one yourself.
It's essentially a really beautiful
Dungeons & Dragons game you can play
with everybody in your team.
Where you set up a situation where
your going to be able to see
in real time how people
anticipate, react, respond,
synchronize, collaborate,
in an intense moment where
they may or may not be
aware of what's going on
in terms of a problem or not.
And there's usually
someone who very kindly
is called the game day facilitator,
sometimes he's called the
sadistic person in the room.
And they set up these conditions,
put this situation together,
we called them a games
master back in the 80s,
dungeon master, whatever you want to say.
They're there doing that,
and their job is to make sure
that whatever conditions
play out, there's a suitable
record that can be used for
further incident analysis
really, after this planned
incident to be learned from.
The way the Chaos Toolkit,
and reliability Toolkit
can fit into that is the
Chaos Toolkit can help
you automate the conditions
so that you could
repeat the scenario, repeat the experiment
if you wanted to.
You can also have then
the basis for executing
that experiment over and over
again as part of a continuous
verification style scenario,
that's also possible.
But of course what you also want to do
is record the all important
data around what was happening
during this incredibly complex moment
that is a game day.
Because if you can
capture what was happening
as well as you possibly can,
then you have an
opportunity to introspect it
amongst yourself and your team afterwards.
So for me, game days, you're right,
it's not just where the most
powerful learning happens.
- That's a fascinating
point and an underutilized
mechanism of game days,
exercising the methods
that people have for
incident response management,
and alerting, and all that we have
around improving availability.
It reminds me of when I used
to live here in England,
I used to live up in North Umbria.
And one day the king came to town
and basically gave us
a charter for the town
to found Ripon.
And part of that charter
mandates that every night
the watch is set
by a horn blower,
this is their alerting
system, so to speak,
for the town.
So the horn blower blows
the horn at the four
corners of the obelisk
there in the town center,
and blows the horn again
in the mayor's face
it's a thankless job,
being the mayor of Ripon.
And that sets the watch, you know,
watching out for the invasion
of vikings of course,
that sets the watch which
establishes a common context
for everybody in the town
and really helps them
understand their safety margin.
Very, very powerful thing,
acting out the pieces of
your incident response
management practice.
Is that a guitar over there?
- The best, absolutely the
best software developers
that I've ever met are musicians.
Now Casey, are you a musician?
- No, I'm not.
And Russ, it was a rhetorical question,
we want this broadcast to be entertaining,
so if you don't mind keeping-
- I'll put it back.
- [Casey] If you don't mind
keeping outbursts like that
to a minimum, James lets
edit out in post okay.
- I thought this was gonna be good.
I wanted to hear the song, but...
- Yeah, let's get back to the-
- [Russ] Subject at hand.
- So Russ, in the Motorcycle
Diaries you quote Dekker
as saying that, "It's the
individual and human error that
let's the system down every time."
Can you expand on that?
Why is human error always at fault?
- Oh, that's an inflammatory phrase.
Human error is given the
fault cause it's an easy
get out of jail card.
- Oh wait, yeah, your
right, I read that wrong.
I'm sorry, it's the system
that always lets the individual down.
- Yes, yes.
- [Casey] I got that backwards.
James let's fix that in post as well.
- Yeah, we'll fix that, we'll fix that.
- So sorry for the post
processing individual.
Yeah, so the point is
that it's human error,
and I got told this back at university.
I did two degrees, one at
Oxford, and when I was at Oxford
they taught me this very specifically on a
module on safety and risk.
And they said that in most
cases, if not in all cases,
human error is the label
used to stop people asking
any more questions.
You know-
- And now a word from our sponsors.
We've got a good one this week.
- Pattisons Whiskey,
Victorious All Along the Line.
The booming of the cannon
is nothing to the booming
of Pattisons Whiskey.
Steady, unfaltering attention to the
object aimed, hits the
mark and wins the battle.
Pattisons have aimed at
hitting the public taste for
a pure, sound, fully
matured, delicately flavored
whiskey and they have succeeded.
Pattisons Whiskey is the Scotch
spirit in its perfection:
wholesome, stimulating and cream like.
Pattisons Whiskey has
fought its way to the front
and will remain there.
- Well that's something.
You know we never got
Pattisons in the colonies,
I guess that's the cost of freedom.
Okay, Russ, what were you saying?
- So we were talking
about how it's the system
that lets the individual down rather than
the individual being the one to blame.
And yeah, the thing I was
taught back at Oxford was
if you want to stop ever questioning,
you just leave the
question at human error.
You say "Someone made-"
- Speaking of questions,
we now move onto our lightning round.
So these are really quick
questions for quick answers.
Russ continuous
verification, right or wrong?
- Right.
Do you want it that quick?
- Right, we actually only have
the one question so that's
the lightning round.
(Russ laughing)
Some people thought we
shouldn't have you on the show
because you wrote some
chaos engineering books,
we wrote some chaos engineering books,
you run a startup company
for chaos engineering,
nominally topically, anyway,
we run a company that
dabbles in chaos engineering.
Did we make a mistake
bringing you on the show?
- Absolutely, I'm here for one
reason and one reason only.
To derail everything.
More than that, reliability engineering
and resilience engineering,
continuous verification
as a principled approach to it,
all of it, is fabulous.
I think it's absolutely
ridiculous and I find it
the most distasteful thing
when a whole industry sector
that is so ready and needed and necessary
is ever going to be
dominated by one personality,
character, or company,
it's not gonna happen.
I'm sorry Casey, it's not gonna happen.
The more voices the better.
- Don't know why you're
emphasizing me there, but...
(Russ laughing)
- No, in all truth it does go back-
- It is a community
effort, it is a community
and it's a fantastic community too.
- [Russ] It is.
- So as I mentioned,
you've written some books.
Head First Software
Development with Dan Pilone.
Learning UML 2.0 with Kim
Hamilton, that sounds fascinating.
The AspectJ Cookbook.
And, more recently,
Learning Chaos Engineering.
- Yes.
- So that's quite a list
there, that's fantastic.
So I wasn't thrilled with the
cover of the chaos engineering
book, but then I looked at
the covers of your books Russ,
and I gotta say, yours are way worse.
In fact we did a poll
internally and we found
that you have four of the all time
worst O'Reilly book covers.
- The very first one.
- [Casey] How does that feel?
Is it soul crushing?
- No, the very first one,
no I take it as a personal vendetta.
I'm always excited about those things.
The very first cover, the AspectJ Cookbook
is still the one I quote as
being the all-time worst.
And I will take that to the grave,
I don't think you can get worse
as an animal book than that.
- So you also self-published
your Motorcycle Diaries
which is about a chaos engineering tour
of the colonies, here.
You obviously didn't have a
map because you managed to
log in over 5,000 miles on a trip
to San Francisco to Chicago.
So it must have been
a very primitive trip.
How did that come about?
- Ah, that came about because
there was far too much whiskey
and far too much enthusiasm from a bunch
of core conference organizers
who I love very dearly.
We managed to go to the
after conference party,
someone, I can't remember who,
asked "What can we do to make
the conference more
interesting next year?"
And I decided this was
a great opportunity to
tick a bucket list item off
and go, "Why don't you get
someone to ride route
66 to the conference?
That would be great.
And they could blog it the
whole way and everything else."
Unfortunately, what I
hadn't looked into was
along route 66 there are very few
reasons to stop for a
software style event.
And so it went from being
a route 66 escapade,
to, "Well, why don't we go vere Atlanta."
Which meant a significant
detour across the country
and actually was some of the
most fabulous part of it.
I almost died three
times, you don't get much
more chaos engineering than that.
I had some of the best nights of my life,
some of which I can remember,
and it was just an incredible experience.
It was like a musical
journey up the coast,
it was fabulous.
- Um, which state is the worst?
(Russ laughing)
- The worst state?
They're all that bad.
No, no, that's a joke.
They're all fabulous, oh the worst?
That's hard.
The worst, I'll tell you what, no.
It's not the worst state
for any other reason,
than everyone told me
a lie about this state
that I'm going to mention.
They told me that it was boring,
flat, and you know, the hardest
thing would be to stay awake
for the 11 hour ride across it.
And this is across Kansas essentially
towards Oklahoma city.
And what they didn't
mention is that obviously
with a really flat landscape
you get huge amounts of crosswinds
and also all the roads
are two lane wonders,
like I have here at home.
And so I spent 11 hours trying not to die
from crosswinds suddenly taking
me, the bike, and everything
I'm attached to, fleeing
into the opposite lane
in front of other vehicles.
So it was utter boredom for
about half an hour or so,
give or take, followed
by a good five minutes
of utter terror.
- Boy you were right James,
alienated a good chunk
of our audience there.
I thought Londoners had a
reputation for being polite, but.
So now I believe we have some
questions from the audience.
James, can we open up the lines?
- Yeah, we have a
question from the audience
that we were able to record
in your own native language,
so for our American audience we're gonna
get this captioned out for you in post.
All right, let me play it.
- Hi Russ, big fan of yours.
I have all two of your books.
So are you a hammer, a
lily white, a Gunnar,
a blue,
or an eagle?
- Oh that's a very
British sounding question,
that sounds very British.
- If I get that right, I
believe I'm a pensioner
in that taxonomy.
If I'm getting right it
sounds to me like slang names
for football team supporters.
So I would put myself
in the unfortunate class
of being a supporter of the
pensioners, which is Chelsea.
- That sounds awfully
British, I'm full of awe.
Do we have any more questions, James?
- I've got a question for
Russ today on Chaos Toolkit
and it's experiment format.
I've got a scenario where
I would like to be able to
adapt the experiment as I run it.
Today the experiment is
fairly static in a sense
where you declare what you want to run
and Chaos Toolkit will run from
picking two ends ordinarily.
But what if my system is doing something
and my experiment should adapt dynamically
and on the fly to it?
Like maybe withdraw an
action that was planned
to be running later on but
because of some conditions
I don't want to run it anymore.
So I was wondering, Russ,
if you knew of a system
to mechanic,
to impact, to change
the experiment on the fly as it runs?
And also what's your take on that?
About the adaptive
aspect of the experiment.
I think that making it too complex
to understand the readings after that,
I'd be really interested in hearing
what you have to think about
how far chaos engineering
experiments should go
before they become themselves
too hard to understand.
But if it's a good idea, do you have
any tip on how we could achieve that?
Because I think it would be very valuable
to what we are doing.
Well thank you, thank you
very much for any insight
you could have on Chaos Toolkit
itself because I know that you
probably have a better
view of Chaos Toolkit
than I have so thank you for that.
(Russ laughing)
- Giving that I've spent most of the day
chatting to that face,
(Russ laughing)
- All right, all right,
well I want to thank you again,
Russ Kilometers for joining us here
and for inviting me into your home.
And offering me this
native drink you call tea.
It's very interesting.
- Always good to see you both.
You're always welcome
in my house, now leave.
(powering down sound)
