この記事は検索エンジンプロダクトを一緒に開発してた同窓会のカレンダーの24日目の記事です。
この記事の想定読者
- 夜中にメモリ使用率超過のアラートを受け取ってるけど、特に何もする必要がない人
- アラートの通知内容だけではよく分からないので、監視ツールの画面や本番環境の状態を目視で確認して影響確認してる人
この記事で想定していない読者
- MSP事業者のようなITインフラの監視・安定化、それ自体を目的とされている方
労働の疎外
まずはカール・マルクスの話をしましょう。
マルクスの理論における「労働の疎外」には主に次の四つの側面があります
-
製品の疎外: 労働者は自分が生産する製品との関係を失います。彼らは自分の労働で作り出した物を所有せず、それが単なる商品として扱われます。
-
生産活動の疎外: 労働者は自分の労働過程との関係を失います。単調な作業により創造性が抑制され、仕事に対する個人的な充足感が欠けます。
-
人間の本質からの疎外: 労働者は自分の本質的な人間性との関係を失います。創造的で自己実現を求める人間の性質とは対照的に、仕事は単純で無意味なものになりがちです。
-
他人からの疎外: 労働者は他人、特に雇用者や同僚との関係において疎外を感じます。競争や階級の分断により、人間関係が希薄になります。
たとえば、町工場で小さな部品を作っていて、どういう製品を構成している部品か知らずに町工場でひたすら部品を作っているような場合は、「製品の疎外」「生産活動の疎外」「人間の本質からの疎外」と密接な関係がありそうです。
なんのために、誰のためにやってるかという目的もわからず、最初は辛かった作業にも慣れ、淡々とこなすだけになるような仕事に充実感や自身のキャリアの成長を感じる人は少ないでしょう。
労働の疎外と運用監視
冒頭に上げた「夜中にメモリ使用率超過のアラートを受け取ってるけど、特に何もする必要がない人」のことを考えてみましょう。
この人も最初に通知を受け取ったときは「え！障害だ！」と慌てて飛び起きてPCに向かって調査をしたり、上司に報告したかもしれません。
しかし、通知を受けとった彼にできることは監視ツールでメモリ使用量を確認するくらいで、どこを調べたらいいかよくわかりません。本番の何処かで不具合があるのかもしれないと思い、本番サービスのWeb画面を見ても普通に表示されてるし、どこにどういう影響があるのかわかりませんでした。上司に報告しても「それはいつものアラートだから無視していいよ」と言われていちおう納得し、何度かそれを繰り返していくうちに、いつしか通知のメッセージだけで「これは無視するやつだな」と判断がつくようになり、夜中や仕事中に通知が来てもそっと既読にするだけの作業に慣れてしまったのでしょう。
「通知を見直したほうがいいのではないか」と考えても、「直近1分間の平均メモリ使用率が80%を超過したらALERTとして通知」という設定の妥当性をどこで判断したら良いのかわかりません。
5分間の平均にすれば通知が減るかもしれませんが「なんかあったらどうしよう」と思い変更するのを躊躇ってしまいます。
彼はアクションが不要な通知を受け取ることを享受しましたが、それは彼の仕事を通じた充実感やキャリアに良い影響を与えると考える人は少ないでしょう。
先に述べた「労働の疎外」との関連を見てみましょう。
通知に慣れてしまった彼は通知を受け取っても「またか」と感じ、必要なアクションを躊躇するようになります。ここでの疎外感は、彼が単純な監視任務に縛られ、その作業がどのように組織の目標や顧客の満足に貢献しているかを理解しにくくなる点にあります。
さらに、「製品の疎外」の観点からは、彼が自分たちの労働が最終的なサービスや製品の品質向上にどのように貢献しているのかを把握しにくい状況が生まれます。例えば、メモリ使用率の問題がサービスのパフォーマンスにどのような影響を及ぼすのか、またそれが顧客体験にどのように反映されるのかについて、明確なつながりを見出せないかもしれません。
このように彼は、日々のルーチンワークによって、自分たちの労働の大きな目的や意義から遠ざかり、結果として疎外感を強く感じるようになります。この疎外感は、仕事に対するモチベーションの低下や職業的な満足度の低下につながり、転職やモチベーションの低下、運用監視という仕事にマイナスイメージを持つようになるかもしれません。
原因じゃない、症状を見るんだ
では、どうすればよいのか考えてみましょう。
RED Method という考えがあります。
RED Methodとは
- Rate（単位時間あたりのリクエスト数）
- Errors（失敗したリクエストの数）
- Duration（リクエストの処理にかかった時間）
の頭文字をとったもので、こちらのブログでは、「REDメソッドは、顧客がどれだけ満足するかを示す良い指標です。もしエラー率が高ければ、それは基本的にユーザーに伝わり、ユーザーはページ読み込みエラーを起こします。処理時間が長ければ、ウェブサイトが遅いということです。」と紹介されています。
監視の優先度として、ユーザーに影響のある、目に見える症状から監視するべきです。Webサービスであれば画面表示やボタンをクリックするなどのユーザーの行動に対してRED Methodを設定し、そこで異常が起きたら通知すべきです。
メモリやCPUの使用率やNetworkの帯域を監視するにはUSE Methodと言う考えがあり、これは
- Utilization（リソースがビジー状態だった時間の割合）
- Satulation（リソースがこなさなければならない仕事の量、多くの場合はキューの長さ）
- Errors（エラーイベントの数）
の頭文字をとったものです。
これも重要な指標ではありますが、あくまでもこれはサービスそのものの監視から考えると原因に過ぎません。
例えばメモリ使用率超過でWebサイトの表示でエラーが起きた場合。サイトの表示がエラーが「症状」で、メモリ使用率超過はその「原因」です。
ここで注意したいのは、症状と原因は1:Nの関係でメモリ使用率超過が必ずしもエラーになるとは限らないことです。
通知はRED Methodに関するものを優先し、インフラメトリクスは通知の優先度を下げ、夜中に誰かを叩き起こすような通知は不要でしょう。
いやいやインフラ監視を軽視するんじゃないよという声
しかし、こういう声もあるでしょう
- 症状は結果であり、障害（結果）を未然に防ぐ必要がある。起きてからでは遅い
- メモリやCPUといったインフラリソースの監視は依然重要であり、優先度を下げるべきではない
この声に従うと、RED MethodとUSE Method全てに通知を出すことになり当然通知量は増えます。冒頭の彼であれば、通知が増えて取捨選択をする回数が増えてちっとも楽になりません。どの通知がどの通知と関連してるのか調べて報告する必要があり、ユーザー顧客の満足度に近い監視ができるようになったものの、今度は数が増えてしまいます。『きめ細かい監視』響きはいいかもしれませんが、夜中に叩き起こされる回数や、仕事中にアラートのせいで手を止める回数が増えることでしょう。
これが俗に言う「アラート疲れ」です。アラート疲れは「人間の本質からの疎外」を誘発する可能性があり、その人の本来持っている能力や創造性の発揮を妨げる可能性があります。
インフラ監視はなんのため？
先程の「インフラ監視をも最重要で必ず通知すべき」という声に関しては、条件付きで賛成です。その条件とは
- 対象のインフラリソースがオートスケール（自動拡張）不可能なもの
に限ります。オートスケール可能なインフラリソースはできるだけオートスケールすべきです。
監視で最も重要なのは「そのサービスがやるべきことをやっているかを監視」することです。多くのサービスのすべきことはメモリ使用率を80%以下に抑えることではありません。ユーザーに価値を提供し続けることです。
障害を起こさずサービスの継続を考えるのであれば、メモリ使用率超過をトリガーにオートスケールする方法を検討すべきでしょう。
仕事のスコープをインフラ監視に閉じてしまうと、こういう発想に至らないケースがあります。改めて、なんのために自分は監視をしているのか見直してみましょう。しきい値や運用フローの見直し以外にも、できることがあるかもしれません。
そもそも、メモリ使用率超過の通知を受け取った人にできることは何でしょうか？「メモリ使用率が80％超えてます」という通知内容だけではアンチパターンです。通知を出すのであれば、以下を考慮しましょう。
- 行動可能であること
- タイムリーである
- 適切に優先順位がつけられている
メモリ使用率超過に関しては優先順位を下げ、例えばSlackならメンションをつけずにInformationやWarningレベルで通知すれば、誰かを夜中に叩き起こすことはなくなるでしょう。
危ぶむなかれ、危ぶめば道はなし
ここまでで、疎外の論理を軸に
- 対応不要なアラートは「製品の疎外」を生み、自分たちの労働の大きな目的や意義から遠ざかり、仕事に対するモチベーションの低下や職業的な満足度の低下につながる
- アラート疲れは「人間の本質からの疎外」を誘発する可能性があり、その人の本来持っている能力や創造性の発揮を妨げる可能性がある
- ユーザーに近い箇所の目に見える症状をRED Methodで監視し、これを監視の再優先事項にすること
といったことを述べてきました。ではここから具体的な改善ステップを考えていきましょう。
現状の観測
まずは現状を観測しましょう。1週間や1ヶ月といった単位で、監視システムから出た通知を分析し、
- 誰も対応しなくて、問題があったもの
- 誰も対応しなくて、問題がなかったもの
に分類しましょう。
問題点の分類と対応
まず、「誰も対応しなくて、問題があったもの」については、通知内容を見直しましょう。通知は行動可能であるべきなので、通知内容には取るべきアクションを書きましょう。
障害時の対応を書いた文書、いわゆるRunbookへのLinkでも良いでしょう。とにかく「その通知を受け取った人に何をしてほしいか」を明確にして通知設定を見直しましょう。
そして、「誰も対応しなくて、問題がなかったもの」に関してはアラート設定の削除や通知の無効化を検討しましょう。
「そんなことをして、なにかあったらどうしよう」と心配になるかもしれませんが、その「なにか」とは何でしょうか？先にも述べたように、皆さんの監視しているサービスがするべきことは、メモリを80％以下に抑えることではないはずです。
RED Methodでサービスがやるべきことを監視できていれば、「なにか」は防げるはずです。
削除が心配なら、まずは検出はするけど通知を出さないようにしましょう。期間を設け通知を切って、てその期間中に運用上全く困ることが起きなければ、そのアラートは不要なはずです。
通知先の整理
あらゆる通知を1つのSlackチャンネルに出さずに、方針に応じて分けましょう。
例えば深刻度に応じて以下のように分けることができます。
| 深刻度 | 対応方針 | 通知先 | メンション |
|---|---|---|---|
| Critical | 深刻な障害。即時の情報共有、対応が必要 | #Critical | @channel （ステータスに関わらずチャンネル参加者全員に通知） |
| Alert | 障害は発生したが、即時対応は不要で翌営業日に対応 | #Alert | @here （チャンネル内のアクティバステータスの参加者全員に通知） |
| Warning | 軽微な障害。5営業日以内に対応 | #Warning | なし |
| Info | バックアップの状態など、知っておきたい情報 | #Info | なし |
こうすることで「このチャンネルの通知は絶対に見なきゃだめ」「このチャンネルの通知を水曜日のMTGで見直すようにしよう」など、情報の混乱を抑え、改善フローもやりやすくなるでしょう。
RED Methodの導入
RED Methodによる監視を導入しましょう。
マイクロサービスのようにAPI連携をしてる場合には、各APIをRED Methodで監視すると監視に統一性が出て、マイクロサービス間の問題にも気づきやすくなるでしょう。
もっと良いのは、ユーザの行動に根ざした形でRED Methodを導入することです。
例えばECサイトで商品一覧画面のURLが example.com/list であるならば、そのURLに対するGETリクエストのRED Method。ログイン画面が example.com/login であれば、そのURLに対するPOSTリクエストのRED Methodを見るようにします。
各RED Methodのしきい値はある程度の期間計測した上で決めるか、値の異常な変化に自動で気づけるアノマリー検知が可能であれば、そちらも検討しましょう。
こうすることで、そのサービスがやるべきことを監視できるようになり、アラートも「一覧を見れない」「ログインができない」など、具体的なユーザ影響のわかる質の良いアラートになります。
USE Methodの見直し
ある程度不要な通知を削除したところで、改めてUSE Methodを使ったインフラ監視を見直しましょう。
先程インフラは可能な限りオートスケールすべきと書きましたが、オートスケールにも限界があります。なのでサーバーやコンテナ1つずつのメモリ使用率ではなく、全体の平均メモリ使用率を監視するとオートスケール設定が適切かどうかわかることでしょう。
しかし、先の分類でいうとこのアラートは決してCriticalにすべきではなく、最悪でもAlertに（個人的にはWarningだと思ってます）すべきでしょう。
とにかく、ユーザーに影響が出ているところが最優先です。
以上のようなステップを繰り返すことで、対応不要なアラートやアラート疲れは低減されることでしょう。
まとめ
最後の方で述べたようなことは、誰かが設定したアラートを消すことの恐怖感だけでなく運用設計のリファクタリングになるわけで、それなりの知識や工数がないとだめだと思いこんで尻込みしたり、工数の確保ができない方も多いのではないでしょうか。
しかし、「労働の疎外と運用監視」で述べたように、無駄なアラートやアラート疲れの悪影響を軽視すべきではありません。あなたが我慢、享受できていることでも誰かの精神を蝕んでいるかもしれませんし、実は知らずのうちにあなたの精神も蝕んでいるかもしれません。
無駄なアラートをこれだけ減らしたという定量的な結果や、無駄なアラートが減ってプライベートや仕事の充実度が向上したという結果や見込みがあれば、工数の確保もいくらか可能になるのではないでしょうか。
O'Reilly Japan - オブザーバビリティ・エンジニアリングによると、オブザーバビリティのゴールは
- 持続可能なシステムと、それに関わるエンジニアの幸福
- ビジネスニーズの充足と、顧客の幸福
とされています。皆さんのサービスが顧客のためにあることが重要なのはもちろんですが、そのサービスに関わるエンジニアの幸福も同じくらい重要です。
この記事を読んだ方がエンジニアの幸福のためにアラートを見直すことを期待しております。
最後までお読みいただきありがとうございました！