はじめに
従来、弊社はフルスタックエンジニアがインフラからフロントまでの面倒を見るスタイルでサイト開発をしてきていました。
今年、その体制が大きく変わり、SREチームが発足してインフラ・運用をメインに担っています。
本記事では、その背景と導入してからの活動について簡単にまとめます。
従来の課題
事業スケールの課題
- 事業を大きくしていく中で、サービス規模も拡大していくが、限られたメンバーで運用していくには限界が訪れる
- リクエスト数の増加、スループットの増加でアプリケーションの改修だけでは対応しきれなくなることが見えている
開発環境の課題
- エンジニアが増え、「よく知っている」エンジニアと「はじめまして」のエンジニアの間で開発速度に差が広がる
- サービス拡充を繰り返す中で、デッドコードやブラックボックスになる関数も増える
- VPS運用からクラウド運用へ移行し、ベストプラクティスが変わっていく
モチベーションの課題
- 事業に直結しているサービスだからこそ、売上につながる活動が優先されてしまう
- ユーザにとっては、サイトは24h/365days正常であって当たり前
- 維持管理の必要性に対する説明責任を果たさなければならない
- そもそも、事業的な活動にモチベーションを持つエンジニアが多い風土
- ベンチャーなので（パワーワード）
設立に至る道
事業を拡大するために開発効率を最大化する必要があるという共通認識があることが、最も大事だったと思います。
- 現在の状況ではエンジニアを疲弊させることになる
- 事業的戦略として、先を見据えた再構築を行えるチームが必要
- 一時的にコストセンター化しても、長期的視野にたてば開発効率の向上が売上につながる
- SREかっこいい。やりたいエンジニアがいる（ココ重要）
SREは何をするか
ただの猿真似で終わらせない
SRE本は良書ですが、それをそのまま真似すればSREというわけではありません。
大事なことは、googleという現代の巨人がなぜSREという活動をしているかを理解することだと思います。
SIerでインフラ部隊、オペレーターとアプリケーション開発の間で確執が生まれ、DevOpsに答えを見出そうとしているその先で、googleはSREを産んでいたのです。
我々はSREのあり方を、その活動ではなく、その意図を学ぶことにしています。
SREのこころ
ただ問題なく運用していくだけでは未来につながらない
Opsとして問題なく運用していくことが求められるのですが、それはあくまで現状維持、リリース時の環境維持に過ぎません。
そうなると、サービスの数やサーバ台数が増えたらその分を人数でカバーしなければならない。
問題が発生すれば手順書が厚くなり、運用時間が増え、やはり人数でカバーしなければならない。
オペレータは目を皿のようにして問題がないことを常日頃から気にしなければならない。
結果として、エンジニアではなく、非人間的な（というと大げさですが）作業に身をやつすという、苦行に至ります。
未来の事業とエンジニアを守るために、SREは現時点で一つの答えを出していると考えられます。
SREエンジニアを守るために
- エンジニアリングをその活動の中心に置く
- 運用に費やす時間に制限を設ける（トイルの管理）
- 運用に神経質にならないよう、サービスレベルを定義・合意してエンジニアリングの時間を守る（SLO）
- SREの意義を理解し、広める
- 事業にとってどのような貢献を行っているのか定量的に判断する
- プライベートを軽視しない
- ページ（呼び出し）を最小限に食い止める（SLOに対するプロアクティブな活動）
事業を守るために
- サービスを健康な状態に保つ
- ユーザにとって何が大切かを正しく判断する（SLOの選択）
- サービスを常に良いものへ変えていく
- 挑戦的なサービ改善（エラーバジェット）
義務や決まりごとに頼ることの危うさを知る
- サービスの維持は不断の努力の成果である
- エラー発生時の訓練を行う
- ポストモーテムの文化醸成
- 正しい行いには賞賛を
- 義務ではなく、意思（will）として自ら行う環境を作る
弊社でのSRE
前項の理解の中で、弊社では SREは事業の根幹となるサイト開発を全面的にバックアップするもの として位置づけています。
ミッションステートメント
- 事業を円滑に進めるために安定的なシステム運用と改善を進める
- サービスの信頼性・可用性・パフォーマンス・開発効率にコミットし、サイト改善の支援を行う
なぜこうなったか
- 現時点でgoogleのようにAPIが大量にあるサービスではない
- UXを改善していくことが最も（ユーザ視点での）サイト信頼性に寄与し、事業的な意味がある
- UXの中にはサイトの安定性も当然含まれる
という理由で、SREの活動をアレンジしています。
SREの主な活動
インフラ維持・管理
サイトの安定性向上のために、各種指標をもとにインフラ維持・管理を行っています。
今後の拡大を見据えた設計が当然必要で、人の手で管理し続けるものではなく、エンジニアリングによる作業の効率化が求められます。
クラウド運用しているので、スケーラブルな構成を念頭にしています。
運用
サイト運用している中で、残念ながら定常業務が発生します。
定常業務はSREが行い、日々、その自動化に向けてエンジニアリングします。
弊社では今まで定常業務に携わっていないメンバーが実施することで、運用自体の非効率な部分のあぶり出しも同時に行っています（副作用ではありますがｗ）
基盤開発
これが最大のアレンジ箇所だと思われます。
googleでは、基盤開発は別のチームが行っているようですが、弊社ではこれもSREの役割です。
というのも、弊社にとっての基盤とは、弊社のサイト開発エンジニアが利用する環境だからです。
その為、動作基盤の充実がそのままバグを防ぐ環境や開発サイクルの促進につながるため、SREの業務として位置づけています。
どうなったか
実際のところはまだSRE活動が始まって間もないので豊富な結果をお伝えすることはかないませんが、着実にエンジニアにも事業にもサイトにも優しい活動を進めています。
ここについては別の機会（後日のアドベントカレンダー？）にお伝えできればと思いますが、事情により今回は詳細を割愛いたします。
SREが発足する前よりも、全体を整える活動が多くできていることは確実です。
お知らせ
エイチームブライズでは一緒にSREとして活躍してくれる優秀な人材を募集中です。
これから先、フロントエンド側も充実していくので、興味のある方はぜひともエイチームグループ採用ページ（Webエンジニア詳細ページ）よりお問い合わせ下さい。
明日は
華やかなデザイナ陣の中で黒一点、@nishio1873が最近学んでいるphpなどについて書いてくれるようです。
先日、@nishio1873がレタッチしているところを見たのですが、素晴らしい技術を持っていました。
その上プログラミングを学んでいるというのですから必見です！
ぜひご期待ください！