AIOps研究録―SREのためのシステム障害の自動原因診断
5/14 12:30 - 13:15 How We Foster "Reliability" in DiversitySRE において「信頼性」は最も重要な指標とされています。しかし、一言で「信頼性」といっても、会社の戦略やサービス、文化によって、計測方法や目指す値、その達成方法にいたる全てが同じになることはないでしょう。さらに、一度定義した信頼性が適切であり続けることはなく、会社や組織のフェーズによって、その時々で柔軟に変化していく必要がありそうです。 このように、サービスを取り巻く環境の変化に応じて適切な信頼性を定義し、またその信頼性を「育てて」いく方法として、サービスや組織の戦略と SRE チーム の方向性を揃えたり、SRE チームの垣根を超えて組織全体に SRE の文化を根付かせるための取り組みなどを紹介しながら、多様性とともに SRE がどのように歩んでいくかについてお話します。
日経SREの取り組み2021年版 — HACK The Nikkei
この記事はNikkei Advent Calendar 2021の23日目の記事です。 はじめに SREチームの杉本です。昨年のアドベントカレンダーでは 日経におけるSREとその取り組み というエントリでSREの取り組みについてご紹介しました。 その後も取り組みについて試行錯誤を繰り返し、ようやく日経のSREはこんな風にやっています、という形ができてきました。 本エントリではアップデートとして2021年のSREの取り組みを振り返りつつ、今後の取り組みについてもご紹介できればと思います。 SREチームのプロジェクトに対するエンゲージメント SREチームのプロジェクトへのエンゲージメント手法は色々ありますが、弊社では日経電子版だけでなく、認証基盤、課金基盤、法人向けサービスなど、数え切れないほど多くのプロジェクトが開発・運用されています。一般的には、各サービスにバンドルされているSREチーム、
請求管理ロボSREチームの方針とここ1年ほどの活動について - ROBOT PAYMENT TECH-BLOG
こんにちは、SREの @trunkatree です。 今日は請求管理ロボSREチームのここ1年ほどの活動についてご紹介したいと思います。 本ブログを通してSREチームがどんなことを目指して、どんなことを考えて、どんなことに取り組んでいるのかが伝わればいいなと思っています。 請求管理ロボシステムではちょうど1年ほど前に"開発チームで開発運用するモデル"へ移行していく方針を決め、SREチームはそれを念頭に置いて活動を続けています。 まずはそれに至った経緯からお話したいと思います。 "開発チームが開発運用するモデル"へ移行することになった経緯 "開発チームが開発運用するモデル"へ移行するにあたり考えたこと "開発チームが開発運用するモデル"へ移行するにあたりやっていくこと 2021年度やったこと Terraformのバージョンアップ、インフラリソースのTerraform化、TerraformのC
Indeed でSREとして働くとは - Indeed エンジニアリング・ブログ
写真：Kevin Ku （Unsplashから転載） Indeed には、毎月3,000万件以上の新着求人が追加され、毎月2.5億人以上もの求職者が応募先の採用企業とつながっています。ユーザーがいつでも利用でき、すばやく拡張性がある Indeed のサービスは、どのように実現されているのでしょうか。その裏には、Site Reliability Engineering（SRE）チームの絶え間ない努力があります。 SREとは？ SREを一言でいうと「企業のコアインフラストラクチャーチームが効果的に運用されるよう支援するチーム」です。2003年、Googleが信頼性の問題に対応するために立ち上げた小規模なプロダクションエンジニアリングチームに端を発するSREは、もともとは、呼び出し対応やモニタリング、パイプラインのリリースなど運用に関する業務が主な職務でした。このチームが、企業全体のインフラを改
アジャイル的ドキュメンテーションのこころ - KAYAC engineers' blog
SREチームの橋本です。 アジャイル開発（ウォーターフォールとの対比の意味で）では「ドキュメントを書かない」、とまで言う人はなかなかいないと思いますが、「コードを読めばOK」といった声は実際の開発者からも聞こえることがあります。 ただ現場でドキュメントにより労力が削減できる場面は間違いなく存在し、またそのときには、軽いメモ程度のドキュメントでも間違いなく役に立つものではないでしょうか。 ややメンタル寄りの内容にはなりますが、ここではそうした観点からドキュメンテーションの「ミニマムスタート」を提案したいと思います。 何のためのドキュメント？ 要件定義書、基本設計書、詳細設計書……こうした「ドキュメント」を基盤として開発を行うウォーターフォールモデルの開発と比べれば、アジャイルではドキュメントが必須でない、というのは確かにそうでしょう。 しかし何の役にも立たないのか？ と言えばそれは間違いなく
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
SRE とは| Red Hat
SRE (Site Reliability Engineering：サイト信頼性エンジニアリング) は、IT 運用におけるソフトウェア・エンジニアリング・アプローチです。SRE チームはソフトウェアツールを使用してシステムの管理、問題解決、および運用タスクの自動化を行います。 SRE は、運用チームが多くの場合手作業で行ってきたタスクを、ソフトウェアと自動化を活用するエンジニアと運用チームに担当させ、ソフトウェアと自動化によって問題を解決し、本番システムを管理します。 SRE は、スケーラブルで信頼性の高いソフトウェアシステムを構築する際に効果を発揮します。コードを使用して大規模システムの管理を支援するため、数千台や数万台に及ぶマシンを管理するシステム管理者により多くのスケーラビリティと持続性をもたらします。 サイト信頼性エンジニアリングのコンセプトは Google エンジニアリングチーム
「コード書きました、あとはよろしく」では優れたソフトウェアは生まれない コンテナのスペシャリストが語る、運用性を損なう8つの実装例
今押さえておくべき知識をアップデートし、ノウハウを共有し、さらなるスキルアップを実現する場として開催されている、AWS で最も Developer に特化したカンファレンス「AWS Dev Day Online Japan」。ここでSr. Product Developer Advocate, Elastic Containersの原氏が登壇。続いて、運用性に優れたソフトウェアが重要な理由と、運用性を損なう8つの実装例について紹介します。前回はこちらから。 You build it, you run it 原トリ氏：（スライドの「You build it, you run it」を指して）この言葉、聞いたこと、見たことがある方がいるかもしれません。これは、2006年にACM（Association for Computing Machinery）という団体が、Amazon AWSのCTOで
SREを自社に導入するためのプラクティス
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます はじめに 前回の記事では、Site Reliability Engineering（SRE）がシステム運用にもたらす利益についてご紹介しました。結論としては、「システムの信頼性の担保」と「開発効率の向上」という対極にある2つの要素を成立させるというものでした。 第2回となる本記事では、企業ごとに組織の体制や文化が異なる中で、どのような目的・意図を持って進めていけば、この対極にある要素を両立させたSREの導入につなげられるかのプラクティスについてご紹介します。 SRE導入はある程度の時間を要する 前述の通りSREの目的は、「システムの信頼性の担保」と「開発効率の向上」という2つの要素を両立させることです。 アプローチ方法としては、ソフトウ
エウレカ SREチームの2021年までの取り組みとこれから | Eureka Engineer Telegraph
こんにちは、エウレカのSREチームでリーダーをしている山本（@marnie0301）です。今回は、エウレカのSREチームが今までどんなことをしてきたか、どんなチームなのかなどをご紹介できればと思っています。 はじめにまずはじめに、SREとはサイト・リライアビリティ・エンジニアリングの略称です。SREという言葉の起源は、2003年にGoogle社が発足したチームの取り組みを起点として以降、同社が継続して実践してきたプラクティスの集合とシステム管理・運用におけるアプローチ（役割）です。 SREという概念やプラクティスにおいてとても有名な書籍である「Site Reliability Engineering」には、SREの責務や概念について以下のように説明がなされています。 SREとはソフトウェアエンジニアに運用チームの設計を任せた時にできあがるもので、ソフトウェア開発エンジニアないし、ソフトウェ
開発チームとともに歩むSREチームが成し遂げたいこと | メルカリエンジニアリング
こんにちは、メルカリMicroservices SREチームでEngineering Managerをしている@m4buyaこと渋谷です。 メルカリでは、昨年6月にSREチームの一部をマイナーアップデートし、プロダクトチームに寄り添いSREとしての専門性を活かし信頼性に貢献していくMicroservices SREチームを発足しました。本記事では、そうするに至った背景、何を目指しているのか、これまでに出来たこととまだ出来ていないことを振り返り、今後の展望についてご紹介します。 背景 メルカリでは、2015年よりSREチームを立ち上げ、お客様が安心・安全にメルカリサービスを利用していただくためのシステムの信頼性の維持向上に取り組んできました。年々プロダクトとして成長を続け、トラフィックも増加する一方のメルカリサービスに求められるスケーラビリティ向上において、メルカリSREチームは大きな役割を
ログイン - ZDNET Japan
■ZDNET Japan Headlineの購読 ZDNET Japanの最新コンテンツをお届けします（平日毎日配信）。また、企業からのお役立ち情報も不定期でお届けしています。[サンプルはこちら] ■ホワイトペーパーライブラリーの利用 製品情報や技術紹介、導入事例など、企業のITご担当者が製品やサービスを購入する際の参考になる資料（PDFなど）をダウンロードしていただけます。 ■企業情報センターの利用 あなたが企業のマーケティング担当者なら、プレスリリース、イベント情報、会社情報、ホワイトペーパーなどを朝日インタラクティブが運営する各サイトに掲載することが出来ます。なおご利用にはCNET_IDのほか、企業ID登録する手続きが必要です。 ■イベントへの参加 朝日インタラクティブが主催および共催する、業界のキーマンが集うカンファレンスやセミナーにご参加いただけます。 ■キャンペーン、アンケート
The Many Shapes of Site Reliability Engineering
In my role as a Cloud and SRE Practice Lead at Slalom Build, I am fortunate to talk to a wide range of organizations, from smaller mid-market companies all the way to astoundingly large and complex enterprises, all from an equally wide range of industries. There is no doubt about it, Site Reliability Engineering (SRE) is the latest hot topic. These companies are looking to reduce the impact and ri
「ホットペッパービューティー」美容クリニックでのSRE活動
美容クリニックは新規体制用の少人数体制で開発を行っており、その内の約 7 割がアプリ開発をしているエンジニアとなっています。 一方で、SRE は全体の約 1 割の人数しかいないという状況にあります。 この SRE の人数が少ないかどうかは扱っているシステムの規模や課題によって評価が変わるかと思いますが、美容クリニックが現在抱えている課題の量に対しては少ない人数だと感じています。 では、このように限られた人数の中でどのようにして SRE 活動を行ってきたのかを紹介していきます。 SRE チームの組閣 美容クリニックのリリース以前から SRE チームは存在していたのですが、リリース前後でその責務は変わってきます。 例えばリリース前はインフラの初期構築がメインの責務となってきますが、リリース後（エンハンス開発）にはインフラの保守運用がメインの責務となります。 さらに、メンバーの変動などにより当初
[レポート] SRE の基本と組織への導入 〜サービスレベル目標やエラー予算などサービスの信頼性に対する考え方〜 #GoogleCloudDay | DevelopersIO
TL;DR Googleでは4分間システムを止めるとボーナスが貰える（語弊） 原則 「信頼性は最も重要な機能」「信頼性を決めるはユーザー」「99.999%はソフトウェアだけでも運用だけでも達成出来ない」 人間の脳はリスク分析を正しく行えない。ではどうするか？ class SRE implements DevOps {} 5/25〜27の日程で行われたオンラインイベント、Google Cloud Day: Digital '21。 3日目に公開されたセッション「SRE の基本と組織への導入」を拝聴しましたのでレポートします。 個人的にめちゃくちゃツボだったセッションでした！ 具体的なサービスレベル目標(SLO)の策定方法・エラー予算(エラーバジェット)の策定方法・考え方から、そもそもSREとは・信頼性とはといった概要論、組織への導入方法・文化論まで、「SRE」を中心に置いた事柄がほぼほぼ網羅
![[レポート] SRE の基本と組織への導入 〜サービスレベル目標やエラー予算などサービスの信頼性に対する考え方〜 #GoogleCloudDay | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/1ee78329be0c669f34331a26f9ed050862dbe0c7/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2021%2F05%2Fd3-infra-01_eyecatch.png)
SREを麻雀に例えたら(哭き派とメンチン派の争い) - エムスリーテックブログ
エムスリーエンジニアリンググループSREチームの山本です。 私はエムスリーに入社してまだ1年少しなのですが、前職でも似たような職務を担当していました。 その中で、実は「インフラのあり方」には二大潮流が存在し、その中で皆が苦しみもがいているのではないだろうか？と感じました。前職や現職で感じたアレコレをエッセーのように軽い読み物にしますので、SREブログリレー二日目のネタとして書かせてください なお、文字だけでは書きたいことが足りぬため、私が直々に画伯として挿絵も描いてしまいます。 ちなみに「麻雀に例えたら」と書きましたが、実は私は麻雀のルールをほとんどしりません。某有名麻雀劇画の作者はルールを知らないのに勢いで麻雀を描いたようですし、私もそれでいきたいと思います。 ロン！クラウド無双！！ 二種の潮流 哭きのSRE メンチン型SRE どちらが正しいのか？ SREとしての立場と技術選定 「シクヨ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サイト信頼性エンジニアリング (SRE) とは？ - ServiceNow
Google - Site Reliability Engineering
サービスレベル指標（SLI）を選択する | Cloud アーキテクチャ センター | Google Cloud
SRE への冒険の始まり : Google Mission Control にようこそ
