書籍紹介：SREサイトリラアビリティエンジニア

システム障害対応の改善を考えていて、世の中で調べたもの、考え方で使えそうなものをご紹介いたします。
今回は2016年頃話題になったSREについてです。
こちらはどちらかというと新しい組織の役割分担を考えたい、一定レベル運用についてもわかっている方へお勧めです。
内容がボリューム多いので、困っている内容を辞書的に引きながら読まれるのがよろしいかと思います。

SREって何？

ご覧になっている皆様へ今更いう話ではないかもしれませんがー・・・

サイトリライアビリティエンジニアリング（SRE）とは、Googleで培われたシステム管理とサービス運用の方法論です。

SREって「共通基盤チーム」と何が違うの？

あくまでも私の解釈ですが・・・長く保守運用をされているチームであれば、一番似ているのは「共通基盤チーム」です。

ただ、この共通基盤チームは、業務チームの指示に従って基盤を触るのではなく「APも直しちゃうし、基盤も勝手に直しちゃう」のが違いです。

事前に監視項目（メトリック）を決めておきます。例えば、webサービスのレスポンスタイムとか、外からの死活監視とか、、、
これらがレベルが下がらないようにする責任をSREチームが負うイメージです。

SREって何がすごいの？

これも個人の感想ですが、SREの革命的なところは「対お客様へのサービス提供に責任を負う」ということです。

古くはカンパニー制とか、アジャイルとかとも通じるところがあるように感じています。

アジャイルを元に話をすると、ウォーターフォールの時には共通基盤チームが業務チームへ基盤を提供して、業務チームが基盤を含めてサービスを作って運用チームへ提供をして、運用チームがアプリ・基盤を含めてお客様へサービス提供をする。という階層構造＋上物がどんどん包含していく形になっていました。

SREの主な機能は２つです。
・サービス信頼性向上
・トイル（無駄な作業）の削除

前者はお客様へのサービス提供で、後者は原価削減につながること、つまりビジネスに直結することを共通基盤が責任を負うというスタイルです。
今まで裏で関節的にサービスに貢献するよりも、ずっと責任感が増して、良いサービスが提供ができそうな予感！

SREって実際どうなの？

SREには元基盤チームの方が多く入られる傾向にありますが、googleの提唱するSRE組織の役割分担を、SREと呼ばれている組織が担いきるのは、めちゃ難しいです・・・

世の中で「うまくできました！」って記事はよく見ますが、私自身はうまく言っている組織になかなかお目にかかれないなぁ、、、と思っています。

よくあるパターンはSREという名称になったが共通基盤チームになっているパターンです。元共通基盤チームで、SREの最大の特長でビジネスに直結することに責任を負わず、「各業務チームと連携しながらやらないと・・・」となってしまうことが多い印象です。

どうすればよいの？

本当にSRE組織を目指すならば、ちゃんとみんなで思想を読み込んで、SREチームの役割を明確にした上で、SREチームがサイト信頼性向上・トイルの削除をできる組織・設計にしないと難しいと思います。

組織・システム設計・運用設計をしっかりした上で、元基盤Tにやってもらうよりも、業務・基盤混成チームを作ったほうが現実的かなと思います。

流行ってはいますが、SREが必ずしも正解じゃないので、思想はうまく利用しつつ、今までの共通基盤チームで私は全然良いんじゃないかなぁと思います。