この番組は駆け出しエンジニアの順平と中級エンジニアのカイチ ノリが送る駆け出しエンジニアを中級エンジニアにレベルアップさせるラジオでございます

はいさあということで今日はやってまいりました 何がですか私がですあなたが来ましたのりさんが来ましたそうです僕がただ曖昧だったことを調べてアウトプットする回でございます いや素晴らしいもうねこのポッドキャストを我々の成長のきっかけにしていきたいそうですはいということで今日は別にこれを知ったからといって何かがいいことがあるかどうかはわかんないけど 知っておいたら

世間話に入りやすくなるんじゃないかなという知らないと恥ずかしかったりします?ちょっと恥ずかしいかなじゃあ聞いときたいわ結構恥ずかしいと思うエスカレーターでお尻丸ごと出てるくらい恥ずかしい結構ですねそれはそれ結構だわ今日解説するキーワードはこちらでございますSRE

時間止まった?2個か3個出てくるのかなと思ったらSREですねSREですSREエンジニアだとかSREエンジニアとは言わないか言わないですね頭痛が痛いですねSREチームとか

弊社では今絶賛SREチームの人を募集してますみたいなうんうんよく見るじゃないですか求人とかで見る見るじゃあじゅんぺいくんに問題ですはいSREどんなイメージですかイメージ問題としてイメージを問う一言で言うと効率化部隊

なるほどねカイチ君は一言で言うとサービスを継続的に提供し続けるためのことをとにかくやる人たちなるほどね

僕これインフラをかっこよく言っただけだと思ってたんですよ 三者三様でしたねはいなんで調べてみましたでも絶対そんなわけないだろうっていう 急にねそのなんかこっちの言い方の方がいいからこの言い方浸透させようなわけないだろうなわけないはいだってジーンズデニム問題と同じだよねそれ ジーンズとデニムはそうなんですかちなみにあ違う違うわえっとジーパン

昔ジーパンとしか言ってなかったのがジーンズになってデニムになってたじゃないですかそうなんですねそのイメージあるそれはそうなのでも物は変わってないじゃないですか素人にはそういう風に見えますねデニムは生地だよっていう反論をよく聞きますけどズボンなのかパンツなのかボトムスなのかみたいなあれも変わってないですよね変わってないはず

ズボンみたいな好きですよね僕ズボンそう俺もねそうなんです響きがおもろい誰もトラウザーとは言わないですよねあんまり知らないトラウザーあれ英語でトラウザーじゃなかったっけトラウザーはイギリス英語でメンズのズボンのみを指して使われるとじゃあほぼ合ってるちょっとあれだけどちょっとジェンダーレスな感じじゃないけどそうですねなんか多分消滅する言い回しでしょうねこれそうだなうんうん

いいんですよこんなもんはSREねSREはインフラを言い換えてなんかかっこよくしたやつに見えていたというかそういう気持ちで募集してる企業あるんじゃないかと思っていたなんかそう言っとけばかっこいいやろ人来るやろみたいなバズワードっちゃバズワードですからねだったんですけど調べましたよ

調べたというか多分このSREっていう概念が広まったきっかけの本がオライリーのサイトリライアビリティエンジニアリングっていう本だと思うんですよ厚くて分厚い青い系のやつのワニのやつ僕それねブックオフで見つけてすっごい綺麗な状態だったんで買っちゃったことがあって買っちゃったんですねすごい前ですよでもこれそれ以来読んでなかったんですよ1ページも1文字も

読みました1章だけ1章に書いてますよね1章に全部書いてあったらどんなものかっていうのは分かる分かるその中のさらに具体的なやつがマジで3文形式でいっぱい載ってるみたいな3文って合ってるかこれ3文分かんなくなったんで訂正します雑に書いてる訂正してよいのそれでひまプロあるあるというか僕の中あるあるなんですけど1章がいっちゃうエピソードにしやすい

わかるちなみにサイトリリアSREの本にも今回のやつは論文形式で章ごとに区切ってるんでどっからでも読めますって書いてましたただ2章3章は読んでねって書いてましたなのであとは結構順番関係なくより深掘りしてるみたいなやつで今日はその第1章を救っていこうかなという感じでございますありがとうございますまずこのサイトリリアSRE

SREはいこれGoogle発祥の概念ですねGoogleさんは何でも発祥してますねなんかすごいですよねメッカ

