Cybozu における次世代障害対応研修の計画と実践 - Cybozu Inside Out

こんにちは！SREチーム兼Manekiチームのhsnとaoi1です。今回サイボウズでの障害対応研修の紹介をします。

背景

cybozu.comでは現在2つの運用基盤が存在しています。 Forest と呼ばれている旧インフラ基盤と、2019年に運用を開始した Kubernetes をベースにした Neco と呼ばれている新基盤です。 Forest 基盤で動いているサービスを Neco 基盤に移すと同時に、サービスの運用体制を見直す機会に直面しています。これを担当しているのが我々Manekiチームです。

Forest 基盤の仕組み上、ほとんどの障害対応は Forest 基盤を運用する SRE チームにしかできなかったため、製品開発チーム（以下：開発チーム）と運用チームが完全に分れていました。しかしこのチーム体制はコミュニケーションに時間がかかる、製品開発チームが自分たちの開発物をコントロールできないなど多くの問題がありました。

Neco ( Kubernetes ) 基盤にサービスを移行することで、様々な権限を細かく設定する事ができます。これにより、各チームが管理する開発物も隔離する事が出来るようになりますし、開発物をより深く理解している製品開発チームのメンバーも製品の動作環境の運用に参加する事ができます。

サイボウズでは、 SRE チームが運用の全てを担う時代から開発者が製品の開発と運用両方に責任を持つ時代になりつつあります。そのためこれまでの運用経験・知見がある SRE チームは開発チームの自立支援を行う必要が出てきました。

自立支援策は色々ありますが、中でも障害対応は即時性も求められ難しい一方、書籍やドキュメントの学習でカバーし切れるものではないと考えました。そこで、自立支援策として、私たちは障害対応ロールプレイを実施することに決めました。

ということで、今回実践した Kubernetes 障害対応ロールプレイについて説明する前に、これまでサイボウズで行ってきた障害対応ロールプレイの歴史を振り返りたいと思います！

Forest 基盤での障害対応ロールプレイ v1

日々の努力のお陰で近年、 Forest 基盤が着実に安定し、障害の発生頻度も減りました。一方で、安定した基盤では新メンバーにとって障害対応を経験する機会も同時に減ることとなります。

新メンバーの経験のために実際の障害対応時に「全部任せた！！」と無茶振りすることもできますが、新メンバーは成長する反面、お客様影響が出る時間が延びてしまう可能性があります。それじゃ身も蓋もないですよね。そのためお客様に影響を出さない範囲で障害対応の研修を行う必要がありました。

また障害対応研修に利用する環境として、 Forest 基盤の開発環境の利用も検討しましたが、その環境は各チームが共通して使うため、研修時に意図的に壊してしまうと他のチームに迷惑がかかってしまいます。また、開発環境のセットアップが複雑なため、破壊した後の修復であったり、研修のためのセットアップも難しい状況でした。

障害対応ロールプレイv1を2匹のクマが行っている図 — 障害対応ロールプレイ v1 の実施方法

そこで2019年の新卒研修で試作としてボードゲーム風に障害対応ロールプレイを以下の形で実施しました：

ゲーム内容：新卒社員にSREの役割をになってもらい、持ち時間60分で障害対応を行う
あらゆるアクション（調査・操作コマンド）を擬似的に行い、障害対応を進める
ゲームマスター役の SRE が事前に障害の概要、各種コマンドの結果やメトリックスのグラフを表として用意し、それらを元に障害のシチュエーションや疑似障害対応を進行する
数人のチームで会話しながら障害の原因となるものを探して解決策まで提示して貰うというゲーム
環境を操作するアクションにはそれぞれのアクションごとに時間が消費される
- 例：「特定のプログラムの再起動：-1分」「お客様に行動を依頼する：-25分」

ボードゲーム障害対応ロールプレイの課題

当時の障害対応ロールプレイは新卒研修の共通研修という枠で行われていました。

共通研修では各部署の業務紹介を目的として、エンジニアリングのバックグラウンドの有無を問わず社内全体の新入社員が受ける事になっていました。

そのため、 Forest 基盤の様々なコンポーネントを抽象化する必要があり、結果的に内容を薄める必要もありました。また、ボードゲームで再現できる物も限られていたため、このままだと SRE チームメンバーの訓練はおろか、新メンバーの研修にもならないという課題がありました。

そのほか、ボードゲームという物理的な道具を使ったロールプレイであったため、物理出社でも在宅勤務にも対応する研修の仕方を考える必要もありました。

そしてボードゲームでの障害対応ロールプレイのもう1つの課題は、どうしてもゲームマスターという役割を持った人間による進行が必要だということでした。ゲームマスターだけが障害の詳細や対応策を知り、障害の復旧を宣言するというフェーズをゲームマスターに持たせる必要がありました。

理想としては「何かしらないが壊れた」のように、正解を知る人がいないとしても、障害が発生し、それを復旧するという現実に近い状態でロールプレイを行うことでした。

Kubernetes を活用した疑似環境での障害対応ロールプレイ v2

経緯

いくつかの開発チームで Neco 基盤の利用をはじめており、一部開発チームで運用できる体制が整ってきました。私たち Maneki チームがサポートに入りながらいくつかのサービスの本番稼働を開始しているのですが、開発チームに運用を全面的に移譲するにあたり、開発チームメンバーからは運用に関して不安があるという声があがっていました。

