最近よく聞くSRE、研修を受ける事ができましたので簡単に纏めてみました。

SREの定義

「ユーザーの満足度に着目し、信頼性を失わないためのサービスの運用スタイル」

今のところしっくり来ている私なりの説明。

Site Reliability Engineering(SRE)

Googleの造語。
「ソフトウェアエンジニアに運用方法を任せることで実現するもの」とされている。
開発と運用チームに分かれる従来のDevOpsの考え方とは完全に違う。

役割と責任

ユーザーの満足度にフォーカスし、幸福度を最大化するための活動を行うこと。
信頼性を向上させるために具体策を決めていく

ライフサイクル

ライフサイクルの摩擦を減らすことで製品のライフサイクルを早く回すことができます。
本来、ビジネスや開発と運用には壁があります。
開発と運用の壁は既にDevOpsが解決していますが、SREはビジネスも含めて解決することができます。

原則

最も重要な機能は信頼性

100%の可用性が期待されることが多いですが、世の中に100%という可用性はありえません。
またSREでは信頼性とはユーザーの期待に答えることを意味しています。

信頼性はユーザーが決める

サーバのCPU値がしきい値を超えてたとしてもユーザーに影響がなければ問題ありません。
逆にユーザーに影響があるのにメトリクスに問題がなければ、そのメトリクスは意味がないことになります。
信頼性とは常にユーザーが決めるのです。

100%の信頼性はありえない

高い信頼性を得るには、アーキテクチャが重要になります。また人間が介すシステムは自動化しなければ99%の信頼性などありえないでしょう。さらに99.999%などという数字は、想像以上のコストが生じることがあります。

実績

10億人以上に利用されているサービスを運用しているGoogleでは、約3000人のSREエンジニアが支えています。
従来から人員不足を懸念していたGoogleは、このSREという考え方を作ったとのことでした。

やること

では具体的にどういうことをしなければいけないのか。

SLOとSLIの構築

サービスを運用していく上で必要となる新たな指標になります。
これらはユーザー目線で考え、サービスを開発運用しているエンジニアやビジネスサイド(経営層)や営業とも合意を得る必要があるでしょう。
例)ここではToDoリストのwebサービスを例に取り上げて行きます。

UJ（ユーザージャーニー）

ユーザーが目的を達成するための操作や体験になります。
例えば、「ToDoリストを呼び出す」、「ToDoリストを登録する」になります。

SLI

サービスが機能していることを示す指標を策定します。
これはユーザーの満足度を可視化する1つの指標になります。
SLIは全部で8つのタイプに分かれます。

• リクエスト/レスポンス
  • 可用性
  • レイテンシ
  • 品質
• データ処理
  • 鮮度
  • ガバレッジ
  • 正確性
  • スループット
• ストレージ
  • スループット
  • レイテンシ

例えば、UJからToDoリストを呼び出すgetToDoListsの可用性を指標にします。
その場合、LBからhttpステータスの200、300、400番台を返す割合を算出することになります。
それがSLIとなります。

SLO

ユーザーの満足する値を目標値として設定します。
例えばSLIから過去28日間で正常なレスポンスを返す割合を99%以上とします。
この99%以上だとユーザーが満足しているととらえることができ、逆に99%未満のだとユーザーが満足していないと捉えることができます。
ちなみに99%未満の場合は、可用性を向上させるために具体的な対策を取る必要があります。

ポストモーテム

SLOを違反した場合、なぜそうなったのか記録を残す必要があります。されがポストモーテムです。

学びの機会を得ること

ポストモーテムは原因や解決策、タイムラインなどを記載します。目的は学びの機会を得ることです。
ポストモーテムを閲覧することで、他のサービスでも考えられる障害を事前に防ぐことにも繋がります。

批判しないこと

ポストモーテムでは批判しないことが重要になります。人間は責任を誰かに押し付けることで、自分の身の安全を確保しようとします。
しかし批判からは何も生まれません。原因を真摯に受け止め、解決していきましょう。

レビュー

公開する前に上級や経験豊富なエンジニアにレビューしましょう。
レビューすることで正確性が増し、非の打ち所がないものになります。

トイルの撲滅

トイルとは手作業で行うこと、反復して行うこと、自動化可能な作業のことを指します。
ただ、多くのトイルは撲滅できないのも事実です。
そのため、トイルを特定し定義し自動化することに努力します。
トイルが少ないほどプロジェクト作業に没頭できるからです。
Googleでプロジェクトとトイルを比較した場合、トイルは50%以上にならないようにすることが理想とのことです。
トイルが及ぼす影響はプロジェクトの停滞や士気の低下、そして進捗の遅れに繋がるとされています。

オンコールシフト

電話呼び出しによる割り込みは、集中力が妨げられる原因の1つです。
これはトイルの1つでもあるとされており、これを解決する方法にオンコールシフトを組むことが上げられています。
シフトを組むことで、集中力を妨げられる原因をローテーションすることができ、ゾーンに入りやすくなります。

ちょっといい？も撲滅

よくある「ちょっといいですか？」も割り込みとなります。
問い合わせページへ促すことで、チケット発行して対応できるフローを作るべきです。
ちなみに問い合わせ者も情報整理ができるよう、できるだけ細かく記入してもらえるページにしましょう。
もしくは1時間/週はオフィスアワーを設けるのも良い手です。
ゆるい質問などなんでもOKとする時間を設けることで、わざわざ問い合わせるレベルではない質問も拾うことができるのです。
ちなみにトイルはすべて計測することが推奨されています。
作業に費やされた時間などを分析することでプロジェクト遅延の原因も特定することができます。
そのため、問い合わせページからのチケット発行は有益な手段の1つなのです。

インシデント

いつか必ず壊れるという真実があります。その中で最も重要なルールは慌てないことです。

インシデントコマンドシステム

SREではICSを適用することで、インシデント対応することになっています。
インシデント対応のほとんどはコミュニケーションと作業管掌区分の問題によるものであるとされており、ICSは最も優れたシステムだということが既に証明されています。
ICSは役割が決められています。

• インシデントコマンダー（IC）
• オペレーションリード（OR）
• コミュニケーションリード（CR）
• プランニングリード（PR）

ICSは拡張と収縮が柔軟にできるよう設計されているため、様々な規模のインシデントに適しているとされています。
決定権はICに委ねられ、トップダウンで行われることが大切とされています。
インシデントは発生したら包み隠さず申告しましょう。

まとめ

SREですることを簡単に纏めました。

• 運用するサービスのSLIとSLOを策定する。
• SLOを違反したインシデントの対応を行う。
• インシデント対応をしたらポストモーテムを作成する。
• トイルを撲滅する。

SREですることを簡単に纏めましたが、まだ点の状態だと思います。
実は奥が深いSRE。
深堀りした記事を作成していきたいと思います。
なんてったってSRE本は2冊合計2000ページありますから。
ブログ1ページに纏められるわけがない。