こんにちは、マネーフォワード サービス基盤本部 インフラ部に所属している中谷です。 先日、鈴木のブログにもあったように、サービス基盤本部では体制を変えていっている真っ最中です。（今までの組織体制の課題や、これからの本部としての目指す方向の詳細については、是非そちらのブログを参照してみてください。） その新しい体制の中で "Enabling SRE" というチームが生まれるのですが、Enabling SREとはどういうチームなのか？どういう背景で生まれたのか？何をやっていくのか？ということを紹介したいと思います。SREの文化を根付かせたいけど、どうアクションすればいいかわからないといった方の参考になればいいなと思っています。 はじめに まずは背景を簡単に説明して、なぜEnabling SREが必要になったのかを知ってもらいたいなと思います。 サービス基盤本部の体制変更の背景 マネーフォワード
開発生産性Conference 2024で発表した資料です。 https://dev-productivity-con.findy-code.io/2024?m=2024/m/XmiKkhYo
みなさん、監視作ってますか？ システムを作ったら、そのシステムを監視していく必要がありますよね。どうやったら「いい監視」が作れるのでしょうか。「いい監視」とそうでない監視との違いとは、いったいなんでしょうか。 今の時代、「監視」ではなくて「可観測性」、 Observability (o11y) の時代になっていて、良いプラクティスや考え方が色々とあります。 この記事は、監視や o11y についての考え方を社内に共有するため書いたものを、社外共有用に調整し直したものです。新しい Observability の時代を、一緒に生きていきましょう。 監視を作ろう あなたはシステムを作りました。そのシステムに「監視」をつけようと思ったとき、最初にすることはなんでしょうか？ まずは、システムを何らかのツールで監視するところから始めましょう。やらなきゃはじまらない。 Nagios, Cacti, Mun
これは SRE Advent Calendar 11日目の記事です。 こんにちは、Backlog の SRE を担当している吉澤（Muzi と呼ばれている人）です。 本記事では、SRE Lounge #5 で講演した際に、時間の都合で省略した「ヌーラボ社内での Backlog のサービスレベル計測とその結果の活用」についてご紹介します。 長年運用されてきたサービスを改善するために、SRE ができる取り組みの一例としてご参考ください。 SRE とは？ SRE とは、Site Reliability Engineering の略です。これは Google で初めて提唱された概念で、その提唱者自身は著書「SRE サイトリライアビリティエンジニアリング」（いわゆる「SRE 本」）のなかで以下のように述べています。 Google 内で規定されることになったサイトリライアビリティエンジニアリングとは、
キラキラした事例に惑わされるな――SRE活動、まずやるべきは自動化……ではない！：リクルート流、SREコトハジメ（4）（1/2 ページ） SRE活動というと、どうしても自動化やツール導入から進めたくなるものですが、一呼吸置きましょう。まずは現状を正しく把握することが先決です。これは、SRE活動を行うための「健康診断」といえるでしょう。 事業との密なコミュニケーションによりサービスを理解し、サービスの特性を意識しながら、個々の対応を適切に実施する。SRE活動とはこれが本質であり、組織を作る中で、各メンバーにこうした意識を浸透させることが大切である――。 これまでの連載では、SREの概要と組織の立ち上げについてお話ししてきました。今回からはいよいよ、リクルートで実際に行われているSRE活動を紹介していきます。 SRE活動のための「健康診断」――四半期ごとのインフラ情報棚卸し 突然ですが、皆さん
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
