ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

Datadog Workflows で OpenAI Integration を試す

こんにちは。この記事は Datadog Advent Calendar 2023 の 12/2 の記事です。

今回は Datadog Workflow で OpenAI Integration を使ってみます。

Datadog Workflow とは

プレスリリースはこちらです。

Monitor, Schedule, Dashboard からの Manual 実行の3種類を Trigger とし、そこからさまざまなことを実行できます。

実行できる内容は Datadog へのさまざまな操作はもちろん、複数の Intergration を使って別のサービスへの操作も可能です。普通に http request を実行することもできるため、Integration のないサービスに対する操作も可能になります。また、javascript もできるのでちょっとしたプログラミングもできてしまいます。

参考

Datadog Workflow の Action

3種類用意されています。インプットに微妙な差異がありますが、ほとんど同じようなものです。

Edit text

Inputs Instruction が以下4つ選択可能です。自由記述も可能です。

  • Improve the text
  • Simplify the text
  • Change the tone to formal
  • Change the tone to informal

Input text に対して何らかの指示を出すための Action です。

Generate text

Inputs Prompt に Prompt を入力するようです。

Edit text との差は明確に Input と Instruction が分かれているかどうかです。

Summarize text

こちらは text to summarize のフィールドに Summerize したい文章を入れることになります。

Edit text で「Summerize the text」を入れた時と同じになる気がしますね。

Blueprints を見てみる

使い心地を見るために、Datadog が提供している Blueprint を見てみましょう。

OpenAI を利用しているのは1つ、「Simplify Language of a Monitor Alert」です。

  • Trigger: Manual
  • Workflow
    • Get event monitor alert details
      • Datadog Event: Get event
      • inputs に event id を入れています
    • Describe the alert message
      • OpenAI Generate text Action
      • Prompt: I have a Datadog monitor message but its in the format intended for the full configuration of the Monitor. So I can't understand what it says. Can you tell me what this Datadog monitor message is saying: {{ Steps.Get_event_monitor_alert_details.event.text }}
      • 1つ前の step の event.text を利用していますね
    • Simplify language of alert
      • OpenAI Edit text Action
      • 1つ前のステップの output をインプットにし、simplify することを指示しています
    • Create incident
      • Service Now: Create incident
      • Service now というサービスで Incident の short description に 1つ前のステップで simplify したテキストを入れています

アラートを受けて、そのアラート内容を OpenAI で要約して、Service Now でインシデントを宣言するという Workflow になっています。便利そうですね。

実際に試してみる

テスト用のアラートを作ってみます。テスト用なので全く意味のない以下のようなアラートを発火させてみます。

Monitor を Trigger とする場合、特定のキーワードを monitor の message に含める必要があります。今回は @workflow-chaspy-testSimplify-Language-of-a-Monitor-Alert" このような文字をアラートの本文に入れています。

はい、このように Monitor を分析して、それをまとめてくれました。

Describe the alert message

This Datadog monitor message is saying that the metric \"kubernetes.cpu.usage.total\" over the environment \"production\" was greater than 10,000,000,000.0 at least once during the last 5 minutes. The monitor was last triggered on Sunday, December 3, 2023, at 10:55:18 UTC. \n\nThe message also provides some additional options:\n- Monitor Status: View the status of the monitor.\n- Edit Monitor: Edit the configuration of the monitor.\n- Related Logs: View logs related to the monitor with the filter \"env:production\" and a specific time range.

Simplify language of alert

This Datadog monitor detected that the metric \"kubernetes.cpu.usage.total\" in the \"production\" environment exceeded 10,000,000,000.0 at least once in the last 5 minutes. The monitor was last triggered on Sunday, December 3, 2023, at 10:55:18 UTC.\n\nYou have three options:\n- Monitor Status: Check the current status of the monitor.\n- Edit Monitor: Make changes to the monitor's configuration.\n- Related Logs: Access logs related to the monitor, filtered by \"env:production\" and a specific time range."

こっちは全然 Simplify できてないですね。

終わりに

Datadog OpenAI Integration, API Key を入れるだけで気軽に使うことができました。

Datadog Workflow は個人的にはかなり推しの機能で、いろんなことができる可能性があると思います。レシピをシェアし合えるといいですね。

Azure OpenAI でも使えると良いですが、Workflow Action はなさそうでした。http request で api を直接呼べば同様のことはできそうです。

AI を使ってインシデント調査も楽にしていきましょう。

近況 - 2023/10

部長どうよ

よく聞かれるのでまとめておく。

blog.chaspy.me

