#SHIFT_SRE No SRE,No life|教科書には載っていない!俺たちが考えたSRE推進の道しるべ| #SHIFT TECH TALKS#1 登壇資料
#SHIFT_SRE No SRE,No life|教科書には載っていない!俺たちが考えたSRE推進の道しるべ| #SHIFT TECH TALKS#1 登壇資料
「少人数のチームにて、一人からSREを始めるにはどうすればいいのか?」 2021年の10月からHR領域(マネーフォワードクラウド勤怠)でSRE組織を立ち上げているVTRyoです。 もっとサービスをより安定させたい!より向上したいといった話から、SREという役割を設置するケースは増えています。 しかし、SREという概念のなかったチームや部署で始めるにはどこから手をつければよいのでしょう。 SREの基本について記されたSRE サイトリライアビリティエンジニアリング――Googleの信頼性を支えるエンジニアリングチームには多くの原則が書かれていますが、同じことを丸々取り組むには前提や環境が違う部分も出てきます(SREのプラクティスを知るにはよい参考資料であることは間違いありません)。 というわけでこの記事では、以下の部分に答えられるよう進めていきます。 SRE本を読んだが、実際の組織やチームでは
SRE NEXT Logo はじめに こんにちは!SRE NEXT 2022実行委員会委員長のnari です。 先日、SRE NEXT公式Twitter アカウントにてSRE NEXT 2022の5/14,15の日程でのオンライン開催が発表され、オフィシャルサイトも公開されました! この投稿では、なぜ我々はSRE NEXT 2022を開催するのか・どんなカンファレンスにしたいかを書いていきます。*1 2022/2/7追記: スポンサー募集開始しました SRE NEXT 2022 スポンサー応募フォーム 2022/2/7追記: CFP Openしました SRE NEXT 2022 の CFP についてのご案内 - SRE NEXT Staff Blog SRE NEXTとは 信頼性に関するプラクティスに深い関心を持つエンジニアのためのカンファレンスであり、同じくコミュニティベースのSRE勉強
技術発信やその他の研鑽ではなく、業務という形式にこだわったのは、座学に偏りがちな私自身の性格を踏まえてのことです。 また、業務形態を問わず、ひとりのエンジニアとして何ができるのかを認知され、裏付ける実績があり、いい形でコラボレーションできる状態でありたいと思うこともあり、Offersに登録して、複業を探し始めました。 詳しい経緯は私のブログ記事「旗を立てる2021年」にまとめています。 > まずは「Offers」で副業オファーを受けてみる 小さいスコープで技術選定 最初に取り組んだのは、ツールやコンポーネントの導入でした。最初のタスクということもあって、「xxxというツールを導入してほしい」というタスクベースのものが主でした。 コンテナ管理にKubernetesを選択しており、運用をいかに信頼性高く効率的に行っていくかという課題がありました。それまでの基盤へのコンポーネント導入や移行の設計
この記事は コネヒト Advent Calendar 2021 18日目の記事です。 コネヒトでインフラエンジニアをしている @laugh_k です。今回は直近のコネヒトインフラチームの業務に部分的にスクラム開発のプラクティスを導入している取り組みを紹介します。 スクラム開発のプラクティス導入の背景 はじめに、なぜインフラエンジニアの業務で部分的なスクラム導入に至ったのかの背景を簡単に紹介します。 元々コネヒトのインフラエンジニアはこれまで基本的に一人、多くとも二人体制で過ごした時間が長く、課題の管理についても個人が把握している課題に取り組むという色が強かったように思えます。 私がコネヒトに入社した1年前からは GitHub Issue にチームの課題を集約する体制を作り、二人体制ではあるもののチームとしてインフラに関する課題を把握できる状況をつくることはできました。一方で日々の業務に取り
こんにちは。メルカリのNotification teamでソフトウェアエンジニアをしている@naruseです。 この記事は、Mercari Advent Calendar 2021 の19日目の記事です。 はじめに 私が所属しているBusiness Platform Notification teamでは、2つの役割で通知周りの基盤を担当しています。 1つ目はアプリケーションとしての役割の通知です。メルカリでは、アプリ内でのお知らせや個別メッセージ、やることリストなどを提供しています。私たちはそれらの膨大なデータを管理し、作成や取得のリクエストに応えています。これらの膨大なデータに対する私たちのチームの過去の記事として、昨年のAdvent calenderの一部である本番稼働中の Spanner にダウンタイム無しに57時間かけてインデックスを追加して得た知見をぜひご覧ください。 2つ目は
こちらは、「dely Advent Calendar 2021」21日目の記事です。 昨日は、PdM櫻本さんの「とりあえずやってみる。精神について」という記事でした。 何か新しいことにチャレンジしてみたいと思っている方は、ぜひ読んでみてください! はじめに こんにちは、クラシル開発部SREチームの松嶋です。 今年の10月に「SREがプロダクトの価値を最大化するためにチームとして取り組んできたこと」と題して、私たちが足元課題解決型の体制から脱却し、チームとして効果的に機能するために取り組んできたことについて5つ紹介しました。 tech.dely.jp こちらの記事で紹介している取り組みは、クラシルというプロダクトの成長を加速させていくために私たちは何をすべきなのか議論し、必要なことを地道に取り組んできただけなので、「これをやれば上手くいく!」というような銀の弾丸になるアクションは特にありませ
こんにちは、プロダクト開発本部SREチームの松嶋です。 delyのSREチームは、2020年末頃まで最大2人体制の少数で奮闘してきましたが、嬉しいことにこの1年でメンバーが4人と倍増しました。 それまでは、リソース不足であったため足元にある緊急度の高い課題を解決していくことがSREのメインイシューで、長期的に取り組んでいく必要のある改善業務に着手することが困難な状態でした。 しかし、SREのプラクティスを何も実践できていなかった訳ではなく、想定外の複雑さを減らし、今以上に増やさないための文化づくりを意識的にしてきたので、サービスの信頼性が大きく下がることはほとんどなく、アラート対応に追われる状況に陥ることは防げていたと思います。 実際どのように想定外の複雑さを減らす取り組みをしていたのかは、現CTOの井上が「SRE NEXT 2020」にて発表しているので、興味のある方はこちらの記事をご覧
概要 こんにちは、@sshota0809 です。 本記事は Uzabase Advent Calendar 2021 の 7 日目の記事となります。 昨今、SRE の文化を取り入れたり組織を新たに作ったりと様々なチャレンジをする会社が増えていると思います。 また、その中で SLA/SLI/SLO といったサービスに対する指標の策定、運用にチャレンジをする方たちも多いと思います。 今回は、SLI/SLO を定義及び運用するプラクティスの 1 つとして GCP の Cloud Monitoring を使った方法を紹介します。 TL;DR GCP の Cloud Monitoring には SLI/SLO を定義できる機能がある ドキュメント 定義した指標に対してエラーバジェットのバーンレートベースのアラートも定義することができる 各種設定は Terraform のモジュール を使うと簡単 GC
開催概要 Google が提唱した SRE という概念は、いまや日本企業の中でも多くの開発組織に取り入れられ、実践されています。 しかし、SRE の実践方法はプロダクトの性質や組織の規模、チーム構成によって異なるほか、 文化としても各企業それぞれ異なる解釈をしている現状が見受けられます。 例) まずは「インフラエンジニア」という役職名だけ「SRE」にしており実務としては変わらないまま 新しい概念で注目度が高いからという理由でインフラエンジニアポジションを「SRE募集」と求人募集している 上記の状況から、まだ日本におけるSREの理解と実践は発展途上な側面があるのではないでしょうか。 本イベントでは、9月3日に発売された新たなSRE本『SREの探求――様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践』の監訳者でもある山口 能迪様、GCPパートナーのスリーシェイク社でSRE特
※この投稿は米国時間 2021 年 5 月 8 日に、Google Cloud blog に投稿されたものの抄訳です。 アプリケーションの可用性を確保するために重要なのは、サービスレベルの指標を確立してモニタリングすることです。これは、サイト信頼性エンジニアリング(SRE)チームが Google Cloud で毎日実施している内容です。SRE 原則の最終目標はサービスを改善し、さらにユーザー エクスペリエンスを向上させることです。 SRE の概念は、指標がビジネスの目標と密接に結び付いたものであるべきだという考えから始まりました。ビジネスレベルの SLA に加えて、SRE の計画と実践に SLO や SLI も使用します。 サイト信頼性エンジニアリングの用語を定義するこうしたツールは、単なる便利な抽象概念ではありません。これらのツールがなければ、システムの信頼性、可用性、有用性は評価できま
JAWS DAYS 2019に登壇したサイバーエージェントに入社した柘植 翔太さんのセッション。AWSが提供しているシステム設計・運用のベストプラクティス集「AWS Well-Architected Framework」を独自でアレンジし自分たちの組織に合わせたものを作るに至った背景やプロセスが語られた。 エンジニアに裁量を与えるサイバーエージェント、そのインフラ組織の変遷 学生時代からJAWS-UGに参加し、新卒でサイバーエージェントに入社した柘植 翔太さんは、アメーバピグのソフトウェアエンジニアとして半年間経験を積んだ後、インフラエンジニアとしてなど各種サービスに長く携わってきた。昨年から所属している技術本部サービスリライアリティグループでは、社内で「メディア管轄」と呼ばれているメディア事業や新規事業のサービス大小含め200弱のインフラを横断的にサポートしている。 メディア、スタートア
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く