「ブランドオフィシャル」 というサービスの開発エンジニアをしている suezawan といいます。
主にエンジニアチームのタスクマネジメントを行っています。
つい最近、Techブログ「Developers Summit 2019 に参加してきたので、サクッとレポート書く#devsumiA に投稿したばかりですが、社内のエンジニアの人にも読んで欲しいので布教をかねて投稿します。
なぜこの本を手にとったか？
私自身これまでのサーバ監視は、zabbix、nagios、munin、CloudWatch、Mackerel、Grafana、kibana、Site24x7など数多くのツールを利用してきました。それでも足りない監視項目は自前で監視機構を作成したりしてきました。ただ、HowTo本から知識を学んだわけではなく、業務で利用していたから覚えたり、アラート対応を自身で行ったからこそ身に付いたものだったりしたわけです。
つまり、これまでやってきた自分の監視経験から得た知識や判断ポイントは多分あってるだろうけど、「入門」監視を照らし合わせて答え合わせをしてみようと思ったのです。
監視のアンチパターン
監視は全員がやるべき仕事であり、チームや部署内での役割はありません。
これはその通りだと思います。
どうせあの人がやってくれるだろう・・という他人任せの考えは自分も成長しません。それにその任せてた人がいなくなるパターンもありえますし。
SLAとは（ほとんどの場合）願望や嘘である
AWS EC2はSLAにおいて、1つのリージョンに対して99.95の可用性しか提供していないことを知っていたでしょうか。これは年に4時間のダウンタイムがあり得るということです。
知ってました。EC2インスタンスは落ちます。ホストの不調で。なのでAWSはマルチリージョンでの提供をしているわけです。（と私は思っています）
どうしたらアラートをよくできるか
誰かを叩き起こすためのアラート、参考情報（FYI）としてのアラートの2種類があります
これもその通りかと思います。
エンジニアは条件反射的にアラート対応にはいるかと思いますが、そもそもアラートとして本当に緊急性が高いものなのか、緊急度の高くないものまでなにかが起こっていることは全員が知るべきだと広範囲にアラートメールを飛ばすことが良いことか今一度考えるべきだと思います。
アラートにメールを使うのをやめよう
アラートメール飛ばし過ぎて埋もれてしまい、本当に対応が必要だったアラートが埋もれてしまうリスクがあります。
最近はSlackに通知させたり、緊急度の高いものは電話でcallするというのもありますね。
アラートを削除し、チューニングしよう
うるさすぎるアラートにはイライラします。うるさいアラートによって、人々は監視システムを信用しなくなり、さらにはすっかり無視してしまうようになります。
定常的に発生しているアラートに対し、「あっまた発生している、でもどうせすぐリカバリくるでしょ」はアンチパターンです。即刻チケット化して対応しましょう。アラートが発生しないことがシステムのあるべき姿です。
インシデント管理とは、発生した問題を扱う正式な手順のことです。
この本のなかにインシデント管理という章立てがありました。
障害は現在進行形で問題は発生している場合が多いことと、原因調査にはすくなくとも時間がかかります。ただ当事者のエンジニア以外からは割と大変さが伝わっていなかったりします。そういうときに営業やサポートチームからは、なぜ障害が起きたのか？もう治ったのか？原因は？という問い合わせもくるでしょう。
この本では、こうあるべきだという体制について言及してくれています。
現場指揮官
判断する人。顧客や社内のコミュニケーション、調査には携わらない。あがってきた情報をもとに適切に判断する役割です。
スクライブ
記録する人。障害対応中は刻刻と状況が変わるものです。後から障害報告書を作成するためにも対応内容は時系列で記録すべきです。
コミュニケーション調整役
最新状況のコミュニケーションを関係者に行う人です。障害でなにが発生しているかはこの人に聞くべきです。
SME
実際に障害対応、調査する人です。
インシデントの解決に取り組んでいる人たちに最新情報を直接聞いてしまって、インシデント解決対応の邪魔をすることは避けないといけません。意外にやってしまってる人もいるかと思います。これは上記の体制がまわりに伝わっていない場合にも起こりえるので、注意が必要です。
そして最後に、障害対応が終わった後は関係者を労う言葉を伝えることがとても大切なことです！！
サーバ監視
8章では、cpu、memory、disk、ネットワーク、ロードアベレージ、証明書問題、Webサーバ、データベースサーバ、メッセージキュー、キャッシュ、DNS、NTPといった、なじみのあるサーバ監視にも基本的な監視の見方や用語の説明が丁寧に書いてあります。
「サーバ監視ってなにからやってみればいいかわからない」といった人は、8章をまずは読んでみるといいと思います。cpu、memory、diskの読み解き方は覚えておいて損はないです。
最後に
一通り読んでみた感想としては、自分の障害対応時の初動はこの本に沿った形で行動できていそうと思いました。ただ、難易度の高い障害ほど冷静に対応する必要があるので、障害が発生したときは、気を引き締めて対応することを心がけようと思います。
また、アラートすべき基準や、そもそもアラートがなぜ必要についても言及してくれているので多くの人が手にとる理由も少しわかったような気がしました。
「監視」はサービスが安定稼働していないときに発せられるメッセージです。アプリケーションの保守とは切っても切れない関係なので、「ハハッこいつまたアラートだしてそんなに構ってほしいのかー」くらいのポジティブな気持ちでサクッと対応できるように、この本読んで一回り成長しましょう！
ps 社内のエンジニアさんへ
この本を読みたい方は、私のところまでお声かけください！
