どうも、セクションナイン の 吉田真吾（@yoshidashingo）です。
はじめに
昨年、メルカリさんが採用したことで一躍注目を浴びた Site Reliability Engineering(SRE) について調べてみました。
メルカリにおけるSite Reliability Engineering(SRE)チーム
メルカリSREの定義
- 運用業務とサイトの信頼性向上の2種類の役割を担う
- 運用業務（サーバー管理者としての役割）
- インフラの自動化
- 障害対応
- システムの維持
- サイトのエンハンス（ソフトウェアエンジニアとしての役割）
- ソースコードに手を加えてサイトのパフォーマンスを改善する（H2Oはまさにこれですかね）
- 可用性、スケーラビリティを向上する
メルカリでのSREチームの導入経緯
- SREチームの前身はインフラチーム
- サービスが伸びてきたためインフラチームの担う仕事が増えてきた
- はじめはインフラのセットアップ、運用のためのセットアップが中心だった
- サービスが伸びて増えてきた仕事は「データベースの分散」「ChatOpsなどのデプロイ環境の構築」「ログ分析基盤やPUSH配信サーバーなどのミドルウェアの開発と検証」「サーバーの冗長化」「APIサーバーのパフォーマンス向上」
- 開発環境やQA環境の整備も行っている
- 運用業務について当番制などを導入した
メルカリでのSREチームの業務
上記ブログエントリーから引用
現在のSREチームの主な業務は次のようになります。
- APIサーバ、ミドルウェアの可用性の維持・向上
- APIサーバ、ミドルウェアのパフォーマンスの向上
- ログ収集・分析基盤の構築、運用
- サーバプロビジョニング・デプロイの整備
- セキュリティの担保
- 開発環境などの整備
メルカリSREに求める人材像
以下のリンクに応募資格が記載されていますが、必要条件としては一般的なエンジニアに求められるスペックで、歓迎条件もさほど厳しい条件は課されていないように見られます。また、給与についてもかなりレンジが広くとられている（年棒400-1200万）ことからして、「入った時点ではロックスターじゃなくてもいいので、内部で長期的に育てていきますよ」という意思を感じます。
感想：カスタマー目線なチーム
一般的な運用／インフラ／DBAチームなど「機能範囲」で定義されているチームを、サービス全体の信頼性を維持・向上する役割を担うチームという「責任範囲」で定義しており、サービスの運営に対して「主体的なチーム」の形と言えますね。
Google SRE
メルカリさんが参考にしたGoogle SREですが、資料がちまたに結構落ちてたので、具体的にどんなものなのか調べてみました。
Site Reliability Engineeringブログ
(2014.4.28)
Google SRE のヴァイスプレジデントである Ben Treynor 氏に対し、Site Reliability Manager である Niall Murphy 氏がGoogleのSREチームについてインタビューをしています。
http://www.site-reliability-engineering.info/2014/04/what-is-site-reliability-engineering.html
この中で、Google SREというのは、今まで運用エンジニアが担ってきた業務も行うが、人手で対応していた内容を自動化に置き換える、ソフトウェアエンジニアとしての役割も担っており、サービスの可用性、レイテンシ、パフォーマンス、効率性、変更管理、監視、緊急対応、キャパシティプランニングを日々の業務で担当していると説明されています。
よって、Google SREの採用活動においてはソフトウェア開発の能力も求めているそうです。
また、SREチームと開発チームの間で利害の競合が問題になりがちですが、この解決手段として「エラーバジェット（Error Budget）」という考えかたを採用しているそうです。これはサービスレベル目標で設定する稼働率要件などをひっくり返した、許容可能なエラー率（時間、範囲、レベル）を指す言葉です。
サービスを早期にリリースしてユーザーを獲得したいソフトウェア開発チームは、この予算内に品質レベルを作り込めた時点でデリバリーできるので、これを超過するまでは機能開発に集中できるという点でメリットがあり、SREに入ってもらうときのように両チームの間で密なやりとりをする必要ありません。
また、ひとつのサービスに複数のチームが機能別に携わってる場合については、ひとつのチームがエラーバジェットを使い果たしてしまい別のチームのイケてる機能がリリースできなくなってしまう事態を避けるために、より多くのテストをリリース前に完了することが推奨されています。
そもそも障害が起きても監視からチケットが上がって数分以内に対応できるような人間はいないので、MTTR(復旧時間)の観点からも設定変更を多層的に自動化し、ミリ秒単位で自動復旧されるようにするほうが有益だと説明されています。
RedditでのGoogle SREたちによるAMA
(2014.1.24)
こちらは実際にGoogleの現場でSREをやっているメンバーが答えたAMA(Ask Me Anything:なんでも聞いて！)のスレ。シニアSRE、Site Reliability Manager、ストレージインフラ担当のSRE、ソーシャル/広告/インフラ担当のSRE TLM(Tech Lead Manager)の4人がさまざまなロケーションから参加しています。
(※RedditのURLを貼ると投稿が失敗するため、こちらの検索結果のトップにあるRedditの記事を参照ください...)
reddit we are the site reliability engineering - Google 検索
この中で「Googleには複数のSREチームがあり、「検索」「ストレージ」「ColossusとBigtable」といった感じでそれぞれが担当のサービスを受け持って」います。
運用に関する話で面白いのは、Googleのインフラはグローバルで巨大なので、「インシデント発生時は悪影響が広範囲に及ばないように極小化する（ロードバランサーの再設定などで経路を調整）のが最優先事項」であることや、「社内には用途や分散処理速度に応じてたくさんの運用ツールがある」と説明されている点で、SREがそれぞれ担当サービスや手に合ったツールを駆使して障害対応にあたっているという点です。
また、どんなスキルがあればSREチームに入れるのかという質問に対し1人のメンバーは「自分はサーバー管理者からキャリアを始めて、ネットワークやパフォーマンス分析やシステムエンジニアリングを学んでからGoogleにジョインした」とのことで、サービスの運用に利用するソフトウェアをひととおり扱えるレベルが必須なようですね。
インタビュー : Site Reliability Engineerは世界で最も強烈なピットクルー
(2012.6.7)
Andrew Widdowson氏は2007年からGoogleで働いており、SREチームとしての担当はウェブ検索や画像検索。
彼によるとSREとは「すべてのサービスが超安定して超速く稼働するように担保するソフトウェアエンジニア」のことで、あくまで「SREは「運用エンジニア」のかっこいい呼び方ということではなくて、ロックスターなシステムエンジニアである」というのがポイントです。
もしSREになりたいなら「コンピューターサイエンスを学んで、できるかぎり多くの経験を積むとよいよ」とのこと。
Google Student Blog: Site Reliability Engineers: the “world’s most intense pit crew”
インタビュー : Site Reliability Engineerは最も面白い問題を解いている
(2012.7.25)
Ben Appleton氏は2008年からMapsチームで働いており、最近(2012年当時)、SREに異動したエンジニア。
彼が過去Mapsチームで働いていた頃、SREの近くで仕事をしてて、彼らが「すごく強いチームで、スマートに物事を成し遂げる」ことを見ていたそう。シドニーのSREチームは、MapsやGeoコマースからChromeやApps、ソーシャルやBlogger、ネットワークやGo言語まで幅広くカバーしており、最も面白い問題を解いているようだと感じたため、自ら希望してSREに移籍させてもらったそうです。
Google AI Blog: Site Reliability Engineers: “solving the most interesting problems”
サンタモニカのSREチームの発表
Alex PerryというサンタモニカのSREチームの中の人の発表資料。
SREチームはマウンテンビュー、チューリッヒ、ニューヨーク、サンタモニカ、ダブリン、カークランドにあるそう（発表当時）です。
SREチームの職責は「ユーザーから見える稼働時間や品質を担保すること」と定義されています。
彼らになぜ「深くて詳細な知識や分散環境の専門知識」が求められるかというと、単なるオペレーターではなく、「SREチームメンバーも障害時のオンコールを受け、どんな問題でも解決するため」ではあるのですが、一次対応に続き「恒久対応も行い、パッチ作成、テスト、コードレビューなどを行い、開発やリリース時期の調整を行う」必要があるうえ、さらには、「サーバー管理の定常業務があれば自動化を促し」「監視や自動化、スクリプトやデータ解析、自動回復機能などをもって、人手によるコストの最小化を担う」、また「サイトの成長やスケールがしやすくなるように、必要な要件（※おそらく非機能要件）を定義し、非効率な部分を特定し、必要ならバグ修正もする。」というソフトウェアエンジニアとしての役割も求められます。
サイトの成長で安定性が失われてはいけないし、成長することで発生する問題も必ずあるので、スタッフの人数によってスケールが制限されてしまうことを防止するために自動化を行ったり、「オンコール（障害連絡体制）のカバレッジを見積もり、可能なら少人数でコスト効率よく対応できるように統合運用できるようにしたりする」のも彼らの役割で、「新しいアイデアを試すために20%プロジェクトをそういったことを実現するための開発にあてたりする」のだそうです。
例として、SREチームの一週間を以下のように記載してます。
- 週1日、20%プロジェクトの仕事をする。
- 週1日、休みか、会社のイベントか、ボランティアか、病欠のために費やされる。
- 週1日、担当サイトのためのトレーニングや勉強をする。
- 週2日、サイト分析、改善計画、メンテナンスなどを実施する。
他社の採用情報
Googleの他にもSREを採用している会社があるので、どういった職責なのか少し見てみましょう。
サイトが24時間365日正常稼働していることを担保するのがSREの仕事であり、問題に直面したら、他のテクニカルオペレーションチームやエンジニアリングチームとともに責任をもって解決にあたり、リリースエンジニアリングチームとはリリース時期の調整や緊急アップデートがサイトにあたえる影響について把握します。また、Facebookがより早く効率的に稼働するようにパフォーマンス問題などを追跡し、長期的目線で課題解決を模索する職種とのことです。
Netflix
NetflixのJob Descriptionのうち、最も象徴的なのが「Minimum Job Qualifications（必須要件）」の部分です。
- 高トラフィックな大規模分散システムで生じる不安定さの根本原因を解決できる能力
- Linux/Java/Tomcatや他のミドルウェア技術における設定や障害対応経験
- 信頼性の観点からの大規模で複雑なシステムの理解力
- pythonかperlかJVMベースの言語でのコーディング力
- 信頼性の問題を解決する情熱と今後の戦略を見極める力
- Ability to root cause sources of instability in a high-traffic, large-scale distributed system
- Experience with configuration and troubleshooting of Linux, Java, Tomcat, and other middleware technologies
- Understands large-scale complex systems from a reliability perspective
- Scripting abilities in python, perl, or JVM-based languages
- Passion for resolving reliability issues and identify strategies to mitigate going forward
sysadmin to SRE
システム管理者からSREに変化するとはどういうことかという内容。「変更管理ツール(ChefやAnsible)よりAMI作成」「コントロール不可能なカオスから意図的なカオスへ（Chaosシリーズのこと）」「変更防止から変更のロギングへ」「監視運用ツールからAtlas(内製ツール)と気づきを得られるエンジニアリングへ」といった変化。
まとめ
GoogleのSREについて、SWE(ソフトウェアエンジニア)とSREが対をなすように説明されていた部分が非常に理解しやすい説明でした。SWEが価値の創造が主軸、SREが価値の継続デリバリーが主軸と考えることもできそうですし、SWEが機能要件が主軸、SREが非機能要件が主軸というとらえかたもできそうです。
また、運用／保守／自動化／アーキテクティングといった「やること」ではなく、サイトの信頼性を担保するという「ミッション」がチーム名になっている点も非常に合理的に感じます。
ちなみに本も出るみたいです。
