Restarting_SRE_Road_to_SRENext_.pdf

Slide 1

Slide 1 text

2025/3/28 Re:Starting SRE ~ KTC SRE が SRE として活動するために必要な X のこと ~ KINTO テクノロジーズ株式会社粟田啓介

Slide 2

Slide 2 text

©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)

Slide 3

Slide 3 text

Slide 4

Slide 4 text

©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

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

©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 とグループ統合

Slide 9

Slide 9 text

Slide 10

Slide 10 text

©KINTO Corporation. All rights reserved. 10 KTC SRE のミッション・ビジョン・バリュー • ミッション • 信頼性の高い価値あるプロダクトを最速で提供できるようにする • ビジョン • サービスレベルに基づいた開発と運用のバランスが取れた組織の実現 • バリュー • フィードバックループを大切にする • オペレーションの継続的改善 • 計測に基づいた判断

Slide 11

Slide 11 text

©KINTO Corporation. All rights reserved. 11 KTC の横断組織プラットフォーム開発部 QA クラウドインフラ MSP アプリケーション開発組織アプリケーション開発組織アプリケーション開発組織アプリケーション開発組織アプリケーション開発組織・・・ Platform Engineering 2024年11月に DBRE と SRE を統合し同じ組織に DBRE / SRE

Slide 12

Slide 12 text

Reliability Engineering と DevOps/Platform Engineering の違いとは？

Slide 13

Slide 13 text

©KINTO Corporation. All rights reserved. 13 僕が SRE の MGR をすることになって自分自身に最初にした問いこの問いに答えられないと自分の中で SRE をマネジメントしていくことができない ◼ SRE の他にクラウドインフラ、プラットフォームエンジニアリングの組織がすでに存在 ◼ これらの組織との役割の違いを答えられるようにならないと企業としてうまくいかない ◼ 何よりもこの問いに答えられないと SRE の組織自体が不要といわれてしまうプラットフォーム開発部 QA クラウドインフラ MSP アプリケーション開発組織アプリケーション開発組織アプリケーション開発組織アプリケーション開発組織アプリケーション開発組織・・・ Platform Engineering DBRE / SRE

Slide 14

Slide 14 text

©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 をはじめよう

Slide 15

Slide 15 text

©KINTO Corporation. All rights reserved. 15 SRE の本質を捉えるための注力点を定義あくまでも自己解釈です ◼ Platform Engineering ◼ 開発者がラップトップ上で描いたコードを本番環境に届ける「生産ライン」の整備 ◼ CI/CD パイプラインや開発環境の最適化を通じて、開発者体験の向上に焦点を当てる ◼ 本番環境へとすすむ「流れ」を安全・高速にする「足場」の構築 ◼ SRE の注力点 ◼ 本番環境の信頼性と安定性にフォーカス ◼ 本番環境からラップトップへ「逆向き」に視線を遡り、問題を解決する ◼ 信頼性を構築するための問いかけを繰り返す ◼ DBRE の注力点 ◼ データを中心に据えた視点で、本番環境の「信頼性」「可用性」「継続的成長性」を確保 ◼ データフローの歪みやリスクを分析・改善し、データの滞りなく活用できる状態を維持 ◼ Platform Engineering や SRE のツールチェーンを活用しつつも、データベース特有の課題(スケーラビリティ、整合性、セキュリティなど)に取り組む

Slide 16

Slide 16 text

©KINTO Corporation. All rights reserved. 16 KTC における各グループの役割各グループの立ち位置 ◼ クラウドインフラ ◼ プロダクトが必要とするインフラ環境を素早く安全・安心な状態で提供 ◼ Platform Engineering ◼ 各プロダクトのエンジニアが素早くリリースを行うための共通基盤の提供 ◼ SRE ◼ 各プロダクトで発生した課題を発生した事象を元に解決を伴走する ◼ DBRE ◼ データベースを中心としてサービスレベルやエンジニアの生産性向上への寄与を行う

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

©KINTO Corporation. All rights reserved. 19 思考の整理なぜ KTC に SRE が必要なのか？ ◼ これまでの SRE の活動 ◼ Terraform の共通モジュール化 ◼ クラウドインフラの部隊に引き継ぎ ◼ Embedded SRE ◼ 興味を持っていただいたグループに対して細々と SRE 活動を実践 ◼ あまり大きな成果を出せていたわけではなく問い合わせベースの活動になってしまった ◼ SRE Handbook ◼ 完成度は高かったがなかなか読まれるタイミング、きっかけがない SRE は KTC にとって良い影響を与えていたのか？

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

©KINTO Corporation. All rights reserved. 22 SRE が KTC に良い影響を与えるための第一歩ビジネスへの影響を最小限に抑える ◼ 見えないものは管理できない ◼ システムの状態を可視化し、正常が分かっているからこそ異常がわかる ◼ リアルタイムな影響把握で迅速な意思決定を行う ◼ 根拠ある改善と予防策の策定を可能にするまずはモニタリングとインシデントレスポンスから！

