LLM時代の少人数開発における、プロダクトエンジニアによるSRE取り組み
Hiroyuki Moriyaさん(IVRy)
https://speakerdeck.com/gekko0114/shao-ren-shu-purodakutokai-fa-nioite-sreye-wu-wozeng-yasanaigong-fu
- LLMで少人数でもプロダクトを作れるようになった
- スタートアップにとっては追い風
- 人が少ないと
- 運用に手が回らない
- 1個1個が小さなプロジェクトでもちゃんと運用すると大変
- IVRy Analytics
- コミュニケーションデータを事業示唆にするSaaS
- 電話のデータを活用
- 音声という非構造データを定量的に解析可視化
- 初期は3人で今は1人で開発
- アーキテクチャ
- 音声データをS3に
- それをバッチでLLMにかけてBigQueryに
- そのデータを参照
- SRE業務を増やさない工夫
- 顧客影響がない障害は優先度を下げる
- 即時でデータを可視化する必要がないプロダクト
- 前日分が見えてればOK
- バッチで失敗があっても前日分が見えればOK
- グラフなど複雑な機能のメンテにエンジニアの手をかけないように
- BigQueryを可視化するライブラリでiframeを埋め込む
- バックエンドもフロントエンドも手を入れなくていい
- 妥協してる部分もあるが
- AIエージェントが障害対応できる仕組み
- ハーネスエンジニアリング
- Datadog MCP Server
- 顧客影響がない障害は優先度を下げる
極端に遅いリクエストとの戦い
島根雄也さん(ANDPAD)
https://speakerdeck.com/mane12yurks38/tamach-sre-3-andpad-shimaison93
- 数十秒から数分かかるようなHTTPリクエスト
- 最初は問題なくても徐々に劣化していくことも
- 遅いリクエストの事業へのインパクト
- 業務効率の低下
- 機会損失
- 社会的信頼の失墜
- 自社へのインパクト
- 収益悪化
- インフラコストの肥大化
- 市場競争力の低下
- 監視体制
- 2020年頃〜
- 対応が属人化して一部の人しか見てない
- 検知はしてるが影響の度合いが不明瞭
- 影響が見えてないので後回しになりがち
- 2021年頃〜
- CREに移管(Customer Reliability Engineer)
- ユーザが何をしたかったのかの文脈でログを解釈していくように
- ユーザの属性などを加味することで業務影響を判断し優先順位付け
- CREは開発者とBizの翻訳者として動ける
- 2024年頃〜
- エンタープライズ利用が開始しデータ量やユーザ数が増える
- 監視条件を詳細化
- 人力が厳しくなってくるので自動化
- 2020年頃〜
- 改善
- 検知する度に調査していたが検知数を集計して優先度判断
- どうなったらどこで誰にどう共有するか整理
- 検知 - 調査 - 共有 - 修正を繰り返しどう変わったか検証
- Datadogでログ取得
- 初検知か既知の問題か自働でスプレッドシートで管理
- 毎営業日Slackに通知
SLI/SLO導入で避けるべきこと3選
八木洸太さん(Money Forward)
- SLI/SLOの導入
- SREの課題
- 扱うプロダクト数が多い
- どこにリソースを割くか判断が難しい
- 開発チームの課題
- ユーザにいい体験を提供できてるか分からない
- データで把握したい
- SREの課題
- 導入の壁
- みんながSLI/SLOを知ってるわけではない
- 重要なのはわかってもどうして今必要か理解できない
- 組織の課題と紐づけるのが大事
- 同時に展開するのは難しい
- 多くのチームにいきなり対応を依頼しても対応は難しい
- スモールスタートしていくのがいい
- 意欲的な1チームから
- 試行錯誤の結果をテンプレート化へ
- そこから横展開
- 開発チームとSREで事前の合意をとっておく
- 半期プロジェクトに入っていないと割り込みになってしまう
- 期のタスクに含まれるようにマネージャーレベルで合意をしておく
- 共同プロジェクトとして進められるように
- みんながSLI/SLOを知ってるわけではない
カルチャーを仕組みに変える オンコール制度の作り方
近藤圭太さん(IVRy)
- オンコール対応
- 個別に手当がついたり制度があるところはそんなに多くない
- 当番
- ローテーション組んで交代で
- インシデント対応やアラートの1次切り分け
- オンコールの制度
- まずは運用の実績を作ってから
- PagerDutyで対応の実績を取得できる
- 労務や人事が相談先
- 報酬や休暇など運用が回るかどうか
- 社労士にも相談
- 待機時間の扱い
- 他のメンバーの自由を守るために自らの自由を制限してることへの報酬
- まずは運用の実績を作ってから
フリーが乗り越えてきたFinOpsの壁〜でもまだ一合目〜
北川卓図さん(freee)
https://speakerdeck.com/zukutakuzu/hurigacheng-riyue-etekitafinopsnobi-demomada-he-mu
- フリーでのFinOps
- 6原則
- ビジネス価値につながってるかが意思決定の基準
- タイムリーで正確であるべき
- オーナーシップ持って
- 3つの壁
- CostExplorerはRI/SP購入前の料金
- 知りたいのはオンデマンド料金の金額
- 組織横断で購入してると割引率のコントロールができない
- 金額口頭のリソース名を確認できない
- Looker Studioやredashとか使って対応
- Athenaで集計
- タグ表記の揺らぎ
- 統制してないとバラバラになってしまう
- フィルタリングや検索が難しくなる
- タグの修正後も連続して計測できるようマッピング
- tflintで制御
- コストオーナーシップ
- 管理チームに属人化してしまう
- プロダクトチームが見てくれない
- 実績確認を毎月やってもらって認識してもらうところから
- 予算策定までプロダクトチームでやってもらうところを目指してる
- CostExplorerはRI/SP購入前の料金
ecspressoのdeployめっちゃ早いよという話
@sugitak06 さん(estie)
- ecspresso
- ECSをいい感じに使うためのラッパー
- アプリケーション側のサイクルを受け持つ
- 最近速度が上がった
- デプロイ完了の確認の方法が変わった
- Services Stable
- サービスの安定化まで待機
- ECSにはdeployの概念がある
- Services Stable
- deployの完了を待つのではやく完了とすることができる
- 旧サービスを落とし切ったら完了
APIをリライトした時の失敗談 実行環境の差異が生んだ不具合と教訓
@rsym1290 さん(GMOペパボ)
- PerlとFastCGIを長年運用している
- APIをGoにリライトした
- リリース後不具合が発生
- 依存モジュールの排他制御の不備でレースコンディション
- 従来の構成では1リクエスト1プロセスだった
- リライト後ははプロセスを共有しメモリも共有
- 環境構成の前提を人もAIも見落としていた
- ガードレールやカナリアリリースなどの工夫も
