こんにちは、Backlog SREチームのmuziです。 この記事は SRE Advent Calendar 2019 の10日目、およびBacklog Play化プロジェクトブログの番外編です。 先日のブログ記事「SREは大規模なリプレイスプロジェクトで発生した様々な問題にどう取り組んだか【Backlog Play 化プロジェクト】」の後半では、Play化プロジェクトの終了後に、開発チーム自身によるオンコール対応の取り組みを始めたことを軽くご紹介しました。 私を含むBacklogのSREチームは、このオンコール対応を助けるためのアラート通知システムを作り、開発者なら誰でも使える形で提供しています。この記事では、前回のブログ記事では書ききれなかった、このシステムの詳細をご紹介します。 同じような問題意識を抱えていて、これからオンコール対応を見直したい、と考えているSREや開発者の参考になれ
Google Cloud Operations Suite で実現する "頑張らないオブザーバビリティ" - KAYAC engineers' blog
SRE チームの市川恭佑です。 先日、CloudNative Days Tokyo 2023 のプロポーザルを提出したのですが、残念ながら採択に至らなかったので、今回は宇宙最速の（？）供養エントリになります。 シェア・投票など、ご応援をくださった皆様にはこの場でお礼を申し上げます。ありがとうございました。 event.cloudnativedays.jp 背景とか、経緯とか 筆者は、カヤックの SRE チームにちょうど2年ほど在籍しています。とは言っても半年ぐらいは学生アルバイトだったので、正社員としては1年半ほどです。カヤックに入る前も、いくつかの会社で IT エンジニアとしてインターンやアルバイトをしていました。 という訳で、何だかんだ仕事で使うプログラムを書き始めてトータル4年半ほどになりますが、そのうち3年半ほどは全て Amazon Web Services（AWS）でホストされる
すべての人類が読むべきマンガ、フラジャイル【SREと病理医の共通点のお話】 - okadato の雑記帳
この記事は SREアドベントカレンダー 2019 11日目の記事です。 テック要素ゼロ・エモ全振りの内容なので、SRE以外の方にもぜひご一読いただきたいです！ 【追記】 SRE とは Site Reliability Engineering の略です！詳細は弊SREチーム Mng のコチラの記事をご覧ください！ 改めましてになりますが、スタディスト開発部はSREチームに所属のおかだと申します。 突然ですがSREとして働いているみなさん、月刊アフタヌーンで連載されている「フラジャイル 〜病理医岸京一郎の所見〜」というマンガをご存知でしょうか？ 2016年には長瀬智也さん主演でドラマ化もされた作品です（ぼくは原作しか読んでいないのですが…） 病理医という（ちょっとマイナーな？）職業がテーマの、個人的に超イチオシのマンガです！！ まずは作画をなさっている恵三朗さん（@36_Megu）の Twit
MLOpsチームは４名程度の規模だったのですが、PF-SREチームは当初から8名という大所帯(現在は10名)で、適切なチーム人数と言われる Two Pizza Rule の8人を超えてしまい、チーム運営のやり方を変えていく必要がありました。 また、2020年2月頃からCOVID-19によって週5リモートワークに代わり、その中で如何に効率を落とさずにチームとして働くかを模索していく必要がありました。 本記事では、小さなチームから、大きなチームのリーダーに移り変わるにあたってどのような変化を進めていったのか、またCOVID-19におけるリモートワークにどのように適合していったのかを記載していきたいと思います。 チームリーディングで気をつけていること私がチームをリードするときに気をつけていることは、約一年前に発表したZOZO MLOps のチームリーディングとSRE (Engineering)と
Terraform Modules で再利用できるので最高ではないでしょうか？ - じゃあ、おうちで学べる
概要 ModuleはTerraformの複数のリソースをまとめて再利用可能な単位として扱うことができます。Moduleを使うことで複雑なリソース構成を抽象化し、システムの構造の把握やリソース構成の再利用が可能になり、読みやすさや可読性が向上し、修正箇所が単一になるなどのメリットがあります。 ただし、理解には初期コストが必要です。Moduleの設計では、1つの機能を持つように小さくシンプルに保つことが重要で、それが難しい場合は大抵複雑と言えます。 また、公式のModuleを利用することで、自身で定義やドキュメントの整備、メンテナンスの手間を省きつつ、プロジェクトを超えて共通認識として扱えるため、Module理解のコストが減ります。 しかし、どのタイミングでModuleに組み込むかの正解は、個々のプロジェクトの特性や開発チームの状況により大いに変わるでしょう。 絶えず試行錯誤を繰り返しながら個
こんにちは、データエンジニアの石井です。 先日公開した記事「社内向けのデータ基盤から集計結果をReverse ETLしてサービスに組み込んだ話」で、ダッシュボード機能のリリースにより、Classiのデータ基盤が「社内用データ基盤」から「ユーザー影響あるシステムの一部」へ進化した話をしました。「ユーザー影響あるシステムの一部」への進化に伴い、データ基盤の品質担保は必要不可欠です。今回は、データ基盤の品質向上に取り組んだKANTプロジェクトについてご紹介します。 KANTプロジェクト 背景・課題 Classiのデータ基盤がユーザー影響あるシステムの一部になる前、つまり社内用データ基盤だった頃には以下のような課題がありました。 データ基盤の状態把握 マルチクラウドにおけるデータ基盤全体の状態把握ができていなかった データ基盤の実行状態（SUCCESS, FAIL, RUNNINGなど）の把握が、
New RelicのSLOモニタリング+バーンレートアラートをCDK for Terraform(cdktf)でIaC管理する - Uzabase for Engineers
こんにちは、ソーシャル経済メディア「NewsPicks」でSREをしている飯野です。 今回はSREで行ったNew RelicをCDK for TerraformでIaC管理する話を紹介したいと思います。 SLOモニタリングをSREチームだけで行うのは難しい CDK for Terraformとcdktf-newrelic-provider 追記 IaCで作成する内容 CDK for Terraformで実装していく -1. cdktf init 0. @cdktf/newrelic-provicerの初期化 1.DataNewrelicEntityの作成 2.ServiceLevelの作成 3.AlertPolicyの作成 4.AlertCondition（バーンレートアラート）の作成 5. NotificationDestinationの作成 6. NotificationChannel
SRE界隈の隅っこでワチャワチャやっているしょっさんです。 今色々やっているコミュニティ活動についてのお話を書き留めておきたいなと思ったので、ここにパパッと書いていきます。 今までについて 今までのコミュニティ活動の関わりについては以下のしずかなインターネットの記事として書きました。 sizu.me そんなこんなで「ゆるSRE勉強会」の運営に関わらせていただいているのですが、せっかく再びコミュニティ活動始めたなら色々やってみっか！ってことで色々走らせてみました。 SRE Magazine SREに関する記事を探すと様々なところに散らばっており、SRE Weeklyみたいな集約された場所があると面白いよな〜ということでエイヤの精神でやってみました。 sre-magazine.net 「るびま」を参考に構成しているWebマガジンなのですが、最近第１号が発刊することができました。で、始めるにあた
情報セキュリティ部「部内勉強会」の取り組み
はじめに MICINの情報セキュリティ部では、2021年3月から部内勉強会を毎週開催しています。最初は4名から始まりましたが、部門メンバーの増員や組織改編もあり、現在は毎週10名程度が参加し、持ち回りで発表を行っています。勉強会の目的としては、 最新の技術情報の交換 各自の業務内容のアウトプット・キャッチアップ 各自が興味のある情報の共有 としており、本の輪読や技術解説、ハンズオンなど形式は様々で、ジャンルも情報セキュリティ部が担当するセキュリティやSRE・インフラ分野だけでなく、生成AIやワークスタイルなど、情報セキュリティ部のメンバーとして有益な情報であれば、何でもOKとしています。 この記事では、2023年に部内勉強会で発表された内容をジャンル別にご紹介します。情報セキュリティ部の1年間の取り組みについて、簡単に知っていただければ幸いです。 部内勉強会の様子（オンラインとのハイブリッ
皆様はじめまして！ NewsPicks SREチームの中川です。 本日はコンテナイメージのバージョン管理についての記事をお届けします。 概要 実装 ビルド デプロイ Pros Cons おわりに 概要 NewsPicksではECSやKubernetesに代表されるコンテナサービスを使用しておりますが、コンテナのデザインパターンとしてサイドカーパターンを採用しているサービスがあります。 詳しい説明は省きますが、サイドカーはメインアプリケーション用コンテナを補助するコンテナです。 これらのサービスをデプロイするとき、サイドカー毎に使用するDockerfileを ImageTag で指定していました。 実際には latest で固定するか、特定のImageTagを設定ファイルに書き込んで運用していました。 こうした運用方法の場合、Dockerfileを変更するときは事前にイメージを登録しておく必
Topotal CTOの@rrreeeyyyさんにSREについて聞いてみました! | CyberAgent Developers Blog
技術本部 サービスリライアビリティグループ（SRG）の小沢です。 #SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。 SRGではリモートワーク中心のメンバーが多いため、組織活性化を目的として、Zoomを使って気になるニュースについての雑談や最近起きた障害の共有、他部署のゲストを呼んで交流などを行う SRG Chatting というイベントを週一で開催しています。今回は、初めての取り組みとして社外の方にゲスト参加していただきました。 きっかけ チーム内でSRE活動を行う機会も増えてきて、e34.fmのSRE回が話題になったこともあり、より具体的な話が聞きたいと思い、e34.fmのホストで、TopotalのCTOである吉川(@rrreeey
ゼロベースでSLOの存在意義はなにか？適切なSLIはどうやって決めるのか？を考察・調査し、まずはプラットフォームの一部のチームでSLOを策定しました。それまでの苦労を含めてSLOがなぜ必要か、またSLIをどのように決めたのか等お話します。 Cloud Operator Days Tokyo 2023で使用したスライドです。
生産性向上は一筋縄ではいかない Q&A [デブサミ2022夏] - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。生産性向上チームの平木場（@korosuke613）です。最近はよくダーツを投げています。好きな料理は辛麺1です。 この記事では、Developers Summit 2022 Summer で発表した「生産性向上は一筋縄ではいかない 〜改善を進める上で生じる課題との付き合い方〜」に寄せられた質問に対して回答します。 はじめに 先日 Developers Summit 2022 Summer というイベントで生産性向上チームの活動を発表してきました。 タイトルは「生産性向上は一筋縄ではいかない 〜改善を進める上で生じる課題との付き合い方〜」です。 Developers Summit とは翔泳社さんが定期的に開催しているソフトウェア開発者のためのカンファレンスです。 2022/07/21 に開催された Developers Summit 2022 Summer は「アジャイル・De
![生産性向上は一筋縄ではいかない Q&A [デブサミ2022夏] - Cybozu Inside Out | サイボウズエンジニアのブログ](https://cdn-ak-scissors.b.st-hatena.com/image/square/f50c746256022d4a279ab6ba08733c18e5ce1282/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F8454420450104491317%2F4207112889907995663%2F1669617091)
メルペイSREチームの @tjunです。この記事は、Merpay Tech Openness Month 2020 の19日目の記事です。 今日は、メルペイSREチームのオペレーションのために開発して利用している Qray(クレイ) というツールの話をします。 はじめに メルペイでは、Google Cloud Platform(以下GCP)を利用してサービスを構築し動かしています。 GCPには Cloud Identity and Access Management (IAM) という権限管理の仕組みがあります。IAMを適切に管理して、アカウントに最低限の権限を付与することがクラウドサービスを安全に利用するためには必要なことです。これはSREが持つ本番環境に対する権限についても同様で、できるだけ本番環境に対する権限を持たないようにしておきたいのですが、障害対応など本番環境でのオペレーション
7月25日、SRE Weekly Issue #280が公開された。 SRE Weeklyは、SRE（Site Reliability Engineering）に関する注目情報を紹介するメールマガジン。 堅牢性の原則がもたらす弊害 The Harmful Consequences of the Robustness Principle 堅牢性の原則（送信するものに関しては厳密に、受信するものに関しては寛容に）は成熟したプロトコルの開発には最適でないかもしれない。 私たちはKubernetesを使用していません。 No, we don’t use Kubernetes なぜKubernetesが自分たちに合わないのかを説明している。 サービス停止時（CDN停止時など）の個人情報漏洩報告 Personal data breach reporting for service outages (s
Snyk IaC + reviewdog + aquaではじめるDevSecOps - Gunosy Tech Blog
はじめに Snyk IaCとは CIでのIaC解析 aquaでSnyk CLIを簡単にインストール＆バージョン管理 reviewdogでコメント形式の指摘を実現 まとめ はじめに こんにちは。技術戦略室SREチームのkoizumiです。 最近は、katoさんからオススメいただいた「スクワットの深さは人間性の深さ」という本を読み、日々スクワットに励んでいます（大嘘）。 さて、こちらの記事は Gunosy Advent Calendar 2022 の9日目になります。 昨日の記事はGunosy Tech Lab 石川さんの「リモートモブプログラミング開発の実践」でした。 本日は「Snyk IaC + reviewdog + aquaではじめるDevSecOps」と題して、CIへSnyk IaCを導入した事例についてご紹介します。 先日、私が執筆したこちらの記事でも、「Shift-Leftによる
SREはソフトウェアコードの再利用性、モジュールの共通化部分に正面切って取り組める【#3 論より動くもの.fm】 - STORES Product Blog
CTO 藤村がホストとなって、技術や技術にまつわることについてざっくばらんに話すPodcast、論より動くもの.fmの第3回を公開しました。今回は、CTO 藤村とSREの藤原で、SREやDevOpsについて話しました。 論より動くもの.fmはSpotifyとApple Podcastで配信しています。フォローしていただくと、新エピソード公開時には自動で配信されますので、ぜひフォローしてください。 テキストで読みたい方は下記からどうぞ。 なぜ変更容易性が重要なのか 藤村：みなさん、こんばんは。論より動くもの.fmです。論より動くもの.fmはheyのCTO 藤村が技術や技術にまつわることについてざっくばらんに話すPodcastです。今日はheyのSREの藤原さんに来てもらいました。藤原さん、よろしくお願いします。 藤原：よろしくお願いします。 藤村：まずは簡単に自己紹介をお願いします。 藤原：
Kaigi on Rails 2021の発表 https://kaigionrails.org/2021/talks/lchin/ "Performance is a feature"と言われています。 スピードは機能だとしたら、それはプロダクトの様々な機能の一つに数えるということになる。その機能のオーナーとして、どのように事業にとって価値のある投資にできるのか？ このトークでは、パフォーマンスをプロダクト開発として捉えて改善に取り組むアプローチについて紹介します。
公開日 2024/01/23更新日 2024/02/15あのサービスの監視・オブザーバビリティ アーキテクチャ選定【前編】 ユーザーや顧客へ信頼性を担保した価値提供をしていく中で、監視・オブザーバビリティの取り組みは非常に重要です。 今回の特集記事では、合同会社DMM.com、株式会社MIXI、株式会社マネーフォワード、パイオニア株式会社、Sansan株式会社、株式会社ZOZOの6社の各サービスを支える監視・オブザーバビリティの仕組みとして各社がどのようなアーキテクチャを組んでいるのか、またそのアーキテクチャにしている背景や意図についてお伺いしました。 自社に近いアーキテクチャやどのようにツールを活用しているかについて、実際の事例を元に参考になれば幸いです。 なお、後編も近いうちに公開させていただきますのでお楽しみに。 合同会社DMM.com（DMMブックス） アーキテクチャ設計の背景・意
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、システム統括本部でPrivate PaaSを担当している増田彬（@Go_zen_chu）と水落啓太（@keitam913）です。 僕たちはPaaSチームとして3年半ほど、ヤフー社内で利用されるPrivate PaaSの運用と関連システムの開発に携わってきました。 その中でどのようにPaaSを通じて利用者へ利便性を提供し、安定して稼働する体制作りをしてきたのかをお話しします。 PaaSとは？ PaaS（Platform as a Service）という単語はさまざまな用途で利用されますが、その中で僕たちが提供しているのは、「社内のエンジニアが簡単にアプリケーションを動作することができるプラットフォーム」です。 この「簡単
SREチームの橋本です。SRE連載の7月号になります。 カヤック社内では弊社藤原のecspressoをAmazon ECSのデプロイツールとして活用していますが、AWS公式のデプロイツールAWS Copilot(現在v1.29)もそのオールインワン的な性質から、開発・運営リソースが限られるプロジェクトでは選択肢に入るようになってきました。 今回はそのAWS Copilot活用のため、背後にあるAWS CloudFormationテンプレートをカスタマイズする手法を紹介します。 AWS CopilotとCloudFormation AWS CopilotはECSなどのデプロイを簡単にするCLIツールですが、実態としてはManifestと呼ばれるYAMLの設定ファイルからCloudFormationテンプレートを生成し、各種リソースを作成・管理するものです。 AWS Copilotは内部的にC
Platform Engineering と Site Reliability Engineering について - Qiita
この記事はスタンバイ Advent Calendar 2022の12日目の記事です。 Platform Engineering と Site Reliability Engineering（以下SRE） について考えていきたいと思います。 この記事の目的 この記事では SREという言葉の定義と最近の取り組み事例についての考察 Platform Engineeringという考えの紹介 Platform EngineeringとSRE の相違点、共通点 について書きたいと思います。 これは決して特定の個人や団体の考えを否定するものではなく、ご自身のキャリアや組織を考える際のヒントとして使って頂けたら幸いです。 SREという言葉 まずはSREという言葉について確認してみましょう。 O'Reilly Japan - SRE サイトリライアビリティエンジニアリングによると、 （開発/運用の分断に対し
「インフラで私が一番面白いと考えている世界」GMOペパボ株式会社 近藤 宇智朗（うづら） | Forkwell Press | フォークウェルプレス
Forkwell が主催する技術イベント「Infra Study」。今回のテーマは「インフラの面白い技術とこれから」です。（開催日：2020年 7月29日）。本記事は登壇者の近藤さんの基調講演から mruby や C言語を使い、コンテナを自作している様子をお伝えします。最後には、登壇者の近藤さんとまつもとりーさんが視聴者からの質問に回答しているので、ぜひご覧ください。 この回ではインフラで一番面白い世界について考えていきます。 皆さん、子どもの頃、中身が気になって時計を分解するようなことがありましたか？ 私はありませんでした。 にも関わらず今私が一番面白いと考えている世界はインフラの「中身」です。インフラエンジニアは、ともすれば与えられたOS、ミドルウェア、 マネージドサービスを上手に組み合わせることを求められますし、実際それらの要素を適材適所位配置できることは良いインフラエンジニア、アー
みんなでつくる Production Readiness - スタディサプリ Product Team Blog
こんにちは。SRE の @chaspy です。 以前、Production Readiness Checklist に関する記事を書きました。 quipper.hatenablog.com Production Readiness Checklist の運用開始から1年ほどの月日が経ち、27ものサービスが無事 Production へ出ていきました。 サービスを安心して Production へリリースするために役立っている Production Readiness Checklist ですが、Product Team がこの Check List を進める上でいくつか課題がありました。 本記事では、Production Readiness Checklist 運用開始後に、どのような改善が行われてきたのか、その内容と方法を説明します。また、1年以上の運用を通して、Production R
5月14-15日に開催されたSREの国内カンファレンス SRE NEXT 2022 ONLINEにて、「AIOps研究録―SREのためのシステム障害の自動原因診断」と題して、ITシステムに障害が発生した際に、機械学習・統計解析の手法を用いて、障害の原因を自動で診断するための研究について講演しました。 講演に用いたスライド資料を以下に公開しています。 当日に配信された講演動画は、Youtubeに公開されています。 なお、この記事では、AIOpsという用語を、機械学習や統計解析をはじめとするAI（人工知能）と呼ばれる技術を用いて、ITオペレーターのオペレーション作業を自動化あるいは支援する技術の総称として使っています。 なぜAIOpsに着目したのか 自分が、統計や機械学習をはじめとするAIと呼ばれる技術をSRE分野に適用することを漠然と考えはじめたのは、2017年ごろでした。当時、今後のSRE
2022年4月新設されたカオナビのCTO室について座談会形式で話す「kaonavi Tech Talk #8 ～部門横断で技術的課題に向き合う！CTO室メンバー座談会～」。ここでCTOの松下氏が登壇。座談会前の発表として、カオナビのCTO室について紹介します。 松下氏の自己紹介 松下雅和氏：カオナビでCTOをしている松下と申します。よろしくお願いします。本日は「部門横断で技術的課題に向き合う！CTO室メンバー座談会」という内容でお送りしたいと思います。 （スライドを示して）まず簡単に自己紹介させてください。私、松下雅和は、@matsukazという（IDで）Twitterなどのアカウントをやっているので、よければフォローなどお願いします。AWS、Node.jsといった技術がけっこう好きです。あと、娘が2人いる2児の父ということで、日々子育てでけっこう苦労して、バタバタしながら仕事をしています
SREは何を目指すのか
Front-end application development, Symfony-style(s)
こんにちは。ピクシブの社内エンジニア職横断組織「エンジニアギルド」マネージャのbashです。主にエンジニア採用プロセスを取りまとめています。 ピクシブでは複数の事業部があり、様々な専門性を持ったメンバーが集って事業領域にフォーカスする体制を取っています。各事業部にいる技術のキーパーソンがどのような考えでエンジニアリングを進めているのかを紹介したいと思います。 先日、pixivFACTORYというプロダクトで特別コラボ企画があり、普段とは違ったスペシャルな体制でリアルタイム対応が行われました。その件をテーマとして、pixivFACTORYのプロダクト開発と運用を主導しているFACTORY部エンジニアhayaと、ピクシブの全サービスインフラを横断的に管理しているインフラ部SREチームリーダーkonoizに、当日対応や準備の様子について話を聞いてみたいと思います。 まずは自己紹介をお願いします。
Cybozu における次世代障害対応研修の計画と実践 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは！SREチーム兼Manekiチームのhsnとaoi1です。今回サイボウズでの障害対応研修の紹介をします。 背景 cybozu.comでは現在2つの運用基盤が存在しています。 Forest と呼ばれている旧インフラ基盤と、2019年に運用を開始した Kubernetes をベースにした Neco と呼ばれている新基盤です。 Forest 基盤で動いているサービスを Neco 基盤に移すと同時に、サービスの運用体制を見直す機会に直面しています。これを担当しているのが我々Manekiチームです。 Forest 基盤の仕組み上、ほとんどの障害対応は Forest 基盤を運用する SRE チームにしかできなかったため、製品開発チーム（以下：開発チーム）と運用チームが完全に分れていました。 しかしこのチーム体制はコミュニケーションに時間がかかる、製品開発チームが自分たちの開発物をコントロール
CNCF連載 の4本目です。 はじめに数年前にクラウドネイティブ注目技術として挙げられたeBPFにかねてよりキャッチアップしたいなと思っていたので、この連載のタイミングでeBPFとその関連プロダクトに入門してみることにしました。 CNCFプロジェクト傘下のeBPFを活用したプロダクトとしてはCilium, Falcoなどが挙げられます。CiliumはKubernetesなどのクラウドネイティブな環境でネットワーク、オブサーバビリティの機能を提供するOSSなのですが、今回はそのいわばサブプロジェクト的な位置づけのセキュリティツールである、Tetragonに触ってみます。 Cilium, Tetragonの開発をメイン行っているIsovalent社は、書籍やハンズオンラボなどで自社の製品・eBPFについての学習リソースを多く提供しています。 https://isovalent.com/reso
CloudNative Days Tokyo 2020 #CNDT2020_A
「開発抽象化レイヤー」とは 「開発抽象化レイヤー」(Development Abstraction Layer)はご存知でしょうか。 これはJoel Spolskyが言い出した言葉で、彼の2006年のエッセイのタイトルにもなっています。このエッセイは大変おもしろいので必読です。ご存じなかった方はいますぐ読むことをおすすめします。 日本語訳もInternet Archiveから読めます。 ちなみに組込み方面では「HAL」という用語があります。これは「Hardware Abstraction Layer」の略です。HALはハードウェアの違いを吸収することで、プログラマにはハードウェアを意識させないよう「抽象化」するためのものです（が、実際には「抽象化の漏れ」が生じやすくて微妙な話が展開されるようなのですが、それはまた別の話になります）。 この「開発抽象化レイヤー」も、実際にはプログラマーが活動
Road to SRE NEXT@福岡(ハイブリッド開催) でLTした時の資料です。
SRE NEXT 2022で「プロダクション環境の信頼性を損ねず観測する技術」というお話をしました - ださろぐ@はてな
登壇＆参加エントリです。 ややエモよりになる予定。 当日の体験については他の登壇者の皆様とも少しお話したんですが、完全に馬場さんのエントリに書かれている点と同じ感想であり（事前収録は当日落ち着けてよい、参加者としてのZoom Event体験はかなり良かった、ブースの仕様はやや残念ではあったが個人的にはそれでも楽しめた）、まあ同じことを書いてもということで発表まわりや個別の参加体験の方を書いていきます。 登壇について プロダクション環境の信頼性を損ねず観測する技術というタイトルで登壇させて頂きました。 6/9時点でまだスライドのみですが、ぼちぼちアーカイブの方も上がってくるかなと思います。 www.youtube.com 前回2020の登壇から2年、SRE NEXTが開催されたら何はともあれproposalは出したいと考えていたので募集の段階でネタを考えました。 ネタは2本考え、1つは長期運
https://tech.dely.jp/entry/sre-next-2020
HashiCorp 製品導入の背景と今後の展望｜イオンスマートテクノロジーのDX ｜AEON TECH HUB
イオンスマートテクノロジー CTO室SREチームの香西が、「Cloud Native Week 2024冬」に登壇しました。HashiCorp製品導入の背景と今後の展望ということで、HCP Terraformを導入した背景などをまとめています。導入当時に抱えていた課題は何だったのか？HashiCorp製品を活用しながらどのように改善していったか？文末の資料と動画では、HashiCorp Japan・村田氏のプレゼン内容もご覧いただけます。
https://lancersrecruit.connpass.com/event/219434/ 【SPACEMARKET×Lancers】シェアリングエコノミーを支えるインフラ/SREでのスライドとなります。
このドキュメントは、PagerDutyにおけるインシデント対応プロセスが載っています。 重大インシデントや、新しくオンコールを始める社員の準備に利用している、PagerDutyの内部ドキュメントの一部を切り出したものです。 このドキュメントではインシデントに備えることだけではなく、インシデント発生中、また収束後の対応についても説明します。 オンコールを担当する人や、インシデント対応プロセスに関与する人（またきちんとしたインシデント対応プロセスを制定したい人）が読むことを想定しています。 このドキュメントが何なのか、なぜ存在するかは、「このドキュメントについて」を参照してください。 どこから手を付けるべきか？ もしあなたがインシデント対応が初めてで、組織的な手順がない場合は、まず「はじめに」で何ができるかを確認してください。 そして詳細な手順を、Training Courseから確認すること
SRE 統制チームの oracle です。 この記事は freee 基盤チームアドベントカレンダー の12日目になります。 今回は AWS の 組織移行を行った話をさせて頂きます。 AWS の 組織移行というのはどういうこと？と思われる方もいらっしゃるかと思いますので、正しく説明しますと、 既存の複数の AWS アカウントを構成している AWS Organizations を解体し、新規に作成した AWS Organizations にすべてのアカウントを移動させました。 となります。 その動機とアプローチについてご紹介したいと思います。 背景 AWS 組織移行する前から、freee では 数十の AWS アカウントを運用していました。運用の仕方は組織によって様々ですが、一般的にはプロダクトで分けたり、環境で分けたりすることが多いかと思います。 freee でも同様の手法でアカウントを分け
本記事は、TechFeed Experts Night#17 〜 事例で学ぶSRE 〜 ツール、プラクティスから組織づくりまでのセッション書き起こし記事になります。 イベントページのタイムテーブルから、その他のセッションに関する記事もお読み頂けますので、一度アクセスしてみてください。 本セッションの登壇者 セッション動画 面白法人カヤックでSREをしています、藤原俊一郎(Twitter: @fujiwara)です。個人的な活動として、ecspresso(Amazon ECSのデプロイツール)やlambroll(AWS Lambdaのデプロイツール)を作ったり、先ほどのセッションで登壇された馬場さんと共著で達人が教えるWebパフォーマンスチューニング(通称「ISUCON本」)を出版したりしています。 SRE不在のチームに加わった背景 SREが不在だったチームの例として、弊社のSMOUTという
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Backlog開発チーム自身によるオンコール対応を支えるアラート通知システム | Backlogブログ
ZOZO プラットフォームSREとコロナ禍におけるチームリーディング術
データ基盤の品質向上への取り組み - Classi開発者ブログ
SREに触れて「いろいろやろうぜ」のモードになった - 生涯未熟
コンテナイメージのバージョン管理を自動化したい！ - Uzabase for Engineers
DMMプラットフォームに ゼロベースでSLO導入している取り組み 適切なSLI模索の軌跡
権限をQray -SREへの一時的な本番環境権限付与のしくみ- | メルカリエンジニアリング
SREに興味のある方向け、SRE Weekly #280が公開 - 「堅牢性の原則がもたらす弊害」など
Performance as a Product Feature
あのサービスの監視・オブザーバビリティ アーキテクチャ選定【前編】 - Findy Tools
40,000コンテナのPrivate PaaSを実現するために必要だったこと
カスタマイズで広がるAWS Copilotの実践力 - KAYAC engineers' blog
SRE NEXTで「AIOps研究録」講演を終えて - ゆううきブログ
「機能開発優先で技術負債解消が進まない」を変えるために 横断的に動き、採用広報活動も進めるカオナビのCTO室
特別コラボ企画の爆発的アクセスを捌き切るエンジニアリングと腕力 - pixiv inside
TetragonでeBPFとセキュリティオブサーバビリティ入門 | フューチャー技術ブログ
K8sとTraefikでつくるマイクロフロントエンド
現代は開発抽象化レイヤーが重層化している、あるいは何を見ても開発抽象化レイヤーに見える
意義から考えるObservability入門 #srenext
delyにおける安定性とアジリティ両立に向けたアプローチ / SRE NEXT 2020
MENTAをAWSに移行して振り返る(ECS/Fargate + Laravel編)
PagerDuty Incident Response Documentation
AWS の組織移行をしました - freee Developers Hub
SRE不在のチームに入って2カ月でやったこと - 負荷試験から始めるプラクティスの導入