SRE 1st steps

1. SRE:Site Reliability Engineering
はじめの一歩！
~SRE 1st Steps~
TDCソフト株式会社 島田雄太
©︎ 2021, TDC SOFT,Inc. All right reserved. 1

2. 本セッションについて
DevOpsやアジャイルというキーワードが、ユーザ企業など
でも語られるようになってきています。DevOpsやアジャイ
ルを推進する上で重要となるSRE(Site Reliability Engineering)
サイト信頼性エンジニアリングという役割をご存知でしょ
うか。
本発表ではSREとは何か？というテーマで、SREの役割や文
化、実践を通じて得たノウハウ・求められる人物像につい
て説明します。
2
©︎ 2021, TDC SOFT,Inc. All right reserved.

3. 自己紹介
3
名前： 島田 雄太
主な経歴：ASPサービスのインフラ設計・構築・運用
ハウジング・ホスティングサービスの提案・設計・構築・運用
顧客先常駐/インフラ設計構築支援（オンプレ・仮想化）
インフラ設計構築案件PM
顧客先常駐/インフラ設計構築支援（パブリッククラウド）
最近の業務経歴：AWS構築支援(SRE)
顧客業務システムのCI/CD環境構築・運用
顧客SoE基盤における業務支援(SRE)
最近の楽しみ：子供と過ごす時間
©︎ 2021, TDC SOFT,Inc. All right reserved.

4. アジェンダ
- 自己紹介
- SREの全体像
- SREとは？
- 自動化・効率化の背景
- CICDの自動化
- コンテナの可搬性
- パブリッククラウドの普及
- SREで知っておくべき文化
- トイルの削減
- SLI/SLOの設定
- エラーバジェットの適切な設定
- ポストモーテムについて
- SREとして取り組むために求められる人物像
- SREとしてのマインド
- SREの技術領域
- SREやっていて面白いこと
- SREやっていて苦労していること
- 最後に
4
©︎ 2021, TDC SOFT,Inc. All right reserved.

5. SREの全体像
5
©︎ 2021, TDC SOFT,Inc. All right reserved.

6. SREとは？
6
SREとはGoogleが提唱する
「システム運用管理の方法論及びエンジニアの役割」を指す。
具体的には、リライアビリティという単語の通り、ウェブサイ
トやサービスの信頼性向上に重点を置いた内容となっており、
システム運用に伴う手動の作業をエンジニアリングによって自
動化・効率化を行う取り組みが一般的。
©︎ 2021, TDC SOFT,Inc. All right reserved.

7. 自動化・効率化の背景
2. Infrastructure as a Codeによる
自動化
7
1.アジャイル開発の導入
©︎ 2021, TDC SOFT,Inc. All right reserved.

8. 自動化・効率化の背景
DevOpsという考え方が普及し、より短期間での開発サイ
クルが求められる
8
1.アジャイル開発の導入
©︎ 2021, TDC SOFT,Inc. All right reserved.

9. 自動化・効率化の背景
9
- CICDの自動化
- コンテナによる可搬性の向上
- パブリッククラウドサービスの普及
©︎ 2021, TDC SOFT,Inc. All right reserved.
2. Infrastructure as a codeによる自動化

10. CICDの自動化
◆CICDとは？
- 継続的インテグレーション(Continuous Integration)：
開発コードの解析・ビルド・テストの自動化
- 継続的デリバリ(Continuos Delivery)：
テストが通ったコードを自動的にデリバリ、デプロイ
10
©︎ 2021, TDC SOFT,Inc. All right reserved.

11. CICDの自動化
GCPにおけるCICD導入イメージ
11
©︎ 2021, TDC SOFT,Inc. All right reserved.

12. コンテナの可搬性
ビルドしたアプリケーションはコンテナ化することで、
開発環境、STG環境、本番環境と同じものを利用するこ
とが可能。（環境差異をなくすことができる）
12
©︎ 2021, TDC SOFT,Inc. All right reserved.

13. パブリッククラウドの普及
AWS、GCP、Azure等のパブリッククラウドを利用することで、
自動化についてもメリットが得られる
- インフラ構築をコードで管理することができるサービスを活用
できる（Terraform / CloudFormation 等）
- リソースの増減を容易に変更することができる
- 増減されたリソース分のみコストとして発生する（余計な固定
費用は発生しない）
13
©︎ 2021, TDC SOFT,Inc. All right reserved.

14. ここまで読むと、SREは単に自動化・効率化
する人と思われがち。
しかし、これから説明する文化がSREについ
てとても重要であると伝えたい。
14
©︎ 2021, TDC SOFT,Inc. All right reserved.

15. SREで知っておくべき文化
15
©︎ 2021, TDC SOFT,Inc. All right reserved.

16. トイルの削減
16
◆トイルとは？
手作業や繰り返される、自動化が可能、戦術的、長期的な価値
がない、サービスの成長に比例して増加する作業を指す。
トイルを削減が、業務の効率化や作業ミスの低減に繋がる。
Google の SRE は、いわゆる「トイル」に費やされる時間を勤務
時間の 50% 未満にすることを目指している。
©︎ 2021, TDC SOFT,Inc. All right reserved.

