入門監視を読んで、「監視の民主化」に本気で向き合おうと思った話

こんにちは！待ちに待った2月です。
何を待っていたか？フットボールネーション（１３） (ビッグコミックス)やブルーピリオド（４） (アフタヌーンコミックス)、BLUE GIANT SUPREME（７） (ビッグコミックススペシャル)が発売される月ということになります。
嬉しい〜！の金城(@o0h_)です。

さて。
(ほぼ)ちょうど1ヵ月前に出た「入門監視」は、いろいろな方面で話題になりました。
既に色々な書評やまとめが出回っていて、反響の大きさが感じられますね！

www.oreilly.co.jp

弊社でも、会社の書籍購入補助を利用して即予約 & 入手をしました。
この本からは非常に多くの学びや示唆を得られたと感じています。

先日、その内容・感じたことを、社内LT会で共有しました。
発表内容を踏まえつつ、読後に自分なりに考えさせられたことをまとめてみたいと思います。
ただしスライドに含まれる全ての内容を扱うと広範になりすぎるため、今回は「組織」側面のトピックに絞って取り上げます。

また、本稿では「入門監視」に関する「まとめ」はあえて避けていきます。
その代り、その内容を踏まえて痛感した、我々のチームにおける「これまでの失敗」と「何を反省したか」を記します。
(そのため、既に一読されている方が対象になるかもしれません。)

TL; DR

この本を読んで、「監視の民主化」をしたい！と非常に強く感じた。
うちのチームは、少なくとも形式的にはアラートへの対応を全員でやっているが、見えない壁があった。
「監視をできるようにする」ために必要なのは、「知っている人」「慣れている人」からの歩み寄りが大事だと思う。
「監視はスキル」。誰でも出来るように、インプットとトレーニングを用意する。

発表資料

こちらが、発表した内容です。
公開に当たり、実際に利用した資料を一部編集しています。

「入門監視」を読んだ背景

ママリで年末に発生したとある問題は、とても厄介に感じる面がありました。
「初動で問題を除去するに至らなかったこと」「問題の解消に数時間を要したこと」「結果的に原因の特定に至ったが、綱渡り的な『アイディア』頼りであったこと」などが、「厄介だった」と感じられる主な要因です。

この事象は、チームの実情に関する多くの学びを残すものとなりました。
もちろん、これまでだって「しっかりサービスを守っていこう」「問題が生じ際には、ちゃんと対応していこう」という意識で一生懸命取り組んできています。
しかしながら、それでも「足りない」ものがあると気付かされました。

今回の件は単なる個別的な「障害対応」に留まらない、より抽象的・本質的な今のチームの課題を物語っていると個人的には感じられたのです。
大げさでなく「サービスの運用・監視についての1つの天井にぶちあたった」という印象があります。

結果として「もっと根本的・全体的な、姿勢や仕組みづくり不可避だな」という想いに至りました。
その最中に、「そういえば！1月に、面白そうなタイトルの本が出るんだった」という事が思い出されます。
それが、「入門監視」です。

この本は、「何かやり方を変えなければならない」と感じ実際に方策を練ってみるも、「これで本当に変わっていけるのだろうか？」とモヤモヤしていた私にとって、非常にシンプルで筋肉質なヒントを与えてくれました。

コネヒトの「監視」の歴史

今回の話を進めるにあたっては、コネヒトにおける監視の状況を共有する必要があります。
なので、ちょっと寄り道をさせてください。

入社当初のプロダクトチーム

2015年当時、エンジニアは

CTO(サーバーサイド・インフラ)
後のリードエンジニア(サーバーサイド・モバイルクライアント)

の2名がいるのみでした*1。
そこに私が、サーバーサイドエンジニアとしてジョインした形です。

サービスはしっかり伸ばしていたし、インフラも安定させられていたし、ユーザーに見える影響を及ぼすような目立った障害もほとんどなく。
少ない人数で「よくやっていた」のだと思います*2。
ただ、見方を変えたら「このサイズだからこそ」という面もあるのではないでしょうか。

サービス開発開始から変わっていない面子が、一緒に数年来やっている
(サーバーサイドに関しては)相互のコードレビューを通して、どちらも「知らないコード」は1行もない
フルAWS構成にした上で、AWSのサポートをゴリゴリに使っている
ディレクターポジションはProduct Ownerの1人のみで、距離を意識することが無い

これらのパラメーターは、「スピード感を持ってうまくやる」ために、かなりのアドバンテージを生み出していたはずです。*3

この輪の中に私が加わったわけですが、そこで起こる状況としては次のようになります。