役割変更に伴いミーティングやメンション、チャンネルの整理は行ったので、業務過多になっているとかはない。めっちゃ寝てます。 多分はじめてマネージャやる時や、開発チームのマネージャを兼務する時の方が負荷は大きかったように思う。

この1ヶ月は期初の考課・グレード設定会議でちゃんと役割を果たしつつ、役割変更をする際のいつも通り、情報収集と期待値調整をやっていた。

アクセルとブレーキの使い分け

考課・グレード設定会議での1番の感想は「アクセルとブレーキを踏み分けなければならない大変さ」であった。 担当のマネージャであれば、基本全力でアクセルを踏むだけで良い(自分のメンバーに関する Promotion や加点評価を説明する) もちろんマネージャ時代も陪席者としてブレーキというか、懸念表明はこれまでしていたし、できるものの、その場における最終意思決定者・責任者になるので重みが違う。 本当に大丈夫?ということや、その根拠はどういうところから、と説明を求めたり、判断基準を自分で言語化したりするのはこれまでやったことがなく、高負荷だった。

で、単にブレーキモードにすればいいなら簡単だが、そうではなく、逆に「アクセル踏まなくていいの?(出してこないマネージャに対してプロモーション/評価しなくていいの?)」ということも必要であり、やはり2つのモードを高速に切り替えることの難しさ、さらに見る範囲が広くなったことも相まって、これまでの10倍ぐらい疲れました。

顔つなぎ

情報収集、特に他部署の GM や部長と顔つなぎの 1on1 をして課題収集と期待値調整を行なった。同時に今まで深く関わってこなかった役割のグループの理解も深めることもでき、非常に有意義であった。時間を割いてもらって本当にありがたい。

また、顔つなぎはマネージャだけでなく、配下メンバーで一度も 1on1 をしたことないメンバーと skip level 1on1 を行い、元気ですか!とお喋りもした。結構な数になるのでゆっくり少しずつやらせてもらっているが、これもやって良かったと思っている。人によってトークテーマは異なり、前半は僕が聞きたいこと、後半は相手が聞きたいことを大体話しているんだが、良い刺激をもらえたり、与えたりできていそうだ。あとは「一度話したことがある」の効果はでかいと思っており、その投資でもある。

世界を理解する

同時に特にコストかけてやっているのは会社における事業・経営、およびそれを成り立たせている仕組みの理解だ。これまでいかに目先の開発だけに集中できていたのかがよくわかる。

管理会計自体の知識を本を数冊読んで行なった上で、では今自分たちの会社、事業はどういう状況なのか、そして毎年の管理P/L はどのように作られているのか、そしてそれを受けての来期や今後の方針は誰がどのように決定しているのか、その大きな流れを、大きな組織がどのように協調してやっているのかを理解している。

新しく学ぶことという意味で非常に刺激的で面白いが、難しいのはこれからだ。世界を理解した上で、じゃあ自分たちはどうする?を考えて実行する。それも目先半年ではない、数年先を見据えて、というのは非常にやりがいのあるテーマだ。

まさにこれから来年および次数年の事業計画を一緒に作っているところなので、やりながら、やり方自体も改善し、それを開発組織として、プロダクト組織全体としてどうあるべきかを考え、より良い未来を作ることををリードしていきたい。

プライベート

家ができつつある。土地を買ってそこで建てるのだが、ようやく更地になったところ。しかし同時に設計は進めており、立面図になって、外壁のデザインを決め、内装の色を決め、など家ができてきている感がある。

この辺りは全面的に妻がリードしており、助かっている。自分はというと、インターネット関係、あとは補助金とかのお金周り、配線やコンセントなど電気周りをやっている。

今の家も気に入っているので名残惜しいが、楽しみでもある。

マラソン

11/18 にハーフマラソンに同僚と出るんだが、いかんせん走るモチベが...

毎日走っていると続くんだが、一度休んでしまうとずっと休んでしまって困る。

podcast を聞きながらまた走り始めないと。もう時間がない。一度は20km通して走っておかないとなぁ。しかも期日より十分余裕もって前に。

ボカロ

ついに念願のボカロを始めた。小春六花にした。いい感じに歌ってくれてすごい。

早く曲リリースしたい

SRE NEXT 2023 で登壇した #srenext

してきました。楽しかったー。

sre-next.dev

登壇後記

実はプロポーザル募集が始まった8月頃、登壇へのモチベーションは枯渇していました。というのも(自分のスライド作成の技術が向上していないとも言えるのだが)準備の時間が割りに合わないと感じていたからです。これは今後再開するときは再度見直したいところ...。本業もあって、家庭の時間も必要で、健康維持の時間も必要で、可処分時間をどう投資するかをいい年なので色々考えると、登壇は”しばらくやめる”ということにしました。楽しさも知っているし、実際 SRE NEXT 終わったあとはすごくいい気持ちだったので、登壇は麻薬やな... などと思いました。

