ヘンリーで SRE をやっている id:nabeop です。今回は SRE チームで実施しているパフォーマンス分析会という取り組みについて紹介します。 取り組みを導入した時に解決したかった課題感 パフォーマンス分析会の変遷 現在のパフォーマンス分析会の様子 パフォーマンス分析会をやっていて良かったこと Datadog の Database monitoring によってインデックス不足に気づけた EF ファイル生成の高速化を確認できた パフォーマンス分析会の今後 最後に 取り組みを導入した時に解決したかった課題感 パフォーマンス分析会は筆者がヘンリーに入社してからわりとすぐに始めた取り組みでした。 筆者が入社した当時は一人目 SRE として入社した id:eller が Henry の運用の基礎固めをしてくれていました1。Cloud Monitoring を監視基盤としてアラートの設定など
株式会社ヘンリーでSREをしている戸田（id:eller）です。ひとりめSREとしてヘンリーにジョインしてから約3年、現在ではSREも3人のチームになりました。それでも事業計画に対してはまだ足りていないので、SREエンジニア採用を継続的に行っています。 私がSREチームを作るのは前職から続けて2回目なのですが、いずれの場合でも重要だと考えていることがあり、カジュアル面談でもよく話しています。今回はそのエッセンスをまとめて、同業はもちろん弊社への転職を検討されている方にも参考にしていただければと思っています。 前提としての「チームの目的」 チームを作っていくためには、そのチームの目的や存在意義を明確にする必要があります。SREチームであれば、何のSite Reliabilityをなぜ、どのようにしたいかを明確にする必要があります。 そしてこれらを明確にするためには、事業やサービスについての理
株式会社ヘンリーでオブザーバビリティを担当しているsumirenです。 ヘンリーではHoneycombのProプラン、15億スパンの契約をしています。 GraphQLのresolverなどあまりにスパン量が多いものは導入時に削りましたが、顧客数が増えたり新規機能が増えたことでQuotaを超えてしまうようになってきたため、既存スパンを分析したうえで削減を行いました。 トレース集計やHoneycomb素晴らしさを示すことにつながるため、主にスパンの分析についてシェアします。 スパン削減の戦略 スパン削減には大きく2つの方向性があります。（アプリケーションを直す以外） トレースカットでのアプローチ トレースカットでサンプリングする 例：正常なトレースは1%だけサンプルする、無料ユーザーのトレースは1%だけサンプルするなど トレース横断的なアプローチ スパン種類ごとにドロップの条件をつける 例：S
こんにちは、SREの戸田です。本日は社内で開催したJVM勉強会（運用編）の一部を公開します。 JVM、使っていますか？弊社ではサーバサイドKotlinが活躍しているので、もちろん日常的にJVMが稼働しています。このためサービス運用の一貫で必要になる知識や関連ツールなどをSREないしプロダクトチームに共有することを目的として、この勉強会を開催しました。 図1 勉強会はGoogle Meetでオンライン開催しました パフォーマンス・チューニング サービスを開発していると、この処理をもっと高速化したい！ランニングコストを抑えてユーザ体験の向上に投資したい！というというシーンには多く遭遇しますよね。こうしたユーザが増えてサービスに負荷がかかるようになったことで生じた課題に対して迅速に打ち手が取れることは、とても重要です。 しかし焦ってはいけません。「このコードはめっちゃループしてるし遅そう！」「あ
こんにちは、ヘンリーでSREをしているTODA（＠Kengo_TODA）です。 弊社ではデータの共有は主にNotionを用いています。ただ各システムからデータをかき集めて動的に共有するには、Notionはちょっと向いていないなと思うところがあります。データを通じてシステムや顧客、チームの課題を掴むことはスタートアップの生命線とも言え、SLOやKPIを動的に図示してスタンドアップミーティングなどで共有できる仕組みが必要だと感じていました。 このため、Grafanaを用いた仕組みをGCP上に構築しました。ウェブページを自動生成できるツールからの情報は以前Noteでご紹介したサーバーレス社内サイトで展開していますが、Grafanaであれば動的にコンテンツを構築して提供できると期待しています。 この記事ではGCPないしGrafanaの設定をどのようにしたか、その背景とともに説明していきます。 どの
こんにちは、株式会社ヘンリー SRE（Site Reliability Engineer）の戸田（@Kengo_TODA）です。来週水曜の2023年2月22日に弊社SREにオンラインで質問できる会を開催します！ SRE、名前は一緒でも中身が全く違う説みなさんはSREの業務を説明できますでしょうか？私はSREの業務や責務はけっこう各社各様だという印象を持っています。 例えば弊社SREが何をやっているかは前回の記事である程度触れていますが、Kubenetesが出てこないことや製品コード（Apolloクライアント）に手を入れることを指して「ウチのSREとまったく違う」と感じる方も、生産性とサービス安定性の向上にピンを留めていることを見て「どこも解きたい課題は同じなんだな」と感じる方もいらっしゃったはずです。 これは自然なことだと言えます。「我々が顧客に提供したい信頼性とは何か」という同じ問いに対
株式会社ヘンリーでSREをしている戸田（@Kengo_TODA）です。2022年の7月にジョインして、組織の生産性とサービスの安定稼働をミッションにする「Platform Group」の立ち上げを行ってきました。この半年間を振り返って、どのような改善が行えて何を課題としているかをまとめてみます。 組織の生産性の向上がミッション私たちはPlatform Groupを「技術基盤の開発などを通じ組織全体の生産性を上げる」ことをミッションとして立ち上げました。 当時ヘンリーにはフロントエンドやバックエンドの開発を担うエンジニア社員が15名ほどいましたが、生産性の向上に注力していたエンジニア社員はいませんでした。そのためPlatform Groupではビルドスクリプトや開発ワークフローから本番環境のインフラストラクチャ、社員向け資料作成まで幅広い舞台での生産性向上を担いました。 また従業員が価値創造
NRUG (New Relic User Group) SRE支部 Vol.1 〜俺たちのSREとNew Relic〜
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
