SRE NEXT 2020 参加記録

1/25(土)に豊洲フロントで開催されたSRE NEXT 2020に参加してきました。
参加者の大半はSREまたはソフトウエアエンジニア現職とのことで、自分が参加しても大丈夫?の不安が募りましたが、全セッションを通して大変興味深く自分の関心が満たされました。私が本イベントに参加した目的は以下です。

  • SREそのものへの興味関心
  • 各社のSREの取り組みを知る
  • 技術と組織・人をどう繋いでいるか、どう仕組みづくりをしているかを知る

拝聴したセッションについて感想を残します。

SRE NEXT 2020

  • 参加セッション
    • [A0] 分散アプリケーションの信頼性観測技術に関する研究 / 坪内佑樹さん
    • [C1] 絶え間なく変化するメルカリ・メルペイにおけるSREの組織と成長 / 渋谷さん、高木さん
    • [A2] パフォーマンスを最大化するための SRE のオンボーディング事例 / tkuchikiさん
    • [A3] freee のエンジニアは障害から何を学び、どう改善しているのか? / 坂井学さん
    • [A4] 日経電子版SREチーム立ち上げ中 / osamu takayasuさん
    • [B6] ZOZO MLOps のチームリーディングとSRE(Engineering) / 瀬尾 直利 (そのっつ)さん
    • [B7] SRE Practices in Mercari Microservices / Taichi Nakashimaさん

[A0] 分散アプリケーションの信頼性観測技術に関する研究

SREの次、 "next" を会場の皆さんと考えてみたいとお話がありました。
冒頭で 1983年に書かれた論文「自動化の皮肉(Ironies Automation)」を紹介します。Bainbridgeは本論文で、システムを自動化すれば運用が楽になり万事解決するとは言えない。自動化するほどに人間の訓練や負荷は高まると示しています。35年前の示唆の通り、システムの自動化推進はエンジニアにひとときの楽をもたらしました。他方で複雑化するシステムは人間に対してさらなる課題を生んでいるように見えます。
Ironies Automationに対するアプローチとして、ゆううきさんは「人間が失敗を許容する前提で運用を設計する。失敗とは、一時的な信頼性の低下を許容すること」を提案しました。

信頼性の低下は、システム開発・運用者にとって恐怖であり失敗と見なされがちです。でもSREは信頼性を制御するための工学だと定義すれば、一時的な信頼性の低下は失敗ではない、というのがゆううきさんの解釈です。仮にシステムが不安定になっても「これは我々が制御できるシステムだ」とわかっていれば、システムに変更を加える恐怖が減ります。恐怖が減ればシステム変更が容易になります。システム変更速度が上がれば開発者は前向きな開発が進めやすくなります。
信頼性向上を目指すシステム開発・運用から、エンジニアがシステムを制御できる状態に主眼を置きませんか。失敗を許容する前提で運用を設計することにより、システムの信頼性を高めたい。この世界をゆううきさんは見たいのだなと感じました。
研究を進めるうえで「人と組織(経営学)」「人と機械(認知システム工学)」にも着目しているそうです。SREの研究者として明らかにしていく3つの研究テーマを紹介されました。

  • 時間軸の可観測性:時系列データベースの研究
  • 空間軸の可観測性:地理的に分散したアプリケーションの信頼性向上
  • データの一貫性を保証しつつ、応答性を最大化できるよう制御

自分が本講演を聴いて印象に残った言葉は以下です。

これらの研究を進めることで、SREの次 (例えばいまSREの領域で主流の Microservise等)や別の道がないかを模索しようとしている

研究とは「研ぎ澄まし、突めること。新しい事実や解釈の発見」です。本講演では、GoogleのSRE本から1つ歩を進めて、SREとは信頼性を制御するための工学で一時的な信頼性の低下は失敗ではないとの解釈を示されました。ゆううきさんは、その解釈の先に新しい山を作って越え、道を作っていくんだな。SREの皆さんが扱う技術領域をよくするために、地図にはない領域を探って扉を開けていかれるのですね。わくわく。技術者がどんなWebシステムも容易に制御可能になって運用が楽になれば、システムや人間にはどんな未来が広がるのでしょう。

