はじめに 開催概要 2025テーマ「Talk NEXT」 SRE NEXT とは Road to SRE NEXT さいごに はじめに こんにちは渡部です。SRE NEXT 2024でアナウンスがありましたが、SRE NEXT 2025の開催が正式に決定しました！！Co-Chairは私と岩堀さんになります。 2025年に開催されるSRE NEXTは、第5回目の開催となります。過去4回の開催を通じて、私たちは参加者からの貴重なフィードバックを元に、内容の充実と多様化を図ってきました。今年も、SREに関する最新のトピックスや、現場で活かせる具体的なプラクティスを共有する場として、さらなる成長を目指しています。 この記事では、SRE NEXT 2025の開催情報やテーマ、予定されているサブイベントについてご紹介します。 開催概要 SRE NEXT 2025は、東京・有明で開催されます。今年も昨年

php artisan queue:work には、色々な引数があるようです。 バージョンにもよるんだろうなぁ、と思うのですが、とりあえず手元の 8.83.27 のバージョンでお話を進めます。 とりあえず引数の一覧は、vendor/laravel/framework/src/Illuminate/Queue/Console/WorkCommand.php によれば protected $signature = 'queue:work {connection? : The name of the queue connection to work} {--name=default : The name of the worker} {--queue= : The names of the queues to work} {--daemon : Run the worker in daemon

SRE NEXT 2024 sre-next.dev 今年もやってきました。2023年で一回スタッフをやっているので今年で2回目です。 印象に残ったセッション 工学としてのSRE再訪 / Revisiting SRE as Engineering speakerdeck.com 「技芸」と「工学」の側面からで考えて進めていくというのは考えたこともなくてもとても面白かったです。技芸と工学の共存について今後もお話を聞いていきたいなと思える内容でした。 speakerdeck.com SRE の考えをマネジメントに活かす speakerdeck.com SREは生き様。すごく納得はしていたがどうSRE以外の活動に活かすかって結構難しかったりします。この発表を聞いて類似点を見つけつつSREとマネジメントでの違いに着目するという進め方はさまざまな場面で参考になるなと思いました。 SREが考えるハイ

Grafanaのダッシュボード表現とGrafonnet Jsonnet、Grafonnetのセットアップ Grizzlyを使う Grizzlyのセットアップ Grizzlyを使ってJSON/形式でダッシュボードを作成する Grizzlyを使ってGrafonnetでダッシュボード管理を作成する まとめ ・・・と一旦まとめた後の雑多な補足 参考 先日、というかもう3ヶ月も経ってしまいましたが Grafana Meetup Japan #1 - connpass にてLTをさせて頂きました。 趣味のダッシュボード開発というテーマで、あわせてGrafanaのダッシュボードをコードで管理するソリューションの1つとして Grizzly GitHub - grafana/grizzly: A utility for managing Jsonnet dashboards against the Graf

SampleAgeLimitというのがmainにマージされたのを観測したのでちょっと歴史を含めてメモしておくという雑記事です。 三行 1) 2.11.0 / 2019-07-09 MaxRetriesが削除された 2) 2.32.0 / 2021-12-09 MaxBackoffが100msから5secに変更 3) xxx / 2024-01-05 SampleAgeLimitが追加されmainにマージされた（デフォルトは無効） 2年おきくらいになにがしか更新がある RemoteWriteがんばり過ぎ問題 プロダクション環境の信頼性を損ねず観測する技術 - Speaker Deck こういうの PrometheusのRemoteWriteはExponential Backoffなリトライをする しかしMaxBackoffに到達するとそこでひたすらRetryを繰り返す WALは2h程度で

