プロダクションミーティングを始めてみた
自己紹介 株式会社モニクルで SRE をしている beaverjr です。 この記事では、弊社のプロダクトチームと SRE チームで定期的に行っているプロダクションミーティングについて紹介します。 プロダクションミーティングとは プロダクションミーティングについては、SRE 本に詳しい記載があります。 プロダクションミーティングは、サービスが実際に運用される本番環境の状況と運用に関する情報共有を目的としたミーティングです。 ミーティングの目的 プロダクションミーティングの主な目的は、以下の通りです。 情報共有: チーム間での情報の透明性を保ち、本番環境に関連する重要な情報を共有します。 問題解決: サービスの運用パフォーマンスの詳細について話し合い、それを設計や設定、実装と関連づけて考え、問題解決の方法を議論します。 継続的な改善: 定期的なミーティングによって改善のサイクルを生み出し、サ
SLO Docsの運用をやってみて得られた知見など
自己紹介 はじめまして、GMOペパボでSREをやっている渡部龍一(X: ryuichi_1208)です。業務以外ではSRE Nextのスタッフをやっています。普段は障害対応をしたりEOL対応をやったりしています。 この記事では、SLODocsの運用を1年ほど前に開始しました。本記事では実際に運用してみて得られた知見を共有します。 SLO Docsとは 「Service Level Objectives」に関連する文書です。内容は「なぜSLI/SLOが必要なのか」や「具体的な目標値」、「関連しているチームや変更のためのステップ」等をステークホルダー間で合意を取った上で運用しているドキュメントとなります。 WEB+DB PRESS Vol.130の中で取り上げらている「【第2回】プロダクト開発に必要なモニタリングの始め方……SLOを定義し，SLIを実装しよう」を参考に我々のサービス向けにアレン
この春SREになったあなたに贈る、心を折らないための読み物
こんにちは。VTRyoです。 2024年現在、株式会社マネーフォワードでSREをしています。 ここ以外でも活動しているので、気になったらジャンプしてみてください。 VTRyo Tech Blog VTRyo MoneyForward Developers Blog VTRyo (@vtryo) on Speaker Deck VTRyo note VTRyo Qiita VTRyo 商業誌 ITエンジニアのための偶然から始めるキャリアプラン －好奇心が導く予想しない未来－ | VTRyo, MBビジネス研究班, MBビジネス研究班 | 工学 | Kindleストア | Amazon 働き方アップグレードガイド (技術の泉シリーズ（NextPublishing）) | VTRyo | 工学 | Kindleストア | Amazon VTRyo 技術同人誌 VTRyo - BOOTH Grow
「コスト削減」というパワーワードに負けずにコストコントロールを素早く進めたい
この記事は株式会社 X-Tech5 CTOの、ばば（netmarkjp）が書きました。 事業でのコストコントロールは永遠の課題ですね。クラウドサービスのコストコントロールは昨年あたりから特に大きく取り上げられている印象です。 キーワードとしては「コスト削減」や「コスト最適化」がよく使われます。ここではまるっとコストコントロールと呼びます。 わたしはお仕事で色々な会社のSREの実践や体制構築をお手伝いするSREサービスや、SRE/オブザーバビリティの導入・定着支援をしています。 各種クラウドサービスのコストコントロールの機会も多々あるので、その中で得たクラウドサービスのコストコントロールにスムーズに取り組むためのヒントを共有します。 同じ成果なら支出は少ないほうが嬉しい 何をいまさら、という感じかもしれませんが、支出は少ないほうが嬉しいですよね。それはそう。 ただ、この「同じ成果なら」という
GoプロジェクトへのOpenTelemetry計装でeBPF自動計装を採用しなかった話
既存GoプロジェクトにOpenTelemetryを計装する機会がありました。eBPFによる自動計装ではなく、手動計装を選んだ理由を説明します。 GoアプリケーションへのOpenTelemetry計装手段 Goにおいては、OpenTelemetryの自動計装が公式で用意されていません。公式サイトにAutomaticの章がないことからわかります。おそらく、ランタイムの制約で実行時にアプリケーションの挙動を変えることが難しいのでしょう。 トレースに十分なスパンを含めるために、現状では以下の2つの計装手段があります。既存のGoアプリケーションに導入する手間や影響範囲をイメージいただくために、概要に絞って解説します。 手動計装 eBPFによる自動計装（Work In Progres） 1. 手動計装 まず、OpenTelemetryのSDKをインストールし、セットアップをします。 func main
SLO期間が28日のとき、アラートの閾値をバーンレート14.4にしてよいのか
これを参考にしているのでしょう、バーンレート14.4や6をアラートの閾値としている例をちらほら見かけます。 14.4には暗黙の前提がある しかし、先の表には暗黙の前提があります。SLOの期間が30日と仮定されているのです。 バーンレートの定義上、SLOの全期間でエラーバジェットをちょうど消費し終える速度が「1」です。 表の最下行でバーンレートが1なのは、期間が30日だからです。30日の10%＝3日で、10％のエラーバジェットを消費するのですから、バーンレートは1となります。 計算式にすると下記の通りです。 2% * (30d / 1h) = 0.02 * 720 = 14.4 5% * (30d / 6h) = 0.05 * 120 = 6 10% * (30d / 3d) = 0.10 * 10 = 1 先の表と整合していますね。 SLO期間が28日だと13.44になる 一方で同書の2章
巻頭言：Four keysの"Change lead time"をちょっと深堀る
ありがたいことに第２号も発刊できました。ご協力いただけました皆様にここで感謝申し上げます。 今回の巻頭言は、Four keysの"Change lead time"についてちょっと深堀りしてみた話を書いていきます。 Four keysとは “State of DevOps Report"という、毎年DORA(Devops Research And Assessment)社によって発刊されている、DevOpsに関わるエンジニアのアンケートを元に統計を取り、考察・研究されたレポートがあります。 Four keysはその2014年度に発刊されたレポートで発表され、「ITパフォーマンスを測る指標」というものでした。（ITパフォーマンスってザックリした言葉ですね） そんなFour keysは以下の4つの指標で構成されています。 Deployment frequency（デプロイ頻度） Lead ti
002号（2024/05/01）
巻頭言：Four keysの"Change lead time"をちょっと深堀る 書いた人：しょっさん（ @syossan27 ） Four keysの指標の一つ、“Change lead time"について気になるところをちょこっと深堀りしてみました。 SLO期間が28日のとき、アラートの閾値をバーンレート14.4にしてよいのか 書いた人：iwamot さん（ @iwamot ） SLOの期間に関わらず、バーンレート14.4をアラートの閾値としている例を見かけます。14.4が常に最適なのか、考えてみましょう。 GoプロジェクトへのOpenTelemetry計装でeBPF自動計装を採用しなかった話 書いた人：sumiren さん（ @sumiren_t ） 既存GoプロジェクトにOpenTelemetryを計装する機会がありました。eBPFによる自動計装ではなく手動計装を選んだ理由を説明し
『LeanとDevOpsの科学』をきちんと解読する 〜Four Keys だけじゃ絶対もったいなくなる話〜
スクラムフェス福岡2024での講演資料です。 --- 皆さん、職場でFour Keysを導入していますか？ Yesと答えた皆さん、『LeanとDevOpsの科学』は読みましたか？ あくまで僕の周囲のみの観測で語るのですが、Four Keysを職場で導入しているという人はとても多いので…
SREに触れて「いろいろやろうぜ」のモードになった - 生涯未熟
SRE界隈の隅っこでワチャワチャやっているしょっさんです。 今色々やっているコミュニティ活動についてのお話を書き留めておきたいなと思ったので、ここにパパッと書いていきます。 今までについて 今までのコミュニティ活動の関わりについては以下のしずかなインターネットの記事として書きました。 sizu.me そんなこんなで「ゆるSRE勉強会」の運営に関わらせていただいているのですが、せっかく再びコミュニティ活動始めたなら色々やってみっか！ってことで色々走らせてみました。 SRE Magazine SREに関する記事を探すと様々なところに散らばっており、SRE Weeklyみたいな集約された場所があると面白いよな〜ということでエイヤの精神でやってみました。 sre-magazine.net 「るびま」を参考に構成しているWebマガジンなのですが、最近第１号が発刊することができました。で、始めるにあた
巻頭言：SRE Magazineを始めました
はじめまして、しょっさんと申します。 この度、SRE Magazine始めました。 何故始めたのかというと、国内においてSREについての情報が集まる場があまり無いなと思っていて、無いなら作っちゃえということで以下のツイートで寄稿者を募ってみました。 【！募集！】 SRE Magazineという"るびま"のようなWebマガジンを始めたいのですが、SREに関する記事を投稿してもいいよ！という方いらっしゃいますでしょうか？👀 内容はどんなものでも問題ありませんので、気になる方はDM等でご連絡ください！🙏 また、拡散もしていただけると助かります！🙇 — しょっさん@ʕ ◔ϖ◔ʔ (@syossan27) March 3, 2024 有り難いことに多くの方に反応頂けたことで「これは自分以外にも需要はありそうだな」ということで、走り始めました。 このTwitterで反応を伺ってから走り始めるの
SRE Magazine - 001号（2024/04/01）
巻頭言：SRE Magazineを始めました 書いた人：しょっさん（ @syossan27 ） SRE Magazineの発刊についての想いなどを書いてます。 ばばさんがお勧めする「SRE入門」と「SRE入門の入門」に効く書籍や文章 書いた人：ばば/netmarkjp さん（ @netmarkjp ） SRE入門に効く書籍や文章を紹介しています。 非常時の可用性をフィーチャーフラグで保つアイディア 書いた人：iwamot さん（ @iwamot ） アクセス急増などの非常時でも可用性を保つ手法に「緊急レバー」があります。この記事では、緊急レバーの実装にフィーチャーフラグを用いるアイディアを提示します。 SIEMってサイトの信頼性向上に寄与するの？ 書いた人：Yuta Kawasaki（ゆーた）さん（ @yuta_k0911 ） SIEM on Amazon OpenSearch Servi
自作RDBMSやろうぜ!
Skip to the content. 自作RDBMSやろうぜ! このサイトの目的 RDBMS（いわゆるリレーショナルデータベース）というものはプログラミング言語の処理系や、OSなどと同様に、世の中で広く使われているソフトウェアであるにも関わらず、いざ自作してみようと思うと日本語で記述されたサイトや書籍で、必要な情報・情報源がまとまったものがないことに気づきました そこで、叩き台として、本サイト管理人および数名のコミッタで開発している自作RDBMSである SamehadaDB が軌道に乗るまでの経験をベースに、自作RDBMSするための道筋をある程度整理して書き記してみました 各々の情報・情報源はあいかわらず多くが英語で記述されていますが、その点はご容赦下さい なお、本サイトは技術的な解説を提供するのではなく、適切と思われる情報・情報源をポイントするようなサイトとなることを想定しています
いつか起業したいエンジニアへ - Qiita
はじめに 34 歳のとき、勤めていた会社の経営が傾き早期退職を促されたのを契機に独立しました。その後、41 歳で Authleteオースリート 社を設立しました。諸般の事情で現在も Authlete 社の代表取締役という肩書きを持っていますが、経営者的な仕事は他の人に任せ (参照: シリコンバレーのプロフェッショナル CEO を迎えて米国市場に挑戦する日本のスタートアップの話)、50 歳目前の現在もプログラマとしてコードを書き続けています。 Authlete 社設立 (2015 年 9 月) から 8 年半弱経過したものの、まだまだ小さな会社で道半ばであるため、起業家として何か語るのは時期尚早ではあるものの、軽い体調不良が長引く中、『自分のエンジニアとしてキャリアを振り返ろう！』という記事投稿キャンペーンを見かけ、生きているうちに子供世代のエンジニアの方々に何か書き残しておこうと思い、文章
転職時に無職になる手続きをインターネットでする
転職する際に空白期間がない場合は会社側で手続きがほとんど終わりますが、一旦無職を挟んで転職する場合は、保険証、年金、iDeCoなどの手続きが必要になります。 今回の転職活動にあたって、 この手続きをするのに市役所やプリンターを使いたくないので、インターネットだけで完結できるかにトライしました。 Open Job Letterを公開しました | Web Scratch 手続きの前提条件 会社や個人によって前提が異なるので、ここでは次の前提で記事を書いています。 会社員: 厚生年金 保険証: ［ITS］関東ITソフトウェア健康保険組合 iDeCo: 個人型確定拠出年金 退職して次の会社が決まってない場合は、保険証や年金などの手続きが必要になります。 保険証: 国民健康保険か任意継続かは好きな方で 今回は任意継続を選択 年金: 厚生年金から国民年金第1号へ切り替える iDeCo: 「加入者被保険
GKEの開発環境クラスタはとりあえず「使用率の最適化」やっとこう - 生涯未熟
GKE / k8s、まだまだ分からんことが多くて学び甲斐があるなぁとしみじみ思っている今日この頃。 今回はそんな中で掲題のコスト最適化のお話をします。 要約 本番環境が載っていないクラスタは自動スケーリング プロファイルをoptimize-utilization（使用率の最適化）やっとくと良い 特に短いスパンでのCronJobを動かしているとコスト改善の可能性大 前提 GKEを使ってサービス運用している時に気になるのはやはりコストですよね。私が関わっているサービスでもコストをもう少し下げようといった声が大きくなり、その中でも大きな割合が割かれているGKEに注目が集まりました。 こういう時、まず手を付けるのは開発環境周りですね。Develop, Staging環境などを一つのクラスタで管理しており、ここなら最悪ぶっ壊しても問題なく着手しやすいのでここからやっていきます。 やったこと やったこ
GitHubのorganization移行をやったお話 - 生涯未熟
この記事はSRE Advent Calendar 2023の１日目の記事です。 今回は業務で「GitHubリポジトリをあるorganization（以下、org）から別のorgへ移行させる」ということをやったので、その時のお話をさせていただきます。 何をするのか？ もう少し、何を目標としていたのか？を具体的に書くと、現在リポジトリ群が所属しているorgからGitHub Enterprise Cloud（以下、GHEC）配下に作成したorgへ移行させる、ということをやろうとしたお話になります。 GHECに移行するモチベーションとしてはGitHub Copilot for Businessが利用できたり、SAML SSOを利用できたりするというメリットを受けることが出来るからですね。（開発者にとってはCopilotが理由として大きいかも） 移行前の状況 移行前は以下のような状況でした。 自分が
Building high-performance GraphQL APIs
One day you decided to give GraphQL a try and implement an API of your new application using GraphQL. You deployed the app to production, but after a while, you realized, that responses are not super fast. How to find out what makes your GraphQL endpoint slow? We’ll discuss how queries are executed and what makes processing slower. After that, we’ll learn how to measure performance in the GraphQL
2023 State of DevOps Reportを読んだ - 生涯未熟
今年もState of DevOps Reportが発表されましたね。ということで、ザザッと全体を読んで気になったところなどピックアップして読み解いてみました。 全文が気になる方は以下からPDFをダウンロードしてみてください。 cloud.google.com 今年の調査主軸 組織の業績 組織は収益だけでなく、顧客のため、さらに広範なコミュニティのために価値を生み出さなければならない チームパフォーマンス アプリケーションまたはサービスチームが価値を創造し、革新し、協力する能力 従業員の幸福 組織やチームが採用する戦略は、従業員にとって有益なものでなければならない。すなわち、燃え尽きを減らし、満足のいく仕事体験を育み、価値あるアウトプット（つまり生産性）を生み出す能力を高めることである。 今回は上記３つの成果達成に対しての調査となった。 調査結果短評 生成的な文化を持つチームは、組織のパフ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
⾃律的な開発チームを⽀えるためのSLO運⽤