勝手に言ってるだけじゃないですかGoogleがでもみんながGoogle信じすぎて誕生したんですね言葉がすごいよね振り回されてるGoogleにそうだから教祖様みたいなもんなんだよコンピューターサイエンティスト教の教祖様Googleが右と言ったら右みたいな赤と言ったら赤みたいなってじゅんぺいが思ってそんな顔してましたこれなんで大事かというとまずSREどういうものっていうので

さっきカイチが言ってたとにかくそのサービスを稼働させ続けるための人たちがほぼ答えですでなんでこれ大事になったのっていう背景なんですけどプログラミングじゃないなソフトウェアを作る時って主に作る時にめちゃくちゃ議論されるんですよとにかくこういうのを作っていきたいよね盛り上げていくぞみたいな

そこでとにかく会話のコストを使ってるんですけど実際にそのソフトウェアを動かすにあたってかかってるコストの40%から90%はソフトウェア誕生後に発生しているとほう

そんな作る時ではなく運用にもっとお金がかかってるよとああそういうことか運用にはお金かかりますね確かにそうだって動いてる時間長いんだもんねそうそうそう作ってる期間はちょっとでうんずっと動いてるからねそうなのに君たちは作ることに集中しすぎだようんうん作った後の話もしようようんそういうチームでございますね

多分ソフトウェアを作ってたもう少し前の時期って多分作るのが精一杯だったんですよねだから運用した後のこととか考えられなかったけど最近そういう知見とかツールとかがいろいろ出てきたおかげで

出た後大変じゃねって気づかされる気づける余裕ができてきたってことかもしれないですねそうかこれ歴史が積み重ならないとこの辛さは出てこないもんですよね車が発明された時に車の修理屋さんとか

ないのと一緒ですよねましてやGoogleなんてめっちゃずっとサービスしてますいつから20年もってってるかやってるか1990私が生まれた後ですよねでもGoogleは多分ね

できたのはどっちか分からないですけどねでもそうですね多分1995年とかそんぐらいだった気がするんだけどもう30年になりますともう少し経ったらただちょっとさっきの言い回しだとまだSREというものがふわっとしてますよねとにかくサービス継続させるのはね運用と何が違うんですかってことですか例えばまさしくそれなんですよ監視してる人と何が違うの

じゃあそこに行こうSREの起源これはシステムアドミニストレーターシスハドと呼ばれてたシステム運用ですねの人たちが関係してますまずそれどういう仕事かっていうとまず例えばモニタリングとかしますよねこのサイトちゃんとさばける量のリクエスト来てるかみたいなところのチェックアラート出てないかとか

でぶっ壊れたらそれ直したりとか新しいバージョンが出たらそれをリリースしたりとかそういう風にして運用しているSysAdと呼ばれている軍団がいましたと軍団ねしかしですねこのシステムアドミニストレーターと開発を分けるという手法うん

利害が対立するわけですねどういう戦争が起きるんですかこれはより安定させたいシステムアドミニストレーターvsよりたくさん機能をリリースしたい開発者の間で対立が起きるんですよデプロイしまくればそれはバグるというかぶっ壊れる可能性が高くなるし危険じゃないですかというところでそこの利害が対立してきたよね

っていう時に出来上がったものがSREと呼ばれてるチームなんですねそれはじゃあ仲介する人ってこと?いや仲介というよりはこれまさにデブオプスと同じでデブオプスってデブとオプスで分かれてた時に利害が対立するからもっと一緒に頑張ろうよみたいなやつじゃないですかそれをちょっと拡張しましたよっていうのがこのSREなんですようんうんうん

もっと具体的な手法で提唱してるっていう風に近いですかねDevOpsが概念だとしたらSREは結構具体的なことを書いてますねこの起源のところでGoogleのこのDevOpsチーム最初はチーム名忘れちゃったんですけどプロダクションチームみたいな名前だったらしいんですけど最初7人いたらしいですねその7人を蘇生した人が言ってた言葉

SREを表すにはこれが一番いいっていうのは運用の人を雇って開発者を雇ってっていう別々のことをしてたんですけど運用のためにソフトウェアエンジニアだけを採用するようにしたんですねその結果ソフトウェアエンジニアに運用チームを設計させた時に出来上がったものこそSREだろうって

言ってて意味が分からなかったと思うんで少し言います難しい日本語がめっちゃ簡単に言うとこれまで運用チームって人手でめっちゃやってたんですよその運用の作業を例えばさっき言ってたアラート出てないかなとかそうそうそう緊急対応とか全部デプロイとか全部人手でやってましたパワーででもこれって問題があって