この記事はSRE Advent Calendar 2023の4日目の記事です。 qiita.com 3日目は@myu_mxさんのゆるやか成長スタートアップの小さなEnabling SRE的活動でした。 久々のアドカレ参加ですが、少し思いの丈に任せてみようということで経験と主観が強めの記事です。 この辺で語られていたよとかこれは賛同できないというポイントなどもっといい情報があればぜひお知らせください、という感じで雑多に書いて参ります。 TerraformやCloudformationあたりをよく触るのでそのあたりがどうしても頭にありますがなるべく固有の話はしない方向で。 色々書きつつ、基本的には長期的な運用を見越したソフトウェアの運用設計と同じ考えで良いとは思ってます。 最低限のインターフェースを公開し疎結合に設計する、モジュールは交換可能する、ライフサクルを考える、などなど。 ただIaCコ

インフラストリーミングチームの近藤 (@udzura) です。今回は、ミラティブで内製しているオブジェクトストレージサーバ「b3」の紹介記事を書きたいと思います。 今回の記事は、6月にGopher Talkというイベントで発表した「Go製ミドルウェアを実践投入するにあたりやったこと」をベースに、内容を詳細にしたり直近の開発状況に合わせて更新したものです。一部内容はこの発表と重複していますがご了承ください。 オブジェクトストレージサーバを内製した背景 1. 大量オブジェクトの操作や増え続ける転送量に対応したい 2. 一定期間しかファイルの保持をしない 3. オンメモリ/SSD/HDDを組み合わせたチューニングがしたい オブジェクトストレージb3の特徴 S3 互換の基本的なAPIを実装 LSM-Tree index＋WALなDB/マージ操作に対応 I/O 帯域を制限可能 非同期レプリケーション

登壇＆参加記事です 今までのあらすじ（ずっとアラートの話してる気がする） 今回の発表まわりの蛇足 セッション ギークがイオンに飛び込んだ結果がやばい〜Reliabilityと経営〜 LINEスタンプのSREing事例集：大量のスパイクアクセスを捌くためのSREing エンジニアのためのSRE論文への招待 【コミュニティコラボ企画】パネルディスカッション 〜信頼性に関わる、ご近所さんが集まりました〜 ブルームバーグのセントラル・テレメトリー・システムが業務にもたらす価値 開発者とともに作る Site Reliability Engineering 信頼性目標とシステムアーキテクチャー セッション以外 今後について 今までのあらすじ（ずっとアラートの話してる気がする） 2020 dasalog.hatenablog.jp 2022 dasalog.hatenablog.jp 開発者とともに作る

明らかに誤ったことをしたのにそれを認められずに醜態をさらしている、場合によっては傷口を広げて自分を窮地に追い込んでいる人を大量に見てきた結果、「こうはなりたくないな」と思う気持ちがずっとありました。にもかかわらず、数年前に見事に過ちを認められずに、謝罪できずに無様な姿をさらしたことがありました。公の場でやったことではないし、もしかすると謝罪されるべきだった相手は気にしていなかったかもしれませんが、自分から見れば間違いなく無様でした。 こういうことがあって以来、誤りを認める練習をするようになりました。練習といっても、壁に向かって謝罪し続けるというような話ではなく、自分の言ったこと、書いたことが間違っていたとわかったら、何もしなくてもその場はやりすごせそうな小さなことでも即座に「これは誤っていた」と表明するということをやっています。小さな誤りを認められなければ、大きな過ちを犯したときにも認めら

こちらを最近読んで takumif.hatenablog.com 一年前の記事ですがめちゃよくまっていてすばらしいですね。 当時子が産まれるちょい前くらいのタイミングで男性育児系の記事いくつか読んだのだけどこれ読んでなかったなと思ったら時期が微妙にずれていたのでした。 育児中、だいたい手が空かないのでぴよログのalexa連携はめちゃ良いですね、皆使うと良いと思う。実装してくれたぴよログの人ありがとう。 ということで、最近育児記事みたいなのも増えてきましたが自分も覚えてるうちに少しは書いておこうという気持ちで、サンプル1/1程度のなにかをざっと書いてみましたなやつです。 どんな状態だったか 最初の子 育休期間は4ヶ月弱 夏生まれ 生まれてから一ヶ月ちょいまで妻の母が泊まりでサポートに来てくれていた 我が家の場合 基本的な役割分担 自分と妻が交代で子のお世話 妻の母が家事サポート 実際は家事以

