DevOps への投資に対するリターンを計算する方法
DevOps や Platform Engineering, Developer Productivity など、開発活動の生産性を高める活動や分野を指す言葉が広く謳われるようになってきましたが、その活動を始めようと思っても効果について説明するのは難しいなと感じていました。 そんななか、Google Cloud による The ROI of DevOps Transformation という、DevOps 施策の ROI を計算する方法がいくつか紹介されている記事を見つけました。 この記事の内容がそのまま使えるかと言うと判断に困るのですが、面白かったので 1 つの計算方法として紹介していきたいと思います。 前提 Four Keys について DORA の研究によって、Four Keys 指標は組織のパフォーマンス（収益性、品質、顧客数、満足度など）に相関関係があることが分かっています。 F
Prometheusでアプリケーションを監視してみよう | IIJ Bootcamp
# Prometheusでアプリケーションを監視してみよう # 0. まえがき # 0-1. 想定している受講者 本講義では以下の受講者を対象としています。 監視って言われても何を監視すればいいのか分からない 監視が必要なのはわかるけど、なんで必要なのか分からない Prometheusを触ったことがないので触ってみたい # 0-2. 前提知識 基本的に前提知識は無しでも問題ないですが、以下の点を押さえておくと講義がスムーズに聞けます。 Linuxの基礎的なコマンド dockerの基礎 # 0-3. 事前準備 Dockerのインストール docker image lsで"hello-world"が存在しない状態で、docker run hello-worldが実行できていればOK Docker Composeのインストール docker-compose --versionでバージョン情報が出
SREとインフラエンジニアの違いを3つのポイントで理解する | sreake.com | 株式会社スリーシェイク
この記事では、SREとインフラエンジニアの違いについて3つのポイントで解説します。 SREとインフラエンジニアの違いを3つのポイントで理解する SREとインフラエンジニアの3つの違い1.業務範囲2.スキルセット3.方法論インフラエンジニアのキャリアパスとしてのSRE希少なSRE人材が提供する高品質なSREサービス = Sreake ここ数年、国内外問わずSREという職種が注目されてきており、実際にSREチームを作ってサービスを開発している企業も増えてきました。しかし、実情を見ると、従来のインフラエンジニアチームと大きな違いはなく、SREとしての力が十分に発揮されていないことが多いように感じます。 そこで今回はSREとインフラエンジニアの違いについて解説していきます。SREとインフラエンジニアの作業領域や、根本となる考え方の違いについても触れていきます。 関連記事：「SREとDevOpsの違
"Enterprise Roadmap to SRE"の日本語訳が出ました - YAMAGUCHI::weblog
はじめに こんにちは、Google CloudでオブザーバビリティとSREの担当をしているものです。今日は去年仕事でやってたものがようやっと表にでたのでその紹介をします。 「SREエンタープライズロードマップ」がでました Enterprise Roadmap to SREの日本語訳が公開されました。本レポートはSREに関して、その技術的立ち位置、導入する理由、必要なプロセス、文化、事例など、幅広く大局観を与えるコンパクトなレポートとなっています。ぜひご一読ください。#SRE #DevOps #GoogleCloudhttps://t.co/Lo1yY40CF4— Google Site Reliability Engineering (@googlesre) 2023年1月25日 「SREエンタープライズロードマップ」はかねてより "Enterprise Roadmap to SRE" と
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 に対する当初の熱意と、その採用の度合いの間に大きな隔たりが生じています。本レポートは、プロダクトオーナーや信頼性の高いサー
待望の日本語版発売！『詳解システムパフォーマンス 第2版』Linuxが深く学べる名著を全力で推したい - LIVESENSE ENGINEER BLOG
こんにちは、かたいなかです。 『詳解システムパフォーマンス 第2版』の日本語版が2023/01/24についに発売されました！ www.oreilly.co.jp 私個人は原著で読んだのですが、他の人に強くおすすめしたくなるような内容でした。そこで、日本語版の発売に合わせてどのあたりが良かったのかなど、内容をご紹介します。 TL;DR パフォーマンス改善タスクの課題感 どんな本？ この本のどこがいい？ Linuxの仕組みを広く深く学べる パフォーマンスの観点での情報が豊富 どんなひとにおすすめできるか？ クラウドやコンテナが当たり前になってからSREになった人 Linuxの知識をアップデートしたいエンジニア 最後まで読み切るには？ あせらずゆっくり読んでいく Linuxの前提知識を仕入れてから読む 終わりに TL;DR 『詳解システムパフォーマンス 第2版』は、Linuxを深く学んで仕事に活
クエリログを使ったPostgreSQLの負荷テスト - カンムテックブログ
SREの菅原です。 この記事はカンム Advent Calendar 2022の４日目の記事になります。 少し前にサービスで使っているPostgreSQLをRDSからAuroraに移行しました。 Auroraに移行するため色々と作業を行ったのですが、その中でAuroraの性能を測るために行った負荷テストについて書きます。 pgbench まず最初にpgbenchを使って、単純なワークロードでのRDSをAuroraの性能差を測ってみました。*1 以下がその結果です。 MySQLで同様のテストをmysqlslapを使って行ったことがあって、そのときは概ねAuroraのほうが性能が高かったので、同様の結果になると考えていたのですが、RDSのほうが性能が高い結果になったのは予想外でした。 ただAuroraのアーキテクチャを考えると、pgbenchのような細かすぎるトランザクションの場合はRDSのほ
サーバーレスアーキテクチャーも大胆に導入！ 自律・自走できる組織作りを進めるカオナビのインフラチーム - はてなニュース
タレントマネジメントシステムを提供する株式会社カオナビでは、サービスをSaaS型にシフトするにあたってAWS（Amazon Web Services）を全面的に採用し、サーバレスの基盤開発でもAWSのマネージドサービスを積極的に活用しています。 そのベースにある「運用しない運用」という言葉の意図や、計測・監視の取り組み、アプリケーション開発の経験も活用できる「自走するインフラ組織」について、インフラグループの大久保智之さんと新井健さんに聞きました。 ※この記事は株式会社カオナビによるSponsoredContentです。 AWSへの移行から技術的な挑戦を進める サーバレスを推進して温かみある手順から脱出 開発の経験も生かしたアプリケーション監視と指標 自動化の原則は自走と自律 カオナビではエンジニアを積極募集しています！ AWSへの移行から技術的な挑戦を進める ── プロフィール（後掲）を
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とエラーバジェットを使って、データ駆動で、客観的、かつユーザー重視の方法でサービスの信頼性を測定・
ITエンジニア向けのトレンド情報 | Forkwell Press （フォークウェルプレス）
Forkwell が主催する技術イベント「Infra Study」。今回のテーマは「インフラの面白い技術とこれから」です。（開催日：2020年 7月29日）。本記事は登壇者の近藤さんの基調講演から mruby や C言語を使い、コンテナを自作している様子をお伝えします。最後には、登壇者の近藤さんとまつもとりーさんが視聴者からの質問に回答しているので、ぜひご覧ください。 この回ではインフラで一番面白い世界について考えていきます。 皆さん、子どもの頃、中身が気になって時計を分解するようなことがありましたか？ 私はありませんでした。 にも関わらず今私が一番面白いと考えている世界はインフラの「中身」です。インフラエンジニアは、ともすれば与えられたOS、ミドルウェア、 マネージドサービスを上手に組み合わせることを求められますし、実際それらの要素を適材適所位配置できることは良いインフラエンジニア、アー
開発メンバーの保守運用スキルを上げるため実施している朝当番制度の紹介 - Classi開発者ブログ
こんにちは、開発支援部基盤インフラチームの kenryooo です。 Classiでは過去の高負荷によるアクセス障害での反省を踏まえ、エンジニア向けに保守運用スキルを高める施策として、朝当番という制度を運用しています。今回はその紹介をします。 目的 朝当番制度は、下記を目的に運用しています。 Classiのピークタイム(毎朝8:00 - 9:30)に問題が起きた場合、社内向けにスムーズな情報連携を行う サービス品質の継続的な改善 パフォーマンスや監視内容に異常があった場合や、依存している外部接続システムやSaaSのメンテナンス情報などを担当チームへ共有する 担当エンジニアの育成 Classiシステムの全体像の理解 担当外のアプリケーション(リポジトリ)の理解 システム監視の入門(Datadog) インシデントハンドリングの入門 背景と課題 朝当番制度は、下記の背景と課題感からスタートしてい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://x.com/yuuk1t/status/1708787131651616988?s=12&t=suYC6B2IhN7jv0qU5zDxmQ
https://twitter.com/aokitenzen/status/1663837146481053696?s=12&t=suYC6B2IhN7jv0qU5zDxmQ
SRE不在のチームに入って2ヶ月でやったこと - 負荷試験ツールからはじめるSREプラクティスの導入
SRE 研修
https://twitter.com/nwiizo/status/1622912186543935490?s=12&t=89UN6VxGo4meCGfwBGB4HQ
https://twitter.com/NIFTYDevelopers/status/1536898749741826048
「入門 監視」5年を経て変わったこと、変わらないこと / Fundamental principles in Practical Monitoring
https://twitter.com/t_yoshinaga0106/status/1507658903311773697