信頼性の育て方 / mackerel-meetup-15
Mackerel Meetup #15 ( https://mackerelio.connpass.com/event/302254/ ) で「信頼性の育て方」というタイトルで発表させて頂きました
Mackerel Meetup #15 ( https://mackerelio.connpass.com/event/302254/ ) で「信頼性の育て方」というタイトルで発表させて頂きました
2020年2月29日(土)の技術書典8で頒布予定だった「AWSを使って学ぶ 監視設計」になります。 ■サークル「チームになったササキです」 https://techbookfest.org/event/tbf08/circle/5768511573983232 残念ながら技術書典8は中止となってしまいましたが、こちらで販売します。 もう少し詳細な内容について、こちらのブログに記載しています。 お時間あればご確認ください http://tenbo07.hatenablog.com/entry/2020/03/07/004743 ■サンプルコードについて 以下で公開しています https://github.com/tenbo07/monitoring-design-book-samples この本について主に監視の設計手法を紹介する本です。 この本では、「モニタリング(監視)」 というテーマに
はじめに こんにちは、最近の私の人生はキックボクシングとコーディングの2つの活動に極端に偏りつつあります。nwiizoです。一見正反対のようなこの2つの活動ですが、共通する本質があります。それは、頭で考えるだけでなく、実際に体を動かして実践することで新しい発見や気づきを得ていくプロセスです。 キックボクシングでは、理論だけでは表現できない”技”を体で覚えていきます。理論上の動作はスムーズに行えても、実際にパンチやキックを繰り出す際には、さまざまな戦略を一瞬のうちに計算し、機動的に対応しなければなりません。そこでは思考するよりも先に、体が自然と反応するよう繰り返し訓練を重ねていきます。 一方のコーディングにおいても、書籍から得た知識を単に暗記しているだけでは意味がありません。実際にコードを書きながら、試行錯誤を重ね、バグに出くわし、その都度解決策を見出していく中で、本当の理解が深まっていきま
GitHub - dora-team/fourkeys: Platform for monitoring the four key software delivery metrics of software delivery
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
SPI原点回帰論：事業課題とFour Keysの結節点を見出す実践的ソフトウェアプロセス改善 / DevOpsDays Tokyo 2024
Autifyをチームで自律活用するには？ 「Autify community meetup テスト自動化を軌道に乗せるまでの道のり」に登壇しました - Link and Motivation Developers' Blog
はじめに こんにちは リンクアンドモチベーション QAエンジニアの小島です 開発ツールの導入者がチームにツールを浸透するのに苦労する というのはあるある話かと思います なんで必要なの？ どう操作するの？ どうメンテしていくの？ こうした壁を乗り越える話を、先日Autifyさんのイベントで発表させて頂きました その内容や気付きを紹介します 活用に至るまでの道のり 実は、弊社でAutifyを導入してから1年が経ちました 振り返ると、色々な壁を乗り越えて来たんだなと感じます そもそもAutifyってなに？から説明したり 導入でテスト工数が削減できて喜んだり 時に活用が難しくなって相談をもらったり 自由に使い方を改善するチームが出てきたり 中でも今回は、開発チームが自律的に活用するステップに焦点を当てています 発表内容 スライド speakerdeck.com YouTube 発表は30:45~で
こんにちは。運営スタッフの@nari です。 いよいよSRE NEXT 2020の先行販売チケット販売がスタートしました!! 今後販売する一般販売チケットよりも安く購入することができます。 数量限定となっておりますので、是非お早めにご購入ください。 チケット購入はこちらから！！ 予定イベント 本編 懇親会 先行販売チケット購入ガイド 1.購入するチケットを選ぶ 2.Eventriteのアカウントを作る(or ログインする) 3.チケットの購入手続き 4.Paypalで支払いを行う 5.購入後の確認 6.QRコードの準備 6.1 アプリのインストールとログイン 6.2 チケットのQRコードを表示する 購入済みチケットの譲渡 チケット譲渡される方 1.該当チケットのattendeeの情報を修正し、チケットを譲渡する 2. チケット譲渡後 チケットを受け取る方 予定イベント 本編 2020年1月
良いSRE(Site Reliability Engineer)、悪いSRE - Speee DEVELOPER BLOG
お疲れ様です、2週間前に思いついた自作キーボードがさっき完成したSREの西田(k.bigwheel)です。 初めて自分で設計したキーボードが完成！名前はuni48にしました🌚 #自作キーボード pic.twitter.com/wFxz6DoVvn— k.bigwheel⌨️🦀🖊️ SREエンジニア@Speee株式会社 (@k_bigwheel) 2020年12月29日 僕がSRE(Site Reliability Engineer)という職種を知ったのは一年前のSpeeeの採用面接の中でした。SREになったのも入社のときからなのでやっと1年経ったばかりですね〜。 この1年のSREとしての自分を振り返ると、元バックエンド屋・インフラ屋としての経験もあって技術選定やアーキテクチャ的な面での大きな失敗は幸いにしてありませんでした。 発生した失敗もすべて想定の範囲内でその面ではよく価値を発揮
良さそう ITインフラの“体調”を一元監視で早期に異常検知 https://t.co/TumixShIsb @PRTIMES_JPより — adachinSRE (@adachin0817) February 26, 2024 皆さんお久しぶりです！1ヶ月ぶりのブログとなってしまいましたが、本日はなかなか面白いモニタリングツールを発見しました。 きっかけはXでの呟きからなのですが、メタップスホールディングスさんがSaaS向けイベントログの一元監視サービス「srest(スレスト)」をリリースされました。非常に気になっていたので使ってみようかなと思っていたところ！開発メンバーが「お初ですが、飲みいきましょう！」と誘われたので、いざ新大久保へ！ 今日は「srest」というイベントログの一元化ツールを開発しているメンバーと新大久保でポッサム会！みんな超面白い方でした！来週辺りに個人でsrest触っ
AWS CDK Conference Japan 2023 3年間運用したCDKの失敗から学ぶ CDK開発のプラクティス 2023/5/20 Yuki Ando あんどぅ JAWS-UG CDK支部の活動を応援したいおじさん 経済ニュースの事業会社のSREチームのリーダー インフラ畑出身で、コーディングはそこまで得意じゃないです 好きなAWSのサービス：ECS、Cost Explorer、CDK @integrated1453 JAWS-UG SRE支部 2 CDKと私 AWS歴が長いのでCDK自体はGA前のβの頃から触っており、もうすぐ5年近くになります。 初期構築でコードを設計・実装した時間よりも、インフラ担当の日々の運用のお仕事として メンテナンスでコードを修正・適用する時間が多く、コーディングに自信ニキではないです😇 2018年夏頃〜 2019年7月頃(GA後)〜 CDK β (
SRE NEXT2022で組織の成長痛と向き合う話をしてきました + 補足 - STORES Product Blog
はじめに プロダクト基盤本部 SREの藤原です。 heyにおけるSREの大切さ~マルチプロダクト運用の「楽しさ」と「難しさ」および今後の展望~と題してSRE NEXT 2022に登壇しました。 www.youtube.com 本エントリはその報告と補足説明です。 セッションでは、SREとは何かというところから始まり、heyにおけるSREの楽しさについて述べました。次に成長し続けるプロダクトと組織において、直面するであろう困難について解説しました。最後に困難の部分に向き合うにあたって、どのような活動や取組を進めていきたいかを述べました。 本エントリでは、セッションのスライドと内容を一部振り返りつつ、補足として取り組みの副作用と向き合い方(案)を述べています。 SREってなに？ まず、SREではなくプロダクト開発組織の目的を考えてみましょう。プロダクト開発組織は、顧客に対してあたらしい価値、よ
監視ってなんだっけ？
監視ってなんだっけ？ 運用監視勉強会#1 小林 良太郎（@ryota_hnk）
サービスティアを設定して、マイクロサービスの障害を防ぐ
成功者がどのようにNew Relicを使用してKubernetesのパフォーマンスを4倍に向上させ、拡張性とスループットを改善したかをご覧ください。
SREの河村(at-k)です。 本記事は freee基盤チームアドベントカレンダー の1日目になります。 カレンダー企画にあたり 今年もこの季節がやってきました。年末に向けて冬が深まり、心なしか忙しなくなってくる中、毎日ブログが一本ずつ投稿されていくのを見て年の瀬の近づきを感じる、ある種の風物詩となっています。 そもそもアドベントカレンダーは12月1日からクリスマスまで続く長い前夜イベントで、日本では、少なくとも筆者には馴染みがないものでした。そんな元ネタから派生した形で、近年ではIT企業が中心となってテックブログを日次で投稿していくイベントとして広く認知されてきています。ことの経緯を知らなかったので調べてみたのですが、意外に歴史は古く、日本では2008年頃からPerl界隈で賑わっていて、海外ではそれ以前からそれなりに定着していた文化のようです。 freeeでも毎年アドベントカレンダーが企
In my role as a Cloud and SRE Practice Lead at Slalom Build, I am fortunate to talk to a wide range of organizations, from smaller mid-market companies all the way to astoundingly large and complex enterprises, all from an equally wide range of industries. There is no doubt about it, Site Reliability Engineering (SRE) is the latest hot topic. These companies are looking to reduce the impact and ri
はじめに こんにちは。fluct でSREをしている村田です。 2020/1/25 (土) に豊洲フロントで開催された SRE NEXT 2020 に参加してきましたので、皆様にご報告していきたいと思います！ sre-next.dev SRE NEXTは日本で初めてのSREをテーマとしたカンファレンスで、弊社もゴールドスポンサーとして参加させていただいており、当日はfluctのSREチームメンバー数名で参加させていただきました。 スポンサーセッションでは fluct SREチームのみっさんが 成長を続ける広告配信プラットフォームのモニタリングを改善してきた話 というタイトルで発表を行いました。 speakerdeck.com 印象深かったセッションなど ここでは特に印象深かったセッション(など)についてまとめていきます。 早期来場者特典の特別ヨガプログラム これはセッションではないのですが
技術部プラットフォームグループ SRE の akichan です。 私が所属する技術部プラットフォームグループは SUZURI や minne といったサービスごとにある事業部に所属しないサービス横断のSREの集団です。運用の効率化、サービスレベル目標を達成できるようにするための支援を行っています。 今回はペパボのSREが普段利用している便利なツールの紹介を通し、具体的な業務の内容について知っていただこうと思います。 Kubernetes関連 SRE は各サービス事業部のKubernetesクラスタの管理者でもあります。 日常的なクラスタの維持管理や、トラブルシュートに対応します。 stern sternは複数のPodのログをまとめて見ることができるツールです。 kubectl logsを使ってPodのログをみる場合、Podの正確な名前を指定する必要があり手間です。 sternはPod名の
[レポート] SRE の基本と組織への導入 〜サービスレベル目標やエラー予算などサービスの信頼性に対する考え方〜 #GoogleCloudDay | DevelopersIO
TL;DR Googleでは4分間システムを止めるとボーナスが貰える（語弊） 原則 「信頼性は最も重要な機能」「信頼性を決めるはユーザー」「99.999%はソフトウェアだけでも運用だけでも達成出来ない」 人間の脳はリスク分析を正しく行えない。ではどうするか？ class SRE implements DevOps {} 5/25〜27の日程で行われたオンラインイベント、Google Cloud Day: Digital '21。 3日目に公開されたセッション「SRE の基本と組織への導入」を拝聴しましたのでレポートします。 個人的にめちゃくちゃツボだったセッションでした！ 具体的なサービスレベル目標(SLO)の策定方法・エラー予算(エラーバジェット)の策定方法・考え方から、そもそもSREとは・信頼性とはといった概要論、組織への導入方法・文化論まで、「SRE」を中心に置いた事柄がほぼほぼ網羅
![[レポート] SRE の基本と組織への導入 〜サービスレベル目標やエラー予算などサービスの信頼性に対する考え方〜 #GoogleCloudDay | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/1ee78329be0c669f34331a26f9ed050862dbe0c7/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2021%2F05%2Fd3-infra-01_eyecatch.png)
Site up and secure is a fundamental element of how we operate, and site reliability engineers (SREs) play a critical role in fulfilling that responsibility. Talent has always been the number one operating priority, and over the last few years, we’ve been running multiple programs to identify, hire, and develop talented SREs, including those without an SRE background. On this journey, we made a few
SREを自社に導入するためのプラクティス
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます はじめに 前回の記事では、Site Reliability Engineering（SRE）がシステム運用にもたらす利益についてご紹介しました。結論としては、「システムの信頼性の担保」と「開発効率の向上」という対極にある2つの要素を成立させるというものでした。 第2回となる本記事では、企業ごとに組織の体制や文化が異なる中で、どのような目的・意図を持って進めていけば、この対極にある要素を両立させたSREの導入につなげられるかのプラクティスについてご紹介します。 SRE導入はある程度の時間を要する 前述の通りSREの目的は、「システムの信頼性の担保」と「開発効率の向上」という2つの要素を両立させることです。 アプローチ方法としては、ソフトウ
(吉井)従来のモニタリングを否定するものではなく、システムの複雑さや規模が増していくことでモニタリングの限界が現れ始め、オブザーバビリティという新しいアプローチが誕生したものと理解しました。 クラウドネイティブによってもたらされる新しい運用コストが、従来の運用作業習慣では処理できないと気付いた結果が、オブザーバビリティだとも言えます。 第Ⅱ部 オブザーバビリティの基礎 第Ⅱ部は、技術的な側面からオブザーバビリティの必要性を解説しています。 構造化イベントを使う システムがどのような状態にあっても、あらゆる質問に答え、データを任意かつ詳細に繰り返し分析でき、完全な抽象度で収集するため 構成要素としてのメトリクスの限界 メトリクスは事前に集計された測定値 あるサービスへの1つのリクエストは、複数のメトリクスで表現される可能性がある 構成要素としての従来のログの限界 非構造化ログは人間には読みや
5 GitOps Best Practices
GitOps has been on the scene for some time now, but some things trip up users, both new and old. Here are some of the key best practices we’ve discovered while engineering Argo CD and running it at scale managing thousands of apps in production at Intuit. #1: Two Repos: One For App Source Code, Another For ManifestsMany engineers start out with both their app source code and their manifests in a s
Merpay Advent Calendar 2020 の21日目は、メルペイ SREチーム の @T がお送りします。 去年のAdvent Calendarでは、Terraform Moduleを使用したSLO（Service Level Objective）の定義と監視設定の定義を共通化し、マイクロサービス毎の1ヶ月毎のSLOを一覧表示出来るダッシュボードを開発していたことを紹介しました。あれから1年、この記事では、その後のSLO運用状況について紹介します。 SLO Dashboard 去年のAdvent Calendarでは、SLOの定義と監視設定の定義を共通化し、DatadogのDashboardやモニターの作成を自動化するため、Terraform Moduleを活用する仕組みを紹介しました。 この仕組みにより、DatadogのSLOのモニター、SLOリソース、SLOウィジェットを
Building Software Reliability through Distributed Tracing.pdf
Chatwork に所属するエンジニアや外部ゲストなど、多分野のエキスパートたちの登壇を通して、エンジニア組織で取り組んでいる試みなどの知見を提供する「Chatwork Dev Day 」。ここで開発部テックリードの加藤氏が登壇。まずは、新アーキテクチャの設計思想でCQRS、Event Sourcingを採用した背景を紹介します。 セッションのアジェンダ 加藤潤一氏（以下、加藤）：それでは、私のセッションを始めたいと思います。アジェンダはこのようになっています。最初はリアクティブシステムと、それに関連してCQRS（Command Query Responsibility Segregation）とEvent Sourcingについて話したいと思います。アーキテクチャの刷新を計画していて、その新アーキテクチャの設計思想の中にこの2つの概念が関わってくるので、最初に話したいと思います。 CQR
人間が目で、今と過去のレスポンスタイムを比較して遅くなっている・早くなっているを判断すると正確な判断ができないこともあるし、正確な判断ができるかどうかが人によってしまいそうです。 また、うちのチームでは二週間に一度ぐらい、主だったエンドポイントのレスポンスタイムが悪化していないかを点検していたんですが、なかなか忙しくて手が回らなくなってきてしまいました。 レスポンスタイムが悪化していないかは、過去のある時点のレスポンスタイムと、現時点のレスポンスタイムを比較し、差がない事がいえればよさそうです。 この比較は、標本平均に差があるかどうかを検定することで、行う事ができます。 この記事では、標本平均の差の検定をするための基礎知識についてまとめます。 中心極限定理 レスポンスタイムの母平均は、レスポンスタイムの確率分布がわかっていれば直接求められます。その差を検定することもできそうです。しかし、レ
この記事はエイチーム引越し侍/エイチームコネクトの社員による、Ateam Hikkoshi samurai Inc.× Ateam Connect Inc. Advent Calendar 2021 8日目の記事です。 8日目は、エイチームグループ内でもレアキャラなインフラエンジニアの @sugoto911 が担当します。 趣味はカメラ、登山、キャンプです！ 今年も雪が多いようなので、これからの季節はスキーを楽しみたい所存です。 来世は長野県松本市在住の山ガール予定なので、生暖かい目で見守っていただけると嬉しいです 仕事では**「推測するな、計測せよ」**をモットーに、日々インフラの管理や監視、Observabilityの整備を行っています。 はじめに 私がSREという方法論に出会ったのは、まだエイチーム引越し侍に入社前の2018年頃です。 当時はそもそも「信頼性とはなんぞ・・・？」という
This is a slide for SRE NEXT 2022 https://sre-next.dev/2022/
ITエンジニアの開発トレンドやキャリア情報・技術勉強会のレポート記事を紹介するメディアです。| 株式会社grooves 運営
IaC Security入門 ～tfsecを用いたTerraformファイルのセキュリティチェック～ | IIJ Engineers Blog
2018年新卒入社し、SOCにてインフラ管理を担当。その後、マルウェア解析や検証業務などに従事。2022年度からは、社内のSREチームにて兼務を開始。主な保持資格は、CISSP, OSCP, GREM, GXPN, RISS, CKA, CKSなど。バイナリを読むのが好きで、一番好きな命令はx86の0x90（NOP命令）。 はじめに Infrastrucutre as Codeは、インフラの構成情報をコードとして管理するという取り組み・概念です。最近、といっても結構前からですが、このコード自体のセキュリティもチェックしようという動きがあります。それは、IaC Securityと呼ばれます。今回は、IaC Securityの入門として、Terraformを題材にセキュリティチェックを行うことができるtfsecを紹介します。 普段SOCでマルウェア解析をしている私は、兼務として社内のSREチー
はじめに 採用管理システム「HRMOS採用」は、企業の採用活動の効率化や採用データの可視化･分析により、採用決定数の向上につなげることができるクラウドサービスです。 この度、HRMOS採用のSREチームでは、技術負債解消のためにログ運用基盤のDatadog Logsへの移行を行いました。その取り組み内容を紹介します。 計画以前のログ基盤構成と課題 サービス開始以降、ログの運用管理はEFKスタック1で構築された基盤を利用していました。サービスが成長にするにつれログ増加などの環境変化も伴い、時間経過とともに様々な課題が生まれてきました。 なお、トラフィックの規模感としては数百万件/日(平日)、数十億件/月ほどログ件数があります。 移行以前のログ基盤の構成イメージを以下に示します。 課題1 インフラの運用負荷が高い OpenSearch の運用負荷 Amazon OpenSearch Servi
IC1 Reliability Engineer I take direction from my team to automate and understand the systems Scope Area of ownership and level of autonomy / ambiguity I execute on defined tasks and contribute to solving problems with defined solutions. Collaborative Reach Organizational reach and extent of influence I work within the scope of my team with specific guidance from my manager/TL Impact Levers Techni
これは SREアドベントカレンダー 2022 - Qiita 2日目のエントリです。 昨日は みのるん☁️（@minorun365）さん の Let's see AWS W-A "Reliability Pillar" from SRE's view でした。 TL; DR SRE的な取り組みを社内で広めていくにあたり、自チームから外への普及に苦戦しているのであれば、ITIL 4が助けになるかもしれません "ITIL" のいいところは、歴史と権威があるところ、ガッツリ言語化されているところで、 "ITIL" の残念なところは、古臭い、柔軟性がなく堅苦しく固定的、実践的かどうかより手続き重視というイメージだった（個人的な印象） ITIL 4について知ったところ「"ITIL" の残念なところ」が払拭された Disclaimer ITIL 4の資格を取得したりはしていません わたし自身が特段IT
「0回目のポストモーテム」としてのプレモーテムのすすめ - スタディサプリ Product Team Blog
こんにちは。SREの@kyontanです。スタディサプリのSREチームにジョインしてから初のブログ記事となります。 つい先日、スタディサプリ 中学講座が大幅リニューアルされました。*1 今回は、そのリリースを自信を持ってユーザーの皆様へお届けするために実施した、プレモーテムという取り組みについてご紹介したいと思います。 背景 今回のスタディサプリ 中学講座のリニューアルは、バックエンド、フロントエンド(Web/iOS/Android)の開発をフルスクラッチで行ったため、大規模なリリースとなりました。 すでにユーザーへ提供しているサービスを、段階的にリニューアルされたものへ切り替えていく複雑なリリースということもあり、リリースにあたっては予期しないトラブルが起きる可能性が推測できます。 通常、さまざまなトラブル(障害)が起きた際には、私たちはあらかじめ定めた障害対応フローに沿って対応を行い、
Home
SRE NEXTとは信頼性に関するプラクティスに深い関心を持つエンジニアのためのカンファレンスです。 同じくコミュニティベースのSRE勉強会である「SRE Lounge」のメンバーが中心となり運営・開催されます。 SRE NEXT 2022は「SRE DIVERSITY」をテーマとして掲げ、スタートアップから大企業まで幅広い業種・領域・フェーズでのSRE Practiceの実践を集約し、より多様なSREの実践が普及することを目指します。 SREとはGoogleにより提唱された、システム管理とサービス運用における考え方または方法論であり、それらを実践するエンジニアを指します。 SREは、サービスやインフラの信頼性をソフトウェアエンジニアリングによって実現することを目指します。 サービスの信頼性を重視する多くの企業において取り入れられており、近年ますますその広がりを見せています。 セッションに
こんにちは、株式会社ヘンリー SRE（Site Reliability Engineer）の戸田（@Kengo_TODA）です。来週水曜の2023年2月22日に弊社SREにオンラインで質問できる会を開催します！ SRE、名前は一緒でも中身が全く違う説みなさんはSREの業務を説明できますでしょうか？私はSREの業務や責務はけっこう各社各様だという印象を持っています。 例えば弊社SREが何をやっているかは前回の記事である程度触れていますが、Kubenetesが出てこないことや製品コード（Apolloクライアント）に手を入れることを指して「ウチのSREとまったく違う」と感じる方も、生産性とサービス安定性の向上にピンを留めていることを見て「どこも解きたい課題は同じなんだな」と感じる方もいらっしゃったはずです。 これは自然なことだと言えます。「我々が顧客に提供したい信頼性とは何か」という同じ問いに対
モニクルのSREチーム形成期を振り返って
はじめに モニクルでSREをしているbeaverjrです。 この記事では、私が2023年7月に弊社初の専任SREとして入社してからの経験を振り返り、行ってきたこと、実際に直面した挑戦やそこから得られた学びを共有します。 今回は技術的な面ではなく、SREチーム・個人としてどのように成長してきたか、その過程でどのようにSREのイネーブリングの取り組みを進めてきたかに焦点を当てて紹介したいと思います。 ※イネーブリング：この文章では組織にSREの原則と実践を広め、根付かせることを目指す活動を意味します。 SREチーム立ち上げの背景 弊社はエンジニア全員がフルサイクルエンジニアとして活躍できる組織を目指しています。このビジョンの実現に向け、2023年7月にSREチームが設立されました。 立ち上げからの取り組み①：チームビルディング チームビルディングの過程では、まず共通の目標とビジョンを確立するた
GitHub - Unleash/unleash: Open-source feature management solution built for developers.
Unleash is a powerful open source solution for feature management. It streamlines your development workflow, accelerates software delivery, and empowers teams to control how and when they roll out new features to end users. With Unleash, you can deploy code to production in smaller, more manageable releases at your own pace. Feature flags in Unleash let you test your code with real production data
6月新刊情報『セキュアで信頼性のあるシステム構築』
『セキュアで信頼性のあるシステム構築 ―Google SREが考える安全なシステムの設計、実装、保守』 Heather Adkins, Betsy Beyer, Paul Blankinship, Piotr Lewandowski, Ana Oprea, Adam Stubblefield 編、Kuma Arakawa 監訳、渡邉 了介 訳 2023年6月6日発売予定 588ページ ISBN978-4-8144-0025-6 定価5,280円（税込） システムのセキュリティと信頼性は表裏一体です。セキュリティは、プロダクトの品質、パフォーマンス、可用性と密接にかかわるため、スケーラブルなシステムの設計と運用にとって極めて重要です。本書は、GoogleのセキュリティとSREのエキスパートが、根本からセキュアで、スケーラブルかつ信頼性の高いシステムを設計するためのベストプラクティスを紹介しま
こんにちは！ AWSのカオスエンジニアリングの新サービスもリリースされ、オンコールトレーニングへの関心が高まっているのを感じています。delyのSREチームのjoooee0000(高山)と申します。 この記事は「dely #2 Advent Calendar 2020 - Adventar」の24日目の記事です。 昨日は新規事業開発をしている おっくー (@okutaku0507) さんによる 「KPI自動通知Botで始める 数字に執着するプロダクトマネジメント｜奥原拓也 / クラシルPdM｜note」でした。 KPIの必要性から具体的なBot化の知識まで具体的に解説されているのでぜひ参考にしてみてください！ note.com adventar.org adventar.org はじめに 今回は、delyのSREチームがオンコールトレーニングを導入する3つの理由を紹介したいと思います。 d
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWSを使って学ぶ 監視設計 - tenbo07 - BOOTH
SREに求められるスキルと心構え | sreake.com | 株式会社スリーシェイク
Sreake流 SREの始め方
SRE NEXT 2020 :Eventbriteでの先行販売チケット購入ガイド
[SRE][Monitoring]イベントログの一元監視サービス「srest」を使ってみた！
3年間運用したCDKの失敗から学ぶCDK開発のプラクティス | ドクセル
freee 基盤チームアドベントカレンダーの歩き方 - freee Developers Hub
The Many Shapes of Site Reliability Engineering
SRE NEXT 2020 参加レポート - CARTA TECH BLOG
ペパボSREの道具箱 - Pepabo Tech Portal
Open source update: School of SRE
【書評】オブザーバビリティ・エンジニアリング | DevelopersIO
Maintain SLO 2020 | メルカリエンジニアリング
実践Observability
“止まらないシステム”ではなく“回復する能力”に価値がある リアクティブシステムを実現するためのCQRSとEvent Sourcing
レスポンスタイムの平均 - happy_siro's blog
SREの実践、SLI/SLO策定までの道のり - Qiita
Embedded SRE at Mercari
ITエンジニア向けのトレンド情報 | Forkwell Press （フォークウェルプレス）
ログ基盤をEFKスタックからDatadog Logsに安全に移行する工夫と効果
Dropbox Engineering Career Framework
社内でSREを広めるのに苦戦しているSREsにITIL 4がいい感じっぽいので共有したい
弊社SREにオンラインで質問できる会、やります！｜株式会社ヘンリー
delyのSREチームがオンコールトレーニングを導入する3つの理由 - dely Tech Blog