健全なオンコール文化をつくる

 (developers.soundcloud.com)
25 ポイント 投稿者 xguru 2021-06-07 | 1件のコメント | WhatsAppで共有
  • 業務時間外に問題が発生した際、呼び出し（Paging）を受けて対応するエンジニアを指定する「オンコール」についてのSoundCloudのヒント

  1. オンコール業務は任意（Optional、希望者のみ）

  2. 正規の勤務時間外の業務であるため、時間給の手当が支給され、ページングに応答した場合は時間当たりで追加支給

  3. オンコールエンジニアはいくつかのローテーションで構成される

  4. 各ローテーションは

→ 1つまたは複数のチームを代表するエンジニアのグループで構成

→ ローテーション内のすべてのチームの問題に対して一次対応を担う1人のエンジニアが常に待機

→ そのほかのエンジニアは、自分のチームのサービスに関する問題を担当する二次対応を提供するため待機

→ 二次対応はベストエフォート（best-efforts）ベース：いつでもページングを受けて、可能なら最善を尽くして対応するが、自分が対応できないときは必ずしも応答する必要はない

なぜオンコール業務はエンジニアにとって良いのか？

  • DevOpsやSRE（Site Reliability Engineers）以外の多様なエンジニアをオンコール業務に入れることは、会社にとっても本人にとっても良い

  • 常に時間外勤務が多い運用チームのエンジニアの負担を軽減できる

  • エンジニアが安定していて、十分に文書化されたシステムを構築する動機づけになる

→ 問題発生時に自分で目にすることで、システムをどう改善し堅牢にするかのインサイトが得られる

  • 自分たちのシステムと他人のシステムの両方を支援することは、エンジニアにとって学びの良い機会になる

手続き面のベストプラクティス：すべての組織は異なるが、SoundCloudが見つけた最適なプロセス

  • 各ローテーションで交代周期は異なるが、多くは1日から2日単位で交代

  • 1か月に3日程度オンコールに入るのが最適。それより多いとバーンアウトし、少ないと効率的でない。

→ つまりローテーションの最適人数は8〜12人。10人なら理想的。

  • ローテーション内で公式または非公式の管理者を選び、交代勤務のスケジュール管理や人員変更などローテーションを管理

→ 例）連休期間の交代日程の調整

ローテーションチームと組織

  • SoundCloudの組織は時間とともに発展し、統合・分割・新チームの作成・チームの部門間移動などが起きてきた

  • しかしオンコールのローテーションチームは、エンジニアリング組織と同じ速度では発展しなかった

  • 現在では、多くのローテーションがまったく関連のないチームの寄せ集めのように見えることもある

  • それでも問題にはなっておらず、これを変更しようとする試みに対してエンジニアが異議を唱えたため中止された

文化面のベストプラクティス：オンコールエンジニアと会社全体の利益のため、次のような規範と姿勢を育てる

  • オンコールの人たちはオンコールであることを望んでいる。自発的に責任を負い（報酬も受ける）エンジニアのほうが、インシデント対応時により高い動機を持てる

  • 交代周期のような問題は、各ローテーションのエンジニアが話し合って決める。会社は交代パターン、交代時刻、個人間の引き継ぎなどについて標準手順を提供しない

  • オンコールエンジニアは、こうした問題が通常勤務時間内に悪化したり、他の人を勤務時間外にページングしなくて済むように調査に時間を使うことが多い

  • インシデント対応時、エンジニアはほかのエンジニアを呼んで助けを求めることができる。夜中に二次対応の呼び出しを受けるのを好む人はいないが、可能であれば応答して助けることで、将来同じ状況を一人で処理できるよう教えられるようになる

  • 合理的な時間が経過した後は、自由にほかの人へ作業を引き継いでよい。重大または長期化するインシデントでは、エンジニアが疲れて効率的に作業できなくなるため、4時間後、あるいはそれより前でも他者に引き継ぐのがよい

  • 最も重要なのは、「非難の文化ではなく学習の文化を育てること」。いくら強調してもしすぎることはない

→ ミスはインシデント対応において避けられない要素であり、ミスから学ぶことで、より強く技術的に成熟したエンジニアリング組織が築かれる

→ ミスによって人を罰すると、エンジニアは新しい状況で行動することを恐れ、助けを求めることを恐れ、透明性を恐れるようになる

→ 結果として、非難の文化の中ではオンコールローテーションをやめるか、会社を去ることになる

大きなインシデントが起きたとき

  • サイト全体の停止や深刻なインシデントへの対応は、誰にとってもストレスになる

  • これは同時に、その会社のオンコール文化に対するストレステストでもある

  • エンジニアが協力して働き、互いに信頼することが何より重要

  • わからないことを認め、他人に助けを求め、ミスをしたことを正直に話し、疲れすぎてこれ以上続けるのが難しいと言えるようになれば、問題をより早く解決できる

  • こうした行動を育てるのは、大きなインシデントが発生する前でなければならない。エンジニアは小さなインシデントに対応し、同僚と協力する中で経験を通じて学ぶ。

→ 小さなインシデントは大きなインシデントへの訓練である

関連記事

1件のコメント

 
xguru 2021-06-07

スタートアップは人手が少ないので、常にオンコールしなければならないような感覚はありますが..

組織が少し大きくなり始めると、一部の人員だけがずっとオンコールを担当するようになり、夜や週末にも問題を解決しながら燃え尽きてしまうのを目にすることがあります。

基本的には文化づくりをしっかりやるべきだと思います（肝心の自分もあまりうまくできていなかった気がして反省中です..）