並び順

ブックマーク数

期間指定

  • から
  • まで

601 - 640 件 / 1096件

新着順 人気順

SREの検索結果601 - 640 件 / 1096件

  • SRE NEXT 2023で「Runbookに何を書き、どのようにアラートを振り分けるか?」というお話をしました - ださろぐ@はてな

    登壇&参加記事です 今までのあらすじ(ずっとアラートの話してる気がする) 今回の発表まわりの蛇足 セッション ギークがイオンに飛び込んだ結果がやばい〜Reliabilityと経営〜 LINEスタンプのSREing事例集:大量のスパイクアクセスを捌くためのSREing エンジニアのためのSRE論文への招待 【コミュニティコラボ企画】パネルディスカッション 〜信頼性に関わる、ご近所さんが集まりました〜 ブルームバーグのセントラル・テレメトリー・システムが業務にもたらす価値 開発者とともに作る Site Reliability Engineering 信頼性目標とシステムアーキテクチャー セッション以外 今後について 今までのあらすじ(ずっとアラートの話してる気がする) 2020 dasalog.hatenablog.jp 2022 dasalog.hatenablog.jp 開発者とともに作る

      SRE NEXT 2023で「Runbookに何を書き、どのようにアラートを振り分けるか?」というお話をしました - ださろぐ@はてな
    • OpenTelemetry 分散トレーシングのシステムアーキテクチャ

      sumirenです。 SREやSDETや技術顧問やフルスタックエンジニアをしています。 この記事は OpenTelemetry Advent Calendar 2023 3日目の記事です。 2日目の記事は @k6s4i53rx さんの OpenTelemetryとOpenObserveを使ってKubernetes監視をかじる でした。 背景 OpenTelemetryを使うと、分散システムの各サブシステムでどのように処理が進んだのか可視化することができます。 経験を積んだエンジニアの方であれば、各サブシステムとオブザーバビリティバックエンドが一体どのようなコラボレーションをしているのか気になることかと思います。実際、SDKやOpenTelemetry Collectorを使って手軽に分散トレーシングを実現できても、仕組みを理解できていないと、いざトラブルが発生したときに問題解決が難しいでし

        OpenTelemetry 分散トレーシングのシステムアーキテクチャ
      • SREがセキュアなWebシステムを構築、維持するためにやれることはなにか / What can SRE do to build and maintain a secure Web system?

        SRE NEXT 2020 2020.1.25 "セキュリティ専門のエンジニアが組織にいない場合、古くなったソフトウェアのメンテナンス、鍵の管理、ファイアウォールの管理を誰が行うのか。それが曖昧な状況が長く続くとサービスが脆弱となり、やがて問題を引き起こすことでしょう。 サービスとシステムの信頼性に対してSREが責任を持つ組織においては、SREが中心となってセキュリティの問題を把握し、安全で堅牢な状態を維持する必要があります。Webアプリケーションやクラウドを使ったシステムをセキュアに保つためにできることは多くあります。 新しくサービスを開発する時、サービスの規模が大きくなってきた時など、セキュリティを意識すべきフェーズで何をすべきなのか、戸惑うことは少なくありません。セキュアなWebシステムを構築、維持するために、最低限知っておきたい知識、応用的な事例について、今までの経験をもとにお話し

          SREがセキュアなWebシステムを構築、維持するためにやれることはなにか / What can SRE do to build and maintain a secure Web system?
        • 〜運用しやすいプレビュー環境を求めて〜 Gateway APIで作るサービスメッシュレスなプレビュー環境 - LIVESENSE ENGINEER BLOG

          みなさん、プレビュー環境してますか?どうも、かたいなかです。 以前、記事や登壇でIstioベースのPreview環境の構築方法をご紹介しました。 made.livesense.co.jp 外向けに発表したものの、Istioの運用工数や学習コストがネックとなってしまい、実際の転職会議の開発環境の導入にはいたっていませんでした。 最近になってGateway APIの実装例も増えてきて、Istio以外にもプレビュー環境でのヘッダを元にしたルーティングの実現において、現実的な選択肢となりそうなツールが増えてきました。そこで、Gateway APIのEnvoyによる実装であるEnvoy Gatewayを用いて、サービスメッシュを使用しないプレビュー環境の構築を試してみたため、この記事では構成例をご紹介します。 なお、今回の記事の中ではプレビュー環境の説明等について前回の記事と同様の説明を再度する箇所

            〜運用しやすいプレビュー環境を求めて〜 Gateway APIで作るサービスメッシュレスなプレビュー環境 - LIVESENSE ENGINEER BLOG
          • SRE Practices in Mercari Microservices

            This is a slide for SRE NEXT 2020 (https://sre-next.dev/). Mercari Microservices Platform Team is building a platform for backend developers to build and run microservices. Currently, in this platform, around 100+ microservices are running and more than 200+ developers are working with. To run this scale of platform, the reliability is really critical. In this talk, I will share how we operate thi

              SRE Practices in Mercari Microservices
            • FIFA ワールドカップ 2022に向けたキャパシティ確保の軌跡 / Trajectory of securing system capacity for FIFA World Cup 2022

              これまで経験したことがない規模の配信を迎えるにあたり、我々SREチームが行った、キャパシティプランニング・リソース調達・負荷試験等のキャパシティ確保に向けた活動から本番での監視体制や実際にどういった負荷傾向があったのか等、可能な限りお話したいと思います。大規模なイベントに向けた対策の参考になればと思いますので、運用担当者の方ぜひお聞きください。 https://developer.abema.io/2023/sessions/axlOoyAFHa/?utm_medium=social&utm_source=speakerdeck

                FIFA ワールドカップ 2022に向けたキャパシティ確保の軌跡 / Trajectory of securing system capacity for FIFA World Cup 2022
              • SRE Classroom: The Art of SLOs - Google

                The Art of SLOsは、GoogleのCustomer Reliability Engineeringチームによって開発されたワークショップです。このワークショップの目的は、Googleがサービスの信頼性を計測する方法 サービスレベル指標(SLI) とサービスレベル目標 (SLO)を参加者に紹介し、実際にこれらの計測方法を作成することを体験してもらうことです。これらは重要で土台となる概念です。サービスの信頼性を客観的に測定する方法があれば、サービスの信頼性について有意義な会話をすることがはるかに簡単になります。 ワークショップの理論編では、開発チームと運用チームの間でしばしば生じる組織的な緊張を、サービスの望ましい信頼性を表す目標値を設定することで解決する方法を学びます。また、SLOとエラーバジェットを使って、データ駆動で、客観的、かつユーザー重視の方法でサービスの信頼性を測定・

                • 1,800万人が利用する『家族アルバム みてね』におけるK8s基盤のアップグレード戦略と継続的改善 / FamilyAlbum's upgrade strategy and continuous improvement for K8s infrastructure

                  SRE NEXT 2023 https://sre-next.dev/2023/schedule/#jp093

                    1,800万人が利用する『家族アルバム みてね』におけるK8s基盤のアップグレード戦略と継続的改善 / FamilyAlbum's upgrade strategy and continuous improvement for K8s infrastructure
                  • Production Readyと開発プロセス改善 - OPTiM TECH BLOG

                    こんにちは。プラットフォーム技術戦略室SREチームの津田(@grim0h)です。 昨年の6月以来の投稿になります。 今回は、Cloud IoT OSに対して行なっているProduction Ready活動について紹介します。 ( この記事はInfra Study Meetup #3のLTで話した内容を詳細化したものです。LTの資料はこちらになります。) Cloud IoT OS とは Cloud IoT OS について簡単に紹介します。 Cloud IoT OS とは、あらゆる人に直感的なIoTデバイスの制御、データ解析、AI・クラウドサービス連携できるユーザ体験を提供するAI・IoTプラットフォームです。 マイクロサービスアーキテクチャで構成されており、コンテナ化された各サービスをKubernetesで管理しています。 www.optim.cloud Production Ready と

                      Production Readyと開発プロセス改善 - OPTiM TECH BLOG
                    • アジャイルなSREチームの運用

                      LAPRAS株式会社でSREをしているyktakaha4と申します🐧 弊社のSREチームで最近運用をはじめた見積もりやふりかえりの手法について書きたいと思います 大規模な立ち上がり済みの組織向けでなく、今ひとりで仕事をしている人が2人目のSREを迎え入れたときの一事例としてご覧ください 経緯 弊社は2016年に創業して以来、ソフトウェアエンジニアとして入社した社員がアプリケーションからクラウドまでプロダクト全体を開発・運用するというスタイルが取られていましたが、 エンジニア組織の拡大に伴い、2021年頃からプロダクトの信頼性や可用性の向上を責務とする専任のSREを立ててシステムの改善をおこなってきました 以下は、弊社で導入しているホラクラシーに基づいて定義された Site Reliabilityサークル のロールの一覧です 原則として、ロールは誰であっても自由に負うことができるので、主務

                        アジャイルなSREチームの運用
                      • 日経電子版SREチーム立ち上げ中

                        日経電子版を支えるSREチームが2019/1に発足しました。メディアとして安定したサービスを実現し、いつでもニュースをユーザーに届けられるようにすることは重要だと考えています。しかし、開発チームの体制は電子版を構成するシステムごとに分かれており、電子版全体の可用性、信頼性、アーキテクチャに責任を負うチームはありませんでした。また、各開発チームは機能開発と可用性、信頼性の担保の両方の責務を負っていて、必ずしも安定稼働上の課題に注力できない環境にあります。この課題を解決するべく、SREチームを発足しました。まだ、道半ばではありますがこれまでの取組を共有します。

                          日経電子版SREチーム立ち上げ中
                        • SRE for single-tiered software applications | Google Cloud Blog

                          In cloud operations, we often hear about the benefits of microservices over monolithic architecture. Indeed, microservices help manage hardware being abstracted away and push developers towards resilient, distributed designs. However, many enterprises still have monolithic architectures which they need to maintain. For this post, we’ll use Wikipedia’s definition of a monolith: “A single-tiered sof

                            SRE for single-tiered software applications | Google Cloud Blog
                          • Google SRE Book Updates, by Topic

                            SRE Book Updates, by Topic Click on a chapter thumbnail to see relevant publications, conference talks, and workshops by Google SREs.

                            • 円滑なエラーバジェット運用に向けた取り組み

                              HRMOSでは顧客満足を最優先し、価値あるソフトウェアを早く継続的に提供するため、スクラムに加え、Site Reliability Engineeringをプロダクト開発に適用し、SLI/SLOを定め、運用しています。また、エラーバジェット枯渇時にどのように行動するのか、その運用ルールも定めています。 私たちと同じようにエラーバジェットを運用する組織において、枯渇後のアクションとしてリリース凍結1を視野に入れようとする場合、プロダクトや関係者に与える影響は大きいため、そのルールの策定や調整に頭を悩ますケースも多いのではないでしょうか。 HRMOSの中でも特に歴史の長いプロダクトであるHRMOS採用では、SREチーム内や関係者との間で議論を重ねてルールを見直してきたため、これからエラーバジェットの運用を開始しようとしている方々の参考になればと思い、現在どういった点を考慮して運用しているかを紹

                                円滑なエラーバジェット運用に向けた取り組み
                              • ポストモーテムを理解する - Qiita

                                はじめに こんにちは、webエンジニアの@an_sonyです。 最近、障害対応の振り返りをしていた時に「ポストモーテム」という手法を初めて知りました。これまで「どうやったら良い振り返りができるのか?」と悩んでいた自分にとって目から鱗の知識ばかりでしたので、整理のためにまとめてみます。 ポストモーテムとは? SRE サイトリライアビリティエンジニアリング1によると、インシデントとそのインパクト、その緩和や解消のために行われたアクション、根本原因(群)、インシデントの再発を避けるためのフォローアップのアクションを記録するために書かれるドキュメントを指します。 言い換えると、失敗(障害)から学び、再発防止策を決める活動です。 障害報告書との違い 障害報告書と内容が似ていますが、ポストモーテムは読者と目的が違います。 障害報告書は、障害発生によって不利益が生じたユーザーに対して、その説明をするため

                                  ポストモーテムを理解する - Qiita
                                • 2021 年の SRE チームの活動について - Gunosy Tech Blog

                                  はじめに SRE 部の茂木です。 こちらの記事は Gunosy Advent Calendar 2021 - Adventar の 21 日目の記事となります。 前回の記事はサンドバーグさんの 改めてドライブレコーダーを作ってみた - Gunosy Tech Blog でした。 かなりマニアックな内容となっていましたね。 さて、2017 年頃から 「SRE」という単語が世の中に出回ってから、数多くの実践が各企業で行われてきました。ですがその業務内容を詳細に公表している企業はそう多くはありません。 私は Gunosy に来てから正式な SRE チームに所属することになりましたが、 常にSRE の定義とは、難しいものがあるなと日々感じています(各社によって責任範囲や求められることがかなり違うため) 。 そこで今回は、 2021 年の Gunosy のSRE チームがどのような活動をしてきたかを

                                    2021 年の SRE チームの活動について - Gunosy Tech Blog
                                  • テックタッチに入社後1ヶ月でSRE部隊を作った話 - Techtouch Developers Blog

                                    こんにちは、この記事はテックタッチアドベントカレンダー20日目を担当するエンジニアリングマネージャーの小林こと Kobaan です。 毎年クリスマスはフライドチキンをいろんなところから購入してます。去年は某コンビニのチキンを購入してましたが、今年はなんとコロナの影響からか品不足で、近隣の店舗では予約できなくなってました。残念。 今年は某フライドチキン専門店のチキンでクリスマスを祝おうと思います。 まずはエンジニアリングマネージャーの業務 主に二つのチームマネジメントとデリバリーマネジメントの業務を持っています。 この二つのチームの内訳としては下記となっています。 プロダクト機能開発チーム SREチーム 今回はその一つである SRE ( Site Reliability Engineering )チームについてお話しさせてください。 当初は保守対応部隊が存在しなかった 当初プロダクトサイドと

                                      テックタッチに入社後1ヶ月でSRE部隊を作った話 - Techtouch Developers Blog
                                    • チームでサービスの運用をうまく支えていくための取り組みについて ~SREを添えて~ | 株式会社ヌーラボ(Nulab inc.)

                                      発表資料について 当時の発表資料とNuCon Mini 2022 Springで登壇した際の動画のリンクを埋め込んでおきますので、もしよろしければ御覧ください。 発表資料 「チームでサービスの運用をうまく支えていくための取り組み ~SREと共に~」 ちなみにこちらの動画では発表前にジョジョネタを盛り込んでいます。もしジョジョが好きな方がいましたら何部のセリフが使われているか当ててみてください。答えは当記事の最後にあります。 過去のGit Teamの体制と課題 Git Team誕生前 BacklogのSRE課にBacklogのGit機能の開発するメンバー1名を包含していました。メンバーはアプリケーションの開発・保守をメインで担当し、BacklogのGit機能に関連するサーバーの保守(kernel updateなど)はWebOperationが担当するという作業分担をしていました。 WebOp

                                        チームでサービスの運用をうまく支えていくための取り組みについて ~SREを添えて~ | 株式会社ヌーラボ(Nulab inc.)
                                      • SREエンジニアが目指すGKE共通デプロイ基盤の完成形 - ぐるなびをちょっと良くするエンジニアブログ

                                        こんにちは。開発部門 開発部 Data AI Strategyセクション データ基盤 Unitの小野です。 2020年8月に入社してから早3年。SREエンジニアとして、日々業務改善に励んでいます。 ここ一年ほど、DAOという組織改善プロジェクトを推進していく中で、Google Kubernetes Engine (GKE)を使ったGKE共通デプロイ基盤の整備も進めてきました。 ※ DAOについての詳細はSREエンジニアが組織改善プロジェクトを立ち上げてみたを参照ください SREエンジニアの責務の一つは、プロダクトのリリースサイクルを極限まで短くし、次々と新しいサービスを世の中にリリースすることです。ChatGPTのような誰でも簡単に扱えるAIモデルが誕生したことで、プロダクト開発競争は今後ますます激しくなっていくと予想しており、SREエンジニアの責務の重要性をヒシヒシと感じています。 そう

                                          SREエンジニアが目指すGKE共通デプロイ基盤の完成形 - ぐるなびをちょっと良くするエンジニアブログ
                                        • Shifting to Zero Touch Production | Mercari Engineering

                                          Author: Dylan Lau (@aidiruu), Platform DX Team Zero Touch Production (ZTP) is a concept where all changes made to production are done by automation, safe proxies or audited break-glass systems. There are many kinds of production outages that stem from human error, such as: Configuration errors Script errors Running commands in the wrong environment ZTP can mitigate the risk of outages from these e

                                            Shifting to Zero Touch Production | Mercari Engineering
                                          • Life with Datadog

                                            July Tech Festa 2021 winter https://techfesta.connpass.com/event/193966/

                                              Life with Datadog
                                            • みてねのSREによるグローバルサービスの体験を向上させる技術 | gihyo.jp

                                              株式会社MIXIで『家族アルバム みてね』(⁠以下みてね)のSREグループに所属している尾関です。 みてねは2017年より海外でもサービス展開していまして、1,500万人を超えるユーザに175の国と地域でサービスを提供しています。そのうち3割以上が海外ユーザになります(2022年8月現在⁠)⁠。 事業としても市場規模の大きさから海外ユーザをもっと伸ばしていくことに注力しており、その中でSREグループは「世界中の家族が快適かつ安心に使えるサービスを提供する。」をミッションに掲げてきました。 本記事では、世界中の家族が快適に使うために行ってきたことの一部を紹介させていただきます。 これまでの改善の歴史 2017年:海外展開スタート 2015年のサービスリリース当時、みてねのバックエンドインフラはAWSの東京リージョンで構築していました。 そして2017年より海外展開を開始しましたが、当時はまだ

                                                みてねのSREによるグローバルサービスの体験を向上させる技術 | gihyo.jp
                                              • ダウンタイムなしでEC2のElasticsearchからマネージドなOpenSearchへと移行した際の工夫

                                                「HRMOS採用」では、採用に関するデータをElasticsearchに保存し検索機能で利用しております。 以前はEC2インスタンスにインストールしたElasticsearchを利用していましたが、スケールやメンテナンスしづらいことからAWSのマネージドサービスであるAmazon OpenSearch Serviceへの移行を行いました。 移行の際には、ユーザに安心・安全な利用をしていただけるように、下記の4つの観点に気をつけました。 データのロストがないこと セキュリティ的に安全であること 機能・非機能ともに劣化がないこと ダウンタイムなしで移行完了させること この記事では、特に ダウンタイムなしで移行完了 に至った3つの工夫を紹介します。 ※以降、Elasitcseasrch=ES、Amazon OpenSearch Service=AOSと記載します はじめに 「HRMOS採用」とは

                                                  ダウンタイムなしでEC2のElasticsearchからマネージドなOpenSearchへと移行した際の工夫
                                                • クラシルのSREをチーム化するときに意識した3つのことと半年間の実績 - dely Tech Blog

                                                  こちらは、「dely Advent Calendar 2021」21日目の記事です。 昨日は、PdM櫻本さんの「とりあえずやってみる。精神について」という記事でした。 何か新しいことにチャレンジしてみたいと思っている方は、ぜひ読んでみてください! はじめに こんにちは、クラシル開発部SREチームの松嶋です。 今年の10月に「SREがプロダクトの価値を最大化するためにチームとして取り組んできたこと」と題して、私たちが足元課題解決型の体制から脱却し、チームとして効果的に機能するために取り組んできたことについて5つ紹介しました。 tech.dely.jp こちらの記事で紹介している取り組みは、クラシルというプロダクトの成長を加速させていくために私たちは何をすべきなのか議論し、必要なことを地道に取り組んできただけなので、「これをやれば上手くいく!」というような銀の弾丸になるアクションは特にありませ

                                                    クラシルのSREをチーム化するときに意識した3つのことと半年間の実績 - dely Tech Blog
                                                  • インフラの整備、SLIとSLOの設定、セール対策 Railsアプリケーションのユーザ体験を支えるSREの取り組み

                                                    オリジナルグッズ作成・販売サービス「SUZURI byGMOペパボ」に関わるエンジニアメンバーや事業部長が登壇し、SUZURIの開発の今や、現在の課題・今後の取り組みについて話す「43万人超のクリエイターの表現活動を支える!ECプラットフォームSUZURIの開発の裏側」。ここでモバイル/Webアプリケーションエンジニアの時田氏が登壇。SRE活動として行っていることを紹介します。 自己紹介と今日話すこと 時田理氏(以下、時田):「SUZURIにおけるSREの取り組み」というタイトルで発表します。よろしくお願いします。自己紹介です。「SUZURI」というサービスのモバイルと、Webアプリケーションエンジニアをやっています。 今日話すことです。すみません、最初におことわりなんですけど、最初の仮のタイトルではFlutterに関する登壇をする予定だったんですが、今日はちょっとFlutterの話はしな

                                                      インフラの整備、SLIとSLOの設定、セール対策 Railsアプリケーションのユーザ体験を支えるSREの取り組み
                                                    • アソビューにおけるSREとは?4,000万人のアクセスに耐えられるインフラと高い信頼性を目指して - asoview! Tech Blog

                                                      この記事は、アソビュー! Advent Calendar 2022の12日目です。(裏面です) アソビューでSREユニットに所属をしている三森です。この記事では弊社のSREについて紹介をしようと思います。 アソビューでのSREとは? SREの指針とは? 信頼性 全体最適 DevSecOps こういうことやってるよ! 最後に アソビューでのSREとは? アソビューでのSREとはGoogleが提唱した「Site Reliability Engineering」の考え方を基本にしておりますが、インフラ/運用の上に乗るサービス、その先に居る顧客までを見据えて改善活動を積み上げるチームとしています。 www.wantedly.com SREの指針とは? アソビューはビジョンとして、「2025年までに、4000万もの人々に遊びを通じて、素敵な思い出をお届けする」を掲げています。 このビジョンの実現する

                                                        アソビューにおけるSREとは?4,000万人のアクセスに耐えられるインフラと高い信頼性を目指して - asoview! Tech Blog
                                                      • Amazon EKS上でアプリケーションをGraceful Shutdownさせる際に注意すべきポイント | 株式会社ヌーラボ(Nulab inc.)

                                                        SRE課で、主にBacklogのSREを担当しているMuziです。 物理サーバやインスタンスで動作していたアプリケーションを、Kubernetesクラスタに移行する際には、いままで暗黙的に存在していた前提に目を向ける必要があります。そのような前提を無視すると、アプリケーションは動作したとしても、可用性が悪化する可能性があるためです。 私たちがBacklogをEC2インスタンスからKubernetesクラスタに移行した際にも、可用性の悪化に繋がる問題に対処する必要が生じました。今回は、そのような問題の一つであるGraceful Shutdownに関する注意点を、私たちの実体験をもとにご紹介します。 なお、以下の内容はAmazon EKSのKubernetesバージョン1.22で確認しました。Amazon EKSに固有の話題も含みますが、Kubernetes全般に共通する部分も多いかと思います

                                                          Amazon EKS上でアプリケーションをGraceful Shutdownさせる際に注意すべきポイント | 株式会社ヌーラボ(Nulab inc.)
                                                        • SLOの運用のために OSS shimesabaの導入 - KAYAC engineers' blog

                                                          カヤックSREの池田です。今回は、カヤックのプロダクトの一つ『Tonamel』で導入したエラーバジェット算出ツール shimesabaの話をします。 shimesabaとは? github.com shimesabaは監視サービスであるMackerelを用いて、エラーバジェットを計算しサービスメトリックとして投稿することでSLI/SLOの運用を助けるツールです。 このツールを用いることで、以下のようなグラフが得られます。 この図の上部は、エラーバジェットの使用率=信頼性の損失率の推移を表すグラフになっています。 この図の下部は、エラーバジェットをいつ?どのくらい?損失したのかを表すグラフになっています。 一言で、エラーバジェットと言ってもいくつかの計算方法が存在します。 今のところshimesabaでは、Rolling windowのコンプライアンス期間で、Windows-based SL

                                                            SLOの運用のために OSS shimesabaの導入 - KAYAC engineers' blog
                                                          • これからはじめる 実践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

                                                              これからはじめる 実践SRE / SLO の監視をやってみよう
                                                            • 転職会議のKubernetes移行のあゆみ - LIVESENSE ENGINEER BLOG

                                                              こちらはLivesense アドベントカレンダー 2020 およびKubernetes3 アドベントカレンダー1日目の記事です。 こんにちは、転職会議のSREのかたいなかです。 転職会議では2020年の一年間をかけてインフラ基盤をECSからEKSに移行してきました。 この記事では構築したEKS基盤やECSからの移行の中で工夫した点を紹介します。 なぜEKS移行? 古くなっていたECS基盤を刷新する上で、ECSで再度作り直すのではなくEKSを選んだのは主に以下のような理由です。 IaCを更に推し進めGitOpsの考えを採用し、開発者がSREにレビュー以外で依存することなく主体的にインフラを変更できる状態を作るため ArgoやIstioといったKubernetesネイティブに開発されているツールを採用することでの恩恵を将来的に受けられるようにするため 純粋な技術的興味 採用を決めた当時は技術的

                                                                転職会議のKubernetes移行のあゆみ - LIVESENSE ENGINEER BLOG
                                                              • marnie0301 on Twitter: "EurekaでSREっていう職責を会社で担って数年、扱ってきたものが多すぎて頭を一回整理したくて、雑にSREのpracticeのMindMapを作ってみた。黎明期に色々扱ったものやデータ周りを除外して、組織が成熟して各種専任チーム… https://t.co/WWWQvj45ee"

                                                                EurekaでSREっていう職責を会社で担って数年、扱ってきたものが多すぎて頭を一回整理したくて、雑にSREのpracticeのMindMapを作ってみた。黎明期に色々扱ったものやデータ周りを除外して、組織が成熟して各種専任チーム… https://t.co/WWWQvj45ee

                                                                  marnie0301 on Twitter: "EurekaでSREっていう職責を会社で担って数年、扱ってきたものが多すぎて頭を一回整理したくて、雑にSREのpracticeのMindMapを作ってみた。黎明期に色々扱ったものやデータ周りを除外して、組織が成熟して各種専任チーム… https://t.co/WWWQvj45ee"
                                                                • SRE と Developer のコラボレーションを支える仕組み - スタディサプリ Product Team Blog

                                                                  こんにちは。SRE の @int128 です。 Quipper の SRE チームでは、Platform の安定運用や改善だけでなく、Platform を利用する Developer のサポートも重要な仕事と位置付けています。 SRE チームで工夫していることを紹介します。 Issue に記録を残す SRE チームでは課題や疑問などを気軽に相談してほしいと考えています。 そのため、Slack で気軽に SRE にメンションしてもらえる文化を作るように心がけています。 Slack で相談している例 一方で、同時に多くのメンションを受け取った場合、経緯の把握に時間がかかる、対応状況が分からなくなるといった課題があります。 例えば、Slack のやり取りを通して、ちょっと設定変更すればできるかも、検証してみようという話になることがよくあります。 Slack のスレッドだけでは、具体的な検証作業に

                                                                    SRE と Developer のコラボレーションを支える仕組み - スタディサプリ Product Team Blog
                                                                  • ZOZOMAT/ZOZOGLASSにおけるSLOの立て直しについて - ZOZO TECH BLOG

                                                                    はじめに こんにちは、計測プラットフォーム開発本部SREブロックの近藤です。普段はZOZOMATやZOZOGLASS、ZOZOFITなどの計測技術に関わるプロダクトの開発、運用に携わっています。計測プラットフォーム開発本部では、以前プロダクト単位でSLO(Service Level Objective)1を定めましたが、うまく活用できず、再度SLOについて運用方法を考え直すことになりました。本記事では、SLOの再導入から運用に向かう中で見つかった課題と、課題に対する対応策についてご紹介します。 目次 はじめに 目次 背景 要因分析 Problem Try Action Actionの実行 SLO設定時の段階分け 例:ZOZOMATの段階分け 課題の洗い出し 例:SLOがない事による課題(SRE視点) 目的の明確化 信頼性とはそもそも何か 一般的な信頼性 計測プロダクト UJの整理 SLOの

                                                                      ZOZOMAT/ZOZOGLASSにおけるSLOの立て直しについて - ZOZO TECH BLOG
                                                                    • SREとDevOpsの違いはなにか | sreake.com | 株式会社スリーシェイク

                                                                      SREとDevOpsの違いDevOpsとはSREとはDevOpsの実装としてのSRE継続的な改善の必要性組織を超えたコラボレーション変更管理と自動化計測の重要性非難のない文化開発速度の改善SREのことなら弊社にお任せください Webサービスの信頼性や価値の向上に用いられるアプローチ方法としてSRE(Site Reliability Engineering)というものがあります。システム開発側と運用側の溝を埋めるために生まれたこの手法ですが、従来のDevOpsとはどのような違いがあるのでしょうか。 本記事ではSREとDevOpsの違いについて見ていきます。 関連記事:「SREとインフラエンジニアの違いについて」 SREとDevOpsの違い SREとDevOpsの違いや関係性を知るには、Googleが提唱している「class SRE implements DevOps」の考えが最も明解でしょう

                                                                        SREとDevOpsの違いはなにか | sreake.com | 株式会社スリーシェイク
                                                                      • AI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想 / DICOMO2022 6A-1

                                                                        DICOMO2022 6A 統一セッション:クラウド 招待講演 https://tsys.jp/dicomo/2022/program/program_abst.html#6A-1 情報サービスの利用者に必要な機能を頻繁に加え続けながらも、いかに必要十分な信頼性を継続させるかが従前より課題となっている。この課題に対するひとつの回答とも言える、Googleが提唱した情報サービスの新しい運用形態であるSite Reliability Engineering(SRE)の普及が進んでいます。本発表では、SREの中核概念を整理した上で、AI時代に向けて、AIとの対話を軸にした未来の運用のあり方を構想します。

                                                                          AI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想 / DICOMO2022 6A-1
                                                                        • AWS勉強会レポート「サービスを動かし続ける為に何が必要か」 - Tech Do | メディアドゥの技術ブログ

                                                                          はじめに 初めまして!6月よりメディアドゥにJoinしたサーバーサイドエンジニアの角田です。 みなさんAWSは使ってますか? 私はとある社内システムのクラウドリフト案件で絶賛活用中です。 さて、先日AWS社ソリューションアーキテクトの八木さん(@ygtxxxx)協力のもと、同社シニアソリューションアーキテクトの大村幸敬(@yktko)さんに表題の勉強会を開いていただきました。 昨今当社でも新しい部署として立ち上げられたSREの話題が中心ですが、開発サイドの方にも非常に有益な内容でしたので概要をレポートしたいと思います! 内容 アジェンダは下記の通りです。 各章の内容や所感についてまとめてみましたのでご覧ください! ※ ⑤参考文献 は割愛 ①運用って何だ このセクションでは、「そもそも運用とは何なのか」をブレイクダウンしてご説明いただきました。 ユーザー視点でシステム運用について分解していく

                                                                            AWS勉強会レポート「サービスを動かし続ける為に何が必要か」 - Tech Do | メディアドゥの技術ブログ 
                                                                          • SREとは? Google Cloudがその基本を説明、JCBも導入/実践経験を紹介 (1/5)

                                                                            グーグル・クラウド・ジャパン(Google Cloud)は2022年8月29日、グーグルが提唱する「SRE(Site Reliability Engineering、サイト信頼性エンジニアリング)」に関する記者説明会を開催した。グーグルからSREの基本な考え方が説明されたほか、ゲストとして実際にSREチームを組成しているジェーシービー(JCB)も出席し、SRE導入と実践の経験を紹介した。 SREとは? システム運用チームとSREチームとはどう違うのか? グーグル シニアデベロッパーリレーションズ エンジニアの山口能迪氏はまず、SREとは「本番システムを信頼性高く開発/運用するための一連のプラクティスと心構え、および職務を指す」言葉だと説明する。現在のような変化の多い時代においては、頻繁なサービス開発/リリースや、ユーザーニーズの変動に応じた急なスケール変更などが求められる。ただし、それらは

                                                                              SREとは? Google Cloudがその基本を説明、JCBも導入/実践経験を紹介 (1/5)
                                                                            • SREはインフラ担当だけでなくチーム全体で取り組んでいくもの | はてなで働く cohalz にアンケート [#9] - Hatena Developer Blog

                                                                              こんにちは、Hatena Developer Blog編集部です。「はてなで働くエンジニアにアンケート」シリーズ、今回ははてなブログチームのSRE、id:cohalzに話を聞きました。 id:cohalzにアンケート はてなidとその由来を教えてください いつどんなきっかけで入社しましたか? 現在の仕事を教えてください チーム内の立ち位置を教えてください 1日の仕事の流れを教えてください 最近うまくいったことは何ですか? 最近うまくいってないことは何ですか? 普段大切にしていることは何ですか? はてなはどんな会社ですか? id:cohalzにアンケート はてなidとその由来を教えてください 読みは「こはる」と呼ばれることを想定しています。 読みとしては日本語としてありふれた名前にしつつも、idとしては被らないものにしたいという意図を持っています。 idはco + hal + zの3つの要素

                                                                                SREはインフラ担当だけでなくチーム全体で取り組んでいくもの | はてなで働く cohalz にアンケート [#9] - Hatena Developer Blog
                                                                              • 最近のSREチームと業務について - BASEプロダクトチームブログ

                                                                                こんにちは!! BASE株式会社 SRE Group Managerの富塚(@tomy103rider)です。 以前、以下のSREの求人票についての記事を公開してから多くの方とカジュアル面談でお話をさせていただく機会が増え、カジュアル面談の中でも「求人票ブログの記事見ました!」という声をいただき嬉しい限りです。ありがとうございます。 devblog.thebase.in そんなカジュアル面談の中でよくいただく質問があり、今回はその中から最近のSREチームについて、 チームで大事にしていることは? チームの働き方は? チームの業務は? この3つについて紹介したいと思います。 チームで大事にしていることは? 現在SREチームでは、 「信頼性=ユーザの期待値を超え続けること」としてこれを維持し続ける BASEの機能等々の価値を高めるための時間を多く作っていけるようにする が大事であると考えていま

                                                                                  最近のSREチームと業務について - BASEプロダクトチームブログ
                                                                                • Debugging Incidents in Google’s Distributed Systems - ACM Queue

                                                                                  June 6, 2020 Volume 18, issue 2 PDF Debugging Incidents in Google's Distributed Systems How experts debug production issues in complex distributed systems Charisma Chan and Beth Cooper Google has published two books about SRE (Site Reliability Engineering) principles, best practices, and practical applications.1,2 In the heat of the moment when handling a production incident, however, a team's act