「教育」や「組織(開発チーム)」という面では、かなりふわふわしている
- 独立・自律した個人の集合という状況
他方で、「新参者」が普段コミュニケーションをとる相手は「全てを知っている」メンバーのみ
- 何につけても「的を射ている」、自サービスに関しての「不完全」性が低い
- 全体にとって「必要なこと」は、自分の視界の届く範囲(n=2なのだから！)で行われている

つまり、コチラが意識をするせざるにかかわらず、環境が「猛スピードでキャッチアップさせてくれる」ように出来ていると言っても過言ではありません。

「監視」の領域に足を踏み込んだ

その上で、新規加入したメンバーとしては「手薄な部分を強化したい」という役割があります。
個人的な興味関心で歩み寄っていったのが「パフォーマンス向上」や「サービス品質向上」といった領域でした。
その一環として、スロークエリを潰していったり、アプリケーションエラーを減らしていったりの「負債解消」にワクワクしながら取り組んでいきました。

当時あまり活用されていた印象はありませんでしたが「Sentry*4を色々眺めてみる」ようなことをしたり、
インフラ担当であるCTOと一緒にCloudWatch Alarmをいじってみたり、
少し経ってからは外形監視に手を出したりもしています*5。

「やりたい！！」と言って手を挙げた時に背中を押してくれる環境は尊いものです。
ただ、「言えばできるんだから、見つけない・言わないのは甘えでしょ」と責任をメンバーに押し付けるのは決して正しくありません。

その点、私の場合は幸運でした。
「明らかに足りていない」「やるべき課題が目の前に転がっている」状況に放り込まれたようなものだったからです。
そういう意味で、当時の「小さいチーム」に下駄を履かせてもらっていたと感じます。

そこからスタートして、今に至るまで「チームの中でSentryに1番長く触っている」という自負がありますし、また弊社における「アプリケーションエンジニア」としての在籍期間は今や最長となっています。
そうした背景から、私は自ずと「障害対応に慣れている」・・言い換えると、相対的には「たぶん最も効率的に対応が行える」「問題切り分け〜対応完了までのハードルを1番低く感じている」という立場になっていたんだと感じました。

変動していく組織の中で「誰が」やれるのか、という問題

f:id:o0h:20190219000029p:plain

この「実は自分の立場が特殊なのかもしれない」というのは、恥ずかしながら「入門監視」を読んで気付かされた点でもありました。

上記の状況から、実は勝手に「監視の現場」のようなものに、私は足を踏み入れていた状況です。
では、そんな下駄の履かせ方は、「新しくチームに入ってきた人、何人目まで通用するのかな？」という問題があります。

監視は全員でやるもの(ってか、やろうと思えばできるでしょ？)

他の多くの書評エントリーでも触れられている通り、「監視は(SREやインフラに限定されず)全員でやるもの」というのが、「入門監視」の唱えているテーマの1つでもあります。
しかしながら、個人的には、正直これについてあまり目新しさを感じはしませんでした。
なぜなら、実際に「SREや、専任インフラがいない」という状況で立ち振る舞ってきため、
既に自己の経験をもって「アプリケーションエンジニアこそ監視をやるべき」と胸を張ってそのメリットを主張できるからです。

いかんせん、アプリケーションエンジニアは、他のロールと比べて、本来的に持っているドメイン知識やメトリクスの裏に透けて見えるユーザー行動への感受性が違いすぎるのです。

例えば、我々にいわせれば、
「急にRDSのコネクション数が上がったよ」という1つの情報だけを以て
「さっきリリースした /hoge/fuga エンドポイントのAPIで既存キャッシュのライフサイクルがアカンくなったかも知らん」「じゃあユーザー的に、アプリケーションの起動までは問題ないかもだけど○○の機能に遷移したときに、全員とまでは言わずとも、10回に1回くらい読み込みが遅くなってる可能性があるな」・・
というところまで直感するに足る要素が含まれています。

これこそ、「ユーザーとインフラの中間に立っている」「サービスとシステムの間に立っている」という、我々アプリケーションエンジニアの経験値からくるものです。
自身はアプリケーションサーバーに身を置きながら、ロードバランサからデータベースまで俯瞰できているようなもので、サービスの「見えている範囲カバレッジ」は非常に高いでしょう。
有している「判断材料が多い」「総合性が高い」という点で、とても有利なのです。
これはロールのもたらす特性です。

私にとっては、この「見え方」が当たり前の世界でしたので、
「普段、サービス開発に携わっている身からしたら、1つもしくは複数のメトリクスを手繰り寄せて、何が起きているかをイメージする」
という態度は、何も特別なものでないと感じていました。
ゆえに、「監視は全員でやろう」は同意しかないし、枯れた視点だったのです。