システムがでかくなればなるほど運用チームもでかくないと対応できなくなってわー大変だコストがどんどん膨れ上がっていく問題があるんですねっていうのをソフトウェアエンジニアを雇うことによってソフトウェアエンジニアは同じことをやってると退屈し始めますとうん

退屈し始めたエンジニアはめっちゃ労力かかるけどそれを自動化し始めましたとっていう風にこれまで人手でやってたことを自動化するためのソフトウェアを作って運用しつつ開発もするよっていうチームになっていったっていうこれがSREチームの起源らしいんですねなので本当にDevOpsを体現してるみたいな感じだね開発しつつ

そういう運用を自動化するためのソフトも作っていく人たちみたいなDevOpsに関しては実際に提供するサービスの開発ですけどSREは提供するサービスを監視とかしてる時の業務を効率化するためのソフトウェアを開発してるんですよねDevOpsは概念SREはチームみたいな感じかなお互いそんな違うことは言ってない

結局オペレーションとデベロッパーの利害が対立するから手を取り合って頑張っていこうねそれっていうDevOpsっていう概念があってそれを具体的かつちょっと拡張させていったのがSREみたいなそういうポジションの感じですかねちなみにSREチームはDevOpsチームとは別ですか一緒ですか対戦にもよるかも同じなんじゃないかな

両方が存在することはないんじゃないですかね僕もあんまり詳しくないんですけどアプリケーション作るときってフロント作ってバック作ってインクラ作ってリリースするじゃないですかその過程でなんとなくですよ僕の今のイメージアプリケーション作る人と

デプロイパイプライン作る人とかインクラ作る人ちょっと分かれてること多いなと思っててそのインクラとかデプロイパイプラインがSREでアプリケーション作る人は別のSREとは別のデブだけどその人たちは同じチームとかなんですかねそれとも兼任することが多いんですかね理想は多分全員全部やるんでしょうけど

そっちのイメージでしたデプロイパイプラインとかをやってる人たちがSREのイメージだったんですけどそうじゃないってことですよねちなみにGoogleだとデプロイパイプラインを作る上限を勤務時間の50%にするっていう上限を定めてて残りの50%はソフトウェア開発をやるっていうなるほど風に運用してるそうですマジでその時点でまず倍仕事してるよね

いいところで気がつきましたすごいちょっとこれメリットデメリットに関係するところなんですけどまずメリットで言うと自動化するため自動化するじゃないですか規模に比例してコスト増えていくってことがないプラスプロダクト開発チームと相互に移動がしやすくなるんですね

結局SREチームの人も開発はしてるから開発チームに行くこともできるし開発チームからこっち来たとしても半分は今までやってた業務なんでその移動が比較的やりやすい過去のインフラとかと比べるとそういうメリットがありつつもデメリットとしてはですね採用が難しいというのがありまして一つはプロダクトの開発者の候補者とめっちゃ被るんですよ結局ソフトウェア開発できないといけないからプラス

要件が高いんで応募者の母数が少ないどっちもできる人じゃないといけないですもんねそうだからちょっとオンされてる感じだよねSREの方が倍だよねシンプルにちょっと重さが同じかどうかは微妙なところですけどだから求めてるスキル感としては通常のソフトウェアのエンジニアリングのスキル

コーディング的な部分ですねに加えてUNIXシステムの内部とネットワーキングレイヤー1からレイヤー3についても熟知している能力みたいなのを持っている人っていうのが応募要件に当たるのでめっちゃむずいっていうかレベル高いことやってます理想論かもしれないんですけど全員やれよって思いますよねやれるべきではあるよねみたいな

うんっていうかねまあちょっと一生読んだ感じだとそれをやんないと意味なさそう うんまああとはもっと言うとコパイロットが出てきたんでそういう仕事の仕方ができるようになるというかそういう仕事をしていくようになっていく気はしますよね うんこれは僕の妄想なんですけどうん

AIに仕事を奪われるんじゃなくてAIによってやらなきゃいけないことが多分増えるなるほどそこで保管されることによってこの難しい業務もできるようになっていくよみたいなそうですさっき言ってた1日機能作るのにかかってた時間がコパイロットで半分になってというか半分でやるように頑張ることになってじゃあ残り半分パイプラインとかインフラとかいけるっしょみたいなねなるほどねうんうん

