12月は色々ありました。今回はそのへんを雑多に振り返る記事です。
SRE Advent Calendar 2018 の個人的おすすめ記事
SRE Advent Calendar 2018 は、スタディストのかつひささんが企画したアドベントカレンダーです。1個目のカレンダーがすぐ埋まってしまったので、2個目（SRE 2 Advent Calendar 2018）も作られてました。僕も11日目に投稿しました。
1個目の方はみんなきっちり執筆して25日埋まってましたし、どちらも内容の濃い記事が多くてすごかったですね。
冬休みに入ったので、この機会に SRE Advent Calendar の記事を全部読み返して、個人的おすすめ記事をピックアップしてみました。どれも面白かったのですが、個人的にはいま SRE の組織体制に興味があるので、主にそのへんの記事に偏ってます。ご了承ください。
Day 10: DevOps文化の組織にSRE活動を導入した話
（記事を読み限りおそらく）過去5年かそれ以上の間に、
- 開発チームとインフラチームが分離していた体制
- 各開発チームにインフラメンバーを送り込む体制（DevOps 体制）
- インフラメンバーを組織横断で繋ぐSREを導入した体制（SRE 体制）
と組織体制を見直してきた現場での、それぞれの体制のメリット・デメリットをまとめた記事です。
最新の体制は、SRE チームと開発チームを兼務する SRE と、SRE チーム兼任の SRE（Core メンバー）を組み合わせたもののようです。これは是非参考にしたいと思いました。
Day 14: プロダクト横断のSREチームを組成したい話
オプトの渋谷さんによる記事。
渋谷さんは SRE Lounge #5 で SRE チーム立ち上げについての話をされてました。この記事は、その今後の展開についての話で、SRE が複数のプロダクトチームを横断して活動するように変えていきたいという構想についてのものです。
記事の最後の方にある「乗り越えるべき壁」のところは、僕もよくわかる悩みで……特に、プロダクトをまたぐことで「一人のSREが知るべき内容はすごく多岐に渡ってしまいそう」という点は、実際やってみた結果を是非お聞きしたいです。
ちなみに、
SREのマトリックス的な配置についてはヌーラボさんの取り組みを参考にしています
とのことで、参考にしてもらえて嬉しい！
Day 16: SLO設定/超過監視にまつわる活動の振り返り
エムスリーテックブログの記事。SLI の測定方法から、SLO 超過時のプロセスまで、具体的なユースケースが詳細にまとめられた良記事です。
SLO を超過したかどうかの検知から、超過した場合のチケット作成まで自動化されており、これから SLO を導入しようという人は必読かと思います。あと、elastalert（Elasticsearch にクエリ投げて結果によって通知するツール）については僕も知らなかったので、今度使ってみます……。
Day 4 (SRE 2): データ基盤をHadoopからBigQueryに移管するときのアンチパターン
Hadoop のようなデータ基盤を持つサービスで、SRE が果たすべき役割に関する記事です。
この記事では、データを処理するフローの途中で組織が分かれていたために、データの欠損や不整合が発生してしまった自社事例を紹介しています。
各組織が「自分の見える範囲で手っ取り早く済ませよう」とした結果、そうなってしまったようです。ソフトウェア開発じゃなくて、データ基盤の開発でも「コンウェイの法則」が出てくることあるんですね……。
最終的に、このような問題を解決するには「プロダクト」と「分析」の間を取り持つ DataOps ロールが必要で、そのロールはシステム全体を最適化する部隊（つまり SRE）が担うべきと結論づけています。
Day 24: SRE風のインフラエンジニアにならないために
はてブでバズってた記事。SREがどういうものかを知ってほしいときには、まずこのページを読んでもらおう！と思ったくらい、説明が必要十分で読みやすい記事でした。
ちなみに、この記事の分類に従うと、僕の今年の仕事は「インフラエンジニアではなくSREとしてどう高速リリースを実現するか」のところにずっと注力してました。CI の改善、リリースプロセスやリリース自動化ツールの改善、開発チームが監視に使えるツールの充実などなど……。
Day 25: [SRE Advent Calendar] SRE Advent Calendar 2018 を終えて
企画者のかつひささんによるまとめ記事です。SRE Advent Calendar の全記事に一言コメントが付けられています。興味のある記事だけ読みたい人は、まずはここをざーっと読むのがいいかも。
ちなみに、この記事の最後に「@katsuhisa__的ベスト3」のコーナーがあって、そこで僕の書いた記事を1位に選んでくれていました。まったく予想してなかったのでびっくりしましたが、頑張って書いた甲斐がありました。ありがとうございます。
ヌーラボSREの吉澤さんのこちらの記事が、SRE Advent Calendar 2018 の@katsuhisa__ 的1位でした。
SREの文脈では、一般的に、SLI といえば、レイテンシやエラーレートを指すことが多いですが、この記事では、自社のチームの課題に焦点を当て、社内向けSLI を整備した話が書かれています。
私が登壇する資料では、度々「ウェブオペレーションは、技芸であり、科学ではない」（ by 『ウェブオペレーション ―サイト運用管理の実践テクニック』 ）という言葉を引用しますが、まさにこの記事の事例には、一種の技芸を感じました。
また、それ以外にもSREと組織構造にも詳しく触れられていて、今後も何回も読み返したくなるような内容でした。
SRE Advent Calendar 2018 に投稿した記事
で、この流れで僕が投稿した記事も紹介。SRE Advent Calendar 11日目の記事として、Backlog プロジェクトにて SRE メンバを中心に試してきたサービスレベル指標と、それぞれについて感じたメリット・デメリットをまとめました。
9月の SRE Lounge #5 の講演では時間の都合で話せなかったネタがあって、年内にアウトプットするならこれがラストチャンスだ！と思って飛びついて、なんとか書き上げられました。結果的には、発表時間が1時間あっても足りなそうなくらいに分量が膨らみましたね……。
あまりにも泥臭すぎる内容だし、人によっては「この会社はレベルが低い」と思うのではないか……と思って、公開前には色々悩んで書いたり消したりしました。それでも最終的に公開したのは、SRE について考えるときには組織の話は外せないし、その具体的なケーススタディの価値は高い、と思うからでした。
SRE の組織体制は、この記事に書いたものが最終形ではなくて、来年以降も徐々に改善していくことになりそうです。半年〜1年後には、また新たな話ができると思います。
おまけ：Mackerel Drink Up の LT 発表
あと、この記事の公開日にちょうど Mackerel Drink Up #8 Tokyo というイベントがあり、Backlog での Mackerel 利用事例について発表しました。Advent Calendar の記事中にちらっと出てくる監視システムについて、もう少し詳しく話しています。
ゆううきさんが東京に来るということで講演を聞いて、色々お話もできてよかったんですが、その数日後に退職ブログが出てびっくりしました。
ゆううきさんが話していたことで、印象的だったのはこのあたりでした。
- 書籍「Webオペレーション」には、運用は技芸で科学ではない、という趣旨の文がある。しかし、個人的にはむしろ、技芸から科学へ進んでいると思ってる。一例として、reliability engineeringという分野が生まれてきている。
- チーム内に SRE がいると、Dev と Ops のトレードオフを取りやすい。チームが分かれているとそこがやりにくくなる（＝変更速度が下がる）のでは。同じチームに SRE がいることで、開発者と SRE の間で、お互いに業務を融通できるようになった。
- メルカリのアドベントカレンダーの記事にも、1つのチーム内で開発と運用に責任を持つという話があった（マイクロサービスチーム編成のベストプラクティスとメルカリでの構想 - Mercari Engineering Blog）。いまのトレンドはその方向なのかも。
個人的に考えている SRE のあるべき姿と、ゆううきさんの話が近かったので、その点は勇気づけられました。運用が科学に進んでいる、という点は、僕はあまりそうは思わないのですが、そうであったら面白い、とも思うので、ゆううきさんの今後の活躍に注目したいと思います。
