#cmdevio2016 (レポート: E-4) AWSトラブルシューティング!早期復旧のための心掛け

2016.02.21

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

こんにちは植木和樹@上越妙高オフィスです。2/20(土)に行われたDevelopers.IO 2016にて、サービス障害時にいかに早く復旧させるかについてお話しさえてもらいました。本日はその資料公開になります。

発表資料と補足

運用と保守

  • 運用と保守という言葉は人によって定義が異なる。
  • 運用:「正常に稼働しているシステム」を用いて実施する業務
  • 保守:「システムが本来あるべき姿」になるよう対応すること
  • 組織によっては運用担当と保守担当が別になることがあるため、上記観点で担当業務を整理分類すると良い。

日常作業

  • 企業の大小に関わらず運用設計の整備に携わる人は少ない。
  • また運用設計者とトラブル対応する人は同じ人になりやすい。
  • 必然的にその人に仕事が集中しやすい。
  • 運用は他の人ができるよう、日々の作業手順を整備し仕事を分散しておかないと、突発的な障害時に対応が難しくなる。

監視

  • 監視通知しただけではダメ。通知を受け取った後のことも検討しておく。
  • CPU使用率が高いことが問題なのではなく、サービスの停止が問題。
  • 障害監視の観点ではリソースでなくサービスを監視すること。
  • 同様にバッチ処理はデータ更新が止まってしまっていないか、を監視すると良い。
  • オオカミ少年はダメ、ゼッタイ。

障害

  • 障害発生時の復旧は考えてたらダメ。
  • どういう障害が起きたら何を行うか事前に決めておく。「機械的」に対応ができるようにする。(機械的 ≠ 自動化)
  • 復旧手段だけでなく、確認手段も決めておく。
  • さらに報告先とその手段も決めておくこと。
  • AWSサポートにケース起票する際はできるだけ具体的に伝えましょう。

調査

  • システム構成図を用意すると障害ポイントの切り分けが早くなる(どことどこが通信しているのか、どんなプロトコルで通信しているのか)
  • ログが大事。とても大事。

リリース前の準備

  • 運用開始前に負荷試験と障害試験をしておきましょう。
  • 本番環境DBのリストア試験は運用開始したらできなくなります!
  • 手順書を作って終わりでなく作業者自身に行ってもらうこと。構築担当なら当たり前のことも第三者には難しいことがあります。
  • 運用開始前に必ず Trusted Advisor はチェック!
  • 構築担当と運用担当が協力して標準化を進めましょう。

まとめ

オペレーション担当の立場からちょっとキツメの口調でお話させてもらいましたが、セッション後に感謝のコメントをもらえてうれしかったです。

システムは構築にかかった時間の10倍の期間利用されると考えています。システムは運用を開始し業務に使われるようになってからが本番です。長い期間安定してシステムを稼働させるためにも、十分な前準備を心がけたいものです。

参考ブログ