This page looks best with JavaScript enabled

[レポート]Infra Study Meetup #3「SREのこれまでとこれから」

 ·   ·  ☕ 7 min read

2020年6月16日のInfra Study Meetup #3「SREのこれまでとこれから」にオンライン参加しました。参加者人数が毎回1000人以上となるのはすごいですよね。

今回も天神放送局様によるライブ配信代行で、ストレスなく視聴することができました。
配信環境のtweetありましたが、テレビ局かな？と思うぐらいの凄さを感じますよね。


また、まつもとりーさんの司会としてのファシリテーションが素晴らしいこともあり、最近は実家のような安心感を感じるようになりました。

テーマ

第3回「SREのこれまでとこれから」 古川 雅大氏（@yoyogidesaiz）

動画

https://www.youtube.com/watch?v=g_oNjQ_G4aw

基調講演

古川 雅大氏による基調講演です。

SREは一般化、体系化が進み、これからは企業や組織毎にあった実践、実装が登場するとのこと。

SREとはソフトウェアエンジニアに運用チームの設計を依頼したときに出来上がるものと言われています。紐解いていくとSREはシステムの信頼性に焦点を当てることです。信頼性のあるWebサービスを提供するために、ビジネス上の条件を考慮した、人と機械のシステムを設計、実装、運用の課題解決する必要があります。そのためにはプラクティスを真似るだけではなく、思想、哲学、文化を理解し考えることが重要です。

技術だけにフォーカスすると1人で全てできることを求められるため、SREの文化を組織毎に最適化していく必要があると理解できました。

質疑応答

基調講演終了後の気になった質疑応答をまとめました。

SREで取り組むのをやめたこと

個人的にやめたことはある。昔は割れ窓をちゃんと潰す、アラートを潰すという考えがあったけど、優先度的に後回しにしている。優先度は信頼性で決めている。Toilを50%以下と決めて、改善に力を回すという考え方に変えたことで、視座が上がってプロダクト全体を見るようになった。

インフラ・運用エンジニアがSREにステップアップするアプローチ

Googleのシステムエンジニアリングとは何かを読んで欲しい。キャリアに対するラダー（ハシゴ）はない。だから難しい。古川氏はスイッチとネットワークとかから上がってきたけど、学ぶことの境目を作らないのが重要。信頼性にフォーカスすることをなんでも学ぶのが重要。コードも苦手だと言っても信頼性のかかるものであれば、今までの技術に固執せずやってみる姿勢が大事。チームだと違うけど個人だとそう言った考えが大事。

SREとインフラエンジニアを明確に分ける？

分ける必要はない、ソフトよりのSREがいても全然いい。
SREとして例えばDBの範疇だとかを業務範囲内じゃないからといって学習をやめない方がいい。

個別プロダクト組織にSREが存在して、複数プロダクトをまたぐSREのようなチームはあるか？

はてながそう。メルカリもそう。
メルカリのdeeeetさんの発表を見て欲しい。
プロダクトに直接関与するSLI、SLOを設定するのは開発チーム内のSREが見る必要がある。
横断的に参加しているSREはインフラ・プラットフォームエンジニアだけでなく、アプリとかも欲しいけど難しいから、横断的に見れるSREが必要。

ちなみにdeeeetさんの資料をtweetしてくださった方がいたので張っておきます。


SREの日々の仕事は？

エンジニアリングマネージャやテックリードに近いので、SREを今後どうするかを考えている。
またコンテナ化等によってメトリクスやログが変わることを一緒に考え、オブザーバビリティを助けることが多い。

LT1「Incident Response」

tjun氏(@tjun)によるインシデント対応のお話です。
インシデントレスポンスはSREをやるなら避けられないので、組織的な仕組み作りが必要とのこと。
ちなみに、tjun氏は発表前日のAM2時にインシデントで叩き起こされたとのことでした。


tweetでの質問回答があったので張っておきます。
また、Incident Responseに対する取り組みをtweetしている方もいたので、そちらも張っておきます。

LT2「AIスタートアップにおけるSRE」

大川 遥平氏(@wxyohei11)によるスタートアップでのSREのお話です。
ソフトウェアに明るくないデータサイエンティストにも簡単にデプロイできるように、自動化スキームを作った話が印象的でした。

舟木 類佳氏(@ruka_funaki)による契約書をAIで自動レビューするサービスのお話です。
リスク分析を機会的に評価できるのはすごいと思いました。

LT3「Production Readyと開発プロセス改善」

ぐりもお。氏(@grim0h)によるProduction Readyを導入してみたお話です。
早期エンゲージメントモデル導入で、早い段階から開発のライフサイクルに関わり、設計漏れをなくし、スムーズなレビューや運用引き渡しが可能になったそうです。


また登壇者自身のLT記事があったので追記しました。

ゆるく振り返り会

枠の時間が拡張されたので、前回より長めの振り返り会となりました。
気になった振り返りをいくつかピックアップしました。

なんちゃってSREをどう思うか

SREやってた人がやめたので、せっかくやるのでラベルではなく考えたアンサーを今回の発表にまとめた。

古川氏がSREになった時のお話

SREを任命された時、CTOの権限委譲してもらわないと価値を発揮できないと相談。
DevOpsはできていた。非難しない、挑戦できるといった企業文化が積み上げられていた。
中心人物が必要であれば、周りの人たちがサポートする文化ができていないと、サービスの変化を安定させて移行することは難しい

信頼性については、客から全て網羅して問題がないことを提示してくださいをどう技術で殴るか？

信頼性100％は報酬の面で割に合わない。
お客様との信頼関係が大事にし、SLAをベースに議論して行った方が良い。

信頼性を99.9、99.99と上がっていくとコストは指数関数的に上がっていく。
将来性を考えると信頼を売りにするとビジネスの伸び代は少ない。
システムの将来性を考えるのであれば、そういった契約をしないこと。

SREはスーパーマンじゃないとできないのか

付け焼き刃を認識した上で、スペシャリストに相談し徐々にやっていくのが大事。

まとめ

今回は技術というよりは、考えかたに対するアプローチの話がメインだったので中々難しかったです。ただ、SREの本では得られない知見や取り組みを知ることができたのは、とても大きいことだと感じました。

次回の勉強会は7月29日となります。
Infra Study Meetup #4「インフラの面白い技術とこれから」

また、姉妹勉強会として7月15日にデータ分析基盤の勉強会も企画されたので、こちらにも参加しようと思います。
Data Engineering Study #1「DWH・BIのこれまでとこれから」

Share on

comments powered by Disqus

See Also