S R E Tec hnology Map 2 023

[1]「Site Reliability Engineering（SRE）とは、Google社が提唱、実践しているシステム管理とサービス運用の方法論」 です。

サイバーエージェントの事業成長とともに、SRE領域へも注力してきました。

SRE Technology Mapは、当社のSREチームの取り組みを知ってもらうための冊子です。

[1]「サイトリライアビリティエンジニアリング」『ウィキペディア (Wikipedia): フリー百科事典』

サイバーエージェントが提供する幅広い事業サービスの信頼性向上に、私達SREsは日々取り組んでいます。事業領域や事業フェーズ、組織規模が異なれば、SREsのアプローチも違ってきます。

それぞれのSRE組織が、様々な課題解決に取り組んだことによって得られた知見や考え方などを多くの人に知ってもらいたいと考え、「SRE Technology Map」を作成しました。

「SRE Technology Map」を通して、少しでもサイバーエージェントに興味を持っていただけ
れば幸いです。また、私達と同様にSRE推進に取り組んでいる人々の助けや学びになることを願っております。

メディア統括本部

サービスリライアビリティグループ

マネージャー 兼Developer Expert of SRE柘植 翔太

Shota Tsuge

2023年3月で当社は25周年を迎えました。  
専務執行役員

技術担当

長瀬 慶重

Norishige Nagase

創業来、インターネット産業の拡大とともに事業成長を続けてきたサイバーエージェントでは、
2015年頃からお客さまに安心・安全なサービスを提供するためにシステムの維持・向上に向けて、SREに取り組みはじめました。  
当初、メディア事業から始まったSREですが、今ではゲーム事業、インターネット広告事業、
AI・DX領域でもSREの専門チームが発足するなど、その活動の幅は年々広がっています。  
この「SRE Technology Map」では、サイバーエージェントのSREチームが日々向き合っている課題や取り組みについてご紹介しています。  
本冊子を通して当グループの知見を展開できることを願っています。

Index01. Introduction

02

05. 事業部毎のSRE組織情報29

7 コラ ム0 .

7 .1. 新卒 1 年目 のSRE が考え るSREの 魅力 と は

5.1. メディア事業

02. サイバーエージェントグループのSRE組織と実装パターン

06

SRG、ABEMA、IU（CAM、タップル）、CyberZ

7 .2. SRE に求められ るエンジ ニ アと して の 素養

5.2. ゲーム事業

CA GameFi、アプリボット、サムザップ

2.1. SRE組織パターン

8 編集

0 .

5.3. AI・DX事業

2.2. SRE実装パターン

アドテクディビジョン

03.データで見るSRE

113.1. キャリアと組織の傾向

06. SREsの取り組み48

a a g Incident Ma n ag e m ent 使って A m e baのイン シ デント 管理体制整備した話

6.1. D t do

3.2. 採用技術の傾向

04. SREs紹介

65

26

6.2.

Cyb er Z でのトイル 可視化 の取り組 み

mb edded SRE と して サー ビスに S LO を導入

して み る6.3. E

6.4. SRE
6.5.

成熟度評価についてG r afa n a O n Call の 活 用

72サイバーエージェントグループのSRE組織と実装パターン

07

01
02

メディア事業、インターネット広告事業、ゲーム事業を中心に事業を展開。

各事業に、SRE組織も立て付けられており、SRE推進に取り組んでいます。

03
04
05
06
07
08

メディア事業● 「ABEMA」● 「Ameba」● 「タップル」 等

インターネット

広告事業● AI 事業● DX 事業● AI 技術の研究・開発 等

ゲーム事業● 「グランブルーファンタジー」● 「ウマ娘 プリティーダービー」● 「戦国炎舞 -KIZNA-」 等

08

01
02

サイバーエージェントグループのSRE組織パターン

03
04
05

①単一プロダクト専任SREs②子会社専任SREs③事業部横断SREs

プロダクト

子会社

事業部

SREs

SREs

SREs

06
07
08

プロダクト

プロダクト

AA

SRE組織とプロダクトは、１対１の関係

プロダクト

A

プロダクト

B

プロダクト

C

…

SRE組織とプロダクトは、１対Nの関係

子会社

A

子会社

B

プロダクト

A

プロダクト

B

SRE組織とプロダクトは１対Nの関係だが、複数の子会社を跨いでSRE推進を行う

…

09

01
02

サイバーエージェントグループのSRE実装パターン

03
04
05

Product SRE

各プロダクトの開発チームに所属し、信頼性向上へ取り組むSREs

Embedded SRE

Enablementフェーズ：SREを組織へ浸透し、自立支援に取り組むSREs

Evangelistフェーズ：SREの強化や改善を行うSREs

Platform SRE

共通基盤の信頼性や開発生産性向上へ取り組むSREs。

SRE Center ofPractice

横断的に展開できるSREプラクティス開発や導入へ取り組むSREs

MovableEmbedded SRE

緊急かつ高重要度の案件毎にチーム編成し、案件完遂に取り組むSREs

06
07
08

10

01
02

SRE組織俯瞰
A事業

03
04

A社
Service A

B社
Service B
開発チームD05
開発チームAエンジニア

開発チームF

開発チームB

06
07

Service C

Product

SRE

エンジニア

Embedded

SRE…

MovableEmbedded

SRE

エンジニア

エンジニア

08

共通基盤
開発チームC

エンジニア

C社

SREチーム開発チームE

SRE

Center ofPractice

Platform

SRE

共通基盤

エンジニア

Embedded

SRE

SREチーム開発チームG
エンジニア

Platform SRE

SRE Center of Practiceデータで見るSRE

キャリアと組織の傾向

12

01
02

有 期 雇 用A I ・ D X

13 %

13 %

03

中 途

04
05
06

入社形態

メ ディ ア

49 %

ゲ ー ム

27 %

新 卒

38 %

事業部管轄

07
08

1 年 目

%

8

新卒と中途の割合は、おおよそ半々

多くの新卒SREsが活躍している

現在は、メディアの割合が多いが、ゲームやAIでの需要も増えている

2 年 目

%

11

5 〜 9 年 目

38 %3 〜 4 年 目

%

16

入社年数

10年目以上27 %
入社5年以上が、6割を超えている

60 %

13

7 〜 9 年 目

01

25 %

02
03
04

1 〜 3 年 目

05

チーム

立ち上げ

年数

4 〜 6 年 目

50 %

25 %

06
07
08

立ち上げて4年以上のSRE組織が、7割を超えている

1 0 人 以 上

12 %
単 一 プ ロ ダ ク ト 専 任

子 会 社 専 任

24 %

38 %
組織パターン

1 〜 4 人5 〜 9 人

所属人数

38 %

事 業 部 横 断38 %8割のSRE組織が、複数プロダクトのSRE推進に取り組んでいる

5割のSRE組織が、4人以下

50 %

14

01

SRE実装パターン

02
03
04

66 %

66 %

05
06
07

44 %

08

Product SRE

Embedded SRE（Enabling SRE）

Platform SRE

44 %MovableEmbedded SRE

22 %

22 %

Embedded SRE（Evangelist SRE）

SRE Center ofPractice

Product SREとEnabling SREが多い傾向

全ての事業部横断SREsが、SRE Center of Practiceを実装している

15

01

その他

02

9%

03

データベースエンジニア

Webフロントエンジニア

営業

04

SREs

10 %

05
06
07

バックエンドエンジニア

08

ファーストキャリア

38 %ネットワーク・インフラエンジニア

19 %サービスインフラエンジニア

24 %ファーストキャリアの8割が、バックエンドやインフラエンジニア

新卒SREsの割合も増えてきている

採用技術の傾向

17

01

1.プラットフォーム

2.監視

02
03

100 %

75 %

75 %

88 %

04
05

75 %

06

75 %
63 %

75 %

63 %

07

38 %

08

25 %

25 %
12 %

AWS

Google Cloud Docker

Kubernetes OpenStack OpenShift

全SRE組織が、AWSを活用している

また、7割以上のSRE組織が、Kubernetes（k8s）を活用している

12 %

12 %

Microsoft

Azure

Datadog

GrafanaAmazon Prometheus
Cloud

CloudWatch
Monitoring

New RelicMackerel

Datadogは、SLO監視や可観測性ツールとしての活用も多い傾向がみられた

Victoria

Metrics

18

01
02

3.可観測性

4.SLO監視

75 %

75 %

03
04
05
06
07
08

38 %
25 %

Datadog

AWS X-RayOpen

Telemetry

7割以上のSRE組織が、Datadogを活用している監視と同じソリューションを活用する傾向がみえた

25 %New Relic

Datadog

12 %

12 %

12 %

12 %

New Relic

SLO監視を

していない

自前

実装基盤を

利用

Prometheus, Grafana

可観測性と同じソリューションを活用する傾向がみえた

19

01
02

5.On-Call

6.CI/CD

75 %

100 %

03
04
05

75 %

06
07
08

50 %
38 %

PagerDuty

12 %

12 %

12 %

SquadcastGrafana

OnCallOn-Call

ソリューションを 活用していない

9割のSRE組織が、On-Callソリューションを活用している

GitHub

Actions

Jenkins

Argo CD

PipeCD

12 %

12 %

12 %

Circle CI

Concourse

CI

Flux

長期運用しているサービスでは、Jenkinsの活用が多い傾向にあったが、Argo CDとPipeCDの活用も増えている

20

01
02

7.IaC/CaC

8.k8s Manifest/deploy管理

03
04

63 %

100 %

63 %

88 %

05
06
07
08

50 %
25 %
25 %

Terraform

AnsibleAWS

Chef
CloudFormation

12 %

12 %

12 %

AWS CDK

PulumiPacker

全SRE組織が、Terraformを活用している

Helm

Kustomize

12 %

12 %

k8sを

Kubevela
活用していない

Grafana

Tanka

Helm、Kustomizeの活用が多い傾向にある

21

01
02

9.DB

03
04

100 %

05

75 %

06
07
08

50 %

50 %

50 %

50 %
38 %
25 %

Redis

AmazonAurora / RDS

MySQL

Mongo

DB

ElasticsearchAmazonDynamoDB

Cloud SQL

Cloud

Spanner

全SRE組織が、Redisを活用している

MySQLとMongoDBの活用が多い傾向にある

12 %

12 %

12 %

12 %

12 %

Postgre

SQL

OracleDatabase

AmazonDocumentDB

Cloud

Bigtable

CloudFirestore

22

01
02

10.CDN