Intro 最近はGoでApiサーバーを作っています。早いうちからコードをdev環境にデプロイして、みんなでワイワイそれを叩いてフロントを開発しているのですが、いかんせん開発中なのでバグがあります。 そうるるとpodにログを見に行って、500エラーを返している箇所付近のログを探すのですが、そもそも詳細な値をログに落としていなかったり、ログ中のどの行がどのリクエストに対応しているのか分からず、調査は難航します。 そこで、traceを取ってみることにしました。 traceは主に処理時間の内訳や呼び出しの依存関係を示してくれますが、スパンのコンテキストにいろんな値を保持しておき、それをエラーログと結びつけることでデバッグに便利に使えます。また、自身でtraceやlogの記録・可視化を行う環境を構築することは面倒ですが、GrafanaCloudの無料枠を使うとこれが快適に行えるので今回はこれを活用

インフラのいわほり（egmc）です。 eBPFを利用したプロダクトとしてはCiliumなどがcloud nativeな文脈として盛り上がっていますが、一方でBCC Toolsやbpftaceは、システム内部のかゆいところに手が届くソリューションとして身近な課題解決にカジュアルに役立つツールとして提供されています。 これらのツールは実際に便利ではあるものの現実世界での事例をそれほど見かけないというのもあり、「こんな感じで役に立った」という事例をカジュアルに紹介していくのもコミュニティにとって有用ではないか、ということで今回はOSのバージョンアップに関連して発生した問題の調査にbpftraceが役立ったというお話をご紹介したいと思います。 環境 Ubuntu 20.04.6 LTS bpftrace v0.9.4 発生した事象 GREEのクラウド環境で利用しているシステムのアラートの配送を行う

サマリ Linuxにおいて使用メモリの情報はだいたい/proc/meminfoの情報から計算されるが、計算式にゆらぎがあって異なるツールやSaaSエージェントを使うと結果が異なることがあるので故あって調べた ダッシュボードの表示とfree(1)の結果が異なるなど 2023現在使用メモリはだいたいMemTotal-MemAvailableということでOK free(1)などprocps依存なコマンドもMemTotal-MemAvailableをUsedとして扱うようになる 稀に計算式が異なるケースもあるのでおかしいな、と思うことがあれば一応まだ気にしたほうがよいことがあるかもしれない ツールをまたぐ時は特に 各種SaaSやツールの状況 procps v4.0.1からMemTotal - MemAvailable、それ以前はMemTotal - MemFree - Buffers - Cach

高木　2年前だから、まだワクチンもなくて、医者も治し方を知らないし、世の中がてんてこ舞いになってた時期だよ。よりによってそんな時に罹るなんて……。今なら助かって帰ってくる人も多いだろ。そう考えると、余計なこと言うようだけど、もし志村があと1週間でもコロナに罹るのが遅かったら、きっと助かってたよ。もっと病院の体制も整っていてさ、違った結果になったと思うんだよな。 加藤　まあな。でもあいつだって罹りたくて罹ったわけじゃないからさ。不可抗力だよ。 高木　不可抗力だなんて、一言じゃ言えないよ。あんな早い時期に罹って、やっぱバカだよ。 加藤　いや、言えるんだよ。罹ったのは仕方ない。あの頃は、無理だったんだよ。 高木　そうかな。 加藤　長さん（いかりや長介）が死んで18年だろ。あっという間だよな。こんなこと言うとなんだけどさ、志村がいないとコントはできないけど、長さんがいなくても、不思議と4人だけでも

