00:00
お疲れ様です ユルテック第9回 始めていきましょう ソフトウェア
エンジニアをやっている博多家 です
お疲れ様です ソフトウェアエンジニア をやっている三長です
よろしくお願いします
よろしくお願いします
今回は自己紹介がソフトウェア エンジニアなんですね
言われると思いました 前回確か エンジニアリングマネージャー
って言って 前ソフトウェアエンジニア って言ってなかったっけなと思
って反省して 今またソフトウェア エンジニアに戻しました
いや自分はあれだと思いました 前回がEMっぽい話題だったから
三長さんもしかして話題によって 帽子かぶり直しとるなって思い
ながら聞いてましたけど
そんな高度なこと今言われるまで 全く気づかなかったですね
やばいちょっと何も考えてなかった のがバレましたね
今回がちょっとエンジニアリング っぽい本を読みましたみたいな
内容だから そっちで来たかと思ったん ですけど
うんまあでもそこに気づくのは さすが博武さんだなって思います
ね
流しましたね
はい
じゃあ行きますか
はいお願いします
今回もその日常ネタがなかったん で本を読みましたシリーズで
行くんですけど
はいはい日常的な本が出てくるん ですね
いや違いますけど
これいつ出たんだろう春ぐらい かな4月か5月ぐらいに多分出たん
ですけどオブザーバビリティ エンジニアリングっていう本が
出たんで
おいいタイトル
はいなんかめっちゃがっつり読ん だわけじゃなくて結構斜め読み
したんですけどねなんでかなり 浅い内容になりそうですけど
ほうほうほう
じゃあ全体的に最初にその感想 を言うと
はい
オブザーバビリティの話がほとんど ですねそのまま本のタイトル
なので
はい
でこの本通して結構オブザーバビリティ ってこういうもんだよとかその
従来のモニタリングいわゆると この辺が違うんだよみたいなこと
が結構繰り返し書かれててですね
そうなんですねほうほうほう
なんでなるほど確かにそうだな みたいな感じでオブザーバビリティ
ってどういうものかって改めて 理解できたっていうのが大きな
感想ですかね
結構あのオブザーバビリティ大事 だねとかオブザーバビリティ
って言葉がここ数年どこですか ここ2,3年どこですかね私の感覚
だとここ2,3年な感覚なんですけど
いろんな資料とか書籍で出てくる ようになったからなんかついに
そこについて深く語ってる方が 出てきたんだなって印象ですね
今聞いてて
そうですね自分が最初にそういう の聞いたのはどの辺だろうななんか
入門監視が多分出てきたら辺だった かなっていう記憶なんですけど
そう実はあの今博多家さんが入門 監視っておっしゃってたじゃない
ですか私も入門監視読んでいて で今博多家さんがそのオブザーバ
03:05
ビリティエンジニアリングは監視 とはちょっと違うみたいなお話
されてて入門監視って英訳する と何だろうなって思ってちょっと
調べてたんですけど
あれ現聴あれですよねプラクティカル モニタリングかななんかそんな
感じですね
そうそうそうそれですそれです なんかそれでって言うとそのモニタリング
って言ってるからちょっと違うん ですかねそのジャンルというか
うんそうでも多分あの入門監視 に書かれてることもまあ結構オブ
ザーバビリティだと思うんでこの 辺はやっぱりこの2,3年でだから
その言葉の定義が洗練されてきた というか固まってきたんです
かねどうなんだろう
そんな気がするあるいはオブザーバ ビリティっていうその大きな何
だえーと範囲の中に監視も含まれてる のかそれともオブザーバビリティ
と監視は別々の領域で重なり合う ところもあるのかどういう関係性
なんだろうなっていうのはちょっと 興味ありますね
一応この本の中では自分のその 感触ですけど一応別のものとして
扱われてましたね
なるほどなるほど
ちょっとあれかもしれないですけど ねそのビジネス的なやっぱあれも
あるのかもしれないですけどね この新しい我々が提唱するこの
概念はその従来のものとは違うん だってやっぱりこう言っていく
のも大事だと思うんで
確かに
そういうところもあるかもしれない ですけどね
なるほどねほよほよ
でなんかそういう話が結構多くて その従来とどう違うかじゃあその
オブザーバビリティって何なのか どうやってやっていくのかっていう
そうですねあの具体的なhowっていう よりは抽象的な話が結構多かった
です
うんうんうん
うんでもまあ逆にそのいいところ としては今までやっそのいわゆる
オブザーバビリティエンジニアリング をやってなかった組織がやるには
こういうとこから始めていくと 良いとか
ほうほうほう
なんかあの後の方でちょっと話 しますけど
うん
オブザーバビリティのroiとかまで ちゃんと書いてあるんですよ
あそこですよねあんまり聞いた ことないですよねそういうのね
なんでなんかその辺も結構意識 して書かれた本だなーっていう
のは思いましたね
うんうんうん
じゃあどうしようかな感想をちょっと ざーっと書いたんで読んでいきます
かね
あじゃあお願いします
はーいえーとじゃあ1個目がえっと オブザーバビリティって何ですか
みたいなのを端的に説明した文章 ないかなーと思って探したんですよ
一応
はいはいはい
それで一応多分これが一番端的 に書かれてたことかなーっていう
のがそのシステムがどんな状態 になりうるかをどれだけ理解して
説明できるか
おー
それが例えばどんな状態になりうる かを完璧に説明できればオブザーバ
ビリティめっちゃあるみたいな 意味ですかね
06:01
じゃあ例えばどうだろうなこの ウェブサイトはこの後アクセス
できなくなりますなぜならばこの 数値とこの数値とこの数値がこういう
ふうに上がってこういう傾向になっている からですみたいな感じなんですかね
そういう感じですかね
うんうんうん
なるほど
なんかあれでしたね今回のメモ には書いてないかな従来のモニタリング
は基地の道を扱っていてオブザーバ ビリティは未知の未知を扱うもの
って書いてありましたねメトリクス ベースのモニタリングだと過去
に起きたことしか判定できない 過去例えばcpuの使用率がこんな
感じだった時にはこういう障害 が起きたとかってそういうふう
な判断しかできないけどオブザーバ ビリティはいろんなこれもテレメトリ
っていう言葉も難しいんですけど テレメトリからこういう状態になる
っていうのを判断できるみたいな ことが書いてありましたねそう
この辺難しいんですよねすごい 何章も裂かれてるんですよ説明
に
なんだかそれを今聞いてて私の そのオブザーバビリティの定義
というか高めていくイメージって モニタリングの延長線上にある
ものだとずっと考えていたんですよ それはモニタリングに対してう
だループを何回も何回も回して いってどんどんどんどんオブザーバ
ビリティが高まっていくものなの かなって思ってたんですよね今の
話を聞くまでだからその未知の 未知を見つけるってイメージが
まだ湧いてないというかどうなんだろう こういうデータが今見えていて
じゃあ例えば異常値にはなってる っていうことがわかったとして
これは何か起こる傾向な兆候だな みたいなことがわかればオブザーバ
ビリティ高いよねって何ならるん ですかね
それも多分一例としてあって説明 の一つにAIOpsも出てきたんですよ
なるほど
はいつまりハズレ値みたいなの を検出できることもオブザーバ
ビリティの一つなのかなっていう 感じですね
難しいですねなかなか
難しいですね
しっかりとモニタリングとオブザーバ ビリティを分けて理解する必要
があるかどうかもちょっと怪しい ところではあると思うんですけど
ここで自分が一番この本での分け 方としてそういう分け方なので
一番しっくりきたのはどこだった かな
09:01
これだこれだ従来のモニタリング だとインフラの健全性を評価
するのが得意オブザーバビリティ はソフトウェアの健全性を評価
するのが得意っていう向き不向き があるんだよっていう話でしたね
そうなるほどそういう意味だと あれかじゃあ自分がこれ例えば
私たち私たち私がこれまで捉えて た監視って勝手にソフトウェア
も入ってたから実はそこって一部 途中からオブザーバビリティ
なんだよってなってるのかもしれない ですね
そうですね
なるほど
だから従来の監視っていうのが つまり単純なメトリクスによる
監視みたいなことを指してるので レイテンシーだとか例えばcpu使用率
とかローダービリッジとかそういう もののことを指してるのでそれが
どれだけその組織にとって必要 かっていうのはなんかあれでした
ねインフラをどれだけ管理している かによるって書いてありました
ねだからクラウドを使っていて なんかそこまでめっちゃ管理して
いなければそんなに必要ではない みたいなあのあれですねオンプレ
とかで例えばストレージの状態 をめっちゃ監視してなければいけない
とかそういう人たちにとっては 従来の監視もとても重要って書いて
ありました
納得なるほどですね
あとは何があったかなあそうちょっと これ三長さんが好きそうと思った
オブザーバビリティーはこういう プラクティスをやるときにはもう
大前提の条件になってるよみたいな のがあってそこにちょっと画像
貼ったんですけど
好き好きかもしれない
カオスエンジニアリングとfeature flag のパターンですねとプレグレッシブ
リリースですねカナリアとか使う やつとかあとインシデントレスポンス
とかあとはポストモーテルもやる ときとかこういうのやるときには
もうそもそもオブザーバビリティ がちゃんと確保されてないと十分
にこのプラクティスはできません よねっていう感じですかね
確かにそうですねそして今はく たけさんが紹介してくれたこれら
のプラクティスの前提ですよっていう ところで結局これらのプラクティス
も結構ソフトウェアに対するところ が多いプラクティスかなって思
っててソフトウェアに対する部分 が多いプラクティスだからそれは
オブザーバビリティってソフトウェア の健全性を評価するのが得意なんだ
なってちょっと鶏卵でどっちが どっちなんだろうってところが
あるんですけど少しだけ繋がった 気がします自分の中で
こうやって例を示されると確かに そうかって感じになりますね
確かにオブザーバビリティで見 れるデータがないことには確かに
12:01
今言ったプラクティスってやって みたところで主観でしかもう全部
物事語れないようにで終了です もんね
そうですねプログレッシブデリバリー とかも完全にそうですよねカナリア
とかやるときも成功とか失敗切り戻し の判断とかどうするのみたいな
そういえば前にした気がするんですけど この話
しましたねそれとかも完全にオブザーバビリティ が前提になってますよね
逆にこれらをやりたいってなった ときにきっと課題というか必要な
ものとして上がってきますよね じゃあこういうデータ取れない
と判断できないよねとかじゃあ まずここから始めましょうになり
そうな気がする
うんなると思いますで次に気になった とかでもそういう監視というか
従来じゃない監視オブザーバビリティ と言われるものがない組織の方
が結構やっぱり多いと思ってて そういうのをやろうと思ったときに
どうするといいですよみたいな 話もちょっと書いてあったんですよ
これはすごく興味深いですね 結構いろいろ書いてあったんですけど
自分の中でとりあえず頭に残った のはここですかね最大の問題を
解決するところから始める
最大の問題
はいえーと何だろうな例えばリリース の後にこういうことがあったときに
どこがボトルネックになっている のかを把握したいっていうのが
一番の問題だとするじゃないですか いつもリリース後に障害が出て
困ってんだよねとかがそのチーム の抱えている最大の問題ならそこを
解決するところから始めるのが 良いみたいな感じですかね
じゃあそこを解決するために例えば じゃあ何が分かると解決につながり
そうかっていう多分仮説とかも 立ててじゃあそれが分かるための
オブザバビリティを高める仕組み を入れましょうみたいな感じですか
ね
そうですねそれをやると効果も すぐ出るし最小のコストで始められる
コストも小さいし目的意識も高い ですよねきっとね最大の問題なので
そうですね導入のそしてモチベーション もあるしなんでいきなり全部基盤
を作りましょうみたいなところ から始めるのはダメって書いて
いましたね
これちょっとタイムリーなんですけど ちょうどここ1週間ぐらいで少し
エンジニアじゃない組織の人と ちょっと話をする機会があって
その人があるシステムで毎朝この 時間になるとちょっとビジになるんですよ
15:00
みたいなそこに対してエンジニア に調査してもらうのが今一番時間
割かれてるんですって話をして くださっててこの調査をまず終わら
せないことには他のことを始め られなさそうですって話になって
その時にちょうどアドバイスした のがじゃあ確かにそれを解決する
のが最優先かもしれないけど今 手持ちのカードが出ただけだと
多分それの状況が全然わからない し解決するまでめちゃめちゃ長い
道のりになりそうだからそこの 事象に対してもう少し取れるデータ
増やしてみませんかって話をしたん ですよまさにもしかしてこういうこと
なのかなって今思いましたね
完璧な対応ですね
私が入れたわけじゃないんですけど ねじゃあすぐ入れましょうっていう
話にはちょっとなってるのでこれ に近い話だったのかなって
思います
いいですねいいですね
なるほどね
そこからやると始めやすいし理解 も得られやすいってとこもある
でしょうしね
そうですね
このキャッチーなキーワードがあ ったんで置いてみたオブザーバ
ビリティドリブンデベロップメント なんですけど
ODD
ODDですねオブザーバビリティ 駆動開発これ言いたいこと自体
は分かるんですよここで最初に TDDがテスト駆動開発ですね例に
出されててフィードバックループ が速いっていうのがメリットの
一つとしてあると思うんですけど これもそうですね要するにオブザーバ
ビリティが確保されてないシステム だとリリースとかがすごく怖い
ものになってしまうここでガラス の城とかって書いてあったんですけど
おしゃれな表現ですね
なのでリリースも遅くなってしまう でもオブザーバビリティが確保
されていればリリースしてもすぐに それエラーとかがあっても気づける
のでそれこそすぐ切り戻しとかも できるなのでそこで得た情報を
もとにまた開発することができる っていうふうな意味でオブザーバ
ビリティのシフトリフトって書いて ありました
言いたいことはすごく分かりました 言いたいことは今すごく伝わって
きたんですけど実践する場合って どうなんだろうって今ちょっと
考えていて
そうですねこれだから多分システム の性質によるなと思ってて
そうですよね
つまりこれはある程度のエラー を許容できるシステムならこれで
バンバンいけると思うんですよね
おっしゃる通りだと思います
18:00
バンバン出して例えリリースが 失敗で何らかまずいことになって
もすぐシステムは切り戻される しそれでまずかったらそれ直して
またリリースすればいいじゃん みたいな考えがゼとされる環境
であればこれが最大限生かされ そうですよね
そうですねでなんか聞いてて例えば 本番環境に限った話で本番環境
に限らなくてもいいかもしれないん ですけども限ったケースでいう
とすごくこのオブザーバビリティ ドリブンディベロップメント
って結構ポストモーティングと セットが基本になりそうだなって
思って聞いてて
確かに
ただ本番じゃなかったら別にって ところありますかねもしかして
そうですねここでこれの前段で ちょっとコンテキストがあって
本番環境でしか発生しないこと っていうのがたくさんあるので
そんなにテストを重ねても本番 環境でのテストには勝てないみたいな
文脈の話がこの前にあるんですよ ね
ちょっとわかりますそれはそうですね
なのでやっぱり本番環境はすごい 複雑なのでそこにリリースして
みないことには実際それがどういう ことが起きるかわからないっていう
まず前提がありかつ本番オブザ バビリティが確保されていれば
本番に出せばどういう影響がある か確実にわかるのでそうするの
が一番妥当な方法でしょみたいな 気結になるんですよねこれ
じゃあデフォープスのケイパビリティ がそこそこに高い状態からじゃない
とどうかな高い状態じゃないと 始めるのって怖そうだなって印象
になっちゃうんですね
それも書いてありました
そうなんですね
ただしこれはやっぱり果敢属性 が確保されててsreとかデフォープス
とかの文化がちゃんとあるチーム ができますみたいな
次のステップですねそういうの とね
そうですそうなりますよねそう なるとね
そうですね最後の方にこれさっき ちょっと話しましたけどオブザ
バビリティのroy投資対効果ですね が書いてあってオブザバビリティ
が高ければさっき言ったみたいに チームの安心が高まるというか
そういうことによりリードタイム が短くなりますと頻繁にリリース
されるので
挑戦しやすいって言ってもね
はいなのでそういうふうに新しい フィーチャーをリリースが一番
頻繁にできるということはそれ だけレベルを得やすいというの
が一つとあとはもうコスト削減 効果がありますよっていうのが
3つポンポンポンって書いてあり ましたねインシデント対応が早
21:03
くなる
mtddとか
そうそうそうインシデントが回避 されるあとは従業員の離職率が
下がると
前々回ぐらいでしたっけ博多家 さんがレポートを紹介してくだ
さってたのデボブレポとかあの中 で確かあれセキュリティでした
っけリライアビリティでしたっけ 確かセキュリティだったと思
うんですけどセキュリティに取り 組んでいるチームはそうじゃない
チームに比べてバーアウト率が 低いみたいな話ありましたよね
そうそうここでもそれ出てくる なと思いましたここもバーアウト
があったんで
そうです何か
海外の人はそんなにバーアウト するのみたいな気持ちがあるんです
けど
逆にそのソフトウェアを作るだけ じゃなくてやっぱ安全安心に運用
できることがバーアウトしない 秘訣みたいな感じなんですかね
そんな感じしますねそうこれ文 中にも結構アクセラレートのこの
state of devopsのレポートリンクも あったんですよ
あそうなんだ
はいあるしなんか全般通して多分 さっき水田さんがおっしゃった
とおり主張が大体似てるんですよ ね
なるほど確かにであと今博多家 さんの紹介してくださった話ROI
の話を聞いてて少し思ったのは これもアクセラレートレポート
の中にもあるんですけどこれまで よく言われている4Kメトリクス
あるじゃないですかあれ4Kメトリクス のことに対して説明を聞いている
ようにもちょっと聞こえてて
確かに
なんか重なってますよねちょっと これね
重なってますね確かにな
4Kメトリクスのあれなんだっけ な確か障害復旧失敗率と
デプロイ頻度とリードタイムと
タイムトゥリストアーか復旧時間 と
変更障害率ですね
うんここからオブザーバビリティ が高いとオブザーバビリティ
が高いとかオブザーバビリティ 自体がこの4Kメトリクスに対して
多分相関がある状態ですよね今 の話で
そうですねあると思いますそう かデプロイ頻度で思い出しました
けどこれ何章あったかなこの中の 一つの章がデプロイパイプライン
CI/CDとかに関するオブザーバビリティ も大事だよって書かれてました
ねその本番環境だけじゃなくて そのパイプラインもちゃんとオブザーバビリティ
24:01
が高まっていることは大事っていう のが書いてありました
そこすごくもし覚えてたら聞いて みたかったです結構オブザーバビリティ
系のツールでデータドックとか ニューレリックとかあるじゃない
ですか最近ちょうどデータドック のリリースされた機能とか私定期
的に追ってるんですけどどんどん CIとかのオブザーバビリティ機能
が追加されていってるですよね 結構初めはCIのオブザーバビリティ
追加してどういうところが見たい のかなって漠然と考えてたんです
けどなんかそういう記載ってありました そのこういうケースだよねみたいな
そうですねこの章だけ実はスラック の人が書いてるんですよ
スラックの人
スラックの中の人が書かれてて どんな話だったかなざっと思い出せない
な名前がソフトウェアサプライ チェーンって書いてあったんで
またセキュリティの話かと思ったん ですけどこれはその話ではなくて
普通にサプライチェーンつまり リリースのプロセスのことだから
ソフトウェアサプライチェーン って言ってるんですねここでは
なるほど
でそこが大事だよっていうこと を言ってるんですけどこれまとめ
しか読まなかったんだよなまとめ になんて書いてあったっけでも
そうだまとめにはスラックの例 を紹介しましたぐらいしか書いて
いないそうするとあれなのかな もしかすると自分たちが今CI/CD
とかで使ってる仕組みで例えば 失敗とか成功したときに無意識
にログとか見て納得してるんだ けれどもそこに対してもっと改善
なのかな改善とかどういう速度 で動いてるのかの可観測性を上げる
ことによってCIの高速化であった りとか失敗時のゲイン究明が早く
なるとかそういう話なのかな
ここではそうですね速度と安全性 のバランスとかも書いてあります
ねだからテストをどれだけ実行 するかとかテストをどれぐらい
早くできるかとかいつのテスト をやるのかとかその辺が書いて
あるかななんかインシデントが起きた みたいですね
ああそうなんなるほどですねそっか そっかてっきりXPの書籍とかだ
と今も書かれてたのかな確かなんか CIの章とかで10ミニッツビルド
27:06
みたいな定義がされていてビルド するCIはなるべく10分以内に収
めたほうがいいんだみたいな表記 があったと思うんですけど例えば
あれを守りたいとかそこに近づけ たいってなった時にやはりオブザバビリティ
が高いほうが改善速度が上がる ってことなのかなチームのリード
タイムが短くなる的な
そうですねどこら辺がボトルネック になって時間かかってるのかとか
が分かるほうが縮めやすいです もんね時間は
確かにそういった部分ではまだ 遅すぎるなって感じたことがな
かったからそこに対してあんまり 問題意識がなかったのかもしれない
ですね私自身
そうですねあとはリリース頻度 にもよると思うんですよ
確かに
1日になんかまあそんな10回とか 20回とかリリースするようなチーム
だと例えばまあ1スプリントとか 1週間とか2週間に1回ぐらいのリリース
頻度のチームだとそのパイプライン の速度に対する感度はだいぶ違う
でしょうね
そうですね確かになるほどなあ でもなんか読み物として面白そうな
印象を受けましたすごく今
そうですねあと自分が今扱ってないん で結構読み飛ばしたんですけど
あれですあの分散システムを前提 にした記述が結構多いです
それはなんかちょっと読んでみたい な
ちゃんとトレースがだからされて ないと分散システムではダメだよ
とか
確かに確かに
メトリクスってその一定の期間 の平均値だったりするじゃない
ですか例えば
はい
cpuの使用率とかでも1秒ごとに 出たとしても1秒の間での平均値
じゃないですか
そうですね
そういうのじゃあその役に立た なくて一連のあるイベントに対する
情報を積み重ねてトレースとした そういうものがオブザバビリティ
には必要ですっていうのが一番 最初に書いてあった気がします
三本柱ってありますもんね
同意です
メトリクスとログとトレースかな 三本柱はあれの中で特に重要な
のはトレースって書いてありました ね
トレースがまた難しいんですよね
いやそうなんですよね
トレースしたいがためにサービス メッシュみたいなものを入れて
みたりとか
いやデータドッグが吉野やって くれるのはすごいありがたいです
けどね
うんそうなるほどなるほどこれは 年内に読めるかなどうかなでも
読みたいなこの本は
まあそうですねサマリみたいな のがあったらそれ読むだけでも
いいのかなと思ったんですけど 多分三浦さんにとってもそんなに
30:00
新しく知ることないと思うんで これ
なるほど
けどまあそうですね組織のところ とかはあんまり他では見ないあれ
だったかもしれないですね
切り口というか視点だったみたいな 感じですか
そうですねあと自分が読んでない ところで言うとこれ後省校生で
読んでるんですけど
はい
第4章が大規模なオブザー部下官 属性っていうのがあって
大規模
大規模っていうのがあって大規模 じゃねーしなーと思ったんですけど
その気持ちすごいわかりますスケール 大きすぎてなんかこれこういうこと
やるのいつ来るのかなぐらいあります よね
それあれですね話変わりますけど sre本あるじゃないですか
はいはいはい
sre本読んだ時思いましたねこれ googleだからだよなーとか思うの
結構ありました
いやーでも大体の書籍ってちょっと これ全然体感だから違うかもしん
ないんですけど後半の章になれば なるほどなんか今の自分じゃない
なとか今の規模には必要ないな って思う章が増えてくるイメージ
そうですね
これもちょっと全然違う話にな っちゃうんですけど3,4年いつだった
かな多分エンジニアのためのマネジメント キャリアパスって本が出た時すぐ
読んだんですよで多分その時私 チームリードする立場でもなければ
ただただこう開発をする人だった ような気がするんですけど後半
何言ってるか全然わかんないです もんね
大体の本ってやっぱり最初は一般論 みたいなところから入って後半
の方が個別具体例になるからだから 後半の方はちょっとnot for meの
やつが出てきたりするんでしょう ね
その時に多分大事なのが脳内に インデックスだけ残しておいて
そういう状況になった時とか近 づいた時にあそういえばあそこに
なんか書かれてたなって思い出せる と後々参考になりますよね
そうですね思い出せればですけど そういえばあれにこれ書いてあった
なみたいな
そうそうなるほど確かに大規模 は読み飛ばしちゃいそうですね
はいじゃあそのぐらいにしておきます か
はい
ちょっと待ってくださいね漢兵を 読みますので
はいお願いします
はいじゃあ質問や感想はマシュマロ で投げてくださいお待ちしています
twitterでは#ゆるテクをつけてツイート をお願いします
お願いします
今日はありがとうございました
ありがとうございました
[音声なし]
