みなさんSREしてますか？

サービスなどの品質を維持していくために切っても切り離せないSREですが、
日本でもSREという言葉が定着しつつあるかと思います。

このSREについて書いていきたいと思います。

SRE NextのCFP忘れてたのでその代わりに・・

SREってインフラですよね？

非常によくあるケース、というか多分ほとんどがこうなっていると思います。
もちろん会社としてインフラのことを指しても問題はありませんが、
SREとはどういうものなのか、正しく認識して今一度現状を振り返ることで
さらに良い活動に繋がることが多いと思います。

なんのこっちゃ、という方も多いかもしれません。
SREはエラーバジェットなどの話が必ず出てきますので、
モニタリングや監視などが必ずセットにはなっていきます。

ですが、この部分が強調されているのかどうしてもインフラエンジニアでしょ、
というのが定着している場面が多いような気がしています。
もちろんこうしたツールがなければ、実践は難しいのは明らかです。

本来やるべき活動はそれではありません。
ではDevOpsなのでしょうか？

DevOpsは、開発と運用が連携する・もしくはその境界線をなくしていく開発手法のひとつです。
SREの活動には含まれますが、
CI/CDなどを作りこれを実践できるための環境を作ることや、その手法が目的ではありません。

SREが一番重要視しなくてはいけないものは、
サービスの利用者がハッピーになるための、あらゆる秩序や品質維持に関する活動ではないでしょうか？

sre.google

ではDevOpsやモニタリングはどういう関わりがあるのでしょうか？ちょっと整理してみましょう。

品質が高いとは？

まず目指すゴールはサービスの利用者がハッピーになること、満足できるサービス提供すること。
抽象度が少し高いですが「品質が高い」、ということになります。

ではこの「品質が高い」とはどういうことを指すのでしょうか？
みなさんは自社における品質の高さはどういうものなのか理解していますか？

たしかにアプリケーションのパフォーマンス（レスポンスなど）が良いことかもしれません。

果たして本当にそれだけでしょうか？
SREというキーワードで見るとほとんどこの観点のものが多いように思います。

速さ以外に本当に重要なものはありませんか？

サービスの形態や事業ドメインによってはまちまちです。
ニュース配信やコンテンツ提供を行っている会社では、パフォーマンスが良いことはもちろんですが、
「読みたいと思った記事が確実に読めること」などではないでしょうか？

たとえば高速なレスポンスを返すシステムがあり、負荷にも強いシステムができている、
たまに意図しないコンテンツが返ることがあり、
利用者が読みたいコンテンツを返却できずに違うものが返却される状態になると
利用者が満足できる状態になるのでしょうか？

高速にレスポンスを返すのも当然必要ですが、
重要視するのは速さだけではなく読みたいものを確実に届けること、になるのではないでしょうか？
読みたいものが確実に読める、届けられるようになりユーザーの満足度が上がり、
サービスへの信頼度も上がり、購読会員などになっていく重要なポイントになるはずです。
レスポンスが速ければ会員登録や、売り上げが上がるのでしょうか？
（広告配信などはそれが一番重要ですね）

購入などを提供するサービスでは確実にユーザー購入できること、が重要になるかもしれません。
配送系のサービスであれば、確実に住所が指定できて配送会社に連携ができること、かもしれません。
（リアルな配達は道路事情などもあるので満足度を高くするにはアプリケーションだけでは不可能ですが）

確かにレスポンスなどの監視だけではこの辺りをすべて満たすのは難しいかも、というのがわかってくると思います。

では再び考えてみましょう。

品質が低くなってしまう理由は？

ここでようやくDevOpsなどの話が少し出てきます。

上記のようなコンテンツが正しく返却できずに、読みたいものが届けられなかった原因を探ってみましょう。
もしかすると開発チームが十分にテストできていなかった。
キャッシュサーバが故障していた。
色々原因があると思いますが、DevOpsっぽく前者のテストができていなかった、に注目してみましょう。

たとえば
「開発がすごい速さで開発している、モダンで自動化されたフローでリリースは毎日、
運用チームは保守やカスタマーサポートと連携して色々な不具合を調査したり改修をしている。」
こんな感じになっているとしましょう（こういった体制のところも多いはず）

