SRE Magazine発刊の話
こんにちは、エンジニアの博崎です。
こんにちは、エンジニアの三つ永です。
ゆるテクは、三つ永と博崎が、ゆるく技術の話をするポッドキャストです。よろしくお願いします。
よろしくお願いします。
はい、ではですね。
はい。
早速、本題なんですが。
はい、お願いします。
今日は、時事ネタです。
おっ、なんですか?
えっと、今日がこれ、4月2日なんですけど。
はいはい。
昨日ですね。
はい。
Xを見ていたところ、SRE Magazineというものが発刊されたというツイートを見まして。
ついに。
はい、作成されたという方のツイートで知りました。
何か、いつだったか覚えてないですけど、Xに、あれ、記事を募集するポストとかありましたよね。
でしたでした。
ですよね、なんか応援する意味を込めて、いいねとリツイートだけはしたっていうのをすごい覚えてます。
えらい、えらい。
あ、リツイートじゃないか、リポストしたのを覚えてます。
そうそう、で、その方が初産、ミクシーでSREをされている方ですね。
で、この方が、昨日第1号発刊しましたって言うんで、早速読んでみて、すごいなと思って。
実際に多分1ヶ月もなかったんじゃないかな、準備してて、ちゃんとしたサイトになっててすごいなって思って見てましたけど。
機構の募集とかもあるんですね。問い合わせ、RSS。
そうそう、これ機構なんですよね。
なので、記事を集める必要があるんですよね。
ですね、ですね。
第1号の関東原って書士さんが書かれてるんですけど、何で始めたかとか、なかなかすごいことが書いてあっていいなと思いました。
それまだ読んでないのがすごい、後ですぐ読もう。
SRE関連の記事をまとめて紹介みたいな、そのフォーマットだけ見ると、英語ですけどSRE Weeklyってあるじゃないですか。
ありますね、はい。
あれも自分も見てるんですけど、こっちはニュースレターなんで、配信者の方がこれ記事を自分で集めてキュレーションしてるんですよね。
うんうん。
紹介したりとか。
はい。
なんですけど、このSREマガジンの方は、これのために書いてもらってるという感じが多分だいぶ違うところですよね。
あー、確かに。確かに確かに。
もちろん日本語記事っていうのも大事なポイントですよね。ないから作ったという話なんで。
結構、もちろん英語の記事とかも読みますけど、そもそもSREっていう文脈がもともと難しいのにプラスアルファして英語だしでだいぶ読みづらいところはあったりしますもんね。
そうですよね。
なのですごいこういうのは出てきたのはとても喜ばしい。おめでたいという感じですね。
確かに記念すべき第一号ですもんね。今回が。
そうですね。すごいおめでとうございますという感じですね。
おめでとうございます。
ここで言っても届くのかな。聞いてもらったら届くかもしれないけど。
うんうんうん。
フィーチャーフラグと緊急レバーの実装
第1号なんですけど、どうですか。タイトルとか見て。
そうですね。気になるのはたくさんあるんですが、割と2人でシンプルに話が盛り上がりそうなやつで言うと、3番目って言ってもあれか。非常時の可用性をフィーチャーフラグで保つアイデア。
そうですね。タイトルが面白くて、これ自分も開いてみたんですけど、AWSにWell-Architected Frameworkっていうのがあるんですけど、それの1つの信頼性の柱。柱がいくつかあるんですよ、Well-Architected Frameworkって。
そうなんですね。
そのうちの1つの緊急レバーっていうのの説明があって、それ実装するのにフィーチャーフラグを使いましょうみたいな。使ったらどうかなみたいな話かな。
なるほど。よくフィーチャーフラグとかで言うと、4証言とか4種類ぐらいに分けられるとかっていうのが昔ソートワークスの記事であったと思うんですけど、この記事で書かれてるのって多分そこで言うOpsフラグみたいな、何か障害があった時とかアクセス型があった時にそれを緩和させるスイッチみたいな使い方をしてるっていう紹介みたいなイメージであってます?
そう、自分も思いました。即座にできるっていうのが大事ですからね。
こういうのってすごい思うんですけど、フィーチャーフラグを使ってるプロダクトって結構多かったりするのかなって思ってたりしてて。そんなことなかったらごめんなさいなんですけど。何が言いたいかっていうと、この緊急レバーの下ろしやすさって多分すごく大事なんだろうなって思ったんですよ。
そうですね。機能が使えてたものが使えなくなるので、ちょっと気楽には落とせないですよね。
そう、ユーザーにあたる影響によって気楽に落とせないっていう落としやすさもあると思いましたし、何かたまにあるのって、とはいえこのレバーを引けるのってエンジニア専門家じゃないと引けないとかもあったりするのかなって思ってて。
この辺がもしかすると本来は第一歩を受けた別にエンジニアじゃない方でも、誰かが判断したらその人が下ろせるぐらいライトにプラットフォームとして提供できてると強いんだろうなって思ったりしました。
そうですね。どこかしらのURLみたいなダッシュボードみたいなものがあって、アクセスしてポチで。
そうそう。
そのぐらい簡単じゃないと。今話しながら思ったんですけど、逆にエンジニアが判断して下ろせるようなやつって機械的な指標に基づいてるとかが多い気がしていて。
確かにありえそう。
この値がこれ以上だからとかで判断するパターンが多い気が今勝手にしてて、そこで下ろすのであればもはや自動でいい気がするんですよね。
確かにメトリックス取って敷地決めてるんだからってことですもんね。
人間の判断というかウェットなというか、この言葉はあれですけどビジネス寄りというかの人が判断するのがやっぱり主導だと思うんで。
そうですね。確かに。
そういう時のためにはさっき三沢さんが言ったみたいに簡単にできてないとダメでしょうね。
なんかそれが例えばこれはデータベースをメンテナンスしないとダメなんだってなって、ボタンにハードル高くなるし。
そうですね。つらいな。
とかとかありますよね。あとはこういうのってちょっと脱線しちゃうんですけど、きっとうまく設計しないとフラグの乱立って避けられないんだろうなって感じしますよね。
しますよね。これを下ろしたら何が起こるんだっけみたいな。
起こるんだっけってなりそう。
そうそうそう。
そうですね。
っていうのが気になったのと、私今のその記事紹介していただいた中で初めてAWSのWell-Architected Frameworkって言葉知ったんで、後で調べてみようって思いましたね。
そうですね。
というのが気になったのと、もう一つ気になったのが、複数のウェブサービスを運用するSREチーム立ち上げの背景っていう記事はちょっと気になってます。タイトルからして。
これもろにみつながさんの境遇というか、今興味ありそうな話題な気がしますけど。
ですです。
これは複数サービスの運用における課題、ナレッジの共有不足とか。
横断チームみたいな感じで、各サービスにはEmbedded SREで、プラットフォームは横断でいるけど、それをした結果ちょっとあの干渉範囲というか広すぎるというかになって、システムのアラートを取りこぼすケースが増えたっていう風に課題が書いてありますね。
SREマガジンの第1号
なるほど、風呂敷が広がりすぎて見切れなくなったってことですね。
みたいなことなのかな。
でも、プラットフォームとEmbeddedをそれぞれ入れてるっていうのは、ある意味おさほ通りって言うとちょっとあれですけど、よく紹介されるパターンですよね。
取り組みとしては、監視のダッシュボード開発とかに力を入れてるって感じなんですね。
そうですね、そこでこれは取りこぼしたとか時系列で何が起きていたかトレースしづらいってなってるけど、対応してるのはプラットフォームSREのほうなのかな。
なんとなくプラットフォームSREで難しいことっていうか、色々調べるもののそれをちゃんと各サービスのプロダクトチームに落とし込むのはEmbeddedの仕事みたいな感じなんですかね。
色々難しいんだろうな。
この取り組み自体って素晴らしいし、多分自分たちも同じことやってるんだろうなって思うんですけど、最近常々思うのは、SREの文化とか視点を入れていくってなった時に、
前段階としてサービス開発チームの文化にDevOpsのDevの部分は少なくとも成り立ってないと、急にSREっていう文脈が来ても対応できないんじゃないかって気持ちを抱くようになりました。
今そういう場面に出くわしてるとかじゃなくて、ふと考えたっていうことを話してるだけなんですけど、例えばSREとかを知ってて、そういう経験も積んだことがあって、やったほうがいいって分かってる人が、
じゃあこれからそういうDevOpsの、まずDevのフェーズをしっかり立ち上げていこうっていうチームに入った時に、どういうふうに広げていくのがいいんだろうなっていうのをちょっと考えちゃいますね。
監視が大事なんだって最初に言われても、おおってなっちゃいそうじゃないですか。
そうですね。望ましいというか、こういう動きをすればいいんだなっていうのが目で見えればいいですけどね。
ですね。かつそれって大事なのって監視を役割として特定の人が担うっていうより、監視のスキルとしてチームがケイパビリティとして持っていかなきゃいけないはずじゃないですか。
そうですね。ロールじゃなくてスキルですからね。
ロールじゃなくてスキルっていうところで、それを醸成させていくのに苦労した記事とかが今後出てくるんじゃないかなって思ってたりします。
そうですね。もうSREっていう触手はあんまりなくなっていってとかかもしれないですね。
そういうのができるようになってきたらそうそうですよね、なんとなく。
だからこのSREマガジン全体の話でいくと、第1号は結構幅広いというかなネタな感じしますね。
そうですね。今後もしかすると何か特定のものにフォーカスしたパターンが出てくるかもしれないしって感じですよね。
そうですね。入門もあったし。
入門書のやつか。
入門書のやつか。
そうそう。あるし、セキュリティーもあるしCMのことが書かれてるんで、セキュリティーのやつだし。
ADR、設計の話。これどちらかというと開発文脈で出ることが多い気はしてるんですけど、結構広いなと思って見てました。
広いですね。そして最初のババさんが書かれてるSRE入門とSRE入門の入門に聞く書籍を今チラッと開いたんですけど、いい書籍ばかり紹介されてるな、さすがだなって思いました。
そうですね。ザゴールとチームギークとかあるところがエモいですね。
ザゴールって黄色いやつでしたっけ?ちょっと忘れちゃったけど。
エモいですね、確かにな。
でもこのウーダループの本って読んだことないな。ウーダループ専門の本があるんだ。
これ本なんですか?記事?
記事なのかな?
本だ。
本ですね。
私もこれは知らなかったですね。読んでみよう。
ウーダループっていろんな記事とかでこういうもんだよっていう紹介読んだだけなんで。
はいはい。
ちゃんとというか、それについての書籍は確かに読んだことないなと思いました。
確かになるほどな。
初回だから頑張った記事が集まったのかわかんないですけど、このクオリティで2号3号っていくのなかなか書く人もプレッシャーある感じするな。
ですね。我々も経験積んだらこういうところで貢献できるといいんですけどね。
そうですね。応援していきたいですね。
ネタがあれば寄稿できればいいですが、こういうことを言ってる時点でダメなんでしょうけど、ネタは作るんだよみたいな感じだと思うんですけどね。
確かに。あそこにネタを提供しようというモチベーションで仕事をやると何か発見があるかもしれないですからね。
そうですね。
なるほど。
もしこれを聞いている方でSREの方がいらっしゃったら頑張ってみるといいんじゃないでしょうか。
ちゃんと収録公開するときにURL貼っておきましょうね。
そうですね。すごい他人頼りな金持ちになってしまった。
今日はそんなとこですかね。
はい。
では、今回はSREマガジンについて話しました。
感想などはハッシュユルティックをつけてポストお願いします。
Googleフォームからも送れます。
今日はありがとうございました。
ありがとうございました。
