IVRyのSREが始まって1年

SRE Lounge #19

Transcript

1. IVRyのSREが始まって1年 2025/11/19 SRE Lounge #19 abnoumaru @ IVRy Inc.
2. 2 ⾃⼰紹介 - ハートビーツ→スリーシェイク→IVRy - 2024年10⽉⼊社 - 2025年1⽉からSREのリーダー id: abnoumaru Software Engineer - 部活動 - #club-idol - #club-radio
5. SREの”チームとしては” 2026年1⽉で2年⽬に突⼊🎉 5
8. IVRとAIであらゆる電話対応を効率化 「アイブリー」 8
9. 9 Mission 最⾼の技術を、すべての⼈と企業に届ける IVRyが考える「最⾼の技術」とは、新鮮な驚きをもたらしながらも⽇常に溶け込み、 いつの間にか⼈々に寄り添うテクノロジーです。 地域や企業規模を問わずに提供し、 その先にいる⼀⼈ひとりがその価値を実感できる環境を共に育んでいきます。 経済活動におけるあらゆるコミュニケーションをシンプルにすることで、すべての⼈ の⾃由を創造し、“Work is Fun”な社会を実現します。 Vision Making “Work is Fun” a reality. 
 “働くことは、楽しい”を常識に変えていく 「働く時間を、もっと楽しく」 私たちは、⾃らの仕事の本質に向き合い、夢中になって取り組むことで、働くことは 喜びに溢れたものになると信じています。 IVRyは、テクノロジーの⼒で⼈が⼈としての価値を最⼤限に発揮できる環境を創り出 し、「働くことは楽しい」が当たり前の世界を実現します。 そして私たち⾃⾝も、お客様が仕事を楽しむ姿を⾃らの喜びとし、期待を超える感動 を届け続けることで、“Work is Fun”を体現し続けます。 Vision/Mission
