オブザーバビリティには限りがない話
先日NewRelicの清水さんにマンツーマンでオブザーバビリティの話をきかせてもらえるという貴重な経験をした。長年アプリケーションレイヤーも含んでシステム運用の経験があると「あるある」な話なのだが、次のようなことが起こる。 何か不具合や障害が起こる 該当時刻のエラーログなどを見るが情報が少なく、原因を特定する決定打に欠ける 次回、また同じことが起こったときには原因を特定できるように、printfデバッグするコードを大量に埋め込んだバージョンに更新して、デプロイする もう一度起こるのを待つ これは最初の状態が「オブザーバビリティに欠けた状態」だったと言える。めちゃ納得してEnter Sandmanくらいヘドバンして頷いてしまう。 僕の経験上このようなケースを避けるために良い結果を出してきたのは、Javaの例外が出た箇所でスタックトレースを取得しておくことだ（僕らは単にログファイルに吐いておい
噴火直後の御嶽山山頂付近。生き残るために彼女は走った
12時35分、二ノ池の水面に水柱が立つ。二ノ池本館の支配人（当時）、小寺祐介氏が噴火の一部始終を撮影していた 63人が犠牲となった御嶽山噴火から10年。頂上付近で被災しながらも生還した著者が、その決死の脱出行と教訓を綴り、その後の安全登山活動、御嶽山の防災への取り組みなどを追加した『ヤマケイ文庫 御嶽山噴火 生還者の証言 増補版』から、三度の噴火の直後の待避行動を抜粋して紹介しよう。 文＝小川さゆり 必死の疾走 12時50分ころ、私のいたお鉢は不気味なくらい静かだった。 剣ヶ峰にのろしのような黒い雲がかかり、ゆらゆら揺れていた。気持ちの悪い雲だった。 私は、噴火が終わったとは思っていなかった。次の爆発までに「全身の隠れる岩を見つけたい」、ザックの雨蓋から手早くサングラスと手袋を取り出して身につけ、行動に移った。水も飲みたかったが、「隠れる岩を見つけてからでいいや」と思った。 「するべきこと
日本ではKubernetesやCI/CDなどが幻滅期に、インダストリクラウドやインフラ自動化は過度な期待。「日本におけるクラウド・プラットフォームのハイプ・サイクル」2024年版発表
日本ではKubernetesやCI/CDなどが幻滅期に、インダストリクラウドやインフラ自動化は過度な期待。「日本におけるクラウド・プラットフォームのハイプ・サイクル」2024年版発表 調査会社のガートナージャパンは、「日本におけるクラウド・プラットフォームのハイプ・サイクル：2024年」を発表しました。 ハイプサイクルとは ガートナーのハイプサイクルは、技術の登場から安定までを5つのステージに分けて説明したものです。5つのステージは、「黎明期」から始まり、「『過度な期待』のピーク期」「幻滅期」「啓発期」「生産性の安定期」まで。この途中で消えていく技術もあります。 同社はグローバルだけでなく国別などさまざまな切り口でハイプサイクルを発表しています。今回発表されたのは日本のクラウドプラットフォームにおけるハイプサイクルです。横幅の関係上、図を2つに分割しました。まずは前半部分。 黎明期にはFi
OSSでオブザーバビリティを実現する (Grafana Stack x OpenTelemetry on Kubernetes) - RAKUS Developers Blog | ラクス エンジニアブログ
はじめに こんにちは。SREの gumamon です！ NewRelic、Datadog、モダンな監視ツール(オブザーバビリティ)って良いですよね。弊社もKubernetes(k8s)等を利用した環境が増えてきた折、そろそろ必要になってきたのですが、NewRelic、Datadog等のクラウドサービスはランニングコストが高くなりがちです。 では内製できないかやってみよう！・・・というようなことを昨年度から取り組んでいたのですが、やっとこさ形になりましたので改めてブログで紹介させて頂こうと思います。 今回ご紹介するのは、大まかなシステムの構成と設計時の観点です。各コンポーネントの詳細や工夫できた点などについては、改めて別の記事でご紹介できればと思います。 また、「オブザーバビリティとは？」や「試行錯誤の過程」については、以前執筆した以下のブログをご参照ください。 tech-blog.raku
Findy Team+を活用した開発生産性向上の取り組み - ZOZO TECH BLOG
はじめに こんにちは。会員基盤ブロックの小原田です。弊社では、ZOZOTOWNという大規模なモノリシックシステムをマイクロサービスへリプレイスする取り組みを進めています。私が所属する会員基盤ブロックでは、ZOZOTOWNの会員情報を扱うマイクロサービスの開発と運用を担当しています。 会員基盤ブロックでは、開発生産性の向上を目指し、約半年間にわたり様々な取り組みを行ってきました。本記事では、会員基盤ブロックが開発生産性の向上のために実施してきた施策と、その成果について紹介します。 目次 はじめに 目次 開発生産性の向上に関する取り組みの背景 Findy Team+を用いた調査 会員基盤ブロックが抱える開発生産性の課題 サイクルタイム短縮の取り組み PRの変更行数を100行以下にする レビューを優先する仕組みの整備 ブレスト会の実施 品質向上についての取り組み Goガイドラインの策定 テストカ
負債あるモノリスのオブザーバビリティに組織で向き合う
2024/09/25に、オブザーバビリティ実践までの道のり〜各社の課題とアプローチ方法とは？～で発表した、moppの資料です。
逆コーンウェイ戦略とDevOps, Microservices, Agile
コーンウェイの法則 「コーンウェイの法則」というのを知ってますか？Jim Conplien の組織プロセスパターンにも登場しますが、”組織の構造がソフトウェアの構造に反映する“あるいはその逆、“ソフトウェアの構造が組織の構造に反映する”というものです。Wikipedia によると、 Conway’s law is an adage named after computer programmer Melvin Conway, … “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations”
KPIのモニタリング自動化と運用体制の整備 - ZOZO TECH BLOG
はじめに こんにちは。データシステム部/推薦基盤ブロックの佐藤 (@rayuron) です。私たちはZOZOTOWNのパーソナライズを実現する推薦システムを開発・運用しています。推薦システムごとにKPIを策定していますが、データの欠損やリリース時の不具合によってKPIが意図しない値を取ることがあるため定常的に確認する必要があり、これをKPIのモニタリングと呼んでいます。 先日、推薦システムの実績をLookerでモニタリングするというテックブログで推薦システムのKPIをモニタリングする方法を紹介しましたが、運用していく中でいくつかの課題が見えてきました。本記事では、より効率的かつ効果的なKPIのモニタリングを実現するための取り組みについて詳しくご紹介します。 はじめに 改善の背景と課題 背景 課題 トレンドを考慮した異常検知が不可能 モニタリングの設定が面倒 アラート対応フローが不明確 サマ
PyCon JPはいますぐ生まれ変わるべき
昨年からトラブルが続いているPyCon JPですが、9月27日のPyCon JP 2024を前にして、また新しい火種が生まれました。 2024年9月22日、PyCon JPの技術に対する不正の告発、並びに技術者と大衆に対しての警鐘（以下、怪文書2）というタイトルの記事が突如として公開されたためです。 この記事は、python_bokume2というアカウントで公開されていることから、およそ4ヶ月前の2024年5月31日にpython_bokumetsuというアカウントで投稿された採択されるプロポーザルを書こう!!（現在はアカウントごと削除されている。以下、怪文書1）を書いた人と同じ人物による投稿であることがうかがえます。 最初に記事に関しては、インターネットでいうところのいわゆる完全なる怪文書であったのに対して、今回の怪文書2では、具体的な登場人物の名前やSlackのログなど、実際におこなわ
NewRelicとRDS Performance Insightsを活用してパフォーマンス改善する！ - クロスマート Tech Blog
1. はじめに 2. 具体的な監視ツール NewRelic Amazon RDS Performance Insights 3. データ増加に伴う対応 パフォーマンス最適化のプロセス 1. トレース分析 2. SQLクエリの検証 具体的な改善 4. まとめ 最後に 1. はじめに ｺﾝﾁｱ~！バックエンドエンジニアの石垣です。 2024年7月、弊社サービス「クロスオーダー」は、当月利用店舗数が90,000店舗を突破しました。 (※)当月利用店舗数：これまでの累計ではなく、当月でクロスオーダーを利用し発注してくださっている店舗数を指します。 xmart.co.jp 過去、弊社テックリードたけじいさんが投稿した「弊社が急成長しそうなのでAPM(NewRelic)を検討してみた」というブログでは、継続的なデータの増加や、アプリケーションやデータベースへの負荷の高まりに直面していることを取り上げま
PyCon JPにおける登壇者採択に関する見解
一般社団法人PyCon JP Association 理事の寺田です。 昨年のPyCon JP APAC 2023および来たるPyCon JP 2024（以下、「本イベント」といいます）の登壇者選定に関して、インターネット上で疑義が一部で取り沙汰されている状況を確認しております。 私たち一般社団法人PyCon JP Association（以下、「当法人」といいます）は、PyCon JP 2024において、参加者の皆様、企業スポンサー、Pythonコミュニティ、そして運営に携わる多くのボランティア主催メンバーを含むすべての関係者に対し、安心してカンファレンスにご参加いただける環境を提供したいと考えています。本イベントの登壇内容の選定に関するプロセスについて、当法人の見解をお伝えします。 一般社団法人PyCon JP AssosiarionおよびPyCon JPについて当法人は日本国内外の
PyCon JPの技術に対する不正の告発、並びに技術者と大衆に対しての警鐘 - Qiita
概要 本文章は、一般社団法人PyCon JP Associationが主催したPyCon APAC 2023の開催に際し、そのプロポーザル選考過程において行われていた不正行為の告発を目的とするものです。 本文章が対象とする読者は技術者、及び、公衆です。技術者は技術『愛好家』との付き合い方について一考をするべきであり、公衆は「専門家ではないにも関わらず技術の専門家のフリをする不正な愛好家」に対して無自覚であるべきではない、という警鐘を鳴らすため、並びに、一般社団法人PyCon JP Associationの公衆に対する不正を告発するため、本文章を公開します。 本文章は、Qiitaが目指す、学びのある情報を技術者に共有することで、よりよい技術者コミュニティの形成を目指す内容であるため、Qiitaのガイドラインに沿った形式でQiita.com上で公開します。 告発する内容 PyCon APAC
SRE Kaigi 2025
SRE Kaigi 2025は、「More SRE !」をテーマに開催される、SREを中心として知見の共有と参加者との交流を楽しむ技術カンファレンスです。 SREは世界的に注目され続けている領域であり、現場によって抱える課題や取り組みはそれぞれ異なります。 そうした多様な事例から得られた知見を共有する場は、まだまだ不足している現状です。 「さらにSREに関わる技術者の活躍の場を増やすため」 「さらにSREを理解し、興味を持っていただける技術者を増やすため」 この2つの“More”を目指し、参加者の皆様とコミュニティをより盛り上げていけたらと思います。 SREに関わる技術者の皆様、またSREに興味を持っている技術者の皆様、ぜひこの機会にSRE Kaigi 2025にご参加ください！ 開催に関しての最新の情報は、Xの @srekaigi で発信していきますので、ぜひフォローしてください！
テストサイズで再考する「テストピラミッド」 Googleが提唱する効率的な自動テスト戦略
ソフトウェアエンジニアリングの第一人者・和田卓人氏が、効果的な自動テスト戦略について解説しました。ユニットテストの定義の曖昧さから生じる問題点を指摘し、Googleが提唱する「テストサイズ」の概念を紹介。さらに、テストピラミッドの再解釈と最適化について論じ、テストサイズに基づくアプローチがビルドパイプラインの効率化にもたらす利点について解説しました。前回の記事はこちら。 短時間でのテスト実行 和田卓人氏：ということで、じゃあ、次にいきます。短い時間で到達するというアジェンダ、3ポチ目ですね。 「信頼性の高い」、これはテストの結果に嘘がないという話でした。「実行結果」、これは信号として、また問題箇所の絞り込みとしてのテストの実行結果にこだわろうという話でした。そういったテストを、短い時間で到達する、信頼性の高い結果に短い時間で到達する状態を保つ。短い時間で。 ユニットテストの定義の曖昧さ と
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
株式会社マイベストのDatadog導入事例
オブザーバビリティの探求 〜性能劣化から始まった旅路〜
実例から学ぶセキュリティ監視
監視ツールを迷ったら CloudWatch から始めてみるのもありなのでは
ビジネスに必要な全てを担い、 自分の専門性を見つけ出す フルサイクル開発者のあり方@技育祭 秋 / how-find-own-speciality-in-full-cycle
APMツールとしてDatadogを選定した理由
