https://fortee.jp/yapc-hiroshima-2024/proposal/1e9fbacd-5a50-43ef-87f1-490e85448f17

はじめに 有用な知識の特性 Google SRE リソース Site Reliability Engineering: How Google Runs Production Systems The Site Reliability Workbook: Practical Ways to Implement SRE Building Secure and Reliable Systems: Best Practices for Designing, Implementing, and Maintaining Systems SLO Adoption and Usage in SRE Creating a Production Launch Plan Training Site Reliability Engineers: What Your Organization Needs to Cre

https://opentelemetry.connpass.com/event/296353/

こんにちは、後藤です。今回はAWS構成における踏み台についての記事です。 データベースなどのインターネットに繋げたくないリソースに踏み台リソース経由でアクセスさせることは、セキュリティ設計としてよくある構成だと思います。 今回はその踏み台リソースに「ユーザーログイン有無を検知して自動停止する」ロジックを組み込んだ方法を共有します。 また、一般的によく用いられるのはEC2だと思いますが、今回はECS on Fargate(以降はFargateと略)を使います。しかも自動停止ロジックにLambdaを使いません！！コンテナの中で完結させます。 踏み台を設計する時に気になること そもそも踏み台について設計する際に何が気になるのでしょうか。それはOS管理負担と自動停止です。 踏み台にEC2を用いるとOSパッチ適用などの運用コストが発生します。業務系サーバでないのに心労が重なるのはなるべく避けたいとこ

こんにちは、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

Light the way ahead: Platform Engineering, Golden Paths, and the power of self-service Imagine that you're a Java developer who has just joined a new company, and you're tasked with creating a small Java service. In a DevOps model, the shared responsibility between Development and Operations teams might mean that you'll not only be expected to write Java code, but also operations code like build p

Developers Summit 2023 登壇資料（2023/2/10） 『数字を上げることが 目的になっていませんか？ Four Keysによる開発生産性向上で陥った3つの失敗』 https://event.shoeisha.jp/devsumi/20230209/session/4180 #devsumi #devsumiA #リンクアンドモチベーション #リンモチ ============================================= 【株式会社リンクアンドモチベーション】 ■お問い合わせ engineer_pr@lmi.ne.jp ■Entrancebook https://note.com/lmi/n/n179505e048f4 ■テックブログ https://link-and-motivation.hatenablog.com/ ■登壇者 川津インタビュ

みなさんSREしてますか？ サービスなどの品質を維持していくために切っても切り離せないSREですが、 日本でもSREという言葉が定着しつつあるかと思います。 このSREについて書いていきたいと思います。 SRE NextのCFP忘れてたのでその代わりに・・ SREってインフラですよね？ 非常によくあるケース、というか多分ほとんどがこうなっていると思います。 もちろん会社としてインフラのことを指しても問題はありませんが、 SREとはどういうものなのか、正しく認識して今一度現状を振り返ることで さらに良い活動に繋がることが多いと思います。 なんのこっちゃ、という方も多いかもしれません。 SREはエラーバジェットなどの話が必ず出てきますので、 モニタリングや監視などが必ずセットにはなっていきます。 ですが、この部分が強調されているのかどうしてもインフラエンジニアでしょ、 というのが定着している場

こんにちは、マネーフォワード サービス基盤本部 インフラ部に所属している中谷です。 先日、鈴木のブログにもあったように、サービス基盤本部では体制を変えていっている真っ最中です。（今までの組織体制の課題や、これからの本部としての目指す方向の詳細については、是非そちらのブログを参照してみてください。） その新しい体制の中で "Enabling SRE" というチームが生まれるのですが、Enabling SREとはどういうチームなのか？どういう背景で生まれたのか？何をやっていくのか？ということを紹介したいと思います。SREの文化を根付かせたいけど、どうアクションすればいいかわからないといった方の参考になればいいなと思っています。 はじめに まずは背景を簡単に説明して、なぜEnabling SREが必要になったのかを知ってもらいたいなと思います。 サービス基盤本部の体制変更の背景 マネーフォワード

2023/5/23開催「オブザーバビリティ最前線 〜 事例LTから学ぶ、オブザーバビリティの成熟度〜」

日本でもDevOpsやSREというキーワードを聞くようになりましたが、肝心のITシステム自体はまだまだ従来のまま、といったケースが非常に多いかと思います。そして多くの場合、監視の仕組みも従来のままとなっているのではないかと思います。にもかかわらず、ビジネス側からITへの期待は飛躍的に増大しており、システムのパフォーマンスや可用性を維持するだけでも、とても大変なタスクとなっているのではないでしょうか。 こういった状況はIT先進国であるアメリカでも当然発生しており、その中でのベストプラクティスとして4つのゴールデンシグナルというものが定められました。具体的には、レイテンシー、トラフィック、エラー、サチュレーションです。これが一定以上の水準である場合にシステムは「健全」と判断されます。この4つのゴールデンシグナルをIT運用側と開発側の共通認識とすることで、「何が起きているか」「どうするべきか」

こんにちは、金融開発チームでアプリケーションエンジニアをしている ogugu です。 普段はサーバーサイド・フロントエンド問わず実装しています。 直近では、半分趣味でGoのlinterを自作したり、フロントエンドにStorybookのインタラクションテストを導入したり、幅広くやっています。 さて、今回は、SREチームに社内留学して Enabling SRE を推進した話をします。 なぜ留学したか 自分はこれまで「技術をリードしていく立場として幅広い知識と経験を持った人材になりたい」というキャリア志向を抱いていました。 そのために、自分自身がウィークポイントに感じていたインフラやセキュリティの理解を深めたいと感じていました。 また、同時に、freeeの開発組織に対して「悪い意味で開発者とSREの責任境界がはっきりしていて、開発者がインフラの構築・運用やアラート対応に疎くなっているのでは」とい

このエントリーは 3-shake Advent Calendar 2022 8日目の記事です。 サービスにおいてインシデントが発生した場合に書くポストモーテムについて，書く負担を減らせるようなテンプレートを提案します。 ポストモーテムのテンプレート ポストモーテムのテンプレートは，例えば以下のようなものが公開されています。 Google SRE タイトル・インシデント ID 日付 対応者 ステータス 概要 影響 主な原因 障害発生のトリガー 解決策 検知 アクションアイテム 学んだ教訓 うまくいったこと うまくいかなかったこと 運が良かったところ タイムライン 補足情報 PagerDuty 概要 起きたこと 原因 解決策 影響 対応者 タイムライン 振り返り うまくいったこと うまくいかなかったこと アクションアイテム 課題感と動機 私が担当しているプロジェクトでは PagerDuty の