Slide 23

Slide 23 text

©KINTO Corporation. All rights reserved. 23 オブザーバビリティツールの導入プロダクト組織に対して SRE が機能する状態を作る ◼ どんなプロダクト組織であっても適切に SRE 活動ができる状態になること ◼ これまでの SRE はプロダクト組織に対して価値提供できているか自信を持って言えなかった ◼ システムの状態がわからない、わかりづらい状態だと本当に価値が出せているかすら判断できない ◼ 共通のツールがあることでプロダクトの状況を素早く把握することができる

Slide 24

Slide 24 text

Slide 25

Slide 25 text

©KINTO Corporation. All rights reserved. 25 New Relic の強力な推進なぜ New Relic を推進したのか ◼ SRE は可視化をした先にどのように課題を発見しアクションできるかが重要 ◼ 全体を見える化してユーザー体験と課題発見の効率を改善するためのセットが揃っている ◼ これまで KTC では標準の監視プラットフォームとして OpenSearch + Grafana を活用はしていたが。。。 ◼ 可視化をすることを目的にしない、その先にあるものを見る ◼ 素早いオンボーディングの実現 ◼ この業界では New Relic か Datadog を使っている企業が多い ◼ 新しく来た方が New Relic を使った経験があればその経験はそのまま活きる

Slide 26

Slide 26 text

©KINTO Corporation. All rights reserved. 26 プロダクト組織への New Relic 導入サポートペアプロ〜 Daily MTG での状況確認が定着するまで ◼ 導入して終わりではなく日々の運用に取り入れられることで価値になる ◼ オブザーバビリティツールは使われてこそ意味がある ◼ 運用に定着すれば、異常の予兆に気づけるようになる ◼ 感度が上がることで重大トラブルを未然に防ぐ力がチームに根付く SRE はプロダクト組織に対してこの価値を届けることで信頼関係を築く

Slide 27

Slide 27 text

©KINTO Corporation. All rights reserved. 27 プロダクト組織への New Relic 導入サポート SRE の支援的アプローチと価値 ◼ SRE が伴走して「見る文化」をプロダクト組織とともに作る ◼ ペアプロを含めさまざまな形でダッシュボード・アラート設計を支援 ◼ Daily MTG で状況確認の習慣をプロダクト組織に定着 ◼ ツールを自分たちの武器として使いこなせる状態へ ◼ 使われるオブザーバビリティツールにすることで ◼ アラートへの即応力が高まる ◼ 変化に敏感なチーム文化が生まれる ◼ プロダクトの安定運用と品質向上に寄与

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

©KINTO Corporation. All rights reserved. 31 SRE が SRE として活動するための種まきはできつつあるもっと直接的に SRE が価値を提供できるようにするためにはどうしたらいいか ◼ 今はまだ、複数のプロダクト組織に対して展開しているフェーズ ◼ SRE が価値を届けるための前提条件を築いている段階 ◼ SRE が最大限に価値を発揮するのはプロダクト組織の中に根差した時 ◼ なぜならプロダクト毎に状況も SLI も異なる ◼ 標準的に整備する “だけ” では Platform Engineering の領域と変わらない

Slide 32

Slide 32 text

©KINTO Corporation. All rights reserved. 32 僕が考える KTC における本質的な SRE の役割とは伴走して個別最適を体現すること ◼ SRE はプロダクト毎の文脈・特性に深く入り込むことが重要 ◼ テンプレートではなく、それぞれのプロダクトに最適な形を考え抜く ◼ つまり SRE は個別最適化を推進する存在としての進化が必要なのではないか？ ◼ 現状の SRE はまだ横断組織としての動きにとどまっている ◼ 将来的には各プロダクト組織に SRE チームが組成され、今の SRE がその立ち上げ、リードを担っていくフェーズに進んでいってほしい ◼ それが成功すれば自然とプロダクト内で SRE の採用が始まり、SRE が文化として定着する

Slide 33

Slide 33 text

Slide 34

Slide 34 text

©KINTO Corporation. All rights reserved. 34 KTC SRE は進化し続ける ◼ SRE の現状 ◼ SRE はオブザーバビリティツールの導入をプロダクト横断で整備中 ◼ これは SRE が SRE として機能するための地盤作りのフェーズ ◼ 見えてきた課題 ◼ オブザーバビリティツールの導入だけでは個別課題に踏み込めない ◼ プロダクト毎に最適な信頼性の形が必要 ◼ これからの戦略 ◼ SRE は横断から個別へのシフトチェンジが必要 ◼ プロダクト毎に SRE チームの立ち上げを視野に現 SRE メンバーがその起点・リーダーになる信頼性をリードする存在になるとともに SRE 活動が組織に根付き KTC の自然な文化となる

Slide 35

Slide 35 text

Road to SRE Next ! ということでこの後 CfP 出す予定です、ぜひ応援してください！！

Slide 36

Slide 36 text

Thank you！