登壇＆参加エントリです。 ややエモよりになる予定。 当日の体験については他の登壇者の皆様とも少しお話したんですが、完全に馬場さんのエントリに書かれている点と同じ感想であり（事前収録は当日落ち着けてよい、参加者としてのZoom Event体験はかなり良かった、ブースの仕様はやや残念ではあったが個人的にはそれでも楽しめた）、まあ同じことを書いてもということで発表まわりや個別の参加体験の方を書いていきます。 登壇について プロダクション環境の信頼性を損ねず観測する技術というタイトルで登壇させて頂きました。 6/9時点でまだスライドのみですが、ぼちぼちアーカイブの方も上がってくるかなと思います。 www.youtube.com 前回2020の登壇から2年、SRE NEXTが開催されたら何はともあれproposalは出したいと考えていたので募集の段階でネタを考えました。 ネタは2本考え、1つは長期運

1987年東京出身。会社員。ハンバーグやカレーやチキンライスなどが好物なので、舌が子供すぎやしないかと心配になるときがある。だがコーヒーはブラックでも飲める。動画インタビュー 前の記事：土曜のお便り 〜家族の一員としての椅子 不満はないがトキメキもない うちには4歳の子どもがいて、朝保育園に連れていき、そのあと家に帰って家事と仕事をして夕方迎えに行く、というスケジュールを繰り返している。 そして数日に一回、近所のスーパーに買い物に行くというルーティンがある。ご飯の材料と、歯磨き粉とかラップとかを買う。 特別な予定が入らない限りはこの繰り返しである。いつものスーパーはいつ行ってもいつものスーパーである。不満はないがトキメキもない。 突然どこか遠くへ行ってしまいたい ならば、通勤中に反対のホームに来た特急電車に飛び乗るように、突然どこか遠くに行ってしまえばいい。 会社だったらその特急の中で上司

インフラ・ストリーミングチームの近藤 (id:udzura) です。 ミラティブのインフラ運用では、監視・自動化などさまざまなツールにGo言語を利用しています。ツールはコマンドラインツールとして提供して、バージョンごとにリリースを作成して各環境にデプロイしています。リリースの作成にはGitHubのRelease機能を利用しています。 今回は、GitHub Releaseの作成をGoogle Cloud Build（以下、単にCloud Build）で自動化したことについて、実装内容と効果を書いていきます。 なぜ Cloud Build を採用したか ミラティブの開発はGitHub Enterprise Cloudを利用しています。対応するCI/CDのサービスとしてはGitHub ActionsやCircleCIなど*1数多くありますが、ミラティブにおいてはGCPの利用箇所が多く、既存GCP

オンコールアラートを設定しようと考えた際に考慮すべき点を自分なりにアンチパターンとしてまとめたなにかです。 ホワイトボックスモニタリングにより得られたメトリクス、ログなどからアラーティングを行う、または併用する環境を想定しています、ブラックボックスモニタリングによるアラート、SLOベースのアラートのみでうまく運用されているサービスにはあてはまらないと考えてます。 参考書籍は色々あり、最後に記載していますが提示されてるプラクティス通りではないものもあります 。自組織、システムにあった設計をしましょう。 システムの監視がまったくありませんみたいな状況であればまずはサービスのURLに対する外形監視からはじめましょう。 言葉の定義 アンチパターン サービスに対する外形監視が設定されていない アラートを受け取って直ちに何かアクションを行う必要がない アラートに対応するrunbookが存在しない 自動

こんにちは、インフラの小林です。 GCP環境の監視基盤が一段落し実績も積めてきたので、アーキテクチャについて簡単に紹介します。この記事ではメトリックに焦点を当てています。Prometheusを用いたGCP監視基盤を検討している方や、Managed Prometheusを検討している方の参考になれば幸いです。 アーキテクチャ 比較のためにAWS EKS環境と合わせて紹介します。 AWS (EKS) AWS EKS環境では、監視用EC2インスタンスがあり、k8s Cluster内にはExporterのみが存在します。 k8s Cluster外部からkubernetes_sd_configを用いたService Discoveryを行い、メトリックを回収します。AWS環境はプロダクトによってVM, コンテナの利用がまちまちなため、両ケースに対応できるよう監視インスタンスはコンテナではなくVMとし