好奇心の足跡

飽きっぽくすぐ他のことをしてしまうので、忘れないため・形にして頭に残すための備忘録。

Infra Study Meetup #3 イベント参加レポート

イベントレポート SRE

2020年6月17日に開催された、Infra Study Meetup #3 を拝聴しました。

forkwell.connpass.com

今回のテーマは「SREのこれまでとこれから」。オンライン開催だし、後から配信もあってとっても良い。
自分のtweetまとめみたいになっちゃったけど、折角参加できたし面白かったのでまとめ。

挨拶

頭からじっくり聞けたので、3回目にしてようやくこの勉強会の成り立ちみたいなのを知った。コロナ禍で、やっぱりオンサイトの勉強会は激減、エンジニアの学ぶ場がとても減ってしまっていることから、Forkwellさんが声がけしてスポンサー、講師を募りつつ始めたそうな。

基調講演「SREの文化と組織」

株式会社はてな SRE 古川 雅大氏

speakerdeck.com

最初は、はてなのSRE、古川さんによる、「SREの文化と組織」。「Site Reliability Engineering」という「分野」についてのお話。

これまでは、一企業(google)のプラクティスだったものが、Webサービス事業者へのプラクティスになってきた。今はそれから「研究分野」になってきつつある、とのこと。

これからは、

  • googleの模倣ではなく企業や組織事に合った、SREの実践・実装の登場
  • セキュリティ分野など、他の分野との連携
  • 産業と研究みたいに、バラバラだったものが融合して新たな手法の発見があるのでは

ということでした。上2つは既に足を踏み入れているところも多そう。3つ目はどんな話だろう。

ここで出てきた、SREの活動を自動車に例える話。なるほどーと思った。
自動車も、最初は便利に使える早く移動できるもの、だったのが、動くことが当たり前になって、皆が使ってみると事故が起こったりして、そこで安全性・信頼性について考えるようになった。Webサービス業界におけるインフラもこれと同じで、はじめはとにかく「動く」ことが目的だったが、今では動く状態に持っていくコストが下がり、余力が出てきた。ここに来て信頼性・セキュリティ的な話が要約できるようになった。

次はSREをどうやって導入するか、という話。
組織にSREを導入することを、大きな機能を実装すると考えてみる、とここでもたとえ話。システムに変更（SRE導入）を加えると、信頼性が下がることに注意して、段階的に入れていきましょう、とのこと。いきなり頑張りすぎないこと。

また、システムを入れ替えるには、旧システムを知ることが必要。組織の規模や、誰に話を通すべきか、など。

まとめると、組織の文化に合わせて、少しずつ、相手を知った上でうまく進めていきましょうってことだ。これ大事。そしてとても難しい。SREについて説明するときも、相手に合わせて話す内容を変えないと伝わらない。説明した後にアンケートをとって改善していくの良いな。

コードもそこまで得意じゃなくても、信頼性に関わることであれば自分の能力を鍛えていこう、という意思の変換。信頼性を担保するのにソフトウェアエンジニアリングが必要なら、じゃ、やるか！という心構えでいると、なりやすいんじゃない？とのこと。
ほか、SREになるのはステップアップなのか？みたいな議論もされていました。

ガチ関西勢からツッコミが来るかとヒヤヒヤしたエセ関西弁だったけど、こういうことだと思う。

LT1「Incident Response」

LT1つ目は、メルペイの @tjun さんより「Incident Response」

speakerdeck.com

インシデントへの事前準備、起きたと きの対応など、よくまとまっている今日の発表資料はこちら！！！これはとても良い資料！

何が起きたら、何が損なわれたらインシデントなのか、深刻度をどう定義するか、更にその深刻度(Severity)がいくつ以上だったら即刻対応なのか、CTO/CEOまで連絡を上げるのか、みたいなところも決めておく必要があるよね。連絡先も、インシデントが起こってからいちいち調べてたら遅くなる原因なので、予めリストを用意しておくべき。
更に、役割を決めておくことも大事。ドウイウ役割の人が必要なのか。もちろん問題の切り分け・原因究明・解決に向けたactionを取る人はとても重要なんだけど、皆でこれをやっているとどこにも報告が上がらない。ちゃんと定刻に然るべきところにレポートを上げる役割も必要。個人的には、原因究明班と解決班もちゃんと分けたほうが良いと思っている。人的リソースに余裕があれば、だけど。余裕なければとにかく応急処置でもいいから解決班に全振りかな。

インシデントが発生したときのコミュニケーションの場を作っておくのも大事とのこと。あとは発表内容にあったか忘れたけど、情報の取りまとめの場と、チケットなどアサイン・TODOを明確に管理できる場も用意しておいたほうが良いと思う。「slackに集合！」は何年も前からやってるけど、コロナ下のリモートワーク環境でも問題なく使えて良さそう。

tjun さん、前の職場が超近かったのもあってか「あー、あるあるー」「それ決めとかなきゃだよねー」「めっちゃわかるー」みたいな内容が多かった💡 それとも皆同じようなこと考えて決めてたり、みんなで解析しちゃって報告が疎かになった経験があるのだろうか。あるあるな気もするな。

