https://sbtechnight.connpass.com/event/230085/

1. 私のSRE探求
My Seeking SRE
ソフトバンク株式会社テクノロジーユニット
ソリューション運用本部プラットフォーム運用統括部
アプリケーション運用部プラットフォーム運用課
北崎 恵凡

2. 本日みなさんにお伝えしたいこと
あらゆることから学ぶ姿勢

3. 最初の見誤り
ベストプラクティスを適用する

4. SREとは
引用元 https://www.oreilly.co.jp/catalog/

5. 景色合わせ（言葉合わせ）
● SRE
● SLA、SLO、エラーバジェット
● トイル
● オンコール
● ポストモーテム
● カナリア
● メトリック、オブザーバビリティ
● コンテキスト vs. コントロール
● イミュータブル (インフラ)
● ソフトウェアエンジニア
● ‥

6. 心理的安全性

7. ITIL、ISO（QMS、ITSMS、ISMS）、PMI（PMBOK）‥

8. 運用保守アプローチ
伝統的運用保守
（プロセス型）
DevOps
（DevSecOps）
アジャイルの価値観
SRE
（信頼性エンジニアリング）
しっかりと計画され、
厳密に管理された
保守運用業務
開発と保守運用業務が
一体的に柔軟に状況の変
化へ対応
保守運用業務をエンジニアリング業
務として扱い、ヒューマンエラーを最
小に、システムの信頼性を継続的に
維持・改善を行う
システム設計アプローチ
堅ろうさを前提
とした設計
故障を前提
とした設計
クラウドの価値観
正常稼働が通常状態
故障・不具合は例外
故障・不具合も通常状態
発生を想定して設計
回復性設計
障害の発生から正常稼働状態
への復旧までを想定した設計
NoOps

9. NoOps
前回（昨年）のイベント

10. 付録 B：プロダクションサービスのためのベストプラクティス
過去、Googleが実際に経験した失敗事例が記載されている。
・2005年 ファイルのパーミッションに問題があり、空の内容の DNSエントリを受け付けて、 Google全サービスで６分
間NXDOMAINとなった。
→新しい設定に対する健全性チェックをいくつも行うようになった。
・2009年 設定ファイルの内容が正しくないデータ（疑わしい URLのリストがスラッシュ（ /）で置き換えられた）により、
Web全体がマルウェアが含まれているとマーキングした。
→ファイルサイズが劇的に変化していないか、マルウェアが含まれていないサイトがマッチしないこと（ False
Positive）を確認するようになった。
・段階的なロールアウトを行う
・SLOの定義はユーザ観点で行う
・モニタリングは３種類（ページ：保全オンコール、チケット：翌営業日保全クローズ、ロギング：？？？）
・キャパシティプラニング（最低、 N+2）

11. 付録 B：プロダクションサービスのためのベストプラクティス
（続き）
・過負荷と障害（動的タイムアウト、キューイング、フィルタリング、ドロップなど。リトライを抑える →カスケード障害を回
避する）
・SREチーム（運用の作業に５０％以上を費やさない）、プロダクションミーティング（ SREと開発で定期的にミーティン
グを行う）
・オンコール人員は最低でも８人。１２時間ごとのシフト、地理的距離を保つ（夜間にオンコールを受けない、各サイト
最低でも６人）、１回のオンコールシフトで扱うページ数は３つまで。

12. 付録 D：ポストモーテムの例
過去、Googleが実際に行った振り返り資料
AIリスト：緩和策、回避策、プロセス見直し、
その他（エラーバジェットの枯渇により xx月xx日まで作業凍結）
教訓：うまくいったこと、うまくいかなかったこと、幸運だったこと（ニアミスだったこと）
タイムライン：2〜3分毎に詳細が記載されている（ 2015年10月21日のとあるインシデント）

13. 引用元 https://landing.google.com/sre/workbook/chapters/postmortem-analysis/
(表のデータをもとに円グラフを作成 )
Google (2010-2017)
障害原因分析（きっかけ） 根本原因分析
4

14. 引用元 https://www.google.com/appsstatus/dashboard/
(障害時に取得したスクリーンショット )

15. 報告書からの抜粋
根本原因
データ保管ポリシー変更に伴う config を push 時の gmail.com の SMTP サービスに影響する箇所に不備
再発防止策
● Update the existing configuration difference tests to detect unexpected changes to the SMTP service
configuration before applying the change.
→SMTPサービスへ意図しない変更を検出できるための仕組みを設定差分試験に追加
● Improve internal service logging to allow more accurate and faster diagnosis of similar types of errors.
→今回のようなエラーが検出できるように内部ログ出力を改善
● Implement additional restrictions on configuration changes that may affect production resources globally.
→グローバルサービスに影響しそうな設定変更の制限を追加
● Improve static analysis tooling for configuration differences to more accurately project differences in
production behavior.
→商用環境への動作差分をより的確に可視化できるように差分検出ツールを改善
引用元 https://static.googleusercontent.com/media/www.google.com/en//appsstatus/ir/4et50yp2ckm8otv.pdf

16. Qiita Advent Calendar
・本番環境でやらかしちゃった人 Advent Calendar 2019
https://qiita.com/advent-calendar/2019/yarakashi-production
・本番環境でやらかしちゃった人 Advent Calendar 2020
https://qiita.com/advent-calendar/2020/yarakashi-production
・本番環境でやらかしちゃった人 Advent Calendar 2021
https://qiita.com/advent-calendar/2021/yarakashi-production

17. プロアクティブ リアクティブ
・障害復旧対応
- アラート対応
- オンコール対応
・トイル業務
- 繰り返しの作業
・自動化
・高信頼化
・付加価値追加
- 影響可視化
- 判断迅速化
5
５０％ ５０％
業務比率（Googleのケース）

18. 最初の気づき
ベストプラクティス
↓
原理と哲学（信頼性のため）

19. 小さなチームを結成

20. 勉強会を開催

21. 目的を持って工数を生み出す

22. 本質思考トレーニング（SDM13）
正解のない問題に直面したとき、答えを出す方法のヒント
引用元 http://www.sdm.keio.ac.jp/2021/07/07-092234.html
引用元 http://www.sdm.keio.ac.jp/2014/03/12-090524.html

23. 本日みなさんにお伝えしたかったこと
あらゆることから
学び続ける姿勢

24. Udemy 中村 浩一郎 様
スタンフォードGSBの
現役コースファシリテーターが魅せられた
世界一流の学び方
ソフトバンクグループ入社後、上海勤務を経て
米国に赴任
2021年よりUdemyに参画
スタンフォード大学経営大学院エグゼクティブ
プログラム(LEAD)修了
同プログラム初の日本人コースファシリテー
ター及びコーチを務める