塹壕よりDevOpsとSRE / DevOps and SRE from the Trenches
2019-01-29 TECHPLAY https://techplay.jp/event/765163 see also : https://dev.classmethod.jp/devops/mydevops192/
2019-01-29 TECHPLAY https://techplay.jp/event/765163 see also : https://dev.classmethod.jp/devops/mydevops192/
31記事で4500以上はてなブックマークがついた2022年のMonotaRO Tech Blogを振り返ってみた - MonotaRO Tech Blog
データ基盤グループ兼TechBlog編集担当の吉本です。 MonotaROでは2021年よりTechBlogでのアウトプットを積極的に行っており、今年が3年目になります。 そこで本記事では昨年に投稿したブログの振り返りと、特に読まれた記事について振り返ります！ ブログ振り返り 特に読まれた記事 SRE導入: システムを安定させる4000万円の魔法の壺 全社員からデータ基盤への問い合わせが殺到して2人では捌けなくなったので仕組みで解決する話〜datatech-jp Casual Talks #2 登壇後記〜 一般企業であまり前例がない「認証VLAN」を導入した、その後の学び 66分かかる同期処理を10分以内に短縮せよ！～商品情報同期システムでの、処理速度と運用の改善～ 【Elasticsearch】1900万点に及ぶ商品データ作成の時間を約67%短縮できた構成と工夫 最後に ブログ振り返り
バクラク事業部 Platform Engineering 部の uehara です。2023年4月に入社しました！ この記事では、直近で取り組んだ Datadog のコスト最適化の取り組みを紹介します。 概要 大きく2つの施策によって、Datadog の月額料金を 30% ほど削減しました。 毎月の利用量を事前コミットすることで単価を下げた ログ運用を見直すことでコストを約半分にした 利用量の事前コミット Datadog の一部機能では利用量を事前コミットすることで単価を下げることができ、価格表も公開されています。BILLED ANNUALLY が年契約、BILLED MONTH-TO-MONTH が月契約の単価です。 www.datadoghq.com オンデマンド料金と比較すると2割から3割ほど安くなっていることが分かります。 直近の利用実績から毎月必ず利用する分を算出し、MONTH-
Self-Hosted Cluster から EKS への移行と Platform の Production Readiness - スタディサプリ Product Team Blog
こんにちは。SRE の @chaspy です。 Quipper では AWS 上で Kubernetes Cluster を運用してサービスを提供しています。 これまで kube-aws を用いて Kubernetes Cluster を Self Host してきましたが、このたび Managed Services である Amazon EKS に移行しました。（以下、 Amazon EKS を EKS と表記します） 本記事では、 Kubernetes Cluster の移行で遭遇した問題をどのように解決したかを説明します。また、数多くの Application が稼働している Platform を移行する際にどのような点を考慮するとよいのか、経験を通して学んだことを共有します。 EKS への移行を検討している方はもちろん、Platform Migration に携わる方にとって学びに
昨日、「プラットフォームエンジニアリングがわからない」という記事を読みました。 私は最近、Platform Engineering Meetupにオンライン参加して話を聞いたり、CNCFの『Platforms White Paper』を読んで、その所感をZennのエントリーにしたり、所属する会社の勉強会でPlatform Engineeringについて同僚とディスカッションしたりする中で、「Platform Engineeringってこういうものなのかな？」というのが最初の頃よりは明確になってきました。 そこで、上記の記事を読んだ上で、私の理解に基づく意見をこのエントリーに書きます。なお、私はPlatform Engineeringをメインにやっている人ではないので、理解が行き届いていない部分や誤解も多々あると思います。一方で、この話題に利害関係がほとんどない点はバイアス排除の面で有利だと
ノートラブルシステムへの道
ノートラブルシステムへの道 ビジネス速度を落とさないために
KubeFest Tokyo 2020 は Kubernetes を利用している人、これから導入したい人が学ぶオンラインイベントです。サイバーエージェントのSREである石田氏が、Kubernetesと既存のシステムとの並行運用方法、直面した問題とその解決方法を共有しました。関連資料はこちら。 稼働しているサービスの紹介 石田：実際に作成した構築物の紹介をします。Kubernetesクラスタは以下のルールに則って構築しました。クラスタはdevelop環境、staging環境、production環境で分割し、既存のセキュリティグループベースのアクセス制限でも対応できるようにしました。 ワーカーノードへのSSHは通常利用の範囲では不必要なので原則不要とし、ワーカーノードのkubeletやDocker Engine、その他ミドルウェア起因の障害も障害と考えられる場合のみ、セッションマネージャー経
続・何でも屋になっている SRE 的なチームから責務を分離するまでの道のり 〜新設チームでオンコール体制を構築するまで〜 - Repro Tech Blog
こんにちは、Platform Team というチームでマネージャーをしている荒引 (@a_bicky) です。 Platform Team は、データエンジニア・アーキテクト的な役割を担う Repro Core Unit と、インフラエンジニア・SRE 的な役割を担う Sys-Infra Unit から成るチームです。 先月 SRE Lounge #15 で「何でも屋になっている SRE 的なチームから責務を分離するまでの道のり 〜新設チームでオンコール体制を構築するまで〜」と題して次の発表をしたんですが、時間の都合上話せなかった内容があるので、それらについて触れたいと思います。 なお、当日の発表内容は動画でも視聴可能です。 アジェンダ 本エントリーのアジェンダは次のとおりです。 SRE Lounge #15 での発表内容の要約 Repro Core と Sys-Infra の棲み分け R
こんにちは。データ・AI戦略部 SREチームの小野です。2020年8月に入社してから早3年。SREエンジニアとして、日々業務改善に励んでいます。 ここ一年ほど、SRE業務の一環で組織作りに挑戦しています。SREエンジニアの責務は自社サービスを安定稼働させ障害に強い基盤を作ることであり、どちらかというと「システム」に焦点が置かれがちです。しかし、個人的にはシステムを運用するメンバーのマネジメント(ピープルマネジメント)を含めた組織作りも重要だと考えています。なぜなら、どれだけ最先端で素晴らしいシステムを構築してもそれを運用するメンバーの行動次第では、障害につながる恐れがあるためです。 私にとってのSREは組織作りにおける文化のようなものであり、「SRE(文化)を組織にインストールする」気概で色々と挑戦しています。 今回は、その挑戦の一つとして「ヘルプデスク体制を構築した話」をお伝えしたいと思
こんにちは。SRE の @chaspy です。 ユーザに価値が提供できなくなってしまうシステム障害は起きてほしくはありませんが、絶対に発生しないとは言い切れません。 そんなシステム障害は、そもそも発生頻度が不定、かつ多くないので、どのように対応すべきかを体系化することは（起きる事象が毎回異なることも相まって）難しいと思います。 本記事では、Quipper において、どのように障害対応を行うのか、また、障害発生時の考え方を紹介します。 障害はどのように対処されていくのか 障害発生フロー Quipper では 標準化された障害時連絡のフロー / 障害レベルがあります。 これによって、障害の内容、影響範囲によっては親会社のリクルートマーケティングパートナーズへのエスカレーションが必要であることと、その基準が言語化されました。また、エスカレーション時に送るメールのテンプレートも用意されており、「誰
SREsのためのSRE定着ガイド
#SHIFT_SRE No SRE，No life｜教科書には載っていない！俺たちが考えたSRE推進の道しるべ｜ #SHIFT TECH TALKS#1 登壇資料
分散トレーシングとOpenTelemetryのススメ / Getting started distributed tracing and OpenTelemetry
OCHaCafe Season7 の LT 資料です。 https://ochacafe.connpass.com/event/282817/
こんにちは、株式会社スマートラウンドSREの@shonansurvivorsです。 私は今年5月に1人目のSREとしてこの会社に入社し、既に半年以上が経過しました。 2022年も終わりが近づいて来た中、この場を借りて、スタートアップの1人目SREとして、今年やってきたことを記録として残したいと思います。 なお、本記事で取り扱う内容はSREの理論や原理原則に沿って各種プラクティスを実践したこと、というよりは、セキュリティ、モニタリング、IaC、コスト、パフォーマンス、運用、開発効率などなど、いまこの組織で取り組むことでプロダクトと事業に貢献できるのではないか？と私なりに判断してきたこととなります。 そのため、Site Reliability Engineeringに関して学びのある記事にはなっていないと思いますし、また概ね時系列順に近い形で実施事項を羅列していきますので(述べ方が長たらしいと
我々はこうしてSLI/SLOを設計し 運用を始めました -これからSLI/SLOの運用を始める人に向けて-
SRE大集合！みんなで学ぶ、信頼性を高めるための取り組みLT大会の登壇資料です。 概要 つい先日SLI/SLOの設計が終わりSLOの運用をスタートしましたがそれまでの道のりは楽ではありませんでした。 本LTではCUJの決め方からSLI/SLOの設計と運用を固めるにあたっての進め方についてお話させて頂きます。 以下の聴講者を想定しています。 SLI/SLOをこれからやっていこうと思っている人 運用開始しているけど他社の事例が気になる人
IaC、あるいはインフラ抽象化レイヤー導入時に考えたらいいんじゃないかと思うことを雑多に書く - ださろぐ@はてな
この記事はSRE Advent Calendar 2023の4日目の記事です。 qiita.com 3日目は@myu_mxさんのゆるやか成長スタートアップの小さなEnabling SRE的活動でした。 久々のアドカレ参加ですが、少し思いの丈に任せてみようということで経験と主観が強めの記事です。 この辺で語られていたよとかこれは賛同できないというポイントなどもっといい情報があればぜひお知らせください、という感じで雑多に書いて参ります。 TerraformやCloudformationあたりをよく触るのでそのあたりがどうしても頭にありますがなるべく固有の話はしない方向で。 色々書きつつ、基本的には長期的な運用を見越したソフトウェアの運用設計と同じ考えで良いとは思ってます。 最低限のインターフェースを公開し疎結合に設計する、モジュールは交換可能する、ライフサクルを考える、などなど。 ただIaCコ
SREへの社内留学を通してEnabling SREを推進した話 - freee Developers Hub
こんにちは、金融開発チームでアプリケーションエンジニアをしている ogugu です。 普段はサーバーサイド・フロントエンド問わず実装しています。 直近では、半分趣味でGoのlinterを自作したり、フロントエンドにStorybookのインタラクションテストを導入したり、幅広くやっています。 さて、今回は、SREチームに社内留学して Enabling SRE を推進した話をします。 なぜ留学したか 自分はこれまで「技術をリードしていく立場として幅広い知識と経験を持った人材になりたい」というキャリア志向を抱いていました。 そのために、自分自身がウィークポイントに感じていたインフラやセキュリティの理解を深めたいと感じていました。 また、同時に、freeeの開発組織に対して「悪い意味で開発者とSREの責任境界がはっきりしていて、開発者がインフラの構築・運用やアラート対応に疎くなっているのでは」とい
SLO サービスレベル目標
サービスレベル目標（SLO）とは、ユーザーの満足度に強い相関があるメトリクスを用いた、開発と運用の目安となるものです。SLOに基づいた運用は、ユーザー視点で高い信頼性を持つサービスを提供する上で最も重要なプラクティスであるとともに、ビジネス指標に紐づく運用方法でもあります。本書は、SLOを導入する際に必要となる基礎概念、実装、文化を解説します。 はじめに、SLOの概要、サービスレベル指標（SLI）の設定、エラーバジェットの使い方などSLOの基本について説明します。そしてSLIとSLOの計測、確率と統計を使ったSLOの活用法、SLOを組み込むアーキテクチャやシステムについて解説します。さらに、組織内での同意の獲得やSLOの提唱など、SLOに基づくアプローチをチームや会社全体に根付かせる効果的な方法を紹介します。 本書への推薦の言葉 序文 監訳者まえがき はじめに 第I部 SLOの開発 1章
SREチーム(新卒)の市川恭佑です。今回は、Tonamelという自社サービス(Web)において負荷試験を導入した事例を紹介します。 このエントリは「先送りされがちな負荷試験の導入について心理的なハードルを下げる」ことを目的としています。 そのため、事例紹介と銘打っていますが、列挙される事実の独立性よりも文脈性を優先しています。 表現が少し冗長に感じるかもしれませんが、負荷試験について距離感を感じている方は是非お付き合いください。 負荷試験を導入するに至った経緯 Tonamelは、本格的なリリースから5年以上という、比較的長い運用歴を持つサービスです。 まず、何故このタイミングで負荷試験を導入することになったのかについて、その経緯を説明します。 ポストモーテムによる気づき（文化的な土台） 今年の3月に公開されたエントリにもあるように、カヤックでは着実にポストモーテム文化が浸透しつつあります。
freee のエンジニアは障害から何を学び、どう改善しているのか？ / What do freee engineers learn and improve from failures? - Speaker Deck
SRE NEXT 2020 の登壇資料です。 https://sre-next.dev/schedule/#a3
SLOいつ決めましょう？
第3木曜LT会というイベントの「SREどうでしょう」という会でSLOはいつ決めたらよいか？自分なりに考えた結果を発表したLT資料 https://metaps.connpass.com/event/313921/
これまでのアプリケーションやシステムのモニタリングは、障害を検知し、なるべく短時間で復旧させてサービスレベルを維持することに重きを置く、いわば守りの運用が中心だった。だが、それで終わらせていいのだろうか。New Relicの大谷和紀氏は、オブザーバビリティ（可観測性）を高めるための成熟モデルを紹介。計測データをとりながらの受動的な対応から、サービスレベルの策定やパフォーマンスの改善、ユーザー体験の向上を目標とした積極的対応、本番環境を使った「避難訓練」で対策度合いを検証する予測的対応、顧客満足がどれほど向上したかCSATスコアなどをベースにデータ分析するデータ駆動へとステップアップしていく方法を丁寧に解説した。 New Relic株式会社 Senior Customer Success Manager 大谷和紀氏 オブザーバビリティを高めるための5つのステップ オブザーバビリティ（可観測性
フロントエンドの組織について考える / think-about-front-end-organization
mabl を融和させるための取り組み in クラウドサイン / how-to-fusion-mabl-in-cloudsign
AWS Startup Tech Meetup Online #3 の登壇資料です。 ※映像はこちら 【p3】CodeZine の記事 https://codezine.jp/article/detail/12714 【p12】SSM セッションマネージャーのデモ https://www.youtube.com/watch?v=cc7jLW0FzzI 【p22】IAM 権限の設定例 https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/getting-started-restrict-access-examples.html 【p22】AWS CLI プラグイン https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/session-
マルチクラスタ戦略を無邪気に採用するとどうなるか 夏のAWS Kubernetes 祭り 発表資料 後半 SRE FY23Q1
マルチクラスタ戦略を無邪気に採用するとどうなるか 夏のAWS Kubernetes 祭り！ - 2022/08/04 2 髙田 颯 Takada Soh freee株式会社 プロダクト基盤本部 SRE Platform team 経歴 2020年5月~ 人事労務freee開発 2021年4月 新卒入社 2021年7月~ SRE お悩み Kubernetesにバグ修正のPRを4月に 送ったものの途中から返信がなく悩み中 マルチクラスタ戦略を 無邪気に採用するとどうなるか 4 （運用が）爆発します。 マルチクラスタ戦略を無邪気に採用するとどうなるか 5 何が爆発したのか freeeのcluster運用の歴史 現在の戦略 マルチクラスタ（シングルテナント） EKS version blue/green upgrade インフラの運用を丸ごと引き受けるSRE 改善の取り組み upgrade方式の整
コンウェイの法則と逆コンウェイの法則から組織構造を考える
この記事は、「コンウェイの法則」とその逆転の発想の「逆コンウェイの法則」について述べていきます。 組織体制とアーキテクチャの相関関係組織体制はアーキテクチャは相関関係があります。わかりやすい例を出すと下図をご覧ください。 よくありがちなモノリシックな構成です。１つのモジュールにたくさんの機能を格納されており、組織体制としては職能型としてバックエンドチームなどが存在していきます。 これをマイクロサービス化したとします。ただ、組織体制はそのままです。このままだとせっかくServiceA,B,Cと責務を分けたのにそれを管轄しているチームは同じになっていました。つまり、マイクロサービス化のメリットが受けられません。 コンウェイの法則こういった現状を的確に表したのが、「コンウェイの法則」です。 コンウェイの法則とはメルヴィン・コンウェイが提唱した概念です。 システム設計(アーキテクチャ)は、組織構造
ミドルウェアアップデートの自動化によってトイルを年間180時間削減しました - Link and Motivation Developers' Blog
こんにちは、リンクアンドモチベーション SREグループの久原です。今回は、SREチーム内の生産性・信頼性向上のために取り組んだミドルウェアアップデートの自動化施策について紹介いたします。 背景 自動化の成果 手順の簡略化 before after 対応時間の削減 やったこと ミドルウェアアップデートの手順 自動化の方針 ①各項目ごとに手動の部分はCodeBuildを使って自動化する before after ②項目間の移行はCodePipelineを使って一気に実施できるようにする 今後の展望 背景 なぜミドルウェアアップデートの自動化に取り組んだのか？それは現在SREチームで注力している 「トイルの削減」に対して大きく貢献するため です。インフラ民主化の記事でも取り上げたように、トイルの対応時間のトップ3を見ると、かなりの割合をミドルウェアアップデートが占めていることが分かります。 トイ
こんにちは。エンジニアの佐々木です。 先日開催したミートアップにて、カヤックの藤原さんを交えてクラシコムのSREについてお話をさせていただき、1つ目のトークテーマ「インフラ強化に向けた具体的な取り組み」について記事を書かせていただきました。 この記事では、２つ目のトークテーマである「一人に頼らないチーム体制づくりを目指して」について紹介します。 SREの必要性SREチームの話をする前に、この後の話がイメージしやすくなるよう、開発組織としては規模が小さいクラシコムにおけるSREの必要性について述べたいと思います（前回のブログに引き続きいきなりイベント当日にお話したことではなくすみません…） まずSREとは何かというのを改めて確認しておくと、SREとはサイト信頼性エンジニアリングの略で、信頼性の高い本番環境システムを実行するための職務、マインドセット、エンジニアリング手法のセットであると発祥元
EKSコンテナ移行のトラブル事例：推測するな計測せよ -CoreDNS暴走編- - MonotaRO Tech Blog
こんにちは、モノタロウの SRE グループ・コンテナ化推進チームの田中です。 現在、私たちはシステムモダナイゼーションのプロジェクトの一環として、200以上のエンドポイントを持つモノリスのバックエンド API を EC2 上から Kubernetes マネージドサービスの EKS（Elastic Kubernetes Service）に移行しています。ノードは Fargate を使用し、監視には Datadog と Sentry を導入しています。 今回、EC2 に流れているリクエストを全て EKS に振り分けを行おうとしておりました。その際に外部（DB、 サービス）への疎通ができないといった内容の Sentry のエラーが大量に発生し、切り戻しをせざるを得ない状況に陥ったのです。エラー内容を詳しくみたところ名前解決に関するものであり、今回私たちは CoreDNS の設定を行うことで解決し
こんにちは。SRE チームの@chaspy です。 本記事では私の所属する SRE チームにおける「ふりかえり」の文化を紹介します。 背景 最近のチームのふりかえり会 *1 で僕自身が以下のようなコメントを"Keep"として出しました。 これは、単にこのふりかえり会が継続している、という意味に留まりません。あらゆる物事に対してふりかえりが行われ、改善サイクルが高速に回っていると感じます。それはチームメンバー全員が以下の価値観で仕事を進められているからだと思います。 あらゆる問題、取り組み、事象について「それは本当に必要か？」「それはなぜやるのか？」といったことを問うことができる。いわゆるクリティカルシンキング。 あらゆる問題に対して、建設的・前向きに、他者や何かを否定することなく、より良い案を言葉にして提案できる。建設的思考。blameless。 やることにコストがかからず、やらない理由が
2023/05/19 「SRE大集合！みんなで学ぶ、信頼性を高めるための取り組みLT大会」発表資料 https://findy.connpass.com/event/281605/
「ZOZO MLOps のチームリーディングとSRE(Engineering)」というタイトルで SRE Next 2020 に登壇しました
1/25(土) に開催された「SRE Next 2020」 という日本では初めて行われる SRE (Site Reliability Engineering) に関するカンファレンスに登壇しました。 2019年4月にチームを新規に発足してから、どのようにチームを率いて成果を上げ、社内の信頼を得てきたのか 、メンバーの成長を促してきたのか、について語りました。 https://docs.google.com/presentation/d/1zEkR9Dm_epg7fxOCFE-asBsUlHDozwObsBEGAILiqic/edit#slide=id.p1 [B6] ZOZO MLOps のチームリーディングとSRE(Engineering) 私は2019年4月にZOZOにMLOpsチームを作り、それから10ヶ月ほどチームをリードしてきました。 その10ヶ月の間にZOZOでは買収も含め色々
EKSコンテナ移行のトラブル事例：ALBの設定とPodのライフサイクル管理 - MonotaRO Tech Blog
こんにちは、SREグループの岡田です。 モノタロウではモノタロウのクラウドネイティブ化の取り組みについて - MonotaRO Tech Blog にも記載されているようにシステムのモダナイズに取り組んでおり、その一環でEKSのPoCそして実際にECサイトの裏側のAPIを対象にコンテナ化に取り組みました。 この記事では移行時に起こったトラブルとハマったポイントの1事例をご紹介します。 前提 起こったトラブル トラブルシュート 1. 問題の整理と仮説 2. 検証 検証1.Podのステータスがterminate状態になってから削除されるまでの時間を変えてみる。 検証2.Pod Readiness Gateを試す。 検証3. ALBのDeregistration delay（登録解除までの待機時間）を短くしてみる。 分かった事 ALBを含めたPod入れ替え時の挙動 EKSにおけるトラブルシュート
「あるサービス用に開発した仕組みを全社共通の仕組みに変える」といったアプローチは決して珍しくない。一から仕組みを構築するよりは、先行事例としてうまくいっているものを流用したり機能拡張させたりする方が失敗は少ないからだ。 ただ、特定の目的に合わせて作った仕組みに汎用（はんよう）性を持たせることは簡単ではない。関係者なら誰でも使えるように環境を整備する必要があるし、運用の方法も全社での利用に合わせて変更しなければならない。 Cloud Operator Days Tokyo 2022のセッション「DMMプラットフォーム ゼロから始めるKubernetes運用 課題と改善」でDMMのpospome（ぽすぽめ）氏（マイクロサービスアーキテクトグループ SRE＜Site Reliability Engineering＞チーム）は、そうした「別の目的で構築された仕組み」の運用を引き継ぐときに起きた課題
SRE / DevOps / Kubernetes Weekly Reportまとめ#13(4/26~5/1) - 運び屋 (A carrier(forwarder) changed his career to an engineer)
この記事は2020/4/26~5/1に発行された下記3つのWeekly Reportを読み、 DEVOPS WEEKLY ISSUE #487 April 26th, 2020 SRE Weekly Issue #216 April 27th, 2020 KubeWeekly #214 May 1st, 2020 English Version of this blow is here. DEVOPS WEEKLY ISSUE #487 April 26th, 2020 News A detailed write up from the recent Failover Conf on all things chaos engineering. Lots of notes and links to related content. A good post for any software d
Mackerel で行った障害対応演習を紹介します - Hatena Developer Blog
こんにちは、Mackerel チーム SRE の id:heleeen です。 この記事は、はてなの SRE が毎月交代で書いている SRE 連載の4月号で、先月分は id:taxintt さんのサービスの一般公開前からSLI/SLOと向き合うです。 今回は、先日 Mackerel チームで行った障害対応演習で実施した内容と、どのような学びを得たかについて紹介します。 本番障害はできればなくしたいものですが、すべての障害を完全になくし可用性を100%にするのはとても困難です。そのため、障害が発生したときの影響範囲を小さくする仕組みを導入したり、ロールバックを素早く行えるようにしておくなど、影響を抑えるための取り組みが必要になります。 Mackerel では、その一環として、障害対応時のオペレーションの確認やバックアップからの復旧が行えるかの検証などの起きてしまった障害を素早く収束させたり、
Blue-Green デプロイメントを採用したデプロイの仕組みを実装して共通基盤として導入した話 / SRE NEXT 2020
Blue-Green デプロイメントを採用したデプロイの仕組みを実装して共通基盤として導入した話 / SRE NEXT 2020
Tech x Marketing meetup #5 サイトリライアビリティエンジニアリング https://techxmarketing.connpass.com/event/189979/
SRE を立ち上げた4ヶ月後の世界
この記事は、Magic Moment Advent Calendar 2023 4 日目の記事です。 こんにちは! Magic Moment で Senior Engineering Manager 兼 SRE Engineering Manager をやっている 木村 (@ryurock) です。 Magic Moment アドベントカレンダー 4 日目では、2023年9月に SRE チーム を立ち上げた 4 ヶ月後の世界。 というテーマでアドカレやっていきたいと思っています。( ｰ`дｰ´)ｷﾘｯ SRE チームの立ち上げの経緯 遡る事、2023年7月頃に弊社が提供しているサービス Magic Moment Playbook のコアデータが立て続けに更新できない障害が相次ぎました。 Sales Operation を行う上で、大切なデータが頻繁に反映されないこの由々しき事態はユーザー様
理想は「SREチームをなくすこと」、一人目SREとしてたどり着いた真理｜イオン・エンジニアインタビュー ｜AEON TECH HUB
イオンスマートテクノロジー・SREチーム齋藤のインタビューです。2022年に1人目のSREエンジニアとして入社し、多くの課題を抱えていた組織を、地道な活動によって少しずつ変えていきました。Jiraの導入、100ページにわたるドキュメント作成、監視・モニタリング基盤の統一…齋藤はどんな想いで改革を進めていたのか、本音を伺いしました。
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Datadog のコスト最適化で月額費用を 30% 削減した - LayerX エンジニアブログ
「Platform Engineeringがわからない」を読んで
どのようなユーザー体験を提供できるか考える サイバーエージェントのSREが行った Kubernetesの問題検証とその解決
SREエンジニアがヘルプデスク体制を作ってみた話 - ぐるなびをちょっと良くするエンジニアブログ
障害対応とポストモーテム - スタディサプリ Product Team Blog
スタートアップの1人目SREが入社後にやってきたこと
運用中のサービスに負荷試験を導入した事例の紹介 - KAYAC engineers' blog
Terraformのレポジトリ、 ディレクトリ構成どうする？/Terraform repository, directory structure What should I do?
アラート対応からデータ駆動の改善まで「攻めのモニタリング」を実現する5つのステップ【デブサミ2020】
AWS Systems Manager で実現する SSH レスでセキュアなクラウド運用
一人に頼らないSREチームの体制づくりを目指して｜Kurashicom Tech Blog
SRE チームを支えるふりかえりの文化 - スタディサプリ Product Team Blog
サイト信頼性を高める前に開発チームからの信頼性を高めよう
目標は「SREが関与しなくても開発者が作業できる世界をつくること」 DMMの挑戦
その広告配信システムは正しく動いているのか？ #TechMar