17. トイルの削減
17
©︎ 2021, TDC SOFT,Inc. All right reserved.
◆トイル削減のノウハウ
- 繰り返し行う作業や実際に手で行っている作業について洗い出
す（例：リリースにおけるリリース手順書の作成、デプロイ作
業など）
- 共通化できる作業内容と都度変える必要のあるパラメタを明確
にする（例：アプリケーション名やバージョンなど）
- 共通化できる作業内容は、ツールとして利用出来ないかを検討
し、作ってみる（例：シェルの作成やツール、クラウドネイテ
ィブなサービスの活用など）
●Point：繰り返し実行を可能とするため常に冪等性を意識する
- シェルは繰り返し実施しても同じ処理が実行できるように、
必要に応じて事前にクリーンナップ処理を加える
- 作業単位: 切り戻しを意識した上で洗い出す

18. SLI/SLOの設定
◆SLI/SLOとは？
- SLI(service level indicators)…サービスレベル指標
サービスのレベルの性質に関して慎重に定義された計測量
例）
リクエストのレイテンシ：リクエストに対するレスポンス
を返すまでにかかった時間
可用性：サービスが利用できる時間の比率（処理に成功した
正常なリクエストの数の比較で計測されることが多い）
- SLO(service level objective)...サービスレベル目標
SLIで計測されるサービスレベルのターゲット値、あるいは
ターゲットの範囲
18
©︎ 2021, TDC SOFT,Inc. All right reserved.

19. SLI/SLOの設定
◆SLI/SLO設定のノウハウ
- システムの境界を意識する
- 顧客に公開している機能を特定する（例：ログインなど）
- 特定した機能について1つ以上のSLIを定義する（例：リクエス
トのレイテンシ、レスポンスコードの割合）
- 試験を通じて、ベースとなるSLOを洗い出す
- パブリッククラウドサービスで提供されているSLAと顧客から
求めらるSLOで乖離している箇所がないから洗い出す
19
©︎ 2021, TDC SOFT,Inc. All right reserved.
●Point：SLI/SLOはスクラムチームやビジネスによって異なる
ステークホルダとの密なコミュニケーションが重要。
試験実施→フィードバックを繰り返し実施する

20. エラーバジェットの
適切な設定
◆エラーバジェットとは？
エラーバジェット（Error Budgets）はエラーに対する予算であ
り、SLOに基づき算出される損失可能な信頼性である。 サービ
スの計測された稼働時間がSLOを超えている、換言すればエラ
ーバジェットがまだ残っている状態であれば、チームは新しい
リリースをプッシュ（デプロイ）できる
20
©︎ 2021, TDC SOFT,Inc. All right reserved.
●Point : 動いて100％の辛い時代から脱却
→より良い効率化とスキル向上による継続的改善につなげる

21. ポストモーテムについて
21
想定読者 目的
ポストモーテム 身内のエンジニア 障害からの学び・サービス
改善
障害報告書 上司・ユーザー 障害の報告・情報共有
◆ポストモーテムとは？
ポストモーテムは、インシデントとそのインパクト、その緩和や解
消のために行われたアクション、根本原因（群）、インシデントの
再発を避けるためのフォローアップのアクションを記録するために
書かれるドキュメント。言い換えると、失敗（障害）から学び、再
発防止策を決める活動
©︎ 2021, TDC SOFT,Inc. All right reserved.

22. ポストモーテムについて
22
● Point： ポストモーテムで重要なこと
- 批判を行わない
- 障害について根本原因を十分に分析し、理解する
- 人でなく仕組みで対応する
- 多くの人に知識を共有する
©︎ 2021, TDC SOFT,Inc. All right reserved.

23. SREとして取り組むために
求められる人物像
23
©︎ 2021, TDC SOFT,Inc. All right reserved.

24. SREとしてのマインド
以下の動き方や意識を持てる方はWelcome！
- 自動化に興味を持つ
- 周囲に対して興味を持つ
（今までのインフラ、アプリの壁を取り払う）
- アプリ/インフラの間に落ちそうなボールを拾う
24
©︎ 2021, TDC SOFT,Inc. All right reserved.

25. SREの技術領域
代表的な技術領域は以下の通り
（詳細について今回は割愛します）
- コンテナの知識(Docker)
- 自動化に関する知識(Python,CI)
- オーケストレーションの知識(Kubernetes)
- パブリッククラウドの知識(AWS,GCP,Azure)
25
©︎ 2021, TDC SOFT,Inc. All right reserved.

26. SREやっていて面白いこと
私が考えるSREの面白さ
- IaC(Infrastructure as a Code)により、アプリ同様、
インフラでも事前にDev/STG環境で検証したコードを
利用することができる
（手順書作成して取り組む場合は、コマンドの入力ミ
スに寄る環境破壊なども考えられる）
- ポストモーテムによる前向きな振り返り・情報共有
- 新たな技術に触れることができる
26
©︎ 2021, TDC SOFT,Inc. All right reserved.

27. SREやっていて
苦労していること
SRE経験して感じたこととその対策
- 習得するべき技術領域が多岐にわたるため、キャッチアップ
の量が多い
→チームで対応することでそれぞれの得意不得意領域を
カバーし合う
- 各技術領域においても情報のアップデートが早いため、新し
い技術の情報収集と案件への適用が必要
→システムの規模や要件に応じて必要なSLI/SLOを設定して無
理のない運用にする
27
©︎ 2021, TDC SOFT,Inc. All right reserved.

28. 最後に
- インフラ技術だけでなく新しい技術分野へシフトし
ていくSREというロールは今後注目されていく
- ぜひSREを楽しみながら挑戦していきましょう！
28
©︎ 2021, TDC SOFT,Inc. All right reserved.

29. ご静聴ありがとうございました！
29
©︎ 2021, TDC SOFT,Inc. All right reserved.