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
⛵️ 長谷川 広樹 🐬
May 07, 2021
Programming
1
850
♾️ SREに入門しよう
社内LTにて、SRE用語を布教しようと試みましたʕ◔ϖ◔ʔ
⛵️ 長谷川 広樹 🐬
May 07, 2021
Tweet
Share
More Decks by ⛵️ 長谷川 広樹 🐬
See All by ⛵️ 長谷川 広樹 🐬
♾️ マルチプロダクトの巨大組織でマイクロサービス開発を支えるCICDプラットフォーム設計
hiroki_hasegawa
5
3.9k
🐙 KubernetesのマルチテナントパターンとArgoCDの実践テナント設計
hiroki_hasegawa
4
3.3k
🧑🚀 tfstate の分割パターンとディレクトリ構成への適用
hiroki_hasegawa
8
7.7k
⛵️ Istioのサービス間通信を実現するサービスディスカバリーの仕組み
hiroki_hasegawa
3
7.2k
🔍 可観測性に入門しよう
hiroki_hasegawa
1
1.1k
🏗️ ドメイン駆動設計と依存性逆転の原則
hiroki_hasegawa
14
10k
🤝🏻 依存関係と依存オブジェクト注入
hiroki_hasegawa
2
1.3k
🐭 Goに入門しよう
hiroki_hasegawa
0
730
🐭 Lambda関数をGoで実装してみた話
hiroki_hasegawa
0
910
Other Decks in Programming
See All in Programming
複数チーム並行開発下でのコード移行アプローチ ~手動 Codemod から「生成AI 活用」への進化
andpad
0
100
CloudflareのSandbox SDKを試してみた
syumai
0
120
Health Kit × Foundation Models でAIコーチを作ってみた
ryunakayama
0
100
Making Angular Apps Smarter with Generative AI: Local and Offline-capable
christianliebel
PRO
0
110
AIの弱点、やっぱりプログラミングは人間が(も)勉強しよう / YAPC AI and Programming
kishida
5
2.1k
なぜ強調表示できず ** が表示されるのか — Perlで始まったMarkdownの歴史と日本語文書における課題
kwahiro
5
2.1k
Register is more than clipboard
satorunooshie
1
450
Dive into Triton Internals
appleparan
0
480
SODA - FACT BOOK(JP)
sodainc
1
9.4k
Vueのバリデーション、結局どれを選べばいい? ― 自作バリデーションの限界と、脱却までの道のり ― / Which Vue Validation Library Should We Really Use? The Limits of Self-Made Validation and How I Finally Moved On
neginasu
3
1.8k
pnpm に provenance のダウングレード を検出する PR を出してみた
ryo_manba
1
220
AI駆動開発カンファレンスAutumn2025 _AI駆動開発にはAI駆動品質保証
autifyhq
0
140
Featured
See All Featured
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Automating Front-end Workflow
addyosmani
1371
200k
A better future with KSS
kneath
239
18k
Typedesign – Prime Four
hannesfritz
42
2.9k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
660
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.3k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
54k
Rebuilding a faster, lazier Slack
samanthasiow
84
9.3k
Facilitating Awesome Meetings
lara
57
6.6k
The Invisible Side of Design
smashingmag
302
51k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
10
660
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
231
22k
Transcript
SREに入門しよう 株式会社ユニクエスト 長谷川広樹 github.com/hiroki-it @Hiroki__IT
自己紹介 ▼ お仕事 最近:クラウドインフラ、IaC、CICD、... 以前:DDD ▼ 関心のある技術領域 ・クラウドインフラ ・IaC ・DDD
github.com/hiroki-it @Hiroki__IT 長谷川 広樹 (はせがわ ひろき) 株式会社ユニクエスト
目次 ▪ SREとは ▪ (僕が思う)SREに必要な思想と技術 ▪ Goによる厳格なルールに基づいた基盤実装 ▪ モニタリング ▪
オンコールとインシデント対応 ▪ SLI/SLO ▪ エラーバジェット ▪ ポストモーテム ▪ まとめ ▪ カンファレンス
SREとは SRE:Site Reliability Engineering(サイト信頼性エンジニアリング) Googleによって提唱されたシステム運用や自動化に関連する開発 Site Reliability Engineering by Betsy
Beyer, Chris Jones, Niall Richard Murphy, Jennifer Petoff
SREとは SREは何をすればよいのか...?
(僕が思う)SREに必要な思想と技術 ▪ 稼働し続けられるシステム作り ・Goによる厳格なルールに基づいた基盤実装 ・モニタリング ・オンコールとインシデント対応 ・SLI/SLO ・エラーバジェット ・ポストモーテム ・クラウドインフラによるマネージドなインフラ(今回は割愛)
・セキュリティ(今回は割愛) ・Production Readiness Review(※マイクロサービスで使用されるルールのため割愛),など... ▪ スケーラブルなアプリケーション開発を生み出す環境作り ・マイクロサービス,Kubernetes,CI/CD,IaC,トイル撲滅,など...(※今回は割愛)
Goによる厳格なルールに基づいた基盤実装(1) ▪ Goのメリット ・データ型の扱いに非常に厳しく,開発時にバグを検出可能. ・ブラックボックスになりにくく,可読性が高い. ・処理速度が速い. ・同期処理と並列処理を簡単に書き分けられる(※非同期処理との違いに注意). ・他の静的型付け言語(Java,C)よりも学習コストが低い. など... 堅牢なバックエンドを実装できる(例:決済系など)
Goによる厳格なルールに基づいた基盤実装(2) Goの導入を実現させる! 一緒にGoに挑戦していきましょう! 僕一人だと力に限界があります(切実)! 知見を共有し合って,お互い爆速成長したい! 僕も勉強中なので,知見共有させていただきます! 僕のリポジトリ:https://github.com/hiroki-it/notify-slack-of-amplify-events
モニタリング ▪ モニタリングすべき4大シグナル ・レイテンシー(リクエスト到達まで+処理終了からレスポンス到達まで) ・トラフィック(とあるネットワーク地点でのスループット) ・明示的エラーと暗黙的エラー (400/500系異常レス + 後述するSLO未達やAPI仕様不一致の正常レス) ・サチュレーション(システムの利用率の飽和度.「サチる」はよく使う)
4大シグナルは注視しよう!(自戒)
オンコールとインシデント対応 ▪ オンコールとインシデント対応とは 何らかのインシデントをチャンネルに通知するようにし,通知を受けて対応すること. 当番制にしている会社もある. ▪ インシデントとは エラーを含むシステム的に良くない事象のこと. 参考:https://backlog.com/ja/blog/on-call-system-for-backlog-developers/ 明示的エラーと暗黙的エラーのオンコールは必須!
SLI/SLO(1) ▪ SLIとは:Service Level Indicator サービスレベルの指標とするメトリクスのこと. ・サーバ稼働率 ・データベース稼働率 ・レイテンシー ・レスポンスタイム
・レスポンスのステータスコード率
SLI/SLO(2) ▪ SLOとは:Service Level Objective SLIとして採用した指標の目標値のこと. ・サーバ稼働率(日当たり0.1%のダウンタイム発生) ・データベース稼働率(日当たり0.1%のダウンタイム発生) ・レイテンシー(日当たり0.1%までのレイテンシー増加) ・レスポンスタイム(日当たり0.1%までのレスポンスタイム増加)
・レスポンスのステータスコード率(日当たり99.9%の200レス)
エラーバジェット ▪ エラーバジェットとは ・前述したSLI/SLOを決めたうえで設定. ・年間や月間のエラーやダウンタイムがSLOに達するまでは, これらが起こることを許容できる. 参考:https://www.redhat.com/ja/topics/devops/what-is-sre ダウンタイムをどの程度発生させてよいかの目安になる. ビジネスより技術を優先するときの意思決定が早くなる.
ポストモーテム ▪ ポストモーテムとは 障害報告書とは異なり,原因特定とシステム改善に重きを置いた報告書のこと. (タイトル・日付・担当・原因と対応・システム的/収益的な影響・幸運だったこと・仕組みの改善策・タイムライン) ▪ 留意すること ・作成に当たり,担当者を絶対に責めない.障害は誰のせいでもない. (★最重要であり,必ず守ること) ・対策は「以後は注意する」ではなく,再発しない仕組み作りになるように.
・多くの人に情報を共有すること. 参考:https://qiita.com/an_sony/items/0565ad980f9097c76d11 エンジニアリングの心理的安全性を高めて挑戦しよう!
まとめ 今すぐ使えそうなSRE用語は どんどん使って SREチームさらにはシステム課全体の 共通言語にしていきましょう! (「サチる」はすぐに使えます)
カンファレンス ▪ SRE Lounge:https://sre-lounge.connpass.com/ ▪ SRE NEXT:https://sre-next.dev/
最後に 改めてGopherくん 超かわいい!!! by Takuya Ueda (https://twitter.com/tenntenn) The Gopher character
is based on the Go mascot designed by Renée French.