TOPインタビュー障害対応を属人化させない。「全員インシデントコマンダー」体制を根付かせた、山本五十六の格言【NewsPicks SRE 安藤裕紀】 障害対応を属人化させない。「全員インシデントコマンダー」体制を根付かせた、山本五十六の格言【NewsPicks SRE 安藤裕紀】 2024年8月26日 ユーザベース NewsPicks事業 SREチームリーダー 安藤 裕紀 大手SIerで10年半エンジニア/アーキテクトとしてアプリケーション開発、インフラ構築、クラウド活用コンサルティングなど大企業の技術支援を行った後、2021年10月に株式会社ユーザベースに入社。プロダクト開発組織のSREチームでインフラや開発基盤を担当。シニアエンジニア、テックリードを経て、チームリーダーに。2024年からはプラットフォームエンジニアリングのグループマネージャーも兼務。 X Docswell GitHub
｜DMM inside
こんにちは、はじめまして。さくらインターネット株式会社の長野雅広（@kazeburo）です。Webの業界に入ったのは学生だった2000年頃で、キャリアは20年以上になります。おそらくこの業界でも長い方ではないでしょうか。20年の間にmixiやlivedoor、メルカリといった企業で働く機会を得て、どの職場でもサービスの裏側にあるインフラや、Webアプリケーションの運用を支える仕事、今ではSREと呼ばれるような業務に携わってきました。 そして今年の1月から、さくらインターネットにてクラウドを中心にサービスの開発を行っています。つまり、インフラやクラウドを利用して一般のお客様向けにサービスを作るという仕事から、クラウドを作ることを仕事にする、という選択をしました。 この記事では、どのような経験からSREとして働くようになったのか、また現職に至る選択をした経緯について語りたいと思います。加えて、
こんにちは。 KINTO テクノロジーズの DBRE チーム所属のp2skです。 DBRE（Database Reliability Engineering）チームでは、横断組織としてデータベースに関する課題解決や、組織のアジリティとガバナンスのバランスを取るためのプラットフォーム開発などを行なっております。DBRE は比較的新しい概念で、DBRE という組織がある会社も少なく、あったとしても取り組んでいる内容や考え方が異なるような、発展途上の非常に面白い領域です。 弊社における DBRE の取り組み例としては、あわっち（@_awache）による DBRE ガードレール構想の実現に向けた取り組みについてというテックブログや、今年の AWS Summit の登壇内容を是非ご覧ください。 今回の記事は、データベースに関する課題解決の事例として「Aurora MySQL でレコードが存在するのに
どんなことが起こったのか？ モノタロウのサイトの監視について レイテンシ監視 トラフィック監視 エラー監視 リソース監視 ログ トラブルシュートの進め方 発生検知 発生箇所の特定 根本原因の調査 強化 課題 おわりに SREチームの市原(@ichi_taro3) です。 モノタロウでは、www.monotaro.com という大規模なECサイトを自社で開発、運用しています。 Webアプリケーションの運用ではトラブルはつきものです。今回は、とあるトラブルシュート事例を軸に、どのように運用を改善しているのかについて紹介します。 どんなことが起こったのか？ あるとき、モノタロウのWebサービス全体でレイテンシ悪化やバックエンドAPIへのタイムアウトの増加が頻発したことがありました。 当然これらは歓迎される状況ではなく、すぐに開発者やSRE、インフラチームの担当者が集まり調査を開始しました。現象は
ゆるSRE勉強会 #1 でお話しさせて頂いたLTの資料です！ https://yuru-sre.connpass.com/event/292063/
こんにちは。SREのkyontanです。Rubyが大好きなのでRubyの話をします。ちなみにリクルートはRubyKaigi 2024へGold Sponsorとして協賛しています! *1。ぜひ沖縄でお会いしましょう。 これはあるアプリケーションのメモリ消費量を示すグラフなのですが、まさかgemを入れ替えるだけでこんなに嬉しい変化が見られるとは思っていませんでした。今日はそんなgemの話をします。 話は遡って2023年4月のある日、インターネットを眺めていたところ、ShopifyがpitchforkというOSSを公開したという情報が目に留まりました。 調べてみると、どうやら著名なRackサーバー実装の1つであるunicornの派生版であり、メモリ使用量の削減に特化しているらしいのです。 github.com これはスタディサプリ小中高のあのリソースドカ食いマイクロサービス第一位である api
公開日 2024/08/16更新日 2024/08/15今日から始める「システム監視」。大量トラフィックのシステムを安定して運用する知見をアソビューのSREに学ぶ はじめにアソビュー株式会社では、アソビュー！という電子チケットを販売するサイトを運営しています。 システムを安定稼働させるためには、日常的にシステムの状態を監視して、問題があれば調整するというプロセスを繰り返すことが必要不可欠です。本記事では、アソビュー株式会社において、どのような体制でこの安定稼働を実現しているかということを書くことによって、同じようにシステムを安定稼働させたいと日々考えておられる方々を想定読者として、そのノウハウを共有しようと思います。 安定稼働をするために必要な要素 人間の健康管理のために必要なことシステムを安定稼働するために必要なことというのは、人間が健康に生きていくためにやっておいたほうがいいことと共通
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のマネージドサービスを組み合わせ
SREチームの長田です。 KAYAC Advent Calendar 2022の11日目の記事です。 アプリケーションから何かしらの外部サービスを利用するとき、そのサービスを利用するためのAPI Keyなり秘密鍵なりの秘密情報を保持することになります。 暗号化したものをファイルとしてアプリケーションに持たせたり、 Amazon Web Services(AWS)ならAWS Secrets Managerや AWS Systems ManagerのParameter Store(SSM Paramater Store)に保存したものを実行時に読み込んだりするでしょう。 これらの秘密情報、どこから来たのかわかりますか？ どこから来た秘密情報なのか 秘密情報を使って出どころを調べられるのであれば問題はないでしょう。 # 例えばAWSのIAM User Credenntialsとか $ AWS_A
from: 合同会社DMM.com CTO室 to: フリーランス DMMどうだった 良かった。 なにしてたの 新卒で入社し、3年ぐらいクラウドをいい感じにするエンジニアしてました。 新規サービス立ち上げたり、リプレイスしたり、リファレンスアーキテクチャ作ったり、スクラムマスターしたり、とかとか。 あと80回ぐらい社内勉強会（勉強会・LT会・Podcast）主催したりもしました。 新卒入社 > プラットフォーム部 > CTO室 > SRE立ち上げ > CTO室 > 退職 詳しくは「転職先募集 - y-ohgi's blog」でいろいろ書きました。 なんで辞めたの 理由としては新しく入ってきた上司（x3人）と折り合いがつかなかったことと、折り合いがつかなかった結果やりたいこと（全社のクラウド活用をいい感じにすること）ができなくなったため辞めました。 特に何かが嫌になったとかではないです。 よ
スクワッド体制における留意点として、「Spotifyは "Spotifyモデル "を使っていない [3]」で以下のように述べられているように、単に方法論を真似るのではく、自分の組織と向き合い、学習して、進化し続けることが大切であると思います。READYFORにおいても日々、組織体制について議論し、改善を進めています。 ビジネスユニット、部門、チーム、マネージャーは、Spotifyの失敗した方法論に固執してはいけません。彼らはSptifyのモノマネよりも効果的に組織構造の役割と責任を伝えることができるのです。 あなたがSpotify Modelを見つけたのは、自分のチームをどのように構成するかをいつも考えていたからでしょう。でもここで止まってはいけません。学習を続けてください。 1-2. READYFORのスクワッド体制 READYFORの場合、どのようなスクワッド体制を敷いているか？ ひと
はじめに こんにちは、情報システム部 SRE 橋本です。 普段はクラウドエンジニア(SRE)としてチームリードをしています。興味関心がインフラ、Observability、SRE、Security、Golangといった分野であり、 Japan Google Cloud Usergroup for Enterprise(Jagu’e’r ジャガーと読みます)でObservability/SRE分科会のオーナーを担当させていただいております。その縁もあって先日Innovators Hive at Cloud Next 2022でコミュニティ運営についてお話をさせていただきました。 この記事では現在チームリードをしていてビルドアップ中でもあるSREチームについて考えていることをお話したいと思います。 また、このSREチームについてのインタビュー記事も掲載いたしました。メンバーやチームの雰囲気を伝
ソーシャル経済メディア「NewsPicks」の運営・開発を行う株式会社ニューズピックスは、近年、DX（Developer Experience：開発者体験）の向上に注力しています。CPO、CTO、VP of Eと、3名のエンジニアがボードメンバーに名を連ねる同社のDXへのこだわりは徹底しており、「DX向上」は経営における重要項目としても取り扱われています。 背景にあるのは、エンジニア組織をスケールさせる、という強い意思。近年、同社の開発組織は著しく拡大していますが、今後、さらにエンジニアを迎え入れるためには、良質なDXが得られるシステム、組織であることが不可欠だと考えているといいます。では、肝心要のDX向上はどのようにデザインされ、実行されているのでしょうか。 本稿の読者も含め、世のエンジニアの方々に向けて同社のDXをプレゼンテーションし、応募を促進するべく、CTOの高山温さん、そして最前
【SREチーム ブログリレー2回目】 お疲れ様です。エンジニアリンググループ、コアSREの山本です。 前回ブログリレー1回目の記事で大量メール送信のために基本設定について書かせていただきました。 www.m3tech.blog 今回はそれを受けて構築したサーバで実際に発生したいくつかの問題、その問題への対処といったものを書かせてください。 エムスリーのメール送信で発生した問題とその対策 特定のメールサーバからの突然のメール拒否 メールの翌日までの滞留 TLS問題 メールがどうしても迷惑メール扱いされるという苦情 postfixのメール処理とステータス メールログの監視 まとめ We are Hiring! エムスリーのメール送信で発生した問題とその対策 実際にここ一年あたりの間に発生した問題とその問題への対応を記述していきたいと思います。postfixを利用して送信していますので設定はpo
10倍に膨れたAWS運用費をどう減らす？ ユーザー急増のnoteが挑む「コスト削減作戦」の裏側（1/2 ページ） 文章やイラストなどを投稿できるコンテンツ配信サービス「note」。コロナ禍以降は巣ごもり需要にも後押しされてユーザー数が急増しており、2020年には月間アクティブユーザー数が前年同期比で3倍以上に増えたという。しかし同時にトラフィック量も急増したため、運営元であるnote社のシステム部門ではその対応に追われた。特にクラウドサービスの利用コストの高騰は、大きな悩みの種だった。 noteのサービスを支えるシステムは、全てAWS（Amazon Web Services）のクラウドインフラ上で構築・運用しており、トラフィック急増でその利用コストは約10倍にまで膨れ上がった。 このままトラフィックがさらに増えれば、コストが利益を食いつぶすことにもなりかねない。そこでシステムの運用や品質管
2022年6月2日に開催された、Observability Lounge 「『監視』の原則と変化」という勉強会での発表資料です https://forkwell.connpass.com/event/247721/
ソフトウェアデリバリーのパフォーマンスを示す4つの指標であるFour Keysについて、指標の成り立ち、改善する意義、各指標への向き合い方、近年の動向などを網羅的に解説しました。
ハイクラス求人TOPIT記事一覧Terraformを使って学ぶーAWSにインフラを構築するIaCの基本と、SREが実務で役立つ機能とエコシステムを徹底解説 Terraformを使って学ぶーAWSにインフラを構築するIaCの基本と、SREが実務で役立つ機能とエコシステムを徹底解説 Terraformは、パブリッククラウドのインフラ構築と自動化のツールとして、IaCのデファクトスタンダードとなっています。この記事では、AWS（Amazon Web Services）を活用するハンズオンを通してTerraformの動作を理解し、実務にもとづいて役立つ機能や便利なエコシステム、さらにSRE視点の事例を紹介します。アソビュー株式会社でSREユニットリーダーを務める鈴木剛志さんを中心に6名のメンバーによる共同執筆です。 アイキャッチ画像 アソビューでは、インフラストラクチャーの変更管理にTerrafo
概要 ソーシャル経済メディア「NewsPicks」SREチームの中川です。 皆さんはバッチ処理基盤はどうされていますでしょうか。 NewsPicks では少し前まではそれらをEC2、cronの組み合わせで動作させていました。 何年も前からこの仕組みだったのですがSREとしてはEC2の面倒見るのも手間ですし、それ以上にcronを変更する際のオペレーションミスが目立ったのが懸念点でした。 その為、まずはAWSマネージド化するための基盤を整備し、その後バッチアプリを載せ替えていくようにしました。 対応前の基盤構成 同じSREチームの安藤さんが CloudNative Days Tokyo 2023 で登壇されたときの資料をお借りします。 ご覧の通り、大体のサービスはマネージド化していましたがバッチ基盤だけは旧来のままEC2インスタンスを利用していました。 10年モノのサービスのインフラを漸進的
tl;dr オブザーバビリティにはあなたの直感よりもお金がかかるかもしれない。でもそれはアジリティを上げるために必要なコストである。同時にオブザーバビリティ関連ベンダーには、それらをリーズナブルに提供してもらうことを期待します。 オブザーバビリティ・エンジニアリング輪読会 8月からVPoEになりました。id:Songmuです。 社内の勉強会で輪読形式でオブザーバービリティ・エンジニアリングを読んでいます。毎週30分、参加者の中から発表者を割り当て、1~2章を読み進めるスタイルです。 ちなみに、ヘンリーではActive Book Dialogue(ADB)というフォーマットも取り入れて輪読会が運営されています。社内で同時並行で数本走っており、先日、CEOの逆瀬川が書いたソフトウェア見積もりに関する輪読会も同様の形式で実施しています。 発表者は、事前に社内のNotionにその章のアウトラインや
「AWS CDKに興味を持ったけれど、なかなかコードを書き始められない」と悩んでいませんか？CDKは簡単に始めることができますが、メンテナンスしやすく、壊れにくいコードを書くためには覚えておきたいプラクティスがあります。しかし、すべてのエンジニアがインフラ構築やプログラミングに精通しているわけではなく、…
ビザスクさんにお誘いいただき、企業内新規事業担当者の方などに向けて、リサーチに関するお話をしました。 https://visasq.co.jp/seminar/research0728 調査、正しく使うと楽しいし、ためになるよ、というお話をしています。 30分くらいでお話したので、同じような講…
Findy主催のイベント「なぜ話題？Platform Engineering最前線 〜いま注目を浴びている理由とは〜」 https://findy.connpass.com/event/298961/ でお話しした資料です
こんにちは。 株式会社ココナラのインフラ・SREチーム所属の かず です。 システム運用において、有事の際に迅速かつ適切なシステム稼働状況の確認は欠かせません。 その手段の1つとして、ログの調査や分析の効率化は切っても切れない関係です。 システムが成長するにあわせ、ログの種類や量が多くなり、結果としてログの調査や分析が難しくなるのはよくある話かと思います。 弊社でもサービスのグロースに伴って、ログの種類や量が多くなり、結果としてログの調査や分析で課題を抱えていました。具体的には以下の2点です。 ログから原因調査を行うには、複数ログを横断・突き合わせが必要 ログの追跡に必要な情報がログに出力されない場合がある そこで、課題への対応としてログ調査基盤の構築を行いました。 本記事では背景や苦労したこと、効果についてご紹介します。 複数ログの横断調査実現に向けて ログ調査基盤の構築 苦労したこと
はじめに こんにちは、Cloud Operations担当者です。このたび私が監訳者として関わった「SREの探求―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践」という本がオライリー・ジャパン社より出版されました。本日より書店ならびに各社オンラインストアでご購入いただけます。 SREの探求 ―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践 オライリージャパンAmazon 電子書籍版についてはオライリー・ジャパンのサイトよりePub、PDFの各種フォーマットにてご購入いただけます。 www.oreilly.co.jp TL;DR 「SREの探求」はGoogle以外の企業でSREの導入がどのように行われているのかを記したエッセイ集です。スタートアップからエンタープライズまで、多くの事例を楽しみながら読める一冊だと思います。ボリュームに圧倒されるかもし
タレントマネジメントシステムを提供する株式会社カオナビでは、サービスをSaaS型にシフトするにあたってAWS（Amazon Web Services）を全面的に採用し、サーバレスの基盤開発でもAWSのマネージドサービスを積極的に活用しています。 そのベースにある「運用しない運用」という言葉の意図や、計測・監視の取り組み、アプリケーション開発の経験も活用できる「自走するインフラ組織」について、インフラグループの大久保智之さんと新井健さんに聞きました。 ※この記事は株式会社カオナビによるSponsoredContentです。 AWSへの移行から技術的な挑戦を進める サーバレスを推進して温かみある手順から脱出 開発の経験も生かしたアプリケーション監視と指標 自動化の原則は自走と自律 カオナビではエンジニアを積極募集しています！ AWSへの移行から技術的な挑戦を進める ── プロフィール（後掲）を
Infra Study Meetup #3 「SREのこれまでとこれから」の発表資料です https://forkwell.connpass.com/event/176885/
第1回 Platform Engineering Meetupで発表した資料です。 #PFEM
GoogleのSREとSecurityによるBuilding Secure Reliable Systems という本の中で「Zero Touch Production (ZTP) 」という考え方が紹介されていた．これはインフラの権限管理やインフラの構築そのものの指針となる概念であり，自分がそうあるべきだとずっと思ってきた考え方でもある．これはどのような考え方なのか?をこれまでの歴史を踏まえて具体的なツールや事例とともにまとめておく． Zero Touch Production Building Secure Reliable Systems においてZero Touch Production (ZTP) は以下のように定義されている． The SRE organization at Google is working to build upon the concept of least
現在 estie では、デプロイの改善・統一に取り組んでいます。複数プロダクトのそれぞれの技術スタックが大きく違う中、どう考えたら効率的なデプロイを組めるのか。2024年のデプロイの原則について、あらためて考えてみました。
最近の開発では、CI/CD、自動テスト、継続的テストが当たり前となっていますが、その影響で、それらのCI/CD方針、テスト方針と、Git等のバージョン管理のブランチ方針をどう連携させるかが、定番の課題になっていると感じています。 今回は、このブランチ方針、CI/CD方針、テスト方針を連携させて、開発の品質とスピードを向上させるアプローチについて解説します。 結論から言うと、要点は以下の二つとなります。 バージョン管理のブランチ方針は、CI/CD方針、テスト・QA方針と不可分であり、連携を考えながら方針立てする必要がある ブランチ方針の工夫で、CI/CD、テスト・QAの開発インフラリソース消費を削減でき、本当に重要なポイントに開発インフラリソースを投入できる。これにより、限られたリソースでの高品質・高スピードの両立を支えられる 背景：開発インフラの進化が全てを解決すると楽観視していた発展期
SRE NEXT 2023で発表した内容です。 https://www.youtube.com/live/c_oMpshssRg?si=LfArG3rX4VXPJ30H&t=27643
※この記事は 開発生産性 Advent Calendar 2022 のカレンダー2の13日目の記事になります。 前回は1日目は hiroshinishio さんの 『より筋肉質なチームにするために、開発者が見るべき21のDevOpsアウトプット指標』 で、個人的には指標それぞれの分析や改善の方法が書かれていて勉強になりました。 こんにちは。 モノタロウで主に DevOps エンジニアとして活動している伊藤です。 休日はジムに節制した食事、サウナと健康を意識するおじさんとしても活動しています。 （最近だと渋谷の改良湯さんのサウナと外気浴スペースの具合が最高でととのいました） 今回は DevOps Four Keys*1 （以降 4keys と呼称） というソフトウェア開発チームのパフォーマンスを示す4つの指標を導入し、部門の目標として掲げたここ1年の取り組みを紹介できればと思います。 背景
鍵がいっぱいあるよこの記事は Eureka Advent Calendar 2021 の 13日目の記事です。 はじめにこんにちは、エウレカ SREチーム のハラダです！ 2020年頃から今年にかけて、 エウレカのSREチームとSecurityチームではAWS IAMのセキュア化を注力ポイントのひとつとして、継続的に取り組んできました。 本記事では、その実践から学んできたIAM管理で守るべき大原則および、具体的にどうやってセキュアな理想像に近づけてきたか、今後の方向性などを話したいと思います。 Why “IAM” so important ?そもそもなんでIAMが注力ポイントなの？と疑問に思われる方もいるでしょう。 クラウドの大きな強みである「すべてをAPI経由で操作できる」という性質ゆえに、IAMは大きなAttack Surfaceでもあります。 Gartner社の予測によると、2023
https://fortee.jp/yapc-hiroshima-2024/proposal/1e9fbacd-5a50-43ef-87f1-490e85448f17
2020/08/31開催の、Infra Study Meetup #5「企業に必要とされているインフラ技術とこれから」のLTでお話した内容です。 https://forkwell.connpass.com/event/183909/
こんにちは。 SRE の @suzuki-shunsuke です。 Terraform Monorepo に対する Renovate の大量の Pull Request を処理するための技術について紹介します。 背景 過去ブログで何度か紹介しているように、弊プロダクトでは Terraform の Monorepo を管理しています。 先日、 CI を AWS CodeBuild から GitHub Actions + tfaction に移行しました。 blog.studysapuri.jp working directory (state) の数は 400 近くあり、 working directory ごとに以下のような tool のバージョンを管理しています。 Terraform Terraform Provider tflint tflint plugin tfsec etc これ
Cloud Native Days Tokyo 2020
先日NewRelicの清水さんにマンツーマンでオブザーバビリティの話をきかせてもらえるという貴重な経験をした。長年アプリケーションレイヤーも含んでシステム運用の経験があると「あるある」な話なのだが、次のようなことが起こる。 何か不具合や障害が起こる 該当時刻のエラーログなどを見るが情報が少なく、原因を特定する決定打に欠ける 次回、また同じことが起こったときには原因を特定できるように、printfデバッグするコードを大量に埋め込んだバージョンに更新して、デプロイする もう一度起こるのを待つ これは最初の状態が「オブザーバビリティに欠けた状態」だったと言える。めちゃ納得してEnter Sandmanくらいヘドバンして頷いてしまう。 僕の経験上このようなケースを避けるために良い結果を出してきたのは、Javaの例外が出た箇所でスタックトレースを取得しておくことだ（僕らは単にログファイルに吐いておい
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く