コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

休みの際の対応フローを考えるときのはじめの一歩

連休前なので自分の知識整理を含めた「障害対応の体制づくりを考えるときにまず何から考えるべきか」という内容の雑記です

考えること

トピックとしては3つ

  • どれくらい止まってもいいのか
  • 有事の際の連絡系統、意思決定系統はどうするべきか
  • 何かあったときにどうすればトラブルに対処できるのか

どれくらい止まってもいいのか

大概のWebサービスが24時間365日稼働していれば一番幸せだけれど、それを確実に保つことはできない。

ただし100%の稼働率を担保するのは難しいので、その場合にどれくらい止まっていいかという観点が重要になる。

そのため「どれくらい止まってもいいのか」というのを考える必要がある。

有事の際の指示系統

障害時は慌ただしくなるのが世の常。そのため慌ただしい状況下においてもただしく関係各所に伝えることが大事。

そのため何か起きたときの連絡先、そして指示系統はしっかりしておくといい。決めるべきこととしては以下の内容

  • 障害発生時の報告先(チャット/連絡網 etc..)
  • 有事の際に動くときのアクションの仕方とルール

1つ目は割と感が得られることも多いのだが、2つ目はあまり考えられることがない。2つ目を定めておくメリットとしては、気づいた人が慌てて行動したことで二次被害を招くということがあるので、有事の際は複数人の意思を絡ませるようにするなど、一定のルールを敷いて認識合わせをしておくことが大切になる。

トラブルに対処できるのは誰か

サービスもRailsやLaravelなどで構成されるようなアプリケーション部分と、Linuxなどのミドルウェア部分だったりと多岐に渡ることが多い。みんながすべてのレイヤーに対して対応できるのであれば問題ないが、大概においてそうではないことが多い。そのため以下のようなことをまとめておくといい。

  • トラブルが起きるとしたらどういう分類でトラブルが起きるのか
  • そのトラブルが起きる部分は誰なら対処できるのか
  • その対処方法はマニュアル化できるか、できるのであればあるか

例えばサーバーの再起動のようなことはマニュアル化できる部分なので、有事の際に人に依存せずできるようになっているとすごく楽になる。

関連リンク