なので非常にホットだと思ってますこれはね非常にホットだと思ってますではですねここでちょっとSREについてふんわりとした部分を触っていったんですけどもっと具体的に何してるかを知っていこうと思いますお願いしますまずSREの責任範囲これは先ほど言った通り結構スーパーハードモードになってるんですけど本当にねまずはサービスの可用性

を非常に重視してますなぜなら誰も使えないプロジェクトっていうのは価値がないからですうんうん

なんでとにかく常に動いているようにしようっていうところにまず責任を持っているのとレイテンシーとかパフォーマンスそういう通信とか実際にさばける量の部分とかそういうパフォーマンスの部分にも責任を持ってますよとそれはサクサク動けよっていうところを担保したいんでしょうねプラスで効率性効率性ちょっとねまだ深掘りされてないんで一旦効率性とだけ言っておきますあとは変更管理モニタリング

緊急対応キャパシティプランニングこういった領域に対してですね責任を持っておりますとじゃあ引きの要件のところに近いんですかね性能とか可用性とかこの辺に責任を持ちつつもでも機能も開発するよっていうのでだいぶハードですねその辺をなんか司る具体的なところってやっぱりインフラというかシステムアーキテクチャのところが

多いかなと思いますねだからこそさっき言ったUNIXの内部の知識とかネットワークの詳しいところを知ってないといけないよっていうことなんですねちなみに今出てきた単語でちょっと難しい部分で言うとレイテンシーこれは遅延ですねネットワークとかのあと変更管理は要はデプロイだよねそう思いますGitとか含めて新しいバージョンリリースするとき

どうしていくとかバグがあったらどう切り戻すとかみたいなとこですねそうそうそうそうあとキャパシティープランニングはサーバーのスペックを決めるための計画みたいな感じですねDBかもしれないしうん

まあこんぐらいの頻度で使われるからこのDBのストレージこんぐらいにしておこうみたいなそういう計算とかをしたりするっていうところにまず責任を持ってますよといやーこれね具体的な業務見たらね僕はもうワクワクしましたワクワクしたんですねはいもうSREめっちゃ楽しそうってね思いましたねこれはこれ順番に行きますはいまず常に動かすっていうところを目標としてるんでオンコールシフトっていうシフトを組んでるんですねうん

要は何か問題が起きた時にそれを受け取って対応するみたいなそういうやつでここでGoogleが定めているルールとしてそのシフト中8時間のシフト中で受け取る依頼っていうのは2つを目標にしてますよと最大ではいでこれは要はその働いている時に起きる問題は2件までよっていう

そういうことですねなんでそうしてるかっていうとたくさん問題が発生するとそれの振り返りをできなくなってしまうから起きた問題に対して常に振り返りをするっていうのを結構重視してましてこれね単語なんでこんな使い方してるんだろうと思ったんですけどページャーが発生したらポストモーテムを書くって書かれてるんですよなんてなんてなんてムズーみたいなこれ一個一個調べたんですけどページャーは普通にポケベルらしいです

要はどっちかというとスラックとかのイメージつけやすいかなって気がするんですけどそういう通知を受け取ったことですねメジャーの発生っていうのはポストモーティムっていうのはその起きた問題に対して原因調査して改善を考える改善の施策を立てるっていうところまでのセットをポストモーティムというらしいですね

振り返り通知受け取ったら振り返るよねみたいなそれが効率的に行われるのが1日2件までじゃねみたいないや2件も大変ですけどねでもGoogleの規模で2件しか飛んでこないの結構やばいよねどういうことなんでしょうね3件以上来たらちょっとやばいぞっていう感じらしいですね逆にバグんないのかもねユーザー数多すぎて

バグ出しは速報を行われるって言うんですかありとあらゆる人がありとあらゆる使い方してるから滅多に壊れないのかもしれないですねでもそれで言うとそもそもモニタリングのところも結構こだわりを持ってる

まずアラートに関しては人間の解釈を挟むべきではないと言ってるんですねではなくてソフトウェアが解釈してそれに対するアクションが必要な時だけ通知を受け取るようにしようねっていうマジで徹底的に仕組み化してますね人間が介在すると仕組みになってないけどソフトウェアで例えばこの人だったら気づけるみたいなのって結局その人いなくなったら気づけないからソフトウェアだけで気づけるようにしようねみたいなことですもんねいや徹底してるねやっぱすごい

