株式会社サイバーエージェント AI事業本部 2024年度エンジニア新卒研修 オブザーバビリティ研修実践編(一部社内向けの内容)
株式会社サイバーエージェント AI事業本部 2024年度エンジニア新卒研修 オブザーバビリティ研修実践編(一部社内向けの内容)
はじめに 本書『Observability Engineering』は、複雑化の一途をたどる現代のソフトウェアシステムに立ち向かうための、強力な武器となる一冊であり本稿はその読書感想文です。Observability Engineering を今から知りたい方はもちろん、Observability Engineering の基礎を改めて学びたい方もぜひお読みください。この記事もかなりの長さになるので普通に書籍を読んだほうがいいかもです learning.oreilly.com 「Observability:可観測性」という言葉は、近年ソフトウェアエンジニアリングの世界で大きな注目を集めています。しかし、その概念の本質を理解し、実践に移すことは容易ではありません。 本書は、そのオブザーバビリティについて、その基本的な考え方から、具体的な実装方法、そして組織への適用まで、幅広くかつ深く解説して
はじめに エンジニアとして就職する前に読んだ「なれる!SE 2週間でわかる?SE入門」の内容があまりにも厳しく、業界に就職するのが怖くなったことを覚えています。本の中に登場する中学生の少女にしか見えない凄腕のSE、室見立華さんのような人物は現実には存在しないでしょうが、実際の業界には彼女のような凄腕エンジニアや年齢不相応な技術力を持つ人間も確かに存在します。 なれる!SE 2週間でわかる?SE入門 (電撃文庫) 作者:夏海 公司,IxyKADOKAWAAmazon SREの探求『Becoming SRE』の内容紹介 私は「なれる!SE」が好きすぎるあまり、「なれる!SRE」というタイトルのクソみたいな文章を吐き出したこともありましたが、そのクオリティがあまりにも低かったため、外には公開せずに留めておきました。そんな中、SREの探求の原著者であるDavid Blank-Edelman(ott
https://hachiojipm.connpass.com/event/304403/ の発表資料です
こんにちは。開発部門 開発部 Data AI Strategyセクション データ基盤 Unitの小野です。 2020年8月に入社してから早3年。SREエンジニアとして、日々業務改善に励んでいます。 ここ一年ほど、DAOという組織改善プロジェクトを推進していく中で、Google Kubernetes Engine (GKE)を使ったGKE共通デプロイ基盤の整備も進めてきました。 ※ DAOについての詳細はSREエンジニアが組織改善プロジェクトを立ち上げてみたを参照ください SREエンジニアの責務の一つは、プロダクトのリリースサイクルを極限まで短くし、次々と新しいサービスを世の中にリリースすることです。ChatGPTのような誰でも簡単に扱えるAIモデルが誕生したことで、プロダクト開発競争は今後ますます激しくなっていくと予想しており、SREエンジニアの責務の重要性をヒシヒシと感じています。 そう
この記事は、Merpay Tech Openness Month 2023 の4日目の記事です。 こんにちは。メルコインのバックエンドエンジニアの@goroです。 はじめに このGitHub Actionsのセキュリティガイドラインは、社内でGithub Actionsの利用に先駆け、社内有志によって検討されました。「GitHub Actionsを使うにあたりどういった点に留意すれば最低限の安全性を確保できるか学習してもらいたい」「定期的に本ドキュメントを見返してもらい自分たちのリポジトリーが安全な状態になっているか点検する際に役立ててもらいたい」という思いに基づいて作成されています。 今回はそんなガイドラインの一部を、社外の方々にも役立つと思い公開することにしました。 ガイドラインにおける目標 このガイドラインは事前に2段階の目標を設定して作成されています。まず第1に「常に達成したいこと
はじめに 有用な知識の特性 Google SRE リソース Site Reliability Engineering: How Google Runs Production Systems The Site Reliability Workbook: Practical Ways to Implement SRE Building Secure and Reliable Systems: Best Practices for Designing, Implementing, and Maintaining Systems SLO Adoption and Usage in SRE Creating a Production Launch Plan Training Site Reliability Engineers: What Your Organization Needs to Cre
Home Being On-Call Before an Incident During an Incident After an Incident Crisis Response Training Additional Resources Getting Started On-Call Being On-Call Who's On-Call? Alerting Principles Before an Incident What is an Incident? Severity Levels Different Roles Call Etiquette Complex Incidents During an Incident During an Incident External Communication Guidelines Security Incident After an In
概要 ソーシャル経済メディア「NewsPicks」SREチームの中川です。 皆さんはバッチ処理基盤はどうされていますでしょうか。 NewsPicks では少し前まではそれらをEC2、cronの組み合わせで動作させていました。 何年も前からこの仕組みだったのですがSREとしてはEC2の面倒見るのも手間ですし、それ以上にcronを変更する際のオペレーションミスが目立ったのが懸念点でした。 その為、まずはAWSマネージド化するための基盤を整備し、その後バッチアプリを載せ替えていくようにしました。 対応前の基盤構成 同じSREチームの安藤さんが CloudNative Days Tokyo 2023 で登壇されたときの資料をお借りします。 ご覧の通り、大体のサービスはマネージド化していましたがバッチ基盤だけは旧来のままEC2インスタンスを利用していました。 10年モノのサービスのインフラを漸進的
目次 はじめに 食べログにおけるKubernetes化のモチベーションとその進み具合 Kubernetesというインフラにおける監視戦略 監視システムは作り込むのではなく買う あらゆるコンポーネントのゴールデンシグナルを観測する なるべく一箇所からあらゆるメトリクス/ログをクエリできるようにする メトリクスデータには決められたラベルを付与する 食べログにおけるKubernetes監視のwhatとhow 監視データの置き場 ログデータ置き場 メトリクスデータ置き場 監視している内容 ゴールデンシグナルの監視 容量監視 ロギング 監視ツールの監視 食べログにおける監視失敗事例 事例1: Pod総数爆増によるクラスタ全体のスローダウン 事例2: 同一DeploymentのPodが同時にevictされたことによるサイト閲覧障害 おわりに はじめに 食べログ 技術部 SREチームの下國 峰昌と申しま
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
こんやっぴー👾 カバー株式会社 技術開発本部のSです。カバー株式会社では組織横断的にSRE(Site Reliability Engineering)やサーバーサイドのエンジニアをしています。 2023年5月に入社し3ヶ月ほどホロプラスのパフォーマンスチューニングや開発環境の整備をしてきましたので、今回はそちらについてご説明します。 ホロプラスとは?ホロプラスは「推しをもっと好きになる!」がコンセプトの、ホロライブプロダクション公式アプリです。先日8月29日に正式リリースされました。主に、以下の二つの体験を提供します。 ホロライブプロダクションの最新情報が公式アプリならではの機能で手軽に逃さずチェックできる 共感でつながるファンコミュニティで投稿やいいねを通じたコミュニケーションが楽しめる ※画面は開発中のイメージですホロプラスのシステム構成ホロプラスは図のようなシンプルな構成でGo言語
障害プロセスを改善してきた話 こんにちは。Reliability & Securityチームに所属するSoftware Engineerの@sota1235です。 今回は10X内における障害対応プロセスの改善をご紹介します。 今が完成系ではなく道半ばではありますがこの半年 ~ 1年で大きく進化したので同じくらいのフェーズの会社で困ってる方がいたら参考にしてみてください! ちなみに私ごとですが去年の5/26にこんな投稿をしてたのでやっと伏線を回収する形となります(※ ドヤ顔ではありません)。 目次 こんな感じで紹介していきます。 目次 障害対応プロセスの改善に踏み切った背景 課題1. 障害の報告フォーマットが統一されていない 課題2. 障害報のクオリティの差異が大きく後から振り返りが難しい 課題3. 障害対応者が特定の人に偏る 第一の改善 改善1. 障害報告書のフォーマット更新 改善2. S
【SREチーム ブログリレー1回目】 お疲れ様です。エンジニアリンググループ、コアSREの山本です。 他の情報伝達手段が現れた今は「メール」は以前よりも比重は落ちたかもしれませんが、まだまだ多くの人に情報を一気に伝えるための重要なツールです。 エムスリーでは自社サーバを利用してメールの大量送信を実施していますが、メール送信を実施するにあたって気にすべき基本的な事項についてシェアさせてください。 大量メール送信に関連する基本的な設定 基本的な設定(SPFと逆引き) DKIM IPの追加削除 バウンスメール処理 金で解決 まとめ We are Hiring! 大量メール送信に関連する基本的な設定 メール送信自体はそれほど難しいものではありません。 エムスリーではpostfixを利用していますが、設定はほとんどオリジナルでもメール送信自体は可能です。せいぜいドメイン名を登録するくらいでもいけます
LAPRAS株式会社でSREをしているyktakaha4と申します🐧 弊社のSREチームで最近運用をはじめた見積もりやふりかえりの手法について書きたいと思います 大規模な立ち上がり済みの組織向けでなく、今ひとりで仕事をしている人が2人目のSREを迎え入れたときの一事例としてご覧ください 経緯 弊社は2016年に創業して以来、ソフトウェアエンジニアとして入社した社員がアプリケーションからクラウドまでプロダクト全体を開発・運用するというスタイルが取られていましたが、 エンジニア組織の拡大に伴い、2021年頃からプロダクトの信頼性や可用性の向上を責務とする専任のSREを立ててシステムの改善をおこなってきました 以下は、弊社で導入しているホラクラシーに基づいて定義された Site Reliabilityサークル のロールの一覧です 原則として、ロールは誰であっても自由に負うことができるので、主務
ドキュメンタリアンとは、役職に関係なく、ソフトウェア業界でドキュメントとコミュニケーションに関心を持つ人のことです。 www.writethedocs.org はじめに これは主に『ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング』の書評です。私はSreakeにてSREという役職についています。SREはサービス概要、アーキテクチャの解説や図、各種構成図、各種手順書、ポストモーテム、ポリシー、SLA(SLO) … その他の様々な場面でドキュメントを書く必要があります。しかし、ドキュメントは価値が見えにくく時間と労力がかかり品質担保の面で重要度がとても高いのにその場での価値が見えにくいので浸透しにくいです。そのため、エンジニアとしてモチベーションが保ちづらいです。2021年 State of DevOps 2021 にもドキュメントに関する言及があり今後、
こんにちはNewsPicks SREチームの美濃部です。 NewsPicksのSREのミッションの1つに「コストを適正化する」というものがあります。サービスの規模拡大に比例してインフラコストが増えないようにし、売上に対するコストの割合を低く維持していくのがミッションになります。 今回はこのミッションに対するアクションとして開発環境のインフラコストを適正化した話をします。 NewsPicksの開発環境について 開発環境のコストをどうやって適正化したか 稼働時間対応を実現する仕組みについて 実際どれくらい削減できたのか まとめ NewsPicksの開発環境について まず、NewsPicksの開発環境について概要を説明します。 インフラ基盤は本番環境と同様にAWSを利用しており開発チームは現在10以上のチームが存在し、それぞれのチーム専用に用意された開発環境を利用しています。 2年程前までは開発
どのようなシステムもそれを作るのも運用するのも人であり(SREが目指すのが運用をなくすことだとしても)、大抵の場合、一人ではなく組織としてシステムを作っていますが、信頼性の低い組織からは信頼性の高いシステムは生まれることは考えにくいです。 SRE NEXT 2022で提起した組織に対してSREを適用することでどうやって信頼性を保つことができるかということについて、実際に組織に起きた問題とそれにどういうプラクティスを適用し、どうなったのかを紹介します。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く