結論 コードメトリクスの一つ、保守容易性指数と、バグ発生率とに、相関の兆候を見つけた まだ下調べの段階だけど、大規模調査および統計的検定の結果、 保守容易性指数とバグ発生率との相関が認められたら、 保守容易性指数をKPIにすることで、数値的品質評価・管理ができるかもしれない バグをまき散らすけど手が早いエンジニアの影に隠れて、 丁寧にモノづくりをしているけどいまいち評価されていないエンジニアに、 日の目をあてられるかもしれない。 バグ対処コストと保守容易性とを掛け合わせることで、 技術的負債を金銭的評価ができる可能性がある 金銭的に評価できれば、返済に関して、ビジネスサイドと有意義な議論ができる可能性がある はじめに 僕ら(@gakuri、@ahera、@yukke7624)は、とあるSI会社で横断的にプロジェクト支援をしている。 マネジメント状況の監査、支援、テコ入れから、技術的アドバイ
Observabilityをはじめよう！(前編) 〜Observabilityの背景と構成要素〜 | さくらのナレッジ
はじめに 仲亀と申します。さくらインターネットでエバンジェリストやインフラエンジニアをしています。エンジニアとしてはシステムの監視まわりの仕事をしています。最近は、今回もご紹介するPrometheusとかGrafana Lokiとか、あの辺が結構好きで触っています。 この記事では、監視について興味をお持ちの皆さんに向けて「Observabilityをはじめよう！」ということで、Observabilityの概念や、それが必要となる背景を少し説明した上で、Observabilityを実現するための要素となる、MetricsやLogsやTracesなどをどこから始めていけばいいんだろう、といったところをご紹介していこうと思います。 この記事のゴールとしては、皆さんに「Observability完全に理解した」と言っていただけたらいいかなと思っています。しかし、この記事を読んだだけですぐに皆さんの
こんにちは。SRE の近藤（@chaspy）です。 先日、より高い信頼性でサービスを提供するために、スタディサプリ小中高大のサービスの最後の砦であるデータベース、MongoDB のインスタンスクラスのスケールアップを行いました。また、スケールアップをするにあたり、負荷試験を行いました。 本記事では、データベースインスタンスのスケールアップの際に行なった負荷試験に対する考え方と、得た学びを紹介します。 なぜスケールアップするのか サービスの急成長に伴い、アクセス数もデータ量も増加しています。数年前に「しばらくは大丈夫」と判断できるインスタンスクラスにスケールアップをしたデータベースも、高負荷時には性能が劣化してしまう問題に遭遇しました。 私たちの MongoDB は AWS 上に EC2 インスタンスとしてセルフホストしており、MongoDB Cloud Manager を使って運用の一部を
GitHub - vectordotdev/vector: A high-performance observability data pipeline.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
技術本部 Mobile Applicationグループの山本です。名刺アプリEightの開発を行っています。 今回はMobile ApplicationグループのEight開発チームの生産性指標をFour Keysからベロシティを含む別の値に変更した話をします。 一般的にはベロシティは生産性指標にすべきではない、Four Keysは生産性指標として適切であるという評価だと思います。もちろんそれは理解した上でこの選択をしています。その理由について説明します。 なお組織全体がこのように考えているわけではないということに御注意ください。例えば同じMobile ApplicationグループでもSansan開発チームはFour Keysを生産性指標にしています。 生産量2倍計画 現在技術本部では中期的な課題として1年で単月の生産量を2倍にするという目標を掲げています。 ポイントとして、技術本部のレ
State of DevOps Report 2021を日本語で解説 ーTeam Topologies Model、プラットフォームが重要な要素ー | TC3株式会社｜GIG INNOVATED.
State of DevOps Report 2021を日本語で解説 ーTeam Topologies Model、プラットフォームが重要な要素ー はじめに State of DevOps ReportはDevOpsの成熟度についてアンケート形式で調査しているレポート資料です。毎年アップデートされているので、直近の動向などを理解し、かつ課題解決の活路を見出すのに良いレポートです。2021版が先日リリースされていました(もとのレポートはこちら)。 デジタルトランスフォーメーションの文脈の中で、ソフトウェア開発がますます増えてきていますが、単に一発作っておしまいではなく、継続的に進化させることが求められます。継続的にサービスを進化させていくことがビジネス力の根源となるということをアンケート調査から証明したのが、このレポートで、調査内容については、『LeanとDevOpsの科学』をご一読いただく
At Airplane, we collect observability data from our own systems as well as remote “agents” that are running in our customers’ infrastructure. The associated outputs, which include the standard “three pillars of observability” (logs, metrics, and traces) are essential for us to monitor our infrastructure and also help customers debug problems in theirs. Over the last year, we’ve made a concerted ef
English Version： https://www.slideshare.net/sakataakinori/xp-fes-2019-b6-application-of-statistical-quality-control-to-agile-software-development XP祭り2019 B-6 「アジャイルソフトウェア開発への統計的品質管理の応用」の資料です。 On 2019年8月20日, in XP祭り2019, XP祭り2019セッション 【セッション情報】 セッションID：B-6 時間：14:45～15:15（30分） 会場：B（1F 102室・後） タイプ：講演 【セッション内容】 アジャイル開発のマネージメントやチーム運営のお手伝いをしていく中で、ウォータフォールで使われている品質メトリクスを利用しようとしているプロジェクトを見かけることがあります。 ウォー
For a $5.99 per month, immigrants have a bank account and debit card with fee-free international money transfers and discounted international calling.
A Theory of Scrum Team Effectiveness 〜『ゾンビスクラムサバイバルガイド』の裏側にある科学〜
Regional Scrum Gathering Tokyo 2024での講演資料です。 --- 2023年、ソフトウェア工学分野の論文誌であるTOSEM[1]、およびトップカンファレンスであるICSE 2023[2]に、スクラムに関する1本の論文が同時に採択されました。 僕は50ページを超えるその論文を読んで衝撃を受けました。こういう学会に投稿されるスクラム・アジャイルの論文は、アジャイル実践者の目線からするとあまりピンとこないものもあるのですが、この論文はまず、そういった点で一分のスキもありませんでした。 ただの研究者ではない、明らかにスクラム実践者が書いた論文でした。 一体誰が書いたのか、と思って調べてみると、2人の著者 Christiann Verwijs と Daniel Russo のうち、Christiaan Verwijsはあの『ゾンビスクラムサバイバルガイド』の著者の1人
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog LINE の Business Platform 開発担当フェローの Matsuno です。 今回は Spring Boot でアプリケーションを開発した場合のメトリクスの勘所についてご紹介しようと思います。 我々のチームでは Kotlin + Spring Boot での開発がデファクトスタンダードとなっているのですが、正直まだまだこのテクニカルスタックで開発しているエンジニアは日本では少ないのです。そこで、実際の運用の雰囲気を感じていただければと思いまして今回の記事を書くことにしました。 メトリクス取得の基本 我々のチームではメトリクスの格納先として Prometheus を利用しています。 Prometheus で格納し
はじめに Four keys とはソフトウェア開発の生産性を測定するのに利用される以下の4つの指標のことである（参考）。 デプロイ頻度（Deployment Frequency） ソフトウェアのデプロイ頻度 変更リードタイム（Lead time for changes） ある変更をソフトウェアに適用してから、その変更がリリースされるまでの時間 障害修正時間（Time to restore） ソフトウェアに障害が発生してから、その障害が修正されるまでにかかった時間 障害率（Change failure rate）ソフトウェアのデプロイのうち障害が発生したデプロイの割合 これらの指標を簡易に測定するための CLI ツールを作成した。 この記事では、この CLI ツールについて紹介する。 使い方 インストール Releases の最新バージョンから自分の環境に合わせた実行ファイルをダウンロードす
こんにちは、開発室の林です。 今回はデータ可視化ツール「Grafana」を利用して、TACT SEOの問い合わせ業務や保守業務の一部を効率化した事例を紹介します。 本記事のスコープ Grafanaで利用した機能 効率化した事例 毎月の社内用レポートの自動化 保守業務の効率化 アプリのAlert通知 関連データの可視化 最後に 本記事のスコープ 本記事の想定読者は以下の通りです。 Grafanaは知っているけど、実際にどのように使えるか知りたい人 同じ保守業務を繰り返しており、効率化を図りたい人 データ可視化ツールを探している人 本記事では「Grafanaとは何なのか」、「Grafanaの詳細な使い方」に関しては記述しませんので、その点ご了承ください。 Grafanaで利用した機能 Grafanaは様々なDatasource(MySQLやAWSの各種サービス等)と連携ができ、それを可視化する
CloudWatch Logsにカスタムメトリクスを埋め込める、Embedded Metricsが追加されました！ | DevelopersIO
CloudWatch Logsにカスタムメトリクスを埋め込める、Embedded Metricsが追加されました！ オペレーション部 江口です。 CloudWatch Logsが、カスタムメトリクスを埋め込んで送ることができるフォーマット"Embedded Metrics Format"に対応しました。 https://aws.amazon.com/jp/about-aws/whats-new/2019/11/amazon-cloudwatch-launches-embedded-metric-format/ ログにこのフォーマットで情報を送ることで、カスタムメトリクスとしてCloudWatchで集計してくれるようになります。 これまでもCLIやAPIでカスタムメトリクスをPushすることは可能でしたし、CloudWatch Logsでフィルターを作成してマッチした文字列の数を数えるメトリ
PubSub/Redisを用いたGoによるスケーラブルなworkerの構築と運用 | メルカリエンジニアリング
こんにちは。メルカリのNotification teamでソフトウェアエンジニアをしている@naruseです。 この記事は、Mercari Advent Calendar 2021 の19日目の記事です。 はじめに 私が所属しているBusiness Platform Notification teamでは、２つの役割で通知周りの基盤を担当しています。 １つ目はアプリケーションとしての役割の通知です。メルカリでは、アプリ内でのお知らせや個別メッセージ、やることリストなどを提供しています。私たちはそれらの膨大なデータを管理し、作成や取得のリクエストに応えています。これらの膨大なデータに対する私たちのチームの過去の記事として、昨年のAdvent calenderの一部である本番稼働中の Spanner にダウンタイム無しに57時間かけてインデックスを追加して得た知見をぜひご覧ください。 ２つ目は
Flutterアプリの定期リリースを支える自動化 - Fast DOCTOR Technologies TECH BLOG
本稿では、ファストドクターのモバイルアプリのリリースフローを整備した取り組みについてご紹介します。 モチベーション ファストドクターのモバイルアプリは、2022年夏にFlutterでのフルリプレースを実施し、それ以降は機能の開発が完了次第随時リリースをするという戦略を取っていました。 この戦略はシンプルであり、開発に関わっているステークホルダーが少ない状況下でうまく機能していました。しかし、組織の拡大に伴い以下のような問題が発生するようになりました。 複数機能の開発スケジュールの調整をしたり、バックエンドのリリース・QAとの整合性を取ったりという必要性が増し、調整コストが肥大化 リリースが不定期なため、いつPull Requestをマージすれば良いか分からずopenされたままのPull Requestが多数 この状況を改善するために、以下の要件を念頭に定期的なリリースとそれを支える仕組みを
ZOZOTOWN Androidチームにおけるコードメトリクスとビルド時間計測の取り組み - ZOZO TECH BLOG
はじめに ZOZOTOWN開発本部 ZOZOTOWNアプリ部 Android2ブロックの高橋です。 ZOZOTOWN Androidチームでは、リファクタリングやビルド速度改善の取り組みを継続的に行なっています。本記事では、それらの取り組みの効果を可視化するために導入した、コードメトリクスやビルド時間計測の方法について紹介します。 はじめに ZOZOTOWN Androidチームにおけるリファクタリングやビルド速度改善の取り組み コードメトリクスの計測 メトリクス Cyclomatic Complexity（循環的複雑度） LOC（ファイルのコード行数） Author数 計測方法 Cyclomatic Complexityの計測方法 Java Kotlin LOCの計測方法 Author数の計測方法 ビルド時間の計測 計測方法 計測結果の可視化 コードメトリクスの計測結果 計測結果のパース
大手ハイテク企業のエンジニアリング生産性指標に学ぶ
The Pragmatic Engineer Newsletterの著者であるGergely Orosz氏は最近、Measuring Developer Productivityという記事を発表した。DXのCEOであり、DevExフレームワークの共同開発者であるAbi Noda氏との共著である。この記事では、Noda氏が有名ハイテク企業の幅広い分野で使用されているエンジニアリング・メトリクスを調査した結果を分析している。Noda氏は、DORA やSPACEメトリクスを全面的に採用するのではなく、使用されている指標には多くのコンテキスト固有の定性的・定量的メトリクスが含まれていることを発見した。Noda氏とOrosz氏は、イネーブルメントチームが求める成果から逆算して、そのようなメトリクスを定義するためのガイダンスを提供した。 Noda氏は、「17の有名ハイテク企業で開発者の生産性測定を担当
SonarCloudと始める静的コード解析 〜ソフトウェア品質向上のための第一歩〜 - ZOZO TECH BLOG
はじめに こんにちは。FAANSバックエンドエンジニアの浜口（@xlgorbylx）です。普段はFAANSのバックエンドシステムの開発をしています。 FAANSとは、弊社が2022年8月に正式ローンチした、アパレル店舗のショップスタッフの販売サポートツールです。例えば、ZOZOTOWN上で実店舗の在庫取り置きができる機能や、コーディネート投稿の機能などを備えています。投稿されたコーディネートはZOZOTOWNやWEAR、Yahoo!ショッピング、ブランド様のECサイト等に連携が可能です。これによりお客様のコーディネート選びをサポートし、購買体験をより充実したものにします。機能の詳細に関しましては、下記プレスリリースをご覧ください。 corp.zozo.com 本稿では、Go言語で実装されたFAANSのバックエンドシステムについて、SonarSource社の提供するSaaSである「Sonar
Linux perf Profiler UIs pprof Web UI looking at a flamechart of regexp stack traces. This post is a quick literature review of CPU profiler user interfaces available for analysing Linux program performance. I couldn't find any list of profiler UIs online. Hopefully this can help people find the profiler UI that's right for them. CPU Profiler output is extremely multidimensional — processes, thread
OSSでオブザーバビリティを実現する (Elastic Stack x OpenTelemetry on Kubernetes) - RAKUS Developers Blog | ラクス エンジニアブログ
こんにちは。インフラエンジニアの gumamon です！ 最近はSRE的なことも ちょこちょこ やらせて頂いています。 NewRelic、Datadog、モダンな監視(オブザーバビリティ)って良いですよね。 弊社もKubernetes(k8s)等を利用した環境が増えてきた折、そろそろ必要になってきた(と思っている)のですが、NewRelic、Datadog等のクラウドサービスはランニングコストが安くない。 そこで内製できないかやってみよう！ということになり、試行錯誤をした結果どうにか表題の構成で作ることができたのでご紹介をしたいと思います！ この記事では、k8sを観測対象とし、オブザーバビリティを実現した際のアーキテクチャ構成、並びに四苦八苦する中で得た観測の勘所(私見)についてご紹介します。 目次 目次 オブザーバビリティとは オブザーバビリティ(OSS)の実現事例 全体構成 Elast
OpenTelemetryについての情報を見聞きする頻度がどんどん上がっており、各種サーバー監視サービスやクラウドでも対応が進んでいることから、そろそろ自分の引き出しに入れたいと感じました。概要を自分で説明できるくらいを目指してざっくり学んだログを自分用に残します。 OpenTelemetryとは opentelemetry.io 公式トップページにある以下が全てを物語っているとは思います。メトリック、ログ、トレースはお馴染みのObservability三銃士ですね。 OpenTelemetry is a collection of APIs, SDKs, and tools. Use it to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) to help you
こんにちは、WEAR部バックエンドブロックの小山とSREブロックの繁谷です。 WEARでは日々システムの信頼性を向上させるため改善に取り組んでいます。今回はその中でもSLOに基づいた改善について紹介いたします。 WEARリプレイスの歩み WEARでは2019年から本格的にリプレイスを開始しましたが、当初は専属のSREはおらずインフラ構築など緊急度の高いものをバックエンドのエンジニアや、プロダクト横断のSREが担っていました。 WEARのSREとして活動に割ける時間も短かったためSLI(Service Level Indicator)1やSLO(Service Level Objective)2の指標もありませんでした。WEARにおけるリプレイスの変遷についてはこちらのスライドに詳しく載せられているため、ご興味のある方は是非ご覧ください。 WEARの組織における課題 WEARでは2021年4
はじめに こんにちは、検索基盤部の広渡です。検索基盤部では、検索クエリのサジェスト（以下、サジェスト）の改善を行なっています。ここでサジェストは一般的に「Query Auto Completion」と呼ばれる、検索クエリを入力した際に入力の続きを補完したキーワードを提示する機能を指します。 ZOZOTOWNにおいては検索クエリを入力したとき、最大10件の検索クエリのサジェスト（以下、サジェストリスト）が表示されます（なお、ランキングを考慮しない場合はサジェスト集合と呼ぶこととします）。また、サジェストリストのランキングはユーザーの行動ログを用いて計算されたスコアによって決定されます。サジェストの具体的な説明や過去の改善事例は以下の記事を参照してください。 techblog.zozo.com techblog.zozo.com サジェストリストをチーム内で定性評価したところ、類似したサジェス
GitHub - remeh/diago: Diago is a visualization tool for CPU profiles and heap snapshots generated with `pprof`.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
GitHub - bloomberg/memray: Memray is a memory profiler for Python
Memray is a memory profiler for Python. It can track memory allocations in Python code, in native extension modules, and in the Python interpreter itself. It can generate several different types of reports to help you analyze the captured memory usage data. While commonly used as a CLI tool, it can also be used as a library to perform more fine-grained profiling tasks. Notable features: 🕵️♀️ Tra
SRE NEXT 2022 https://sre-next.dev/2022/
そのアジャイル開発、品質管理は大丈夫？ 無料の電子書籍で分かる、アジャイル開発におけるテストの考え方
デジタルトランスフォーメーション（DX）が叫ばれる昨今のソフトウェア開発では、短期間での開発や、ニーズに合わせた頻繁なアップデートが求められる傾向にあるでしょう。これに対応するため、少人数、短期間の開発を繰り返す、アジャイル開発を取り入れる組織も増えつつあります。 スクラムというフレームワークでアジャイル開発を行う場合、「スプリント」と呼ばれる短い期間で要件定義から開発、テストまで、システム開発における一連の流れを繰り返します。しかし、テストはその性質上スプリントの最終段階で実施するため、どうしても不十分な結果となってしまいがちです。 そんなアジャイル開発において生じる「どのようにすれば品質を保証しつつソフトウェアをリリースできるのか」「テストの選定方法とその進め方をどうすべきか」という疑問に、本eBookでは答えます。 全5回の連載内容を読めば、きっとアジャイル開発のテストをどう進めたら
本記事は株式会社ログラス Productチーム Advent Calendar 2022の20日目の記事になります。 昨日はtkamaiさんのto B SaaS企業を2社経験して感じた、プロダクトマネージャーに大切なことでした。 はじめに 昨今、開発生産性や開発者体験、Four Keys(DORA Metrics)にDeveloper Productivity Engineering(DPE)などの言葉を耳にする機会が少しづつ増えてきたように思います。 生産性可視化・改善の動きは弊社でも強まってきており、先月11月からログラス開発組織初のnot フィーチャーチーム、チームトポロジーで言う所のイネーブルメントチームが誕生しました。 私は上述のイネーブルメントチームの中で、特に開発生産性・体験の向上を役割として持つことになったため、開発生産性は個人的にもホットトピックです。 様々な企業の取り組
Connascence：コードの結合度を測るもうひとつの指標 - snoozer05's blog
構造は、凝集度が高く、結合度が低い場合に安定する - Larry Constantine 私たちプログラマーは、その仕事において、できる限り良いコードを書きたいと考えます。しかし、「良いコードとは何か」という問いに対して答えるのは、そう簡単ではありません。「良さ」を測るには、「何に対して」という軸が必要であり、その軸は一つではなく、さらには、コードを書いている状況に応じて、大事にすべき軸が変わるということも往々にしてあるからです。そうしたとき、私たちは何らかの尺度でもってコードを測って、そのときのコンテキストにおいて良い落とし所を定めます。 そのようなときに、コードの品質を測る軸としては、有名なものには「凝集性（Cohesion）」と「結合度（Coupling）」があります。ここでは、そのうちの「結合度」を測る指標の一つとして「コナーセンス（Connascence）」を紹介します。 コード
mobsfscanとGithub Actionsによるモバイルアプリの継続的セキュリティチェック - Pepabo Tech Portal
こんにちは、EC事業部事業領域拡大チーム所属のTatsumi0000です！業務ではAndroidアプリ開発をメインに、時々iOSアプリの開発をしています。 EC事業部では、Chapterという活動をしています。Chapterとは、事業部内のチームを横断した組織で、フロントエンド、バックエンド、セキュリティなど、様々なChapterが存在しています（詳細については、後述します）。その中でも私はセキュリティChapterに参加し、Chapterのメンバーと一緒にいろいろな活動をしてきました。 この記事では、EC事業部で行っているChapterと、セキュリティChapterの活動の一環として、mobsfscanをgithub.comのGitHub Actionsで試した話について紹介します。 EC事業部のChapterとは mobsfscanをGitHub Actionsで試した おわりに EC
[Prometheus Meetup#3] Victoria Metricsで作りあげる大規模・超負荷システムモニタリング基盤 / Monitoring Platform With Victoria Metrics
[Prometheus Meetup#3] Victoria Metricsで作りあげる大規模・超負荷システムモニタリング基盤 / Monitoring Platform With Victoria Metrics
![[Prometheus Meetup#3] Victoria Metricsで作りあげる大規模・超負荷システムモニタリング基盤 / Monitoring Platform With Victoria Metrics](https://cdn-ak-scissors.b.st-hatena.com/image/square/84b7cf1b224c8d0cb162e2062c4030890d0e37e7/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F4e6d3b7ac55240aca7c91bcd120d2c81%2Fslide_0.jpg%3F14662725)
「技術者を育てる」ことを目的とした、エンジニアを目指す学生のための日本最大のオンラインカンファレンス「技育祭」。ここで株式会社 LIFULL（ライフル）の相原氏が「趣味と仕事の違い、 現場で求められる アプリケーションの可観測性」をテーマに登壇。まずは、仕事と趣味のアプリケーションの違いと、可観測性の基本的な3つのシグナルのうち2つの「Logs」「Metrics」について紹介します。 自己紹介と目次 相原魁氏：今日は「趣味と仕事の違い、現場で求められるアプリケーションの可観測性」について、僕の自室からお送りしようと思います。株式会社LIFULLの相原です。よろしくお願いします。 （スライドを示して）今日の目次ですが、「だいたい趣味のアプリケーションってこういうことをやりがちだよね」みたいな話をした後に、では仕事だとどういうことが求められるのか。その上で、どういう実装をすると可観測性を満たせ
EngineeringOpen SourceMetrics for issues, pull requests, and discussionsWith the new Issue Metrics GitHub Action, you can now track and monitor important metrics related to issues, pull requests, and discussions, such as time to first response, time to close, and more! Data-driven insights At GitHub, we believe that data-driven insights are the keys to success for any software development project.
GitHub - sumup-oss/performance-observer: Generic interface for PerformanceObserver API.
Optimizing the quality of user experience is important for any application on the web. Modern browsers understand that and provide PerformanceObserver API interface that can be used by developers to observe browser performance measurements like the speed of rendering of certain elements or responsiveness of user interactions on the page. Unfortunately due to the early age of the API it lacks stand
Findy Team+は、1万を超える開発チームのデータを基に、Four Keysや開発生産性の可視化・向上を通じて、アジャイルな開発をサポートします。
Keep SLO HealthyOpenTelemetryを基盤にした、問題を解決するための監視プラットフォーム
アジャイルプロセスは、労働生産性を向上させます。しかし、ここで言う労働性生産性は、一般的に言われている「生産性」とは定義が異なります。本稿では、生産性の分類とアジャイルプロセスについて４回に分けて解説して行きます。
top in container. Running the original top command in a container will not get information of the container, many metrics like uptime, users, load average, tasks, cpu, memory, are about the host in fact. topic(top in container) will retrieve those metrics from container instead, and shows the status of the container, not the host. Below shows a container of 2 cpu and 2 Gi running status when stres
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
![EUデジタル市場法：ビッグテックからの返答「クソくらえ」 | p2ptk[.]org](https://cdn-ak-scissors.b.st-hatena.com/image/square/ac2b18011c5c760c7c3b86188a8bb8a88127805f/height=288;version=1;width=512/https%3A%2F%2Fp2ptk.org%2Fwp-content%2Fuploads%2F2024%2F05%2Feu-flag-11.png)
もしかしたらコードメトリクスこそが、僕たちを救ってくれるかもしれない。 - Qiita
負荷試験との向き合い方 - スタディサプリ Product Team Blog
生産性指標をFour Keysから変更した話 - Sansan Tech Blog
Migrating to OpenTelemetry | Airplane
XP祭り2019 B-6 アジャイルソフトウェア開発への統計的品質管理の応用
TechCrunch | Startup and Technology News
Spring Boot アプリケーションにおけるメトリクスの取り方の基本
Four keys を計測する CLI ツールを作った - Qiita
Grafanaを導入して問い合わせ対応や保守業務を効率化した話 - WILLGATE TECH BLOG
Linux perf Profiler UIs
OpenTelemetryをざっくり学んだ - yigarashiのブログ
WEARにおけるSLOを用いた信頼性改善の取り組み - ZOZO TECH BLOG
検索サジェストにおける多様性評価指標とゴール指標の相関について - ZOZO TECH BLOG
Who owns the Service Level?
Observabilityをはじめよう！(後編) 〜Metrics/Logs/Tracesチュートリアル〜 | さくらのナレッジ
Four Keysだけじゃない開発者生産性フレームワーク
メンテナンス担当者が変わるからこそ必要な“可観測性” 基本的なシグナル「Logs」「Metrics」の特徴と適切な使いかた
Metrics for issues, pull requests, and discussions
Four Keysや開発生産性向上ならFindy Team+
Vaxila: OpenTelemetryネイティブの監視プラットフォーム
アジャイル と生産性・１ | Graat（グラーツ）-グロース・アーキテクチャ＆チームス株式会社
GitHub - silenceshell/topic: top in container.
www.google.com
magicki.hatenablog.com
fullap.co.jp
shoko0.px.ebb.jp
web.archive.org
ja.wikipedia.org