バックエンド→インフラに移って「監視」に対する意識が少しずつ変わってきた話

この投稿はアイスタイル Advent Calendar 2020 の7日目の記事です。

#目次

  1. はじめに
    異動し意識が変わった点について
  2. 監視に対しての意識がどう変わっていったか
    アプリケーション担当時代
    インフラに入ってから
    改めて入門監視を読んでからの気づき
    これまでの監視体制と問題
    取り組んでいる監視改善について
    どう動き、どうなったか
    今後は更にどう改善していきたいか
  3. おわりに
    まとめ
    所感

#はじめに

こんにちは。今年の5月頃から web アプリのバックエンド→インフラに転向した urabes です。
まだまだインフラとしてひよっこですが必死にやらせてもらってます。
ネットワーク/サーバ周りについて、これまで苦手意識があったからこそ毎日刺激を受けてやりがいを感じています。

インフラとして初めて取り組む業務として、監視改善を担当させていただきました。
この経験と、入門監視を改めて読み直したことを軸に、心境と行動の変化についてお話したいと思います。

異動し意識が変わった点について

チーム単位毎に担当サーバはあるものの、インフラエンジニアとして関わりが強いため、網羅的に当事者意識を持つことができました。
そしてこの監視改善の取り組みから、立場的にアラートへ反応することに対し、心理的障壁が無くなりました

しかし、それはあくまでもポジショントークです。
ここで改めてオライリーの「入門監視」をしっかり読み直しました。監視の本質について胸に刺さる言葉がいくつもあり、それについても弊社の現状と合わせて後ほど話したいと思います。

#監視に対しての意識がどう変わっていったか

時系列的に話していきたいと思います。

アプリケーション担当時代

何か問題でアラートが上がった際、自チーム担当の領域に対して、自分も焦りつつもどう動けばいいかわからなかったり、アラート対応の経験が少なく、自信も無かったことから、積極的に動けずにいました(言い訳でもある)。
いつも仕様理解が深く、経験が多く強い方々が反応/対応してくれていて、どこかしら遠い存在に感じていました…。

ましてやアプリケーションサイドだと尚更、本番調査は全員の機会が均等ではないため、やった者とそうでない者で、心理的障壁が異なる、と個人的には思います。

インフラに入ってから

監視改善について取り組んだこともあり、当時反応ほぼ0の当時よりも圧倒的に反応/対応をするようになりました。まだまだ経験と全体のシステム背景の理解は浅いかもしれませんが、対応を任せられた環境により、「前回対応よりもうまく立ち回れるように」心掛けられる段階に入ることができました。アラートにまず反応することの意義を知ることで、以前よりモチベーションと積極性は増したと思います。

ポジショントークにならぬ様、監視の課題に対して向き合い方を定め、まずは自分から体現していこうと心掛けるようになりました。

改めて入門監視を読んでからの気づき

以下の言葉が、今回監視改善に取り組む上で特に胸に刺さりました。

  • 手順書(RunBook)をつくろう
    サービスに紐づくアラート説明やその理由、どんなメトリクスやログを送っているか等。
  • 監視は役割でなく、スキル
    決まった個人に対し、監視の責任を押し付けてしまうのはアンチパターン。全員で「監視するまでが本番環境」の責任を持つこと。サービスのパフォーマンスのための重要項目スキル。

この気づきを基に、具体的に監視改善のひとつで行ったことをお話します。

これまでの監視体制と問題

弊社のこれまでのアラート事情は、基本的なサーバ(WEB/API/DB)の、ping 疎通や DISC/CPU/inode/daemon系/ミドルウェア等のサーバ内状態、traffic の状態を Zabbix/Grafana で検知するようにしています。
通知先は、slack のアラート channel と開発メンバーへの ML に対し Gmail で通知しています。

今回任さられた監視改善では、課題として以下が挙げられました。

“各アラートに対し、反応/対応者が限られること”

サービスや人が増え、無意識に監視が「役割」として課されてしまっていたことから、新規参入者の対応が困難になっていることが原因と考えられました。

取り組んでいる監視改善について

従来は経験則から必要なアラートを汲み取れる人が反応、対応をしてくれていましたが、その人がいない場合には対応が遅れてしまう可能性もありますし、周囲も不安になります。

そこで今回アラートが上がっているサーバに対し、まずはコマンドや監視ツールで「誰でも現状共有ができるようにすること」をはじめの課題にしました。
そのためアラートを見過ごさぬ様、その事象とそのためのコマンド、運用フローを記した「対応表」の作成に取り組みました。