10. 10 SREの1年 ⾜回り整え期 うまくいかないを 繰り返す 知らないを知る
11. ⾜回り整え期 11
12. 12 Terraformのレポジトリが激しく改善され始める様⼦ - 開発に必要なリソース追加に加えて2024年9⽉からインフラのレポジトリの改善が活発に - リソースの修正/削除/import、CIの整備、タグ付け、フォーマットの変更... - ⼈数も増えてより安全かつスピードを出せる状態にしていく - （2025/09〜2025/01は renovate[bot] が元気だったので下駄履いてるけど...）
13. 13 SLOのダッシュボードを作ってイテレーションを始める - 通話や電話履歴に関するエンドポイントでSLOを始める - 性能劣化を検知できたこともあった - ただいま思えばサービスの特徴を捉えきれていなかった(後述) - イテレーションを回してSLOが組織に存在し始めたし仕組みが出来たのは👍 - モバイルアプリチームが⾃分たちでSLO策定を始めてくれたときが⼀番嬉しかった
14. 14 オンコールの整備や依頼対応の仕組み化 - オンコールの仕組みや制度が整備された - 依頼対応はSlackのワークフローで集約→LinearでIssue化 - LinearのTriage responsibilityとPagerDutyを連携してて1stのメンバーが⾃動でアサインされる - 知識がまんべんなく共有されたり負荷が分散された
15. 15 インシデント対応のbotを内製 - 組織やサービスが⼤きくなるにつれて対応にばらつきがでる - botを作って型化することでインシデント対応を迷わず充⾜してできるように
16. 16 インシデントや⾼負荷について全社で説明 - ⼤量に電話が来た場合にサービス全体を守る仕組みや有事の際の対応を整備 - 着電量が多い利⽤が予想される場合のヒアリングシートやフローを整備 - 全社のメンバーが集まる場で⾼負荷について話した
17. 知らない、を知る 17
18. 18 未知のインシデントと出会うことで知らない、を知る - 1年⽬SREs、インシデント対応のたびにプロダクトについてまだ知らない部分に気づく - この機能...どう動いてるんだ...？ - 外部のLLMは思ったより落ちる（フォールバックの仕組みを⽤意） - 裏でこんなジョブが動いてるんだな - ユーザからの問い合わせで利⽤者⽬線のジャーニーをより深く理解する（SLOの⾒直し） - 事業の成⻑も⾒据えた既存のアーキテクチャの伸びしろも⾒えてくる - インシデントからしっかり学びは溜まっていく
19. 19 プロダクトを触る - 基本的にアイブリーから電話してる - 電話番号は名刺に設定してる - プロダクトの機能を触ることでこれどうやって動いてるっけ...って知る機会が増える
20. 「うまくいかない」を繰り返す 20
21. 21 「うまくいかない」を繰り返す - 定期的にSLOを確認していると⾒直しの案が出てくる - HTTPSのエンドポイントのレスポンスやエラー率では測れない部分の追加が必要 - 不具合に”仕組みで”気付けるカバー範囲もどんどん増やしていきたい（機能がたくさん） - SREが外から何かを改善しようとしても理解が⾜りていない
22. プロダクト「アイブリー」の 難しさ
23. 23 ref: https://speakerdeck.com/ivry/ivry-culture-deck
24. 24 電話×AIのサービス - アイブリーの⼊⼝は対話型⾳声AIのアプリケーション ref: https://speakerdeck.com/ivry_presentationmaterials/dui-hua-xing-yin-sheng-aiapurikesiyonnoxin-lai-xing-xiang-shang-noqu-rizu-mi
25. 25 通話後に様々な処理が⾊々な場所で実⾏される - SMS送信、⽂字起こし、要約、電話転送、通知、料⾦計算... - 通話後のデータを活かすためのデータ連携、データ加⼯、分析、ラベリング... - 例えばSLO⼀つ考えても処理ごとに仕組みを把握したり計測⽅法検討する必要がある
26. 結論：まだ全然整え期 26
27. 27 “難しさ”とどう向き合うか？
28. SREがプロダクトに 染み出していく
29. 29 SREがプロダクトに染み出していく - スタートアップの時間は限られている - 結果を出すため、ときに勢いのある意思決定が必要 - SREもプロダクト開発しよう、Embedded SREで専任をつけていこう - よりプロダクトの近くそして内側からSREのプラクティスを浸透させるという判断 - SREのチームが出来て半年が経った頃の話 - 会社のValue「Beyond the Wall」に通じる
30. SRE Team Product Team SRE PdM Designer Engineer SRE 留学制度 30 - オンコールからも⼀度外れてプロダクトチームに所属して開発を⾏う - 開発の中でいまあるリリースエンジニアリングやサービスの課題を体験する - 実際に開発をする中で課題を⾒つけてリリースに関する改善する動きが⽣まれた🎉
32. SRE Team Product Team SRE SRE PdM Designer Engineer Embedded SRE 32 - プロダクトチームの近くでSREのプラクティスを実践する - 事業計画やプロダクトの特徴をより理解して信頼性と向かい合う - プロダクトの理解が進みドメイン固有の課題をより深く理解🎉
33. 33 ref: https://zenn.dev/ivry/articles/a80997cd465d98
34. 現在 34 電話/AI対話 バックエンド モバイルアプリ Product B セキュリティ O11y インシデント レスポンス フロントエンド ⾮同期ジョブ データ基盤 認証基盤 ログ基盤 Product A 開発者体験 Product C - SREのラベルが付いたメンバーがプロダクト開発や特定ドメインのチームに入り込んでいく - 将来を見据えた基盤づくりをするために Platform Engineeringのチームが爆誕
35. ⾃分の働き⽅の変化 35
36. 初期 36 - ⼿も動かすけどリーダーとしてチーム作りや回る仕組みづくりを優先 - プロダクトや会社の構造を理解する - 周囲のメンバーとコミュニケーションを取りSREの関⼼事/⽂化/考えを知ってもらう - SREに関することはこの⼈に聞けば良さそう！となる（SREの顔になる） - SREとはなにか？IVRyのSREで⼤事なことは？の認識合わせ（ex. OKR、意思決定） - ロードマップづくりを主導する - ドキュメントや会議の整備 - 採⽤ - イベント対応
37. 整備によってSREにも⻑期⽬線の共通認識が⽣まれてくる 37 - 前述のようにいろいろ整備によりSREの共通認識が出来た - 全⼈類が電話をかけてきても耐えられるサービスを⽬指す - 適切にサービスの価値を届けられているか？を⽰す共通の指標をつくる - 運⽤する組織ではなく運⽤する仕組みをつくる組織 - 認識が揃ったのであとはみんな⾛れる🏃 - 「電話が⼤量に来たことを想定するといま携わっているプロダクトの改善点は？」 - 「ユーザに届いてる価値を表現するためにこのメトリクスが必要だ」 - 「これはトイルになってるから仕組みを作ってみました」
38. 整備もできた頃こんな出来事があった 38 - 今年の夏ぐらいに受け取ったタスク - 価値検証フェーズのプロダクトのインフラを作ることになった - PdMがすでにモックを作っていたけど社内検証やデモのためのインフラが必要 - 移植するためにしっかり踏み込んでプロダクトの仕様を調べたりコードを書いて環境を準備した - フィードバック（意訳） - めっちゃプロダクト開発したそうですね？チャンス作ったほうがいい - 会社のフェーズ的に⼿を動かして仕組み作りしよう - 現場で共通認識を体現したいフェーズ - この体現はリーダーももちろんやる - 結果として、現在⾃分は新しい⽂字起こし基盤を開発しながら信頼性と向かい合ってる
39. 対話型⾳声AI SaaSアイブリーの⽂字起こし 39 - 電話で会話した内容が⽂字起こしされてクライアントの画⾯から参照できる - この⽂字起こしの結果が要約など後述の処理にも利⽤される
40. 新しい⽂字起こし基盤を開発 40 - 経緯 - 新機能を追加する流れ - 既存の課題を解消できる基盤に刷新したい - Step Functionsにしていろいろ解決 - ⽂字起こし外部サービスの⼊れ替え/選択を実現 - 新しい処理も追加しやすい - 状態をまとめて追えるようになる - パフォーマンスもまとめて追えるようになる - 再実⾏しやすくなる - 成功した割合を出しやすくなる（SLOになる！） - みんなに教えてもらいながら開発のサイクルで働いてる
41. まとめ 41 - IVRyのSREの1年は「⾜回り整え期」「知らないを知る」「うまく⾏かないを繰り返す」 - プロダクト特有の難しさをしっかり理解し始めたがまだまだ整えることがたくさん - 難しさに向き合うためにSREのラベルがついたメンバーがプロダクト、プロジェクト、プラットフォー ムに⾶び込んで信頼性や必要な基盤づくりに向かい合っている - SREのリーダーとして様々なことを整理する中で共通認識が⽣まれてきた - 共通認識を体現するフェーズで⾃分も開発に⾶び込んでプロダクトの信頼性に向かい合ってる
42. IVRyエンジニア⼤忘年LT⼤会 2025(12/16) 42 - https://ivry.connpass.com/event/374154/
43. 43 We are Hiring!