ディレクターの渡邉雄介です。担当しているサービスのメンテナンスやトラブルがあったとき、初動が遅れたり、パニックになって判断能力が鈍ってしまったことはないでしょうか？
ディレクターブログでは、すでに何度か障害時の基本的な対応についての記事 (障害対応的ディレクションスキル・サーバ障害と向き合うには) が書かれていますが、今回はもう一歩踏み込んで、メンテナンスやトラブルの際にディレクターがしておいた方がいいTipsをいくつかご紹介します。
責任感の強い人は、まずはディレクターが問題をある程度取りまとめてからエンジニアや関係者に共有……と思いがちですが、たとえその時点で問題をよく把握できていなくても、障害が起きているということだけは最速で伝えるべきです。これは下記の2つの点から重要です。
ディレクター、エンジニアをはじめて開発メンバーが把握している (よく理解している) 領域はそれぞれ異なります。問題を切り分け、障害の原因をいち早く発見するには、自分ひとりでやろうとせず、関係者全員で取り組んだ方がいいと思います。
Tips2. トラブル時に使用するメンテナンス画面の雛形は
たとえまだ一度もトラブルが起きていなくても、実際にトラブルが起こってからメンテナンス画面を作り始めるのと、事前に雛形の用意されたメンテナンス画面に入れる内容を考えていくのとでは精神的負担が違います。
これは、ユーザーへの告知をテンプレート化して楽をしよう、ということではなく、事前に起こりうるトラブルの内容を想像し、ユーザーへの状況説明を事前にシミュレーションできることに価値があります。これによって実際のトラブルでの初動が早くなるだけでなく、冷静に対応できるようになるはずです。
担当エンジニアの連絡先を聞いておくことはもちろんですが、前任のディレクター・エンジニアなどの連絡先も聞いておいた方がいいです。とくに、引き継いでから日が浅いサービスの場合、前任者へのヒアリングが原因の早期発見につながることも多いです。
もちろん、前任者任せになってしまうのは本末転倒なので、現担当の自主的な行動が求められてしかるべきですが、障害対応用のMLやグループチャットなどを利用しているのであれば、引き継ぎ後の一定期間は念のため参加したままでいてくれるよう前任者にお願いしておくことをおすすめします。
Tips4. メンテ前後の開発メンバーのリソース・タスク状況は
すでに予定されているメンテナンス (とくに深夜メンテなど) の場合、ディレクターは売れっ子芸能人のマネージャーになったつもりで開発メンバーのリソース・タスク状況を完全に把握しておいてください。
開発メンバーが抱えている他の案件がリリース前だったり、メンテ中にスポットで依頼があるような場合はとくに要注意です。メンテ中は開発メンバーが最高のコンディションで対応できる環境を作るのがディレクターの使命です。メンテナンスの対応に影響が出る可能性がある場合は事前に関係各所と調整してください。
これは超基本的なことですが、エラーメッセージは英語で書かれていることが多いからか、ろくに読まずに「エラーです、ごにょごにょ」といったことが稀にあり、エンジニアからの苦情もたまに聞くので、あえて入れます。
一口に障害といえども様々です。エラーメッセージを目にしているのに「なんだかわからないけど障害です」では意味がありません。翻訳はもちろん、検索すれば同じような問題に遭遇した人の情報が出てくることもあります。エラーメッセージはちゃんと理解しようとしてください。
なお、404や500エラーなどのHTTPステータスコードについては、下記の記事に詳しくまとまっています。
→web開発者なら知っておきたい HTTPステータスコード
担当サービスのテンプレートをディレクターがある程度触れるのであれば、SVN (バージョン管理システム) のコミットログや、本番化報告メール、テンプレートの最終更新日時などを調べて、自分が把握していない編集履歴がないか、それが本番化されていないかどうか調べます。
よくあるのは開発中のフロントエンドのコードが誤って本番化されてしまって、バックエンドのプログラムが上がっていない事による障害です。こういったものはフロント側の該当コードを取り除けばひとまず復旧できる可能性があります。
障害発生直後に「さすがに3時間もあれば復旧してるだろうー」と思うのはディレクターの希望的観測でしかありません。開発メンバーの調査で問題を把握し、復旧までの目処が分かればすぐに告知するべきですが、なんとなくで「3時間」などと根拠のない時刻を告知してしまい、さらに遅れて再度訂正……などを繰り返すとそのサービスに対するユーザーの信頼は一気に崩れ去ります。
とくに規模の大きいサービスだと、「いつ復旧するのか」とユーザーのクレームや広告主などから答えを求められてプレッシャーになることもありますが、その時点で復旧の目処が立っていない場合、ここで伝えるべきはその場しのぎの復旧予定時刻ではなく、調査結果の報告時刻です。これは、問題が解決しているかどうかに関わらず、その時点での調査の進捗を伝えることですので、報告が遅れるといったことはありません。
また、その段階になれば復旧までの目処が立っている可能性も多く、その場で改めてより正確な復旧予定時刻を伝えることができるはずです。
障害対応後に障害報告書を書くのは当然ですが、よくありがちなのは、この報告書の再発防止の項目に「もっとしっかりと確認します」といったような「もっと (more)」を書いてしまうことです。
これを文字通り「もっとしっかり」頑張ってやるのはせいぜい数日〜2週間ほどで、その後はいつもの調子に戻ってしまうでしょう。手を動かす類の改善案は根本的な解決にはならないことが多いので、そもそも問題を起こさないために何をすべきなのか、具体的かつ無理のない方法を考えた方がいいでしょう。
私も新人ディレクターの頃は冷静にならなければいけない場面で、頭の中が真っ白になって苦い思いをした経験が何度もありました。このとき「もっとこうしておけばよかった」の積み重ねがこのようなTipsとして自分の中に蓄積されていたりします。実際のメンテナンス・トラブル時に少しでも思い出していただけると幸いです。
ライブドアではどんなトラブルにも風林火山の面構えで対応できるディレクターを募集しています。
ディレクターブログでは、すでに何度か障害時の基本的な対応についての記事 (障害対応的ディレクションスキル・サーバ障害と向き合うには) が書かれていますが、今回はもう一歩踏み込んで、メンテナンスやトラブルの際にディレクターがしておいた方がいいTipsをいくつかご紹介します。
Tips1. トラブルの第一報だけは最速で開発メンバーに伝える
責任感の強い人は、まずはディレクターが問題をある程度取りまとめてからエンジニアや関係者に共有……と思いがちですが、たとえその時点で問題をよく把握できていなくても、障害が起きているということだけは最速で伝えるべきです。これは下記の2つの点から重要です。
◆ひとりよりも複数で問題に取り組んだ方が解決が早い
ディレクター、エンジニアをはじめて開発メンバーが把握している (よく理解している) 領域はそれぞれ異なります。問題を切り分け、障害の原因をいち早く発見するには、自分ひとりでやろうとせず、関係者全員で取り組んだ方がいいと思います。
◆すぐに対応できる環境にいるとは限らない
ディレクターはいつどこで障害の連絡があるかわかりませんし、エンジニアも外出や旅行中ですぐには対応できないかもしれません。そのようなときに第一報を入れるのが遅れると、全てが後手後手にまわって復旧も遅くなります。Tips2. トラブル時に使用するメンテナンス画面の雛形は
事前に用意する
たとえまだ一度もトラブルが起きていなくても、実際にトラブルが起こってからメンテナンス画面を作り始めるのと、事前に雛形の用意されたメンテナンス画面に入れる内容を考えていくのとでは精神的負担が違います。
これは、ユーザーへの告知をテンプレート化して楽をしよう、ということではなく、事前に起こりうるトラブルの内容を想像し、ユーザーへの状況説明を事前にシミュレーションできることに価値があります。これによって実際のトラブルでの初動が早くなるだけでなく、冷静に対応できるようになるはずです。
Tips3. 前任者の連絡先まで聞いておく
担当エンジニアの連絡先を聞いておくことはもちろんですが、前任のディレクター・エンジニアなどの連絡先も聞いておいた方がいいです。とくに、引き継いでから日が浅いサービスの場合、前任者へのヒアリングが原因の早期発見につながることも多いです。
もちろん、前任者任せになってしまうのは本末転倒なので、現担当の自主的な行動が求められてしかるべきですが、障害対応用のMLやグループチャットなどを利用しているのであれば、引き継ぎ後の一定期間は念のため参加したままでいてくれるよう前任者にお願いしておくことをおすすめします。
Tips4. メンテ前後の開発メンバーのリソース・タスク状況は
必ず把握する
すでに予定されているメンテナンス (とくに深夜メンテなど) の場合、ディレクターは売れっ子芸能人のマネージャーになったつもりで開発メンバーのリソース・タスク状況を完全に把握しておいてください。
開発メンバーが抱えている他の案件がリリース前だったり、メンテ中にスポットで依頼があるような場合はとくに要注意です。メンテ中は開発メンバーが最高のコンディションで対応できる環境を作るのがディレクターの使命です。メンテナンスの対応に影響が出る可能性がある場合は事前に関係各所と調整してください。
Tips5. 英語のエラーメッセージも是が非でも読む
これは超基本的なことですが、エラーメッセージは英語で書かれていることが多いからか、ろくに読まずに「エラーです、ごにょごにょ」といったことが稀にあり、エンジニアからの苦情もたまに聞くので、あえて入れます。
一口に障害といえども様々です。エラーメッセージを目にしているのに「なんだかわからないけど障害です」では意味がありません。翻訳はもちろん、検索すれば同じような問題に遭遇した人の情報が出てくることもあります。エラーメッセージはちゃんと理解しようとしてください。
なお、404や500エラーなどのHTTPステータスコードについては、下記の記事に詳しくまとまっています。
→web開発者なら知っておきたい HTTPステータスコード
Tips6. 自分が把握していない変更・本番化履歴がないか調べる
担当サービスのテンプレートをディレクターがある程度触れるのであれば、SVN (バージョン管理システム) のコミットログや、本番化報告メール、テンプレートの最終更新日時などを調べて、自分が把握していない編集履歴がないか、それが本番化されていないかどうか調べます。
よくあるのは開発中のフロントエンドのコードが誤って本番化されてしまって、バックエンドのプログラムが上がっていない事による障害です。こういったものはフロント側の該当コードを取り除けばひとまず復旧できる可能性があります。
Tips7. 根拠のない復旧予定時刻は書かない
障害発生直後に「さすがに3時間もあれば復旧してるだろうー」と思うのはディレクターの希望的観測でしかありません。開発メンバーの調査で問題を把握し、復旧までの目処が分かればすぐに告知するべきですが、なんとなくで「3時間」などと根拠のない時刻を告知してしまい、さらに遅れて再度訂正……などを繰り返すとそのサービスに対するユーザーの信頼は一気に崩れ去ります。
とくに規模の大きいサービスだと、「いつ復旧するのか」とユーザーのクレームや広告主などから答えを求められてプレッシャーになることもありますが、その時点で復旧の目処が立っていない場合、ここで伝えるべきはその場しのぎの復旧予定時刻ではなく、調査結果の報告時刻です。これは、問題が解決しているかどうかに関わらず、その時点での調査の進捗を伝えることですので、報告が遅れるといったことはありません。
また、その段階になれば復旧までの目処が立っている可能性も多く、その場で改めてより正確な復旧予定時刻を伝えることができるはずです。
Tips8. 障害報告で「もっと頑張ります」は禁句
障害対応後に障害報告書を書くのは当然ですが、よくありがちなのは、この報告書の再発防止の項目に「もっとしっかりと確認します」といったような「もっと (more)」を書いてしまうことです。
これを文字通り「もっとしっかり」頑張ってやるのはせいぜい数日〜2週間ほどで、その後はいつもの調子に戻ってしまうでしょう。手を動かす類の改善案は根本的な解決にはならないことが多いので、そもそも問題を起こさないために何をすべきなのか、具体的かつ無理のない方法を考えた方がいいでしょう。
私も新人ディレクターの頃は冷静にならなければいけない場面で、頭の中が真っ白になって苦い思いをした経験が何度もありました。このとき「もっとこうしておけばよかった」の積み重ねがこのようなTipsとして自分の中に蓄積されていたりします。実際のメンテナンス・トラブル時に少しでも思い出していただけると幸いです。
ライブドアではどんなトラブルにも風林火山の面構えで対応できるディレクターを募集しています。
コメント