GitHubが築いたオンコール文化

GitHubはRuby on Railsで構成された大規模なモノリスシステムだった。

モノリスのオンコール体制で最も難しかった点

• 大きく多くの製品や機能が含まれていたため、ほとんどのエンジニアはコードベースを十分に理解しておらず、オンコール時に障害へ対応できると自信を持てなかった。呼び出しを受けると他チームへエスカレーションすることになり、エンジニアというより交換手のように感じられた。

• オンコールの間隔が長く、1回のオンコールは24時間だった。エンジニアは年に4回以下しかオンコールを担当せず、担当中に十分なコンテキストを得られなかった。

• モニタリングとアラートシステムが複数のチームに分散しており、しかもオンコールを経験するのは24時間だけなので、オンコール用の監視やドキュメントは十分にメンテナンスされていなかった。

• ほとんどのエンジニアがモノリスのオンコールに自信を持てなかったため、システム全体をよく知る5〜10人があらゆる本番障害に参加することになり、オンコール責任の偏りが生じた。

新しいオンコール文化

業務組織上の障害

• ファイルのオーナーシップを明確にするためサービスカタログを作成し、ファイルをサービスにマッピングし、さらにサービスをチームにマッピングした。

• モニタリングと通知がモノリス全体に対して設定されていたため、各チームが自分たちの責任範囲の監視を作るようにした。

• この作業を行うチームが多かったため、チームごとにGitHubへIssueを作成し、チェックリストを提供した。

文化的・教育的な障害

• パンデミックが人々に悪影響を与えていたため、当初考えていた以上に共感を優先するアプローチが必要だった。

• ほとんどのエンジニアにはオンコール経験も運用経験もあまりなかったため、教育プログラムを作って提供した。オンコールの専門家との勤務時間を設定し、十分なツールとドキュメントを整備し、助けを求められるSlackチャンネルも作った。

• 多くのエンジニアは、オンコールが生活にどれほど影響するのかを心配していた。経験が少ないと、オンコール中に日常生活の時間を調整するのは難しいことがある。このため、オンコールの専門家によるコツやテクニックをまとめ、呼び出しを逃した場合に別の人がバックアップできるようにするなどの対策を取った。これは不慣れさの問題なので、訓練よりもオンコールを何度も経験し、時間が経つことで安心できるようになるだろう。

• オンコールにうまく対応できないのではないかという不安が大きかったため、失敗しても大丈夫であり、どれだけうまくやっても障害は起こり得るという安心感を持てるようにしている。

• 製品ごとに重大度レベルが異なるため、あるチームは5分以内に応答しなければならない一方で、別のチームは翌日に対応すればよい。これを不公平だと言う人もいるが、単にエンジニアごとに関心領域が異なるだけだ。

• 変更を適用しながら、各チームがオンコール体験を改善するために多くの時間を割くことはできない。オンコールがうまく機能していないときこそ、オンコールプロセスを改善すべきだ。チームには、約20%を技術的負債の返済に使い、約20%をオンコール体験の改善に使うべきだと伝えており、リーダーシップの長期的な視点が必要になる。

[galadbran]

オンコールというものがだいたいどういうものなのか分かりません……サポート要請のことなのでしょうか。韓国のような電話応対ではなさそうですが……

[andrewchaa]

私の会社では、通常2か月に1週間ほど、業務時間外にシステム障害へリアルタイムで対応することを on-call と呼んでいます。PagerDuty というアプリをよく使いますが、severity が high の障害が発生すると、- dead letter が発生するとか、api failure rate が一定以上を超えるとか… - 携帯電話に即座にアラームが届き、会社のラップトップに接続してログを確認しながら必要な対応を行います。

[sukso96100]

オンコール対応のことだと考えればよさそうです。

[bach80]

当番や週番のような感じですね。障害対応を持ち回りで行う、という……