The Art of SLOsは、GoogleのCustomer Reliability Engineeringチームによって開発されたワークショップです。このワークショップの目的は、Googleがサービスの信頼性を計測する方法 サービスレベル指標(SLI) とサービスレベル目標 (SLO)を参加者に紹介し、実際にこれらの計測方法を作成することを体験してもらうことです。これらは重要で土台となる概念です。サービスの信頼性を客観的に測定する方法があれば、サービスの信頼性について有意義な会話をすることがはるかに簡単になります。 ワークショップの理論編では、開発チームと運用チームの間でしばしば生じる組織的な緊張を、サービスの望ましい信頼性を表す目標値を設定することで解決する方法を学びます。また、SLOとエラーバジェットを使って、データ駆動で、客観的、かつユーザー重視の方法でサービスの信頼性を測定・
最近「いかに運用作業に手を抜くか」というのを考えているので、なんとなーくアウトプットしてみようと思う。 運用作業とは? 運用作業はゼロが理想だけど、そーもいかない 運用を頑張りすぎてしまうエンジニア pospomeはどうしているか? まとめ 運用作業とは? 自分が想定する "運用作業" というのは機能開発に関係ない作業全般である。 例えば以下の作業は "運用" にカテゴライズしていいと思う。 ソフトウェアのバージョンアップ ユニットテストの実装・保守 問い合わせ対応 リファクタリング 運用作業はゼロが理想だけど、そーもいかない 自分は運用作業がゼロになるのが理想だと思っている。 可能であれば、機能開発にすべての工数を投じて、自身が開発するプロダクトを進化させていきたい。 ただ、運用作業をゼロにするのは不可能である。 ソフトウェアのバージョンアップは定期的にしなければいけないし、リファクタリ
SLO策定とアラート設定までの長い道のり - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、@ueokandeです。早速ですが、皆さんが運用しているサービスには、SLO (Service-level objective: サービスレベル目標) がありますか？アラートの監視項目はどのように設定して、基準値をどのように決めていますか？ 社外とのコミュニケーションだけでなく、社内向けのSLOを決めておくことで、サービスの健康状態を知るための手がかりや、普段の開発・運用タスクの優先度を決める上での指標にもなります。 またSLOがあると、サービスを監視するアラートに、理にかなった閾値を設定できます。 この記事ではAWS版kintoneの、SLOとアラートを設定するまでの記録について紹介します。 cybozu.com版kintoneのSLOとアラート 国内のcybozu.comで運用しているkintoneにも、もちろんSLOやアラートはあります。 しかし現状のSLOはkinton
SLOを活用した技術的改善
株式会社タイミーではスキマバイトプラットフォームを開発・運用しています。サービスもリリースして3年を超え、"負債"と呼ばれるものが増えてきました。一方でビジネス的に開発したいものは後を絶ちません。そこで開発チームでSLOを制定し、サービスの健全な状態を測定・監視することで「システムが健全にサービス提供できているか」を調べ、必要なときに必要な改修を行えるようにしました。本セッションでは弊社のSLOの解釈や利用方法を伝えるとともに、実際に感じたメリットや行われた技術的改善を紹介します。 セッション動画 https://www.youtube.com/watch?v=VburNEFcg64
「マンガが快適に読める」を数値化し、SLOをマンガビューワに導入するまで - Hatena Developer Blog
マンガビューワにおけるサービスレベルとは なぜSLOを策定したかったのか サービスレベルを単純に決める 何をサービスレベル指標としてどう計測するか 一般的なSLIの表現 期間を移動しながら集計する アクセスログからサーバーのSLIを計測する PageSpeed Insights APIでフロントエンドを計測 プロダクトオーナーとともにSLOを決定する 決定したSLO どのように監視するか まとめ 株式会社はてなのマンガチームでSREをしているhappy_siroです。 私がチームで担当しているサービスは、いくつかのWebマンガサイトで採用されている「GigaViewer」というマンガビューワです。 GigaViewerチームでは、サービスのSLOを策定しました。 理由は、SLOに基づいて開発速度と信頼性のバランスをとるためです。 この記事では、私がチームメンバーと協力して「GigaView
https://sre-lounge.connpass.com/event/227250/
SLOをゼロからつくる
tfnotify - Show Terraform execution plan beautifully on GitHub
New RelicではどのようにSLI/SLOを定義し、SREを実践しているか。その経験から、SLI/SLOについて解説した記事 Best Practices for Setting SLOs and SLIs For Modern, Complex Systems の翻訳です。 -- New Relicのサイト信頼性VPであるMatthew Flamingも、この記事に貢献しています。この記事はサンフランシスコその他で行ったFutreStack18での講演「SLOs and SLIs In The Real World: A Deep Dive.」をもとに作られています。 New Relicでは、サービスレベル指標（Service Level Indicator: SLI）とサービスレベル目標（Service Level Objective: SLO）を定義したり設定したりことが、サイト
Exadata Database Service on Dedicated Infrastructure(ExaDB-D) UI スクリーン・キャプチャ集
こんにちは、広告サービスを担当している飛田です。 今回は "SLO導入で悩んでいる方" に向けて、弊社リワード広告サービスでのSLO策定の取り組みについてお話したいと思います。 そもそもSLOを策定するに至った経緯は二つあります。 ユーザへの影響度合いが分かりづらいパフォーマンス問題などの対応が後回しにされがちで、品質改善がなかなか進まない アラート通知があってもユーザに影響があるか即座に判断できず、静観や一部アラートを無視する状況もあり、モニタリングが形骸化しつつある 両方とも共通してユーザに与える影響を正しく把握できていないことが課題のようです。 そこでSLOを策定する過程でオブザーバビリティを高め、モニタリングの最適化とエラーバジェット運用で開発リソース配分の状況改善を図りました。 一挙両得作戦です。 細かな取り組みは順を追って紹介します。 プロジェクト初期 ワークメトリクスからSL
WebアプリケーションにGoの並行処理アーキテクチャを導入してSLOを改善し、WebAPIを100倍速くした話 - スタディサプリ Product Team Blog
こんにちは。スタディサプリの小中高プロダクト基盤開発グループでProduct Platform Engineer兼テックリードをやっている@tooooooooomyです。 今回は、WebアプリケーションにGoの並行処理機構を導入してSLOを改善し、WebAPIを100倍速くした話をしたいと思います。 前提条件 システムを0から作らない場合、アーキテクチャの改善の際には前提条件が付きものです。そこでまずは今回のシステムの前提条件をお話します。 対象となるシステムと、アーキテクチャ 今回対象とするシステムは、ここでは security-tracker と呼び、Webアプリケーション本体はGoで書かれています。 スタディサプリの各アプリケーションにおけるユーザーのログ1を、Amazon Kinesis Firehoseを通して、リクルート全体のセキュリティチームが管理するS3バケット(スタディサ
はじめにはじめまして、原木と申します。 皆さまはSRE NEXTをご覧になりましたでしょうか？ SRE NEXTは 先日実施された『信頼性に関するプラクティスに深い関心を持つエンジニアのためのカンファレンス』です。国内外のエンジニアが日々SRE(サイト信頼性エンジニアリング/Site Reliability Engineering)の実践手法を共有することで、Webサービスが今後運用、成長していくための次世代の信頼性を担おうとしています。 もしもWebサービスの運用を安定的に行う手法やそのためのチームビルディングに興味がある場合、SRE NEXTの動画セッションやスライドが公開されると思うのでご覧ください1。 さて本ブログではそんなSREとも関係の深い、OpenSLOに関して取り上げたいと思います。 OpenSLOとは最近、SLOモニタリングという言葉が注目を集めつつあります。例えば、Go
SRE Lounge #13 での発表資料です。 https://sre-lounge.connpass.com/event/227250/
「SLO サービスレベル目標」という本が出版されました #slobook - YAMAGUCHI::weblog
はじめに こんにちは、Google Cloudのオブザーバビリティ担当者です。このたび私が翻訳ならびに監修として関わった「SLO サービスレベル目標」という本がオライリー・ジャパン社より出版されました。本日より書店ならびに各社オンラインストアでご購入いただけます。 SLO サービスレベル目標 ―SLI、SLO、エラーバジェット導入の実践ガイド 作者:Alex HidalgoオライリージャパンAmazon 電子書籍版についてはオライリー・ジャパンのサイトよりePub、PDFの各種フォーマットにてご購入いただけます。 www.oreilly.co.jp SLOがなぜ重要なのか まず本書の意義について解説する前に、サービスレベル目標（Service Level Objective; SLO）がなぜ重要なのかについて改めてお伝えしたいと思います。 サイトリライアビリティエンジニアリング（SRE）に
SLI/SLO運用の実践 shimesabaによる指標モニタリング - KAYAC engineers' blog
カヤックSREの池田です。 先月は、カヤックのプロダクトの一つ『Tonamel』で導入したエラーバジェット算出ツール『shimesaba』の話をしました。 techblog.kayac.com github.com 今回は、実際にどのようにSLI/SLOを運用しているのか？という内容をshimesabaを使った設定例を交えつつ話します。 SLI/SLOの運用にお悩みの方の助けになれば幸いです。 最初のSLI/SLOはどう決定したのか？ SLI/SLOの運用を始めるにあたって、多くの人が悩むのは以下の２つだと思います。 一体何をSLIとすれば良いのか？ 最初のSLOはどのくらいにしたら良いのか？ つまりは、最初の1歩をどうしたら良いか？と言う話ですが、こちらに関しては２つ参考になるものがあります。 『SLO決定のためのArt of SLO』 https://sre-next.dev/2022
ANDPAD TECH TALK 第11回 - 開発チームの生産性向上に取り組むスペシャリスト対談！後編 可視化ツールを導入してみて分かったこと、そして今後の展望 - ANDPAD Tech Blog
こんにちは！アンドパッドの荒瀧です。 「ANDPAD TECH TALK」第11回の配信です！ 今回は、社外ゲストをお招きしたスペシャリト対談回となっており、前編・後編と2回に渡ってお届けします！ 関連エピソード tech.andpad.co.jp 出演 モデレーター: 荒瀧 (EM 兼 エンジニア採用マネージャー) 社内ゲスト: 柴﨑(テックリード) 社外スペシャルゲスト: 近藤宇智朗さん(GMOペパボ株式会社 シニア・プリンシパル) ハイライト 第11回は、社外ゲストをお招きした対談形式のスペシャル回です！ 「開発チームの生産性向上に取り組むスペシャリスト対談！」と題して、 アンドパッドからはテックリードの柴﨑(id:shiba_yu36)、GMOペパボさんからはシニア・プリンシパルの近藤さん(id:udzura)をお呼びして開発チームの生産性向上について語り尽くしていただきました。
SLOをもっとカジュアルに活用しよう
はじめに こんにちは。Google Cloudでオブザーバビリティの担当をしているものです。 昨日、シンガポールで開催されたスタートアップ向けのイベントにリモート登壇したのですが、そこでスタートアップでもSLOを活用しましょう、というテーマで話しました。 せっかくなので日本語にしておこうと思い、スライドを抜粋しながら内容の一部を記事にしておこうと思います。発表内容を記事化してるので、文体が少し発表のようになっているのはご容赦ください。 「ユーザーからの信頼性」が大切 まず、スタートアップ、さらにはWebサービスに限らず、あらゆる事業において、顧客に対する信頼は重要です。荷物が全然届かない配送業者は利用したくないですし、接続してもつながらないISPは契約したくありません。飛行機も統計上事故の確率が低いから利用するわけで、自動車並に事故が発生していたら絶対利用しません。日々私たちがさまざまなサ
SLO サービスレベル目標
サービスレベル目標（SLO）とは、ユーザーの満足度に強い相関があるメトリクスを用いた、開発と運用の目安となるものです。SLOに基づいた運用は、ユーザー視点で高い信頼性を持つサービスを提供する上で最も重要なプラクティスであるとともに、ビジネス指標に紐づく運用方法でもあります。本書は、SLOを導入する際に必要となる基礎概念、実装、文化を解説します。 はじめに、SLOの概要、サービスレベル指標（SLI）の設定、エラーバジェットの使い方などSLOの基本について説明します。そしてSLIとSLOの計測、確率と統計を使ったSLOの活用法、SLOを組み込むアーキテクチャやシステムについて解説します。さらに、組織内での同意の獲得やSLOの提唱など、SLOに基づくアプローチをチームや会社全体に根付かせる効果的な方法を紹介します。 本書への推薦の言葉 序文 監訳者まえがき はじめに 第I部 SLOの開発 1章
我々はこうしてSLI/SLOを設計し 運用を始めました -これからSLI/SLOの運用を始める人に向けて-
SRE大集合！みんなで学ぶ、信頼性を高めるための取り組みLT大会の登壇資料です。 概要 つい先日SLI/SLOの設計が終わりSLOの運用をスタートしましたがそれまでの道のりは楽ではありませんでした。 本LTではCUJの決め方からSLI/SLOの設計と運用を固めるにあたっての進め方についてお話させて頂きます。 以下の聴講者を想定しています。 SLI/SLOをこれからやっていこうと思っている人 運用開始しているけど他社の事例が気になる人
こんにちは、SRE(Site Reliability Enginner) の @showwin です。前回の LAPRASインフラチームで避難訓練を行いました の記事に引き継ぎ、今回もSREチームの取り組みの紹介です。 概要2021年2月からSLI, SLOを定めた運用を開始し、約半年が経過しました。導入の背景や、運用開始までの流れ、実際に運用してみて気付いたことをまとめました。 体制としては、SREチームはフルタイム1名、適宜手伝っていただけるメンバー2名で構成されており、アプリケーションエンジニアが9名です。また、サービスの利用者に対してはSLAを提示しておりません。このような状況下において運用されているという前提で読み進めていただけたら幸いです。 SLO導入に至った経緯前任のインフラエンジニアの退職により、2020年9月より私がその役割を引き継いだのですが、なんとなくカッコ良さそうと
MackerelでSLOとエラーバジェットを運用するためのツール shimesaba - KAYAC engineers' blog
この記事はMackerel Advent Calendar 2021の7日目です。 こんにちは、SREチーム所属の@mashiikeです。 皆様はSLOとエラーバジェットという言葉を聞いたことはありますか？ サービスの信頼性を保証することを目標するSRE（Site Reliability Engineer／Site Reliability Engineering）の領域に携わってる方なら聞いたことがあると思います。 今回は、SLOとエラーバジェットに関して、Mackerelを用いてサービス/サーバー監視をしている際に便利なツールとして shimesaba というものを作った話をします。 github.com はじめに 本題に入る前に、SLIやSLO, エラーバジェットという言葉について触れておきます。 これらの言葉は、ざっくりと説明すると以下のようになります。 SLI(Service Le
Merpay Advent Calendar 2019 の14日目は、メルペイSREチームの@Tがお送りします。 本記事では、メルペイSREチームのSLO運用状況について、紹介いたします。 メルペイリリース前 去年のAdventCalendar 2018で、メルカリのWeb MicroservicesにおけるSLI/SLOについて紹介がありました。 メルペイでは新規のMicroserviceをリリースする前に、各MicroserviceチームがSLOを定義し、品質保持の一指標を決めるルールがあります。 メルペイSREチームでは、Microserviceチームと一緒にSLOを考え、各MicroserviceにSLOを定義していますが、一からSLOを定義するのはとても難しいです。 幸いなことにGoogle社からSLOの説明や定義方法などSREに関する素晴らしい記事がたくさん共有されており、SL
Enabling SRE チームの oracle です。 チーム内で SLO の推進を担当しております。 freee での SLO の実践についてご紹介させて頂きます。 改めてSREとは 皆さんご存知のように SRE とは Google 社が実践してきたシステム運用のノウハウを書籍化したことで一般的に知られるようになった言葉です。 日本語版の書籍が発売されてからもう5年経ちました。 Google が提唱しているアプローチを皆さんは実践できていますでしょうか。 freee では SRE チームの前身はインフラという部署でした。 同じように部署を新設ではなくて名前を変更した企業も多いのではないでしょうか。 チームの名称は何であれ問題はありません。重要なのは SRE を実践しているのか、していないかです。freee は SRE を実践できていたかというとそうではありませんでした。 信頼性とは S
ゼロベースでSLOの存在意義はなにか？適切なSLIはどうやって決めるのか？を考察・調査し、まずはプラットフォームの一部のチームでSLOを策定しました。それまでの苦労を含めてSLOがなぜ必要か、またSLIをどのように決めたのか等お話します。 Cloud Operator Days Tokyo 2023で使用したスライドです。
みんなでつくる Production Readiness - スタディサプリ Product Team Blog
こんにちは。SRE の @chaspy です。 以前、Production Readiness Checklist に関する記事を書きました。 quipper.hatenablog.com Production Readiness Checklist の運用開始から1年ほどの月日が経ち、27ものサービスが無事 Production へ出ていきました。 サービスを安心して Production へリリースするために役立っている Production Readiness Checklist ですが、Product Team がこの Check List を進める上でいくつか課題がありました。 本記事では、Production Readiness Checklist 運用開始後に、どのような改善が行われてきたのか、その内容と方法を説明します。また、1年以上の運用を通して、Production R
CloudNative Days Spring 2021 ONLINE でお話したときの資料です https://event.cloudnativedays.jp/cndo2021/talks/201
この記事は、Merpay Advent Calendar 2021の16日目の記事です。 こんにちは、メルペイSREチームのfoostanです。普段はキーボードのことばかり話していますが、本業ではSREチームの一員としてソフトウェアエンジニアリングをしたりEM(Engineering Manager)をしています。 SREチームの重要な役割の一つはサービスの信頼性を高め、当たり前のようにメルペイを使えるようにすることです。信頼性を高めるためにはサービスが止まらないようなシステム構成にすることが重要ですが、サービスが異常な状態になったとき、関係者に状況を知らせるためのアラートを適切に上げることも重要です。そこで本記事ではお客さま影響に基づく実践的なアラート方法についてご紹介します。 適切なアラートとはなにか まずはどのようにアラートを上げるのが適切か考えてみます。アラートを上げる目的のひとつ
■イベント 【ユーザベース × Sansan】組織全体で向き合うSaaSプロダクトの信頼性向上への取り組み - UB Tech Vol.13 https://uzabase-tech.connpass.com/event/300220/ ■登壇概要 タイトル：⾃律的な開発チームを⽀えるためのSLO運⽤ 登壇者：技術本部 Bill One Engineering Unit 上司 陽平 ■Bill One エンジニア 採用情報 https://media.sansan-engineering.com/billone-engineer
こんにちは、WEAR部バックエンドブロックの小山とSREブロックの繁谷です。 WEARでは日々システムの信頼性を向上させるため改善に取り組んでいます。今回はその中でもSLOに基づいた改善について紹介いたします。 WEARリプレイスの歩み WEARでは2019年から本格的にリプレイスを開始しましたが、当初は専属のSREはおらずインフラ構築など緊急度の高いものをバックエンドのエンジニアや、プロダクト横断のSREが担っていました。 WEARのSREとして活動に割ける時間も短かったためSLI(Service Level Indicator)1やSLO(Service Level Objective)2の指標もありませんでした。WEARにおけるリプレイスの変遷についてはこちらのスライドに詳しく載せられているため、ご興味のある方は是非ご覧ください。 WEARの組織における課題 WEARでは2021年4
The Art of SLOsは、GoogleのCustomer Reliability Engineeringチームによって開発されたワークショップです。このワークショップの目的は、Googleがサービスの信頼性を計測する方法 サービスレベル指標(SLI) とサービスレベル目標 (SLO)を参加者に紹介し、実際にこれらの計測方法を作成することを体験してもらうことです。これらは重要で土台となる概念です。サービスの信頼性を客観的に測定する方法があれば、サービスの信頼性について有意義な会話をすることがはるかに簡単になります。 ワークショップの理論編では、開発チームと運用チームの間でしばしば生じる組織的な緊張を、サービスの望ましい信頼性を表す目標値を設定することで解決する方法を学びます。また、SLOとエラーバジェットを使って、データ駆動で、客観的、かつユーザー重視の方法でサービスの信頼性を測定・
HRMOSでは顧客満足を最優先し、価値あるソフトウェアを早く継続的に提供するため、スクラムに加え、Site Reliability Engineeringをプロダクト開発に適用し、SLI/SLOを定め、運用しています。また、エラーバジェット枯渇時にどのように行動するのか、その運用ルールも定めています。 私たちと同じようにエラーバジェットを運用する組織において、枯渇後のアクションとしてリリース凍結1を視野に入れようとする場合、プロダクトや関係者に与える影響は大きいため、そのルールの策定や調整に頭を悩ますケースも多いのではないでしょうか。 HRMOSの中でも特に歴史の長いプロダクトであるHRMOS採用では、SREチーム内や関係者との間で議論を重ねてルールを見直してきたため、これからエラーバジェットの運用を開始しようとしている方々の参考になればと思い、現在どういった点を考慮して運用しているかを紹
これからはじめる 実践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
はじめに こんにちは、計測プラットフォーム開発本部SREブロックの近藤です。普段はZOZOMATやZOZOGLASS、ZOZOFITなどの計測技術に関わるプロダクトの開発、運用に携わっています。計測プラットフォーム開発本部では、以前プロダクト単位でSLO(Service Level Objective)1を定めましたが、うまく活用できず、再度SLOについて運用方法を考え直すことになりました。本記事では、SLOの再導入から運用に向かう中で見つかった課題と、課題に対する対応策についてご紹介します。 目次 はじめに 目次 背景 要因分析 Problem Try Action Actionの実行 SLO設定時の段階分け 例：ZOZOMATの段階分け 課題の洗い出し 例：SLOがない事による課題（SRE視点） 目的の明確化 信頼性とはそもそも何か 一般的な信頼性 計測プロダクト UJの整理 SLOの
カヤックSREの池田です。今回は、カヤックのプロダクトの一つ『Tonamel』で導入したエラーバジェット算出ツール shimesabaの話をします。 shimesabaとは？ github.com shimesabaは監視サービスであるMackerelを用いて、エラーバジェットを計算しサービスメトリックとして投稿することでSLI/SLOの運用を助けるツールです。 このツールを用いることで、以下のようなグラフが得られます。 この図の上部は、エラーバジェットの使用率=信頼性の損失率の推移を表すグラフになっています。 この図の下部は、エラーバジェットをいつ？どのくらい？損失したのかを表すグラフになっています。 一言で、エラーバジェットと言ってもいくつかの計算方法が存在します。 今のところshimesabaでは、Rolling windowのコンプライアンス期間で、Windows-based SL
この記事では、Mackerelを使ったSLI/SLOによるサービス運用を紹介します。 SLI/SLOとは何か SLIの実装 SLOの設定 エラーバジェットとは さらに詳しく知るには MackerelでのSLI/SLO運用 SLI/SLOを策定する 可用性の計測 レイテンシの計測 ダッシュボードで定期的に状況を確認する 式による監視でモニタリングする SLI/SLOを運用と開発に活用するためには まとめ SLI/SLOとは何か SLI(Service Level Indicator)とはユーザーに提供したいサービスのレベル(水準)を計測する指標であり、SLO(Service Level Objective)とはSLIの目標値です。 サービスレベルを適切に定め、その指標(SLI)を実装・計測し、設定した目標値(SLO)を満たしているかどうかを定期的に確認することで、サービスレベルを適切に改善す
はじめまして、株式会社Luup SREチームに所属しています、ぐりもお（@gr1m0h）です。 Nobl9社が主催する SLOconf というSLO（サービスレベル目標）にフォーカスしたカンファレンスのローカルなコミュニティーイベント、SLOconf Tokyo 2023 に登壇しました。このイベントは、Googleの渋谷オフィスで 5/16 に開催されました。 発表資料は以下になります。 はじめてのオフライン登壇でした。これについては個人のブログに記載しています。 この記事は登壇内容についての詳細になります。 資料を読めば良いというのはあるのですが、口頭で話した部分は資料から読み取れないのでこのブログで補足していきます。 はじめに はじめに、何故このテーマで話すに至ったのか簡単に書いてみます。主題ではないのでこの項は読み飛ばしていただいても構いません。 現在LuupのSREチームではSL
開発者でも取り組める！発展期のサービスこそ、SLOやDatadogダッシュボードで状態を可視化してメンバーに安心を届けよう - Money Forward Developers Blog
こんにちは。 2021年10月からマネーフォワード クラウド勤怠の開発チームでSREとして働いています、VTRyo です。 入社2週間経過ブログを書いて以来の登場です。 https://moneyforward.com/engineers_blog/2021/10/28/mf-on-boarding/ 現在の僕は、チーム一人目のSREとして活動しています。せっかくなので、SRE立ち上げ記を綴っていきます。 第1話は 「サービスの状態を可視化して、まずはチームメンバーに安心を与えていこうな」 という話をします。 話さないこと SREそのものについて 具体的な作業ログ 経緯 10月某日。入社オリエンや開発オリエンが終わって徐々にSRE活動を始めることになりました。 必要なチャンネルに一通り招待され、どんなやり取りが発生するかを把握していきます。 そこで、真っ先に気になったのはモニタリングに関す
GitHub - OpenSLO/OpenSLO: Open specification for defining and expressing service level objectives (SLO)
The intent of this document is to outline the OpenSLO specification. The goal of this project is to provide an open specification for defining SLOs to enable a common, vendor–agnostic approach to tracking and interfacing with SLOs. Platform-specific implementation details are purposefully excluded from the scope of this specification. OpenSLO is an open specification i.e., it is a specification cr
個人的には、この考え方はとても興味深いものです。 SLO は 100% に近いほど良いもので、「目指せ 100% !!」 と考えがちですが、そうではなく障害などによる未達部分を除いた時間を余力・機会とし、本番環境でのリリース作業や改善を施すことが出来る数値的な目安とすることは、関係者間（開発者・運用者・ビジネスサイド）での合意形成をスムーズにさせてくれるはずです。 やってみる Web サービスからの レスポンスタイムを SLI とし、平均 5ms が 1ヶ月で 99.5% 満たすことを SLO とします。 Datadog Synthetics 作成 Synthetics API Test を利用して対象となる Web サービスを外形監視します。(手順は割愛します) Datadog Monitor 作成 SLO を利用するには、Monitor の作成が必要となります。 Monitors >
OpenSLO
What is OpenSLO?OpenSLO is a service level objective (SLO) language that declaratively defines reliability and performance targets using a simple YAML specification. It is released under Apache 2.0 and we welcome contributions from the reliability engineering ecosystem. SLOs are reliability targets for services that allow organizations to make better decisions in how to create, operate, and run cl
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SRE Classroom: The Art of SLOs - Google
いかに運用作業に手を抜くかという話 - pospomeのプログラミング日記
PairsにおけるSLI/SLO再定義
モダンなシステムにSLI/SLOを設定するときのベストプラクティス
クリティカルユーザージャーニーを利用した SLI/SLO の改善 / #mackerelio
たった2ヶ月半でSLOを導入して事業判断に影響を与えた話 - Adwaysエンジニアブログ
OpenSLOについて | フューチャー技術ブログ
サービスと組織の拡大を支えるEmbedded SREs
LAPRASにおけるSLO運用状況 | LAPRAS株式会社
Maintain SLO 〜俺たちのSLOはこれからだ!〜
freee での SLO の実践について - freee Developers Hub
DMMプラットフォームに ゼロベースでSLO導入している取り組み 適切なSLI模索の軌跡
SLO策定とアラート設定までの長い道のり
お客さま影響に基づく実践的なアラート方法 | メルカリエンジニアリング
⾃律的な開発チームを⽀えるためのSLO運⽤
WEARにおけるSLOを用いた信頼性改善の取り組み - ZOZO TECH BLOG
SRE Classroom: The Art of SLOs - Google
円滑なエラーバジェット運用に向けた取り組み
ZOZOMAT/ZOZOGLASSにおけるSLOの立て直しについて - ZOZO TECH BLOG
SLOの運用のために OSS shimesabaの導入 - KAYAC engineers' blog
Mackerelを使ったSLI/SLOによるサービス運用の紹介 - Mackerel お知らせ #mackerelio
「LuupにおけるSLOの物語」という題でSLOconf Tokyo 2023に登壇しました
Datadog を利用して SLO を管理しよう！ #datadog | DevelopersIO
shonenjumpplus.com
2ch-ero-report.blog.jp
note.com/ttttttttttt
news.yahoo.co.jp
www.newsweekjapan.jp
approach.yahoo.co.jp