AD100年頃にガラスの製造方法が発見されてから、人間は鏡を作り、自画像が描けるようになり、眼鏡や望遠鏡を発明し、カメラレンズそしてテレビ映像の発達に繋がりました。そしてグラスファイバーを活用してWWWがスタートし、今ではスマートフォンで撮影した画像を世界中に公開できます。
研究者のお話から私たちは悠久の時を感じたり未来への想像を膨らませる機会をもらえます。
本講演の次は、SREの未来はどんなだろうと思わされる、SRE "next"にふさわしい基調講演を聴くことができました。

[C1] 絶え間なく変化するメルカリ・メルペイにおけるSREの組織と成長

本セッションは後方で立ち見となりました。外のブースの声が近く、ドアも解放状態でしたので、講演内容全てを聞きとることができませんでした。少し残念。
高木さんパートのスライド「1人目のSRE時代」のくだりはリアリティがあります。1人でSREを立ち上げて手を動かし、最初はtoilも受け入れてできることは全部やる。しんどい1人時代から数年かけて複数チームにするまでの過程を知れることは、これからSREを導入していこうとする組織に大きな学びとなります。

[A2] パフォーマンスを最大化するための SRE のオンボーディング事例

中途採用で入社したSREが新しい環境で成功するために実施したオンボーディング事例を紹介されました。
まず参考にしたいと感じたのは、オンボーディングのゴールはどこかをきっちりと設定して一連を仕組み化されている点です。メルカリさんのSREチームでは、オンボーディングのゴールを「オンコールを担当できる状態になること」としています。
そのための技術知識の習得は、newbie用のチャンネルを作ったり演習問題をこなすなど充実した環境整備がされているようでした。しかしオンコール対応時は技術知識だけでは足りません。オンボーディングに必要な追加項目としてドメイン知識や組織詳細の情報共有を挙げられておりなるほどなあと感じました。
ドメイン知識や組織間コミュニケーションは時間をかけて慣れるしかなく、慣れるまでの時間も人によりばらつきが大きいです。できる限りばらつきを小さく早期にスムースにキャッチアップできるために、メルカリさんでは以下の取り組みを行ない効果を得ているとのことでした。

今後自分が所属している組織でも参考にできる具体例をたくさん拝聴できました。

[A3] freee のエンジニアは障害から何を学び、どう改善しているのか?

いや〜1から10まで勉強になりました。発表最初に「エンジニアとして恥ずかしいことも全部話すつもりできました」とおっしゃった通り、失敗体験含めた事例詳細と改善策を洗いざらい公開してくださいました。
「失敗して攻めよう」が根付いているfreeeさんの文化は素晴らしいと思いました。失敗や障害の一つひとつから学んで、仕組みづくりや対応フローの整備、ポストモーテムの文化醸成など、全社で組織的に改善を進められている姿勢に見習うことは多いです。
幅広く参考にできる具体的な事例がたくさんです。定期的にスライドを目にして、自組織でも取り入れていきたいです。

[A4] 日経電子版SREチーム立ち上げ中

日本経済新聞社さんSREチームの現状紹介も大変興味深くリアルな内容でした。日経電子版のシステムは巨大なだけではなく、さらに内製と外注システムが入り混る複雑な構造で、普段の技術導入やシステム開発も相当たいへんなのではないか?と想像できます。会社として今後電子版に力を入れるためSREチームを立ち上げられたそうですが、当初はSREに求めるスキル保持者はいなかったそうです。「サービスレベルがバラバラ・計測されていない・目標がない」課題は明確だが、チーム全員が兼務で、何から手をつければいいのやらという状況でしたとのお話から、これまでのご苦労が身にしみて感じました。
社内のエンジニアやマネージャに対して、システムの安定性担保は大事ですよねという啓蒙からスタートし、少しずつ理解者協力者を増やしながら、障害対応フローを整備やDevOpsを進められています。次はSLI/SLOの設定・計測にチャレンジされるとのこと、今なおSREチームの立ち上げに挑まれている発表に力をもらいました。
自組織の参考にぜひさせてもらいたいです。

ZOZO MLOps のチームリーディングとSRE(Engineering)

