Incident is a Candy

Site Reliability Engineer (SRE) として働いていると、毎日のように障害対応をすることになる。日によって忙しさは異なるのだが、障害対応のローテーションに入っているときは、一週間基本的には障害対応に脳内エネルギーも体力も持っていかれる。障害が発生していないときも、再発防止策の実装をしたり、利害関係者に必要な報告をしたり、根本原因の究明をするためにダッシュボードと睨めっこしたりしている。

そんな障害対応の週には、自分は社内で利用しているチャットシステムである Slack のステータスを "🍭 Incident is a Candy" に変えることにしている。これは、とあるマインドセットを自分に言い聞かせるためであり、厳しい大規模な障害に呼ばれても冷静さを失わないためのおまじないようなものである。

さて、「障害対応はすなわち飴である」とは、どういうことか。

Site Reliability Engineering に必要なマインドセットの一つは、"Learn from failure" すなわち「失敗から学べ」にあると考えている。というのも、ソフトウェア開発の大前提として、障害の発生しない「完璧」なシステムを作り上げることは不可能である。そこに人間が関与する以上、必ずどこかで綻びが生まれる。マシンのハードウェアだって、予測不可能な天候や地震のような災害によって、データセンターが浸水したり電気が断絶したりする。システムがどのような形で失敗するか、その "Failure patterns" をいかに事前に導き出し、それに対して弾力性のあるシステムを設計するかが、Site Reliability Engineering の腕の見せ所である。

したがって、全ての障害は、システムに対して新たな気づきと発見をもたらしてくれる Feedback Loop のインプットであるべきで、「障害が全くない」状態というのは、それはそれで不安である。嵐の前の静けさ、とも言うべきか。断続的に地震が起きるからこそ、震災に備えた科学技術や庶民の防災に対するマインドセットが形成されるのと同様に、障害が起こるからこそ、そこから我々ソフトウェアエンジニアは学ぶことができるのである。

そう、障害はいわば喜ぶべきものであって、PagerDuty（障害が起きた時に担当者に電話で通知をするシステム）からの騒がしいアラートも、アドレナリンを分泌するものでこそあれ、不安を煽るようなものであってはならないのでないか。障害が発生した時に、飴を差し出された子どものような好奇心に満ち溢れたマインドセットは形成できるのではないだろうか。「今回はどんな新しい学びがあるだろうか」「今度は誰が秘孔を突いたんだろうか」そんなワクワクした気持ちで障害に向かっていくことができるのではないか。

そんな気持ちから、"Incident is a Candy" は生まれた。確か最初は、チームの誰かがちらっと言った言葉だったろうか。とても気に入ったので、勝手に真似して言い続けている。

さて。問題は、飴も楽しく食べられる許容量が決まっているということである。美味しいからと言って、一日に百本も飴をもらっても、消化しきれないし、体をかえって壊してしまう。飴をおやつの時間に美味しく食べるためには、おやつの量を決めなくてはならない。

障害の量は決して個人プレーで決められるものではない。毎日同じようなイチゴ味の飴をもらっていたら、流石に飽きてしまう。それと同じように、例えば同じような原因の障害は可能な限り再発を防止させたい。誰も深夜に DDoS による気まぐれな障害通知で叩き起こされたくはない。"Incident is a Candy" の限界は、そこである。あくまで個人のマインドセットに寄与するだけであって、本当の仕事は飴を食べ終わった後に始まる。

とはいえ、多忙なプロジェクトもこなしながら、増え続ける障害通知にストレスを管理可能なレベルでコントロールするためには、時にはこのような「自己暗示」も必要である。今週は障害対応の週だったのだが、非常に飴の多い一週間であった。さて、今の私に消化し切れるだろうか。