(業務として登壇するのだから)業務時間でやればいいじゃん、と言うのは簡単だしごもっともであるし、自分も所属メンバーにはそう言います。ただ、業務と登壇資料作成どちらが大事かなんて比べられないわけで、結局”業務を捨てる"ことができなかった自分は単に労働時間が膨らむ形になってしまっていました。

とのっけからネガティブな感じになってしまったんですが、そんな後ろ向きな状態でも SRE NEXT のプロポーザルは気がついたら書き始めていました。僕にとって思い出深く、大切な大切なカンファレンス。もしプロポーザル落ちたらそのときはそのとき、新しい世代へバトンタッチだな、通ったのなら、まだ自分に共有できることがあるな、と思い出しました。

プロポーザルの段階でかなり濃いめのアウトラインを書いていたので登壇自体は楽でした。今後出す人の参考に現物を記事の最後に晒しておきますね。

この登壇内容は、僕が2年間 SRE チームのマネージャとして過ごした期間の集大成のようなものでした。SLI/SLO として信頼性を開発チームで観測していく世界についてはある程度は僕がマネージャになる前から根付いていました。今でこそ Platform Engineering の認知が高まっていますが、我々も以前より信頼性と開発生産性、両方で開発チームをサポートするために Enabling / Platform Engineering 両面に取り組んでいました。

ここで語られなかったこともたくさんやりますが、僕が最も重要視し、注力したのが「開発チームからうまくフィードバックを得る」ことでした。Enabling だろうが Platform だろうが開発者の声を聞き、自分たちで何をやるかを決め、その結果を計測・観察し、次の計画につなげる。言葉にすれば当たり前に聞こえてしまうのですが、僕たちにとっては新しい挑戦でした。

そしてこれらの活動がうまくいったのは単なる方法論 / プラクティスがうまくいっただけではないことはわかっていました。簡単に真似ができない、だからこそみんな苦労している。だからその土台となる組織文化に着目し、考察した発表にまとめました。

結果として登壇内容で語られたことはほぼ全て所属メンバーの高い技術力とソフトスキルによってなされたものです。こういったものを僕の口で発表することは最初は抵抗あったのですが、所属組織の成果を代弁するのは何ら変なことではなかろう、マネジメントの成果の出し方の1つであろうと言い聞かせて話していました。

結果多くの方に来場いただき、感想を残していただき、ありがとうございました。当日の Twitter も、ブログで言及していただいているものも全て目を通しております。

本当にこの気持ちです。

懇親会も楽しかったです。アツい思いをぶつけてくれた VTRyo さん、お久しぶりの Nari さん、廊下で会って懇親会でもキャリアや業務について語れた t-jun さん、登壇後よりご一緒させてもらえた @yuta_k0911 さん、いつも仲良くしてくれている @donm_ri さん @a0i さん、全然暇ですよ!などと供述していた katsuhisa さん(安心感ある)グロービス _yukin01 さん、リアルでは久しぶり minamijoyo さん、その他懇親会で同じテーブルでお話しした皆さんありがとうございました!またどこかで会いましょう。

カンファレンススタッフとして room B を担当いただいた taxin_tt さん、shotaTsuge さん(ご近所!)ほか全てのスタッフの皆さん、本当にありがとうございました!

これから

登壇をやり切ったおかげでバチっと切り替えて 10/1 から新しい責務をやっております。

SRE のプレイヤーもマネージャも引退した後どうするのか、というのは以下の記事に書いたとおり、開発部長をやっております。部長なんて照れくさい、Senior EM だ!といってたけどなんやかんや社内呼称というのは強いもので、"部長"の自認も高まってきました。

blog.chaspy.me

社内 Public になってから1ヶ月、正式任用から1週間経った。忙しすぎて死ぬ、みたいなことは特段なく、順調に(?)職責変更と、責務を果たすために下準備を行なっています。

基本的には担当領域について、エンジニアリングを経営に接続することが責務だと思っている。(実際に数値責任を持つではなく、あくまで"接続"(橋渡し)が責務である)

この1ヶ月はとにかくいろんな人と話しまくっている。隣接の部署、あるいは新しくマネジメント対象になるメンバーと。新しい人と、自分にとって新しいことを知るのはとっても面白い体験で、そういう意味ではこのロール変更は自分に向いている面もあると思った。

