2024年8月3,4日に開催された SRE NEXT 2024 での発表資料です。 「徹底的な自動化とトイルの撲滅で実現する効率的なSREの実践例」 https://sre-next.dev/2024/schedule/#sp007 本発表では、数十のウェブサイトを限られた人数で構築・運用するため…
2024年8月3,4日に開催された SRE NEXT 2024 での発表資料です。 「徹底的な自動化とトイルの撲滅で実現する効率的なSREの実践例」 https://sre-next.dev/2024/schedule/#sp007 本発表では、数十のウェブサイトを限られた人数で構築・運用するため…
信頼性の追求というのは、決して完璧を求めることではありません。完璧な可用性を追求するのではなく、ユーザーの満足と、限りあるリソースのバランスを取ることこそが重要です。このバランスを取るための一つのツールが、SLO（Service Level Objectives）です。 はじめに 「Implementing Service Level Objectives」は、現代のソフトウェアサービス管理において不可欠な概念の一つであるSLO（Service Level Objectives）の実装と運用に関する包括的なガイドブックです。本書は、SLOの基本概念から実践的な導入方法、組織文化への浸透まで、幅広いトピックをカバーしています。このSRE本がすごい！2024年版でも紹介しているようにSREやインフラエンジニアの方が必読の一冊だと思います。 Implementing Service Level
はじめに まず、はじめに皆さんへ言っておきたいことがあります。 このドキュメントの目的は皆さんをやる気にさせて一心不乱にコードを書きまくって新機能追加や改善をしてソフトウェアを開発していってほしいというわけではないということです。 もちろん、そうなってくれれば嬉しいですが気合が入ったからプログラムを急に書けるようになるわけではないのでそのような目的は一切ありません。また、この文章にはインフラエンジニアがコードを読み書きできなくて良いという意図はなくポジショニングトーク的にSREという単語を利用しておりますので何も言わないでください。 SREはそもそも、コードを書かなくてもよいエンジニアではない SREとは、ITサービスの信頼性を高めるために、ITエンジニア（開発者）が信頼性向上のために行う設計やアプローチ、またはこれらを行うチームや役割を指します。 Google では、SREチームの50～
5月14-15日に開催されたSREの国内カンファレンス SRE NEXT 2022 ONLINEにて、「AIOps研究録―SREのためのシステム障害の自動原因診断」と題して、ITシステムに障害が発生した際に、機械学習・統計解析の手法を用いて、障害の原因を自動で診断するための研究について講演しました。 講演に用いたスライド資料を以下に公開しています。 当日に配信された講演動画は、Youtubeに公開されています。 なお、この記事では、AIOpsという用語を、機械学習や統計解析をはじめとするAI（人工知能）と呼ばれる技術を用いて、ITオペレーターのオペレーション作業を自動化あるいは支援する技術の総称として使っています。 なぜAIOpsに着目したのか 自分が、統計や機械学習をはじめとするAIと呼ばれる技術をSRE分野に適用することを漠然と考えはじめたのは、2017年ごろでした。当時、今後のSRE
登壇＆参加エントリです。 ややエモよりになる予定。 当日の体験については他の登壇者の皆様とも少しお話したんですが、完全に馬場さんのエントリに書かれている点と同じ感想であり（事前収録は当日落ち着けてよい、参加者としてのZoom Event体験はかなり良かった、ブースの仕様はやや残念ではあったが個人的にはそれでも楽しめた）、まあ同じことを書いてもということで発表まわりや個別の参加体験の方を書いていきます。 登壇について プロダクション環境の信頼性を損ねず観測する技術というタイトルで登壇させて頂きました。 6/9時点でまだスライドのみですが、ぼちぼちアーカイブの方も上がってくるかなと思います。 www.youtube.com 前回2020の登壇から2年、SRE NEXTが開催されたら何はともあれproposalは出したいと考えていたので募集の段階でネタを考えました。 ネタは2本考え、1つは長期運
今回の記事では、SREとは何なのかについて根本から考えながら活動してきた、グロービス SREチームの探求と実践について紹介します。 はじめにグロービス・デジタル・プラットフォーム SREチームでチームリーダーを務めている沼田（@chroju）です。 突然ですがSREとはどう定義されるでしょうか。この問い、存外に難しいのではないかと感じています。インフラエンジニアは「インフラ領域を担当しているから」そう呼ばれますが、ではSREは「サイト信頼性を担当しているから」そう呼ばれるのでしょうか。サイト信頼性を担当する、とは、具体的にはどういうことなのでしょうか。 SREチームの業務内容や責任領域は広範囲に渡り、おそらく会社によって様々な形を取っているのではないかと思います。2021年9月に日本語版が発売された『SREの探求』は、まさにそういった様々なSREの実践をまとめた書籍であり、冒頭の「はじめに
美容クリニックは新規体制用の少人数体制で開発を行っており、その内の約 7 割がアプリ開発をしているエンジニアとなっています。 一方で、SRE は全体の約 1 割の人数しかいないという状況にあります。 この SRE の人数が少ないかどうかは扱っているシステムの規模や課題によって評価が変わるかと思いますが、美容クリニックが現在抱えている課題の量に対しては少ない人数だと感じています。 では、このように限られた人数の中でどのようにして SRE 活動を行ってきたのかを紹介していきます。 SRE チームの組閣 美容クリニックのリリース以前から SRE チームは存在していたのですが、リリース前後でその責務は変わってきます。 例えばリリース前はインフラの初期構築がメインの責務となってきますが、リリース後（エンハンス開発）にはインフラの保守運用がメインの責務となります。 さらに、メンバーの変動などにより当初
SREの@deeeetです。 新しい機能を素早くリリースしフィードバックを得てすぐにPivotの決定を行う、もしくはリスクを抑え小さな改善を継続的に行うContinuous Deliveryはソフトウェア開発において非常に重要です。 メルカリではこのContinuous DeliveryのためのPlatformにSpinnakerを採用し始めました。現在は主にkubernetes（k8s）へのコンテナアプリケーションのDeployに利用しており、既にいくつかの本番アプリケーションがSpinnakerによりDeployされています。 本記事ではなぜSpinnakerを採用したか、Spinnakerとは何か、実際にメルカリでどのようにSpinnakerを使っているか、について簡単な紹介をします。 kubernetes上でのDeploy問題 k8sへのコンテナイメージのDeployは非常に簡単で
前回の『CRE が現場で学んだこと』シリーズでは、システムの可用性を担保するにあたってターゲットとする正確な数値をいかにして割り出すか、ということについてお話ししました。このターゲットをシステムのサービス レベル目標（SLO）と呼びます。 今後、システムが十分な信頼性を保って稼働しているか、またシステムにどんな設計やアーキテクチャの変更が必要かについて議論する際は、システムが継続的に SLO を満たしているという枠の中で語る必要があります。 SLO の適合性は直接測定することが可能です。システムにおいて精査が成功した頻度で計るのです。これをサービス レベル指標（SLI）といいます。システムが過去 1 週間 SLO を満たしつつ稼働していたかどうかを評価する場合に、SLI からサービスの可用率を把握するのです。定められた SLO を下回っているとなれば問題があるということですから、他の場所に
By: Heather Adkins, Betsy Beyer, Paul Blankinship, Ana Oprea, Piotr Lewandowski, Adam Stubblefield Can a system be considered truly reliable if it isn't fundamentally secure? Or can it be considered secure if it's unreliable? Security is crucial to the design and operation of scalable systems in production, as it plays an important part in product quality, performance, and availability. In this bo
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The Murphy-Beyer Effect
