これからはじめる 実践SRE / SLO の監視をやってみよう
SRE がアツいですね。 昨年は以前に増して SRE 関連のイベントも増え、SRE 人材への注目も更に高まっていると感じた 1 年でした。私も Google Cloud の Customer Engineer として、お客様へ SRE のお話をする機会が増えてきています。 ご存知の通り、SRE は Google から生まれた運用プラクティス、またはそのロール自体を指す言葉です。 詳細は無料で読むことができる書籍を御覧ください。 “Site Reliability Engineering” 及び “The Site Reliability Workbook” （右上の右2つ）は HTML 形式 なので、Google Chrome で右クリックして 翻訳を選択するという簡単な手順で日本語でも読むことができます。（書籍がよい方は日本語版も購入できます。） 今回のテーマは SLO (Service
Four Keys 〜自分たちの開発レベルを定量化してイケてる DevOps チームになろう〜
はじめに この記事タイトルに興味をもって読み始めていただいている方の多くは、ソフトウェアエンジニアとしてチームで開発をしていたり、エンジニアリングマネージャーとしてチームビルディングやマネジメントをされている方なのではないかと思います。 実際、この記事を書いている加藤も、リクルートライフスタイルのデータプラットフォームグループ (以前は CETチーム と呼ばれていました) に所属するデータエンジニアとして、データ活用のための基盤開発・運用を行っている一人です。また、担当している社内データプロダクトのプロダクトマネージャーも兼任しています。 本記事では、自分の所属している DevOps チームを「イケてる DevOps チーム」にするために取り組んだ内容や気づいた点をお伝えしたいと思っています。 目次 はじめに 「イケてる」DevOps チームってなに？ Four Keys とは なぜ Fo
DevOpsとSREの違いとは?
ビズリーチのSREチームでJenkinsおじさんとマネジメントを担当している阪本です。もう先月の話になりますが、サンフランシスコで開催されたGoogle Cloud Next ‘18に参加してきました。今回はその場で何度も聞いた class SRE implements DevOps という考え方を紹介させて頂きます。DevOpsとSREの関係性を理解する上で大変参考になりました。 DevOps、SREという単語が使われるようになって時間が経ちましたが、若干のバズワード感も否めず私自身混乱していました。そのような中でSREの草分け的存在であるGoogleが新たに class SRE implements DevOps というメッセージを発信し始めました。これは「SREはDevOpsというinterfaceの実装である」という意味で、いわゆるプログラミング言語の抽象化機能であるinterfa
上位組織のデプロイ頻度は1週間に約30回 1日1デプロイだったメドピアが挑んだ頻度改善の取り組み
多数のヘルステックサービスを企画・開発しているメドピアが、リモートワーク継続中でも事業成長を加速させたプロダクト開発の事例や技術的な知見を紹介する「事業成長を加速させたエンジニアリングのウラ側」。ここで「Deploy Rails apps in 2021」テーマに正徳氏が登壇。まずは過去のレポートをもとにした目指すべきデプロイの頻度と、デプロイ改善のために取り組んだことについて紹介します。 自己紹介 正徳巧氏（以下、正徳）：「Deploy Rails apps in 2021」というタイトルで発表します。ちょっと私も緊張しているので、ビールを飲みながら発表させてください。 自己紹介です。正徳と言います。会社に入社して1年半ぐらいで、CTO室のSREという部署に所属しています。SNSなどは@shinsokuというハンドルネームで活動しています。よろしくお願いします。 SREでなにをやっている
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
横断的なSRE推進と成熟度評価
