SLI/SLOを策定し、New Relicで可視化する - dip Engineer Blog
本記事はNew Relic Advent Calendar 2023の25日目の記事となります。 qiita.com はじめに こんにちは。はたらこねっとのユーザー向けサイトのバックエンドエンジニアをしている大塚です。 はたらこねっとではサービスのモニタリングなどにNew Relicを活用しています。 New Relic にはアプリケーションのモニタリング以外にも様々な機能が用意されています。 その中でも「Service Levels」の機能を使ったSLI/SLOの策定と設定を行っているので、そちらについてご紹介させて頂きます。 なお、細かい操作方法などは本記事では触れません。 本記事で登場する用語について クリティカル ユーザー ジャーニー（CUJ） ユーザーがサービスを利用する際の重要な経路やプロセスを表したものです。 サービスレベル指標（SLI） サービスレベルを測定するための具体的
SREエンジニアのSLI/SLO導入への挑戦 - ぐるなびをちょっと良くするエンジニアブログ
こんにちは。データ・AI戦略部 SREチームの小野です。2020年8月に入社してから早3年。SREエンジニアとして、日々業務改善に励んでいます。 ここ一年ほど、DAOという組織改善プロジェクトを推進してきました。このプロジェクトは組織内で発生するあらゆるイベントを「機能」として定義・実装し、それらを束ねてサービスとして組織内外に提供するプロジェクトです。 ※ 詳細はSREエンジニアが組織改善プロジェクトを立ち上げてみたを参照ください これまでの通常業務をサービスとして提供するという考え方は、我ながらとてもユニークかつ俊逸な発想だったと感じています。なぜなら、このサービスベースな考え方により組織にSLI/SLOを導入しやすくなったためです。 SLI/SLOの導入は個人的に難しいと考えています。導入するためにはさまざまな「ハードル」を突破する必要があるためです。しかし一方で、SLI/SLOを導
SREがたどる4つのフェーズ - Paper2 Blog
SREのプラクティス導入による文化面の変化などを踏まえ、「火消し」「門番」「パートナー」「触媒」の4フェーズを紹介します。自チームの現状把握と今後の方向性を検討する上での材料になったら幸いです。*1 火消しフェーズ 火消しフェーズ 初期段階では開発チームが機能開発のタスク（Feature Task）に注力し、サービスに必要な信頼性に関するタスク（Reliability Task）が対応領域に含まれないことがあります。このフェーズではSREチームが火消し部隊としてReliability Taskを巻き取り、信頼性の向上に努めます。コラボレーションなどは考慮されず、火消しが最優先となります。そのため、Reliability TaskはSREチームだけが処理するものとなっていき、後の門番フェーズに突入します。 門番フェーズ 門番フェーズ 信頼性に関するタスクの大部分をSREチームが対応しているフ
サービスの信頼性と可用性を担保するSREが目指す「サイバーエージェント流ベストプラクティス」模索の道のり 技術・デザイン
柘植 翔太 メディア統括本部サービスリライアビリティグループ マネージャー / SRE 2014年新卒入社。インフラエンジニア、SREとして、AMEBA、AWA、社内基盤など50以上のメディアサービス・システムへのSRE推進、リスク改善、サービス立ち上げを経験。現在は、横断SRE組織のマネージャーとして、SREのEnablementや人材育成へ注力している。 ── 柘植さんの現在の役割をおしえてください 私は、メディア事業横断のSRE組織のマネージャーをしています。主にメディア事業を担当し「Ameba」「AWA」「タップル」「CL」「社内基盤」など様々なサービスやシステムへのSRE導入をしてきました。また、インターネット広告事業やゲーム・エンターテイメント事業とも連携しながら、横断的なSRE(Site Reliability Engineering)組織を構築する事を目指しています。 この
コアSREチームからサービスチーム側に落下傘してみてた話 - エムスリーテックブログ
皆さんこんにちは、エンジニアリンググループの高橋(@tshohe1)です。 この記事はエムスリーSREがお届けするブログリレーの15日目です。 他の記事でも何度か説明されていますが、エムスリーでは2019年頃からチーム横断的なシステムを管理する「コアSRE」とは別に、サービスチーム内にて各サービスのインフラを重点的に見る「チームSRE」というポジションを新たに設けています（チームSRE化の流れの詳細については下記ブログリレー最初の記事*1を御覧ください）。 私は入社時点ではコアSRE（当時はまだインフラチーム*2）として働いていましたが、2019年頃からサービスチーム側SREと兼務したりコアSREに戻ったりまたチーム側SREに移動したりとふらふらしている謎の存在になっていました。 現時点ではコア/チーム側両方に所属していた者はいないはずなので、本記事ではコアSRE側の視点/チームSRE側の
[資料公開] DevOpsとSREのために知るべき3つの原則 〜忙しすぎるエンジニアのための開発環境リファクタリングガイド〜 #devio2023 | DevelopersIO
盛況のうちに閉幕しましたオフラインイベント。お暑い中多数のご来場をいただき、ほんとうにありがとうございました！ 2日目 7/8 の 15:10 より、標題の 長すぎる タイトルのセッションで登壇しました。その時に資料を公開します。 「開発環境」と銘打っていますが、運用がメイン担当であるエンジニアの方にとってもヒントになるものを盛り込めたのではないかなーと自負しています。 *1 内容 日々大切なアプリケーションを開発されている開発者の方々のなかには、開発基盤やパイプラインに何かしらの課題を感じている方も多いのではないでしょうか。 それらを一撃で吹き飛ばす特効薬「銀の弾丸」はもちろん存在しませんが、その一部は、ツールや手法・考え方の工夫次第で軽減できるものかもしれません。 状況の変化に合わせて武器や装備を整え直すRPG（ロールプレイングゲーム）のように、開発環境やパイプラインに改善の余地はない
![[資料公開] DevOpsとSREのために知るべき3つの原則 〜忙しすぎるエンジニアのための開発環境リファクタリングガイド〜 #devio2023 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/bd645ea7ea4c43ccbe3f3fdc22958f3a1111361b/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2023%2F07%2F202307-session-sdlc-refactoring-guide-devio2023-eyecatch.png)
データで見るサイバーエージェントグループのSREと横断的なSRE推進の取り組み | CyberAgent Developers Blog
サイバーエージェントグループには、様々なSRE組織があり、日々サービスの信頼性向上に取り組んでいます。 6月27日〜28日にかけて開催した「CyberAgent Developer Conference 2023」では、当社のDeveloper Experts（SRE領域）を務める柘植が、サイバーエージェントグループのSRE組織やSREsの活動についてもご紹介しました。 柘植 翔太 2014年新卒入社。インフラエンジニア、SREとして、AMEBA、AWA、社内基盤など50以上のメディアサービス・システムへのSRE推進、リスク改善、サービス立ち上げを経験。現在は、横断SRE組織のマネージャーとして、SREのプラクティス開発やEnablement、人材育成へ注力している。 サービスリライアビティグループというメディア事業横断のSRE組織のマネージャーをしている柘植と申します。本日はデータで見る
マネーフォワードのSRE、インフラエンジニア組織のこれから - Money Forward Developers Blog
こんにちは。12/1 サービス基盤本部の本部長を務めている鈴木(@syou1024) です。 マネーフォワードの全社のサービスのインフラ関連の組織について、今までとこれからについて話そうと思います。同じような悩みを持つ方のヒントになったり、またマネーフォワードのSRE、インフラエンジニアに興味を持って頂けたら嬉しいです。 サービスのインフラチームの歴史 現在のマネーフォワードでは、全社のプロダクトのインフラを担当するサービスインフラチーム、幾つかのプロダクトの開発チームの中に存在するプロダクトのSREチームと、複数のインフラ、SREチームが存在します。 サービスインフラチームはサービ基盤本部に所属していて私が管掌しています。また、サービス基盤本部の本部長就任前にプロダクトのSREチームを一番最初に作ったのも私です。 マネーフォワードのインフラの組織が「なぜそうなってるのか？」。まずは私から
SRE チームをよりサステナブルにするために Vision/Mission/Values を作った話 - スタディサプリ Product Team Blog
小中高 SRE チームで Engineering Manager をやっている @yuya-takeyama です。 Quipper にはスタディサプリ ENGLISH の SRE である ENGLISH SRE チームと合わせて 2 つの SRE チームがありますが、この記事では自分たち小中高 SRE チームについての話です。 少し前の話になるんですが、小中高 SRE チームの Vision, Mission, Values というものをチームで作りました。 Quipper には会社としての Vision, Mission そして Quipper Identities というものがあります。 これらは策定から数年以上経っていますが、Quipper の社員にとって今も変わらず大事なものです。 が、SRE チームにとっては教育や学習に対して直接的に貢献しているとは言いづらい状況です。 そこで
「6社合同 SRE勉強会」で学んだこと
以下イベントを見てたときのメモ的なあれです。SREの初学者目線で学べたことを書きました。全ては見れてません。 全体通して学んだこと 「SREとは」といったところから定義しているところが多かった こうしないとインフラエンジニアの名称が変わっただけのただの便利屋になってしまう 何ができて何をするのか https://blog.studysapuri.jp/entry/sre-vision-mission-values SREはSREでも種類があったりした CenterOfPractice(CoreSRE、pureSRE、横断SREなど) 全社としてのSRE ベストプラクティスの策定 ツールの選定や開発 EmbeddedSRE プロダクト開発チーム内としてのSRE Embeddedだと外から埋め込むという意味合いになってしまうので、内部からの場合はenablingといった表現をしている会社もあっ
テックリードがどんな活動したらよいのか考えて行動してみた話 - ZOZO TECH BLOG
2022年6月に、Androidテックリードになった いわたん です。最近、某モンスターを育てたり図鑑を埋めたりするゲームで社内大会をやったらフルボッコにされて涙目でした。悔しくて最近は不思議な力でクラフトしたり空飛んだりして王国を救うゲームやってます。 今回はAndroidテックリードとして1年間やってみた施策の紹介と、それぞれの成果や反省点を紹介したいと思います。これからテックリードになろうとしている方やテックリードをしている方の参考になったり、こんな施策もいいよというアドバイスをもらえたら幸いです。 ZOZOのテックリードの役割と責任 実施した施策 テックリード1on1 読書会 歴史的経緯があるアプリのアーキテクチャ整理へのアプローチ ネーミングセンスを鍛える会の取り組み 案件への関わり方 横断的なコードレビュー 横断的に使う機能の実装 まとめ 最後に ZOZOのテックリードの役割と
なんとなくで終わらせない、言語化すると見えてくる障害調査の5つのポイント - エムスリーテックブログ
【SREチーム ブログリレー4回目】 こんにちは、SREチームの後藤です。 障害が発生した時、魔法のように原因を特定し颯爽と解決していくスーパーな同僚は皆様の周りにもいませんか? その姿に憧れてそうなりたいと思ったことが誰しも一度はあるはず。 ですが、話を聞いてみると「なんとなく怪しそうだった」「勘でここかなと思った」と言われたりして、まったく参考にならなかったこともあるのではないでしょうか。 そこで今回は私が考える障害調査において意識すべきポイントを、なんとなくではなくしっかりと言語化してまとめたいと思います。 題して「なんとなくで終わらせない、言語化すると見えてくる障害調査の5つのポイント」 神頼みしたくなる時も挫けずに強い心を持つことも大事 1. 調査できるように備えておく 2. 事象を正確に把握する 3. 事実と推測を区別する 4. 先入観を排除する 5. 問題を局所化する まとめ
アジャイルなSREチームの運用
LAPRAS株式会社でSREをしているyktakaha4と申します🐧 弊社のSREチームで最近運用をはじめた見積もりやふりかえりの手法について書きたいと思います 大規模な立ち上がり済みの組織向けでなく、今ひとりで仕事をしている人が2人目のSREを迎え入れたときの一事例としてご覧ください 経緯 弊社は2016年に創業して以来、ソフトウェアエンジニアとして入社した社員がアプリケーションからクラウドまでプロダクト全体を開発・運用するというスタイルが取られていましたが、 エンジニア組織の拡大に伴い、2021年頃からプロダクトの信頼性や可用性の向上を責務とする専任のSREを立ててシステムの改善をおこなってきました 以下は、弊社で導入しているホラクラシーに基づいて定義された Site Reliabilityサークル のロールの一覧です 原則として、ロールは誰であっても自由に負うことができるので、主務
SLOをもっとカジュアルに活用しよう
はじめに こんにちは。Google Cloudでオブザーバビリティの担当をしているものです。 昨日、シンガポールで開催されたスタートアップ向けのイベントにリモート登壇したのですが、そこでスタートアップでもSLOを活用しましょう、というテーマで話しました。 せっかくなので日本語にしておこうと思い、スライドを抜粋しながら内容の一部を記事にしておこうと思います。発表内容を記事化してるので、文体が少し発表のようになっているのはご容赦ください。 「ユーザーからの信頼性」が大切 まず、スタートアップ、さらにはWebサービスに限らず、あらゆる事業において、顧客に対する信頼は重要です。荷物が全然届かない配送業者は利用したくないですし、接続してもつながらないISPは契約したくありません。飛行機も統計上事故の確率が低いから利用するわけで、自動車並に事故が発生していたら絶対利用しません。日々私たちがさまざまなサ
SREチーム体制について - JCB Tech Blog
本稿はJCB Advent Calendar 2022の12/20の記事です。 JCB デジタルソリューション開発部 SREチームの笹野と申します。 今回はJDEP（JCB Digital Enablement Platform） におけるSREチームの体制ついてご紹介します。 SREチームとは JDEPではGoogleが提唱しているSRE(Site Reliability Engineering)の考え方をベースにチームを組成しています。 ミッションとして、各アプリチームが継続的に(信頼性高く)サービスを提供できる状態を提供することを掲げており、 ひいては、JDEPで提供するサービスを使用するお客様の満足度を維持することを目的としています。 こうしたミッションをもとに、各工程での取り組みをSREとして実践すること、また各アプリチームにSREの考え方や手法を注入することを日々実施しています
SRE室の紹介 & Embedded SRE/Enabling SREとしてのお仕事紹介 - febc技術メモ
本投稿は、さくらインターネットアドベントカレンダー2022の14日目の投稿です。 この記事では2022年7月に発足した「SRE室」という部署について+これまで私が取り組んできたお仕事の一部を紹介します。 はじめに さくらインターネットへ入職しSRE室で働き始めてからもうすぐ半年となります。 febc-yamamoto.hatenablog.jp 新しい環境に慣れるまで苦労しましたが、ここ数ヶ月はだいぶ落ち着いてきており、最近は毎日の仕事がとても楽しく感じられています。 これまでSRE室としての取り組みをあまり紹介できていませんでしたが、せっかくのアドベントカレンダーという機会なのでここで紹介させていただきます。 SRE室の紹介 SRE室とは 2022年7月に発足したばかりの新しめの部署です。 以下のような企業理念/ミッション/ビジョン/バリューに従い日々の業務へ取り組んでいます。 企業理念
これからはじめる 実践SRE / SLO の監視をやってみよう
SRE がアツいですね。 昨年は以前に増して SRE 関連のイベントも増え、SRE 人材への注目も更に高まっていると感じた 1 年でした。私も Google Cloud の Customer Engineer として、お客様へ SRE のお話をする機会が増えてきています。 ご存知の通り、SRE は Google から生まれた運用プラクティス、またはそのロール自体を指す言葉です。 詳細は無料で読むことができる書籍を御覧ください。 “Site Reliability Engineering” 及び “The Site Reliability Workbook” （右上の右2つ）は HTML 形式 なので、Google Chrome で右クリックして 翻訳を選択するという簡単な手順で日本語でも読むことができます。（書籍がよい方は日本語版も購入できます。） 今回のテーマは SLO (Service
AIOps研究録―SREのためのシステム障害の自動原因診断
5/14 12:30 - 13:15 How We Foster "Reliability" in DiversitySRE において「信頼性」は最も重要な指標とされています。しかし、一言で「信頼性」といっても、会社の戦略やサービス、文化によって、計測方法や目指す値、その達成方法にいたる全てが同じになることはないでしょう。さらに、一度定義した信頼性が適切であり続けることはなく、会社や組織のフェーズによって、その時々で柔軟に変化していく必要がありそうです。 このように、サービスを取り巻く環境の変化に応じて適切な信頼性を定義し、またその信頼性を「育てて」いく方法として、サービスや組織の戦略と SRE チーム の方向性を揃えたり、SRE チームの垣根を超えて組織全体に SRE の文化を根付かせるための取り組みなどを紹介しながら、多様性とともに SRE がどのように歩んでいくかについてお話します。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
2022年11月9日NRU303_配布用
https://newrelic.com/sites/default/files/2022-02/NRU303_SLISLO_20220222.pdf