Gameshow: LARPing Incident Response Training

At StarkWare, we faced a problem: our backend was complex: API servers, a blockchain node, databases, microservices, the works. However, it was new (this was 2019, the entire company was new), and few of us knew it well, and most of us had little to no experience in incident response whatsoever. We could have put everyone through an on-call rotation and waited for bad things to happen in production. But a trial-by-fire puts production at unnecessary risk and stresses people out. We felt there was another way.

So, we thought of "Gameshow.".

It’s similar in spirit to Google SRE’s “The Wheel of Misfortune,” but with a crucial difference: Google’s version is a tabletop exercise - essentially Dungeons & Dragons. Gameshow is a Live Action Role-Playing (LARP) situation. It’s entirely hands-on.

The Setup

We spun up three fully-fledged, non-production copies of our live backend on Kubernetes. No mocks. A real blockchain node, a real database, the whole shebang. We then pumped synthetic, production-like traffic into them.

Then, an experienced engineer (Shahar Papini, in this case) intentionally sabotaged these systems. He drew on actual past malfunctions, like misconfiguring a database endpoint, to wreak havoc. Three broken systems gave us about an hour of gameplay.

The Gameplay

We gathered the team in a room. One by one, engineers were called to the "stage," connecting their laptops to the main screen.

We handed them a broken system and a vague prompt: "A user complained their transactions are failing" or "X alert just fired."

The player on stage was the driver, but the entire room was involved in helping debug. Once the system was declared fixed, the moderator either confirmed it or provided more fake user feedback that it was still broken.

Key points

• Scientific Mindset: Form a hypothesis, verify or disprove it, and reason out loud. Just restarting a service may fix the problem at times, but sometimes this is a temporary fix, covering up the actual issue.

• Team Effort: The room sounds out opinions. This limits the stress on the "driver" while giving them hands-on keyboard time.

• Poker Face: The moderator gives nothing away. The system itself must be the only source of feedback (with the exception of the initial fake user complaint).

I recently adapted this methodology on a smaller scale at doubleAI to onboard a new engineer. It felt to me just as effective for 1-on-1 instruction as it did for a whole team.

Tabletop exercises are fine, and sometimes the ROI of replicating a large system for the sake of training does not justify the effort. In a small startup you play to your strengths: being small and agile, you can usually spin up a sandbox and get everyone hands-on experience, LARPing your way forward.

פרות, חיות בר, והשיטה המדעית

מתכנת אחד תיאר לי לפני שנים דיבאגינג כתהליך של חקירה מדעית: מעלים השערה ועושים ניסוי כדי להוכיח או להפריך, וכל צעד מקרב אותנו יותר לאמת. זה תיאור כל כך שימושי, שהופתעתי שהוא לא עלה בקורסי התוכנה במהלך התואר במדעי המחשב. איכשהו, למרות שהמילה ״מדעי״ נמצאת בשם של התואר, וטכנית היינו חלק מהפקולטה למתמטיקה ולמדעי הטבע, הסתכלנו על המדעים האמפיריים ממרחק בטוח בתחושה שנעה בין בוז לפחד.

-

ב 2011, רנדי באייס הציע את האנלוגיה של חיות מחמד לעומת עדר בקר כדי לחדד את ההבדלים בין שרתים מסורתיים וארכיטקטורת ענן. הוא ניסח את זה בערך ככה (התרגום שלי):
״…למשל בוב שרת הדואר. אם בוב נופל, מזעיקים את כולם. המנכ״ל לא יכול לקבל את האימיילים שלו וזה סוף העולם. בדרך החדשה, שרתים ממוספרים כמו עדר בקר. למשל www001 עד www100. אם אחד מהשרתים נופל, לוקחים אותו הצידה, יורים בו, ואחד אחר לוקח את מקומו.״
הסגנון והאנלוגיה לא התיישנו טוב, אבל לתקופתה, האנלוגיה הזו הסבירה יפה מעבר מהנדסה שמגינה על פרטים לארכיטקטורה שמנהלת אוכלוסיות.