役割は「現状把握のためのコマンド」「担当者へのエスカレーションをさせる運用フローを載せる」ことです。これを見て全員が同じ対応ができることが理想。上記の「入門監視」で挙げた点を満たせるものを目指してます。

工夫した点としては、アラート発生時に初見の人でも読みやすく、左から読んでアラート名→説明→コマンドへ促せる様に文脈を意識しています。

まだ改善の余地はありますが、上記で「入門監視」について挙げた気づきの2点を抑えられるものになっているかなと思います。
▼イメージ例

アラート名 アラート説明 一次対応内容 実施コマンド(OS種別) 備考
NTP_Localtime NTPによる時刻同期が正常にできておらず、60秒以上時刻がずれている状況。監視間隔は 3600 秒に1回。 NTP設定、時刻設定を確認し、相談しズレている場合は正常に戻す。▼以下手順… 一次対応内容の手順に合わせてコマンド列挙 NTPサーバ構築時のドキュメントURL

どう動き、どうなったか

まず誰かが反応してくれる安心感を生むための施策として

  • 補助として対応表を作成、slack のトピックに共有
  • 文化として馴染ませる前に、まずはインフラひよこな自分が使用し、適宜テスト対応でアップデート

対応表の作成にもチームレビューを適宜してもらい、動作1つ1つに自信が付きました。
また1次対応が少しずつできるようになり、自然と少しずつ自信が付いてきました。
自信をつけるための補助輪になり、少しでもアラート反応の不安を減らすことに貢献できるものになれば幸いです。

更にもっと便利にさせたいためコマンドのオプションの組み合わせにも関心が高くなり、仮想環境等で調べてよく試すようになりました。

今後は更にどう改善していきたいか

▼全員で監視対応できる文化構築
監視自体とアラート自体の本質と取り組み方について、組織の認識をアップデートさせて、皆で監視対応できる文化をつくっていきたいです(このブログでも少しでも伝われば幸い)。
対応表のアップデートも引き続き行っていきます。

「入門監視」を読まなかったら、インフラに就き監視について役割として「見方が変わった」とポジショントークで終わらせるところでした(恥ずかしい)。
監視改善について自分の本当の役割は、まずは反応に自信の無かった自分から反応し、体現し続けます。
そして徐々に監視文化の育成を促すことだなぁと痛感しました。

▼監視の自動化
また、本では手順書(RunBook)は大事とも言っている反面、「手順書依存」にも気を付けてというのも挙げられています。
手順書は「人間が読み人間の判断や心理が関わってくるため不安要素も生まれる可能性があるよね」ということです。

そのためIaC(Infrastracture as Code)に沿って、アラートに対して対応表の内容を自動化で対応できるようになったら最高だなと思います。

▼APM(Application Performance Management)の導入
またここ最近はインフラだけでなくアプリケーション側のアラートボトルネック把握のために、いくつかの APM を導入/検証しつつ検討しています。
これで、どこが原因でアラートが上がっているかをGUIでわかりやすく特定します。

▼適切な監視が行われているか整理
各アラートが OS/ミドルウェアなどに応じて適切な監視ができているか。「入門監視」にもありましたが、目的に対し「本当にその監視は必要なのか」「トリガーやアイテムは正しいのか」見直しを改めていきます。

#おわりに

まとめ

最後まで読んでいただきありがとうございます。
インフラに就き監視改善について施策として機会を貰え、相談できる文化や空気感があったことから、自分も踏み出して何かあった時の保守に回れる勇気が付きました。チームの皆さん改めてありがとうございました。

改めて監視はスキルであり、チーム文化です。
有識者もそれ以外の人も歩み寄って、皆で責任を持って対応する空気をつくり、どうせやるなら切磋琢磨してサービスを守っていきましょう!

監視も勿論ですが、弊社のインフラは今諸々改善で新しく生まれ変わろうとし、やりがいのある時期です。ネットワークに自信のある方、または IaC やクラウド、運用改善に関心のある方、よろしかったらこちらよりお待ちしております!
一緒にインフラをアップデートしていきましょう🍜

所感

オライリーの「入門監視」めちゃくちゃ良かったです。
具体的な施策やツールを提示してくれるというより、「メトリクスの在るべき見方」や「アラートの在り方」「組織として監視をどう向き合っていくものか」を学べる、汎用的なものになります。
フロントからバックエンド/サーバ/ネットワーク/セキュリティやインシデント管理など項目も充実しています。組織の大小関係なく開発者以外も読むべきバイブル的な一冊だと思いました。

あと付録内容も素晴らしいので是非買ってみてください。

最初の乾杯から〆の一杯までいけるくらいこよなく日本酒を愛す系エンジニア。おでんのダシ割りは七味入れる派。