SRE Magazine - 001号（2024/04/01）
巻頭言：SRE Magazineを始めました 書いた人：しょっさん（ @syossan27 ） SRE Magazineの発刊についての想いなどを書いてます。 ばばさんがお勧めする「SRE入門」と「SRE入門の入門」に効く書籍や文章 書いた人：ばば/netmarkjp さん（ @netmarkjp ） SRE入門に効く書籍や文章を紹介しています。 非常時の可用性をフィーチャーフラグで保つアイディア 書いた人：iwamot さん（ @iwamot ） アクセス急増などの非常時でも可用性を保つ手法に「緊急レバー」があります。この記事では、緊急レバーの実装にフィーチャーフラグを用いるアイディアを提示します。 SIEMってサイトの信頼性向上に寄与するの？ 書いた人：Yuta Kawasaki（ゆーた）さん（ @yuta_k0911 ） SIEM on Amazon OpenSearch Servi
Meaningful availability | the morning paper
the morning paper a random walk through Computer Science research, by Adrian Colyer Made delightfully fast by strattic Meaningful availability, Hauer et al., NSDI’20 With thanks to Damien Mathieu for the recommendation. This very clearly written paper describes the Google G Suite team’s search for a meaningful availability metric: one that accurately reflected what their end users experienced, and
エンジニアのためのSRE論文への招待 - SRE NEXT 2023 - ゆううきブログ
この記事では、2023年9月29日に開催されたSRE NEXT 2023 IN TOKYOでの講演の概要に加えて、講演では触れられなかった部分の補足と、発表を終えての後記、最後にSRE NEXT全体の感想を書きました。 SRE NEXT 2020の基調講演に招いていただいたところから始まり、昨年のSRE NEXT 2022の公募セッションでも発表し、今回で3回目の発表になりました。今回の講演は、SRE NEXTの「NEXT」と価値観の一つである「Diversity」を踏まえて、自身のエンジニアと研究者の両方の経験を活かして、SREを深く実践する上で、技術論文を探して読むアプローチを提示するものです。昨今の国内のSREコミュニティでは組織的実践に主な関心が移っている状況と対比させて、コンピュータサイエンスに基づく技術的挑戦の可能性を示唆する意欲的な講演を目指したつもりです。 この講演での主要
OSS 『Prepalert』 の紹介 - KAYAC engineers' blog
SREチームの池田です。 この記事が出ている頃には私は SRE Next 2023 に参加しているでしょう。 SRE Next 2023での私のセッションは『Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵』です。 このセッション中で話す仕組みはOSS『Prepalert』というもので実現しているのですが、今回の記事ではセッションの裏番組的にOSS『Prepalert』の紹介をします。 github.com Prepalertについては以前にTechBlog上で記事を書いているので、そことの差分を中心に紹介します。 techblog.kayac.com 3行でまとめ OSS『Prepalert』はMackerel Webhookを受け取って、各所に情報を問い合わせてMackerelのアラートのメモに貼り付ける仕組み そろそろ運用歴2年でv1リ
9/29(金)開催のSRE NEXT 2023 IN TOKYOにカヤックSREの池田が登壇します！ - KAYAC engineers' blog
SREチームの長田です。 9/29(金)に開催される SRE NEXT 2023 IN TOKYO にカヤックSREチームの池田が登壇します。 sre-next.dev TrackBで15:50から、『Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵』というタイトルで登壇予定です。 自作OSSの導入によるWarningアラート対応の改善について、カヤック社内の事例を踏まえて紹介させていただきます。 前日のアナウンスになってしまいましたが、オンラインチケットはまだ取得可能です。 興味のある方はぜひご参加ください。 カヤックではトイルを削減したいエンジニアを募集しています！ hubspot.kayac.com
SRE不在のチームに入って2カ月でやったこと - 負荷試験から始めるプラクティスの導入
本記事は、TechFeed Experts Night#17 〜 事例で学ぶSRE 〜 ツール、プラクティスから組織づくりまでのセッション書き起こし記事になります。 イベントページのタイムテーブルから、その他のセッションに関する記事もお読み頂けますので、一度アクセスしてみてください。 本セッションの登壇者 セッション動画 面白法人カヤックでSREをしています、藤原俊一郎(Twitter: @fujiwara)です。個人的な活動として、ecspresso(Amazon ECSのデプロイツール)やlambroll(AWS Lambdaのデプロイツール)を作ったり、先ほどのセッションで登壇された馬場さんと共著で達人が教えるWebパフォーマンスチューニング(通称「ISUCON本」)を出版したりしています。 SRE不在のチームに加わった背景 SREが不在だったチームの例として、弊社のSMOUTという
障害対応プロセスを改善してきた話 - 10X Product Blog
障害プロセスを改善してきた話 こんにちは。Reliability & Securityチームに所属するSoftware Engineerの@sota1235です。 今回は10X内における障害対応プロセスの改善をご紹介します。 今が完成系ではなく道半ばではありますがこの半年 ~ 1年で大きく進化したので同じくらいのフェーズの会社で困ってる方がいたら参考にしてみてください！ ちなみに私ごとですが去年の5/26にこんな投稿をしてたのでやっと伏線を回収する形となります(※ ドヤ顔ではありません)。 目次 こんな感じで紹介していきます。 目次 障害対応プロセスの改善に踏み切った背景 課題1. 障害の報告フォーマットが統一されていない 課題2. 障害報のクオリティの差異が大きく後から振り返りが難しい 課題3. 障害対応者が特定の人に偏る 第一の改善 改善1. 障害報告書のフォーマット更新 改善2. S
Amazon ECSのタスクを常に新鮮に保つ仕組みをStep Functionsで - KAYAC engineers' blog
SREチームの藤原です。今回はAmazon ECSのサービス内のタスクを定期的に再起動することで、日々のメンテナンスコストを削減する話です。SRE連載 3月号になります。 3行でまとめ ECS Fargateのタスクは時々再起動が必要 人間が対応するのは面倒 Step Functionsを定期実行して常に新鮮なタスクに入れ換えて予防しよう ECS Fargateのタスクは時々再起動する必要がある ECS Fargateでサービスを運用していると、数ヶ月に一度ほどの頻度でこのようなお知らせがやってきます。 [要対応] サービス更新のお知らせ - AWS Fargate で実行されている Amazon ECS サービスの更新が必要です [Action Required] Service Update Notification - Your Amazon ECS Service Running
ヤフーが実践するプロダクション環境でのカオスエンジニアリング
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog 突然ですが、みなさんへ質問です。「今この瞬間にシステム障害が起こったら、自信を持って対処できますか？」システム運用者であれば、誰しもが考えたことがある内容かと思います。障害の影響範囲がどの程度なのか、ユーザーアナウンスの必要の有無、そして自動復旧のメカニズムが正しく動いたか。そのあたりが気になるポイントなのではないでしょうか。単純な質問ではありますが、とても考えることが多い不安な質問です。 システムは動いて当たり前と思われがちですが、実際は動いている方が奇跡、壊れて当たり前、という点はエンジニアのみなさんなら共感していただけると思います。どうやったら障害にアプローチできるか、ヤフーで取り組んでいるカオスエンジニアリングについて紹介
SRE連載が始まります！ - KAYAC engineers' blog
あけましておめでとうございます。SREチーム(新卒)の市川恭佑です。 カヤック技術ブログでは本記事が2023年初エントリですが、Happy Lunar New Year!の方が違和感のない時期になってしまいました。 本年、新たにカヤックSRE連載と題した企画を始めるので、概要についてご報告します。 連載企画を始める経緯 カヤックの技術ブログといえば毎年恒例のアドベントカレンダー企画が人気ですが、これは12月限定のため、それ以外の時期にブログの更新が激減する傾向がありました。 ブログ過疎化の対策として、カヤックでは去年からSREチームで毎月1本のペースでブログ記事を出していました。 実のところ、内部的にはこれを「SRE連載」と読んでいました。 「とりあえずやってみよう」というノリで始まった連載でしたが、結果的には「12月を除くすべての期間において記事を出す」という実績を作れたので、本年は正式
Enterprise Roadmap to SRE - Google - Site Reliability Engineering
Google が過去に出版した 2 冊の書籍「Site Reliability Engineering」と「The Site Reliability Workbook」は、サービスライフサイクル全体への取り組みによって、組織がソフトウェアシステムの構築、展開、監視、保守を成功させる方法と理由を示しています。本レポートでは、Google Cloud Reliability Advocate の Steve McGhee と Google Cloud Solutions Architect の James Brookbank が、組織で SRE を導入する際にエンジニアが直面する特定の課題について深く掘り下げています。 SRE の普及にもかかわらず、多くの企業では SRE に対する当初の熱意と、その採用の度合いの間に大きな隔たりが生じています。本レポートは、プロダクトオーナーや信頼性の高いサー
一人に頼らないSREチームの体制づくりを目指して｜Kurashicom Tech Blog
こんにちは。エンジニアの佐々木です。 先日開催したミートアップにて、カヤックの藤原さんを交えてクラシコムのSREについてお話をさせていただき、1つ目のトークテーマ「インフラ強化に向けた具体的な取り組み」について記事を書かせていただきました。 この記事では、２つ目のトークテーマである「一人に頼らないチーム体制づくりを目指して」について紹介します。 SREの必要性SREチームの話をする前に、この後の話がイメージしやすくなるよう、開発組織としては規模が小さいクラシコムにおけるSREの必要性について述べたいと思います（前回のブログに引き続きいきなりイベント当日にお話したことではなくすみません…） まずSREとは何かというのを改めて確認しておくと、SREとはサイト信頼性エンジニアリングの略で、信頼性の高い本番環境システムを実行するための職務、マインドセット、エンジニアリング手法のセットであると発祥元
「北欧、暮らしの道具店」インフラ構成の変遷、5年間の課題と取り組み｜Kurashicom Tech Blog
こんにちは。エンジニアの佐々木です。 先日12/6、弊社イベントにてカヤックの藤原さんを交えてクラシコムのSREについてお話をさせていただきました。 当日は96名と多くの方にお申し込みいただきありがとうございました。1時間半があっという間で、時間の関係でお話できなかったことも多々ありました。改めてではありますが、記事にて当日の内容含め話せなかったこともご紹介したいと思います。 当日のテーマは「インフラ強化に向けた具体的な取り組み」と「一人に頼らないチーム体制づくりを目指して」という2つでした。 この記事では前半の「インフラ強化に向けた具体的な取り組み」について紹介します。北欧、暮らしの道具店のインフラ構成の変遷を追いつつ、その時々の課題や実際の取組みについて説明していきます。 5年前(2017年5月頃)のインフラ構成エンジニア3人で作った月間1600万PVのECサイト 「北欧、暮らしの道具
運用中のサービスに負荷試験を導入した事例の紹介 - KAYAC engineers' blog
SREチーム(新卒)の市川恭佑です。今回は、Tonamelという自社サービス(Web)において負荷試験を導入した事例を紹介します。 このエントリは「先送りされがちな負荷試験の導入について心理的なハードルを下げる」ことを目的としています。 そのため、事例紹介と銘打っていますが、列挙される事実の独立性よりも文脈性を優先しています。 表現が少し冗長に感じるかもしれませんが、負荷試験について距離感を感じている方は是非お付き合いください。 負荷試験を導入するに至った経緯 Tonamelは、本格的なリリースから5年以上という、比較的長い運用歴を持つサービスです。 まず、何故このタイミングで負荷試験を導入することになったのかについて、その経緯を説明します。 ポストモーテムによる気づき（文化的な土台） 今年の3月に公開されたエントリにもあるように、カヤックでは着実にポストモーテム文化が浸透しつつあります。
EKSからECSに移行して開発運用コストの削減を図る - KAYAC engineers' blog
SREチームの長田です。 今回はカヤックで運用している「まちのコイン」というプロダクトのアプリケーション基盤を Amazon EKS(以下EKS)からAmazon ECS(以下ECS)に移行したはなしをします。 まちのコインとは coin.machino.co www.kayac.com まちのコインはカヤックが運営している、デジタル地域通貨を使ってその地域のコミュニティを活性化させるサービスです。 2019年11月から実証実験を開始し、翌年2月から正式リリースされました。 2022年9月現在、20の地域に導入されています。 一般ユーザーが使用するクライアントアプリと、導入地域の運営団体が使用するブラウザ用の管理画面、 それらにAPIを提供するRailsサーバーアプリがあります。 データベースはAmazon Aurora PostgreSQL、 その他AWSのマネージドサービスを組み合わせ
SLOの運用のために OSS shimesabaの導入 - KAYAC engineers' blog
カヤックSREの池田です。今回は、カヤックのプロダクトの一つ『Tonamel』で導入したエラーバジェット算出ツール shimesabaの話をします。 shimesabaとは？ github.com shimesabaは監視サービスであるMackerelを用いて、エラーバジェットを計算しサービスメトリックとして投稿することでSLI/SLOの運用を助けるツールです。 このツールを用いることで、以下のようなグラフが得られます。 この図の上部は、エラーバジェットの使用率=信頼性の損失率の推移を表すグラフになっています。 この図の下部は、エラーバジェットをいつ？どのくらい？損失したのかを表すグラフになっています。 一言で、エラーバジェットと言ってもいくつかの計算方法が存在します。 今のところshimesabaでは、Rolling windowのコンプライアンス期間で、Windows-based SL
Don't Use Kubernetes, Yet
Early-stage startups shouldn't run on Kubernetes yet. But eventually, growth-stage and large companies should be running on Kubernetes in some form. Kubernetes Maximalism doesn't mean one-size-fits-all. Infrastructure should progressively grow with your workloads and team. How can you choose the right technology now so that you can maximize growth and minimize pain later when you inevitably outgro
「SRE NEXT 2022」にSREチームの藤原が登壇します - KAYAC engineers' blog
SREチームの長田です。 5/14(土)・5/15(日)に開催される「SRE NEXT 2022」にカヤックSREチームの藤原が登壇します。 sre-next.dev 「1年間のポストモーテム運用と、そこから生まれたツールsre-advisor」というタイトルでポストモーテムの運用と、 そこから生まれたツールについて紹介させていただきます。 sre-next.dev カヤックではSREが関わっている社内の複数プロダクトで、ポストモーテムを2020年末から運用してきました。 社内には多数のプロダクトがあるため、エンジニアは自分が関わっているもの以外の事故や事例に疎くなりがちでした。ポストモーテムの運用を通して、それがどう変わっていったかを紹介します。 ポストモーテムからは、普段は問題なく動いていても高負荷時や長期間の運用で問題になる、インフラやミドルウェアの設定が要因として見つかることもあり
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「北欧、暮らしの道具店」を支えるインフラ技術
SRE座談会 - 株式会社はてな
