Restarting_SRE_Road_to_SRENext_.pdf

2025-03-28【JAWS東北支部共催】Road to SRE NEXT@仙台
https://sre-lounge.connpass.com/event/345125/
の登壇資料です

Transcript

1. 2025/3/28 Re:Starting SRE ~ KTC SRE が SRE として活動するために必要な X のこと ~ KINTO テクノロジーズ株式会社 粟田 啓介
2. ©KINTO Corporation. All rights reserved. 2 自己紹介 mysql > SELECT * FROM me \G *************** 1. row *************** name: 粟田 啓介 nickname: あわっち X(twitter): @_awache company: KINTO テクノロジーズ株式会社 role: DBRE/SRE MGR favorite: MySQL 1 rows in set (0.00 sec)
3. ©KINTO Corporation. All rights reserved. 3 KINTO テクノロジーズ株式会社 (KTC) について 2021年04月設立 2019年01月設立
4. ©KINTO Corporation. All rights reserved. 4 KTC における DBRE / SRE の立ち位置 エンジニア組織： 約 30グループ 社内のエンジニアの数： 約 350名 アプリケーション開発組織 • KINTO サービス開発 • グローバル ID 基盤開発 • バックオフィスシステム開発 • モバイルアプリ開発, etc. 横断組織 (プラットフォーム開発部) • QA • クラウドインフラ • DBRE / SRE • Platform Engineering • MSP (24*365 保守運用) プラットフォーム開発部 QA クラウドインフラ DBRE / SRE MSP アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 ・・・ Platform Engineering
5. ©KINTO Corporation. All rights reserved. 5 お品書き 1 Reliability Engineering と DevOps/Platform Engineering 2 SRE のマネジメント 3 KTC SRE のアクティビティ 4 KTC SRE のこれから 5 まとめ
6. ©KINTO Corporation. All rights reserved. 6 Reliability Engineering と DevOps/Platform Engineering 1
7. ©KINTO Corporation. All rights reserved. 7 KTC の横断組織 プラットフォーム開発部 QA クラウドインフラ DBRE MSP アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 ・・・ Platform Engineering SRE KTC 内でも元々は SRE の機能は別組織にあった
8. ©KINTO Corporation. All rights reserved. 8 KTC の SRE チームの歴史 2021 年 2022 年 2023 年 2024 年 • インフラチーム内に SRE チームを発足 • Terraform の共通モジュール化を推進 • インフラ環境構築を 2週間から条件がそろえば 30分程度まで短縮 • SRE チームの役割を Embedded SRE に位置付け • 「データに基づいたポストモーテムを実施し、具体的なアクションプランを決定する土台を作る」 ことをPhase1の目標として活動開始 • SRE ハンドブック作成 • KTC の技術スタックに基づいた具体的な SRE アクティビティを定義し、実践可能な手順を示す • プロダクト導入時に信頼性向上のサイクルを再現性を持って実現できる状態にする • SRE ミッションビジョン策定 • SREチームのミッション・ビジョンを決めた話 • DBRE とグループ統合
9. ©KINTO Corporation. All rights reserved. 9 SRE ハンドブック
10. ©KINTO Corporation. All rights reserved. 10 KTC SRE のミッション・ビジョン・バリュー • ミッション • 信頼性の高い価値あるプロダクトを最速で提供できるようにする • ビジョン • サービスレベルに基づいた開発と運用のバランスが取れた組織の実現 • バリュー • フィードバックループを大切にする • オペレーションの継続的改善 • 計測に基づいた判断
11. ©KINTO Corporation. All rights reserved. 11 KTC の横断組織 プラットフォーム開発部 QA クラウドインフラ MSP アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 ・・・ Platform Engineering 2024年11月に DBRE と SRE を統合し同じ組織に DBRE / SRE
12. Reliability Engineering と DevOps/Platform Engineering の違いとは？
13. ©KINTO Corporation. All rights reserved. 13 僕が SRE の MGR をすることになって自分自身に最初にした問い この問いに答えられないと自分の中で SRE をマネジメントしていくことができない ◼ SRE の他にクラウドインフラ、プラットフォームエンジニアリングの組織がすでに存在 ◼ これらの組織との役割の違いを答えられるようにならないと企業としてうまくいかない ◼ 何よりもこの問いに答えられないと SRE の組織自体が不要といわれてしまう プラットフォーム開発部 QA クラウドインフラ MSP アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 ・・・ Platform Engineering DBRE / SRE
14. ©KINTO Corporation. All rights reserved. 14 Reliability Engineering と DevOps/Platform Engineering Reliability Engineering と DevOps/Platform Engineering はタスク注力の方向が違う 1. DevOps のストーリーは、開発者がラップトップにコードを打ち込むところから始まります。DevOps は(とりわけ)、顧客がそのコードから最大の価値を享受できるように、その コードを本番環境に提供するためには何が必要かを考えます。注目の方向は、ラップトップから本番稼働に向かっています。継続的インテグレーションと継続的デリバリー (CI/CD) システムが、DevOps の道具箱、スキルセット、そして採用広告でこれほど重要な位置を占めている理由の一つは、ここにあると推測できるかもしれません。 2. SRE は異なる場所から始まります。SRE は本番環境から始まります(実際、SRE の意識は本番環境にあります)。信頼できる本番環境を構築するために、SRE は何をしな ければならないのでしょうか。この問いに答えるには、本番環境から「後方」に目を向け、開発者のノートパソコンに辿り着くまで、この問いを一歩一歩問いかける視線が必 要です。 3. 注目する方向が異なります。同じツール(例えば CI/CD パイプライン) を使うかもしれませんが、その理由は異なります。DevOps と SRE はどちらも監視システムの構築に大 きく関与するかもしれませんが、異なる理由で監視を行なっている可能性があります。 引用：SRE をはじめよう
15. ©KINTO Corporation. All rights reserved. 15 SRE の本質を捉えるための注力点を定義 あくまでも自己解釈です ◼ Platform Engineering ◼ 開発者がラップトップ上で描いたコードを本番環境に届ける「生産ライン」の整備 ◼ CI/CD パイプラインや開発環境の最適化を通じて、開発者体験の向上に焦点を当てる ◼ 本番環境へとすすむ「流れ」を安全・高速にする「足場」の構築 ◼ SRE の注力点 ◼ 本番環境の信頼性と安定性にフォーカス ◼ 本番環境からラップトップへ「逆向き」に視線を遡り、問題を解決する ◼ 信頼性を構築するための問いかけを繰り返す ◼ DBRE の注力点 ◼ データを中心に据えた視点で、本番環境の「信頼性」「可用性」「継続的成長性」を確保 ◼ データフローの歪みやリスクを分析・改善し、データの滞りなく活用できる状態を維持 ◼ Platform Engineering や SRE のツールチェーンを活用しつつも、 データベース特有の課題(スケーラビリティ、整合性、セキュリティなど)に取り組む
16. ©KINTO Corporation. All rights reserved. 16 KTC における各グループの役割 各グループの立ち位置 ◼ クラウドインフラ ◼ プロダクトが必要とするインフラ環境を素早く安全・安心な状態で提供 ◼ Platform Engineering ◼ 各プロダクトのエンジニアが素早くリリースを行うための共通基盤の提供 ◼ SRE ◼ 各プロダクトで発生した課題を発生した事象を元に解決を伴走する ◼ DBRE ◼ データベースを中心としてサービスレベルやエンジニアの生産性向上への寄与を行う
17. ©KINTO Corporation. All rights reserved. 17 KTC における各グループの役割 各グループの立ち位置 クラウドインフラ Platform Engineering SRE DBRE
18. ©KINTO Corporation. All rights reserved. 18 SRE をマネジメントするためにおこなったこと 2
19. ©KINTO Corporation. All rights reserved. 19 思考の整理 なぜ KTC に SRE が必要なのか？ ◼ これまでの SRE の活動 ◼ Terraform の共通モジュール化 ◼ クラウドインフラの部隊に引き継ぎ ◼ Embedded SRE ◼ 興味を持っていただいたグループに対して細々と SRE 活動を実践 ◼ あまり大きな成果を出せていたわけではなく問い合わせベースの活動になってしまった ◼ SRE Handbook ◼ 完成度は高かったがなかなか読まれるタイミング、きっかけがない SRE は KTC にとって良い影響を与えていたのか？
20. ©KINTO Corporation. All rights reserved. 20 思考の整理 実際のマインドマップ
21. ©KINTO Corporation. All rights reserved. 21 メンバーへの期待値セット SRE としては新任 MGR ◼ 自分が何をメンバーに期待しているのかをはっきりさせる ◼ 同時に自分が MGR として SRE に何をもたらすことができるのかを明示する
22. ©KINTO Corporation. All rights reserved. 22 SRE が KTC に良い影響を与えるための第一歩 ビジネスへの影響を最小限に抑える ◼ 見えないものは管理できない ◼ システムの状態を可視化し、正常が分かっているからこそ異常がわかる ◼ リアルタイムな影響把握で迅速な意思決定を行う ◼ 根拠ある改善と予防策の策定を可能にする まずはモニタリングとインシデントレスポンスから！
23. ©KINTO Corporation. All rights reserved. 23 オブザーバビリティツールの導入 プロダクト組織に対して SRE が機能する状態を作る ◼ どんなプロダクト組織であっても適切に SRE 活動ができる状態になること ◼ これまでの SRE はプロダクト組織に対して価値提供できているか自信を持って言えなかった ◼ システムの状態がわからない、わかりづらい状態だと本当に価値が出せているかすら判断できない ◼ 共通のツールがあることでプロダクトの状況を素早く把握することができる
24. ©KINTO Corporation. All rights reserved. 24 SRE のアクティビティ 3
25. ©KINTO Corporation. All rights reserved. 25 New Relic の強力な推進 なぜ New Relic を推進したのか ◼ SRE は可視化をした先にどのように課題を発見しアクションできるかが重要 ◼ 全体を見える化してユーザー体験と課題発見の効率を改善するためのセットが揃っている ◼ これまで KTC では標準の監視プラットフォームとして OpenSearch + Grafana を活用はしていたが。。。 ◼ 可視化をすることを目的にしない、その先にあるものを見る ◼ 素早いオンボーディングの実現 ◼ この業界では New Relic か Datadog を使っている企業が多い ◼ 新しく来た方が New Relic を使った経験があればその経験はそのまま活きる
26. ©KINTO Corporation. All rights reserved. 26 プロダクト組織への New Relic 導入サポート ペアプロ 〜 Daily MTG での状況確認が定着するまで ◼ 導入して終わりではなく日々の運用に取り入れられることで価値になる ◼ オブザーバビリティツールは使われてこそ意味がある ◼ 運用に定着すれば、異常の予兆に気づけるようになる ◼ 感度が上がることで重大トラブルを未然に防ぐ力がチームに根付く SRE はプロダクト組織に対してこの価値を届けることで信頼関係を築く
27. ©KINTO Corporation. All rights reserved. 27 プロダクト組織への New Relic 導入サポート SRE の支援的アプローチと価値 ◼ SRE が伴走して「見る文化」をプロダクト組織とともに作る ◼ ペアプロを含めさまざまな形でダッシュボード・アラート設計を支援 ◼ Daily MTG で状況確認の習慣をプロダクト組織に定着 ◼ ツールを自分たちの武器として使いこなせる状態へ ◼ 使われるオブザーバビリティツールにすることで ◼ アラートへの即応力が高まる ◼ 変化に敏感なチーム文化が生まれる ◼ プロダクトの安定運用と品質向上に寄与
28. ©KINTO Corporation. All rights reserved. 28 プロダクト組織への New Relic 導入サポート SRE も AI を積極活用中 ◼ インシデントレスポンスの確実性を高めるツール ◼ New Relic の Trace ID から関連するログとトレース情報をサマリ何が起こっているのかを出力
29. ©KINTO Corporation. All rights reserved. 29 プロダクト組織への New Relic 導入サポート New Relic をきっかけとして SRE の支援の輪を社内に拡げている 導入に向け調整中の組織
30. ©KINTO Corporation. All rights reserved. 30 KTC SRE の今後の展望 4
31. ©KINTO Corporation. All rights reserved. 31 SRE が SRE として活動するための種まきはできつつある もっと直接的に SRE が価値を提供できるようにするためにはどうしたらいいか ◼ 今はまだ、複数のプロダクト組織に対して展開しているフェーズ ◼ SRE が価値を届けるための前提条件を築いている段階 ◼ SRE が最大限に価値を発揮するのはプロダクト組織の中に根差した時 ◼ なぜならプロダクト毎に状況も SLI も異なる ◼ 標準的に整備する “だけ” では Platform Engineering の領域と変わらない
32. ©KINTO Corporation. All rights reserved. 32 僕が考える KTC における本質的な SRE の役割とは 伴走して個別最適を体現すること ◼ SRE はプロダクト毎の文脈・特性に深く入り込むことが重要 ◼ テンプレートではなく、それぞれのプロダクトに最適な形を考え抜く ◼ つまり SRE は個別最適化を推進する存在としての進化が必要なのではないか？ ◼ 現状の SRE はまだ横断組織としての動きにとどまっている ◼ 将来的には各プロダクト組織に SRE チームが組成され、 今の SRE がその立ち上げ、リードを担っていくフェーズに進んでいってほしい ◼ それが成功すれば自然とプロダクト内で SRE の採用が始まり、SRE が文化として定着する
33. ©KINTO Corporation. All rights reserved. 33 まとめ 5
34. ©KINTO Corporation. All rights reserved. 34 KTC SRE は進化し続ける ◼ SRE の現状 ◼ SRE はオブザーバビリティツールの導入をプロダクト横断で整備中 ◼ これは SRE が SRE として機能するための地盤作りのフェーズ ◼ 見えてきた課題 ◼ オブザーバビリティツールの導入だけでは個別課題に踏み込めない ◼ プロダクト毎に最適な信頼性の形が必要 ◼ これからの戦略 ◼ SRE は 横断 から 個別 へのシフトチェンジが必要 ◼ プロダクト毎に SRE チームの立ち上げを視野に現 SRE メンバーがその起点・リーダーになる 信頼性をリードする存在になるとともに SRE 活動が組織に根付き KTC の自然な文化となる
35. Road to SRE Next ! ということで この後 CfP 出す予定です、ぜひ応援してください！！
36. Thank you！