その上で、だからこそ、「入門監視」で触れられていた 手順書 というコンセプトは非常に衝撃をもたらしました。

手順書というコンセプトと、「スキル」としての監視

これは、 特定のサービスについて以下のような質問に答えるように書かれたもの と説明されています。

これはなんのサービスで、何をするものか。

誰が責任者か。

どんな依存性をもっているか。

インフラの構成はどのようなものか。

どんなメトリクスやログを送っていて、それらはどういう意味なのか。

どんなアラートが設定されていて、その理由は何なのか。

(『P38 3.1.2 手順書を書こう』)

本書の「付録A」にサンプルが紹介されているのですが、例えば以下のようなものです。

アラート: 記事の作成時間が長すぎる
このアラートは、ユーザーの記事作成時間が1秒を超えた時に発報されます。
直近の不正なデプロイか、PostgreSQLのパフォーマンスに問題がないか確認してください。

ここに書かれている内容は、日常において私が「想像している」と感じていることに相違ありません。
今まで「アプリ書いてりゃイメージつくようなるっしょ」と決めつけていた内容が、「形式知化し、チームメンバーにインストールするべき事柄」と書かれていたのです！

私にとってそれは、

お前がそれを『当たり前』と呼んでいる限り、お前がチームの癌になるし、少なくともお前が望んているような有機的で自律的な監視・運用を行えるチームになんてならないぞ

と、Mike Julian氏と @dblmkt 氏が語りかけているような気すらしました。

「アプリケーションエンジニアが監視もやっているんだから、うちは監視が役割になったりなんて、していないよ」という私の思い込みとは裏腹に、
監視が「スキル」になりきらずに、属人性の高い、実質的な「役割」化されて偏っていたといえます。

関連して思い出すのは、件の障害の振り返りミーティングを年末に実施した際に受けた発言です。
私が「これから監視体制を見直していきたい点・やり方」の草案を共有すると、サーバーサイドエンジニアの同僚から

障害対応の可能な人員を増やしていくにあたって、『あるメトリクスが増減したときにそれをどう読み解くか」というのを言語化・共有できないか

という指摘がありました。
その時は、正直に言ってあまりピンと来ていませんでした。

しかし、この「手順書」のやり方を見たら、確かに「誰でもできる！というには難易度が高いのかも知れない」と気付かされます。
それを他人に配布していくには、シンプルな方法で、的確にやっていく必要がありそうだ・・というオチでした。私の「何となく」は、「アーキテクチャからサービスの提供内容や機能といった立体的な理解が必要」なスキルのようなものだったのです。

なんで、私が老害に！？

f:id:o0h:20190218235902p:plain

繰り返しになりますが、
私がこれをできたのは「いろいろなものを実際に自分の手触りとして覚えてきたから」に過ぎません。

いま、コネヒトのエンジニアは、インフラ・クライアントサイド(ネイティブ、Web)・サーバーサイドで10名を超えています。
サーバーサイドのプロダクトに限っても、「全てのレポジトリに触れたことがある」のは私を含め2名に留まります。
社内ツールも数に含めると、全て触れているのは「たまたま古くからいて、PHPが好きだったので」という理由で私が該当するのみというのが現状です。
ここだけを切り取ってみても、「今までのやり方を見直してみるべきだ」という黄色信号が点灯しているように思います。

おそらく、もう「何でも屋」はこの組織に入ってこないでしょう。
もちろんWeb系エンジニアは領域横断のハードルが低いので、スキルやポテンシャル的に「何でもできる」人材は少なくないはずです。
ただし、「社内のあらゆるプロジェクト(リポジトリ)に馴染みがある」という状況が生まれるか？というと、全く別の論点です。

では、そうした未来において
自分のような「環境が下駄を履かせてくれる」恩恵を受けながら「ｶﾝｼﾁｮｯﾄﾃﾞｷﾙ」人員が発生し得るのでしょうか？

持論ですが、監視や障害対応は「知識」と「実務経験値」の総合格闘技だと思っています。
性質としてはデバッギングなどと近いでしょう。
「ここが怪しい」とか「これで切り分けよう」などというのは、
深い知識があるか、身体で覚えているかというパラメータに大きく左右されます。

そこで、そもそも「知識」のカバー範囲が広く「実務経験値がある」メンバーが前線に立ち続ける*6というのは・・・・どんな状況を招くでしょう。

これが、私がスライド中で、あえて「老害」などという極めて強い言葉を用いて表現したかった状況であります。

私はずっと「サービスの安定性は十分に高いが、チームとしての監視・障害対応のレベルは決して十分でない」と感じながら過ごしていました。
この状況は、とても皮肉なことに、「私こそが、アクションして打破していくべき課題だった」ということに、「入門監視」を通じて気付かされたのです。
正当な進化の道筋に、自分が立ちはだかっているのだと感じました。

