Performance as a Product Feature
Kaigi on Rails 2021の発表 https://kaigionrails.org/2021/talks/lchin/ "Performance is a feature"と言われています。 スピードは機能だとしたら、それはプロダクトの様々な機能の一つに数えるということになる。その機能のオーナーとして、どのように事業にとって価値のある投資にできるのか？ このトークでは、パフォーマンスをプロダクト開発として捉えて改善に取り組むアプローチについて紹介します。
Kaigi on Rails 2021の発表 https://kaigionrails.org/2021/talks/lchin/ "Performance is a feature"と言われています。 スピードは機能だとしたら、それはプロダクトの様々な機能の一つに数えるということになる。その機能のオーナーとして、どのように事業にとって価値のある投資にできるのか？ このトークでは、パフォーマンスをプロダクト開発として捉えて改善に取り組むアプローチについて紹介します。
ヤフー株式会社は、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
「ユーザー検知で障害に気づいたら、SREとして負け」元AWSエンジニアが感じたイオンネクストが目指すレベルの高さ｜エンジニアインタビュー ｜AEON TECH HUB
イオンスマートネクスト SREチームの荒井のインタビューです。AWSやフリーランスなどを経て、組織改善に貢献したいという想いで2023年にイオンへ入社。信頼性に関わることは何でもやるSREチームにて求められる役割やレベルに応えるべく、荒井が取り組むチームの土台作りやチームの理想について語ってくれました。
みんなでつくる 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
Goを改善するためのGo Telemetry
はじめに こんにちは！Google CloudでオブザーバビリティやSRE関連の担当をしているエンジニアです。この記事はGoアドベントカレンダーの22日目の記事です。 Goとオブザーバビリティ 私は業務でオブザーバビリティを中心として啓蒙活動や開発を行っているわけですが、その中で常に「改善にはまず計測が必要です」というメッセージをさまざまな方々にお伝えしています。 Goでは計測のための仕組みとして（ testing.B あるいは go test -bench として知られる）ベンチマーク[1]や pprof が最初期から[2]用意されていて、パフォーマンス計測はかなり標準が充実した言語になっています。 そして近年もそれに満足せず、Goを改善するための計測の仕組みがいくつも提案されています。 たとえばruntime/metricsはdesign #37112で提案されてGo 1.16から導入
SRE 統制チームの oracle です。 この記事は freee 基盤チームアドベントカレンダー の12日目になります。 今回は AWS の 組織移行を行った話をさせて頂きます。 AWS の 組織移行というのはどういうこと？と思われる方もいらっしゃるかと思いますので、正しく説明しますと、 既存の複数の AWS アカウントを構成している AWS Organizations を解体し、新規に作成した AWS Organizations にすべてのアカウントを移動させました。 となります。 その動機とアプローチについてご紹介したいと思います。 背景 AWS 組織移行する前から、freee では 数十の AWS アカウントを運用していました。運用の仕方は組織によって様々ですが、一般的にはプロダクトで分けたり、環境で分けたりすることが多いかと思います。 freee でも同様の手法でアカウントを分け
SRE NEXT 2024（のアンドパッドブース）に参加したエンジニアがいまオススメするソフトウェアやサービスとは？ - ANDPAD Tech Blog
こんにちは。SREチームの吉澤です。 アンドパッドは、8/3(土)〜4(日)に開催されたSRE NEXT 2024にゴールドスポンサーとして協賛し、企業ブースとスポンサーLTに参加させていただきました！ スポンサーLTでは、SREチームリーダーの角井さんが「アンドパッドのマルチプロダクト戦略を支えるSRE」というタイトルで発表しました。このLTについては、昨日公開された1本目のイベントレポートをぜひご覧ください。 tech.andpad.co.jp 2本目のイベントレポート（この記事）では、アンドパッドブースの様子と、来場者アンケートの集計結果をご紹介します。アンドパッドブースの来場者という範囲に限定されてしまいますが、SRE NEXT 2024に参加したエンジニアがいまオススメするソフトウェアやサービスの傾向が、集計結果から見えてきました。 アンドパッドブースの様子 アンケート項目 アン
2022年4月新設されたカオナビのCTO室について座談会形式で話す「kaonavi Tech Talk #8 ～部門横断で技術的課題に向き合う！CTO室メンバー座談会～」。ここでCTOの松下氏が登壇。座談会前の発表として、カオナビのCTO室について紹介します。 松下氏の自己紹介 松下雅和氏：カオナビでCTOをしている松下と申します。よろしくお願いします。本日は「部門横断で技術的課題に向き合う！CTO室メンバー座談会」という内容でお送りしたいと思います。 （スライドを示して）まず簡単に自己紹介させてください。私、松下雅和は、@matsukazという（IDで）Twitterなどのアカウントをやっているので、よければフォローなどお願いします。AWS、Node.jsといった技術がけっこう好きです。あと、娘が2人いる2児の父ということで、日々子育てでけっこう苦労して、バタバタしながら仕事をしています
SREは何を目指すのか
デザインシステムとコンポーネント指向によるフロントエンド開発プロセスの革新 / Innovation in Frontend Development Processes through Design Systems and Component-Oriented Architecture
2024年8月3日より開催された「SRE NEXT 2024 IN TOKYO」の登壇資料です。 https://sre-next.dev/2024/ ▼関連資料 ユーザー数100万人規模の事業成長を止めずに、レガシーコードと戦う https://speakerdeck.com/vi…
こんにちは。ピクシブの社内エンジニア職横断組織「エンジニアギルド」マネージャの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
「開発抽象化レイヤー」とは 「開発抽象化レイヤー」(Development Abstraction Layer)はご存知でしょうか。 これはJoel Spolskyが言い出した言葉で、彼の2006年のエッセイのタイトルにもなっています。このエッセイは大変おもしろいので必読です。ご存じなかった方はいますぐ読むことをおすすめします。 日本語訳もInternet Archiveから読めます。 ちなみに組込み方面では「HAL」という用語があります。これは「Hardware Abstraction Layer」の略です。HALはハードウェアの違いを吸収することで、プログラマにはハードウェアを意識させないよう「抽象化」するためのものです（が、実際には「抽象化の漏れ」が生じやすくて微妙な話が展開されるようなのですが、それはまた別の話になります）。 この「開発抽象化レイヤー」も、実際にはプログラマーが活動
CloudNative Days Tokyo 2020 #CNDT2020_A
SRE NEXT 2022で「プロダクション環境の信頼性を損ねず観測する技術」というお話をしました - ださろぐ@はてな
登壇＆参加エントリです。 ややエモよりになる予定。 当日の体験については他の登壇者の皆様とも少しお話したんですが、完全に馬場さんのエントリに書かれている点と同じ感想であり（事前収録は当日落ち着けてよい、参加者としてのZoom Event体験はかなり良かった、ブースの仕様はやや残念ではあったが個人的にはそれでも楽しめた）、まあ同じことを書いてもということで発表まわりや個別の参加体験の方を書いていきます。 登壇について プロダクション環境の信頼性を損ねず観測する技術というタイトルで登壇させて頂きました。 6/9時点でまだスライドのみですが、ぼちぼちアーカイブの方も上がってくるかなと思います。 www.youtube.com 前回2020の登壇から2年、SRE NEXTが開催されたら何はともあれproposalは出したいと考えていたので募集の段階でネタを考えました。 ネタは2本考え、1つは長期運
Forkwell が主催する技術イベント「Infra Study」。今回のテーマは「インフラの面白い技術とこれから」です。（開催日：2020年 7月29日）。本記事は登壇者の近藤さんの基調講演から mruby や C言語を使い、コンテナを自作している様子をお伝えします。最後には、登壇者の近藤さんとまつもとりーさんが視聴者からの質問に回答しているので、ぜひご覧ください。 この回ではインフラで一番面白い世界について考えていきます。 皆さん、子どもの頃、中身が気になって時計を分解するようなことがありましたか？ 私はありませんでした。 にも関わらず今私が一番面白いと考えている世界はインフラの「中身」です。インフラエンジニアは、ともすれば与えられたOS、ミドルウェア、 マネージドサービスを上手に組み合わせることを求められますし、実際それらの要素を適材適所位配置できることは良いインフラエンジニア、アー
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から確認すること
本記事は、TechFeed Experts Night#17 〜 事例で学ぶSRE 〜 ツール、プラクティスから組織づくりまでのセッション書き起こし記事になります。 イベントページのタイムテーブルから、その他のセッションに関する記事もお読み頂けますので、一度アクセスしてみてください。 本セッションの登壇者 セッション動画 面白法人カヤックでSREをしています、藤原俊一郎(Twitter: @fujiwara)です。個人的な活動として、ecspresso(Amazon ECSのデプロイツール)やlambroll(AWS Lambdaのデプロイツール)を作ったり、先ほどのセッションで登壇された馬場さんと共著で達人が教えるWebパフォーマンスチューニング(通称「ISUCON本」)を出版したりしています。 SRE不在のチームに加わった背景 SREが不在だったチームの例として、弊社のSMOUTという
はじめにプレイヤーの皆様にはご不便をおかけしており大変申し訳ございません。 皆様からお問い合わせを頂いております、現在起こっている複数の不具合に関しましての原因説明とこれまで実施した対処法に関しまして、そして今後どのように進めていくかの解決計画に関しましてご説明をさせていただきます。 一部キャラクターの巻き戻り不具合の対応に関して サーバーの停止は単体での問題により発生しているものではないため、都度不具合が発生した際、緩和策の調査及び長期的な構造の組み換えの両面での問題解決に取り組んでいるのが現状でございます。一部のキャラクターに関しましてデータの巻き戻りが起こる現象が発生しておりましたが、今後はサーバークラッシュにより巻き戻りが起こってしまった場合、巻き戻りは数分程度分にとどまる予定でございます。 ただこちらは根本的な解決策になっていないこと、開発チームの方でも重々理解しておりますので引
SRE-NEXT 2020 C2
Identity-based access Boundary provides access to applications and critical systems with fine-grained authorizations without managing credentials or exposing your network. Authenticate and authorizeAuthenticate with any trusted identity provider you are already using and authorize access based on granular, logical roles and services. ConnectManage dynamic infrastructure and integrate service regis
SREチームで社内GameDayを実施しました
GameDayとは 起源はAWSが毎年行っているAWS re:inventの中で開催される行事の1つです。 チームを組んでクラウド・アプリケーションを襲う謎の障害や悪意のある攻撃に対処し、トラブルシューティング能力を競うコンテストとなっています。 のちに様々な企業が社内でも実施するようになり、今ではAWS Well-Architectedのセキュリティ項目でもその実施が推奨されています。 ゲームデーを実施する ゲームデーを実施する: さまざまな脅威について、インシデント対応イベントのシミュレーション (ゲームデー) を実施します。このゲームデーには、主要なスタッフや管理者を参加させてください。 教訓から学ぶ: ゲームデーの実行から得られた教訓は、プロセスを改善するためのフィードバックに含まれている必要があります。 GameDayの手順 今回社内で行なったGameDayの流れです。 1. 発
新米SREとしての半年を振り返る
2020年12月22日以前の記事にあるように、かれこれ8年くらいやっていたiOS開発を一旦離れてフルタイムのSREに転向するという決断をした。それから約半年が経ったので、ここまでどのようなことをやったか振り返ってみる。まだまだ経験の浅い分野なので語彙に厳密性が欠けているかもしれない。 やったことKubernetesやはりこれを触ることが一番多い。弊社ではマルチテナントのクラスタが5つあり、うち2つがDCで、3つがAWS上で動いている。アプリケーション開発者やCI/CDパイプラインはGoで書かれた内製のコマンドラインツールを通じてクラスタとインタラクトする。つまり、開発者向けに新機能のサポートする度に、このツールのインターフェースを拡張することになる。 StatefulSets/Cephそうした中でもステートフルなアプリケーションのサポートが一番目立った変更だった。マネージドのサービスをほと
サービスの一般公開前からSLI/SLOと向き合う - Hatena Developer Blog
Mackerel チームで SRE を担当している id:taxintt と申します。 はてなの SRE が毎月交代でブログ記事を書く Hatena Developer Blog の SRE 連載、3月分は私が担当します。2月の記事は id:masayosu さんの はてなにおけるEKSの運用と自動化 (2024年版) でした。 私が所属する Mackerel 開発チームでは、SaaS 型サーバー監視サービスである Mackerel を開発しています。 Mackerel は、テレメトリデータの計装・収集の標準化を目的としたプロジェクトである OpenTelemetry 対応のための開発を進めています。この記事では、OpenTelemetry のメトリックを扱うサブシステムの開発における SLI/SLO の決定・運用についてお話しします。 mackerel.io OpenTelemetry
この記事は、CyberAgent Group SRE Advent Calendar 2023の7日目の記事です。 4年ぶりに、AWS re:Inventに現地参加していたのですが、今年のWerner先生のKeynote（特に前半）がとてもよく、SREを推進する上でも非常に大事なことをお話しされていたので、それについてまとめてみました AWS re:Invent 2023 - Keynote with Dr. Werner Vogels ざっくりどんな事を話していたか クラウド移行によって、様々な制約からは解放されたが、コストを考えてアーキテクトする必要はある そしてコストを考えるということは、サステナビリティを考えることでもある といった感じで、コストとサステナビリティについての話から、WenerがAmazon CTOとして、過去20年間のアーキテクトする上でのコストと持続可能性の考え方
2022: freee SRE Journey - これまでの振り返りとこれから - freee Developers Hub
忙しい方向けサマリ EKS化・IaCの浸透・DB改善活動が、ここ数年のfreeeのインフラ事情の主だった動きです。 一方で組織・サービスも増えてきており、従来のワンチームSREでは色々と厳しくなってきました。 基盤も進化し、課題も変化した。それに伴い、SREの組織構造を、チームトポロジ的に再編しました。 本文 こんにちは、freeeでSREのマネージャをやっている河村です。 freeeは会計年度の開始月が7月となっており一つの節目となっています。加えて今年はfreee創業10周年ということで、一つのマイルストーンとして、freeeのSREの現状と、それを受けた今後の展望について整理してみました。 この数年の中で、EKS化やAurora化といった基盤の刷新が進む一方、プロダクト・組織規模拡大に伴う従来型SREチームのスケール限界が顕在化してきています。それに対し、新しい基盤に合わせた仕組みの
この記事では、2024年8月3-4日に開催されたSRE NEXT 2024 IN TOKYOでの自分の講演概要とパネルディスカッションに加えて、セッションでは語りきれなかった話と、登壇を終えての後記、最後にSRE NEXT全体の感想を記します。 SRE NEXT 2024では、公募セッション「工学としてのSRE再訪」と題して講演しました。それだけでなく、2日目のパネルディスカッション「SREの技術トレンド2024」にもお声がけいただき登壇しました。SRE NEXTの初回の基調講演から数えて4回目の登壇で皆勤賞を達成しました。 「工学としてのSRE再訪」 （表紙スライドの背景画像は京都のあるコーヒーショップのエスプレッソマシンを撮ったものです。コーヒーは技芸と工学の両者の側面があるため、適任かと思って選びました。） SRE NEXT 2020の基調講演は、ちょうど博士課程の入学試験を控えてい
メルカリSRE発足から7年、グループ会社が増えるなかでの変化と「今」を担当メンバーに直撃 | mercan (メルカン)
ソフトウェアエンジニア。2005年に株式会社ヌーラボに入社し、プロジェクト管理ツール Backlogの初期から開発や運用に携わる。2015年からは同社ニューヨーク拠点のエンジニアリングチーム立ち上げや US 向けのプロダクト拡大のための開発を担当。2018年にメルカリへ入社し、Microservices Platformチームにて、メルカリ・メルペイの開発。現在はソウゾウEnablingチームに所属。 メルカリの事業・組織の歩みとともに変化してきたSRE @keigow：メルカリグループにはそれぞれSREチームがあり、共通する業務も多いので連携して動くこともよくあります。だからこそ、各プロダクトでSREがどういった役割・体制なのかを知りたいです！まず、メルカリはどうですか？ @deeeet：メルカリにはSRE的なチームが大きく分けて3つあります。それがPlatformグループ、Micros
（上記ブログ執筆時は、EKS on EC2 へ移行予定でしたが、EKS on Fargate への移行を行う方針に切り替えました。） Kubernetes 移行に関連する技術面の話題についてはご紹介してきた一方で、これまでの記事では、 「なぜ Kubernetes 移行を行っているか？」「スタディスト開発部は、最終的に何を目指しているのか？」といった背景には触れておりませんでした。そこで本記事では、スタディスト開発部が目指す世界観と、その過程として歩んでいる Kubernetes 移行の位置づけについてご紹介します。 目次Teachme Biz における Infra の現在と抱えている課題スタディスト開発部が目指す世界観Kubernetes 移行の位置づけ今後のやりたいことTeachme Biz における Infra の現在と抱えている課題現在 Teachme Biz の大部分（以降、本記
How Google SRE and Developers Collaborate - IT Revolution
July 12, 2022 How Google SRE and Developers Collaborate This post was adapted from the paper “How Google SRE and Developers Collaborate by Christof Leng, Tracy Ferrell, Alex Bligh, Michal Gefen, Betsy Beyer with help from Salim Virji from the Spring 2022 DevOps Enterprise Journal. Google’s Site Reliability Engineering (SRE) team is a specialist engineering organization focused on designing, buildi
プロダクトエンジニアリング部の吉田と申します。 普段はRubyやTypeScriptといった言語を使ったサーバサイドエンジニアをしています。 今回、サイトの閲覧障害をきっかけに行ったポストモーテム会が個人的にとても有意義だと感じたので紹介させてください。 障害分析レポートの紹介 弊社では障害が起きた場合、障害分析レポートを書くという決まりがあります。 この障害分析レポートというものは、一般的にはSREの用語でポストモーテムとして知られている障害対応時のことを記録する文書のことです。 弊社では品質管理を行っている部署がテンプレートやフォーマットを整えてくれており、内容としてはオライリーのSRE本の付録Dに記載してある「ポストモーテムの例」にかなり似通った内容です。 かいつまんで紹介すると下記のような内容を記載するものです。 障害の概要 影響範囲 タイムライン 水面下で起きていた問題（根本の問
エムスリーエンジニアリンググループSREチームの山本です。 私はエムスリーに入社してまだ1年少しなのですが、前職でも似たような職務を担当していました。 その中で、実は「インフラのあり方」には二大潮流が存在し、その中で皆が苦しみもがいているのではないだろうか？と感じました。前職や現職で感じたアレコレをエッセーのように軽い読み物にしますので、SREブログリレー二日目のネタとして書かせてください なお、文字だけでは書きたいことが足りぬため、私が直々に画伯として挿絵も描いてしまいます。 ちなみに「麻雀に例えたら」と書きましたが、実は私は麻雀のルールをほとんどしりません。某有名麻雀劇画の作者はルールを知らないのに勢いで麻雀を描いたようですし、私もそれでいきたいと思います。 ロン！クラウド無双！！ 二種の潮流 哭きのSRE メンチン型SRE どちらが正しいのか？ SREとしての立場と技術選定 「シクヨ
実例で学ぶモニタリング定例のすゝめ | CyberAgent Developers Blog
この記事はCyberAgent Developers Advent Calendar 2021 11日目の記事です。 みゆっきこと山中勇成(@toriimiyukki)です。普段は、ABEMAで動画配信基盤の開発運用を担当しています。 直近では、配信システムの大規模刷新プロジェクトなどを担当しており、こちらの模様はCA BASE NEXTの発表からアーカイブを閲覧可能です。 ABEMAでは、24時間365日のリニア型配信やVOD配信など、昼夜を問わず落とすことができないミッションクリティカルなサービスを運用しています。サービスを支えるマイクロサービスは、配信分野に限っても20サービスを超えています。 既にPrometheusなど、各種モニタリングソリューションでの監視やアラーティングなども行っていますが、この記事では、あえて手動監視を定期的に行う、モニタリング定例を勧めたいと思います。 な
こんにちは、エムスリー エンジニアリンググループ / 製薬企業向けプラットフォームチームの鳥山 (@to_lz1)です。 この記事はエムスリーSREがお届けするブログリレーの8日目です。 このブログリレーで複数回言及されているように、エムスリーでは昨年から大々的に「チームSRE」という制度を導入しています。従来からのSREすなわち「コアSRE」が受け持っていた業務や権限を、各プロダクトチーム内のSREすなわち「チームSRE」に委譲している真っ最中です。 私の所属する製薬企業向けプラットフォームチーム（Unit1と呼ばれています）のチームSREの導入タイムラインは、以下のような感じです。 2020年4月に最初のチームSREが入社 2020年7月ごろに私を含む6名がチームSREとして追加 複数サービスのクラウド移行を実施しつつ今に至る したがって、少なくとも私のチームではこの「チームSRE」と
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
40,000コンテナのPrivate PaaSを実現するために必要だったこと
カスタマイズで広がるAWS Copilotの実践力 - KAYAC Engineers' Blog
AWS の組織移行をしました - freee Developers Hub
「機能開発優先で技術負債解消が進まない」を変えるために 横断的に動き、採用広報活動も進めるカオナビのCTO室
プロダクト全体で取り組むSREing イシューから始める信頼性・生産性向上の実践/SRE NEXT 2024
特別コラボ企画の爆発的アクセスを捌き切るエンジニアリングと腕力 - pixiv inside
https://sre.google/static/pdf/jp-enterprise-roadmap-to-sre.pdf
TetragonでeBPFとセキュリティオブサーバビリティ入門 | フューチャー技術ブログ
現代は開発抽象化レイヤーが重層化している、あるいは何を見ても開発抽象化レイヤーに見える
K8sとTraefikでつくるマイクロフロントエンド
ITエンジニア向けのトレンド情報 | Forkwell Press （フォークウェルプレス）
delyにおける安定性とアジリティ両立に向けたアプローチ / SRE NEXT 2020
MENTAをAWSに移行して振り返る(ECS/Fargate + Laravel編)
PagerDuty Incident Response Documentation
SRE不在のチームに入って2カ月でやったこと - 負荷試験から始めるプラクティスの導入
『ディアブロ II リザレクテッド』で起こっている不具合の原因説明/今後の恒久的な解決計画に関しまして
成長を続ける広告配信プラットフォームのモニタリングを改善してきた話
Boundary by HashiCorp
Dr.WernerのKeynoteは全てのSREに聞いてほしい話だった - Qiita
工学としてのSRE再訪 - SRE NEXT 2024登壇後記 - ゆううきブログ
スタディスト開発部が目指す SRE の未来と現状と Kubernetes
ポストモーテム会を行って障害対応の改善を図った話 - LIFULL Creators Blog
SREを麻雀に例えたら(哭き派とメンチン派の争い) - エムスリーテックブログ
チームSRE立ち上げ期にやってみて良かったこと - エムスリーテックブログ