そのっつさんが現職でEM、TLとしてどのようにチームマネジメントをやっているかの紹介でした。マネジメント内容を技術イベントで話すことは滅多にないとのことで、そのっつさんのマネジメント手法が伺える貴重なお話でした。こんなマネージャがいるチームにjoinしたいと思われた方も多いのではないでしょうか。
発表内で特に印象に残った項目は以下です。

  • チーム方向性を定義
    • チームの軸(目標)がぶれないようにちゃんと定義する
      • 意義目標(業務の意味付け)、成果目標(実務ベースの目標)、行動目標(個々人)
  • ルールより文化
    • 意識しなくてもできる当たり前にするように、日々言葉にして伝える・話すことを重視
      • 例「エンジニアはコードがあれば読むのは当たり前」「技術ドキュメントを書くのは当たり前」「やってみてダメなら変えればいい」「技術で殴ろう(細部を追わないと技術で解決できない)」など

お話の端々から、マネジメントのあり方を日々学ばれていることが垣間見えて刺激を受けました。

SRE Practices in Mercari Microservices

メルカリさんのプラットフォームチームTLとして、SREをどう実践しているか「SLI/SLO」「オンコール」「トイル」3点を軸に紹介されました。
deeeeetさんの発表はたいへん綺麗かつ端的に体系化されていて、スライドを見てもそのことが明らかです。加えてSREを実践するための組織背景には、数多くの書籍や事例からdeeetさんが学ばれた理論や手法を導入されており、引き出しの多さに圧倒されます。

メルカリさんのオンコール対応はSREやプラットフォームチームだけじゃなく、サービスチームも担当するというのは新たな知見でした。オンコール対応のシステム区分やオンコール時にどんな判断がなされているかの紹介もあり勉強になりました。
メルカリさんの技術組織力はさすがだなと感じます。「お願いされる」「お願いする」チーム関係をなるだけ排除し、全体最適を重視してできる限り組織的な判断で決めがなされているようでした。組織やチーム・人数が多くなると全体最適がしづらくなります。メルカリさんは、常に新たな技術やノウハウを柔軟に取り込み、仕組み作りと運用を重視して日々のシステム開発を行われていることが伝わりました。

むすび

本イベントに参加できてよかったです。技術組織に所属しているがエンジニアじゃなくSREでもない自分にも得るものが多くありました。
私はいま経営学と技術組織デザインについて書籍・資料と自組織から学んでいる最中です。他社事例を知る機会が少ないなか、これまではSREconの動画を見たりSRE皆さんが語られる「人と技術と組織」を統合したリアルなお話から学んできました。今回は一度に研究者の解釈や複数企業の事例を伺うことができてうれしい情報の洪水でした。
【SRE Next 2020】発表資料まとめ - Qiita 今後このまとめを繰り返し参考にさせてもらうでしょう。

SRE NEXT 2020では、運営メンバ皆さまそして参加者皆さんの親切に救われました。
一人で席についていた時、SREの前職同僚が「一人ですか、自分が解説しましょう」とフォローしてくださったのはうれしかったです。「イベント運営は、一人で来ている参加者や、専門分野外から新しく参加してくれた人を大切にしないといけない。今回自分は運営じゃないけど技術イベントに育ててもらった身としてSREとして協力したい」とお話いただき、自分が知るSRE 皆さんのやさしさをここでも感じることができました。運営メンバ皆さまのサポートも行き届いていて助かりました。
別分野の初心者が一人でイベントに参加するのは勇気がいりますが、そこにいるひとの親切と温かさの後押しがあればえいっと越境することができるように感じます。なので今回のように、お隣の領域で安心して参加や活動ができる経験を自分内に増やしていきたいです。最近はぼちぼちGoogle - Site Reliability Engineeringを訳しはじめています。本職SREの方のサポートが必要になりますが仕上げられるといいな。

参加からはや2週間が経過し、やっとレポートをまとめることができました。
少し遅くなりましたが、SRE NEXT 2020運営皆さま、講演者皆さま、そして参加者皆さまに感謝をお伝えしたいです。ありがとうございました。

参加記録を残すだけに留まらず、ゆくゆくは自分もどこかでお話ができるようになれるといいなぁと妄想しはじめています。