「グリー開発本部 Meetup #3 モニタリング」行ってきました
先日『入門 監視』を読み終えた直後かつ業務的にもモニタリングを設定しているところで、モニタリングが熱いのでこちらの勉強会に行ってきました。
詳細な内容はそれぞれスライドが公開されていますので、雑感を軽く。
アラートを減らしている話
GREE 小林 裕明さん @kobtea
『入門 監視』でもモニタリングを進めたら、その中でやることの一つとして、自動復旧に触れられています。GREEでの実践についての話でした。
所感とよかった質疑応答は以下
- アラート管理のミドルウェアが自前であるのが印象的。羨ましい
- 復旧の手順書から自動復旧手順を考える、という流れは地道で素敵だった
- 自動復旧はあくまで恒久対応ではない。忘れないようにしたい
- 自動復旧の実装はシンプルに。これも重要。つい凝っちゃう気がする
- 質疑応答
質問：自動復旧はどのくらいやったのか
回答：数は多くないが、対処できたアラートの数は非常に多い
自動復旧というちょっと印象的な項目の地に足のついた実践を見せていただきました。
監視の目的とは何か問いかけよう
GitHub 松浦 隼人さん (『入門 監視』訳者) @dblmkt
入門監視を訳すまでの流れと監視に興味を持ったきっかけ、入門監視のポイントを説明でした。
以下、所感。すでに読み込んでいたので少な目ですが。
- 入門監視 すでに4刷。すごい！
- 監視とバックアップは似てる。普段気にしない。いざという時に困る。しかも動かない。わかりすぎる。
- 入門監視の中でも、監視担当を作るな、という提言はやはり刺さる。書籍の中ではインフラ部門の人が担当になるから、アプリケーションの人も見るべき、という流れですが、アプリチームもKibanaなりNewRelicなりで見てても、決まった人が対応してる、というのはあるあるなような
sysloadや監視などの話
GREE 瀬島 貴則さん
社内監視基盤についての思い出話から、独自メトリクスsysloadの話まで。
所感は以下。
- 圧倒されました。低レイヤまで本質的に理解しているエンジニアの強さを思い知りました。メトリクスがおかしかったら、カーネルのコードを追い、メモリ処理の正確な理解から、問題となる処理のあたりをつける。かくありたいものだなあと。
- 本質的に理解をしている人ならば、原因の本質に迫るために数百のメトリクスも必要になる。これは目から鱗。自分ではメトリクスは絞るべきだと考えていたので。ただ、そのために自分含めレベル上げが必須
- 紹介されたsysloadはそういったまだレベルが足りない人のためのメトリクスだった。機会があれば使ってみたい。
それぞれ別のレベルでモニタリングについて話が聞けて面白かったです。GREEの運営の方々もありがとうございました。
うちの会社から自分以外にも二人参加していて、初めて顔を合わせたのでプチオフ会見たいで楽しかったです。次回はちゃんと社外の方とも交流したいところです。
『入門 監視』読んだ
- 作者: Mike Julian,松浦隼人
- 出版社/メーカー: オライリージャパン
- 発売日: 2019/01/17
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
タイトルの人聞きが悪いことでも有名ですが、すでに巷で言われているように良書です。
本書の概要
全体は大きく分かれて二部(付録も入れると三部)に分かれています。
- アンチパターン、デザインパターンといった監視の考え方を伝える第一部
- ビジネスからアプリケーション、サーバーの具体的な監視手順について触れていく第二部
- はてなの松木さんがMackerelを中心に、監視SaaSの考え方、使い方を説明してくれる付録
といった形に分かれています。
なので、まだ読んだことない人はまず第一部だけでも読むといいんじゃないでしょうか。せいぜい60Pくらいですし。
個人的には、監視についてわかった気になっていたことや、漠然と考えていたことがスッキリまとまっていて、監視についての考えがかなり整理できて良かったです。
スッキリまとまりすぎてるくらいなので、日頃監視をしている人の方が飲み込みやすいかと思います(メトリクスのダッシュボードを眺めるのが日課な人とか。本当に毎日見る必要ある？)。
特に良かったところ
アンチパターン：チェックボックス監視
なんとなく設定して、それでOKとしてしまっている監視を、「チェックボックス監視」と呼んで、本書では批判しています。
意味があるかわからないけど眺めているCPU使用率や、毎日手動でチェックしているElasticSearchのエラーログ、そんなものがあったりしませんか？
僕はかつてやってました。なんとなく仕事している気にもなってしまいがち、こういった実は無意味な作業に気づくことができるのも本書の良いところです。
デザインパターン：ユーザ視点での監視
監視を設定していく時に、どこから設定していくか。
ついついアプリからやりがちなんですが、本書ではユーザー視点側から設定していくことが提案されています。
確かにその通りです。本当に影響があるのはユーザー視点(例えばサイトが落ちてる、表示速度が遅い)であって、アプリケーションで起きている問題(例外処理ミス、メモリリーク)というのはその原因でしかありません。問題自体を検知するならば、ユーザー視点に立つべき、というのは当然の考えです。
ユーザー視点からはじめ、アプリやサーバー、DBへと順に設定していくわけです。
設定の優先順位決定にも役に立ちますし、かなり良い考えだと思いました。今すぐにでもチームに取り入れられるのではないでしょうか。
まとめ
とても良い本なので、チームに一つ置いておくくらいでいい本です。
第一部だけでもエッセンスが詰まっているので、まずそこだけでも読んでみてください。
この話を前提にシステム設計・運用ができると幸せになれそうなので、広く読まれてほしいと思っています。
スクラム運営に失敗した話
はじめに
スクラムマスター始めましたを書いて半年で失敗しました、という話をするのは大変かっこ悪いのだけど、事実なのでどうしようもない。
チームでのスクラム運営に失敗した。
ベロシティは上がらず、スクラムへの不信感は募り、チームは解散とまでは行かないが空気は悪くなった。
今はスクラムではなく、カンバンで開発を進めている。
自分もスクラムマスターをやめて、ただの開発者をやっている。
失敗したままにしておいても仕方ないので年末らしく反省をする。
主な失敗の原因
チームのスクラム理解
メンバーのスクラムに対するモチベーションによって変わる部分かなと思う。
自分のチームの場合、スクラムをやることで複数のスクラムイベントで開発を阻害されると感じた人間が多かった。
とりあえずはじめてみればわかるよでやってみたが、イベントは邪魔という観念が拭えないままになってしまった。
チームにスクラムの価値をしっかり説くところから始めるべきだった。
社内の他チームの話を聞いたところ、スクラム開始前に毎日五分間スクラムについてを説明し続けたというスクラムマスターがいて、そういった手順を取るべきだったと思う。
スクラムのプロセスにこだわりすぎた
各種イベントを実施し、しっかりイテレーションを回していくことがスクラムだとこだわりすぎた。
最初のチームの理解度の話にも繋がるが、いきなり全部を完璧にやろうなんていうのは無理な話だった。
あれもこれもとなって、自分の準備もチームの理解も半端なままになった。
失敗を踏まえた結果、スクラムで本当に重要なのはレトロスペクティブ(ふりかえり)だと考えている。
きちんとふりかえりで反省し、次のスプリントがさらに良いものになっていけば、チームも良い雰囲気で開発していけたかもしれない。
今ならば、レトロスペクティブだけ取り入れて、他は徐々に進めていくようにすべきだと思える。
開発を一切せず、スクラムマスター業に集中した
初めてのスクラムマスターだからと気負って、教科書的に開発を一切やらなかったが、これがむしろよくなかった。
熟練したスクラムマスターならばよかったかもしれないが、少なくとも新米がやるべきことではなかった。
結果として、チームの生産性にポジティブな影響を与えられず、チームからはむしろ開発に入ってほしいと思われ、自分でもこんなことをしてていいのかとメンタルに負荷を感じることになった。
プロダクトリリース期限をある程度意識せざるを得ない環境でも合ったため、チームは『Elastic Leadership』でいうところの「サバイバルモード」に入っていた。
この状態で新しいこと(=スクラムの導入)は挑戦的すぎた。
自分も開発を行い、チームから信頼を得ながら、なるべく早くチームが「サバイバルモード」から抜け、その上でスクラムを実践していくべきだった。
最後に
振り返ってみても、初めてのスクラムマスターということで正直気負っていたなあと思う。
その結果として、チームをいい方向に持っていけず、チームメンバーには本当に申し訳なかった。
今、チームはずっとうまく回っていると感じる。自分としても開発者として力を発揮できている。
スクラムマスターとして意識していた、チームの働き方や周囲へのアウトプットの見せ方は引き続き意識できていると思う。そういった経験を使って、チームメンバーにはお返ししていきたい。
スクラムマスターになって三ヶ月経った
技術記事はQiitaに書けばいいが、ポエムや読んだ本の感想をまとめる場所が欲しいのでブログを作った。
最初なんでポエムを書いとこうと思う。
三ヶ月前からスクラムマスターをやっている。
最初は開発者と兼任でやっていたが、半端なスクラムマスターなら必要ない、専任するか決めてくれとリーダーに言われて、専任することにした。
その時はダメだったら戻ればいいや、という気持ちで始めたが(それは了承してもらっていた)、今はもっとちゃんとできるようになりたいという思いが強い。
やってみて得られるものが多かったからだ。特に視野の変化が大きい。
まず開発に対する視野。
開発環境をよくするために必要なことは、実装技術を上げることだけではないと身にしみた。
タスクの見せ方や完了条件の整備、そんなことを変えるだけでも開発はしやすくなる。
仮に開発に戻っても、自分たちの開発環境をよりよくするために何が必要か、広いアプローチで考えることができるようになったと感じる。
次にコミュニケーションの視野にも変化があった。
スクラムを数回進めていくと、メンバーごとに理解していない点があることが見えてくる。
スクラムイベント内で何をすべきかだったり、プロダクトバックログの捉え方だったり、人によって異なる。
チーム内でスクラムを浸透させるためには、その理解していないポイントを知って、理解してもらえるようにアプローチを考えなければいけない。
そのように個別のメンバーにアプローチをすること、そもそもアプローチを考えることというのは新鮮だった。
開発者として何かの技術を広める場合、自分のコードで表現すればいいし、必要に応じて広めていけば十分だったからだ。
人に何かを理解してもらう困難さ、そしてそのためにインセプションデッキなどの多くのプラクティスを勉強する必要があるのだと知れたのは有意義だった。
色々よかったと書いてきてはみたものの、まだまだ力不足だ。
チームに本当の意味でスクラムの価値を浸透させるにはまだ至っていないし、メンバーの質問にとっさに正しく返せないこともしょっちゅうある。
プラクティスを適切に取り出すほどの知識も足りない。
この仕事をやっていくのに必要ないろんな能力が足りていない。
自分を客観視すること、新しい手札をしっかり使えるようにするため理解し直すこと、そういったことのために、読書や考えたことのまとめを書いていけたらと思っている。
