「システム運用の基本と戦略」についてただまとめる
23卒でバックエンドエンジニアをしているたかしゅんです。（@1341Shun） 先日、株式会社サイバーエージェントAI事業本部の2024年度 エンジニア新卒研修でシステム運用に関する講義を行いました。 そこで話した内容とスライドを完全公開したので、内容について解説します。 90分の内容のため、かなり長いですが、個人的にぜひ一読して欲しい内容になっています。 実際の資料はこちらになります↓ 自己紹介 こんにちは、たかしゅんと言います。2023年度入社で今年で２年目になります。株式会社サイバーエージェントのAIオペレーション室で新規立ち上げをやっております。 入社して最初に広告プロダクトに配属し、PipeCDの導入などのDevOps業務を中心に行なっておりました。 記事もあるのでもしよろしければ、ご覧ください。 2月中旬からAIオペレーション室に移動し、新規立ち上げのインフラ環境の構築からCI
Datadog→New Relicの移行を決めた際のADRを公開します！
はじめに レバテック開発部、SREチームに所属している金澤です。 弊社開発部では、Datadogで行っていた監視からNewrelicを用いたオブザーバビリティへの移行を行う決定をしました。 そして、なぜオブザーバビリティを採用したのか、DatadogからNewrelicへ移行したのかといった意思決定をADRとして記録し、社内に展開しています。 今回はこのADRの内容を公開します！ ※本記事はNewrelic、Datadogを肯定、否定するものではございません。 ADR コンテキスト 事業軸 レバテックの事業戦略は事業ポートフォリオ構想に従っている 既存の事業を拡大させながら新規サービスを生み出し続ける 事業ポートフォリオ構想 開発軸 事業領域の大きさ、深さが拡大し必要なドメイン知識が肥大化 スケーラビリティとアジリティの担保が困難になってきた バグ、障害の発生 レビュー工数の増加 新規参画
家族アルバム みてねで直面してきた技術的負債 / MIXI KAG 2024
2024.3.22（金） SRE観点での技術負債 懺悔会 2024 https://mixi.connpass.com/event/312191/
エンジニアのための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コミュニティでは組織的実践に主な関心が移っている状況と対比させて、コンピュータサイエンスに基づく技術的挑戦の可能性を示唆する意欲的な講演を目指したつもりです。 この講演での主要
AWSの開発環境の利用時間をGoogleカレンダー連動させたら開発チームが自由に使えてコスト70%削減！！ - Uzabase for Engineers
こんにちはNewsPicks SREチームの美濃部です。 NewsPicksのSREのミッションの1つに「コストを適正化する」というものがあります。サービスの規模拡大に比例してインフラコストが増えないようにし、売上に対するコストの割合を低く維持していくのがミッションになります。 今回はこのミッションに対するアクションとして開発環境のインフラコストを適正化した話をします。 NewsPicksの開発環境について 開発環境のコストをどうやって適正化したか 稼働時間対応を実現する仕組みについて 実際どれくらい削減できたのか まとめ NewsPicksの開発環境について まず、NewsPicksの開発環境について概要を説明します。 インフラ基盤は本番環境と同様にAWSを利用しており開発チームは現在10以上のチームが存在し、それぞれのチーム専用に用意された開発環境を利用しています。 2年程前までは開発
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導入: システムを安定させる4000万円の魔法の壺 - MonotaRO Tech Blog
こんにちは。鈴木です。 ここにシステムを安定させる4000万円の魔法の壺があるとします。 あなたなら買いますか。 はじめに SREやればいいのに 4000万円の魔法の壺 なぜモノタロウはSREに取り組むのか 10分落ちると数百万円、数千万円の影響が出る 不安定なシステムを札束でしばいたことがある 大規模化・複雑化が旧来の運用方法を無効化する SREの導入による効果 会話の中に「SLO」が登場するようになった システムの状態を深く理解できるようになった オンコールの初動対応が早く精緻になった SREの難しさ 組織横断的な活動の難しさ 安定的に時間を使うことの難しさ 利用するツールやサービスの難しさ どのようにSREを導入したのか Googleの最新SREを学んだ CUJを定義した SLIとSLOを定義した Cloud Monitoringでダッシュボードを作成した 役に立つかもしれない話 可
SRE Classroom: The Art of SLOs - Google
The Art of SLOsは、GoogleのCustomer Reliability Engineeringチームによって開発されたワークショップです。このワークショップの目的は、Googleがサービスの信頼性を計測する方法 サービスレベル指標(SLI) とサービスレベル目標 (SLO)を参加者に紹介し、実際にこれらの計測方法を作成することを体験してもらうことです。これらは重要で土台となる概念です。サービスの信頼性を客観的に測定する方法があれば、サービスの信頼性について有意義な会話をすることがはるかに簡単になります。 ワークショップの理論編では、開発チームと運用チームの間でしばしば生じる組織的な緊張を、サービスの望ましい信頼性を表す目標値を設定することで解決する方法を学びます。また、SLOとエラーバジェットを使って、データ駆動で、客観的、かつユーザー重視の方法でサービスの信頼性を測定・
SRE実践の形：7種類の SRE 実践パターン - 株式会社X-Tech5
SRE （Site Reliability Engineering）の実践パターンの話をします。 わたしたちが自身の経験をもとに書いたものですが、参考資料の影響を多大に受けています。参考資料がどれも厚すぎて参考にしきれていない感はあります。 これらの実践パターンはどれかが優れているというものではなく、組織やプロダクトの状況によって選択するものだと考えています。 なお次のエントリでSREを成していく道のりの話をしています。 SRE実践への道：ボトムアップの場合 SRE実践への道：トップダウンの場合 7種類のSRE実践パターン これらは順番に発生していくものではありません。また これらの実践パターンは排他的ではなく、複数を並行実施する ことがあります。 わたしたちが知る限りSREのミッション（あるいはSREに対する期待値）は両極端で、全体を俯瞰し全体最適を図る方向性の場合と、可用性・パフォーマ
開発メンバーの保守運用スキルを上げるため実施している朝当番制度の紹介 - Classi開発者ブログ
こんにちは、開発支援部基盤インフラチームの kenryooo です。 Classiでは過去の高負荷によるアクセス障害での反省を踏まえ、エンジニア向けに保守運用スキルを高める施策として、朝当番という制度を運用しています。今回はその紹介をします。 目的 朝当番制度は、下記を目的に運用しています。 Classiのピークタイム(毎朝8:00 - 9:30)に問題が起きた場合、社内向けにスムーズな情報連携を行う サービス品質の継続的な改善 パフォーマンスや監視内容に異常があった場合や、依存している外部接続システムやSaaSのメンテナンス情報などを担当チームへ共有する 担当エンジニアの育成 Classiシステムの全体像の理解 担当外のアプリケーション(リポジトリ)の理解 システム監視の入門(Datadog) インシデントハンドリングの入門 背景と課題 朝当番制度は、下記の背景と課題感からスタートしてい
SRE伝道師としてMicroservices SRE チームが取り組んでいる事例 | メルカリエンジニアリング
※この記事は、"Blog Series of Introduction of Developer Productivity Engineering at Mercari" の一環で書かれています。 著者: Microservices SREチーム @k-oguma（ktykogm） 本記事の内容は、前日の記事である "Embedded SRE at Mercari "の具体的な事例等の紹介となります。私自身が実際にEmbedded SREsとしてプロダクトチームに参加し、その中で発見したプロダクトチームの課題とそれに対して行った取り組みをいくつか紹介したいと思います。最後に具体的な活動を通して見えてきたEmbedded SREsのメリットなどについてまとめます。 本記事内の用語 SRE Site Reliability Engineering の略 信頼性における方法論、概念、ベストプラク
入門監視やSRE本に学ぶ障害対応フォーメーション - An Epicurean
システム障害が起こったときにどういう体制で望むか、エンジニア個人が障害に直面した時にどのような役割を受け持つのが良いのか。組織によって色々なパターンはあるでしょう。しかし、幸いにも「入門 監視」やSRE本に書かれている4つの役割分担が浸透しているので、それをベースに考えるのがファーストステップとしては良いのではないでしょうか。 入門 監視 ―モダンなモニタリングのためのデザインパターン 作者:Mike Julianオライリー・ジャパンAmazon SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム オライリージャパンAmazon ただ、小さな組織では障害時に4人もすぐに揃わない場合もあるでしょうし、そもそも4人もスタッフがいない、と言う場合もあるでしょう。そういった場合にもどうすればいいのか考えていきます。 役割分担の基本 「入門 監視」に
Mackerelでは計画メンテナンスをどう実施しているか？ RedisをElastiCacheに移行した裏側をご紹介 - Hatena Developer Blog
こんにちは。MackerelチームSREのid:heleeenです。 Mackerelでは、2020年10月14日に計画メンテナンスを実施しました。今回は告知ブログに記載の通り、Mackerelが利用しているRedisをAmazon ElastiCache for Redis（以下、ElastiCache）へ移行しました。 本記事では、この10月の計画停止の裏側を紹介します。 どのようにElastiCacheへ移行するか 大半のRedisを無停止で移行 最後はElastiCacheへのオンライン移行を使用 メンテナンスに向けたさまざまな準備 メンテナンス手順書のチーム内レビュー メンテンス実施中の役割分担 なぜタイムキーパーが必要になったのか リモートで停止メンテナンスを実施する方法 検証環境を利用して事前にリハーサルも実施 Redisを安全に効率よく切り替えるために 参照するRedisを
スタディスト開発部が目指す SRE の未来と現状と Kubernetes
（上記ブログ執筆時は、EKS on EC2 へ移行予定でしたが、EKS on Fargate への移行を行う方針に切り替えました。） Kubernetes 移行に関連する技術面の話題についてはご紹介してきた一方で、これまでの記事では、 「なぜ Kubernetes 移行を行っているか？」「スタディスト開発部は、最終的に何を目指しているのか？」といった背景には触れておりませんでした。そこで本記事では、スタディスト開発部が目指す世界観と、その過程として歩んでいる Kubernetes 移行の位置づけについてご紹介します。 目次Teachme Biz における Infra の現在と抱えている課題スタディスト開発部が目指す世界観Kubernetes 移行の位置づけ今後のやりたいことTeachme Biz における Infra の現在と抱えている課題現在 Teachme Biz の大部分（以降、本記
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SadServers - Linux & DevOps Troubleshooting Interviews
長年運用されてきたモノリシックアプリケーションをコンテナ化しようとするとどんな問題に遭遇するか？ / SRE NEXT 2022
ZOZOTOWNのProduction Readiness Checklistと信頼性向上の取り組み / Improvement the reliability of ZOZOTOWN with Production Readiness Checklist
非ITの事業会社にSREと言わずにSREを持ち込んだ
SRE Lounge #7 Gunosy版「SREミッション」策定