これで僕は革命だなと思ったのはアラートを3つに分けようっていうアラートというか通知を3つに分けようっていうのを言っててですねアラートとチケットとロギングに分けましょうとアラートとチケットとロギングそれをソフトウェアが自動で分けるんですけどまずアラートは人間が即時対応が必要なものチケットが人間の対応が必要だけど即時では必要ないもの

ロギングが必要に迫られた時に読むけど普段は別に読むことを期待されてないものみたいなっていう風に分けると本当に必要な通知だけを受け取ることができるみたいな狼少年にならずに済むとそうとすると例えばチケットの時はチケットにしか置きないってことですよね

だと思うよ多分ログにも残らないのかなログは残るんじゃないさすがにログ残りますかねログは残ると思うよ不安だからさすがにログ残したくなりますけどそっかだからミーシーではないかこの3つはアラートとチケットはミーシーかもしれないけどログはこのアラートとチケットと重なってるとは思うだからイメージなんですけどロギングはワーニングに近いってことなのかなていうかまあ

何か問題が発生して要はソフトウェアが解釈してるから正しくないケースもあるんじゃないですかねそういう時に必要に駆られてロギングを見に行くみたいな感じなのかなって思ってましたねロギングってログですかねログとは別なのかアプリケーションログとは別なんですかねいや同じじゃないかそうですよね多分一緒ですよね同じだと思うよ多分だからエラーログが普通に残りますとチケットは俺やったことないわいいかもねチケットは

チケットやんなくないですかあんまりやんないアラートじゃないですか大体アラートだと思っちゃうアラートがログになるチケットってどうやるんだろうそれをソフトウェアが勝手に解釈してるってのがなんかちょっとね不思議なんかどうやっミドルウェアとかでなんか上手いことやってるんですかねどうなんだろうななんかちゃんアラートはわかるじゃないですかだから多分チケット作る

のができるんでしょうねどっかでこれに関してはモニタリングの書をしっかり読んで再度共有したいなとも思いましたAWSとかならできるイメージあるななんとなくクラウドログ残しておいて種類に応じてスイッチの仕方変えるみたいな結局ラムダ多分呼び出してラムダでジラカなんかのAPA叩いてチケット作るだけだと思うんでそうねうん

でもAWSでできるってことは多分そういうミドルウェアあるんだろうなきっとGoogleともなると自作してそうだけどそうっすねGCPには絶対あるでしょうしねGCPで動いてるんでしょう動いてるんじゃないかなさすがにねなるほどなちょっとねいいっすねっていう効果的なモニタリングを行うっていうのも具体の一個なんですよあとこれすごいなと思ったのはエラーバジェットの考え方ですね聞き覚えがありますがはい

これは何かというと新機能を開発するぞーっていうモチベーションとプロダクトを安定させるぞーっていうそのモチベーションの対立を取り除くための考え方なんですけどそもそもこれって100%の可用性を求めるのは間違ってるよっていう概念から始まってるんですよでなんでかっていうと例えば99.999%動きますよっていうサービスがありますと

でそれを100%目指すのって全く意味ないなんで意味ないかっていうと観測不可能だからなんですね

なぜならそのサービスがちゃんと稼働してても例えばスマホの調子が悪いとか家のネットの調子が悪いとかはたまたインターネットエクスチェンジの調子が悪いみたいな感じでそういうノイズによって使えない時間って絶対出るわけじゃないですかってなった時にユーザーから見た時の観測できる量が変わらないノイズにかき消されてしまってなのでそこの0.001%を改善するために莫大なコストを投資するのは間違ってるっていう発想なんですねで

例えば目標を99.9%にしましたと可動性のそうなった場合その残りの0.1%をエラーバジェットとするんですねこれは超過しない限り何にでも使えるって言ってて要はこれを超過してない限りはバグ出してOKみたいなっていう考えをすることによってイノベーションを加速するためにその予算を使うぞっていう姿勢になるんですね

その結果その範囲内に収まってるからってことでリリースが制限されることもないしプロダクト安定させるぞっていうチームがそれ以上頑張らなきゃってなることもないっていうめっちゃ極論なんですけどファンタジーの話なんですけどまずこのボタンを押したらデータが壊れますっていうボタンがあるとしますで