11.開発言語（SREsが業務で使っている）

03
04

100 %

100 %

88 %

05

75 %

06
07
08

25 %

25 %

25 %

25 %
12 %

AmazonCloudFront

FastlyAkamaiCloud CDN

全SRE組織が、Amazon CloudFrontを活用している

Cloudflareshell script

Go

PythonNode.js

12 %

12 %

12 %

Java

Ruby

TypeScript

全SRE組織が、shell scriptを活用している

また、Go、Pythonの活用が多い傾向にある

23

01
02

12.負荷・障害試験ツール

03
04

50 %

50 %

50 %

05
06

38 %

07
08

25 %
12 %

LocustApacheJMeter

Grafana k6

VegetaGatling

Locust、Apache JMeterの活用が多い傾向にある

近年は、Grafana k6の活用も増加傾向にある

障害試験

ツールを

活用していない

24

01
02

13.インシデント管理

03
04

38 %

38 %

05
06

25 %

07

25 %

08

GoogleDocs

Google Sheets

Datadog

Incident

Management

Notion

12 %

12 %

12 %

12 %

12 %

Statuspage

PagerDuty

Confluence

GitLab

Issue

Slack

ドキュメントソリューション活用が多い傾向にあったが、Datadog Incident Managemetの活用も増えている

25

01
02
03
04

14.Postmortem

38 %

05
06

25 %

07

25 %

25 %

08

NotionGitHub

Datadog

Postmortem

Notebooks

Google

Docs

12 %

12 %

12 %

esa

GoogleSheets

書いてないドキュメントソリューションの活用が多い傾向にある

SREs紹介

27

01
02
03
04
05

松田 正也

赤野 裕喜

Matsuda Masaya

Akano Yuki

メディア統括本部

株式会社タップル 技術本部

サービスリライアビリティグループ

SREグループ

06
07
08

岩永 勇祐

岡麦

Iwanaga Yusuke

Oka Mugi

株式会社AbemaTV 開発本部

株式会社CAM

開発局 SRE

Creative Division

28

01
02
03
04
05

長谷部 充洋田口 雅教

Hasebe Mitsuhiro

Taguchi Masanori

株式会社アプリボット

AI事業本部 アドテクディビジョンSRE

SREグループ SREチーム

06
07
08

藤井 貴大

吉岡 賢

Fujii Takahiro

Yoshioka Suguru

株式会社CyberZ

株式会社サムザップ プロダクトDiv.

開発本部

SRE

事業部毎のSRE組織情報メディア事業

30

01
02
03

Service Reliability Group

メディア統括本部 / サービスリライアビリティグループ

04
05
06

Serveice Reliability Group（通称SRG）は、「サイバーエージェント
グループが提供するプロダクトの信頼性を”横断的に”向上させる」というミッションの元、横断SREとしてメディア事業・そしてサイバーエージェ
ントグループへのSRE導入を促進し、信頼性を向上するための取り組みを行っている組織です。

07
08

SRE組織パターン

SRE実装パターン

事業部横断SRE
SRE Center of Practice、Embedded
SRE（Enabling SRE、Evangelist SRE）、
Movable Embedded SRE

SRE活動

7〜9年目

所属人数

10〜15人

担当領域

AMEBA、AWA、CL、社内基盤など、100以上のサービス・
システム

31

技術領域（スキルセット）

チームの文化や体制、働く環境

監視：Datadog, Mackerel, Prometheus, Grafana,

組織活性化施策として、srg_chatting、srg_studyなど

Amazon CloudWatch, Cloud Monitorin

を行ってい

02

可観測性：Datadog, AWS X-Ray, New Reli

横断組織なので、幅広いドメインの知見が得られる

03

SLO：New Relic, Datado

01

04
05
06
07
08

インシデント管理：Datadog Incident Management,
Statuspage, Google Doc
Postmortem：GitHub, Datadog Postmortem
Notebooks, Google Docs, Notio
On-call：PagerDuty, Squadcas
プラットフォーム：AWS, Google Cloud, OpenStack,

業務内容
業務遂行する上で主軸となる3つのバリュ
各事業の技術ノウハウを集約し、展開す信頼性を明確にし、組織で改善す

Concourse CI, Argo CD, PipeC
開発言語：GO, Java, Python, shell scrip
DB：MySQL, Oracle Database, MongoDB, Redis,
Elasticsearch, Amazon Aurora / RDS, Cloud SQL,
Amazon DynamoD
CDN：Amazon CloudFront, Fastly, Akamai,
Cloudflare, Cloud CD
負荷・障害試験ツール：Locust, Apache JMeter,
Vegeta, Grafana k
IaC/CaC：Terraform, Pulumi, Ansible, Che
k8s Manifest/deploy管理：Helm, Kustomize,
Kubevela, Grafana Tanka

こ れ ま での 取り 組 み や ア ウトプット
CyberAgent Developers Blo

業務内容の一例
事業におけ る技術 的も しく は 組織 的課題 の 発 見 および解アーキ テ クチ ャ の 初期設計 や改善、IaC ベ ースの 提
CDN 移設 、AWS 移設 、Terraform moduleの 提様々 な技術 要件・規模 の シ ス テ ムの パフォ ー マ ンスチュー
ニ ン グ や 負荷 対
新規サ ー ビ ス、ABEMA 「 FIFA ワ ールド カ ップ カ
タ ール 2022」全64試合無料生中継 、Ameba 認証刷
SRE文化の 醸
プロダクトチーム、事業 責任者へ のインストール /EnablinSREプ

ラ ク ティ スの開 発 や 様々 な 規模 の組織 へ の 導入 、

改
SRE
化

成熟度評価 、DB ワ ーキン ググ ループ、 コ スト 最適

執筆 し た記 事一
デ ー タベ ース ワ ーキン ググ ループ活 動 の 紹
SRGメンバーがプロダクトに対し、技術力で直接貢献する

OpenShift, Docker, Kubernete
CI/CD：Jenkins, GitHub Actions, CircleCI,

種オペレ ー ショ ンの 自動 化や 効率 化を 支援 する ツ ー
ルの開 発運用 や改SRE ・運用 プ ラ ク ティ スの改
監視 見直し、イン シデ ント対 応 体制 整備 、 ポ スト モ ー
テ ム見直し、SLO 導入 、トイルの 撲
SREプ ラ ク ティ スの 発 信と組織 間連携 の 強 化
各登的 なSRE 推進 と 成熟度評価 @6社合同 SRE 勉強
シ ン グ ルク ラ ス タ ー マ ルチ テナ ン シ ーを 目指 している
EKS上でkubevelaの 運用 をして みた@ CNDT 202
Well-Architectedな組織 を 
実現 する ため のチ ャレ ン ジ - な ぜ 、CA W-Aを 作ろうと 思 っ た の か - @j awsdays 201
事業 責任者も必 見 ! AWS Well-Architected
Frameworkの ビジネ ス へ の 有効 活 用＠
AWSSummitTokyo 201
事業と 歩む Ameba シ ス テ ム 刷新 の 道@ AWSSummitTokyo 202
ポ ー タ ル サ イト（SRG Portal
Embedded SRE として サ ー ビ スに SRE をやって み
横断

MySQL8.0 のバック ア ップ は どれがいいの か

32

01
02
03

ABEMA

株式会社AbemaTV / 開発本部 / SRE Team

04
05
06

横断的なインフラを担当していたメンバーを中心に発足し、2021年頃にクラウド基盤を管理するチームとSREプラクティスの導入を推進しているチームに分離。

以降、ユーザー向け機能を提供するチームを中心にSREプラクティスの導入を行い、継続的に適切な信頼性への投資をもってデリバリー速度の向上
を目指す。

07
08

SRE組織パターン

SRE実装パターン

単一プロダクト専任SRE

Platform SRE、Embedded SRE (Enabling SRE​​)

SRE活動

4〜6年目

所属人数

1〜4人

担当領域

ABEMA

33

01

技術領域（スキルセット）

チームの文化や体制、働く環境

こ02

監視：Prometheus, Grafana, New Relic, Amazon

活動における技術領域の制限はなく信頼性の視点で課題

登CloudWatch, Cloud Monitorinの発掘から解決までを行

可観測性：OpenTelemetry, Cloud Profiler, Cloud

抽象的な問題を扱うことが多いため、ディスカッションを

04

Trac

中心としたコミュニケーションは多い

05

SLO：Prometheus, Grafan

03

06

インシデント管理：PagerDuty, GitHu
Postmortem：esa, Notio07

On-call：PagerDut08

プラットフォーム：Google Cloud, Kubernetes, AWS
CI/CD：PipeCD, GitHub Actions, CircleC
開発言語：Go, Python, shell scrip

業務内容

維持 における ツ ール 開 発、お よび 体制の 構
SRE、お よび De v Ops 関連 の プラクテ ィスや 実施サポ ー
信頼性

大型配 信 時 の 取り まとめ、お よびサポ ート

DB：MongoDB, Redis, Elasticsearch, Cloud
Spanner, Cloud Bigtable, Cloud Firestor
CDN：Akamai, Cloud CDN, Fastly, Amazon
CloudFront,
負荷・障害試験ツール：Grafana k6, Locus
IaC/CaC：Terraform, AWS CloudFormation,
Packe
k8s Manifest/deploy管理：Kustomize, Helm

業務内容の

一例