ひとまずこれまで関与してこなかった会計用語の習得と、事業の現状を把握し、その現状に対して開発組織として貢献できることを探し、それを組織戦略、技術戦略に落とし込む、というのを直近やっている。あと FinOps は関係者と会話し進め始めている。開発生産性の経営への接続も、仕込みをちょっとずつやっている。

見るべき範囲が増え、変数が増え、これまで以上に緊張感は増すが、まずは半年、しっかり走りきろうと思います。

引き続きいろんな人とお話ししたいです!オンラインでもオフラインでも、声かけてください!


おまけ:出したプロポーザル


タイトル
開発者とともに作る Site Reliability Engineering

発表概要
SRE の実現には、SRE という Role を持つ人だけでは成し遂げられません。プロダクト開発を行う組織の場合、プロダクト開発者と緊密な連携が必須です。その場合、SRE Team がいかにプロダクト開発者の直面する課題をどれだけ深く理解し、その要求を適切に定義できるかが鍵となります。

開発チームの要求を理解するためには以下の3種類のアプローチが有効です。
直接のフィードバックを受け入れる
継続的にコラボレーションする
実際の現場を体験し、開発者の立場を理解する

そしてこれらを実現するためにはマネジメント上の工夫だけではなく、オープンで避難のないコミュニケーションや、定期的なふりかえり、そして適切なフィードバックを行うといった組織文化が必要不可欠です。

本セッションではこれらのアプローチの具体的な実践例と、それを支える組織文化に関する実例を詳しく紹介します。SRE チームと開発チームの両方のマネージャを経験を持つ私の独自の視点を通じて、プロダクト開発組織全体で SRE を効果的に実践するヒントを持ち帰っていただければと思います。

聞いた人が得られるもの
SRE チームが実現すべきことを開発者から得る方法
SRE チームとプロダクト開発者のコラボレーションを支える組織文化の作り方

発表の詳細
アウトラインです。

Google Docsに貼り付けやすい形で以下のように変形できます。

---

自己紹介

この発表のまとめ(伝えたいこと)

1. **SREの価値**  
   サービスの信頼性を期待値通りに実現するために開発者をサポートする - を最大限発揮するためには、SREが開発者の要求を正しく理解する必要がある。
   
2. **SREが開発者の要求を正しく理解するためのアプローチ**  
    1. フィードバックを得る  
    2. コラボレーションする  
    3. 実際に体験する
  
3. **円滑/高速にサイクルを回すために必要な要素**  
   マネジメントの工夫だけでなく、フィードバックをうまく行うスキルを組織文化として実装する必要がある。

導入 / これまでのあらすじ