ただそのボタンがあったとしてもSREエンジニアがめっちゃ頑張ってデータが壊れても直前のデータに10秒で復旧して戻すみたいな仕組みがすでに入ってたとしてそのバグのせいで年間例えば4時間合計でサービス止まってますだとしてもだから気にしないってことですよね予算内だから機能リリースじゃーいってその割り

切りすごい大事ですよねっていうかこの割り切りしないと確かに対立取り除けないなというか対立を取り除くすごい考え方だなって思ってねちょうどよく間というかうんでもこの考えがなかなかできないんですよね仕事だとねお客さん例えばその何?

内政組織を持っててなおかつエンジニアのマネージャーとかだったらそういう考えできるかもしれないんですけどそういうのじゃなくてめちゃくちゃビジネスサイドとかでこのシステムめちゃくちゃ厳格なんですっていう状況の時ってどうしても100って言うんですよねそういうのもね難しいですよね物によりますよもちろんね多分お金系とかあれなんだっけな証券証券取引とか

あれいつデータ壊れても全部復旧できるらしいんですごいすぎるんですけどどういうことなんだとんでもないことが起きてるんですけど多分サーバーの外側にタイムマシーンがありますよねそういうのだったらわかるんですけどそうじゃなくても100って言われることあると思うんでなるほど

それで言うとこれに関してはそもそも元の発想がGoogle.comのサイトを動かし続けるために作られたチームだからミッションクリティカルのやつはまた別の話だよとは言ってました本の中でもそうですよねでも大概そうじゃない?

ビジネスサイドからしたらなんでってなるもんねスーモの不動産とかなくなったら困りますけどデータの完全性とかは気を取るけどあれ100%動いてなくてもいいじゃないですか1年間で

8時間とか泊まってもね不動産屋さんには迷惑かかりますけどその時間帯ね迷惑かかるすまんだけど死にゃあしないんで誰もねみたいな割り切りをちょっと世に広めていきたいですねこのエラーバジェットはすごい発想の転換だなって思いましたね定量的なのいいですね解釈が人によってばらけないっていうのはGoogleが徹底しているところで

素晴らしいあとは緊急対応みたいなのもあって具体的な作業内容としてはやりたくねーここではねMTTRを減らす努力って言ってミンタイムミンタイムトラベルリクエスト旅行に行きたいと言うまでの平均時間俺は年に1回なんだよMTTRって今年は熱海行くんだよみたいな

違いますねはいミンタイムトゥリペアかなこれは復旧までにかかる時間かなうん

とかをなるべく減らしていこうとこれはまず一番効果でかいのは手作業を不要にすることだよと基本的にこけたら自動復旧できるようにするっていうのがもちろん一番効果がでかいあとは手作業の場合でもベストプラクティスを事前に用意しておくことで実はノラ復旧とかやるよりもタイムがだいぶ縮まるらしいですねなんでそういうのを用意しておくっていうのもSREのやること

修復の自動化とマニュアル用意みたいな感じだねっていうのもやったりするしあとは変更管理のところで言うとサービスの障害って実は70%がですね動作中のシステムを変更することで起きるわけなんですねそうなんですねらしいそんな?いやでもね分かるだってさめっちゃ確認しない?大丈夫だよねってやってからリリースするけどうん

バグっちゃうんですねでも今僕はウェブサイトの運用に近いことをやってるんですけどだいぶそうだなっていう実感あるなんなら9割超えるんじゃないかなとそうなんだ意外ではないかもしれないですねテストデータだと存在しなかったこんなデータのケースがあったんかい大爆発みたいなあるあるわ時間かかる系

期限2日ですよみたいなやつってテスト段階でテストするの結構抜けちゃいがちというかそこもあったんかい2日みたいなのがあってそれが大爆発するケースがありますね確かに

これの対応方法例えば全身的なロールアウトっていって一気に全員にデプロイするんじゃなくてちょっとずつの人にデプロイしていくみたいなカナリアリリースってやつですねそうそうそうそうっていう仕組みを作ったりとかあとまあ高速かつ正確な問題検出ってあったんですけどまあそりゃそうだよなっていうとかあとは問題が生じた際に安全にロールバックできる仕組みみたいなそういうのを作っていくっていうのもSILの仕事ですよとうん

あとはキャパシティープランニングこれに関しては結構びっくりするほどサボる組織が多いらしいのでちゃんとやろうねっていうことを言ってましたねサボるとどうなるんだ?え?不意にデータパンパンやーってボーンになるんじゃない?なるほどね保存できねえ動かなくなったストレージパンパンになるとマジでOS動かなくなったりしますよねそうなんだよねあれ復旧大変だよね