ではテストができなかった原因を探ってみましょう。

一方が開発速度が早く毎日自動でリリースしていて、ユニットテストも書いている、結合テストもできている
テストがすべて通ったので自動でリリースされる、
が実はDBのレコードにミスがあり
気が付かずに自動でどんどんリリースされてしまった。

運用チームがリリース内容などをチェックするよりも早くリリースされていくため、
当然気がつくのはユーザーからのクレームだったり、もしくは他の部署の人たちから運用チームに連絡が来た。
という流れだとしましょう。

当然これはテストが十分にできていなかった、ということになります。
これはDevOpsとして考えるとどうでしょうか？

テストコードが足りなかったのかもしれませんし、
自動化することだけを目的にしてしまったため起きてしまった事故なのかもしれませんし、
もしくは開発と運用が仲が悪くてリリース時に連携したくなかったのかもしれません。
（ほとんどArt of SLOsの例そのまんまですねw）

こうしたことがきっかけで結果としてユーザーの満足度が下がっていくことに繋がるわけです。
この場合解決しないといけないものは、
リリース時の体制や自動化によるリリースの頻度、
普段のコミュニケーションの改善かもしれません。
もしくはとにかくリリースしろ！というような方針が招いた結果かもしれません。

SREは
こうした事態を招かないようにユーザーの満足度低下に繋がる原因を突き止め、
守るべきものを文章化して会社全体に共有しながら文化を作り、
秩序を維持していくための活動なのです。

これはインフラエンジニアだけがするものなのでしょうか？

これはポジションや領域関係なくできる活動のはずです。
もちろんインフラエンジニアが関わることが多い監視やモニタリングはありますが、
これらはあくまで手段であり、目的ではありません。
開発チームと運用チームがうまく連携し、品質を維持するために活動しなければいけません。

SLI/SLOはただ設定するだけでなく、
現在の開発サイクルや運用、サービスの利用状況や事業ドメインなどを考慮して設定する必要があります。
ユーザーの満足度を上げるためにどうすれば良いかを第一に考え、
それを実現するための活動をすることがSREの本質です。

つまり逆算して考えると、
活動が十分にできるように社内における信頼関係を築くこと、
職種問わずドメインに関する知識を共通認識とすること、
そしてユーザーの満足度を上げる・維持のために品質を維持するルール策定、
同時にモニタリングやそれらを実現するためのツール・環境整備などをする（実装ですね）、
これらがSREの活動になります。

インフラエンジニア = SREとすると、
多くの場合は手段のひとつであるモニタリングや監視に偏ってしまい、
本来の目的であるユーザーの満足度を上げるための活動ができていない、ということになります。
これではエラーバジェットを設定しても、活用が難しくなるのではないでしょうか。

HowではなくWhyを考えることが大事です。

会社の体制などにもよりますがインフラエンジニアは
ドメインの知識を持つための機会に参加することが難しい場合も多く、
それよりも障害対応や環境整備・コスト削減や場合によっては情シスなどの活動が多くなってしまうことも多いと思います。
そしてそれを期待してインフラエンジニアを採用している会社も多いと思います。

この体制ではSREとしての活動は難しいでしょう。
SREとしての活動をするためには、
企業のこうした体制や文化を変えていくことが必要になります。

SLIメニューを振り返ろう

SREはどのような活動をしていくものなのか、というのを簡単にピックアップしていきました。
それに基づいてSLIメニューを振り返ってみましょう。

サービスの種類	SLIの種類	説明
Request/Response	可⽤性(Availability)	正常に応答したリクエストの⽐率
Request/Response	遅延(Latency)	しきい値より早く応答したリクエストの⽐率
Request/Response	品質(Quality)	特定の品質を満たしたリクエストの⽐率
データ処理	新鮮さ(Freshness)	ある特定の時間をしきい値にして、それより最近に更新されたデータの⽐率
データ処理	正確性(Correctness)	正しい値の出⼒につながったデータ処理への⼊⼒レコードの⽐率
データ処理	カバレッジ(Coverage)	処理したジョブの⽐率、処理に成功した⼊⼒レコードの⽐率など
ストレージ	Durability(耐久性)	書き込まれたレコードのうち、正しく読み出せるものの⽐率

