エンジニアのためのSRE論文への招待 - SRE NEXT 2023 - ゆううきブログ
この記事では、2023年9月29日に開催されたSRE NEXT 2023 IN TOKYOでの講演の概要に加えて、講演では触れられなかった部分の補足と、発表を終えての後記、最後にSRE NEXT全体の感想を書きました。 SRE NEXT 2020の基調講演に招いていただいたところから始まり、昨年のSRE NEXT 2022の公募セッションでも発表し、今回で3回目の発表になりました。今回の講演は、SRE NEXTの「NEXT」と価値観の一つである「Diversity」を踏まえて、自身のエンジニアと研究者の両方の経験を活かして、SREを深く実践する上で、技術論文を探して読むアプローチを提示するものです。昨今の国内のSREコミュニティでは組織的実践に主な関心が移っている状況と対比させて、コンピュータサイエンスに基づく技術的挑戦の可能性を示唆する意欲的な講演を目指したつもりです。 この講演での主要
道を照らす: プラットフォーム エンジニアリング、ゴールデンパス、セルフサービスのパワー | Google Cloud 公式ブログ
※この投稿は米国時間 2023 年 9 月 12 日に、Google Cloud blog に投稿されたものの抄訳です。 入社したばかりの Java デベロッパーが、簡単な Java サービスを作る仕事を割り当てられたとしましょう。DevOps モデルでは開発チームと運用チームが責任を共有するので、Java コードだけでなく、ビルド パイプラインやモニタリング計測のような運用コードの作成も求められるかもしれません。しかも、クラウド プラットフォームは以前の仕事で覚えたものとは異なります。 あっという間に YAML ファイルの山に溺れ、簡単な Java サービスの構築が難事業になってしまいました。決めなければならないことがたくさんあります。コードの構成はどうしよう？継続的デリバリーにはどのツールを使用したらいいのだろう？ DevOps モデルは開発者に耐えられないほどの学習の手間をもたらすこ
インフラエンジニアはSREではないし、SREとPlatform Engineeringも別物 - inductor's blog
インフラエンジニアの肩書きをSREに変えるタイプの組織変更は近いところから遠いところまでいろんなところで見かけてるんだけど、改めてそれって名前変えただけじゃないよね？って問いかけは個人が組織に、組織が個人にそれぞれ相互でした方がいいと思う。 インフラエンジニアって言葉もまあ定義が死ぬほど広くてどこからどこまで指すのってのは組織によって違うね大変だねって話ではあるんだけど、SRE(Site Reliability Engineering)やPE(Platform Engineering)はインフラと必ずしも対応関係にあるわけではないんだよな。 Platformってのは言ってしまえば会社のエンジニア組織の中で自分達に最適化された基盤を作る人たちの集合体とそのプロダクトそのものを指していて、Platform Engineering組織の中には当然フロントエンドエンジニアやデザイナー、プロダクトオ
ChatGPT:SREやDevOpsなどのソフトウェアの運用に伴う課題解決に関する提案を行うプロンプト - じゃあ、おうちで学べる
はじめに ソフトウェアの問題解決に関する提案してくれるプロンプトを利用することは、今後の開発者やエンジニアがより効率的に問題解決を行うための重要な手段の一つになります。というか毎回、適切なプロンプトを作成するのが面倒になった。このプロンプトには、ソフトウェア開発におけるベストプラクティスやDevOps、SRE方法論などの知識や経験が共有され、開発者やエンジニアの能力向上に貢献することができるようになれば良いなーと妄想しております。GPT4 のみを対象にしています。GPT3.5 で改善を試みたけど4ほど良い内容が返ってこない。 効果 ユーザーの問題を効果的に解決するための具体的なソリューションを提案します。 DevOpsとSREの手法を活用して、ユーザーのソフトウェア開発プロセスを改善します。 ユーザーとのコミュニケーションを通じて、問題解決の過程でのフィードバックを得ることができます。 想
『家族アルバム みてね』を支えるオンコールエンジニア制度 | gihyo.jp
株式会社MIXIで『家族アルバム みてね』（以下みてね）のSREグループに所属している本間です。 みてねは現在、1,500万人を超えるユーザに175の国と地域でサービスを提供しています(2022年8月現在)。そこで、より高い信頼性と可用性を担保するためにみてねのSREグループではオンコールエンジニア制度を設けています。 今回はこの「みてねのSREグループにおけるオンコールエンジニア制度の取り組み」についてご紹介させて頂きます。 オンコールの定義 まず、どのような条件でアラートを設定しオンコールを実施するかの定義について簡単に触れておきます。 現在はさまざまなソースから多種多様な情報を収集することができます。 たとえば、みてねではKubernetes（Amazon EKS）を採用しています。Kubernetesだけでも非常に多くのメトリクスが収集できますが、それだけではなくアプリケーション
エラーバジェットとは｜CAMPFIRE 開発チーム
エラーバジェット（Error Budgets）とはエラーに対する予算であり、SLOに基づき算出される損失可能な信頼性である。サービスの計測された稼働時間がSLOを超えている、換言すればエラーバジェットがまだ残っている状態であれば、チームは新しいリリースをプッシュ（デプロイ）できる。エラーバジェットはプロダクトマネージャーによって規定される客観的なメトリクスであり、SREとプロダクト開発者の緊張を取り除くものである。 SREにおけるエラーバジェット一般的にプロダクト開発チームとSREチームは目的が異なるため、しばしば両者の間に緊張が生じる可能性がある。 例えば、プロダクト開発チームのパフォーマンスは、主にプロダクトの開発速度で評価されるが、SREチームのパフォーマンスはサービスの信頼性によって評価される。プロダクト開発チームができる限り早く新しいコードを投入することにインセンティブを感じる一
ZOZO プラットフォームSREとコロナ禍におけるチームリーディング術
MLOpsチームは４名程度の規模だったのですが、PF-SREチームは当初から8名という大所帯(現在は10名)で、適切なチーム人数と言われる Two Pizza Rule の8人を超えてしまい、チーム運営のやり方を変えていく必要がありました。 また、2020年2月頃からCOVID-19によって週5リモートワークに代わり、その中で如何に効率を落とさずにチームとして働くかを模索していく必要がありました。 本記事では、小さなチームから、大きなチームのリーダーに移り変わるにあたってどのような変化を進めていったのか、またCOVID-19におけるリモートワークにどのように適合していったのかを記載していきたいと思います。 チームリーディングで気をつけていること私がチームをリードするときに気をつけていることは、約一年前に発表したZOZO MLOps のチームリーディングとSRE (Engineering)と
Sreake流 SREの始め方
SPI原点回帰論：事業課題とFour Keysの結節点を見出す実践的ソフトウェアプロセス改善 / DevOpsDays Tokyo 2024
SRE の原則に沿ったトイルの洗い出しとトラッキング | Google Cloud 公式ブログ
※この投稿は米国時間 2020 年 2 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。 作業効率を検証するために Google のサイト信頼性エンジニア（SRE）が使用している主な測定指標の一つが、日々の時間の使い方です。長期間のエンジニアリング プロジェクトのために時間を確保する必要がありますが、エンジニアには Google のサービスを稼働し続ける責任もあり、そこにも手作業が生じることがあります。Google の SRE は、いわゆる「トイル」に費やされる時間を勤務時間の 50% 未満にすることを目指しています。では、トイルとは何でしょうか。トイルに邪魔されずに開発スピードを維持するには何をすべきでしょうか。本稿ではこれらの問いについて見ていきます。 まずトイルの定義ですが、『Site Reliability Engineering』の第 5 章には次の
Eliminating Toil をやっていく話 - Qiita
SRE Advent Calendar 2019 14日目の記事です。 皆さんこんにちは。都内某社でSREっぽいことをしているものです。SREを名乗り始めてから早2年も経過してしまいました。 本記事では日々のモチベーションを削ぐToilの削減についてこの2年間一体何が出来たかを振り返ってみたいと思います。 Toilの定義 まずはおさらいとしてToilの定義を復習しようと思います。 英単語的な意味は「骨折る、骨折って働く、骨折って進む、難渋しながら歩く」ですが、GoogleのSRE本 では下記のような作業と定義しています。 手作業（Manual） スクリプトの手動実行も含む 繰り返し作業（Repetitive） 自動化可能（Automatable） 戦術的（Tactical） 割り込みで作業が発生する On-call対応とかも 永続的な価値なし（No enduring value） サービス
SRE Practices in Mercari Microservices
This is a slide for SRE NEXT 2020 (https://sre-next.dev/). Mercari Microservices Platform Team is building a platform for backend developers to build and run microservices. Currently, in this platform, around 100+ microservices are running and more than 200+ developers are working with. To run this scale of platform, the reliability is really critical. In this talk, I will share how we operate thi
「信頼性」を保ちつつ大規模サービスをリニューアルする / cookpad-tech-kitchen-service-embedded-sres
Cookpad Tech Kitchen #24 5800万人が使うサービスのリニューアルとその技術 ( https://cookpad.connpass.com/event/183385/ ) で、"「信頼性」を保ちつつ大規模サービスをリニューアルする" というタイトルで発表した際の資料です。 スライド内のリンクは次のとおりです。 - How SRE teams are organized, and how to get started: https://cloud.google.com/blog/products/devops-sre/how-sre-teams-are-organized-and-how-to-get-started - Design Docs at Google: https://www.industrialempathy.com/posts/design-docs
SREとしてMercariに入社した | SOTA
1月16日よりMercariにてSRE/BSE（Backend System Engineer）として働いてる． これまではとある会社で社内向けのPaaSエンジニアとして働いてきた（ref. PaaSエンジニアになった）．PaaSの目標である「アプリケーション開発者の効率を最大化」を突き詰めながら少人数のチームでいかにScalableなプラットフォームを構築するかに注力してきた．Cloud FoundryやDockerといったインフラの最前線とも言える技術やアーキテクチャに触れ，かつその中で自分の技術的な柱である自動化に取り組むことができたのは非常に刺激的で自分に大きなプラスになった． その一方でPaaSというプラットフォームはその性質上サービスそのものからは中立的になることが避けられない（だからこそScalabilityを実現できるのだが）．よりサービスに近い部分，サービスの成長に直結す
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.
What is an error budget—and why does it matter? | Atlassian
Implementing Site Reliability Engineering in your organization
Amazon.co.jp: SREの探求 ―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践: David N. Blank-Edelman (編集), 渡邉了介 (翻訳), 山口能迪 (監修): 本
SRE Is the Most Innovative Approach to ITSM Since ITIL - DevOps.com
https://sre-next.dev/
Amazon.co.jp: SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム: Sky株式会社玉川竜司 (翻訳), Betsy Beyer (編集), Chris Jones (編集), Jennifer Petoff (編集), Niall Richard Murphy (編集), 澤田武男 (監修), 関根達夫 (監修), 細川一茂 (監修), 矢吹大輔 (監修): 本