っていうことが起きるんでキャパシティープランニングまずちゃんとやろうねっていうのを言ってましたねであとはプロビジョニングって言ってプロビジョニングは要はキャパシティープランニングプラス変更管理みたいなもんなんですけど要はプランニングするだけじゃなくてちゃんとそれを正確に素早く本番環境に反映していこうねっていうやつ例えばこの勢いだと3ヶ月後にパンパンパンになるなみたいなじゃあ

これはちょっと来月までにこれぐらいの容量を的確に素早くアップしていきましょうみたいなストレージでっけえのにしましょうみたいなのをちゃんとやるとそしてあとはパフォーマンスこの本の中であるパフォーマンスウェブ開発もやるって書いてあったんでアプリケーション寄りのこともやるのかなって思ってたんですけど基本的にはちゃんとキャパシティープランニングでキャパシティをちゃんと見てリクエストが多くなりすぎてないかとか

データ大丈夫そうかみたいなところをチェックしてレスポンスが遅くならないようにすることみたいな感じで書いてましたねこういうのをやってるのがSREチームというチームらしいですねこれをやりながらウェブ開発やってますからね忙しすぎません?やばい死んじゃうGoogleでは運用のための時間50%開発のための時間50%を結構徹底してやってるらしくてうん

もし超過した場合とかは開発エンジニアを借りてきて運用の時間に当てさせるとかそういうことをやるらしいですねそれをやることによって開発者も運用というか安定して稼働させるためのことを知ってよりスキルアップできるというかアプリケーション開発のところにもつながるし多分SREチームへの移動がトレーニングになるって書いてあったのでそういう交換をやってるんでしょうねポジションのチェンジというか

っていうのをやることによって開発と運用が一体化したチームを作れてますこれがGoogleのSREです大小感ドーンって感じですねありがとうございますすごいなんか僕去年とかに去年一昨年しかもしれないなソフトウェアアーキテクチャの基礎とか読んでシステムアーキテクトとは何かみたいなところを読んでそれいいなとか思ったりして勉強し続けてるんですけど

SREとアーキテクトって結構近いと思ってて近い近いと思っててアーキテクトの人もその辺のキャパシティプランニングというか可用性を満たすためにどういう風なアーキテクチャにする必要があるんだろうとか考える人なんですけどはい

実際僕は現場を見ててシステムアーキテクトと言われる人って存在しないなと思ってて実際は1000人でやってる人ってあんまりいないよね1000人でやってる人っていなくて多分

SREみたいな動きを求められてるんですよ全部やるっていう風に思ってますさっき出てた可用性とかの話とかもキャパシティープランニングとかも今AWSのソリューションアーキテクトの勉強してますけどそこなんですよまさしくアーキテクトってついてるんで多分アーキテクチャーアーキテクトに通じる今アプリケーションの開発もSREが得る必要があるっていう話してたんですけど

今は多分別に別々にもいいんじゃないって思ってる人いるかもしれないんですがアプリケーションの作りがシステムに関わってくることってあると思っててステートレスなアプリにしないといけないとかあると思うんですよ例えばコンテナ管理にしてそれでスケールアウトできるようにしますってことはスケールインすることがある減った時に誰にも迷惑かけずに死ねるようにアプリケーション作らなきゃいけないですしデータの構造とかもね

その辺の勘どころとかを失わないでいい感じに動くアプリを作るためにはそこ全部やらなきゃだよねじゃあ全部やりましょうねっていうのが多分SREなんでねやっていかなきゃなと思いつつ僕も作ったアプリをできるだけ早くお客さんに届けるっていうのが目標なんでSREという考えは非常にやらなきゃなと思ってますこれでもねむずいよね広すぎコンテキストスイッチやばそうじゃないですかどう区切るんだろうねマジで

だってアプリケーションって言ってもアプリケーションって言ってもフロントとバックになるじゃないですか多分インクラって言ってもインクラストラクチャーアズコードIACテラフォームとかもあるしデプロイパイプラインとかの話になると多分また別ですよねキットアクションなのかサークルCAとかでインクラ層に行ったらオンプレなのかAWSなのかですよ今テラフォーム

AWSパイプラインギターアバクション例えばひょっとしたら全部AWSにまとめられるのかもしれないですけどクラウドフォーメーションとコードデプロイとかできるんですけどやんないってことが多いと思うんででフロントとバックエンドとすごいよほんでもないよねほんとに