ככל שיותר ויותר קוד נכתב על ידי AI ומתוכנן על ידי AI, ומערב אייג׳נטים ומערכות אוטונומיות, אנחנו צריכים לעדכן את האנלוגיה של באייס. השרתים שלנו הם כבר לא עדר שאנחנו הרועים שלו שמתכננים ושולטים בכל המשאבים. אפילו האייג׳נטים שלנו הם לא כאלו, הם בסך הכל מפעילים עוד אייג׳נטים. העבודה שלנו הופכת להיות פחות הנדסה במובן המסורתי של תכנון מדוקדק והוצאה לפועל, ויותר צפיה ומדידה, בדיקת השערות, הגעה למסקנות, ואז פעולה לא ישירה. לא רק שאנחנו לא מגדלים חיות מחמד, אנחנו גם כבר לא רועים של עדר פרות. אנחנו פקחים בשמורת טבע עצומה, נניח הסרנגטי בטנזניה, והכלים שלנו מגיעים מהמדעים האמפיריים - השערות, מדידה, ניתוח, וחוזר חלילה.
צורת המחשבה הזו של צפיה בחיות בר אפילו מסתדרת עם טרנדים יחסית עדכניים, כמו למשל האופן שבו observability מחליף את ה monitoring. אנחנו לא יודעים מראש מה יהיו האירועים המעניינים או אפילו מה השאלות שנרצה לשאול, אז אנחנו צריכים לוגים, טרייסים ומטריקות שאפשר לתחקר פוסט הוק.

זו לא התיאוריה היפה שהבטיחו בלימודים, זו אפילו לא ההנדסה הפרגמטית שהתרגלנו אליה בתעשיה. זה משהו אחר, כאן בין חיות הבר, בטבע הפראי שצומח מסביבנו במהירות והקוד שנערם במהירות גבוהה ממה שבני אדם יכולים לקוות להדביק. ולנו נשאר לצפות, למדוד, לנתח, לשער, להקים פה גדר, שם לשים קצת אוכל. אתם יודעים. מדעי המחשב.

---

אחרי שהפוסט הזה עלה בטוויטר, אבישי איש-שלום העיר שהוא אמר דברים דומים כבר לפני עשור. ואמנם המטאפורה שונה, אבל הרעיונות מאד דומים והוא באמת היה שם קודם. חבל שלא הקשבתם לו:

New York City traffic and the future of software development

 It is a truth universally acknowledged that code expands to fill the available capacity to debug it. We’ll get back to software in a minute, but let’s talk about a man first.

Robert Moses was a uniquely powerful, smart, and corrupt figure in mid-20th-century New York City and New York State. He was an unbelievably prolific builder who channeled various public and private resources into the parkways, beaches, and bridges of the New York metropolitan area by every means possible. He had no problem lying, ruining people’s lives, and upending communities if it served his purposes. Under his leadership, the city gained many more roads that were wider and better. It had more bridges connecting various parts of the city. It had more parkways.

Robert Moses and his subordinates believed that all this would alleviate the traffic problems the city was already experiencing with the mass production of cars. To their surprise, as they built more roads, more cars seemed to pop up. This offset the change in capacity and left congestion unchanged. They initially believed this to be a good sign. It meant that many people were suddenly able to use the roads, and they assumed the eventual result would be a smoother flow of traffic.

They were wrong.

More roads, they learned slowly, meant more, not less, traffic. This was counterintuitive at the time, but it is well understood today that this is how traffic in heavily populated areas works. It becomes congested up to a point, and adding roads provides a very temporary solution to the problem, if that.

Academics caught wind of this phenomenon and felt the immediate need to name it. Around 1962, economist Anthony Downs formulated "Downs's Law of Peak-Hour Traffic Congestion." By the '90s, the general case became known as induced demand.

For some things, it seemed, increasing the underlying resource’s availability is never enough.

Fast forward to emerging software development patterns in light of advances in AI. We appear to be more efficient and more productive. We need fewer people to do the same job, and we do it faster than ever. We generate code. More and more code.

The more code we generate, the more bugs there are in the world. The more bugs we find, the more work these code-generating machines will have. To fix them, they will generate more code, and round and round it goes. Therefore, in this software engineer’s opinion, reports of our profession’s death have been greatly exaggerated. The industry overall will end up needing similar numbers of people. The increase in efficiency we currently feel will soon be squashed under masses of code piling ever higher and deeper. There will always be just one last bug to solve, for which the AI apologizes humbly. "It was indeed an oversight on my part," it will say. "I will fix it immediately. Is there anything else you’d like to talk about?"