SRE Advent Calendar 2018 - Qiitaの20日目の記事です。先日はもりはやさんのSRE本の素晴らしさについて語ってみる - もりはやメモφ(・ω・ )でした！私もエラーバジェットという考え方には影響を受けました。

タイムライン

時間	内容
2017/4	インフラをVPSからAWSへ
2017/6	AWSサミットの内容を社内で報告会(メルカリさんのSREの話も)
2017/8	SRE本の社内読書会
2018/4	SRE的なことしていくぞ事業支援チームできる(2人)
2018/12	俺たちは雰囲気でSREをやっている

なぜ雰囲気でやることになったか

これを読まれる方の立場で受け取り方は変わってくると思いますので、私と弊社についての説明を書きました。SRE自体の説明は省きます。

会社の事業が成長段階にあり、開発案件が多い。
SREチームとして正式に組織にできたわけではない。
私のやっていき不足

結果例えばこのような状況となっています。

次の開発に追われている
急ぎで作ったものの運用コストが徐々に増えている。
SLOが運用されていない
新しい技術を試す余裕がない

本当はどうしたいのか

SREの活動として紹介されているようなことをやりたい。（SREをやりたいというわけではない）
楽しく開発（アプリも、基盤構築も）したい。
SLOを軸に動きたい。エラーバジェットの考えは画期的だ。
めんどくさいトイルを自動化して、運用コストは減らしていきたい。クリエイティブなことに使える時間は増やしたい。
モニタリング基盤などはしっかり整えて、サービスを診れる状態にしたい。わからないという状態はつらいので、これさえ押さえればとりあえず大丈夫！という状態になりたい。
その時々のベストな構築・開発がしたい。（時間に余裕があれば設計を議論したりしてどうするのがいいか考えて楽しく開発ができるはず）
設計から小さなリファクタリングもやりたい。リファクタリングは楽しい。
新しい技術を試すなど余裕を持ちたい。常に少し新しいものを取り入れるというのは継続的にやれれば楽しい。
サイト開発チームの開発速度を遅くする要因を取り除くことを継続的にやっていきたい
- （開発も楽しいですが開発する環境を整える方も、私は楽しみを感じます。）

あげると、キリがないかも知れないですが、楽しく開発したい、もしくは開発してほしいが一番の欲求かもしれません。

どうすればできるのか

モニタリング基盤を整える
- エンジニアリングする以上やはりまずは定点観測できる基盤を整えねば良くなっているか悪くなっているかわからりずらい
- 開発に追われた結果、モニタリング（ロギングも）が不十分なところがあるのです..。
サービスに合わせたSLOを決める
速度やエラー率などわかりやすい数値を元に改善結果をビジネスサイドにアピールし、SREチームを正式に作る

いや、何かそういうとこじゃないんです。

先日コッターやレヴィンの変革のモデルを学びました。わかりやすいのでレヴィンの変革モデルを紹介すると、組織が変革するには以下の3段階があります。

解凍 - 既存の考えを破棄
変革 - 新しい考えを打ち立てる
再凍結 - それを定着させる

解凍ができていない組織に解凍を促すには、例えば危機感を持たせると良いようです。

私はこのモデルを知って、これだと思いました。今までになかったSREという考えを組織に定着させるには、まずSREが必要なんだと組織に思わせるところから初めるアプローチも良さそうです！！(改善を元に数値を示して徐々に必要だと思わせるアプローチもありだし、組織の権威がガッと推し進める方法などもあると思います。）

実践するとしたら、SRE（もしくはそのような動きをする人）がいない組織というのをプレゼンテーションするとかでしょうか。

組織について

組織のことを考えると

なぜSREが必要なのか
今必要か
必要なのはSREなのか
などなど..

と、考えることがあります。組織の整合性をみる、7Sというフレームワークがあります。

ハード面
- 組織構造 (Structure)
- 制度 (System)
- 戦略 (Strategy)
ソフト面
- 共通の価値・理念(Shared value)
- スキル・能力 (Skill)
- 経営スタイル・文化 (Style)
- 人材 (Staff)

例えば、メルカリがGAFAを目指すという戦略(Strategy)で、開発組織を1000人にするとしたら、組織構造としてマイクロサービスを軸にした組織構造(Structure)にするのは整合性がある、というように使います。

では、SREを自分の組織に置いたときには他の人材や共通の価値、制度、戦略とはどう関連するでしょうか。少なくともSREを置くと単純に考えると戦略とは整合性を見る必要がありそうです。スタートアップにおいては、サービスの信頼性より、PMFを目指してバリバリ開発をするかもしれません。

そう考えると、SREやっていくぞと言っただけではだいぶだめな気がします。自社について、SLOを設定して、エラーバジェットがなくなると開発ストップができる状況かどうかなどをみる必要があります。

逆に組織の権威がガッとSREを置いて、ちょっと組織構造を変えたときは、それに合うように戦略や文化もちょっと変える必要があるかもしれません。

他に例を出すと、組織構造がDevとOpsが別れていることによる連携不足が原因で戦略に合わないから、エラーバジェットを作って、組織構造をSREに寄せて、戦略と整合させるなんてパターンもあるかもしれません。

以上、組織構造について説明しましたが、正直私は何も考えていませんでした。

まとめ

もちろん、ポストモーテムだったり、導入できることは導入しています。しかし、SREを置ける状況か、置くとしたら他の戦略や文化などと整合しない部分はあるかなどを考えてやっていかないといつまでも雰囲気になってしまいます。そして、今会社に必要なのはSREだ、となったら解凍、変革、再凍結を意識して組織を変えていきましょう！

前提

私と弊社の状況を軽く説明致します。

弊社(以下"ヘイシャ"もしくは"ヘイ"と呼びます)はVPSからAWSに昨年の春頃に移行しました。私は新卒でヘイに入り、1年目はだいたいWebやスマホのもろもろの業務をやりつつ、 2年目から移行業務をきっかけにインフラも触るようになりました。

Webプログラミングはココ最近はレビューくらいになりまして、スマホはWebViewくらいのアプリですがたまに何かあれば見るといった感じです。採用業務など、PCに触らない業務もあります。

感覚値で言うと、開発(アプリやインフラ構築)、運用、その他の業務=5:3:2です。

インフラの業務になったのは、あるあるかもしれませんが、私の大学時代の研究室が学生がWebやDNSやLDAP、メールサーバなどを運用していたこともありました。なので、インフラ業務に対して嫌だななどの感情がなく、むしろやりたいと思い、そう上司に言っていたのと、移行というタイミングがあったからです。 AWSは地方のJAWS-UGは行っていましたが、お金がなくEC2でサーバ立ててみるくらいでしたので、社会人になってから本格的に触り出しました。

VPSからの移行は、基本的には構成を踏襲してAWSで実装しました。例えば、VPSの時はロードバランシングさせていなかったので、ELBを置いて、そのまま下にWebサーバを置く感じです。

弊サービスはWebサービスでリアル店舗もあります。クライアント側や社内スタッフ用のサービスもあります。インフラをみるチームは2人ですが、感覚でいうと実質0.8人~1.2人くらいです。曖昧な言葉ですが、そんなにシビアなサービスではないです。