50%50%って言ってましたけど1スプリントだとしたらさすがに日は分けてほしい分かる午前中アプリ開発やるぞって中途半端な状態で運用やんなきゃみたいなのきつすぎるしんだいしんだいもっと言うとスプリントで分けてほしいあー

なるほどねアプリのスプリントそれはあるなでもちょっと一周開けちゃうと忘れちゃうよねっていう可能性あるんですけどねどっちがいいんだろういやでもさすがに結構大きく分けてほしいなそうすると大きく分けたとしてフロントとバッグ1スプリントに収めなきゃいけなくなるんですよなんかそうするとね

フロントとバックもスプリント分けちゃうと3週間に1回とかになっちゃうんでほぼ月1みたいなそんなの忘れちゃいますよねフロントとバックは混ぜてもなんとかなるなります?じゃあ

でもそういう進め方ですよねだからもっと言うと倍のスピードで仕事してるから50%50%でも大丈夫なんでしょうねあとなんかそういうもともと手作業でやってた運用を自動化できる人たちだからなんか開発においてもなんかとんでもないことをやってそうな気がする本当に理解があるいろんなことに

インクラ層とかの方って多分コード書くの大変じゃなくてどうしたらいいかなが超大変ですよね世の中にどういうやり方があって調べて比較検討してこういう観点だとこれこっちいいけどこういう観点だとこれこっちがいいお金はこっちの方がかかるけど性能的には良くないけどお金かからないこっちでいいのかな

っていうのを相談しに行って合意取ってよしこれだってコード書いてって言わなきゃいけないんですからそうねしかもあれだよねGoogleのSREとなるとさインフラの規模とかが一般的な企業と桁違いすぎて前人未到のことをしてそうだよねまあそうですねそれに関しては多分

そうだろうなそうですね多分いろんなところでただレビュアーがいるだけなんでGoogleって確かそれを全て司るスーパーマンがいろんなコンポーネントごとにいてその人に向かってプッシュしてるみたいなんでやべえどうなってんだまじでまあだから勉強頑張りましょうってことですねすごいよ果てしないけどでもちょっとね僕はSREめっちゃ興味湧きましたねこれ第1章読んだだけでいいですね僕もなんか今年

SREから始めようみたいな本出ましたよねあー出た7月くらいにあれ結構ホットだなと思ってるんで僕もちょっと気になってるですちょっとね最近アプリケーションレイヤーからちょっと違うとこ行きたいなと思ってるんでその勉強の関心的な意味で7月じゃねーわ10月だあーじゃあめっちゃ最近ですねめっちゃ最近だわたまれサルのやつですよねあーそうなんかメガネザルみたいなやつメガネザルなんでぜひまあそのねアプリケーション飽きたようじゃないけど大きい穴を掘るにはね幅いるんでうん

一緒に幅広げていきましょう僕はSREを今までインフラと勘違いしてきたんですけどだいぶ違ったっていう僕も正直アプリケーションまでやると思ってませんでした俺一回読んだけどな読んでないのかなんか調べたけどな思ったよりスーパーマンだったんで思ったよりスーパーマンになろうと思いました頑張りましょうハッシュタグひまじんプログラマーでSNSネックスフィードバック募集してますので

SREの方SREへの道ロードマップとか調べれば出るんでしょうね確かにとりあえずアプリケーションエンジニア終わったところからスタートするみたいなロードマップ出てきそうそれはある世の中ここからそういうのが求められると思うんでね結局コパイロットで

アプリケーション開発の難易度が下がったというかスピードがつくようになったと思うんだよね確かに頑張って追いついていきましょうはいあとはポッドキャストの説明欄からGoogleフォームで番組のお便り・感想・質問何でもお待ちしていますのでお気軽にお願いいたしますお願いしますあとは各種ポッドキャストプラットフォームでのフォローこういう他もお待ちしていますお願いしますフォローしてくださいお願いしますではのりさんありがとうございましたありがとうございましたまた次回バイバイバイバイ

ある夜ねいつものようにラジオのお便りのチェックをしていたんですよそしたらね夜なのにねお便りの通知がねポーンポーンってなってねこんな時間におかしいなぁおかしいなぁおかしいなぁと思ってリスナーも寝てる時間なのになぁって思ってメールフォルダー開けたらねうわぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