設定・可 視化 ・アラ ート 基盤 の 構築( Platform
SLI/SLO 導入・運用サポ ート ( Enabling
イ ンシデント 管理ツ ールの 導入・構障害レベ ルの 導入・対応フロ ーの 策
負荷・障害試験 の 実 行 基盤構
大型配 信 時 におけるキ ャパ シ ティ プラ ンニン グ・試験実
施・監 視体制の 構築

SLI/SLOれ までの 取り組み や アウ ト プ ットv
2021: ABEMASRE の挑戦〜 Frontend & Backend Team へのEmbedded SRE 導入
SRE NE X T: 事業の成長と共に歩む、 ABEMA SRE 探
求の歴大規模 イ ベ ント を成功させるための 負荷・障害・ セ
キュリティ対FIFA ワ ール ドカ ップ 2022に向けたキャパ シ ティ確保の軌AbemaT V ：Google Cloud の活用による徹底した 負荷 対策によって世界的スポ ーツ イ ベ ント において安定した 視 聴体 験 を提供

ABEMA De eloper Conference

34

01
02

IU-SRE030405

横断的なインフラを担当していたメンバーを中心に発足し、2021年頃にクラウド基盤を管理するチームとSREプラクティスの導入を推進しているチームに分離。

以降、ユーザー向け機能を提供するチームを中心にSREプラクティスの導入を行い、継続的に適切な信頼性への投資をもってデリバリー速度の向上
を目指す。

06
07
08

SRE組織パターン

SRE実装パターン

事業部横断SRE

IU-SRE: Embedded SRE（Enabling SRE）,Platform SRE,

SRE Center of Practice,Movable Embedded SRE

Tapple: Product SRE,Embedded SRE（Enabling SRE）

SRE活動

4〜6年目

所属人数

5〜9人

担当領域

エンタメコンテンツ、ビジネスバラエティメディア、ライフス
タイルメディア、Tapple、社内基盤など、80以上のサービス

35

01

技術領域（スキルセット）

チームの文化や体制、働く環境

こ れ ま での 取り 組 み や アウ ト プ ット

02

監視：Datadog, Prometheus, Grafana, Amazon

会社の方針に合わせ週2日のリモー

CyberAgent De elopers Blo

CloudWatch, Cloud Monitorin

横断組織なので、幅広いドメインの知見が得られ可観測性：Datado

新規事業が多い環境なので設計から関われる

03
04

SLO：Datado

05

インシデント管理：Notion, Datado

06

postmortem：Notio

新規案件の設計/構07

プラットフォーム：AWS, Google Cloud, Microsoft

運用改善、負荷対策

08

Azure, Docker, Kubernete
開発言語：Go, Node.js, shell scrip
DB：MySQL, MongoDB, Redis, Elasticsearch,
Amazon Aurora / RDS, Amazon DocumentD
CDN: Amazon CloudFron
負荷・障害試験ツール：Apache JMeter, Grafana k
IaC/CaC：Terraform, AWS CloudFormation,
Ansiblk8s Manifest/deploy管理：Helm

75億 ドキ ュ メント 以上 の デ ー タを保持す るMongoDB
を 、Amazon EC2からMongoDB Atlas へ約3ヶ月 で移 設 した 方
SRE 内 定者ア ル バ イト 成果ブロ
タ ッ プ ルSRE はタ ッ プ ルの 成長をどこま で 支え られる
か | CyberAgent De v elopers Blo

業務内容

On-call：Grafana OnCal

CI/CD：Jenkins, GitHub Actions, Argo Cv

CAM

試験 環境に k 6 -operator を活 用 し 、ChatOps ラ
イ ク な負荷 試験を実現 で きた
GCPリ ソ ース を Terraform 管理してみよ
負荷

業務内容の一例

を 用い た 環境の 刷
個人情報 な ど セキ ュア な 情報を扱う基盤 設計や構MongoDB Atlas/Elasticsearchの パフォ ー マ ンス ・チ ュ ー ニ ン グとサ イ ジ ン グ
ArgoCD登

タ ッ プ ルに おけ るBFF と openAPI 導入 事例の 紹介 |CA BASE NE X T - CyberAgent De v eloper
Conference by Ne x t Generation
100を超え る クラウ ド サ ー ビ ス環境 を SREで 効率的 に
コ スト 最適 化 した話 | CA BASE NE X T CyberAgent De v eloper Conference by Ne x tGeneration

画的 に負荷リス クを排除す る ため のキ ャパシティプ
ラ ン ニ ン グ - Speaker Deck
計

36

01
02
03

CyberZ株式会社CyberZ / 開発本部

04
05
06
07

CyberZのSREは、ライブ配信プラットフォームであるOPENREC.tvなどのサービスを中心に、システムの安定性を向上させるために日々従事しています。最近ではそれ以外の新規サービスについてもSRE業務を兼任しており、SREとしてよりスケールメリットのあるチームを目指しています。

08

SRE組織パターン

SRE実装パターン

子会社専任（複数プロダクト横断）SRE

Product SRE、Embedded SRE（EnablingSRE）、Movable Embedded SRE

SRE活動

4〜6年目

所属人数

1〜4人

担当領域

OPENREC.tvおよび一部の新規事業37

技術領域（スキルセット）

チームの文化や体制、働く環境

02

プラットフォーム: AWS, Kubernete

インフラよりも、バックエンドなどの経験があるエンジニ

Blog

監視: Prometheus, Grafana, Amazon CloudWatc

アが多OPENREC.tvに

可観測性: OpenTelemetry, AWS X-ra

場合によってはバックエンドの実装を行うこともある

03
04

SLO: 独自実装基盤を利05

オンコール: Grafana Oncal

06

CI/CD: GitHub Actions, Argo CD, PipeC

業務内容

IaC/CaC: Terraform, AWS CloudFormation,

SREプラクティスの模索、実07

Ansibl

各開発チームへDevOps関連知識の啓蒙や実践サポー

08

k8s Manifest/deploy管理: Kustomize, Hel

OPENREC.tvの一部開発業務

DB: Redis, Elasticsearch, Amazon Aurora / RDS,
Amazon DynamoD
CDN: Amazon CloudFron
開発言語: shell script, Python, G
負荷試験ツール: Locus
インシデント管理: Slack, Notio
Postmortem: GitHub, Notion, Google Doc
ドキュメントツール: Notion, Google Docs

業務内容の一例

で の 分散 ト レ ー シ ン グ の 検証お よ び導SLI/SLOや オ ン コ ール体制など、より 良い 開発体験を 補
佐す る 仕組み を 検
バ リュ ースト リ ーム マ ッ ピ ン グ の実 施主
FourKeys 計測基盤 の 構築 、 提古い アプ リケ ー ショ ンの 廃止お よ び Kubernetesへの 移 行
Kubernetes環境など

これまで の 取 り 組み やア ウ トプット01

おけ るOpenTelemetryの 活
DevOpsの 取 り 掛か りと し てのバ リュ ースト リ ーム
マ ッ ピ ン グ のスス
Cyber Z が Amazon DynamoDB を 使用し てフ ォ
ロ ー タ イムラインの 表示 に 必要 な Read-Light 方式 を
実 現した方法登V MとAWS ECSが メ インのインフラにKubernetesを導入した効Cyber Z のSREに おけ るプ ロダ クト開発チームとの関
わり
OPENREC.tvに おけ るDynamoDBを 用いたデザ イン
パタ ーンゲーム事業

39

01
02
03

CA GameFi

CA GameFi / SRE

04
05
06
07

CA GameFiのSREはCA GameFiの全プロダクトに注力し、ユーザ体験を損なわせないことを目的にプロダクトの信頼性を向上させる取り組みを行っています。

08

SRE組織パターン

SRE実装パターン

子会社専任（複数プロダクト横断）SRE

Product SRE、Platform SRE

SRE活動

1〜3年目

所属人数

1〜4人

担当領域

マルチテナントインフラ基盤およびCA GameFi内の全プロジェクト

40

01

技術領域（スキルセット）

チームの文化や体制、働く環境

02

監視：Datadog, Grafana, Cloud Monitoring,

SREで運用しているインフラ基盤を担当しつつ、各プロ

VictoriaMetric

ジェクトがインフラ基盤を利用するに当たって導入や運用

可観測性：Datado

も担当しま

04

SLO: Datado

会社の方針に合わせ週2日リモートによる開発体制をとっ05

インシデント管理：Notio

ています

03

06

postmortem：Notio
On-call：PagerDut

07

プラットフォーム：AWS, Google Cloud, Docker,

08

Kubernete
CI/CD：Jenkins, GitHub Actions, Flu
開発言語：Go, Python, shell scrip
DB：Redis, Cloud SQL, Cloud Spanne
CDN：Amazon CloudFron
負荷・障害試験ツール：Apache JMeter, Grafana k
IaC/CaC：Terraform, Ansibl
k8s Manifest/deploy管理：Kustomize

業務内容
Kubernetesを用いたマルチテナントインフラ基盤の運
各プロダクトのインフラ構築、運用、セキュリティチェッ
ク、コスト管理な
SREの実践

41

01
02
03

アプリボット

事業部 / SRE

04
05
06

アプリボットのSREチームは、アプリボット内の全プロジェクトのインフラを一手に担う横断組織です。小規模な新規事業から大型のIPゲームタイ
トルまで、様々なプロジェクトに寄り添い、臨機応変に対応しています。
最近では、サイバーエージェントのゲーム・エンターテイメント事業部（SGE）に所属する各社を横断したプロジェクトや、非ゲーム領域のWeb
サービス開発事業など、より活動領域が拡大しています。

07
08

SRE組織パターン

SRE実装パターン

子会社専任（複数プロダクト横断）SRE

Product SRE、Platform SRE

SRE活動

7〜9年目

所属人数

5〜9人

担当領域

アプリボット内の全プロジェクト（小規模な新規事業から大型のIPゲームタイトルまで様々）

42

一例

01

技術領域（スキルセット）

チームの文化や体制、働く環境

業務内容の

02

監視：Datado

全社方針に合わせ、毎週火曜、木曜のみリモート推奨

Applibot Gems Vol

可観測性：Datado（2023年6月現在

SLO：Datado

主担当のプロジェクトを持ちつつ他プロジェクトも横断し04

インシデント管理：Google Docs, Google Sheets,て担当する人や、1つのプロジェクトを専属として担当す05

Confluence、GitLab Issu

る人、全プロジェクトを俯瞰して臨機応変に対応する人な

On-call：PagerDut

ど、本人の適正や状況に合わせて担当を割り振っていまプラットフォーム：AWS, Google Cloud, Docke

す。

03

06
07

CI/CD：Jenkins, GitHub Action

08

開発言語：Go, Python, shell scrip
DB：MySQL, PostgreSQL, Redis, Amazon Aurora /RDS, Amazon DynamoD
CDN：Amazon CloudFron
負荷・障害試験ツール：Gatling, Veget
IaC/CaC：Terraform, Ansible

業務内容

インフラ 環境の 設計 / 構築 / 運用 / 改善
安定リリ ース/ 安定運用 の 実現に向けた負荷対策 や モニタ
リング、キ ャパシティプランニングな
ユ ー ザ ーの ゲ ームプレイ 体 験向上 や 開発者 の 開発 体 験向上の ため の 各種改
セキ ュリティ の 担保:.

.
product/ 5 6 4 63 7 02 78998 01
Applibot Gems Vol .
https : //blog . applibot . co .j p/2020/0 9 /11/applibotgems- v ol-2/
https //techbookfest org/

43

01
02
03

サムザップ

株式会社サムザップ / SRE

0405

サムザップでは各プロジェクトにSRE 担当がおります。プロジェクトに深く入り込み、開発メンバーと一緒に SRE導入や運用を見据えた各プロ
ジェクトに最適なSRE文化作りなど、サービスの信頼性を向上するために
日々取り組んでいます。

また、プロジェクトを超えた情報共有を行い、技術知見の蓄積、標準化、
SRE文脈に基づいた文化づくり、サイバーエージェントのゲーム・エン
ターテイメント事業部（SGE）各社との技術交流など幅広く活動しており
ます。

06
07
08

SRE組織パターン

SRE実装パターン

単一プロダクト専任SRE

Product SRE / Embedded SRE（Enabling SRE）

SRE活動

4〜6年目

所属人数

1〜4人

担当領域

運用サービス、新規サービスのSRE実践

44

01

技術領域（スキルセット）

チームの文化や体制、働く環境

これまでの

02

監視：Datadog, New Relic, Amazon CloudWatc

主担当制による責任（独立性）と情報共

Sumzap03

可観測性：Datadog, New Reli

共有されている資産を元に構築することが可SLO：Datado

各プロジェクトにおける技術的な導入判断ができ04

インシデント管理：Google Sheet

05

Postmortem：Google Sheet

各サービスの主担当が集まり、情報共有する定On-call：PagerDut

会社の枠を超えて子会社間で情報共有する定06

プラットフォーム：AWS, Google Cloud, Docke

働く環

CI/CD：Jenkins, GitHub Actions, AWS CodeBuil

会社の方針に合わせ週2日のリモー

08

開発言語：Go, shell scrip

サービスやチームで相談し柔軟に対応

DB：Redis, Amazon Aurora / RD
CDN：Amazon CloudFron
負荷試験ツール：Locust, Gatling, Veget
障害試験ツール：障害試験ツールを使用せず、自分たちでインスタンスを強制停止したりして確認していIaC/CaC：Terraform, Ansibl
k8s Manifest/deploy管理：k8sを使用していない

E ngineering Blo
Glueを用いてAurora から Big Q uery への データ 転送
処 理を 高速化 した
AWS の Blue/Green Deployment で ハマっ た こと を
つらつら
社内 制 度 を 利 用して AWS 認 定 を 10個取得 した
時限オ ートス ケ ー リ ン グと ス ポ ットインスタンス によるリソ ース 最適
CodeBuildを使用したFargate開発 環境の 自 動構

情報共

07

業務内容

インフラ 環境の 設計 、構築、 運用 、 改善 な どコ ストを 含む
管
プロ ダ クトに対する 負荷試験 、セキ ュ リ ティ チェック、 障
害試験 な ど の 実
SR E の 実践 （ 運用改善 、 コ スト 管理 、 負荷 対 策 、 監視 、
障害管理 な ど ）取 り 組み や アウ トプット

登019 Tokyo, ある SR E チ ーム の挑戦
運 用 6 年目の大規模ゲ ームを AWS 移設後に安定運 用する た めの技術と今後の展
AWS Summit Online Japan 2 0 2 0 , 『この フ ァ ン 』
におけるマネ ー ジドサ ー ビ ス ドリブ ンな アー キテク
チャへの挑
ゲ ームインフラ 運 用 ・ 開発 メソ ッ ド LT 大会！ - AWS,K ubernetes, Jenkins - 2 0 2 0 , 「戦国炎舞 K I Z NA- 」 で 行っ たAWS のコ スト 最適化の話
AWS Summit 2

AI・DX事業

46

01
02
03

アドテクディビジョン

AI事業本部 / アドテクディビジョン / SREグループ

04
05
06

SREグループは、AI事業本部が提供するAI・DXを中心とした複数の事
業・サービスと一体となり、各サービスに所属しながらSREの視点を持ってインフラ構築やバックエンドなどの開発を行っています。

また、横軸組織としてもSRE観点の横展開や、技術の共有を行い効率化を目指しています。

07
08

SRE組織パターン

事業部横断SRE

所属人数

SRE実装パターンProduct SRE 、 E m bedded SRE （ Evan g e l ist
SRE ）、 Movab l e E m bedded SRE

担当領域

SRE 活動

1〜3年 目

5〜9人
アドテクディビジョ
CPI事業部：CPI/ノンインセンティブ型広告配
AF事業部：CPA/インセンティブ型広告配
AMoAd事業部：アドネットワークを中心とした配協業DXディビジョ
エレベーターサイネージカンパニ
AICG関株式会社CyberMetaverse Production
AIクリエイティブディビジョン Future Event/Live事業部

47

01

技術領域（スキルセット）

チームの文化や体制、働く環境

02

監視：Datadog, Mackerel, Prometheus, Grafana,

基本会社の方針に合わせていますが、担当チームの働き方

New Relic, Amazon CloudWatch, Cloudに合わせるケースも多いです。現状リモートは多めではあMonitorin

りますが、出社しているメンバーもいます

04

可観測性：Datadog, AWS X-Ra

チーム内勉強会として、GoogleのSRE本の輪読であった

05

SLO：Datado

り、ベ ストプラクティスの輪読会などを実施（週１インシデント管理：Google Docs, Google Sheet

横軸組織として複数の事業部を見ているため、ナレッジ共Postmortem：Datadog Postmortem Notebook

有会（週１

07

On-call：PagerDut

チーム内懇親会(月１)08

プラットフォーム：AWS, Google Cloud, OpenStack,

03

06

Docker, Kubernete
CI/CD：Jenkins, GitHub Actions, Argo C

業務内容

開発言語：Go, Python, Ruby, Node.js, shell script,

基本、 Embedded SRE として、事業並びに、サ ー ビスと一体になって 開発 を行っています。一体になることでコ
ミュニケ ーシ ョ ン ロスを減らし、パ フォー マ ン スのあげやすい状態を作る。また、横軸として、技術の共有を行い、ノウハウなどの効率化を図
既存 シ ステ ム から、マ イ クロサ ー ビスなどへの移Kubernetes などコ ン テナ環境の構築 ・ 支
監視/ ア ラート 設計、 シ ステ ム の安定に向けたサ ー ビスのモニタリ ン グ、キャパ シ ティ プラン ニ ン グ、 SLI/SLO など
策定、またこれらの フ ァ シ リテ ーインフラ （サ ー バ、ネ ット ワ ー ク）設計 ・ 構
シ ステ ム障害 時の対応

TypeScrip
DB：MySQL, MongoDB, Redis, Amazon Aurora /RDS, Cloud SQL, Amazon DynamoD
CDN：Amazon CloudFron
負荷・障害試験ツール：Locust, Apache JMeter,
Grafana k
IaC/CaC：Terraform, AWS CloudFormation, AWS
CDK, Ansible, Che
k8s Manifest/deploy管理：Kustomize, Helm

要件 に 応じ たプラット フォ ーム、 アーキテクチ ャ の 選定・
構
CI/CDの 構築 、 運
MLOpsの 構築並び 、 機械学習 の 導
ア プリケー ショ ンの 開発 、 支
新規開発 、 サ ーバ 構築全般支援

これ までの 取 り組 み や アウ トプット

登協業 DXDi v De v eloper ' s way （ AI 事業本部内のみ）SREsの取り組み

49

01

Datadog Incident Management使ってAmebaのインシデント管理体制整備した話

02
03

課 題 整理はじめに

04

横軸組織の SRG がEmbedded SRE （Site Reliability Enginner）としてAmebaに参加し、SRE 文化

05の構築の一端としてIncidentMangementを行うことでサービス品質の向上に寄与したお話をします。

課 題 整理 を行ったとこ ろ 、 以 下のような問題に 直面 した。（ 図1 ）体制

07

インシデント対応を行うメンバーの偏りやインシデントコマンダー不在による連携力低下、トリアー

08

ジ・インシデント対応フローの未定義に起因した問題解決遅延によりMTTRの肥大化が問題となった。

既存 の 運用 で は インシデント 発生時 にメンバー 各人 が ど う い った 役割 として問題解決に向 け て
稼働 する か が決定して い な か ったた め 、 特 にIncident C ommandarと Op eration C ommandar
を 役割 と 責務 を 明確 化し、 当該職務 が 重要 な 役割 をになって い る 事 を 説明 。（ 図2 ）図1: 現在と理想とのギャップ

図2: 体制（相関図）

06

背景

50

01

トリアージ

02

重大障害に対してのみトリアージが設定されていたものを、復旧が必要となる全ての障害をイ03

当該トリアージに関してはDatadogIncidentを利用すれば、[Setting]にて表記可能となるため、記載した上でチーム全体に案内すると良い。
め、記載した上でチーム全体に案内すると良い。（図4）

ンシデントのスコープとして再定義。（図3）

04
05
06
07
08

図3: これからのトリアージ

図4: DatadogIncident

51

01
02
03
04
05
06
07
08

Da t a d og Incident

Da t a d og Incidentでのインシデント 管理 は 特 にサ マ リに 相当 する 以下 の 3点 をリア ルタ イ ム でア ップ デートする こ とが重 要です
Wha t happ ened (何 が 発生 したか
I mpa ct (ユ ー ザ影響/ い つ か ら い つ まで
Why it happ ened ( な ぜ 起 こったか )こ れ ら は事 後 に 振 り返りを 行 った 際 に必要な 情報 となる だ け
でな く 、インシデント 発生時 に お いて最新 化 する こ とでサービスの メ ン バ ーの キャッチ ア ップコ ストが大 幅 に 削減 する ことが 可能 です。

事 業責任者目線 に お いては 状況 を 的確 か つ迅 速に 把握 する ことで、 意思決定 のス ピ ードを向上 させ ます。

エ ンジ ニ ア 目線 に お いては 障害解決チ ー ム への ヘルプ難易 度
が低 下 するといった 効果 が 見 込 め ます。

①②③

Da t a d ogPos t mor te m

よ くつま づ く 問題

インシデントど収束後 に 振 り返りを 行うこ とは 重 要です。

Da t a d ogPos t mor te m を 利 用すれ ば 、 発生 した 障害 に 当該
Pos t mor te m を 紐づ ける こ とが 可能 であり、 障害概 要や 発生
時刻 、 解決 に 至 るまでの タ イ ムラ インな ど の 情報 が
Pos t mor te m に 引 き 継 がれるた め 運用が 非常 に 楽 になります。

評価
Incident対応における評価は運用が困難です。どのチームもパッシブな対応となるインシデント解決を目標として挙げる

れ だけ 情報整備 を 行 なっても、人は 自らDo c s を確 認 して
意 欲 的に対応を 進 めることはできません。
IncidentM a n ag e m entにおいてはIncident Comma nd ar を
中心 にインシデント 管理手法 について 理 解をしても ら うために フォ ローを 積極 的に 行 うことでインシデント 発生時 に解決
まで 責任 をもつ人 材 を 育成 することができます。

また、 「そ も そ も設定したト リア ー ジ に 即 したインシデント
が 起票され ない 」 という 問題 も 発生 しが ち です。こ れ は
IncidentM a n ag e m entを 行 う人間が アラ ート、 CS か ら の 問
い 合 わせや リリ ース 後 に確 認され た 障害 などに対して 起票 を
行 うことを 促 すことで 文 化として 醸成 が 進み ます。

ことはなかなかありません。こういったケースだとチームとして設定しているミッションを優先することが個人としての評価向上の近道となってしまうため、インシデント対応に対終わりにする評価を明確化しましょう。

まずは体制・トリアージやインシデント対応フローの整備は

注意点はMTTRの短縮などの長期的かつ個人ではコントロー

最低限必要として、ビジネスサイドを巻き込むには「地道にルできない数値を追うのはNGです。インシデントコマン

声かけ・質問への返答速度向上」が一番大事です。

ダー担当数やMTTAといった間接指標で評価していくと良い

その上でもインシデント運用が漏れるケースはあるので、代でしょう。

わりに起票・更新したりといった手厚いサポートが必須とな
ります。

52

01

CyberZでのトイル

可視化 の 取 り 組み

02
03
04

はじめまして。CyberZでSREをしている藤井と申します。

05

普段はOPENREC.tvなどを中心に、いくつかのサービスに

06

SREとして関わっています。

07
08

自動化 できるも戦略的 でなく、 戦術的 で あ るも
一 時的 な 対処 で あ り、 永続的 な 価値 をもたら さ ないもサービスの 成長 に 伴 い 作 業 量 が 増え るも のはじめにCyberZではSREチームが出来てからというもの、各種古いアプリケーション基盤をKubernetesに移行したり、TerraformによるIaCを推し進めたり、各種DevOpsの実践

可視化 しています。

参考程 度ですが G rafana ダッ シ ュボ ー ド で実行しているS QLの一 部 を 以下 に 貼 っておきます。
で本的 には実 際 の 作 業 者 が、 上記 の 定義 に 則 りそれをトイルと み なすかどうかなどを 判断 します。

基を牽引・啓蒙したりしています。その結果として、普段の業
務におけるトイルの割合はかなり減ったと感じています。しかし、明確にトイルについて計測はこれまでしてきていませんでした。

今回は、今一度トイルに向き合い、トイルの計測を始めた話についてお話しできればと思います。

トイルの

定義

定義 は、 G oo gl eのSRE 本 第五章「 E li m i nat i n g
To il」 に 従 っています
トイルの手動 での 作 業を 伴 うも
繰 り 返さ れるもの

トイルの計測・

可視化

本題 の計測およ び可視化 についてですが、今回は計測に 際 して 新 たな基盤を 構築 したりはしていません。

CyberZでは 昨年 から F ourKeysの計測のため、OSSで あ る
d ora - team / four k eys に 少 し 手 を 加え た基盤を 構築 およ び
運用 しています。 デ ー タ ストアで あ る BigQ ueryには、 紐づ
けた Gi t H ub Repos i toryの各種イ ベ ントが W eb h oo k経由
で 書 き 込 まれており、これを G rafanaで 可視化 することでF ourKeys メ トリ ク スとして 役立 てています。

F

デ ー タ を 活用 して 構築 しています。 具体的 には、 Gi t H ub Issueのイ ベ ント
を 用 い、 特定 の ラベ ルの 付 いたIssueの 件数 などを G rafana
今回のトイル計測は、この ourKeys基盤の

図 1 : FourKeys基盤
F ourKeysは Gi t H ubの W eb h oo k イ ベ ントを 1 行 ず つ
BigQ ueryのevents _ ra wテ ーブ ルに 書 き 込 んでいます。
event _ typeが i ssuesのイ ベ ントの 最新 一 件 から、To ilラベ
ルの 付与さ れたものの み に 限定 することで、トイルIssueを
抽 出しています。

53

01
02
03
04
05
06
07
08

L CT

*

F R OM

(

SE E

L CT

A ALU A AY_A GG (v _ w

O D BY_D ES C

L M T

1) [OFF SE T(0)]F R OM

fourkeys . e v ents _ ra w

W HER Ee v ent _ type = " issues "GR OUP BY

i d

SE E
S V
E RR
e ents ra
R ERtime created
I I

運用 フ ロ ーとしては以下の 通 りです。

トイルが 発生 した 場 合は、作業 者 はその 都度 GitHu b Issue
を作 成 します。

例 として、E K S ノ ードの ディスクサ イ ズ が 減少 した時の ア
ラート対 応 を 挙げ ます。Issueにはトイルであることを 示 すToilラ ベ ルと、そのトイルがどの程 度 の負荷であるかの
Volumeラ ベ ルを 付与 します。

参考: Identifying and tracking toil using SRE
principles

Volumeは、可視化される過程でトイルの負荷を表現するト
イルポイントに変換されます。それぞれ、Easyは1、Normalは3、そしてHardは9ポイントになります。Grafana
ダッシュボードは、指定された期間の全体のポイント合計と、各人の負荷をグラフで可視化します。

) tolisW HER E

REGE XP_CO N TA INS (J S O N _ E XT R ACT( metadata ,'$. issue . la b els '),'" name " : "([^"]*?)Toil ([^"]*?)"');

図3: トイル

図2: トイル計測用Issue

Volumeは一時間未満で作業が完了する「Easy」、数時間を要する「Normal」そして数日以上必要な「Hard」の三種類があります。この区分は、Googleの公開している下記の記
事を参考にしています。

可視化ダッシュボード

SREチームでは、このダッシュボードを定期的に確認することで、トイルについての見直しを行っています。トイルの絶対的な量が多すぎないか、メンバー間での偏りが顕著でないか、トイルのVolumeが適切かなどの認識をすり合わせま
す。

54

01
02

明らかな作業の偏りがあれば他の人にオフロードできないか検討しますし、頻繁に実施されているEasyなトイルがあれば自動化に動きます。上記の図で言うと

03

NodeFilesystemSpaceFillingUpがそれにあたるでしょ04う。実際にはここまで単純なデータではないため、GitHub

05のGUIで把握するのは難しいですが、Grafanaダッシュボー
ドにすることで日々のトイルが一目瞭然になりました。

06
07
08

所感

測定を始 め、 メ イ ン の目 的 であるトイルの把握 以外に も 、い くつ かの 副次的 な 効果も得 られました。 特 に、トイルが 発生 した 時 にGitHub Issue を 作 成 するという作業が 追加 されることに よ り、トイル自 体へ の 負荷 が 若干高 まりました。 今 までは 慣 れている作業で ほん の 数分 で 終え ていた も のも 、Issue作 成 の一 手間 が 増え ることで、 思っ た よ り頻繁に発生 していたり、 面倒 なタ スク であると 改 めて 気 が つく きっか け になりました。実際に 定期的 に 発生 している
P romet h eusのディスクアラ ートから、 Th anos 導入 の検 証を始 めたり、 更 なるトイル 撲滅 の動きに つ なが っています。

トイルの分以外 のS R E メンバ ーが日々実施しているトイルにも 目が 向くよ うになりました。 組織 が 変 化に 強く なるためには、シ ステムや技術だけ でな く 人 や知識も流 動 的 でな け れば
なりま せん 。 特定 の作業 者 に 知見 が偏りが ち なトイル を減 ら
また、自よ り 新 しい人が 受け入 れ 易 い、 変 化に 強 い チ ー ムになるは ず です。Issue を介 して 知識 の 属 人化 を排除 し、
チ ー ム としてトイルに 向 き 合 う動き を今後よ り一 層強 めてい
きたいと 思 います。

すことで、

おわ りに

私 た ち のS R E チ ー ム は、トイルに つ いてはある 程度減 ら せ ていると 感じ ていましたが、い ざ計測を して み るとま だ ま だ改
善 の 余地 がありました。

もちろん全 てのトイル を撲滅 することは 理想論 でしかな く 、
費用対効果 との 天秤 であるのはいうまで も ありま せん が、 何はと も あれま ず計測 、 現状 把握です。 も しトイルの 削減 はしている も のの 計測 ができていない 方 がいましたら、この記 事がトイル 計測 の一 助 となれば 幸 いです。

55

01

Embedded SRE としてサービスに SLO を導入してみる

02
03
04

はじめに

行うまでにやってきたことをご紹介します。

この記事ではあくまで個人的なやり方であり、多くのパター

す。

Enginner）としてドットマネー by Ameba（以下ドットマ

06ネー）に参加し、SRE 文化の構築やサービス品質の向上を

08.信頼 性の 獲得 と 初 期の 取 り組み

私 はEmbedded SREとして、サービス 側 の 部署 か ら信頼 性を 獲得 するために To ilの 削減 や コミュニケ ー ショ ンを 重 視しました。これは 私自身 がSRE 初心者 であり、サービス 側 がSREの メリ ットを 享受 する 前 に 疲 れる可 能 性があるためで横軸組織の SRG がEmbedded SRE （Site Reliability

05

07

1

ンで当てはまるやり方ではないかもしれません。そのため、手法の1つだと思っていただけると幸いです。

SRE を導入するきっかけ
SRE を継続して行うことでサービスの可用性と安定性が向上

2. ビ ジ ネスサ イ ドとの 協力

維持 にはビ ジ ネスサ イ ドの 協力 が 不 可 欠 です。 特 に エラ ー バジェ ットが 枯渇 した 後 の 対応 は、 プロダク
トマネー ジャ ーの 許 可が 必要 です。
サービス品質のし、サービスの品質が向上します。SRE を導入することで可視化できないサービス品質を可視化でき、開発チームと運用チーム間の連携が向上し、問題の早期発見・解決が容易になります。

3.CUJ の決定

最 もビ ジ ネス イ ンパ ク トが 大 きい 部分 からCUJ を決定しました。 今回 は 「ユ ー ザ ーがサ イ トに 訪 れる
→ 商 品 ペ ー ジ一覧 を開ける → 交換 ができる 」 という 一 連の流 れを CUJ としました。
ドットマネーでは、

56

01

4.SLIとSLOの設定

5.エラーバジェットの取り扱い

02

今回のCUJに対して、SLIは「3秒以内に正常にレスポンス

ドットマネーでは、エラーバジェットが枯渇した際の対応をが返せる」と設定しました。また、怪しいリクエストは除外「機能のリリースを禁止する」としましたが、特定の条件下し、定期的に見直しを行います。

では例外を認めます。

03
04
05
06

ドットマネーで現在利用している「ユーザーがトップページに訪れる」際の Datadog クエリを例にあげます。

07
08

Total Event===========

service:cloudfront @http.ident:d-money.jp@http.url_details.path:"/" @http.status_code:[400 TO 499]
host:"arn:aws:cloudfront::masked" @http.useragent_details.browser.family:curl

Good Event==========

service:cloudfront @http.ident:d-money.jp@http.url_details.path:"/" @http.status_code:([200 TO 299] OR [300 TO 399])
host:"arn:aws:cloudfront::masked" @http.useragent_details.browser.family:curl@duration:<3s

6.SREの浸透と継続的な改善
SREは終わりのない文化であり、定例での振り返りやサービ
ス内での浸透が重要です。また、全員が参加するチャンネル
で週に1回SLOサマリーを投稿するツールを作成しました。

https://github.com/rluisr/datadog-slo-insufflate

7.今後の展望
私はまだSREを完全に理解していませんが、導入から改善に努めることで知見が得られると考えます。今後はSREとビジ
ネスインパクトの紐付けを可視化し、SREがビジネスに対して実際に影響があることを示したいと思います。

導入時の工夫サービス側の部署から信頼性を獲得するためにToilの削減やコミュニケーションを重視しました。

57

01

Toil などを探し改善をする

インシデント対応フローの確立

02

サービスのインフラ構成を把握したり、デプロイフローなど

サービス品質を担保するためにもインシデント対応フローをを調査しているうちに Toil が見つかりました。

確立し MTTR(Mean Time To Repair: 平均修復時間)を短03
04

縮することも SRE の1つです。そしてその文化を継続させ
例えば

05
06
07
08

なければなりません。インシデント対応フローのドキュメン

全くメンテナンスされていない EC2 と Ia

トは古くそれに沿ったフローでは動いていなかったためビジ

過剰なリソース割当によるコストの無ネスフローも含めて確立しました。

長時間かかるデプロイフロ

ここでは、オンコールの導入、インシデント対応フローの確

インシデント発生時の対応フローがない

立、Datadog Incident を活用した MTTR の計測とポストなど。

モーテムの運用に関する物事を進めてきました。

EC2 と Ansible、過剰なリソース割当によるコストの無壁

駄、デプロイフローの改善は全て、EC2 から Fargate へ移SRE 導入時の行を行うことでサービス側へ数値として明確な成果を示すこ自身 の 信頼性 をサービス側の 部署 から 得 る 際 に Toil 削減 の目的 で EC2 から Fargate への移行を進めていました。

その 際 に A W S Copilot という ECS ツ ールの 検証 、導入をしていましたが SRE の導入には 新 しい ツ ール や プロ セ スが必要 となるためそれらを導入 ・整備 するのは 手 間がかかり、コストが 増加 する 場合 が あ ります。

とができました。

コミ ュ ニケ ーシ ョ ン

ッ ト マ ネーでは 毎日 サー バ ーサイドの 夕会や 、 週 に1 回 の全 体会議 などが あ るのでそこへ 顔 を 出 したり、IaC に対する
P R への 積極的 な レ ビュー、 （ 当たり 前 ですが ） インシデン
ドトの対応などを行いました。

や ることが 多 いため 小 さな成 功体験 を 残 して お き、
組織内 で SRE 疲 れを 感じ た 際 に 振 り 返 りが 出来 る 状態 を
作 って お くと 良 いと 思 います。
SRE は

58

01

SRE成熟度評価に

ついて

02
03

はじめに

的にリソースを割くことができておらず、リスク管理においても後手に回ることが少なくありま

04

メディア事業の横断SRE組織であるSRG（サービスリライアビリティグループ）が、横断的にせんでした。そういった課題を解決するために、私たちはSRE成熟度評価を開発しました。

05

SRE推進するために開発したSRE成熟度評価の取り組みについてご紹介します。

SRE成熟度評価とは

07

物理的に、全プロダクトへEmbeddedするのは難しいので、横断的にSRE推進する方法を私た

08

ちは探していました。また、全体を俯瞰してみる為のデータや指標がない為、組織として効率

部 全体を俯瞰しデータ 化 するために、 能力 成熟度 モ デル 統合 を ベ ースに 作 成したものです。また、サービス 信頼性 の断 層 な ど を 参考 に 必要項目 をリスト 化 し、評価しやすくする為に極力シン プルにしています。

図 1 . 成熟度概要

図 2 . サービス信頼性の断層

06

取り組みの背景

事業

59

01
02
03
04
05

S

RE 成熟度 評価 に よ って 何 が でき るのか ？

RE 成熟度 評価 を 活用 する こ とに よ って、 横断 的にS RE推進
（ Enablement含め ）を行 うこ とが でき ます。また、 自分 た
ち の現在 地 を 知 る こ とが でき るの で、 改善 計 画 が 立 てやす く
なり、 プ ロ ダ クトにとっての理想状態 へ 近づ くこ とが 出来 る様 になります。

各

プ ロ ダ クトにおいての理想状態は 違う の で 、 全 てをメトリク

満 たしている必要はない

S

メトリクスの取得頻度や保存期間が、適切に設定されてい
アラー

2.評価と計画

アラートメッセージに必要な情報が整理されてい送られたアラートログを元に、定期的にアラート設定

各項目のLv.3を参考にしながら、各項目の現在の成熟度レベは見直されていルと理想状態の認識合わせを行います。各項目のLv.3は、下

06
07

S

08

S

RE 成熟度 評価 の 流 れRE 成熟度 評価 は、 大きく分け て 4つ のス テ ッ プで実施 しま

す

準
評価 と計
改善実
振り返り

準備

RE 成熟度 評価 を 実施 するにあたり、S RE 成熟度 評価 のコン
セ プ トや 活用フ ロー、Lv.3 ガイド ラ イ ンの 説明 をします。

・ Lv.3 ガイド ラ イ
各項目のベ スト プ ラク ティ スを考 え る 上で の 観点 を 質問 にしたも各 プ ロ ダ クトの理想状態 = Lv.3

監視にかかっているコストが可視化され、定期的に見直しされている

1.サービスレベル目標
定
SLO導入の目的と意義が、経営層にも認識されてい計
ユーザーに近い位置から計測されており、SLOの悪化とサービス影響が紐づいてい1.

コス記になります（一部抜粋）。

振り返
SLOを振り返る機会が定期的に設定されている

S

3.

インシデント対応

イ ンシ デ ントレベルと 役
ユーザー影響に 伴 った イ ンシ デ ントレベルが定義されており、 イ ンシ デ ントレベル 毎 に 業務時 間 外で の 対応
方針 やメン テナ ンス イ ン 基準 が定義されていオ ンコール、 検知 とトリアー
休暇 や 手当 な ど の オ ンコールに 対 する 補償 が 用 意され
てい

2.監視
要件定
監視の目的が定義され、要件にあった監視ソリューションが選択されている

問 い合わせ よ りも 早く 、 イ ンシ デ ント 発生 を検知 する こ とが でき てい
情報 共有 、 事後対必要に 応じ て、ユーザに 対 して イ ンシ デ ント状 況 の報
告 が行 えている
ユーザの

60

01
02

トイルに該当する運用作業が継続的に、可視化されてい4.ポストモーテム

トイルの改

インシデント発生
ポストモーテムを書くかどうかの基準が定められてい

03
04
05

機能開発と同じ枠組みで、計画的にトイルの改善が行えている

記載内
システム影響だけではなく、ユーザー影響まで記載されてい認識合わせが行えたら、最後に改善計画を立てます。まずは、四半期単位での改善計画を作成
し、そこからアクションアイテムとオーナーを整理していきます。また、監視、インシデント

振り返
ポストモーテム自体の過不足や書くことへの負荷について振り返りできている

対応、ポストモーテムがLv.1の場合は、優先的に改善計画を立てることを推奨しています。

06
07
08

5.トイルの撲滅
トイルの整
トイルに該当する運用作業が定められており、共通認識できている

図3. SRE成熟度評価シート

図4. SRE成熟度

改善計画書

61

01

3.改善実施SRE成熟度評価によって得られたもの

02

他サービスでのナレッジを活用しつつ、各項目の成熟レベル

データとして、事業部全体を俯瞰してみることができる様にを改善していきます。ポストモーテムやインシデント対応になったので、優先的にリソースを割くべきプロダクトや改善

ついては、すぐに活用できるテンプレートも提供していま

項目を決めやすくなりました。また、この取り組みを通しす。

て、把握できていなかった社内のプラクティスを知ることが03
04

出来たのもよかったです。

05
06

終わ りに

07

成熟評価 に よって得 られた も のは 沢山あ りましたが、改善の 余地 はま だ ま だあ る と思って います。 こ の 取 り 組み を よ
り 広く展開 するた め に も 、 スケール可能な体制作 りの 為 の 整
備や各項目 の Lv.3の 内容 を ブラッシュアップ する など し て、
品質向上 し て いければ と考えて います。
SRE

08

図5. ナレッジデータベース

4.振り返り改善を実施したら、四半期または半期毎に振り返りを実施
し、改善計画を見直します。先ずは、四半期毎に振り返りを実施し、運用負荷が高ければ、半期毎にするのが良いです。

62

01

Grafana OnCallの活用

02
03
04
05

はじめに

PagerDutyを利用していた理由

Grafana OnCallを採用した理由

CAMやTappleが所属するIU管轄でオンコール対応で活用す

PagerDutyは、インシデント管理およびアラート通知に特Grafana OnCallは、PagerDutyとるツールについて紹介します。

化したプラットフォームです。

同様 にアラート管理およびオンコールスケジューリン グ を 提供 するプラットフォームです。オンコールのスケジュールとエスカレーションポリ06

複数ある機能のうち下記を主に活用しておりまし
07

背景

08

IU-SREでは、監視およびアラートツールにDatadogとPagerDutyを活用しておりました。

Datadog/Datadog APMでインフラストラクチャ、アプリ
ケーションの監視を行い、PagerDutyを活用してサービス担
当者へオンコール対応に必要な通知をしていました。

この記事では、PagerDutyからGrafana OnCallへ移行した
理由、Grafana OnCallの活用について紹介します。

それぞれのサービスについては、下記からご確認ください

PagerDuty: https://www.pagerduty.com/platform/
devops/on-call-management/

Grafana OnCall:https://grafana.com/products/cloud/oncall/SMS通
スケジュールやエスカレーションポリシーの作
SSO可Slack連携

これらを活用することで、社内のユーザーにアクセスを絞り、システムやアプリケーションからのアラートを受信して
います。

シーに

基づ いて通知を行うことができます。

比べ て 圧倒的 に 安 く活用することができます
PagerDuty ( https://www.pagerduty.com/pr i c i ng/
i nc i dent-response/$49：1 ユーザーあたりの 月
Grafana OnCall ( https://grafana.com/pr i c i ng/$8：1 アクティブ ユーザーあたりの 月額※ その 他 、プランな ど の 詳細 は、 各 リンクをご確認くださ
PagerDutyにい。

また、週毎にシフトスケジュールを組み、適切なチームや個人に通知し、Slack上での情報連携によりシステム障害に対PagerDutyで利用していたSMS通知/スケジュールやエスカして早急な対応を実施することができていました。

レーションポリシーの作

成 //Slack連携が利用でき、スケ
ジュールされた担当者へ、 電話 での通知の機能を主に活用す
るた め乗 り 換え ることにしました。

63

01

Grafana OnCallの活用

Grafana OnCallでOn Call当番を管理する

02

Schedulesで On Callの当番を管理してます。Schedulesの作成には Google.com のアカウ

Grafana OnCallの Schedule の更新は連携したGoogleカレンダーで行います。

03

ントで作成した Googleカレンダー を利用しています。

Escalation Chainを作成します。

04

On Callがトリガーされたときのエスカレーションフローを定義できます。Notify users from05

on-call schedule を設定すると先ほど登録した schedule に通知できます。

06

ここでは担当者へ電話とSlackの通知が届くシンプルな設定にしています。

07
08

イベント名を **Grafanaユーザー名** にしてGoogleカレンダーに予定を登録すると、Escalation Chains

Grafana Schedule側に当番として連携されます。

開発メンバーはカレンダーを確認して、担当を理解します。

また、担当が切り替わった時にSlack通知もしています。

O nCall S ch edu l e

64

01

移行中に遭遇した課題や解決策

02

また、当番用のスケジュールを管理するのにカレンダー連携

03が必須でした。

04

社内のGoogle Workspace内のカレンダーは外部共有が許05

可されておりませんでした。

06

Workspaceの共有設定を変更することはリスクがあると判断したため、google.com でカレンダーを作成し、作成した07

カレンダーに社内のGoogle Workspaceユーザーを編集権08

限で追加する方法で運用することにしました。

Googleカレンダーを活用してよかった点は、使い慣れたイ
ンターフェースのため、開発メンバー含めて担当の変更などの操作が容易でツールへの習熟が短期間ですみました。

おわりに私 たちがPagerDutyからGrafana OnCallへの移行を行った 経緯 、 プロセ ス、 そ して そ の 結果 について解 説
本記事では、しました。

サ ー ビ ス 提供 する 上 で 顧客満足度 の 向上に 不 可 欠 なものとなっており、オンコール対応に必 要 な モニ
タリン グ と アラ ー ト ツールの 選 定も 大 事になっています。

オンコール対応は、

Grafana OnCallの導入により、PagerDutyを利用していたときと同様の機能を保ちつつ、費用を抑えることができました。

また、スケジュール管理が使い慣れたインターフェースであったことから担当の振り分け変更にもスムーズに対応できる環境を作ることができました。

最後に、本記事がオンコール対応のためのツール検討をしている方々にとって参考になることを願っています。

コラム

66

01

新卒1

年目 のSREが 考 えるSREの 魅力 とは

02
03

自分なりのSREを確立して組織に貢献したい04
05― 新卒入社して最初の配属先にCAMでのSRE業務を選んだ
理由を教えてください。

06
07
08

岡：学生時代に参加したWeb企業の長期インターンでインフラ業務に携わり、面白いと思ったことがきっかけでした。そこでKubernetesやDevOpsについて学ぶうちに、その先にあるSRE（Site Reliability Engineering）という仕事がやりたいと思うようになりました。

SREは会社や組織によってそのあり方が全く違う職種で、「SREとは？」と10人に聞いたら10通りの答えが返ってくる
ぐらい、新しい職種と言えます。自分なりのSREを体現して実践し、それによって組織に貢献できるようになれば、すごく幸せで楽しいのではないかと思いました。

サイバーエージェントに内定をもらった後は、株式会社CAM
で内定者バイトとして働きました。とても充実した日々を過ごせたので、入社後の配属先もCAMを希望しました。

庭木：初めて会話をしたのは内定者バイトの受け入れ面談でね 。そこでインターン 経験 やKubernetesの 知識 があることを聞き、「 G C P はある 程度環境構築 ができるのでAWSでもできるようになりたい」という 本 人の希望を聞いて、それを実現できるようなタ スク を 用意 しました。

したよ

公開 している 管 理 画 面 ツ ー ル 「 V ir o n」の ス
テ ージン グ環境 や 本番環境 をAWS Cl o u dFo r m ati o nで 構築したり。 IU管轄 （ ※注 ） のタ ップル でAWS F argate Sp o tを使 った コス ト 削減 や、A m a zo n E B S へ の 移行 に 取 り組んでもらったり。タ ップル が 使 っている 構成管 理 ツ ー ル
CAMがOSSでTerra fo r m に セキュリティチ ェ ックツ ー ル を 導 入してもらったりと、かなり 幅広 くやってもらいました。

※注 ：CAMやタ ップル な ど6 社からなる 子 会社 連合 の 総称 。 ス タート アップに 特化 した組織で、サイバーエージェントの 専 務 執行役員 飯塚勇太 が 管轄
する (2 0 23年6月 現 在)

幅広 いです ね 。その後入社して1 年間 働いた 中 で、自分の 成 長を 感じ た 部 分は ？

―確かに

好 きな 技術 にただ 触 れていた学生のこ ろ と 比べ ると、 コ
ス トの 部 分は 特 に 考 えるようになりました。 例 えば「自分が
岡：

67

01
02

やりたいこと」と「組織としてやるべきこと」の判別や、たときも、頭ごなしに否定するのではなく、いったん受け止「既存サービスのコスト削減」と「新規サービスの迅速なリめた上でアドバイスをしていただけるので、心理的安全性がリース」のどちらに今は注力すべきか、といった優先順位も高いことをすごく感じています。

03

意識するようになったと思います。もちろん私一人で判断す04

るのではなく、上長の庭木とすり合わせながら動いていま

05

す。

06

庭木：彼とは「こういう風に作っていこう」という話であっ07

たり、コスト削減と新規の業務バランス、つまり先ほどの優08

先順位の部分であったり。今後どうなりたいかといった未来の話や、モチベーションが上がる仕事は何かというような話もしています。

岡：今後やりたいことや思い描く将来像について話せるのは本当にありがたいと思っています。何か間違ったことを言っ共通基盤 としての 負荷試験環境 を 構築 しコスト削減に 貢献―CAM や IU 、 さ らには グル ープ 全 体 の SRE についてどう
いった 展望 を描いていますか。

IU発足以降 、 急 に 仲 間が 増え ました。しかし IU の 中 でも CAM と タップル には SRE がいるけ れ ど、 SRE がいない 会
社 もあります。 そ こで 最初 は 設 定 周 りやコスト削減のやり 方など、 CAM や タップル でうまくいっている事 例 を 他 の 子会社に 広 めることで、 IU としての一 体 感を 強 めていくことを 目指
庭木：

しました。

そ うやって IU の 仲 間である CAM と タップル で 協 力しつつ、 お
互 いに 幅 を 広げ ながら事業を 加 速 さ せて、 信頼 性を 向 上していく。ま ず はこの 取 り組 み を 良 い 形 に 持 っていけ れば と思っています。 ゆ く ゆ くは SRG（メディ ア事業部 横 断の SRE チーム） や 他 の SRE チー ム とも 相互 に 連携 を 強化 していきたいですね。

CAM の SRE として CAM の 中 でやるべきこともまだまだあります。 多 くのサービスを 抱え る CAM特有 の事 情 として、コスト削減が 大 きなイン パク トになりやすい 面 があります。 1 つ 1 つのコストは 小さ くとも、 掛 け 算 すると 大 きなコス
トになります。 例えば 岡が先 日実現 したコスト削減の 施策 もかなり 効果 は 大 きかったです ね 。

もちろん

ざ います。サービスを 横 断して 使用 できる
独自 の 負荷試験環境 を 設計・構築 したのですが、こ れ は 周囲の人からの 反響 も 大 きかったと思います。 詳細 は CAM の ブロ
グ に 記 事を 載 せています。

岡：ありがとうごれ までは CAM が 抱え る 多数 のサービスに お いて そ の 都度負荷試験環境 を 構築 して お り、 大 きなコストがかかっていました。 そ こで 負荷試験ツ ー ルk6 を Kubernetes 上で動かせる
こ

68

01
02

k6 Operatorを活用し、全てのサービスに使える負荷試験環境を構築したという取り組みです。コスト削減に加え、ナレッジを蓄積できるメリットも大きいと思っています。

03
04
05

―SREを目指す学生に向けてアドバイスがあればお願いします。

06

岡：SREはフロントエンドからインフラまで幅広い知識を求07

められます。そこが大変なところでもあり、魅力でもあると08思っていて、その気になれば10年単位で深掘りしていける職種だと思います。

最初のきっかけとして例えば、HTMLのシンプルなページでもいいので、自分でWebサイトを作り、自分で用意したサーバーで公開し、それを運用してみるのが良いと思っています。本当に基礎的な部分ですが、実際にやってみると全てが完璧にうまくいくことはほぼないと思います。電源が落ちたり、バグやエラーが発生したり、ファイルが破損したり。

問題を解決するために原因を調べたり、あれこれ試行錯誤することが得がたい経験になるので、是非取り組んでみてほしいですね。理想を言えば物理サーバーですね。それが難しけ
ればコンテナではなくVMで。その方が身に付くものは大きいと思います。

庭木 ： 今 はRa s pberr y Pi な ど もありますし、 昔よ りは自 前
で物理サーバーを構築する ハ ードルは 下 がっているかもしれ
ま せ んね 。

69

01

SREに

求 められるエンジ ニ アとしての 素養

02
03
04
05

ベ ストプラクティスだけでは解決できない課題に向き合う―今回なぜテクノロジーマップを作ろうと思ったのですか？

06
07
08

T
術 長期 価値特徴 持
時間 %未満J nブ グ

手
ビ
指

繰 返さ
成長 比例

自
増加
費 さ
参

可能 戦
時間 勤務
d

（※注）：トイル（ oil）とは「 作業、 りれる、 動化が、的、的ながない、サー スのにしてする、といったを つ作業」のこと。GoogleのSREはトイルに や れるをの 50にすることを目 しているという（ 考：Google Clouapa
ロ ）ナレ ッジやプラクティスが 蓄積 しやすいところです。その強みを活かし、 蓄積さ れた知 見 を 展開 していくことで 各 プロ ダ クトをサ ポ ートしたり、AWSのWell Arc h itecte d F ra m e w or k （以下、 ウ ェルアー キ ）にア レ ン
ジを 加 えた 独自 の ウ ェルアー キ を作 成 し、 ワ ークロー ド 改 善に役 立 ててもらうといった活動を行いました。

横断組織の強みは柘植：制作の目的は2つあります。「社内のSREチームの連携強化」と、「サイバーエージェントのSREを社内外に知ってもらうこと」です。

Service Reliability Group（以下、SRG）は、サイバーエージェントのメディア事業部において横断的にSREに取り組んでいる組織です。前身はメディア事業部のインフラ組織
でした。AWSやGCPへのシフトが進むにつれ我々の役割も変わっていき、2015年に組織名をSRGに変更し本格的にSREに取り組んでいくことになりました。

SRG発足当初はGoogleのプラクティスに従いトイルの撲滅（※注） 運動などを継続的に行なっていたものの、抱える事業数や組織形態が異なる我々にとってはベ ストプラクティスではないことを実感しました。そこで改めて我々に適したSREを模索していった結果、横断組織の強みを活かせるような
SREが良いのではないかと考えるようになりました。

これらの活動を通じ 、メディア事業部内のプロ ダ クトに 関してはSREとしてある

程度貢献 できたと思っています。 次 なる

一歩 として、今 後 はSRG以外のSREチームとの連携を強化することで、より 幅広 く 信頼性 向 上 に 繋 がる 貢献 をしていきた
いと考えました。これがテクノロジーマップを作った1つ目の目的です。

藤井 ： 私 は201 9 年にCyber Z に 入 社し、バックエン ド を 経 てSREチームに異動しました。 着任時 は「 O PE N REC . tv」のSREという 位置付 けでしたが、2021年の組織改 編 で 他 のプ
ロ ダ クトも 見 る横断的な 立ち位置 に変わりました。

理想 形ではあるものの、「我々の組織では 現 実的ではない」という部 分 も当 然 あります。その 際に「 相談 する 相手 がいない」「 参 考にできるような ナレ ッジ
を 得 られない」というのは 大 きな課題です。これは 多 かれ 少
なかれどこのSRE組織でも抱えている 悩 みだと思います。

GoogleのSREは1つのず は 自分 た ち の 仕 事について発 信 していこうという取り組みを2022年から 始 めました。そうして ちょ うど動き 始 めたところに柘植 さ んから 声 を掛 けられたので、 是非 にということで今回のテクノロジー
マップにも 協力さ せてもらいました。
横の連携を作っていくためにも、ま

70

01
02

柘植：実のところ、これまでにも弊社でSREチームの横の連携を強めるような取り組みがなかったわけではないと思います。ただナレッジやプラクティスの共有を考えたとき、誰し03

も「テイク」はしたいけれど「ギブ」のモチベーションを持04

つことは難しいですよね。

05

必要もありません。

SRGの場合はもともと横断組織ゆえに「ギブ」にモチベー

06

ションを持っているメンバーが多く、またそこを評価される

07

枠組みもありました。しかし通常の開発現場にそれを求める

08

材 の 採用 を考えたとき、「 サ イバー エ ージ ェ ン トのSRE」をブラン ディン グ していく必要もあります。しかし弊社には多くのSREチームがあり「 サ イバー エ ージ ェ ン ト のSRE」を ひ とまとめで 語 ることは ほぼ不可能 ですし、そもそもそれ ぞ れの 事 業に 適 したSREがあるので 全 てが 同じ である

またSRE人のは無理があります。

サ イバー エ ージ ェ ン ト のSREはこう」と 言 い 切 ることはできなくとも、「 各 組織がどういったSREを実 践 しているのか」「どういうチームがあるのか」を発 信 することはで
しかし「

きます。

とはいえ自分たちが見ている範囲だけにスコープを狭めてしまうと、得られる情報の幅が狭まり、やがては今後チャレンジをしていくときの幅も狭めてしまうことになりかねません。

ず は 知 ってもらい、 知 ってもらうことで「 一緒 に 働 きたい」「 話 を 聞 いてみたい」といった 繋 がりができたら 嬉 しい。これがテク ノ ロジー マ ップを 作 った 2 つ 目 の 目的 です。

まSREに求められる資質とは―どういう人がSREに向いていると思いますか？

藤井：SREの業務は「人」が大きく関わってきます。SREを

目 を向けられる 視野 を持つ人が向いていると思います。 言
葉 にするのは 簡単 ですが、なかなか 一筋縄 では 行 かないのが現実です。組織の 数 だけ 正解 があるところもSREが難しいといわれる要 因 の 1 つだと思います。

も材 が 欲 しいという 企 業は多いものの、「 採 れない」「 育 成 方法 がわからない」という 悩 みを多くの 企 業が 抱えています。実は 採用 する 側 も「求めているSRE エ ンジ ニア
像 」をうまくイメージできていないのが実情かもしれませ柘植：SRE人ん。

私個 人の考えとしては、「 サ ー ビ スに 貢献 したい」「 サ ー ビ
スを 良 くしたい」という 目線 が大 事 だと思っています。 単 に技術をやりたいという 形 だとギャップが 生 まれやすい。 事 業
責任者 に 対 して 提案 をする場 面 もあるので、 事 業に 目線 を合わせて 貢献 する マ イン ド が求められます。

ダ ク トへ の 貢献 に 主体性 を持って アクションをすること。 目線 を 事 業に合わせた 上 で ミ ッションを 設定 すること。
その技術を 選 んだ理 由 を自分の 言葉 で 話 せること。これまで
SRE業務に 従事 してきて、 特 に重要だと 感じ たのはこういっプロた資質です。

組織に根付かせるためには文化の醸成が重要な要素になるた
め、チームや人を考慮しつつ動いていく必要があるからです。そのため技術だけでなく、組織の文化や開発プロセスに（ S ite R eliability E ngineering） は 日本語 に 訳 すと「 サ イ ト信頼性エ ンジ ニアリ ン グ 」です。 信頼性 という ワ ー

SRE

71

01
02
03
04
05
06
07
08

ド が一 番大切 で、その 信頼性 を得るた め には人や組織から 信
頼 されることも 必要 だと思っています。

個 人 的 にはSREという 職種 は「SREか バ ックエン ドか」という 分 かれ 道 の 先 にあるとは 考 えていません。 バ ック
エン ド の 先 にSRE 的 な 考 えもあると思っています。これはバ ックエン ド からSREになった 自分自身 の経験からくる 考 え藤井：方かもしれません。

イ ン フ ラからサービスに関わりたい人が 集 まってSREとして動くという 流 れがあり、 バ ックエン ド にもSRE 的 な 考 え方を持った人がいる。SRE 的 な思 考 をSREエンジニアだけに 留 まらず、 バ ックエン ド や イ ン フ ラにも 広め ていければ、 結 果としていい 状態 を 作 れるのではないかと思います。その 意味 でも実 際 に手を動かしてサービスに 貢献 するという 部分 は 私 も非常 に 重要 なとこ ろ だと思っています。

B
ata b a se Re lia b ilit y
E ngin eer）のように、 特定 の 技術領域 に 特化 した形になっていく 可能性 はあります ね 。藤井くんが 今 言ったように、
バ ックエン ド や イ ン フ ラ 側 の人た ち がある程度SREの ベ ース
部分 を 担 ってくれるようになれば、 必然的 にSREの役割も 変化 していくことになるので。
柘植：いずれはSREもD RE（D

藤井：CyberZのSREチームに関して言うと、SREの人数は

最近はSREをやりたいという学生も増えてきましたが、学生増えないにもかかわらずSREが見るプロダクト数は増えていである程度の規模のサービスの運用経験がある人はほとんどるというのが現在抱えている課題です。その解決策になり得いません。SRE志望だけど運用は未経験、でも開発経験はある形として期待しているのが、Embedded SREという関わるというようなスキルセットの場合、Embedded SREは良り方です。

い選択肢になり得ると思います。柘植さんもおっしゃっているように、「サービスを良くしたい」という目線をSREが他

Embedded SREとは、簡単に言えば「開発チームに組み込のエンジニアと同じように持つことで、開発と運用のコラボ

まれた（Embedded）」SREです。開発チームに入ってレーション、いわゆるDevOpsが実現でき、よりよい開発組

チームと一緒に手を動かしつつ、SREとしての役割を果たし

織、ひいてはよりよいサービスの提供に繋がると思います。

ていくという形です。

編集

09

Member編集

デザイン

柘植 翔太（メディア統括本部）

佐藤 恒平（技術人事本部）

植田 祥子（技術広報）

藤井 貴大（株式会社CyberZ）

関本 育久（技術広報）

柴 尚子 (Design Factory)

庭木 勝也（株式会社CAM）

北村 瑠美（株式会社CyberZ）

山田 彩加 (Design Factory)

岩立 稜佑（株式会社CA GameFi）

田口 佳澄（株式会社CAM）

横山 恵 (Design Factory)

岡 麦（株式会社CAM）

武田 佳那子（SGE統括本部）

岩永 勇祐（株式会社AbemaTV）

髙橋 佳那（AI事業本部）

伊藤 崇洋（株式会社アプリボット）

田爪 裕子（AI事業本部）

吉岡 賢（株式会社サムザップ）

田口 雅教（AI事業本部）

SRE Technology Map 2023

公開日 2023年 6 月 1 日

公開元 株式会社サイバーエージェント〒150-0042 東京都渋谷区宇田川町40-1 Abema Towers© 2023 CyberAgent, Inc