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
180
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
120
上から見るか下から見るか.pdf
hayabusa333
0
940
Elixirでやってきたこと
hayabusa333
0
1.4k
APIサーバとしてのCowboy
hayabusa333
1
1.2k
CowboyとPhoenixの速度比較
hayabusa333
1
1.6k
E言語スタック
hayabusa333
0
490
Other Decks in Technology
See All in Technology
バッチ処理のSLOをどう設計するか
rynsuke
7
540
AMLD 2024 - Build Your Own GPT
donlelef
1
260
「XX試験の環境作ってよ」と言われた時によく使うAWSのソリューションについて
bun913
0
120
私のRSpecの書き方 / How I write RSpec
tmtms
4
820
Cloud Deploy と仲良くなりたい
phaya72
1
100
BDD(Cucumber)コミュニティが無料提供しているコンテンツの紹介と現在起きている危機
nihonbuson
4
730
『QAという人』が必要ではなく、『QAという技術』が必要
sadonosake
2
460
Cloud Friendly(?) Jenkins. How we failed to make Jenkins cloud native and what we learned?
onenashev
PRO
0
110
現実世界の事象から学ぶSOLID原則
h0r15h0
24
9.4k
Tohoku.Tech #1 「Cursorを使ったRaspberry Piの開発」by ねこまた
jun2882
0
250
KubeCon EU 2024 : Knative Maintainers Session
salaboy
0
360
Autopsy of a Cascading Outage from a MySQL Crashing Bug
jfg956
0
200
Featured
See All Featured
JazzCon 2018 Closing Keynote - Leadership for the Reluctant Leader
reverentgeek
178
11k
For a Future-Friendly Web
brad_frost
170
8.9k
How STYLIGHT went responsive
nonsquared
92
4.7k
Design by the Numbers
sachag
274
18k
Designing the Hi-DPI Web
ddemaree
275
33k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
113
18k
Fontdeck: Realign not Redesign
paulrobertlloyd
75
4.8k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
355
22k
Designing for humans not robots
tammielis
247
25k
The Brand Is Dead. Long Live the Brand.
mthomps
48
21k
Thoughts on Productivity
jonyablonski
57
3.8k
Designing with Data
zakiwarfel
94
4.8k
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/