WEARにおけるSLOを用いた信頼性改善の取り組み - ZOZO TECH BLOG
こんにちは、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
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
Slab キャッシュの使用量が増加した原因を SystemTap で調査した [DeNA インフラ SRE] | BLOG - DeNA Engineering
2022.07.28 技術記事 Slab キャッシュの使用量が増加した原因を SystemTap で調査した [DeNA インフラ SRE] by Hidetaka Masuda #infrastructure #sre #troubleshooting #stateless-server #iaas #game-infrastructure #infra-quality IT 基盤部の増田です。新卒2年目で業務では主にモバゲーや社内向け SaaS のインフラ運用を行っています。 本記事ではサーバーのメモリ使用量増加の原因を SystemTap で調査したときの話を紹介します。 この記事を通して、手掛かりを元に少しずつ核心に近づいていく、謎解きゲームのような楽しさを感じていただければと思います。 問題発生 調査を開始したきっかけは、サーバーのメモリ使用量増加のアラートが頻繁に鳴るようになっ
![Slab キャッシュの使用量が増加した原因を SystemTap で調査した [DeNA インフラ SRE] | BLOG - DeNA Engineering](https://cdn-ak-scissors.b.st-hatena.com/image/square/c899e14d0d2479abd7a044d3c20a16eff024add6/height=288;version=1;width=512/https%3A%2F%2Fengineering.dena.com%2Fblog%2F2022%2F07%2Finvestigation-of-increased-memory-usage%2Fcover.png)
SRE Classroom: The Art of SLOs - Google
The Art of SLOsは、GoogleのCustomer Reliability Engineeringチームによって開発されたワークショップです。このワークショップの目的は、Googleがサービスの信頼性を計測する方法 サービスレベル指標(SLI) とサービスレベル目標 (SLO)を参加者に紹介し、実際にこれらの計測方法を作成することを体験してもらうことです。これらは重要で土台となる概念です。サービスの信頼性を客観的に測定する方法があれば、サービスの信頼性について有意義な会話をすることがはるかに簡単になります。 ワークショップの理論編では、開発チームと運用チームの間でしばしば生じる組織的な緊張を、サービスの望ましい信頼性を表す目標値を設定することで解決する方法を学びます。また、SLOとエラーバジェットを使って、データ駆動で、客観的、かつユーザー重視の方法でサービスの信頼性を測定・
SREは運用チームだけの問題？ 開発者のメリットをGoogle×スリーシェイクがプラクティスとともに解説！
もともとSREはGoogleがサイトの信頼性を高めるために、新しい部署を作り、ゼロから作りあげたものだ。今回はGoogleでオブザーバビリティ領域を担当する山口能迪氏とともに、SREの歴史や原則を確認し、アプリケーション開発者にも恩恵がある部分について語り合ってもらった。 株式会社スリーシェイク Sreake事業部 部長 手塚卓也氏 信頼性向上のためにGoogleが作りあげたSRE、その現在地とは ――まずはこれまでのご経歴や現在の役割について簡単にお聞かせください。 手塚：2016年にインフラ系ベンチャー企業に就職しインフラエンジニアとしてキャリアをスタート、スリーシェイクには2018年に入社し顧客企業へのSRE立ち上げ支援などを行ってきました。現在はSRE総合支援やセキュリティサービスを展開しているSreake事業部の部長としてチーム全体を見ています。 山口：前職は外資系パッケージベン
SLOの運用のために OSS shimesabaの導入 - KAYAC engineers' blog
カヤックSREの池田です。今回は、カヤックのプロダクトの一つ『Tonamel』で導入したエラーバジェット算出ツール shimesabaの話をします。 shimesabaとは？ github.com shimesabaは監視サービスであるMackerelを用いて、エラーバジェットを計算しサービスメトリックとして投稿することでSLI/SLOの運用を助けるツールです。 このツールを用いることで、以下のようなグラフが得られます。 この図の上部は、エラーバジェットの使用率=信頼性の損失率の推移を表すグラフになっています。 この図の下部は、エラーバジェットをいつ？どのくらい？損失したのかを表すグラフになっています。 一言で、エラーバジェットと言ってもいくつかの計算方法が存在します。 今のところshimesabaでは、Rolling windowのコンプライアンス期間で、Windows-based SL
SRE に成る君に最低限の開発力を身に着けてほしい - じゃあ、おうちで学べる
はじめに まず、はじめに皆さんへ言っておきたいことがあります。 このドキュメントの目的は皆さんをやる気にさせて一心不乱にコードを書きまくって新機能追加や改善をしてソフトウェアを開発していってほしいというわけではないということです。 もちろん、そうなってくれれば嬉しいですが気合が入ったからプログラムを急に書けるようになるわけではないのでそのような目的は一切ありません。また、この文章にはインフラエンジニアがコードを読み書きできなくて良いという意図はなくポジショニングトーク的にSREという単語を利用しておりますので何も言わないでください。 SREはそもそも、コードを書かなくてもよいエンジニアではない SREとは、ITサービスの信頼性を高めるために、ITエンジニア（開発者）が信頼性向上のために行う設計やアプローチ、またはこれらを行うチームや役割を指します。 Google では、SREチームの50～
AWSコスト倍になっちゃった！〜削減への道のり〜 - freee Developers Hub
こんにちは、DevBrandingのellyです。5月20日に配信した「AWSコスト倍になっちゃった！〜削減への道のり〜」の様子をご紹介します。 今回はITストラテジーチームとSREチームから2人のゲストを招いて、freeeで実際に起きたAWSコスト増加の事例をもとに、気がつけば増えるインフラ費用の無駄をどのように見つけ、コスト削減していったのか、実話のストーリーを話してもらいました。 登壇者集合写真 miry:写真左上。2015年入社。ITストラテジー。全社のITツールのコスト管理やIT戦略の策定を担当。 nakagawa:写真右上。2020年5月入社。SREチームエンジニア。基盤の更改やクラスタ管理効率化を担当。 のぶじゃす (@noblejasper): 写真右下。ラジオパーソナリティ、2017年に中途入社。mixi、ソーシャルゲーム企業でソフトウェアエンジニアを経験し freee
SRE NEXT2022で組織の成長痛と向き合う話をしてきました + 補足 - STORES Product Blog
はじめに プロダクト基盤本部 SREの藤原です。 heyにおけるSREの大切さ~マルチプロダクト運用の「楽しさ」と「難しさ」および今後の展望~と題してSRE NEXT 2022に登壇しました。 www.youtube.com 本エントリはその報告と補足説明です。 セッションでは、SREとは何かというところから始まり、heyにおけるSREの楽しさについて述べました。次に成長し続けるプロダクトと組織において、直面するであろう困難について解説しました。最後に困難の部分に向き合うにあたって、どのような活動や取組を進めていきたいかを述べました。 本エントリでは、セッションのスライドと内容を一部振り返りつつ、補足として取り組みの副作用と向き合い方(案)を述べています。 SREってなに？ まず、SREではなくプロダクト開発組織の目的を考えてみましょう。プロダクト開発組織は、顧客に対してあたらしい価値、よ
SRE NEXTで「AIOps研究録」講演を終えて - ゆううきブログ
5月14-15日に開催されたSREの国内カンファレンス SRE NEXT 2022 ONLINEにて、「AIOps研究録―SREのためのシステム障害の自動原因診断」と題して、ITシステムに障害が発生した際に、機械学習・統計解析の手法を用いて、障害の原因を自動で診断するための研究について講演しました。 講演に用いたスライド資料を以下に公開しています。 当日に配信された講演動画は、Youtubeに公開されています。 なお、この記事では、AIOpsという用語を、機械学習や統計解析をはじめとするAI（人工知能）と呼ばれる技術を用いて、ITオペレーターのオペレーション作業を自動化あるいは支援する技術の総称として使っています。 なぜAIOpsに着目したのか 自分が、統計や機械学習をはじめとするAIと呼ばれる技術をSRE分野に適用することを漠然と考えはじめたのは、2017年ごろでした。当時、今後のSRE
SRE NEXT 2022で「プロダクション環境の信頼性を損ねず観測する技術」というお話をしました - ださろぐ@はてな
登壇＆参加エントリです。 ややエモよりになる予定。 当日の体験については他の登壇者の皆様とも少しお話したんですが、完全に馬場さんのエントリに書かれている点と同じ感想であり（事前収録は当日落ち着けてよい、参加者としてのZoom Event体験はかなり良かった、ブースの仕様はやや残念ではあったが個人的にはそれでも楽しめた）、まあ同じことを書いてもということで発表まわりや個別の参加体験の方を書いていきます。 登壇について プロダクション環境の信頼性を損ねず観測する技術というタイトルで登壇させて頂きました。 6/9時点でまだスライドのみですが、ぼちぼちアーカイブの方も上がってくるかなと思います。 www.youtube.com 前回2020の登壇から2年、SRE NEXTが開催されたら何はともあれproposalは出したいと考えていたので募集の段階でネタを考えました。 ネタは2本考え、1つは長期運
kubernetesをキャッチアップし、知識を蓄積していく | はてなで働く masayosu にアンケート [#20] - Hatena Developer Blog
はてなで働くエンジニアにアンケートシリーズ第20回は、サービスプラットフォームチームのSRE、id:masayosuに話を聞きました。 社内に「まさよし」が複数いて紛らわしい SREメンバーでEKSとGKEの2つをキャッチアップ 自分の中にkubernetesの知識が蓄積されていった ここまでオープンな会社はこれまで経験したことがなかった 社内に「まさよし」が複数いて紛らわしい ── Q1. はてなidとその由来を教えてください TwitterのIDが@masayosuなので、はてなidもTwitterと同じ文字列を利用しています。由来は本名が「まさよし」なので。 はてな社内には「まさよし」という名前やはてなidを持つ人が3〜4人くらい存在しているので、紛らわしい状態になっています。 ── Q2. いつどんなきっかけで入社しましたか？ 2020年7月に、id:hayajo_77さんの紹介で
![kubernetesをキャッチアップし、知識を蓄積していく | はてなで働く masayosu にアンケート [#20] - Hatena Developer Blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/aebd9f036ff4f257bad5c8f9e02c8a062e54d129/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fh%2Fhatenatech%2F20220608%2F20220608112301.jpg)
OpenSLOについて | フューチャー技術ブログ
はじめにはじめまして、原木と申します。 皆さまはSRE NEXTをご覧になりましたでしょうか？ SRE NEXTは 先日実施された『信頼性に関するプラクティスに深い関心を持つエンジニアのためのカンファレンス』です。国内外のエンジニアが日々SRE(サイト信頼性エンジニアリング/Site Reliability Engineering)の実践手法を共有することで、Webサービスが今後運用、成長していくための次世代の信頼性を担おうとしています。 もしもWebサービスの運用を安定的に行う手法やそのためのチームビルディングに興味がある場合、SRE NEXTの動画セッションやスライドが公開されると思うのでご覧ください1。 さて本ブログではそんなSREとも関係の深い、OpenSLOに関して取り上げたいと思います。 OpenSLOとは最近、SLOモニタリングという言葉が注目を集めつつあります。例えば、Go
Poolにおける足を止めないシステム基盤構築
バッチ resource "aws_sfn_state_machine" "xxx" { name = "xxx" role_arn = aws_iam_role.state_machine.arn definition = jsonencode({ StartAt = "Run ECS Task", States = { "Run ECS Task" = { Type = "Task" Resource = "arn:aws:states:::ecs:runTask.sync" Parameters = { LaunchType = "FARGATE" EnableExecuteCommand = true NetworkConfiguration = { ... } Cluster = ... TaskDefinition = ... Overrides = { ContainerOv
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SREとしての「コスト最適化」
長年運用されてきたモノリシックアプリケーションをコンテナ化しようとするとどんな問題に遭遇するか？ / SRE NEXT 2022
1年間のポストモーテム運用とそこから生まれたツール sre-advisor / SRE NEXT 2022
成長を続ける組織でのSRE戦略：プレモーテムによる信頼性の認識共有 SRE Next 2022
プロダクション環境の信頼性を損ねず観測する技術
AIOps研究録―SREのための
システム障害の自動原因診断 / SRE NEXT 2022