- **SRE NEXT 2020, 2022 の話**
- **スタディサプリ SRE の歴史**  
  - 2018 chaspy 入社  
  - 2020 SLO コンセプトを組織に導入  
  - 2021  
    - SRE チームの Vision / Mission / Value 策定 [リンク](https://blog.studysapuri.jp/entry/sre-vision-mission-values)  
    - Terraform, Kubernetes など基盤の進化, 負荷試験基盤の構築など
- **スタディサプリ小中高の組織規模やプロダクトについて**

この2年間の SRE チームが目指していたこと

- **課題: SRE チームがやることは、SRE チームが決めていた**
  - 適切な課題設定ができない可能性  
  - 再現性がないと感じていた  
- **開発者からフィードバックを得る / フィードバックサイクルを回す**
- **複数のアプローチを試す**
  - 過去事例: [マネジメントによるSREの実現](SRE を実現するための組織マネジメント / Management to achieve SRE - Speaker Deck)

事例紹介

1. フィードバックを得る

- **SRE サーベイの実施**
- **「月間SRE」として、毎月の SRE からの Updates を開発チームが多く参加する勉強会で共有、フィードバックをもらう**
- **2週間開発チームに SRE が入って密にコミュニケーション(Embedded SRE パターン)**

2. コラボレーションする

- **新機能リリース前のデプロイパイプラインの構築**
- **技術戦略グループで議論**
  - [CNCF2023 での発表予定](https://event.cloudnativedays.jp/cndf2023/talks/1866)

3. 実際に体験する

- **短期留学(開発メンバーとSREメンバー)**
- **SRE マネージャが開発マネージャを兼任**

これを可能にする組織

- **マネジメントの工夫**
- **組織文化**

マネジメントの工夫

組織文化について

- **フィードバックのスキル**
  - 360 feedback について
  - あらゆるシステムやプロセスへのフィードバック
- **率直に・非難なくコミュニケーションすること(Blameless)**
- **あらゆるものを振り返る文化**
  - [ふりかえりの文化について](https://blog.studysapuri.jp/entry/2022/02/19/sre-retrospective-culture)

まとめ
1. **SREの価値**  
   サービスの信頼性を期待値通りに実現するために開発者をサポートする - を最大限発揮するためには、SREが開発者の要求を正しく理解する必要がある。
   
2. **SREが開発者の要求を正しく理解するためのアプローチ**  
    1. フィードバックを得る  
    2. コラボレーションする  
    3. 実際に体験する
  
3. **円滑/高速にサイクルを回すために必要な要素**  
   マネジメントの工夫だけでなく、フィードバックをうまく行うスキルを組織文化として実装する必要がある。



SRE サーベイの質問内容


Slack ID (GitHub ID)
所属チーム
関わっているサービス
ロール
自分たちのチームは自己完結化できていると感じますか?        
自分たちはいい感じにサービスを運用できていると感じますか?
何ができていればサービスを自分たちで運用できている、と言えますか?        
よりプロダクトを良くしていくためには、何がボトルネックですか?
もし、最近直面した SRE に関連しそうな課題/問題があれば教えて下さい

自分たちはいい感じにサービスを運用できていると感じますか? (2)        
普段の開発の中で最もストレスを感じている工程・手順は何ですか?
開発の工程の中で、これが速くなったら嬉しいという部分はありますか?        
自分たちのサービスにおいて、負債だと感じている / 消し去りたい要素は何かありますか?
あなたは、以下のツール等をどの程度理解していますか(詳細のコンポーネント別に質問)

現在の(SREが開発/運用している)プラットフォームは良くできていると思いますか
現在の(SREが開発/運用している)プラットフォームで分からないことがあったら、何を見ますか?
今のプラットフォームにあって便利な機能や、よく使っている機能があれば教えてください
現状の SRE の対応や取り組みに満足していますか?        
SRE の対応や取り組みについての要望/コメントがあればお願いします        (問い合わせをしたことがあれば) 
対応の速度や質に満足していますか?
SREの問い合わせ対応について要望/コメントがあればお願いします
サーベイについて何か要望/コメントがあればお願いします
SREチームから依頼があるとき、どのような形で連絡/依頼されると良いですか?



参考リンク
所属組織のブログ
Web 開発者目線での、SRE が作る開発基盤について
スタディサプリのWebアプリケーションはこうやって開発されている
AWS Dev Day 2023 Tokyo で スタディサプリのDarklaunch について発表してきました
開発生産性を支えるデータベースリストアを SRE が作った事例 スムーズな開発体験を支えるデータベースリストアの仕組み - スタディサプリ Product Team Blog
SRE メンバーが開発チームに入り、リニューアルプロジェクトのリリース前にプレモーテムをファシリテーションした話 「0回目のポストモーテム」としてのプレモーテムのすすめ - スタディサプリ Product Team Blog
著者自身のアウトプット
Web Application 開発の EM を兼務することになった Web Application 開発の EM を兼務することになった - ツナワタリマイライフ
SRE とプロダクト開発の EM を兼務して半年経った  SRE とプロダクト開発の EM を兼務して半年経った - ツナワタリマイライフ
開発チームに実際に入ったからこそ見えた課題と SRE としての経験を活かした事例 『スタディサプリ 中学講座』における E2E Test の運用と計測による改善 / Improved E2E testing through measurement - Speaker Deck

Senior Engineering Manager になった

過去形で書いたが正式任用は10月から。昨日社内にアナウンスされた。ソワソワしているのはようやく落ち着いた。

入社してからの経緯はここで振り返った。

blog.chaspy.me

一応社内の肩書きは「部長」であるが、ソワソワするので自称は Senior EM で行く。(それでいうと EM もそもそも社内の役職には存在せず、GM (Group Manager) であった)

部を2つに分割し、前任が持っていたものの半数を受け持つことになった。スタディサプリ小中高の BtoC 領域と、横断組織のいくつかを担当する。システムは共通部分も多いし、横断を見ているというのもあるし、技術戦略も見ているので BtoB のことは知りませんよ、となるわけもなく、なんだかんだ全体のことを見ていくことになる。

主務の担当メンバーの数は52名で、まぁかなりの責任のポジションである。数が全てではないし、数名だろうが誰かの人生に関与する意味では管理職の責任自体は変わらない。ただ、良くも悪くも影響範囲・影響力はある。恐ろしさがないといえば嘘になる。

責務は中間管理職の仕事と、技術組織の Engineering Management の仕事がある。どっちも未知の仕事だが、今は新しいことを学べること、経験できることにワクワクしている。

具体的にどうしていくかはこれからいろんな人と会話し、特にマネージャとのミッション策定を通じて実行していくことになる。

特に今は技術戦略と FinOps に関心がある。スタディサプリという事業に、技術組織が、システムが長期的に価値を生み出し続けるには何が必要なのかを考えたい。SRE を経験してきた身から、FinOps - ファイナンシャルチームと協力し、全てのチームがコストに説明責任を持ち、リアルタイムレポートを見て意思決定する世界(それが今の会社において本当に理想かの模索からではあるが)は挑戦していきたい。それを支えるためにブランディング、採用、メンバーの活躍と組織づくりもやっていく。

呼称について、社内から部長と呼ばれるのはそうなのでいいが、やっぱり Senior Engineering Manager がしっくりくる。たとえば以前だと VP of Engineering なのかもしれないが、別に副社長じゃないし、ただの1社員に過ぎない。求められることのレベルが変わるのはそうだが、やっぱり Engineering Management を主務としてやりたい。そしてそのために、直接的には今所属する、優秀な Engineering Manager たちの活躍をサポートしたい。それが目指したい姿とも合っている。間接的に、EM の活躍を通じて、全てのメンバーが活躍できる組織にしたい。

仕事が増えるということは、減る仕事もあるということで。長年勤めた SRE チームから卒業することとなる。僕より遥かに優秀な後任にお任せすることができて本当に嬉しく、ほんの少し寂しい。だけど任用当時目安にしていた2年という期間で引き継げたのは良かったと思う。このチームのおかげで僕は昨年開発のマネージャにチャレンジできたし、その経験がこの人事にも生きていると思う。

プロダクトセキュリティについても僕がオープンしたポジションで、無事2名採用できてチームとして独立することができた。ここは引き続き僕がマネージャとして担当し、SRE チームと協力しながらプロダクトのセキュリティ施策の要件定義と実装をする。将来的には DevSecOps もやっていきたい。また、僕が元々担当していた契約 SaaS のアカウントマネジメントの自動化にも取り組みたい。

brand.studysapuri.jp

この人事が正しかったかどうかは時が判断するだろう。前任ともなぜ自分なのか?はちゃんと会話した。運が6割、やる気が3割、実力が1割ぐらいだろうと思っている。うち運は半分が後任を作れたこと、もう半分が誰かに渡さないといけない状況になったこと(ポジションが生まれたこと)だ。というわけで僕にとっては運に恵まれたが、期待を含めて任せていただいているということなので、期待に応えられるように頑張ります。

信頼して任せてくれた前任と、受け入れてくれる仲間に感謝しながらがんばります。楽しみながらやりたい。

というわけで飲みにいきましょう!かこつけてめでたいワイワイするのもよし。CTO / VPoE / EM の方との繋がりも増やせたらなと思います。よろしくお願いします。

勉強会参加メモ - Workers Tech Talks #1

https://workers-tech.connpass.com/event/287490/

GraphQL Server on Edge

speakerdeck.com

  • GraphQL server をコンテナでやるとして、初手 Cloudrun を選ぶとして、
  • cloudfrare workers という選択肢
  • 許容しなければならないこと
  • gcp 主体から cloudfrare 主体に書き換えることができた
  • (kysely, SQL builder. schema から型を生成する. DB migration のために prisma と合わせて使う)
  • メリット
    • デプロイが8分から1分
    • コールドスタート 5秒から200ミリ
    • コンピュータリソースあたりの単価は高め(起動時間が減ることで結果的にサーバ費用は1/10に減ったとのこと)
  • デメリット
    • nodejsが必要な場合は別途サービス作らないといけない
    • tcp はリクエスト処理しているときだけ接続可能
  • まとめ
    • API サーバとしては実用的な状況
    • cloud frareにロックインするが、メリットはある
  • ユースケースを見極めれば十分に使えるという事例だった

Gyazo の素朴な Workers

scrapbox.io

  • Gyazo のユーザは北米に多いので gcp us-central に origin
  • 素朴だけど明日から真似できる例として発表
  • 画像をキャプチャ、画像は png として url でアクセスできるが、
    • 再度アクセスすると上に gyazo と表示される
  • 解決したい課題
    • 画像直リンシェアされると gyazo.com に辿り着けない
  • Cloudfalre proxy を CDN として使う
    • 「人間が見てそう」なら画像バイナリの代わりに html を返す
  • 100行ぐらいの素朴な実装
  • cloudfrare worker proxy mode で使えるなら簡単に使える
  • 従来アーキテクチャでの nginx/lua で持っていた logic をなくせるのはメリットとして大きそうだった

Cloudflare Workers + R2で低コストで画像配信を移行した話

speakerdeck.com

  • Cloudfront + S3 に対するソリューションの1つとして Cloudfrare Workers + R2 ケースの紹介
  • r2
    • s3互換
    • s3に劣る部分はある、当てはまらない場合は検討できる
      • IAM/トークン単位でのアクセス制御できない
      • バケットのバージョニングできない
      • S3 Glacier のようなストレージクラス概念ない
  • 円安でのコスト増加への対策
  • これまでの構成
    • cloudfrontの後ろにnginx、basic auth、s3の構成だった
  • そもそもr2配信でworkers必要?
    • public buckets機能がでたのでシンプルな配信なら不要
  • workers を使うとpath mappingなど複雑な処理がedgeでできる
  • キャッシュは?
    • kv を検討したが、従量課金でコストかかる
    • cache api を使った
  • コストより柔軟な画像リサイズなどやりたいなら cloudfrare imagesを使うと良い
  • 移行の際はトラフィック料金がシビア
    • s3とr2はダブルライトした
  • 他スピード早くメモが追いつかず。移行のtipsがめっちゃ詰まってた
  • ペインを移行によって解決できていてすごい
    • コスト削減含め

Server Side JavaScript のためのバンドル最適化

speakerdeck.com

  • (前提破壊)制限が5MBから10MBになった
  • サーバサイドでバンドルするメリット
    • 起動高速化
    • CI
    • セキュリティ
  • デメリット
    • sourcemap で複雑化
  • v8 isolate で120MBのメモリを割り当ててスクリプトを実行
    • chrome のタブ1つに相当
  • パフォーマンスバジェットという考え方
    • バンドルサイズの上限をチームで合意しようね

gRPC Client on Cloudfrare Workers

speakerdeck.com

  • gRPC を cf-worker で動かす事例

まとめ

Cloudfrare Workers が何かもわからない状態で行ったので豊富な事例を聞いて活用方法はいろいろあることがわかった

勉強会参加メモ - 【有料プランユーザー様限定×オフライン】MagicPodユーザーLT会

trident-qa.connpass.com

普通に会社名義で出たので会社ブログを書けという話だが、個人の学びとして他の人の発表で感じたことメモしておきたいので書く。

MagicPodでFlutterアプリをテストする

Flutter から遠い生活をしているので特に思ったことはないが、サポートできる Platform を増やすことは E2E Test SaaS ベンダーとしては重要だが、Flutter という Native から1段階 wrap しているものをサポートするのはかなり苦労があるんだなーと思った。

MagicPodで始める がんばらない回帰試験の自動化

speakerdeck.com

  • 自動化の導入コストは当然かかる
  • MagicPod のベストプラクティスは知らなかった
  • 実際に経験してみて自動化が難しいものとそうでないものを切り分けられたのは良い学びだと思う
  • kintone 普通に metrics を食わせて表示できるんだーってのがびっくり
    • 後の自分の発表言うことないな、ってなっちゃった
  • issue ちゃんと書いているの大事

『スタディサプリ 中学講座』における E2E Test の運用と計測による改善

所属チームのこれまでの軌跡が話されてよかった 合わせてブログ書きたい 「開発チームが自ら自動テストを書き、メンテしている。QA はサポート」というのはもっとアピールしたい。 質疑でも補足したけど tatto さんの丁寧なサポートと品質リードへのファシリテーション、そういった役割を踏まえて組織したマネジメントが合わさって成し遂げられていることだと思う

自分の資料はこっち

speakerdeck.com

github.com

「計測されていると、改善したくなる」が一番言いたかったことかもしれない。

あと Web だからか、E2E が15分ってめっちゃ短いほうなのね、ってわかったw

そういえば Duration seconds 的なのも API で取れると嬉しいと言う話をして issue を書いてもらった。

github.com

みてねの安定リリースを支えるMagicPod活用状況

speakerdeck.com

  • QA からはじめて開発チームに認知が広がったのはいい話
  • 共有ステップを使いこなすのすごいと思うけど、副作用もあると思った
    • 共有ステップの管理とその周知はどうやっているのだろう
    • QA チームが少人数だとコミュニケーションでうまくやれるのかもしれない

高い開発生産性を実現するために取り組んだMagicPodの利活用

speakerdeck.com

  • 実行方法の整理は見事で、特にデプロイ前と定期実行でテストケースを分けている点は見習える点があるなと思った
  • Jimbo さんと懇親会でも話したけど、デプロイ前はマジで重大障害につながるクリティカルなところだけにすることで、開発速度を止めない
    • 逆にそれ以外定期実行の「最悪3時間」で気づけるものはデプロイブロックしない、というのは言うは易しというか、うまく問題起こさずにできているのはすごいと思う
    • CI で PR マージ前実行でも5分ならまぁ我慢できるなと思う

自動テストを社内へ浸透させた話

speakerdeck.com

  • 手動テストと自動テストをどう棲み分けるのか、そのガイドなり考え方なりを発信するのは大事だと思う
    • 100% は無理
  • 特にレコチョクさんの扱うような音楽再生みたいな、メディアが関わるものは難しいですよね

まとめ

懇親会も楽しかったです。ありがとうございました。 発表させて、といって当日までつなげてくれたコミュニティマネージャの田上さん、懇親会で会話させていただいた伊藤 CEO 他みなさんありがとうございました。

引き続きよろしくお願いします。何かあったら Issue 書きます。

勉強会参加メモ - 開発生産性 Conference

dev-productivity-con.findy-code.io

From Metrics to Mastery: Improving Performance with DORA and the SPACE Framework

  • SPACE フレームワークはかなり有益だと思った
  • あらゆる metrics・評価指標自体の評価ができるメタフレームワーク
  • DORA のページがある DORA | DevOps Research and Assessment
  • SPACE Framework
    • S: Satisfaction and well-being
    • P: Performance
    • A: Activity
    • C: Communication and collaboration
    • E: Effectivity and flow
  • 多面的に評価できるので、トレードオフを考えられるので良い
  • 特に flow に入れるかどうかは satisfaction にも影響を与えると思う
  • 計測方法はヒアリングしかないなーと思うのでここをうまくやりたい

組織をスケールさせるためのFour Keysとチームトポロジー

speakerdeck.com

  • 適切な摂理面の探索、どうすればいいんでしょうねぇ
    • バリューチェーンでわけても上流下流が密に影響する場合そこで分けられないのはそうだと思う
    • 戦略的にモノリスにしているのは賢いと思う
  • ダブルループ学習を推奨するのは良さそう
    • 結局やって学んでいくしかない

なぜ Four Keys を改善するのか? 〜How ではなく Why を重視したメトリクス改善活動〜

speakerdeck.com

  • 発表が上手だった
  • 資料もわかりやすい、参考にしたい
    • 伝えたいことが1スライドで明確
    • 文字だけでなくアイコンは図を使っている
  • 0から最終的にオーナーシップを渡せるまでの旅路が描かれていた、これからやる人は参考にできそう
  • 各メトリクスはつながっているの、そうなんですよね

The Metrics Key: Connecting Product, System, Team

speakerdeck.com

  • 1番聞けてよかったセッション
  • DMM さんは組織規模的にも先を行っているので参考にしている
  • 基本の基本で「計測」かなりちゃんとしていおる印象、ここまでできてないなぁと反省
    • 工数、予算、品質の観点で調査していてすごい
  • "「不確実性が高い」という言葉を計画、計測、学習を適切に行なっていない言い訳にしない” 肝に銘じます
    • 可観測性と再現性を作る、100回言いたい
  • Metrics の整理が素晴らしかった
    • 事業、プロダクト、システム、チーム
    • 事業、システム、組織、という整理を自分でしていたが、プロダクト軸と、それぞれの指標例が載っていてありがた
  • 有効稼働率を計測しているのは驚いた、できる気がしない。..
    • 勤怠管理ツールと接続するとは。..

これからのソフトウェア開発 "GitHub x AI" による生産性革命

copillot X は相当便利だなーと思った 早く使いたい。

行政府の開発生産性向上のアプローチと、目指す未来

各自治体で分かれている中で DX を進めていくのは並大抵のことではない、尊敬の念です。

大規模言語モデル時代の開発生産性

資料だけ見ました。素晴らしかった。

speakerdeck.com

  • 開発生産性の3つのレベルと組織の関係 p19 がわかりやすい
    • 開発部の目標、事業の目標はわけて考えないといけない
  • p24 もわかりやすい
    • Engineering Manager, Product Manager, Sales/Maketing Manager の役割がよくわかる
    • GP = Gross Productivity
  • p34 定性目標、定量目標、「健全化指標」という整理もよかった
  • AI 時代に関連すると、AI エージェントが何をし、人間が何をやるのかを理解して取り組む必要がある
    • 実際にツールを書いて検証していてすごい

まとめ

所属会社でもこの領域に取り組んでいるため良質なインプットを得られてよかった。 自分の取り組みを省みて、今後の方向性を考えたい。