システム監視の目的は障害を検知すること、だけではない
敗北しない設計に憧れます、那須です。
システム監視って皆さんされてますか? 障害発生したらピューン!ってメールとかが飛んでくるアレですね。 障害検知したらドキュメント見て初期対応したり関係各所に連絡入れたりして運用担当者は大忙しです。 それが 1,2 件とかならまだいいんですよ。 問題はそれが一気にやってきたり、運用手順がよくわからなかったりして、運用に支障をきたす場面ってありますよね。 本気で運用業務の負荷を下げたい。 その一心で考えてみたことを書き残します。
システム監視導入の目的とは?
ここでは、1 秒でも早く障害状態から正常状態もしくは縮退運転状態にしてサービスに影響がない状態にすること、と定義しましょう。 障害発生したら運用担当者が気づけること、ではないと私は思っています。 気づいてどうするの?って視点がないと運用で苦しむことになりますから。 なので、アラートが飛んできてから正常状態になるまでの時間をいかに短くできるかが大切だと思います。
その目的を達成するために何をしないといけないのか考えてみましょう。
アラート内容の工夫
アラートの内容ってカスタマイズできるサービスが今は一般的かなと思います。 Datadog でも Mackerel でも Zabbix でもできますよね。 で、何も考えずにアラートを設定すると、まあこうなります。
mm/dd hh:ss、○○で××が発生しました。
しきい値:100
検知した値:200
的な。 いや、わかるんですよ。 いつ、どこで、何が起こっているのかがわかるんで十分って声もわかります。
でもね、一度ここでさっき確認したシステム監視の目的に立ち返ってみましょう。
1 秒でも早く障害状態から正常状態もしくは縮退運転状態にしてサービスに影響がない状態にすること
さっきのアラートが自分のところに飛んできたとして、1 秒でも早く対応しないといけない。 そんな状況でこのアラートだけが飛んできたら。。。 目的達成できますか? もっと事前にできることあるんじゃないでしょうか?
あくまで案ですが、アラートの情報には、発生日時や対象、障害内容以外にもこんな情報を付け加えましょう。
- 障害対応手順
- 運用ドキュメントへのリンク
- 復旧目標時間
Slack への通知例だとこんな感じですね。
アラートの中に対応手順が書かれていれば、ドキュメントを探す時間がなくなります。 手順がものすごく長いとかなら、そのドキュメントへのリンクをアラートに書くだけでも手順実施までの時間が短くなります。 あとは、運用契約で目標復旧時間がある場合は、障害発生からいつまでに復旧させる必要があるのかまで書きましょう。 これがあれば、状況や運用担当のスキル等を基に障害発生してから○分経過しても状況が変わってなければエスカレーションするってフローが作りやすくなりますよね。
手順等をアラートの中に書くって運用にすれば、監視設計している時にそれぞれの監視項目での一次対応を決めることになります。 一次対応が書けないなら、そもそもそれを監視する意味ってあるの?って気づきも得ることができますね。 不要なアラートを飛ばすのはやめましょう。 運用の負荷が上がるだけですから。
このような工夫をすることで、場合によっては復旧までの時間が大幅に短縮されることもあります。 アラートはただの通知ではありません。 よくできたアラートは、よくできたガイドにもなり得ます。
障害対応の工夫
アラートで手順を書くようにすれば、一次対応はすぐに着手することができるようになります。 でもその一次手順、絶対に人間がやらないといけないですか? 自動化できる余地があるなら自動化しましょう。
たとえば、サーバで何かのメトリクスの異常を検知したとしましょう。 サーバでコマンド叩くのもいいですが、調査系のコマンドであれば障害発生をトリガーに自動実行してその結果もアラートに続いて送るようにしましょう。 AWS 等のクラウドなら案外簡単にできますよね? 復旧するためのコマンドも叩けるなら一緒に自動実行するようにすれば、人間が関与することなく復旧まで持っていくことができます。
調査や復旧を自動化すれば、かなり時間短縮になりますし、人間のオペレーションによるオペミスの発生確率もグンと下げることもできますね。 でも自動化したものが必ず想定した動きをするとは限りません。 なので、アラートにはどんな場合でも対応手順は書くようにしましょう。
最後に
この記事を書くきっかけとなったツイートがあります。
運用に「無駄が多い」のって結局「設計」の敗北なんですよね。システム設計の敗北だし、システム運用設計の敗北だし、業務設計の敗北なんですよ。
— のらから@運用屋さん (@norakara512) May 15, 2019
現場オペレータがどうとか言うレベルじゃないんですよね。いわゆる「上流」で失敗→下流に押し付けってのが実情だと思います。マジで。
設計で敗北すると最終的に運用でも敗北するんですよね。 お互い疲弊するだけですので、最初から「運用でカバー」ありきの設計はやめましょう。
のらから@運用屋さん (@norakara512) | Twitter さん、HATANO Hirokazu (@tcsh) | Twitter さん、いつもありがとうございます。