これまでの Forest 基盤に触ったことがあったとしても、Linux サーバーに管理者権限でログインして障害調査を行うことと、 Neco ( Kubernetes ) ユーザーとして障害調査を行うことではできることや必要な知識が違うので不安に思うのも当然です。（Neco 基盤では Neco チーム以外はクラスタアドミンの権限はなく、 Node にログインすることもできません）

また、Kubernetes はその性質上障害が発生しにくいと考えられるため、何もせず待っているだけで場数で経験を積むという期待もあまりできません。

単純に知識を獲得するだけであれば座学による講義であったり、ドキュメントを参照すれば十分です。しかし CKA や CKAD の試験にもあるように、実際に手を動かして調査をすることは大事な経験となります。

とはいえ全員に CKA や CKAD の試験勉強をしてもらうには時間とお金がかかりすぎるので、私たちはこれまでの歴史を踏まえ、 Kubernetes 障害対応ロールプレイを研修メニューとして用意しました。（会社としてはCKA/CKAD試験受験費用の補助はありますよ！）

実現方法

開発チームメンバーが今後直面するであろう障害の種類や、それぞれのメンバーの運用スキルレベルを考慮し、 Forest 基盤上ではなく、Kubernetes において障害対応調査を疑似体験できることをロールプレイの目的としました。

そしてNeco 基盤相当の環境を用意することは難しいため、ロールプレイでは Kubernetes の仮想環境を利用することにしました。 kind等のツールを使えば手元のパソコン等でも簡単に Kubernetes の仮想環境を立ち上げる事ができます。

この仕組みを活用してボードゲーム時の障害対応ロールプレイの様々な課題を解決して、より質の良いロールプレイ研修を実施する事ができました。

Kubernetes障害対応ロールプレイを3匹のクマが行っている図 — Kubernetes 障害対応ロールプレイのやり方

製品開発チーム向けに研修を実施した時に以下の形で進行しました：

まず共通で操作できる環境を予め用意する
研修参加者全員がオンラインビデオ会議に参加して各々のパソコンから研修環境に接続してもらう
ゲームマスターは進行のファシリテーターになり、開発チームメンバーの中から障害対応をメインに担当するメンバーを募集する
メイン担当者は自分の画面を共有して障害対応の代表としてコマンドを打つ
- ただし、本番環境同様、メインの担当者が対応中でも他のメンバーが環境を操作する事ができるため、役割分担して調査する事もできる
ルール上、操作系コマンド（環境に変更をもたらす様なコマンド）は2人以上で打たなければならないので画面共有のセッションで行ってもらう
後はボードゲーム版の時と同じ様に、会話しながら自分の仮説や疑問を述べて、調査して、障害を復旧させる事でゲームクリア

障害は実際に起こった障害も含めて7つの障害を用意し、時間が許す限り障害調査のケースをこなしてもらいました。

v1の課題解決

ボードゲーム障害対応ロールプレイ実施時の課題は、それぞれ以下のように解決することができました。

実際に障害対応を行うチーム単位での研修参加

実施するに至った経緯もあって、今回は障害対応を行うチーム単位で研修に参加してもらいました。

チーム内メンバー間のスキル差はあったものの、ある程度のスキルセットが揃ったメンバー間での研修だったため新人研修の時のような抽象化は必要ありませんでした。
全員がリモート状態で参加可能

コロナ禍ということもあり、今回は全員がリモート状態で参加できることが必須でした。そのため環境も開発チームのメンバーであれば誰でもアクセスできる環境を用意しました。
実際に動く環境でのロールプレイ

今回全参加者が ssh でログインできる環境に Kubernetes クラスタを作成しました。実際に動いている Kubernetes クラスタに障害を起こすことで、調査するためのコマンドを実行することができ、本番で必要な調査の体験を行うことができます。また、動作確認や障害復旧も自分たちで確認する事もできます。

よって環境さえあれば、ゲームマスターが居なくても各自で練習する事も可能です。研修当日、ゲームマスターの役割は障害対応担当者たちの会話を引き出すファシリテーターとなっていました。

他チームへの展開

Kubernetes で作られた環境なので、環境の定義のための YAML ファイルさえあれば誰でも立ち上げる事ができます。 kind等を使って仮想環境も簡単に構築し破棄する事もできます。このように他のチームにも負担をかけることなく展開する事ができる様になり、環境の定義ファイルも全部GitHubに保管しているため、研修後にも簡単に予習できます。

以下に実際利用した障害対応環境を作成できるリポジトリと、その内容について説明します。

https://github.com/cybozu/maneki-troubleshooting

ロールプレイ用のGitHubリポジトリには環境や障害の種類を柔軟に定義できるためにシナリオ毎の定義を置けるようにしています。

clusters/
dockerfiles/
manifests/
scripts/
stories/

ディレクトリ名	説明
`clusters`	`kind`クラスタの定義ファイルがあり、将来的に異なったクラスタでの障害を作りたい場合も定義ファイルを追加するだけでできます。同じ環境で複数シナリオを同時に実行したい場合、`listenAddress`を分ける事で対応しています
`dockerfiles`	シナリオに合わせたイメージをビルドし`kind image load`を用いて障害シナリオ環境にのみ適用する事ができます
`manifests`	各障害シナリオの環境を構築するためのYAMLマニフェストを置く場所
`scripts`	環境構築の前後等に実行したい追加スクリプトを置く場所
`stories`	人間に読まれるためのシナリオの簡易な説明を置く場所