Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
SREってなんだろう
Search
Junnichi Kitta
March 13, 2022
Technology
0
220
SREってなんだろう
Drecom SRE Sunday Vol.2 で話した内容です
Junnichi Kitta
March 13, 2022
Tweet
Share
More Decks by Junnichi Kitta
See All by Junnichi Kitta
ポストモーテムから振り返る
hayabusa333
0
170
上から見るか下から見るか.pdf
hayabusa333
0
1.1k
Elixirでやってきたこと
hayabusa333
0
1.6k
APIサーバとしてのCowboy
hayabusa333
1
1.3k
CowboyとPhoenixの速度比較
hayabusa333
1
1.8k
E言語スタック
hayabusa333
0
550
Other Decks in Technology
See All in Technology
データグループにおけるフロントエンド開発
lycorptech_jp
PRO
1
110
20250705 Headlamp: 專注可擴展性的 Kubernetes 用戶界面
pichuang
0
270
OPENLOGI Company Profile
hr01
0
67k
ビズリーチにおけるリアーキテクティング実践事例 / JJUG CCC 2025 Spring
visional_engineering_and_design
1
130
LangChain Interrupt & LangChain Ambassadors meetingレポート
os1ma
2
320
OPENLOGI Company Profile for engineer
hr01
1
34k
KubeCon + CloudNativeCon Japan 2025 Recap Opening & Choose Your Own Adventureシリーズまとめ
mmmatsuda
0
280
MobileActOsaka_250704.pdf
akaitadaaki
0
130
AWS認定を取る中で感じたこと
siromi
1
190
CDKTFについてざっくり理解する!!~CloudFormationからCDKTFへ変換するツールも作ってみた~
masakiokuda
1
150
生成AI活用の組織格差を解消する 〜ビジネス職のCursor導入が開発効率に与えた好循環〜 / Closing the Organizational Gap in AI Adoption
upamune
7
5.3k
品質と速度の両立:生成AI時代の品質保証アプローチ
odasho
1
360
Featured
See All Featured
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
We Have a Design System, Now What?
morganepeng
53
7.7k
Into the Great Unknown - MozCon
thekraken
40
1.9k
The Pragmatic Product Professional
lauravandoore
35
6.7k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
A designer walks into a library…
pauljervisheath
207
24k
Writing Fast Ruby
sferik
628
62k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Become a Pro
speakerdeck
PRO
29
5.4k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.6k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
Transcript
SREってなんだろう
About Me • 橘田隼一 / Twitter: @hayabusa333 / Github: hayabusa333
• 株式会社ドリコム ◦ Work ▪ エンジニアリーダー • 技術スタックを考えたり、更新計画を立てたり • golang で開発したり ▪ サーバー/インフラエンジニア • SREチームとして色々とやったり • Community ◦ tokyo.ex • Hobby ◦ お酒 ◦ TRPG
ゴール • ターゲット ◦ SREについて知らない方々 • ゴール ◦ SREが、どのようなものかわかる ◦
SREになりたいと思ってもらう
SREとは • Site Relaiability Engineer ◦ Google 来るべきシステム管理の姿として考えられたもの ◦ デプロイ、運用、改善、平穏なる撤去をエンジニアリングで解決
▪ SREはエンジニアである
SREとDevOpsの違いは? • SREとDevOps は混じり合う箇所があるという人もいる • DevOpsは開発からデプロイまでの箇所を見て、SREはその拡張であるという人も いる • SREはDevOpsチームを支えて、高い信頼性でリリースするために集中するっとい う人もいる
• DevOpsは思想で、それを実践するのがSREという人もいる • SREは従来の運用の進化系、DevOpsは最新情報を把握してチームを横断してビ ジネスを強化するっという人もいる SREとDevOpsは共存できるししていくべきではあるが、定義は人によってまちまちであ る
SREの用語 • SLI ◦ サービスレベル指標 ▪ サービスの挙動に関する単一の計測可能なメトリクス ▪ 何を測定して、何を使用するかが重要 •
可用性 • レスポンスタイム • SLA ◦ ユーザーがサービスに期待する挙動の全体を定義 ▪ SLIを組み合わせたもの ▪ 何を適切として、何を不適切とするかを考えるのが重要
SREの用語 • SLO ◦ サービスレベル目標 ◦ SLAと同じものであり、SLAのレベルを引き上げるのが一般的 ◦ SLAとSLOの違いは制約の強さ
SREの用語 • トイル ◦ プロダクションサービスを動作させるために必要な手作業 ◦ 自動化することが可能なもの ◦ 割り込みで発生し長期的な価値を持たないもの ◦
作業量がサービスの成長に比例する • トイルの作業はできるだけ少なくする必要がある ◦ トイルがあると仕事をしている感が出るが何も生み出していない ◦ サービスに機能を追加するエンジニアリングプロジェクトにこそ時間を費やす べきである
SREってどこから入っていくの? • 正直わからん • いろいろな会社で違うので一概にはどこからっと言えないと考える ◦ SREはインフラストラクチャを管理しないという人もいる ◦ インフラストラクチャの管理と開発がSREという会社もある ◦
信頼性の高いシステムとアプリケーションの構築と管理するというところもある ◦ 開発に強いバックグラウンドがある運用者というところもある ◦ ステージング環境、CI/CDパイプライン、自動テストの用意とかを行うというとこ ろもある
ドリコムのSRE • インフラチーム ◦ 開発環境、本番環境の用意、デプロイパイプラインの用意 • アプリケーションチーム ◦ 性能試験、負荷試験の対応 •
クライアントチーム ◦ ライブラリの用意、更新
SREのスキルセット • オペレーティングシステムの内部 • ネットワーキング • モニタリングとアラート • トラブルシューティング •
デバッグ • インシデント管理 • ソフトウェアエンジニアリング • ソフトウェアのパフォーマンス • ハードウェア • 分散システム • キャパシティプランニング • セキュリティ
SREチームの学び • ポストモーテム ◦ 発生した障害と影響度、障害の緩和や解消のために行われた対応、根本原 因、再発防止のためのアクションを記録する • プロダクションミーティング ◦ 開発者とSREが集まってサービスの状態を議論する週次のプロダクトミーティ
ング ◦ チーム全体としてサービスのパフォーマンスや発生している問題について情報 を得ることができる ◦ 新しく入ったエンジニアはミーティングで理解できなかったことを書き留めてリ ストにする ◦ リストの内容をメンターは教えることによって、ドキュメントや知識の更新を行う ことができる
ポストモーテム • ドリコムのポストモーテムに関しては以前話させていただきました ◦ https://speakerdeck.com/hayabusa333/posutomotemukarazhen-rifan-ru ◦ https://www.youtube.com/watch?v=wua__TdBOtk
SREチームの学び • Wheel of Misfortune:不運の輪 ◦ ロールプレイングゲーム ◦ ゲームマスター1名とチームメンバー 1名で行う
◦ 何らかのイベントが発生していることをチームメンバーに伝える ◦ チームメンバーは問題の権限、根本原因分析、解決を行う ◦ ゲームマスターはチームメンバーが行った内容に対して何が起こったかをシ ミュレートする ◦ ゲームの内容は過去起こったインシデントで行う
なぜSREチームは学ぶのか • SREチームが学ばないとサービスの障害の原因を作ってしまう • SREチームが学ばないと障害の発生時間が延びてしまう • セキュリティ問題で会社の信頼問題になる ◦ 上記は何度も発生させて良い問題ではない ◦
そのためSREチームとして教訓から学ぶ方法が用意されている
SREの作業 • ソフトウェアエンジニアリング ◦ コードの作成や修正、設計やドキュメンテーションの作成 ▪ 自動化スクリプトの作成 ▪ ツール・フレームワークの作成 ▪
サービスへのスケーラビリティや信頼性のための機能の追加 ▪ インフラストラクチャのコード修正 • システムエンジニアリング ◦ プロダクションシステムの設定 ◦ システムに関するドキュメントの作成 ▪ モニタリングのセットアップ・更新 ▪ サーバーの設定 ▪ パラメータのチューニング
SREの作業 • トイル ◦ サービスを稼働させることに直結する作業 • オーバーヘッド ◦ サービスを稼働させることに直結していない管理的な作業 ▪
採用 ▪ 人事の事務作業 ▪ ミーティング
まとめ • SRE自体は新しい考えではない ◦ 運用を良い形でやるためにはどうすれば良いかという流れ ◦ DevOpsと混じり合ったり喧嘩したり • SREはエキスパートとゼネラリストを兼ねている ◦
全てに対してエキスパートである必要はない ◦ 自分自身の強みはどこにするのか ◦ 幅広い知識は必要になってくる • SREを始めるに対しても、どこから始めていくかは自由だと思う
参考資料 • SRE サイトリアイアビリティエンジニアリング ◦ https://www.oreilly.co.jp/books/9784873117911/ • サイトリアイアビリティワークブック ◦ https://www.oreilly.co.jp/books/9784873119137/
• SREの探究 ◦ https://www.oreilly.co.jp/books/9784873119618/