00:07
はい、7月29日金曜日ですね。
時刻は朝9時を回りました。
本日の東京はいい感じの天気ですね。
はい、おはようございまーす。
himehimeのkkeethことくわはらです。
本日も朝活を始めていきたいと思います。
はい、というわけで、今日は、
何を言うのかすごい悩んだんですけど、
悩んだせい、わからなくなったので、
一旦また、
タイトルがあるとですけど、
weekly frontend roundup from tokyoさんの議事のうち、
昨日は371回だったんですけど、
今日は370回の記事をガーッと見させていただいて、
その中から読みたい記事をピックアップしていこうかなと思っております。
はい、元気さんですね。
おはようございまーす。ご参加ありがとうございます。
タイトルある記事をダラダラと読む回です。
これですね、はい。
はい、読み方が合っている感じですけど、
dkumaさんですかね。
はい、おはようございます。ご参加ありがとうございます。
はい、タイトルある記事をダラダラ読んでいきます。
一応、読んだことない方に補足を一応しておきますと、
このweekly frontend roundup from tokyoさんは、
何名かの方々で、
フロントエンド周りの議事をダーッと書き集めて、
そのうち10個をピックアップして、
そこに載せるっていう感じのものですね。はい。
割とエンジニアとかデザイナーとか、
職種が分かれた方々でやられているので、
結構幅広い記事が多いなというところです。
はい。では早速やっていきましょう。
ボリューム370回のときのところですね。
はい。では、一つ目ですけども、
一つ目は、ドラメトリックスですね。
The right answer to measuring engineering team performance.
ヤコブ・カプランさんという方と、
モスさんという方が書かれたときにですね、
パフォーマンスを測定するための
ドラメトリックスというものがあるらしいですね。
ドラ、d-o-r-aでドラだと思いますけど。
エンジニアリングチームのパフォーマンスを測定するには、
どのような指標を使用する必要があるか。
この質問に対して、ドラメトリックスという方の考え方を紹介します。
ドラメトリックスでは、次の4つの指標を測定することで、
チームのパフォーマンスの評価も行っていますということです。
1つ目は変更のリードタイムですね。
2つ目がデプロイの頻度。
3つ目が変更障害率ですね。
最後の4つ目はサービスの復元時間です。
この4つですね。
最近自分がパフォーマンス改善周りのところの
お話とか技術に関してすごく興味があるので、
ちょっとこれ気になりますね。
ただこれは技術とかシステムパフォーマンスではなくて、
チーム的な観点でのパフォーマンスだと思いますね。
一応見てみたいと思いました。
2つ目ですね。
2つ目の記事はセブンシッピングプリンシップルですね。
7つのデプロイポリシーと言われるものです。
本番環境へのデプロイに関わる7つのポリシーを紹介します。
例えばいい仕事だけをデプロイするとか、
自信を持ってデプロイするとか、
完了した仕事のみをデプロイするなどなどみたいなところですね。
03:01
3つ目です。
3つ目はARIA Authoring Practice Guideですね。
APGと言われるものだそうですね。
ARIAのパターンガイドを載せています。
ARIAをどのように実装すればよいか、
コンポーネントごとに詳細に解説をしていますよということでした。
これも読んでみたいですけど、
ソースコードがバリバリに出てくる気がしていて、
今開いてみたんですけど、ざっくり開いた感じ、
これはパターン化されてますね、完全に。
例えばアラートのパターンとか、ボタンのパターンとか、
パンクズのパターンとかということに関して、
それぞれどういうようなARIAパターンで実装すればいいかみたいなのを
総まとめになっている感じですね。
これは読むものではないので、
皆さんのほうで見ていただければと思います。
これとても有用そうだし、便利そうなので、
アクセシビリティとかしっかりやってみたいよという方は、
ここにすごいケースが載っているのでいいなと思いました。
しかもこれよく見たら、W3Cのサイトっぽいですね。
w3.orgっていうところにYARIAっていうURLで貼られてますので、
これ良さそうだなと。
これは後ほどツイートします。
では続いて、1、2、3、4つ目ですね。
次はベタースクロール、モダンCSSですね。
スクロールの挙動をモダンなCSSでカスタマイズ・改善するというような記事だそうです。
これもソースコード多そうなので、読むことは控えます。
続きまして、スタイルスコーピングVSシャドウドムですね。
Which is fastest?
スタイルスコープとシャドウドムはどちらが高速か検証を行います。
シャドウドムがほとんどの場合高速であることが分かりましたよということでした。
シャドウドムの方が速い。
では残り5つですね。
5つはインプリーフになりますけど。
6つ目の記事ですね。
Building Forms with Custom Elementsですね。
ちょっとよくわからない団体さんでしたね。
の書かれたものですけど、
カスタム要素を使用したフォームの作成方法について解説するというところでした。
確かにリアクトもそうだし、ビューもそうだし、
僕の好きなライオットもそうですけど、
カスタムコンポーネントを作って埋め込んでてページを作っていくものだと思うので、
その辺のものについて解説したものだそうですね。
わざわざここに選ばれているから結構学びありそうだなって気はしますけど、
これもまたソースコードばっかりだろうなという感じはしました。
続いて7個目の記事です。
Can We Enterprise CSS Gridってことですね。
大規模なエンタープライズなソフトウェアについて
CSS Gridは有効に機能するかどうかというのを考察をしてみましょうというところでした。
これは読んでみたいですね。
続き8つ目ですね。
8つ目の記事はトレードオフスインザディシジョンメイキングですね。
意思決定のサイドのトレードオフをどのように考えるべきかアドバイスするというところでした。
これもドンピシャで僕刺さったんで、後でも。
続いて9個目ですね。
06:00
9個目はランダムノーツアラウンドサービスワーカーズディベロップメントアンドテスティングですね。
サービスワーカーズのテストについてのところでした。
サービスワーカーとテストか。
僕サービスワーカー実は案件とかでガリガリ使ったことがなかったので、
技術的な好奇心はくすぐられますね。
これもソースコードだらけだと思うので今回の音読の中には控えようかなと思いました。
ラスト。
Apple is not defending browser engine choiceって言ってますね。
AppleのiOSがブラウザーの多様性を妨げてるんじゃないかっていう観点からの考察だって言ってました。
それは皆さんにお問い合わせの意見があると思いますけど、
Safari 16のベータの記事をだいぶ前に読んだんですけど、
Safari 16ベータでついにプッシュ通知が実装されるっていうところが大分大きなお話だったと思います。
さっきのWWDCでAppleの発表の中にありました。
Safari 16を僕は結構期待はしてますね。
やっとウェブの進化にAppleも乗っかってくれたんだなっていう感はあります。
あとなんだっけ。
Chrome拡張みたいなものをSafariでも作れるようになりますよっていうのも同じようにやってて、
そういうツールキットみたいなのを紹介してたはずなので。
気になる方はAppleの公式ブログを見てみてください。
WWDCのブログの中にSafari 16ベータっていう確かタイトルの記事があると思います。
その辺からざっと。
しかも2,3回に分けてその辺の詳細なものが書かれてたと思うので見てみてもらうと結構面白かったと思いますね。
ここまで10個紹介していったんですけども、
やっぱり一番読みたかったのは一番最初のドラメトリックスですね。
パフォーマンスを測定するためのドラメトリックスってやつが僕が一番気になったので、
そこを読んでいこうと思いました。
本当はですね、ざっくり今日読みたかったものとして、
昨日読んだものの中に出てきたのはWhy Use SASってやつと、
Write Better Commits, Build Better Projectってやつですね。
良いコミットメッセージが良いプロジェクトを作りますよっていうところですけど。
読みたかったんですけど、
特に後者の方はめちゃくちゃ長くてですね。
とても今日じゃ読みきれなかったので、ちょっと控えようと思いました。
ただ全部英語なんですけど、
これはこれで学びがすごくありそうだったので、
もちろん皆さんもきっと使われると思いますので、
ぜひぜひ参考に読んでいただけたらいいんじゃないかなと思ったりはしましたね。
改めて読んでやっぱり読みたくなったら、
こちらで読もうと思います。
というわけでじゃあ今日は、
ドラメトリックスってやつのところを読んでいこうかなと思います。
では行きましょう。
ドラメトリックスですね。
エンジニアリングチームのパフォーマンスを測定するために、
どのような指標を使用すれば良いですかっていうような質問を結構な頻度で聞かれますと。
FAQを作成するものの頻度で聞かれると言われたので、
私の答えは人それぞれだと思われるかもしれませんと言ってます。
今から4つぐらい、
09:03
ドラメトリックスのところで書いていくんですけど、
基本的に人それぞれじゃないのっていうところにあるかもしれないですけど、
そうではないよっていうことを言っておきます。
私は正しい答えは一つだけだと信じています。
より正確には非常に優れた、より適応可能な、
確立された一連の測定基準があって、
それを出発点とすべきだと思います。
うまくいかないかもしれないし、
他の測定基準で補強する必要があるかもしれませんが、
大多数のチームでうまくいくはずですよと。
そしてその証拠ができるまでは、
これらの測定基準を使うべきだというふうにおっしゃっています。
というところでした。
それらの測定基準、メトリックスっていうのは
以下になりますよっていうところです。
1つ目がデプロイ、フリクエンシーですね。
DFって言われます。
最初のドラメトリックスのDのところですかね。
あなたのチームはどのくらいの頻度で
本番間隔へのリリースを成功させていますか。
通常、期間ですね。
何日なのか、週なのか、月なのかっていう。
その期間ごとのリリース数で測定されます。
パフォーマンスの高いチームは
一般的にリリース頻度が高く、
DFの変化によりチームが減速しているのか、
スピードアップしているのかというのが
一応分かるよというふうに言っていますね。
はい、というところでした。
確かにこのメトリックスって
Amazonじゃなくて、どこだっけ?
あってますね。Amazonとか
ゲームスネーター、AmazonじゃなくてAWSですね。
とか、Googleもその辺の指標を取っているらしいですね。
一日何回デプロイするかみたいなところも
計測をしているみたいなのを
一回読んだ気がしますね。
なのでこのデプロイメント頻度っていう
メトリックスは割と世界でも使われていて
良さそうだなと確かに僕は思いましたね。
はい、で2つ目です。2つ目の基準が
Read Time for Changesですね。
LTって言われるものですけど。
はい、変更のリードタイムですね。
変更が開始されたとき、
例えばバックログから開始されたチケットだったり、
脆弱性の修復の開始などなどとかありますけど、
そのような開始されたときと
それがリリースされるときの時間間隔っていうところを
基準ですね。
レードタイムのスタートとエンドとして
測っていこうというところですね。
これはチームの効率と応答性を測定します。
LTが高いということは
チームがフカフカで一度に多くのことをやっているか
もしくは仕事を十分に小さく分化していないか
ということを示す場合が多いですよって言ってました。
はい、まあそうですね。
リードタイムだと思います。
余談ですけども
弊社イメミでも今
エンジニアチームの
生産性向上とパフォーマンス改善ってところを
今視野に、裏で実は動いていて
ファインディーチームズさんの
っていう名前のサービスを使っているんですけど
その中で、要はリードタイムっていうところが
結構重要になっていて
そのリードタイムをどこに置くかっていうので
メトリクスの指標を測っていますね。
これもこれでなかなか
今まさに僕がやっていることと共感があったので
いいなと思いましたね。
エンジニアの生産性どこで測るかって
すごく難しくですね。
困ったので、一旦弊社の具体例で
12:01
喋っちゃいますと
最初の各チケットごとに
着手し始めた
最初コミットし始めるときがあるじゃないですか
そのファーストコミットから
そのやっている
開発が
デプロイするためのブランチですね。
メインブランチとかいっぱいブランチあると思うんですけど
そのブランチにマージされるまでの
時間、リードタイムっていうのを
僕らはその生産性
っていう風に一旦決めました。
というのも、本当はデプロイまで行きたいんですけど
やっぱり弊社っていうのはクライアントワークを
する会社なので
ブランチにマージはしたんですけど
実際デプロイするかどうかとかリリースするかっていうのは
意外とお客さんマターだったり
タイミングは計らせてくれって言われたりすることも
あったりするので
デプロイにしてしまうと
お客さん都合でデプロイしなくてリードタイムがものすごく長くなって
この人生産性悪いみたいな
指標になってしまうのでそれは良くないよね
なので出荷準備までできました
つまりブランチにマージされましたっていうところまでを
リードタイムに一旦して
弊社では一旦生産性の
可視化っていうのを図ろうと
言いまして、余談でしたけど
参考程度に
お話しさせていただきました
3つ目ですね
3つ目はチェンジフェイラーレイトですね
変更の失敗率
失敗という定義を
またどうするかっていうのはすごく難しいですけど
とにかく落ちた確率ですね
変更のうち
何%が失敗したか
その失敗は一応障害であったりバグであったり
セキュリティ問題が起きたみたいなことですね
何と何と引き起こしたかっていうところを
失敗度定義しますと
そのCFRですね、チェンジフェイラーレイトですけど
っていうのは品質管理の指標です
ということになってます
CFRが高いということはテストのやり方が悪いか
コードレビュー厳密じゃないとか
システム的なセキュリティの問題があるなどなど
っていうのを示している可能性があります
それはそうでしょうねっていうのもあります
これにしてだいたいコードレビューと
あとはテストしてなかったみたいなことが
多いと思いますけど
要はレビュー観点とか
その耐性が弱かったんじゃないの
っていう感じは
僕の経験値的にはしますけど
はい
またその変更失敗率っていうのを
メトリックスの一つに持ってますと
逆に言うとこれが高いっていうことは
それに対応しなきゃいけないコストがかかるんで
結果的にチーム全体のパフォーマンスが悪い
っていうことに繋がるっていうことだと思います
はいラストです4つ目です
4つ目はメンタイムトゥリカバリーですね
はい名前の通りです
リカバリーの時間の話ですね
障害が発生したときに
システムを復旧して通常運転を戻すのに
どれくらいの時間がかかるかというところですね
MTTRが低いチームっていうのは
より代替になることができますと
それは確かにそうですね
早くリカバリーできるんだから
リスク高いチャレンジをすることも別に
そんなになくなって
障壁はなくなるって感じですよね
よって代替になることができると
つまり障害が発生しても
迅速に回復することができる
MTTRが低いってことを重視すると
より堅牢なシステムを構築する方向に向かう傾向がある
と言ってます
それは結果的にそうなる
っていうことなんでしょうけど
15:01
それを目指すことは悪いとは思わないので
いいと思うんですね
これらは一応
ドラメトリクスとして知られていますと
すみません僕は今日初めて知りましたのでごめんなさい
そうですね
ドラメトリクスでもよく見たら
DORAじゃないじゃんっていう気がしますね
頭文字だけ取ると
DLCMになっちゃいますけど
ドラとは
さっきの頭文字を取った意味ではなくて
DevOps Research and Assignment Group
アセスメントグループのことだそうですね
はいはいはい
Googleの研究グループだってことだそうですね
やはりGoogleでした
彼らの研究によると
上級のメトリクスっていうのは
何があることがわかりましたと
その背景や研究の深掘りについては
アセスレイっていう記事があるので
そちらを読んでみてくださいと
Dream SoftwareとDevOpsの科学
っていうものもあるのでそこを見てみてくださいよ
ってことでした
一応この記事のリンクも
貼られてますので
ざっと見てみて
よさそうであれば
すみませんこれは書籍でした
なるほど
ペーパーバッグですね
音読するかどうか
できないですねこれ
お金払って読まなきゃいけないものなので
それを音読するとさすがに
怒られると思うのでこれは読めない
一応リンクだけツイートします
続いての
入っていきましょう
ドラメトリクスのとりあえずの紹介でした
続いて
Tips and Tricks for Drametrics
ヒントとコツの
ところの話をしていこうと思いました
これらの
測定基準を実際に採用するには
いくつかのスキルが必要で
そこには微妙な違いがあります
ここではあまり深く掘り下げることはしませんが
それについてはさっき出てきたアクセラレイト
本があるのでそこを読んでみてください
私が長年に渡って
これらのメトリクスを使って得た
簡単なヒントやトリックをいくつか紹介したいと思います
まず測定して
目標を後で設定します
というところです
あるいは全く設定しないということもあり得ますと言ってますね
へーそうなんや
セットターゲットズレイター
これは本当に
素晴らしい名言ですね
とにかくまずは計測
測定をしろということですね
数字を取りなさいと言ってます
グッドハートの法則を思い出してください
測定が目標になるときそれは良い測定ではなくなります
ドラの指標に関する私の経験では
早急に目標を設定しても
うまくいかないということだそうです
そうだよね
測定が目標になってしまうとそれは良い測定ではなくなります
何のための測定なんだという話は絶対出てくる
例えば
あなたのエンジニアリングチームが
週に3回で苦労しているとしましょうと
これは良いDFでしょうかどうかというところですね
それとも悪いDFでしょうかと
これもっと詳しく説明したい人は
今の単語だけど言葉だけだと分かりません
あるチームにとっては
週3回というのは素晴らしいことだし
他のチームにとっては教育的な遅さだと言われる可能性もあります
多くの場合目標を設定する必要はないでしょう
私は特定の目標を設定するよりも
時間の経過に伴う変化をモニターすることの方が
価値があると考えています
相対的な変化というのは
18:01
チームの何かがプラスにせよマイナスにせよ
変化したことを示し
その根本原因を調査し
それに応じて調整することができるのです
いずれにせよ明確な目標を設定するのであれば
まず測定して
推定で済ませないでくださいということを
言っています
確かにそうかもしれないですね
測定した数字とかデータを見て
チームの状況とか
開発ビルドから考えるときに
遅いか早いかというのを
測定するのは全然いいかなと
確かに思いました
でも何のために測定するのかという
共通の握りというのも
僕は結構重要だと思うので
ざっくりですね
共通認識とか共通の目標みたいなところ
持った上で
一応測定するものというのを比較
選定して実際に測定して
そこから目標を作っていくのがいいのかなと
ちょっと思いましたね
闇雲に測定したりするとか
だと結果数字を取ったらどうするの
という話に繋がってしまいますので
というところでした
続いて
carefully define
termsでした
というところですね
保証的な用語注意書きを定義しましょう
というところですね
ドラメトリクスが使用する用語の中には
慎重に定義する必要があるものがいくつかありますと
それは障害だったり
回復だったり変更開始終了
というようなことですね
などなどというものがありますと
デプロイされたという言葉も
見た目以上に複雑ですよと言っています
フィーチャーフラグの後ろに新機能をデプロイする場合は
どうなるのでしょうか
コードが本番稼働した時点で
そのLTの時計を止めるのか
それとも100%のユーザーがフラグを立てた時点で
止めるのかその中間でしょうかみたいなところですね
確かに割と
段とかゴールの定義というのが
曖昧だとする可能性がありますね
ある程度の一貫性があれば
答えはどうでもよいのです
しかしこれらの値をどのように測定するかについて
どのように定義しておくとは価値がありますよと言っていますね
はい、というところでした
まあ確かにね
はい
それ以上でもいいかでもないなというふうに思いましたね
では続きまして
これちょっと長い
標準読めるかな
あと7分ちょっと頑張ります
はい、じゃあ続きまして
A few real examples to apply in DoraMetrics
ドラメトリクスを適用したいくつかの
実例というところです
最後にこれらを具体的にするために
これらのメトリクスを様々な種類のチームに適用した
いくつかの例を紹介したいと思います
これらは全て実際の例だというふうに言っています
まずはフィーチャーチームですね
このチームは
新しい製品の実装を
エンドツーエンドで担当する
フィーチャーチームだと言っています
彼らはドラメトリクスをどのように定義し
使用したかというとこんな感じですと
まず一つ目ですね
DF、デプロイメント
もう忘れた
DFでした
彼らのDFは
CDバイプラインから直接測定した
1日あたりのデプロイの数だと言っています
本番クラスターにメインがデプロイされる度に
デプロイとしてカウントされますと
起動フラグの有無に関わらずそれはカウントされます
21:01
目標値は週5回から週20回
この範囲の回数があった場合は
何か問題があるのかとチーム内で議論したそうです
すごいな
週5回から週20回
デプロイするんですね
これはすげえな
デプロイって言っても
デプロイって言ってますね
CDバイプライン使ってるってことは
本当にちゃんとデプロイしてるんですね
これは僕らからすると驚異的なスピードだとやっぱり思っちゃいますけど
続いてLTですね
LTについてはチケットトラッカー
GitHub Issuesとかで計測をしているそうですね
時計っていうのはチケットが
進行中の列に移動した時点から始まって
チケットがクローズされた時点で
時計止めますと
チケットのタイオープンで時計はやっぱり再スタートして
クローズされるまでの時間はやっぱり追加になりますよと言ってます
いいですねちゃんとその辺計測してるんですね
目標は
平均LTが1週間未満で
チケットを非常にうまく小さく保つように設計されています
というところですね
いいですねチケット1週間未満で
ちゃんとクローズされるように設計されてる
っていうのは素晴らしいと思いました
とにかくほっといてくとチケットの1週なんて
全然1週間余裕で超えてまた来週もこのチケット見るな
なんてよくよくある話なので
これが1週間でなるべくクローズされるようになっている
っていうのはめちゃめちゃ素晴らしいと思いました
はい続いて
CFRですね
失敗したデプロイメントの割合ですけど
失敗度は以下のいずれかと
定義してみたそうです
3つの定義ありますね
1つ目はそのデプロイで導入された
ユーザー向けのバグが起きたときです
はい
2つ目はそのデプロイで
発生したセキュリティ問題ですね
3つ目長いな
3つ目はインシデントポリシーガイドで
定義されたインシデントを
発生させたこと
CFRに特定の目標はありませんでしたが
上向きのドリフトがないか
長期間経って監視しましたという風に
補足をされています
で最後4つ目ですね
MTTRですけども
上記で定義した障害について
障害が最初に指摘されてから
解決されるような時間
インシデントの終了が宣言されるかもしくはバグが解決されて
本番環境にデプロイされるか
いずれかだという風に言っていますと
バグとインシデントのタイムラインは大きく異なるため
この2つを別々に測定して
バグのMTTRと
インシデントMTTRと呼んでいますと言っています
目標としては
インシデントMTTRの平均を4時間未満
バグMTTRの平均を
重大度に応じて
クリティカルな問題の24時間から
ローセブな問題の
90日までとします
ローセブだからいいと思いますけど
クリティカルな問題はなるべく
24時間1日以内に
直しましょうというのを言っています
というところでした
結構参考になりますね
他社の実際に運用されたチームの
メトリクス基準というのは
今のはフィーチャーチームのメトリクスでした
続いての例は
例は2つしかないんですけど
チームはセキュリティエンジニアリングチームですね
このチームはもちろんセキュリティエンジニアリングチームで
エンベデッド
エンゲージメントモデルを採用しています
24:01
つまりチームのメンバーは通常
メトリクス間に異なるエンジニアリングチームに所属して
高リスクまたは何らかのセキュリティに焦点を当てた
重要な
イニシアチブに取り組んでいきますよ
というところでした
このチームのメトリクスはこんな感じですよ
まずDFですね
組み込まれたチームのDFを
見ることによって間接的に測定します
目標はセキュリティエンジニアの
存在によって
DFが変化しないようにすることでした
言い換えればセキュリティエンジニアチームというのは
頻度を落とさないようにすることだ
というふうに言っています
なるほどですね
関わったことによって頻度を下げないようにする
というのは非常に重要
なおかつ間接的に
第三者目線でどんどん測定するというところに
注意を置いたという感じだそうです
続いて
具体的にどういう設定
目標の数値にしたのかというのが出てこない
ここはあくまで測定だけをしたチームっぽい感じに
見えますね
続いてLTですね
LTは前の例のLTとほぼ同様に
セキュリティエンジニアチームが直接ですね
エンジニアとかレビュアなどとして取り組んだ
変更についても測定をしましたと
DFと同様目標というのは
あなたが参加したチームのLTに悪影響を
与えないことでした
やっぱりセキュリティチームだけあって
開発をするわけじゃないので
関わり方が違うらしいですね
それでもドラマトリックスに従って
いろいろやってみたということですね
三つ目CFRですね
セキュリティエンジニアが関与したときに
行われた変更によってもたらされた
これを特に定義しましたと
目標というのはCFRが1%未満だよと
言っています
私はこれは高すぎると承知しましたが
それはまた別の機会に話します
なるほど
セキュリティエンジニアチームが関わったことによって
1%未満のセキュリティ問題を
定義したと
それは高すぎるって思う人はいるでしょうね
セキュリティ専門のチームなのに
セキュリティチームが関わって
1%近く
問題が起きてしまうというのは
いやですよね確かにね
はい
最後MTTRですね
MTTRはセキュリティエンジニアチームが関与した
製品のセキュリティ問題についても具体的に定義しました
問題そのものにも定義しました
最初の発見から最終的な修復までの経過時間で
もちろん測定されます
目標は会社の脆弱性管理ポリシーによって
定義されクリティカルの7日間から
ローの91日間までとしました
はいというところですね
7日間になっていますねクリティカルの問題が
ちょっと長くなりましたね
安易に設定とか対策をして
別の二次災害とか起きないようにするとか
いろいろ多分考えることが
セキュリティチームの場合はあるのかなと
ちょっと思いましたね
最後がSREチームの例を出されて
終わりになっていますね
30分来たんですけど
もうちょっとだけなので
このまま走り切りたいと思います
SREチームですけど
これは他の約12のエンジニアチームに対する
サービスチームとして活動していました
SREは中堅的な
中堅的なオペレーションは担当せず
各チームがそれぞれのコンポーネントを運営し
オンコールで対応して
全体的に組織をレベルアップさせる役割を担っていました
27:00
というところですね
第3社チームですね
どのように定義して使っていたかというところですけど
まずDFですね
DFっていうのは
SREっていうのは各コンポーネントチームのDFを監視して
各チームは上記の最初のレートと同じように
DFを測定しましたと
市販機ごとにDFが最も低いチームと協力して
DFを高めるように
努めましたというところです
後々こっちはアプリケーション側に
しっかり寄り添いつつ
チームとして協力して動いていたという感じですね
LTは
このSREチームでは
LT使ってないってことはそうですね
全然対象外だから
スコープ外だから使ってないですね
3つ目です
3つ目CFRですけどもSREチームっていうのは
各コンポーネントチームのCFRを一応監視はしていて
これはインシデントを発生させた
デプロイの割合と定義しました
このCFRはインシデントを発生させた
デプロイの割合と定義され
ここでもパフォーマンスの低いチームと
協力してやっぱりCFRを
低減させましたよと言っています
興味深いことに特定のペアやグループの
CFRの間に相関関係が見られることがあって
それはある種の障害依存性
というのを示していますと
これはある種の故障の依存関係も示しています
多くの場合
これはそれらのチームの故障状態を
互いに切り離すための作業に発展しました
チーム自体の故障状態を
切り離して
作業することに発展しました
特定のペアやグループで
CFRの間に相関関係があったということなので
確かに人依存の
問題はあったのかもしれないですね
結果的にシステムの監視をしていたら
チームの話になったというのは結構面白いですね
最後はMDTRですけども
SREというのは
ほぼ全てのコンポーネントチーム間で
高い相関があることを発見したと
結局組織全体のMDTRを総合的に測定するものになりました
これまたすごくいい話ですね
なるほど逆に言うとやっぱりSREチームって
すごく大事なんだなということがわかりますね
Googleの中で特にそれが機能したということですけど
目標はMDTRを4時間以下に抑えることでした
これは彼らが提示した
特定のSLAに置き換えられますと
SLAとは何ぞやというのは書かれてないですね
4時間は突然出てきたもんじゃもちろんないですよ
と言っています
MDTRを4時間以下に抑えるってすごいですよね
今までの2つのチームだと
クリティカルなものが1日で
ローなものが90日
もしくは7日間で
クリティカルなものを90日と言っていたのに
SREチームのMDTRというのは
基本的には4時間ですね
すごいですねめちゃめちゃ勝負感を持っている感じでした
ということで例は終わりで最後
記し目ですね
ハブユーズドラメトリクス
ハウイズゴー
ドラメトリクスを使ったことありますかどうでしたか
というところで締められていますね
参考になれば幸いです
ドラノメトリクスを使ったことがある方はぜひその感想を聞かせてください
ご連絡ください
30:01
Twitterの
yacobianまたはyacob
このドメインまでメールを送ってください
以上で今日のサカツア終了にしたいと思います
もう1個の記事読めるかなと思ったけど
全然読めませんでしたね
ただとても参考になりましたね
ドラメトリクスというところですけども
人に関するパフォーマンスの
メジャーリングのところですけども
なかなか
僕らが事例出しましたけど
弊社の事例だと結局まだ
LTところですね
リードタイムフォーチェンジしか僕らは見てなかったんですけど
しっかりDFまで見て
DFとCFRMDTRですね
この辺まで確かに見ていくのはいいなと思いました
一方ですの僕らはクライアントバックなので
障害可能性とか
なかなか測定しづらいものもあったりするんですけど
やっぱりメンバーのパフォーマンスが高いというのは
結局そのビジネスの数字に直結するので
ここを測るのはすごく大事だなと思いましたので
改めてすごく参考になったなという感じがしました
では
今日のサカツちょっとオーバーしましたけど
以上にしたいかなと思います
ご参加いただいた皆さん
大変にありがとうございました
金曜日ですね
今日しっかり乗り切ってまた土日
永久休養していただければなと思います
頑張っていきましょう
お疲れ様です