こんなのもあるみたい。

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

LT2つ目はAVILENの大川さんによる「AIスタートアップにおけるSRE」。

これ、後半は自分の体験談だったんですけど、大川さんが喋ったみたいになってしまった…。

スタートアップって、勝手なイメージだけど「全員開発・Deployできる」みたいなところが多そう。だけど、ここにAI人材、データサイエンティストが入ってきて、インフラちょっとよくわかんないし、やるつもりもないよ、みたいな感じだと、どうしてもシステムに変更を加える人と、Deployして動作を確認する人が別になってしまう。

インフラメンバーもデータサイエンティストのいじる領域はなかなか手が出せず、すると、「なんかコケたんですけど、どこ変更したんですか？」みたいな無駄なコミュニケーションが多発して、皆に不幸な結果に。だから、誰でもDeploy&Test出来る環境ってとても大事だなーと。

データが絡んでくると自動Deploy,Testってとても大変＆複雑になりがちだと思うので、具体的にどうやってるかお聞きしてみたいなぁ。ｌ

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

LT3つ目は、ぐりもお。氏による「Production Readyと開発プロセス改善」

speakerdeck.com

早期エンゲージメントモデルとは、早い段階からSREが開発に関わっていくこと。企画・設計・開発・運用全てのプロセスにSREが関わってレビューをする。
これを導入してみた話。

導入したことによって、設計漏れが起こらない、運用引き渡しがスムーズといったメリットがあったそうです。

これは以前、私達も取り組もうと思って、前に自分たちの開発プロセスに取り入れたらどうなるかを検討してみました。SREという役割・チームが無いにしても、SRE的視点で各段階でレビューを行うのはとても効果的だと思う。

ゆるく振り返り会

この「なんちゃってSRE」、「名前だけSRE」って、「名前だけ変えてSREって言ってんじゃないよ」みたいな嘲笑を感じてあまり好きでない。というのもきっと、自分がやろうとしたときも、こういうことを言って腰を折られるのが嫌だったからだろうなぁと思う。

最初から「これぞ完璧なSREの取り組みだ！」みたに始める所なんて殆どないと思うし、基調講演でもあったとおり、組織に合わせて徐々にSREの考え方を取り入れていくスタイルが多いんじゃないかなと思う。だから、「気づいたらSREっぽい事してたからSRE部隊を作ってみました」っていうパターンじゃない場合、「SREの考え方を取り入れていくぞ！」っていう段階で、まずは名前を変えてみたり、とりあえず作ってみたりということはあると思うし、戦略としてそんなに間違ってないんじゃないかな、と思う。

だから、このゆるく振り返り会で沢山出てきた、「ちゃんとSREについて考える」というのを意識して続けられれば、入り口は既存組織の名前を変えただけだろうが、気にする必要はないという雰囲気はとても良かったなぁと思う。

逆にSREについてちゃんと考える人、中心になって考えられる人がいないと回らないよおね、という話も。こういう人をどうやって引っ張ってくるのか、育てていくのかはとても難しい。たまたまそういう人がいたり、入ってきてくれたら良いんだけど。

ということで、そういう人がいる・可能性がある人がいた場合に、企業文化って結構大事だよね、という話になった。ちゃんと中心になって回そうとしてる人を応援できる風土がないと、人は育たないし他に移ってしまう。

他、お金の視点、顧客の視点も大事だよね、という話も。SLI/SLOだけじゃなく、顧客とすり合わせて決めるSLAが大事。

顧客からしてみたら、稼働率が100%に近いほうが良いに決まってる。こういう議論に慣れていない顧客だと、普通に「100%で」って言ってくる可能性があるので、どうやったらこの100%ってめっちゃお金かかるんですよ、そんな信頼性いります？みたいな話をうまく伝えるかについて、一生懸命考えたことがあったなぁと思い出したのでした。
そもそも現場で使われる医療系のシステムと、エンタメ系のシステム、求められる信頼性って違うよね、とか。大体98.5%の稼働率があれば、年間のダウンタイムはこれくらいですよ、って表にしてみたりとか。100%に近づけるためには深夜対応メンバーの増強が必要なので、人的コストもコレくらい跳ね上がりますよ、とか。いろんな視点でちゃんと説明することを試みた記憶。

最後に。

確かに、今回の勉強会のハッシュタグを追っているとSREって全知全能、オールジャンルデキル人なんですか！？、みたいな感想がちらほらあって気になっていた。そこに基調講演の古川さんからこのコメントがあって、すごく良いなぁと思った。
これに対して、ジェネラリストの集団っていうイメージ、という反応もいくつか見られ、スーパーマンだけがSREを名乗っていいってわけじゃないし、徐々に守備範囲を広げていけたら良いんだなと感じられてとても良かったです。

今回は組織・人的な話がメインということでSREについて見つめ直す良い機会になったのではと思います。

次の第４回は、インフラの面白い技術とこれから。

forkwell.connpass.com

紹介文が面白いので読んでみて！とのこと。

今回は、私が比較的精通している分野であるコンテナの要素技術やミドルウェアを題材に、中身を「深追いする」方法や技術について少しでもお話しできればと思います。

とあります。楽しみ！