さて、気づいてしまえばやるべき事は1つです。
いま「先頭」っぽいところにいる自分が、仲間たちと手を取りこの先の旅路に就くことです。

監視を「スキル」化し、「民主化」していくために

f:id:o0h:20190219000328p:plain

ここまで(そしてスライド中でも)何度も「スキル」という単語を使っていますが、
これには次のようなニュアンスがあります。

役割(ロール)」の対立軸としてのスキル

監視アンチパターン「役割としての監視」に対して、「スキルとしての監視」を推奨しています。
アプリケーションエンジニア、ネットワークエンジニア、データベースエンジニア・・・サービスの開発運用には色々な「役割」がついて回るものです。
本書では、 監視の旅へ進むに当たって、皆が監視について責任を持つ事を主張してください。 と語られます。
大前提、監視とは「サービスが動いているかを監視する」ことに他なりません*7。
そして、サービスとは、複層的で複雑な構造の上に成り立つものなのです。
「特定の誰か1人」隅々まで全容を把握するのは非現実的でしょう。

そのため、チームの全員が「一定度以上できるようにする」事が不可欠になります。

「サービス全体が正常に動いている」というのがどのような状態であるかを共通理解とし、
飛んできたアラートと、それが意味する状況についても共通理解をした上で、
自身の主たる守備領域における「原因探索」もしくは「影響の考察」を行い、
これらの情報を綜合していくことで効率的で有機的な対応が成立するでしょう。

習得可能な事柄としてのスキル

スキルという単語は、「教養や訓練を通して獲得される、実務を遂行可能とする能力」と説明されます。
本書において、監視が「スキル」と表現されているのは個人的には非常に希望であり、他方でプレッシャーのようなものを覚えました。

すなわち、「監視」とは「チームとして、明確に、各メンバーが実行可能になるように支援し引き上げるべき対象」ということになります。
例えば「CakePHPを使っているチーム」において、「一緒にレポジトリをいじるメンバーが、CakePHPを使いこなせるようにしていく」のは、もはや義務であるといって過言ではないでしょう。また、周りのメンバーもそのように支援し、協力していくはずです。

「チームにとって必要なスキル」というのは、習得する努力は必須です。
それと同様に「やれる人」から支援を行い適切なレベルデザインを行い・・・という意味でも「できるようにする」のは使命だと思っています。
まして、「監視」というのは「各領域のプロフェッショナルが協力して行う」べきものです。
インフラやオペレーションに近い職務を担う人が「たまたま監視にも親しみがあった」というだけでは、監視が一部の人の「特殊スキル」になってしまいます。
(今のコネヒトも黄信号です。)
これを、ちゃんと「取得できる」「取得させる」スキルへと転化していくことが、重要なのではないでしょうか。

最後に: 「入門監視」はどのような本だったか

f:id:o0h:20190219031519p:plain

私はこれまで、実際にプロダクトの「監視」をやってきました。
重要な障害対応にも取り組んだし、CloudWatchのダッシュボードも作りました。アプリケーションの健全性のようなものをレポーティングしたことだってあります。

それでもなお、この一冊を読んで「私(たち)は、監視というものに入門する必要がある」と感じています。
それは、「監視とは何を目的としたものか」を定義し、「ユーザー(との接点であるサービス)にどのような効果をもたらすか」のゴールを掲げることに他なりません。
1つの方向を向くことをスタート地点とし、「民主化」された監視を実現していきたいのです。

現状のチームにおいても、「できていること」や「伸ばすべき芽」はあると感じています。
きっと、世の中一般の「偏差値50」を高く超えている点もあることでしょう。
また、本書の内容は一部「極端かもしれない」と感じたり「これはすぐには真似できなそうだ」と感じられる部分もゼロではありません。なので、単純な猿真似を目指さず、本質的な理解に迫りたいと考えています。
総じて、活かすとこは活かしつつ、反省すべきは反省しながら、ウチはウチとして、強力な安心監視マインド&体制を作っていきたい所存です。
やらなければ・正さなければならない事が何個もあるなかで、我々は「スキルとしての監視」に取り組んでいきたいと思います。

多くの方の書評記事・感想レポートにもありますが、
改めて、私個人としても「全(クライアントサイド|サーバーサイド|インフラ)エンジニアやテックリード、SREが1度読んでみてほしい！！」と感じられた一冊でした。
もし「読もうかどうか迷っている」という方がいましたら、ぜひ手にとって見ることをオススメします！！

f:id:o0h:20190219000728p:plain