イオンスマートネクスト SREチームの荒井のインタビューです。AWSやフリーランスなどを経て、組織改善に貢献したいという想いで2023年にイオンへ入社。信頼性に関わることは何でもやるSREチームにて求められる役割やレベルに応えるべく、荒井が取り組むチームの土台作りやチームの理想について語ってくれました。
![「ユーザー検知で障害に気づいたら、SREとして負け」元AWSエンジニアが感じたイオンネクストが目指すレベルの高さ|エンジニアインタビュー |AEON TECH HUB](https://cdn-ak-scissors.b.st-hatena.com/image/square/76bf79d08966d55ca3f69e541c9773f5cf051de9/height=288;version=1;width=512/https%3A%2F%2Fstorage.googleapis.com%2Fstudio-cms-assets%2Fprojects%2FogO0vl6Ea2%2Fs-1200x630_v-fms_webp_a221f57c-06ba-48d2-95ae-cf1d67fcf23f.png)
こんにちは、SREチームの後藤です。 8月3日と4日の2日間、Abema Towersで開催されたSRE NEXT 2024にて登壇させて頂きました。 こちらに、自身の登壇についての話と印象に残ったセッションなど参加レポートとしてご紹介させて頂きます。 正答率80%でギリギリゲットした信頼性カレー SRE NEXT 2024について 自分の登壇について 印象に残ったセッション 組織的なインシデント対応を目指して〜成熟度評価と改善のステップ〜 プロダクトのスケールによって顕在化しうるリスクをどう管理するか? 事業フェーズの変化を乗り越えるEnabling/Platform SREへの転換 まとめ We are Hiring! SRE NEXT 2024について 今年は、「Beyond NEXT」というテーマで2日間、オンラインとオフラインのハイブリッド開催でした。 私は両日とも現地で参加させ
23卒でバックエンドエンジニアをしているたかしゅんです。(@1341Shun) 先日、株式会社サイバーエージェントAI事業本部の2024年度 エンジニア新卒研修でシステム運用に関する講義を行いました。 そこで話した内容とスライドを完全公開したので、内容について解説します。 90分の内容のため、かなり長いですが、個人的にぜひ一読して欲しい内容になっています。 実際の資料はこちらになります↓ 自己紹介 こんにちは、たかしゅんと言います。2023年度入社で今年で2年目になります。 入社して最初に広告プロダクトに配属し、PipeCDの導入などのDevOps業務を中心に行なっておりました。 記事もあるのでもしよろしければ、ご覧ください。 2月中旬から移動し、新規立ち上げのインフラ環境の構築からCI/CDの整備などに取り組み、リリースを行いました。 業務外では来年開催の「SRE Kaigi」のコアスタ
本記事はNew Relic Advent Calendar 2023の25日目の記事となります。 qiita.com はじめに こんにちは。はたらこねっとのユーザー向けサイトのバックエンドエンジニアをしている大塚です。 はたらこねっとではサービスのモニタリングなどにNew Relicを活用しています。 New Relic にはアプリケーションのモニタリング以外にも様々な機能が用意されています。 その中でも「Service Levels」の機能を使ったSLI/SLOの策定と設定を行っているので、そちらについてご紹介させて頂きます。 なお、細かい操作方法などは本記事では触れません。 本記事で登場する用語について クリティカル ユーザー ジャーニー(CUJ) ユーザーがサービスを利用する際の重要な経路やプロセスを表したものです。 サービスレベル指標(SLI) サービスレベルを測定するための具体的
こんにちは。データ・AI戦略部 SREチームの小野です。2020年8月に入社してから早3年。SREエンジニアとして、日々業務改善に励んでいます。 ここ一年ほど、DAOという組織改善プロジェクトを推進してきました。このプロジェクトは組織内で発生するあらゆるイベントを「機能」として定義・実装し、それらを束ねてサービスとして組織内外に提供するプロジェクトです。 ※ 詳細はSREエンジニアが組織改善プロジェクトを立ち上げてみたを参照ください これまでの通常業務をサービスとして提供するという考え方は、我ながらとてもユニークかつ俊逸な発想だったと感じています。なぜなら、このサービスベースな考え方により組織にSLI/SLOを導入しやすくなったためです。 SLI/SLOの導入は個人的に難しいと考えています。導入するためにはさまざまな「ハードル」を突破する必要があるためです。しかし一方で、SLI/SLOを導
SREのプラクティス導入による文化面の変化などを踏まえ、「火消し」「門番」「パートナー」「触媒」の4フェーズを紹介します。自チームの現状把握と今後の方向性を検討する上での材料になったら幸いです。*1 火消しフェーズ 火消しフェーズ 初期段階では開発チームが機能開発のタスク(Feature Task)に注力し、サービスに必要な信頼性に関するタスク(Reliability Task)が対応領域に含まれないことがあります。このフェーズではSREチームが火消し部隊としてReliability Taskを巻き取り、信頼性の向上に努めます。コラボレーションなどは考慮されず、火消しが最優先となります。そのため、Reliability TaskはSREチームだけが処理するものとなっていき、後の門番フェーズに突入します。 門番フェーズ 門番フェーズ 信頼性に関するタスクの大部分をSREチームが対応しているフ
柘植 翔太 メディア統括本部サービスリライアビリティグループ マネージャー / SRE 2014年新卒入社。インフラエンジニア、SREとして、AMEBA、AWA、社内基盤など50以上のメディアサービス・システムへのSRE推進、リスク改善、サービス立ち上げを経験。現在は、横断SRE組織のマネージャーとして、SREのEnablementや人材育成へ注力している。 ── 柘植さんの現在の役割をおしえてください 私は、メディア事業横断のSRE組織のマネージャーをしています。主にメディア事業を担当し「Ameba」「AWA」「タップル」「CL」「社内基盤」など様々なサービスやシステムへのSRE導入をしてきました。また、インターネット広告事業やゲーム・エンターテイメント事業とも連携しながら、横断的なSRE(Site Reliability Engineering)組織を構築する事を目指しています。 この
皆さんこんにちは、エンジニアリンググループの高橋(@tshohe1)です。 この記事はエムスリーSREがお届けするブログリレーの15日目です。 他の記事でも何度か説明されていますが、エムスリーでは2019年頃からチーム横断的なシステムを管理する「コアSRE」とは別に、サービスチーム内にて各サービスのインフラを重点的に見る「チームSRE」というポジションを新たに設けています(チームSRE化の流れの詳細については下記ブログリレー最初の記事*1を御覧ください)。 私は入社時点ではコアSRE(当時はまだインフラチーム*2)として働いていましたが、2019年頃からサービスチーム側SREと兼務したりコアSREに戻ったりまたチーム側SREに移動したりとふらふらしている謎の存在になっていました。 現時点ではコア/チーム側両方に所属していた者はいないはずなので、本記事ではコアSRE側の視点/チームSRE側の
盛況のうちに閉幕しましたオフラインイベント。お暑い中多数のご来場をいただき、ほんとうにありがとうございました! 2日目 7/8 の 15:10 より、標題の 長すぎる タイトルのセッションで登壇しました。その時に資料を公開します。 「開発環境」と銘打っていますが、運用がメイン担当であるエンジニアの方にとってもヒントになるものを盛り込めたのではないかなーと自負しています。 *1 内容 日々大切なアプリケーションを開発されている開発者の方々のなかには、開発基盤やパイプラインに何かしらの課題を感じている方も多いのではないでしょうか。 それらを一撃で吹き飛ばす特効薬「銀の弾丸」はもちろん存在しませんが、その一部は、ツールや手法・考え方の工夫次第で軽減できるものかもしれません。 状況の変化に合わせて武器や装備を整え直すRPG(ロールプレイングゲーム)のように、開発環境やパイプラインに改善の余地はない
サイバーエージェントグループには、様々なSRE組織があり、日々サービスの信頼性向上に取り組んでいます。 6月27日〜28日にかけて開催した「CyberAgent Developer Conference 2023」では、当社のDeveloper Experts(SRE領域)を務める柘植が、サイバーエージェントグループのSRE組織やSREsの活動についてもご紹介しました。 柘植 翔太 2014年新卒入社。インフラエンジニア、SREとして、AMEBA、AWA、社内基盤など50以上のメディアサービス・システムへのSRE推進、リスク改善、サービス立ち上げを経験。現在は、横断SRE組織のマネージャーとして、SREのプラクティス開発やEnablement、人材育成へ注力している。 サービスリライアビティグループというメディア事業横断のSRE組織のマネージャーをしている柘植と申します。本日はデータで見る
こんにちは。12/1 サービス基盤本部の本部長を務めている鈴木(@syou1024) です。 マネーフォワードの全社のサービスのインフラ関連の組織について、今までとこれからについて話そうと思います。同じような悩みを持つ方のヒントになったり、またマネーフォワードのSRE、インフラエンジニアに興味を持って頂けたら嬉しいです。 サービスのインフラチームの歴史 現在のマネーフォワードでは、全社のプロダクトのインフラを担当するサービスインフラチーム、幾つかのプロダクトの開発チームの中に存在するプロダクトのSREチームと、複数のインフラ、SREチームが存在します。 サービスインフラチームはサービ基盤本部に所属していて私が管掌しています。また、サービス基盤本部の本部長就任前にプロダクトのSREチームを一番最初に作ったのも私です。 マネーフォワードのインフラの組織が「なぜそうなってるのか?」。まずは私から
小中高 SRE チームで Engineering Manager をやっている @yuya-takeyama です。 Quipper にはスタディサプリ ENGLISH の SRE である ENGLISH SRE チームと合わせて 2 つの SRE チームがありますが、この記事では自分たち小中高 SRE チームについての話です。 少し前の話になるんですが、小中高 SRE チームの Vision, Mission, Values というものをチームで作りました。 Quipper には会社としての Vision, Mission そして Quipper Identities というものがあります。 これらは策定から数年以上経っていますが、Quipper の社員にとって今も変わらず大事なものです。 が、SRE チームにとっては教育や学習に対して直接的に貢献しているとは言いづらい状況です。 そこで
以下イベントを見てたときのメモ的なあれです。SREの初学者目線で学べたことを書きました。全ては見れてません。 全体通して学んだこと 「SREとは」といったところから定義しているところが多かった こうしないとインフラエンジニアの名称が変わっただけのただの便利屋になってしまう 何ができて何をするのか https://blog.studysapuri.jp/entry/sre-vision-mission-values SREはSREでも種類があったりした CenterOfPractice(CoreSRE、pureSRE、横断SREなど) 全社としてのSRE ベストプラクティスの策定 ツールの選定や開発 EmbeddedSRE プロダクト開発チーム内としてのSRE Embeddedだと外から埋め込むという意味合いになってしまうので、内部からの場合はenablingといった表現をしている会社もあっ
2022年6月に、Androidテックリードになった いわたん です。最近、某モンスターを育てたり図鑑を埋めたりするゲームで社内大会をやったらフルボッコにされて涙目でした。悔しくて最近は不思議な力でクラフトしたり空飛んだりして王国を救うゲームやってます。 今回はAndroidテックリードとして1年間やってみた施策の紹介と、それぞれの成果や反省点を紹介したいと思います。これからテックリードになろうとしている方やテックリードをしている方の参考になったり、こんな施策もいいよというアドバイスをもらえたら幸いです。 ZOZOのテックリードの役割と責任 実施した施策 テックリード1on1 読書会 歴史的経緯があるアプリのアーキテクチャ整理へのアプローチ ネーミングセンスを鍛える会の取り組み 案件への関わり方 横断的なコードレビュー 横断的に使う機能の実装 まとめ 最後に ZOZOのテックリードの役割と
【SREチーム ブログリレー4回目】 こんにちは、SREチームの後藤です。 障害が発生した時、魔法のように原因を特定し颯爽と解決していくスーパーな同僚は皆様の周りにもいませんか? その姿に憧れてそうなりたいと思ったことが誰しも一度はあるはず。 ですが、話を聞いてみると「なんとなく怪しそうだった」「勘でここかなと思った」と言われたりして、まったく参考にならなかったこともあるのではないでしょうか。 そこで今回は私が考える障害調査において意識すべきポイントを、なんとなくではなくしっかりと言語化してまとめたいと思います。 題して「なんとなくで終わらせない、言語化すると見えてくる障害調査の5つのポイント」 神頼みしたくなる時も挫けずに強い心を持つことも大事 1. 調査できるように備えておく 2. 事象を正確に把握する 3. 事実と推測を区別する 4. 先入観を排除する 5. 問題を局所化する まとめ
LAPRAS株式会社でSREをしているyktakaha4と申します🐧 弊社のSREチームで最近運用をはじめた見積もりやふりかえりの手法について書きたいと思います 大規模な立ち上がり済みの組織向けでなく、今ひとりで仕事をしている人が2人目のSREを迎え入れたときの一事例としてご覧ください 経緯 弊社は2016年に創業して以来、ソフトウェアエンジニアとして入社した社員がアプリケーションからクラウドまでプロダクト全体を開発・運用するというスタイルが取られていましたが、 エンジニア組織の拡大に伴い、2021年頃からプロダクトの信頼性や可用性の向上を責務とする専任のSREを立ててシステムの改善をおこなってきました 以下は、弊社で導入しているホラクラシーに基づいて定義された Site Reliabilityサークル のロールの一覧です 原則として、ロールは誰であっても自由に負うことができるので、主務
はじめに こんにちは。Google Cloudでオブザーバビリティの担当をしているものです。 昨日、シンガポールで開催されたスタートアップ向けのイベントにリモート登壇したのですが、そこでスタートアップでもSLOを活用しましょう、というテーマで話しました。 せっかくなので日本語にしておこうと思い、スライドを抜粋しながら内容の一部を記事にしておこうと思います。発表内容を記事化してるので、文体が少し発表のようになっているのはご容赦ください。 「ユーザーからの信頼性」が大切 まず、スタートアップ、さらにはWebサービスに限らず、あらゆる事業において、顧客に対する信頼は重要です。荷物が全然届かない配送業者は利用したくないですし、接続してもつながらないISPは契約したくありません。飛行機も統計上事故の確率が低いから利用するわけで、自動車並に事故が発生していたら絶対利用しません。日々私たちがさまざまなサ
本稿はJCB Advent Calendar 2022の12/20の記事です。 JCB デジタルソリューション開発部 SREチームの笹野と申します。 今回はJDEP(JCB Digital Enablement Platform) におけるSREチームの体制ついてご紹介します。 SREチームとは JDEPではGoogleが提唱しているSRE(Site Reliability Engineering)の考え方をベースにチームを組成しています。 ミッションとして、各アプリチームが継続的に(信頼性高く)サービスを提供できる状態を提供することを掲げており、 ひいては、JDEPで提供するサービスを使用するお客様の満足度を維持することを目的としています。 こうしたミッションをもとに、各工程での取り組みをSREとして実践すること、また各アプリチームにSREの考え方や手法を注入することを日々実施しています
本投稿は、さくらインターネットアドベントカレンダー2022の14日目の投稿です。 この記事では2022年7月に発足した「SRE室」という部署について+これまで私が取り組んできたお仕事の一部を紹介します。 はじめに さくらインターネットへ入職しSRE室で働き始めてからもうすぐ半年となります。 febc-yamamoto.hatenablog.jp 新しい環境に慣れるまで苦労しましたが、ここ数ヶ月はだいぶ落ち着いてきており、最近は毎日の仕事がとても楽しく感じられています。 これまでSRE室としての取り組みをあまり紹介できていませんでしたが、せっかくのアドベントカレンダーという機会なのでここで紹介させていただきます。 SRE室の紹介 SRE室とは 2022年7月に発足したばかりの新しめの部署です。 以下のような企業理念/ミッション/ビジョン/バリューに従い日々の業務へ取り組んでいます。 企業理念
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く