参考

www.coursera.org

* New RelicやGoogleでも開催されていますので、問い合わせなどをしてみてください。

各社でやっているワークショップに参加したことがある方は理解しているかもしれませんが、
SLIメニューをみてもわかるように
正しさや比率などがそれぞれのサービスによって設けられています。

SLIの種類はこれ以外にも独自に作ることももちろんできると思いますが、
大事なのは何を持って正しいとするのか、良いとするのか、ということです。
このSLIメニューは、DREなどの活動にも当てはまりますのでぜひ意識してみてください。

これらは教科書通りに作るのではなく、
事業ドメインやサービスの特性を考慮して作る必要があります。
これはSREの活動をする上で非常に重要なことですので、
ぜひ意識して、プロダクトオーナーや開発チームと一緒に考えてみてください。
またCTOやCEOなどの経営陣とも一緒に考えてみるのも良いかもしれません（割とオススメです）。

インフラエンジニアがこうした活動をうまくするには？

せっかくなので、この観点でどう進んでいくと良いのでしょうか？
会社の体制や文化などもありますので、すべてにおいてこうすると良い、というのはありませんが
こうすると良いかもしれません、というものをピックアップします。
（もちろんインフラエンジニア以外にもオススメのものでもあります）

1. ドメインの知識を深める

これはインフラエンジニアだけでなく、開発チームや運用チーム、会社に属するすべての人に当てはまります。
ドメインの知識を深めることで、
それぞれの立場でどういうことが重要なのか、どういうことがユーザーの満足度に繋がるのか、
どういうことがユーザーの満足度を下げるのかを理解するできます。

プロジェクトやプロダクトの立ち上げ時には、
ドメインの知識を深めるためのワークショップなどを行うことが多いと思います。
これは非常に重要なことですが、
プロジェクトが進んでいくとドメインの知識を深める機会がなくなってしまうことが多いです。
インフラエンジニアの場合、とくに何か困った状態になった場合などに呼ばれることが多く
ドメインの知識を深める機会もなく、単純に困ったことを解決するためのタスクをこなすことが多くなってしまいます。

これではドメインの知識を深めることができません。
ドメインの知識がないと、ユーザーの満足度を上げるためにどうすれば良いのか、
どういうことがユーザーの満足度を下げるのか、を理解することができません。
つまりモニタリングなども単純なAPIのレスポンスの監視になってしまい、
何をもっていして品質が良いとするのか、ということがわからなくなってしまいます。

こうした状態にならないように、インフラエンジニアもドメインの知識を深める機会にぜひ加わりましょう。
また会社自体がエンジニアとそれ以外などで分断している場合は、
ドメインの知識を深める機会を作ることも大事です。

2. インタラクションを理解する

ドメインの知識を深めることで、
自分達のサービスはどのようにインタラクションをしているのか、
どのようなことがユーザーの満足度を上げるのか、下げるのかを理解できます。
UI/UXの観点からも考えることができます。
この観点から考えられるようになると、必然的に監視の観点も変わってきます。

冒頭にも書いたようにリクエストレスポンスの速さだけではなく、
提供しているコンテンツが正しいものになっているか、
データ提供までの鮮度や正確性なども考えることができるようになります。

3. 分析に参加する

これはいわゆるインフラ的なモニタリングだけを指しているわけではなく、
GAなどの分析ツールを使ってユーザーの行動を分析することも含みます。

ユーザーの行動を分析することで、
どのようなことがユーザーの満足度を上げるのか、下げるのかを理解することできます。
またどのように分析できればユーザーの満足度やユーザーの行動を理解できるのか、
設計から考えることができるようになります。

これはSREとしての活動においても非常に重要なことだと思っています。
自分自身はSRE/DRE、事業戦略などにも関わることが多く（サポートさせていただいてる会社でもよくやっています）、
同時にドメインの知識も深めることができます。

