安定・安価なECS auto scalingを目指して / SRE Lounge #11
https://sre-lounge.connpass.com/event/151290/ の発表資料です
https://sre-lounge.connpass.com/event/151290/ の発表資料です
Developer eXperience Day 2024で登壇した資料です
SREを以てセキュリティエンジニアリングを制す / SRE, Security Engineering, and You
SRE NEXT 2023 のスポンサーセッション (20min) で使用したスライドです。 --- 概要: システムやソフトウェアの信頼性（Reliability）とセキュリティは多くの共通項を持つ概念です。本セッションでは、信頼性に主な関心を置いた技術体系であるSREを、セキュリティリスクの健全な管理のための技術体系として活用する方法を考察します。具体的にはSLO/SLI/エラーバジェット的発想に基づくセキュリティリスク管理や、セキュリティに関するソフトウェアエンジニアリング技法について、具体的な事例も交えながら論じます。 セキュリティ領域は技芸（Art）的解決が必要な課題領域も未だ多く、Engineering的体系は進化の途上にあります。SREというプラクティスを土台としてセキュリティ課題の解決を検討することは、SREに慣れ親しんだ（あるいは興味を持った）技術者の集まる本カンファレン
僕は CREing：ソフトウェアエンジニアにカスタマーサクセスを任せたときに起こるもの、を Autify で実現したいと思っている - えいのうにっき
この文章で出てくる用語たち： SRE Site Reliability Engineering / Engineer 。 前者のことを指して SREing, 後者のことを指して SREs, と表記することもある サイトリライアビリティエンジニアリング - Wikipedia CRE Customer Reliability Engineering / Engineer 。 「CRE」という言葉が使われるときはだいたい後者な気がする。前者を指してこの言葉が使われてるのはあんまり見ないな、という印象がある 僕自身、前職でサーバーモニタリングSaaSに携わっていたこともあって「SRE」については最低限の知識というか、その概念の理解はあるつもり。でも最近目にしたこちらの記事を読んで、ああそうだった、と認識を新たにした表現があった。以下は、この記事の中の「そもそもSREとは何なのか」という問を受けて
はじめに ベンチャー企業や立ち上がって間もない開発組織の場合、事業の成長スピードに対して、インフラ/SREエンジニアへのリソース不足が発生します。 スピード重視の結果、監視設計が不十分なままプロダクトがリリースされることも少なくないため、インフラに強いベテランの方のみが障害対応に当たらざるを得ず、周囲はただ応援するといった形もあるのではないでしょうか。 いざというとき、「アプリケーション起因じゃなければ、私は何もわからない...」とならないために、非インフラ/SREエンジニアでも最低限覚えておきたい障害発生時に役立つ監視系のコマンドをまとめてみようと思います。 本記事で想定している読者は以下の通りです。 インフラ関連の障害時に、問題の切り分けを行うためのコマンドが知りたい人 監視系コマンドを実行できる環境構築をサクッと作って動かしながら学びたい人 非インフラ/SREエンジニアでインフラ起因
ソーシャルゲームの長期運用
を目指すための SRE の取り組み - 10 周年を⽬指すコトダマンの場合 -
[Road to SRE NEXT@京都 - connpass](https://sre-lounge.connpass.com/event/318844/) で話した内容です!!
Enabling SRE チームの oracle です。 チーム内で SLO の推進を担当しております。 freee での SLO の実践についてご紹介させて頂きます。 改めてSREとは 皆さんご存知のように SRE とは Google 社が実践してきたシステム運用のノウハウを書籍化したことで一般的に知られるようになった言葉です。 日本語版の書籍が発売されてからもう5年経ちました。 Google が提唱しているアプローチを皆さんは実践できていますでしょうか。 freee では SRE チームの前身はインフラという部署でした。 同じように部署を新設ではなくて名前を変更した企業も多いのではないでしょうか。 チームの名称は何であれ問題はありません。重要なのは SRE を実践しているのか、していないかです。freee は SRE を実践できていたかというとそうではありませんでした。 信頼性とは S
じゆうちょう Advent Calendar 2019 18日目の記事です。 概要 データエンジニアリングという業務を扱うにあたって、どのように人事評価を実施するか。 本稿では実践可能なレベルで「評価基準」の例を提示します。 もくじ 概要 もくじ 背景 注意点 本題: 人事評価の設定例 1. マイルストーン（計画） 2. QCDS（構築） 3. サービスレベル（運用） 4. 利益目標（企画） まとめ Appendix 前提1: 本稿のスコープ ＝ 査定でボーナスが上下するような状況 前提2: 被評価者がコントロールできない事象に対してはフォローする 応用編1: 「データ基盤」という固有トピックにおける技術や案件の評価について 応用編2: 「データの民主化」の目標設定をどうするか おわりに 背景 データエンジニアリング業務に伴う「人事」（採用・アサイン・育成・評価）について質問を受けることが
Introducing Dispatch
By Kevin Glisson, Marc Vilanova, Forest Monsen Netflix is pleased to announce the open-source release of our crisis management orchestration framework: Dispatch!Okay, but what is Dispatch? Put simply, Dispatch is: All of the ad-hoc things you’re doing to manage incidents today, done for you, and a bunch of other things you should’ve been doing, but have not had the time! Dispatch helps us effectiv
2023年もSRE再考と叫びなさい‼️
2023年もSRE再考と叫びなさい‼️ SREの跡を求めず SREの求めたるところを求めよ というタイトルで登壇してきました 2023年3月3日 エンジニア文化祭 2023 https://forkwell.connpass.com/event/272596/ 『2023年もSRE再考と叫…
SRE界隈の隅っこでワチャワチャやっているしょっさんです。 今色々やっているコミュニティ活動についてのお話を書き留めておきたいなと思ったので、ここにパパッと書いていきます。 今までについて 今までのコミュニティ活動の関わりについては以下のしずかなインターネットの記事として書きました。 sizu.me そんなこんなで「ゆるSRE勉強会」の運営に関わらせていただいているのですが、せっかく再びコミュニティ活動始めたなら色々やってみっか！ってことで色々走らせてみました。 SRE Magazine SREに関する記事を探すと様々なところに散らばっており、SRE Weeklyみたいな集約された場所があると面白いよな〜ということでエイヤの精神でやってみました。 sre-magazine.net 「るびま」を参考に構成しているWebマガジンなのですが、最近第１号が発刊することができました。で、始めるにあた
Performance Schemaの仕組みと活用法の紹介 - freee Developers Hub
メリークリスマス！！freee Developers Advent Calendar 2022 25日目担当のid:shallow1729です！昨日はtdtdsさんでfreee特有の風土病：エンジニアの症例と寛解についてでした！ 僕からはMySQLのPerformance Schemaという機能の仕組みの解説とfreeeでの活用についての紹介をします。 前置き Performance SchemaはMySQLで実行されるトランザクションやクエリなどの実行時の様々な情報を取得してくれる機能です。特に面白いのは後で説明するようにstageやwaitなどのMySQLの実装レベルでのモニタリングを提供してくれているところで、これを使う事でどのあたりがボトルネックになっているかについて実際のProduction環境のワークロードで分析できる点です。また、最近だと例えばAWSのRDSを用いているとPe
マルチテナントなk8sクラスタで構築するログ収集基盤、システムの信頼性向上のために取り組んだ施策
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog 2021年11月10日・11日の2日間にわたり、LINEのオンライン技術カンファレンス「LINE DEVELOPER DAY 2021」が開催されました。特別連載企画「DEVDAY21 +Interview」では、登壇者たちに発表内容をさらに深堀り、発表では触れられなかった関連の内容や裏話などについてインタビューします。今回の対象セッションは「マルチテナントなk8sクラスタで構築する信頼性の高いログ収集基盤」です。 LINEはプライベートクラウドのVerda上で、さまざまなマネージドサービスを提供しています。Verdaはマイクロサービスアーキテクチャになっており、各サービスのコンポーネントはマルチテナントなKubernetes
SRE NEXTに行ってきました SRE NEXT 2024に参加してきました！資料のまとめ集です。 メルカリさん、ランチごちそうさまです🍞 SRE NEXT 2024タイムスケジュール ※ユーザ名は敬称略です。 Day1 工学としてのSRE再訪 @yuuk1t 登壇者紹介リンク: https://x.com/yuuk1t/status/1819631327219798137 ※08/05 13:40ころまでリンクに誤りがありました。失礼いたしました。 DevSecOpsの内回りと外回りで考える持続可能なセキュリティ対策 @yamaguchi_tk 登壇者紹介リンク: https://x.com/yamaguchi_tk/status/1820376622715002885 組織的なインシデント対応を目指して〜成熟度評価と改善のステップ〜 @nari_ex 登壇者紹介リンク: https
ヤフーのPrivate PaaS、KaaS、スタディストのTeachme BizにおけるSREの取り組み SRE（Site Reliability Engineering）は、サービスやインフラの信頼性にまつわる多くの課題を、ソフトウェアの力で解決していこうとするアプローチとして注目を集めています。企業にとって、ITシステムがビジネスに大きなインパクトを与えるようになった現在、多様なシステムの「信頼性」を確保し、高めていくための取り組みは重要性が増しています。今回、ヤフーでSREに向けた取り組みを続けている水落啓太氏、増田彬氏と、スタディストで開発部副部長兼SREを務めている北野勝久氏に、それぞれの企業で、どのようにSREに取り組んでいるのか、今後SREの領域で注目すべきテーマは何かについて語ってもらいました。 Private PaaS、KaaS、B2B SaaS……それぞれのSREの役割
SRE室の紹介 & Embedded SRE/Enabling SREとしてのお仕事紹介 - febc技術メモ
本投稿は、さくらインターネットアドベントカレンダー2022の14日目の投稿です。 この記事では2022年7月に発足した「SRE室」という部署について+これまで私が取り組んできたお仕事の一部を紹介します。 はじめに さくらインターネットへ入職しSRE室で働き始めてからもうすぐ半年となります。 febc-yamamoto.hatenablog.jp 新しい環境に慣れるまで苦労しましたが、ここ数ヶ月はだいぶ落ち着いてきており、最近は毎日の仕事がとても楽しく感じられています。 これまでSRE室としての取り組みをあまり紹介できていませんでしたが、せっかくのアドベントカレンダーという機会なのでここで紹介させていただきます。 SRE室の紹介 SRE室とは 2022年7月に発足したばかりの新しめの部署です。 以下のような企業理念/ミッション/ビジョン/バリューに従い日々の業務へ取り組んでいます。 企業理念
【SREチーム ブログリレー4回目】 こんにちは、SREチームの後藤です。 障害が発生した時、魔法のように原因を特定し颯爽と解決していくスーパーな同僚は皆様の周りにもいませんか? その姿に憧れてそうなりたいと思ったことが誰しも一度はあるはず。 ですが、話を聞いてみると「なんとなく怪しそうだった」「勘でここかなと思った」と言われたりして、まったく参考にならなかったこともあるのではないでしょうか。 そこで今回は私が考える障害調査において意識すべきポイントを、なんとなくではなくしっかりと言語化してまとめたいと思います。 題して「なんとなくで終わらせない、言語化すると見えてくる障害調査の5つのポイント」 神頼みしたくなる時も挫けずに強い心を持つことも大事 1. 調査できるように備えておく 2. 事象を正確に把握する 3. 事実と推測を区別する 4. 先入観を排除する 5. 問題を局所化する まとめ
Merpay Advent Calendar 2019 の14日目は、メルペイSREチームの@Tがお送りします。 本記事では、メルペイSREチームのSLO運用状況について、紹介いたします。 メルペイリリース前 去年のAdventCalendar 2018で、メルカリのWeb MicroservicesにおけるSLI/SLOについて紹介がありました。 メルペイでは新規のMicroserviceをリリースする前に、各MicroserviceチームがSLOを定義し、品質保持の一指標を決めるルールがあります。 メルペイSREチームでは、Microserviceチームと一緒にSLOを考え、各MicroserviceにSLOを定義していますが、一からSLOを定義するのはとても難しいです。 幸いなことにGoogle社からSLOの説明や定義方法などSREに関する素晴らしい記事がたくさん共有されており、SL
こんにちは、Backlog SREチームのmuziです。 この記事は SRE Advent Calendar 2019 の10日目、およびBacklog Play化プロジェクトブログの番外編です。 先日のブログ記事「SREは大規模なリプレイスプロジェクトで発生した様々な問題にどう取り組んだか【Backlog Play 化プロジェクト】」の後半では、Play化プロジェクトの終了後に、開発チーム自身によるオンコール対応の取り組みを始めたことを軽くご紹介しました。 私を含むBacklogのSREチームは、このオンコール対応を助けるためのアラート通知システムを作り、開発者なら誰でも使える形で提供しています。この記事では、前回のブログ記事では書ききれなかった、このシステムの詳細をご紹介します。 同じような問題意識を抱えていて、これからオンコール対応を見直したい、と考えているSREや開発者の参考になれ
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と病理医の共通点のお話】 - okadato の雑記帳
この記事は SREアドベントカレンダー 2019 11日目の記事です。 テック要素ゼロ・エモ全振りの内容なので、SRE以外の方にもぜひご一読いただきたいです！ 【追記】 SRE とは Site Reliability Engineering の略です！詳細は弊SREチーム Mng のコチラの記事をご覧ください！ 改めましてになりますが、スタディスト開発部はSREチームに所属のおかだと申します。 突然ですがSREとして働いているみなさん、月刊アフタヌーンで連載されている「フラジャイル 〜病理医岸京一郎の所見〜」というマンガをご存知でしょうか？ 2016年には長瀬智也さん主演でドラマ化もされた作品です（ぼくは原作しか読んでいないのですが…） 病理医という（ちょっとマイナーな？）職業がテーマの、個人的に超イチオシのマンガです！！ まずは作画をなさっている恵三朗さん（@36_Megu）の Twit
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）でホストされる
情報セキュリティ部「部内勉強会」の取り組み
はじめに MICINの情報セキュリティ部では、2021年3月から部内勉強会を毎週開催しています。最初は4名から始まりましたが、部門メンバーの増員や組織改編もあり、現在は毎週10名程度が参加し、持ち回りで発表を行っています。勉強会の目的としては、 最新の技術情報の交換 各自の業務内容のアウトプット・キャッチアップ 各自が興味のある情報の共有 としており、本の輪読や技術解説、ハンズオンなど形式は様々で、ジャンルも情報セキュリティ部が担当するセキュリティやSRE・インフラ分野だけでなく、生成AIやワークスタイルなど、情報セキュリティ部のメンバーとして有益な情報であれば、何でもOKとしています。 この記事では、2023年に部内勉強会で発表された内容をジャンル別にご紹介します。情報セキュリティ部の1年間の取り組みについて、簡単に知っていただければ幸いです。 部内勉強会の様子（オンラインとのハイブリッ
SRE NEXT 2024での登壇資料です https://sre-next.dev/2024/schedule/#jp040 System Risk Records テンプレートはこちら: https://docs.google.com/spreadsheets/d/e/2PACX-1vT2…
MLOpsチームは４名程度の規模だったのですが、PF-SREチームは当初から8名という大所帯(現在は10名)で、適切なチーム人数と言われる Two Pizza Rule の8人を超えてしまい、チーム運営のやり方を変えていく必要がありました。 また、2020年2月頃からCOVID-19によって週5リモートワークに代わり、その中で如何に効率を落とさずにチームとして働くかを模索していく必要がありました。 本記事では、小さなチームから、大きなチームのリーダーに移り変わるにあたってどのような変化を進めていったのか、またCOVID-19におけるリモートワークにどのように適合していったのかを記載していきたいと思います。 チームリーディングで気をつけていること私がチームをリードするときに気をつけていることは、約一年前に発表したZOZO MLOps のチームリーディングとSRE (Engineering)と
こんにちは、データエンジニアの石井です。 先日公開した記事「社内向けのデータ基盤から集計結果をReverse ETLしてサービスに組み込んだ話」で、ダッシュボード機能のリリースにより、Classiのデータ基盤が「社内用データ基盤」から「ユーザー影響あるシステムの一部」へ進化した話をしました。「ユーザー影響あるシステムの一部」への進化に伴い、データ基盤の品質担保は必要不可欠です。今回は、データ基盤の品質向上に取り組んだKANTプロジェクトについてご紹介します。 KANTプロジェクト 背景・課題 Classiのデータ基盤がユーザー影響あるシステムの一部になる前、つまり社内用データ基盤だった頃には以下のような課題がありました。 データ基盤の状態把握 マルチクラウドにおけるデータ基盤全体の状態把握ができていなかった データ基盤の実行状態（SUCCESS, FAIL, RUNNINGなど）の把握が、
Terraform Modules で再利用できるので最高ではないでしょうか？ - じゃあ、おうちで学べる
概要 ModuleはTerraformの複数のリソースをまとめて再利用可能な単位として扱うことができます。Moduleを使うことで複雑なリソース構成を抽象化し、システムの構造の把握やリソース構成の再利用が可能になり、読みやすさや可読性が向上し、修正箇所が単一になるなどのメリットがあります。 ただし、理解には初期コストが必要です。Moduleの設計では、1つの機能を持つように小さくシンプルに保つことが重要で、それが難しい場合は大抵複雑と言えます。 また、公式のModuleを利用することで、自身で定義やドキュメントの整備、メンテナンスの手間を省きつつ、プロジェクトを超えて共通認識として扱えるため、Module理解のコストが減ります。 しかし、どのタイミングでModuleに組み込むかの正解は、個々のプロジェクトの特性や開発チームの状況により大いに変わるでしょう。 絶えず試行錯誤を繰り返しながら個
公開日 2024/01/24更新日 2024/07/25あのサービスの監視・オブザーバビリティ アーキテクチャ選定【前編】 ユーザーや顧客へ信頼性を担保した価値提供をしていく中で、監視・オブザーバビリティの取り組みは非常に重要です。 今回の特集記事では、合同会社DMM.com、株式会社MIXI、株式会社マネーフォワード、パイオニア株式会社、Sansan株式会社、株式会社ZOZOの6社の各サービスを支える監視・オブザーバビリティの仕組みとして各社がどのようなアーキテクチャを組んでいるのか、またそのアーキテクチャにしている背景や意図についてお伺いしました。 自社に近いアーキテクチャやどのようにツールを活用しているかについて、実際の事例を元に参考になれば幸いです。 なお、後編も近いうちに公開させていただきますのでお楽しみに。 合同会社DMM.com（DMMブックス） アーキテクチャ設計の背景・意
メルペイSREチームの @tjunです。この記事は、Merpay Tech Openness Month 2020 の19日目の記事です。 今日は、メルペイSREチームのオペレーションのために開発して利用している Qray(クレイ) というツールの話をします。 はじめに メルペイでは、Google Cloud Platform(以下GCP)を利用してサービスを構築し動かしています。 GCPには Cloud Identity and Access Management (IAM) という権限管理の仕組みがあります。IAMを適切に管理して、アカウントに最低限の権限を付与することがクラウドサービスを安全に利用するためには必要なことです。これはSREが持つ本番環境に対する権限についても同様で、できるだけ本番環境に対する権限を持たないようにしておきたいのですが、障害対応など本番環境でのオペレーション
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 サイトリライアビリティエンジニアリングによると、 （開発/運用の分断に対し
TimeTree の SRE が海外展開においてやったこと＆やってないこと by【TimeTree × みてね勉強会】 グローバル対応への挑戦 〜SRE/インフラ編〜
![[TimeTree] Aurora から Spanner への 移行の決断と背景](https://cdn-ak-scissors.b.st-hatena.com/image/square/b2996b601519e42f0b70cc7e630a29ea83be92bf/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F545a6393167a49a2ab387ecc0a0ca90c%2Fslide_0.jpg%3F30594713)
皆様はじめまして！ NewsPicks SREチームの中川です。 本日はコンテナイメージのバージョン管理についての記事をお届けします。 概要 実装 ビルド デプロイ Pros Cons おわりに 概要 NewsPicksではECSやKubernetesに代表されるコンテナサービスを使用しておりますが、コンテナのデザインパターンとしてサイドカーパターンを採用しているサービスがあります。 詳しい説明は省きますが、サイドカーはメインアプリケーション用コンテナを補助するコンテナです。 これらのサービスをデプロイするとき、サイドカー毎に使用するDockerfileを ImageTag で指定していました。 実際には latest で固定するか、特定のImageTagを設定ファイルに書き込んで運用していました。 こうした運用方法の場合、Dockerfileを変更するときは事前にイメージを登録しておく必
Road to SRE NEXT@福岡(ハイブリッド開催) でLTした時の資料です。
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)
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の藤原さんに来てもらいました。藤原さん、よろしくお願いします。 藤原：よろしくお願いします。 藤村：まずは簡単に自己紹介をお願いします。 藤原：
5月14-15日に開催されたSREの国内カンファレンス SRE NEXT 2022 ONLINEにて、「AIOps研究録―SREのためのシステム障害の自動原因診断」と題して、ITシステムに障害が発生した際に、機械学習・統計解析の手法を用いて、障害の原因を自動で診断するための研究について講演しました。 講演に用いたスライド資料を以下に公開しています。 当日に配信された講演動画は、Youtubeに公開されています。 なお、この記事では、AIOpsという用語を、機械学習や統計解析をはじめとするAI（人工知能）と呼ばれる技術を用いて、ITオペレーターのオペレーション作業を自動化あるいは支援する技術の総称として使っています。 なぜAIOpsに着目したのか 自分が、統計や機械学習をはじめとするAIと呼ばれる技術をSRE分野に適用することを漠然と考えはじめたのは、2017年ごろでした。当時、今後のSRE
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「責任ある開発」を！フルサービスオーナーシップが変えるエンジニアリング文化
【10分で確認】インフラ起因のシステム障害で焦らないための監視系コマンド集 - Qiita
freee での SLO の実践について - freee Developers Hub
データエンジニアリングにおける人事評価基準 - 下町柚子黄昏記 by @yuzutas0
SREに触れて「いろいろやろうぜ」のモードになった - 生涯未熟
SRE NEXT 2024@Abema Tower 登壇資料まとめ
重要さが増すサービスの「信頼性」を高めるためにSREエンジニアたちが続ける挑戦
なんとなくで終わらせない、言語化すると見えてくる障害調査の5つのポイント - エムスリーテックブログ
Maintain SLO 〜俺たちのSLOはこれからだ!〜
Backlog開発チーム自身によるオンコール対応を支えるアラート通知システム | Backlogブログ
プロダクトのスケールによって顕在化しうるリスクをどう管理するか？
ZOZO プラットフォームSREとコロナ禍におけるチームリーディング術
データ基盤の品質向上への取り組み - Classi開発者ブログ
あのサービスの監視・オブザーバビリティ アーキテクチャ選定【前編】 - Findy Tools
権限をQray -SREへの一時的な本番環境権限付与のしくみ- | メルカリエンジニアリング
[TimeTree] Aurora から Spanner への 移行の決断と背景
コンテナイメージのバージョン管理を自動化したい！ - Uzabase for Engineers
意義から考えるObservability入門 #srenext
DMMプラットフォームに ゼロベースでSLO導入している取り組み 適切なSLI模索の軌跡
SREに興味のある方向け、SRE Weekly #280が公開 - 「堅牢性の原則がもたらす弊害」など
SRE NEXTで「AIOps研究録」講演を終えて - ゆううきブログ