【学習メモ】SREについて

はじめに

エンジニアとしてお仕事をしていると耳にする機会も多い言葉”SRE”　
SREとは　Site Reliability Engineering：サイト信頼性エンジニアリングのことです。

……つまりなんだ？というわけで今回はSREについてお勉強したのでまとめてみました。

使用した書籍

• サイトリアイラビリティワークブック ――SREの実践方法
• SRE サイトリライアビリティエンジニアリング ――Googleの信頼性を支えるエンジニアリングチーム

SREを学ぶ理由

現状の運用には一般的な答えがない状態です。
ベストプラクティスだ！と思っていても状況や環境に依存している場合が多いです。
運用チーム自体の運用も宙に浮いてしまってしまっているようです。
その状態ではソフトウェアシステムをスケーラブルで信頼性高く効率的に構築・運用することは難しいです。

SREという考えを取り入れて実施して行くことで上記のような問題を解決していきたいし現状を超えていきたいよね！という感じです。

SREとは

SRE

グーグルのエンジニアリング担当バイスプレジデントのBen Treynor Slossが作った言葉であり、仕事のロール・定義です。

特に「標準化」「自動化」に目を向けることでサイトの信頼性を上げていこうよ！という考え方となります。

SREの背景

SREにおいて主要な7つの原理を説明していきます。

①運用はソフトウェアの問題

運用をうまく行えるかどうかはソフトウェアの問題です。
ソフトウェアの問題解決にはソフトウェアエンジニアリングでアプローチします。

②サービスレベル目標（SLO）にて管理するべし

SLOとは、サービスレベル指標（SLI）で達成させたい目標のことです。
SLIとは、サービスの品質を測るものです。

例を挙げます。

SLI：サーバの稼働率
SLO：サーバの稼働率が99.9%以上

サーバの稼働率（SLI）が99.9%以上（SLOで定めた目標値）であればSLOを満たしているといえます。
もしサーバの稼働率が80％だった場合はSLO違反となります。
この際は誰かを責めるのではなく、全員でSLO達成に向けて取り組んでいきます。

ちなみに、サービス品質保証 / サービスレベル合意書（SLA）はサービスを提供する事業者がサービスの契約者とかわすSLOについての合意のことを言います。

③トイルはなるべく減らしたい

SREにおけるトイルとは、手作業で繰り返し行われる運用タスクを指しています。

このようなタスクはマシンにて自動化させることが可能ですので、「マシンにお願いして問題ない作業だったらどんどん自動化させちゃいたい」というのがSREの信念になります。

組織の中での役割にこだわらず、同じツールを使用することは重要と考えます。

状況によって振る舞いが異なると、サービス管理として△であると感じるのは自然な感覚かと思います。

また、1つに絞ることでツール改善の労力も削減できるかと思います。

④自動化できるトイル、出来ないトイル

トイルに費やすことができる時間に50%という絶対的な制限を設けています。
SREでは、自動化できる事は自動化し、自動化出来ないことは残します。
自動化出来ないトイルに支配されることはありません。

⑤失敗コストdownによって開発速度up

SREの関与による主な利点の1つに「プロダクト開発のアウトプットの向上」があります。
※プロダクト開発：仕様書に沿って開発していくシステム開発とは異なるもので、目的達成のため様々な手段を用いて開発していくことをプロダクト開発といいます。

「プロダクト開発のアウトプットの向上」がなぜできるのかというと、失敗のコストを削減することができるからです。

失敗（=問題発見）はプロジェクトの後ろになればなるほど対応が大変です。
つまり、失敗コストが高くつきます。

上記で上げてきたトイルの削減や障害へのリカバリーをはやくすることで、エンジニアがプロダクト開発にさける時間が増えます。
さける時間が増えると、失敗の発見も早くすることができるので失敗コストを避けることができます。
失敗コストが下がるとプロダクト開発の速度も向上しますので、会社全体としての利益も向上すると考えられます。

⑥アプリ開発とプロダクションの境界をぼかす

アプリケーション開発者とプロダクション（プログラマーと運用者とも言う）が完全に分離していると非生産的です。
生産性もそうですが、責任の分離がされたり、「運用ってコストセンターだよね～…」といった心無い言葉が出てきてしまって組織内での評価が偏ってしまう危険があります。

※コストセンター：コストはかかり利益は生まないものを言います。

プロダクト開発チームの全員が、該当のシステムの全体像を把握していると効率が良くなります。
反対に、どこか1つのコンポーネントをどこかが独占してしまう事は避けたいです。

想定されるコンポーネントは以下です。

• フロントエンド
• バックエンド
• ライブラリ
• ストレージ
• カーネル
• 物理マシン

境界をぼかすことで可能となる範囲が広がります。
例えばSREチームがJavascriptを、プロダクト開発者がカーネルの修正を行うことで知識と権限が広がり成せることが増えると考えられます。

⑦みんなでおそろいのツールを仲良く使いましょう

DevOpsにもつながってくる話かと思います。

組織の中での役割にこだわらず、同じツールを使用することは重要と考えます。
状況によって振る舞いが異なると、サービス管理として△であると感じるのは自然な感覚かと思います。

また、1つに絞ることでツール改善の労力も削減できるかと思います。

感想

お仕事の進め方として、かなり定義づけられていると感じました。
SREの考えのもとチームが動くことで、かなり効率が上げられるのではと考えます。

今回使用した本では、ケーススタディなども細かく載っておりかなり実践的です。
サイトリアイラビリティワークブック ――SREの実践方法

実際我々のチームでは、トイルの撲滅とポストモーテムの活用に挑戦しています。
ぜひ、多くの方にSREの考え方に触れていただきたいなと思いました。