これはマーケティングやプロダクトオーナーなどがやっていることですが、
一緒に行動したり加わることで信頼関係も生まれ、活動しやすい環境になると思います。
このような活動の繰り返しによって文化が生まれ、
品質がよく、満足度の高いサービスを提供することができるようになると思います。

4. 当事者意識を持つ

SREとしての活動をする上で、当事者意識を持たずに動いていくのは不可能だと思っています。
自分たちのサービスがユーザーにどういう影響を与えているのか、
どういうことがユーザーの満足度を上げるのか、下げるのか、
クレームなどから理解することも当然できます。
ですがそれだけでは不十分で、これまで述べてきたようにあらゆることが満足度低下に繋がる可能性があります。

これらを知り、それを防ぐための秩序などを作るのは誰かがやってくれるのではなく、
SREなのです。
色々な領域に関わる必要性も出てきますし、コミュニケーションも必要になります。
そして自分たちSREはどうしていきたいのか、をきちんと伝えて伝播させていったり文化を作っていく必要があります。
当事者意識を持たないままでいると、いい感じにしてくれるインフラエンジニアというイメージが定着してしまいます。

ほんの少しの前に進む力と、やるかやらないかだけです!

5. 仲間作り

ドメインを理解し、インタラクションを理解し、分析などにも参加することで
自然と当事者意識を持つようになると思います。
もしくは当事者意識を持っているからこそ、ドメインを理解し、インタラクションを理解し、
分析などにも参加することができるのかもしれません。

ここまで意識できるようになればあとは仲間作りです。
もしSREの活動をしている人がいるのであれば、合流して一緒に活動していくのが良いと思います。
もしSREの活動をしている人がいないのであれば、
仲間を作るための活動が必要になります。

ここまで書いたようにSREは活動の幅が広く、一人でできることは限られています。
文化作りや秩序を守るためのルール作りなどに専念できる環境であれば問題ありませんが、
インフラエンジニアとしての活動もある程度はしなければならないでしょう。
もしこれを読んでいる方がインフラエンジニアでなくても、日常的に携わっている業務があるはずです。

エネルギーが必要な活動なため、一人では難しいのです。
仲間を作り、一緒に活動していくことで文化ができていきます。仲間作りが難しい、でもSREの活動をしたい、という場合は
SREとして活動している外部のエンジニアに相談してみるのも良いかもしれません。

まとめ

SREはサービスの利用者がハッピーになるための、あらゆる秩序や品質維持に関する活動です。
これはインフラエンジニアだけがするものではなく、
開発チームや運用チーム、会社に属するすべての人がするべき活動です。
決してコンテナーのオーケストレーションやクラウドの運用などの活動ではありません。
（が、コンテナーのオーケストレーションによってユーザーの満足度が上がるのであればやりましょう）

モニタリングなどはたしかにインフラエンジニアがやることが多いですが、
これはあくまで手段であり、目的ではなくいろんなエンジニアの方が協力してできる活動です。

自分自身でもできているのかというと、
すべての場所で、すべてがうまくできているのは当然なく、
体制の問題やSREについての認識の差異などもありできていないことも多いです。

ですがどんなドメインであっても当事者意識を持ち、事業に対してコミットしていくことは大事にしており
実際にやっていることも多いです。
アプリケーション開発をする場合においても、こうした活動をするときでも、
データエンジニアとしての活動をするときも、まずはドメインの知識を深めることから始めています。
そして怪しいと思ったら分析をして、ユーザーの行動を理解し、
自分自身でPDCAを回していくことで「これができたらよいな」、を実際に自分で取り組むようにしています。
（文章化やモニタリングの整備がまだまだですが、一人では全然できません・・）

もしかするとこれはSREとは違うのでは？と思うかもしれませんが、
SREとは何か、ということを考えるとこうした活動が一番近いのではないかと思っています。
もちろんいろんな環境によって差異やベストプラクティスはあると思いますが、
ユーザーのことを考えながら、社内のコミュニケーションや文化作りがセットになるため、
教科書通りにすることは難しいでしょう。

しかし行動した分だけ、ユーザーの満足度が上がり、
みなさんにとっても有益な楽しい活動になると思います。
ぜひ皆さんでやってみましょう!