メトリックの種類

この記事は、Mackerel アドベントカレンダー（全部CRE）の6日目の記事です。 今回は、Mackerelで取ってこられるメトリックの種類と簡単な概要についてまとめます。

Mackerelでは、まずはメトリックを取ってくることから始まります。 メトリックを取得する方法はいくつかあります。

システムメトリック

Mackerelのエージェントをメトリックを取得したいサーバー上にインストールすると、エージェントが標準でいくつかのメトリックを取得してきます。項目はOSによってことなりますが、たとえば、ロードアベレージ、CPU使用量、メモリー使用量、ディスクIO、ネットワークインターフェースの使用率、ファイルシステムの容量などが取得できます。 これらのエージェントが標準で取得するメトリックをシステムメトリックと読んでいます。

カスタムメトリック

Mackerelには、OSやミドルウェアに特化したより詳細なメトリックを取得するための公式のプラグインがたくさんあります。

mackerel.io

インストールはとても簡単で、Linuxサーバーなら yum コマンドでインストールできます。 Windowsサーバなら、よく使うものはエージェントに同梱されています。 このプラグインを利用して取得されたものは、Mackerelではカスタムメトリックとして扱われます。

ちなみに、ホスト上のエージェントを介して取得できるこれらシステムメトリック、カスタムメトリックを合わせてホストメトリックと呼ぶこともあります。

サービスメトリック

システムメトリックやカスタムメトリックは、エージェントを介して投稿され、エージェントが動くホストに紐づくメトリックです。 サービスメトリックは、エージェントを介さずにMackerelのAPIを利用して投稿するメトリックになります。 メトリックを投稿する際は、投稿する先のサービスを選びます。

サービスメトリックは、以下のようにサービス詳細にて確認できます。

この例は、HTTPのレスポンスタイムですが、他にも、PVやビジネスのKPIなどアイディア次第でいろいろなメトリックをMackerelに投稿、グラフ描画できます。 APIを実行する場所も、サーバー上でアプリケーションを動かしたり、AWS Lambda や GAS などサーバーレスで実行できるサービスを利用したりと方法は問いません。

まとめ

• システムメトリック：mackerel-agentが標準で取ってくるメトリック
• カスタムメトリック：mackerel-agentのpluginで取ってくるメトリック
• サービスメトリック：ホストに依らないAPIを叩いて投稿するメトリック

次回は、Mackerelでサービスの異常に気づくための監視ルールと、チェックプラグインについてまとめます。

サービスとロールが効いてくるところ

この記事は、Mackerel アドベントカレンダー（全部CRE）の4日目の記事です。 今回は、サービスとロールがMackerelの中のどういったところに関わってくるのかについてまとめています。

Mackerelでの管理の単位はサービスとロール

Mackerelでは、あらゆる設定にサービスとロールを使います。 グラフの描画、監視ルール、通知など基本的な機能はもちろん、アラートグループといった新しい機能でも設定の単位はサービスとロールです。 これから新しく増える機能もサービスとロールと紐づいて設計されていることが多いと思うので、どういうふうにこの2つの概念が使われるのかをおさえておくとMackerelの設定を考える上でとても便利です。

ロールでまとめる見る「グラフ」

ロールグラフ

Mackerelでは、取得してきたメトリックをグラフ描画することができます。 グラフの見方にもいくつか種類があるのですが、その中でも、「ロールグラフ」はサービスとロールを設定してはじめて描画されるグラフです。 ロールに紐付けをしたホストの各種メトリックが、ロールグラフの中で、重ね合わせだったり、積み上げのグラフで見ることができます。

カスタマイズしたグラフ

また、Mackerelでは、関数を使ってカスタマイズしたグラフを表示することもできます。 ここでも、ロールが効いてきます。 たとえば、ロールに含まれるホストメトリックの平均をとったり、ロールに含まれるホストメトリックの中の最大、最小を取り出したりすることができます。 つまり、WebサーバーやDBサーバーの平均や最大・最小の負荷を見ることができるのです。 その際に使う関数は role(roleFullname, metricName) です。 関数には他にもいろいろあるので、ぜひヘルプをご覧ください。

ロールグラフをダッシュボードに

これらのロールグラフや、カスタマイズしたグラフを、カスタムダッシュボードに並べて、毎日システムの状態を眺めたり、月次のキャパシティプランニングの場で使ったりすることもできます。 「Webサーバーにもう3台追加しよう」とか「DBサーバーのメモリ足りてないんじゃない？」というようなロールを主役にしたそれにフィットしたグラフを見ながらみんなでワイワイ会話することができます。

サービスやロールに「監視ルール」を適用

監視ルールとは、取得してきたメトリックに対して、何を障害とみなしアラートとするかを決める"条件"にあたる設定です。 条件は、たとえば「CPUの使用率が70%を超えたらWarning」というようなものです。監視の世界では、一般的にあるような設定ですよね。 Mackerelの一つの特徴とも言えるのは、この監視ルールをサービスやロール単位に設定できるというところです。

スクリーンショットの例では、監視ルールがそれぞれ以下のとおりに適用されています。

• CPU％ は「sample-service」サービスの「sample-rore」ロールにのみ適用
• filesystem は「すべて」のサービスに適用
• connectivity は「すべて」のサービスに適用、ただし「missasanbook」サービスについては除外

なので、このようにサービス、ロールを指定してうまく監視ルールを作っておけば、ホストを適切なサービス、ロールに所属させればすぐに監視ルールを適用させることができます。 サーバを1台構築したからといって、CPU、メモリ、ディスクなどそれぞれの監視ルールを都度設定しなくてもよいので楽ちんです。

Mackerelでは、どのサービス、ロールに所属させるかはエージェントの設定ファイルに書いておくことができます。

サービスにごとに「通知」先を指定

通知とは、起票されたアラートをメールやslackなど人が気が付ける方法でお知らせする仕組みです。 この通知の設定でも、指定したサービスに関わるアラートについては、どこに通知する、といった設定ができます。

この設定では、全てのサービスに関わるアラートをslackに通知しています。

サービスとロールがかかわるその他の機能

アラートグループ

アラートグループというアラートを同時間帯にまとめる機能があります。 これを、まとめる単位もサービスとロールです。

フィルタ

各種フィルター機能を使うときにも、サービスとロールが活躍します。

いかがだったでしょうか。とにかくいろんなところで登場するんだなーということは伝わったのではないでしょうか。 次回はMackerelで取ってこられるメトリックの種類と概要についてまとめます。

サービスとロール

この記事は、Mackerel アドベントカレンダー（全部CRE）の2日目の記事です。

12月に入りました。今月はMackerel CRE アドベントカレンダーに挑戦します。目新しい記事というよりは、ゆるやかに、あらためて自分の理解を自分の言葉で整理するためと、これからもっとお会いしていくであろう未来のMackerelユーザの方々とお話するときに役立ちそうなものをまとめていくような記事を書き溜めていきたいと思います。

qiita.com

第1回目はMackerelの「サービス」と「ロール」という概念についてです。 Mackerelを理解するなら、まずはここからといったところでしょうか。

サービスとロールとは？

サービスとロールとは、監視対象や取得したメトリックをグルーピングする単位です。 Mackerelの中でとても重要な概念で、アラート通知の条件設定やグラフの描画など、いろいろな設定に関わります。 Mackerelを活用していく上で、はじめにこのサービスとロールをどのような形で切り出して行くのかをぼんやりとでも考えておくと、あとの設定がとても楽でわかりやすいものになります。

サーバーが提供する「サービス」

「Mackerelはサーバー監視サービスです。」とよく説明しています。 サーバー監視という言葉を使うと、どうしても対象のサーバーに目がいきがちですが、サーバーとはもともと、サービスを提供するもの、という意味です。 Mackerelでは、サーバー1台1台というよりも、そのサーバーが提供しているサービス全体にフォーカスできるような設計になっています。

サービスは、サーバーが提供しているある程度のまとまりのある機能のことです。 厳密には、管理のしやすさや何かしらの制約によって、まとめたりより細かいコンポーネントごとに分けるということもあるので、必ずそうとは言えませんが、イメージとしてはこのような感じです。 例えば、Webサーバーをたてて、コーポレートサイトを運用しているのであれば、コーポレートサイトがサービスにあたります。ソーシャルゲームであれば、ゲームタイトルごとの環境がそれにあたるでしょう。 はてな にとっては、「はてなブログ」や「はてなブックマーク」がサービスにあたります。 実際に、はてな社内用 Mackerelの「サービス」の設定には、「はてなブログ」や「はてなブックマーク」にあたる設定が入っていて運用に活用しています。

サーバーには役割「ロール」がある

クラウド環境などを利用していると、ひとつのサービスを複数台のサーバーで運用しているということはよくあります。 私もお客様のところにお伺いすると、まず「担当されているサービスは何ですか？」と聞いたあと、そのサービスが何台程度のサーバーで、どんな構成で運用されているのかということをよく聞きます。 この「どんな構成で？」というところが、Mackerelでいうところの「ロール」にどんなものがあるのかのヒントになります。

例えば、以下のようなものです。

• Webメディアサービスを運用しています
• ロードバランサーを前段にWebサーバーを3台並列に動かして負荷分散をしています
• Webサーバーはデータベースに接続しています
• DBサーバーは、マスターDBサーバーが1台、そこからレプリケーションする参照用のスレーブDBサーバーが2台あります

など。 この中に含まれるロールは、ざっくり以下のようなものでしょうか。もちろんこちらも管理のしやすさなどから、DBサーバーはマスターDBサーバーとスレーブDBサーバーに分けてもよいでしょう。あくまで例です。 本来なら、これ以外にも管理サーバーやログサーバーなども入ってくるかもしれません。

• ロードバランサー
• Webサーバー
• DBサーバー （または マスターDBサーバー と スレーブDBサーバー）

そして、この役割を担う個々のサーバーをMackerelでは「ホスト」と呼びます。 図にするとこんな感じです。

次のブログでは、実施にサービスとロールがMackerelの中でどのように登場してくるのか、どの設定に関わってくるのかというところをまとめてみようと思います。

私のブログはこんな感じでゆるゆると進みます。どうぞみなさまお付き合いくださいませ。

コンサートと村上春樹「意味がなければスイングはない」の話

先日、ちょっと気が向いて、とある大学の管弦楽団の定期演奏会に行ってきた。 とくに団員の誰かにゆかりがあるというわけでもないのだけれど、その日の朝にSNSで見かけて、これは最近の少しもやもやしたような煮詰まった気持ちをやり過ごすのによいかもしれないと思ったのだ。実際、とてもよくやり過ごせた。 それに、1000円程でオーケストラの演奏を聴けるというのはリーズナブルで、とてもよい機会だとも思った。

開催されたコンサートホールは広くて立派で客席が3階まであって、私と連れはゆかりのない大学の楽団の定期演奏会ということでなんとなく気後れして、3階の、そのなかではよさそうな席を、当日券を売る団員さんに選んでもらって座った。 ゆったりとしていて、居心地がよくてすばらしかった。

クラシックにとくに詳しいわけでもない。でも、私はほんとうならいわゆるハイコンテクストな理解が必要そうなものをさほど理解もなく楽しむことが得意だ。 絵画も写真も落語もプロレスも、人に誘われていくあまり知らないアーティストのライブとかもそうだ。そこにあるものだけで楽しめる。（今気づいたが、そこにあるものだけで楽しめるようなタイプのアーティストや落語家やレスラーを好きになりがちだ。しかしそれはいったいどんなタイプなんだ。分類できるのか。）

クラシックのコンサートを聴くときは、少し早めに席についたら、パンフレットに書いてある曲紹介を読み込んだり、指揮者の人の写真を眺めながら、もしかすると今日はこんな演奏になるのかもしれないな、と想像する。 曲がはじまったら、うーむこの曲はロマンチックでいいなとか、ディズニーみたいでたのしいなとか、旋律がわかりやすくていいなとか、やっぱりメインの曲が一番演奏がうまいなとか、自分はさっきの曲がほう好きだなとか、アンコールというものは明るい曲をやるからいいなとかそんなことを思いながら楽しむ。考えていることを書きあげると教養のなさとしまりのなさがバレてしまう。

今日はそんなことを思い出していたら、なんだか音楽についての本が読みたくなったので、本屋で、村上春樹の「意味がなければスイングはない」という本を買ってみた。タイトルがよくて目に止まった。「音楽についてそろそろ真剣に、腰を据えて語るべきではないか」という帯もよかった。腰を据えて語るコンテクストをもたない私は深く理解している人に教えて欲しいのだ。

意味がなければスイングはない (文春文庫)

少し読んでみた限りだと、これが実によくて、音楽の教養がなくても、ほほうそれは面白いなとか、ははあそんな解釈があるのかとか、いい曲なんだろなとかいって知らないことを知らないまま楽しく読ませる。私がクラシックのコンサートを楽しむときと同じテンションや取り組み方で読める。 村上春樹さんは文章がうまいなぁ、とまた中身のない適当な感想が出てしまう。

気が向いたので、というような徒然なるままの日常ブログを書いてみた。

SRE本 6章 (輪読会予習)

社内の有志数人でゆるっと読書会をしているのでその予習資料です。 これまで、テキストメモにしたり、qiitaに下書きしたり、いろいろしてたのですが、今回は はてなブログで書いてみたので、せっかくなので公開します。

(私の解釈によるものや誤読が紛れているかもしれませんので、そのこころづもりで見ていただけたらうれしいです。)

モニタリングの章なので、ところどころ心にしみる箇所がたくさんありました。 大まかにはモニタリングをいかにシンプルに、かつ根本原因にクリティカルパスでたどり着けるようにメンテナンスしていくかという内容だったと解釈しました。 最後に書いてあった、それほど重要ではない進行中の問題はダッシュボードにしてアラートの対象にしない、というのは参考になるなと思いました。

分散システムのモニタリング

定義

• モニタリング
• ホワイトボックスモニタリング
• ブラックボックスモニタリング
• ダッシュボード
• アラート
• 根本原因
  • ソフトウェアの欠陥やヒューマンエラーで、修正されれば同じことが同じように起こることはないと確信できるもの
• ノードとマシン
  • 一つのサーバやコンテナで複数のサービスが同居していることがある
• プッシュ

モニタリングの必要性

• 長期的なトレンドの分析
• 時間や、実験グループ間での比較
• アラート
• ダッシュボードの構築
• アドホック(限定的な、その場限りの)な振り返りの分析の進行（でバッキングなど）

モニタリングはビジネス分析やセキュリティ侵害の分析にも役立つが、SREの文脈では取り扱わない。 システムが壊れているときは、モニタリングとアラートを組み合わせて人に通知できる。人は時間を割いて対応をする。アラートは「少し何かおかしい」というレベルであげるべきではない。 アラートによるページの発生が頻繁になると、以下のようなことを招く。

• 従業員が勘ぐる
• 表面だけを見る
• やってきたアラートを無視する
• ノイズに隠れた「本物の」ページを見逃す
• ノイスは迅速な診断と修正の妨げとなり、障害が長引く

モニタリングにおける妥当な期待値の設定

• 10-12人程度のSREチームでも、1-2人はモニタリング担当となる。
• 問題がないか画面をみている必要があるよな状況は避ける
• 自動的に因果関係を検出しようとするような「魔法の」システムは避けている
  • 仕組みを紐解いて理解できないようなシステムのことかな？
• エンドユーザのリクエストレートの予想外の変化を検出するルールは例外
  • シンプルなルールで検出できる
• 複雑な依存関係の扱いはうまくいったことがない
  • データベースの速度が落ちているなら、データベースの速度低下アラートを出す。そうでなければWebサイトの全体的な速度が落ちているというアラートを出す、など。
• 重要なのは、「プロダクション環境での問題から発する人間へのページ、基本的な切り分けと深いでバッキングに至るクリティカルパス」を、チーム全員でシンプルかつ包括的なものに保つ
• ノイズを減らし、シグナルをはっきりさせておく

症状と原因

• 症状が起きている故障で、原因はなぜ故障したか
• 「何が」と「なぜ」の区別がモニタリングルールを書く上で重要

ブラックボックスとホワイトボックス

• ホワイトボックス：システムの中で何が起きているかを細かく把握するのには便利。目に見えないけれど起きている問題や、今後起きうる問題を発見するのに便利。システムのボトルネックを探すことなどにも使える。これを元にシステムの改修もできる。
• ブラックボックス：人間のページを発生させるのに便利。すぐに人間が動かないといけないのは、目に見える問題だから。

4大シグナル

• レイテンシ
  • リクエストを処理してレスポンスを返すまでの時間
• トラフィック
  • システムに対するリクエストの量
• エラー
  • 処理に失敗したリクエストのレート
• サチュレーション
  • リソースがどれだけ手一杯になっているか

テイルレイテンシに関する懸念

• パーセンタイルも見ようねっていう話

適切な計測の粒度の選択

• 適切に粒度を選びましょう
• あまり細かく取りすぎると分析が大変

可能な限りシンプルに、ただしやり過ぎないこと

NG

• さまざまなメトリクスに閾値、アラートが設定されている
• 考えられる原因(起きていないものも含め)を検出して知らせるための追加コード
• 考えられる原因のそれぞれに関連するダッシュボード

GOOD

• シンプルで予想しやすいルール
• ほとんど使われないルールやデータの集計は消す
• 収集されているけど、どのダッシュボードにも表示されずアラートにも使われていないメトリックは削除候補のひとつ

複雑に組み合わせず、疎結合に保つのがGOOD。

原則のとりまとめ

書かれている質問をすると問題が明るみになるかも。

アラート関連

• ルールが検出する事象は、緊急で、対応が可能で、ユーザ影響があるものか？そのルール以外では検出されないものか？
• アラートは間違いなくユーザ影響があることを示しているか？
• アラートに対して、取れるアクションはあるのか？
  • そのアクションは緊急か？翌朝まで待てるか？
  • そのアクションは安全に自動化できるか？
  • そのアクションは長期間にわたる修正効果を待つもの？それとも短期間だけ有効な回避策？
• アラートでページが発生する人は複数いたら、不要なページが混ざっている

ページ関連

• ページは緊急であるもの。対応できるページは1日に数回が限度。
• すべてのページは具体的な対応が可能でないとダメ
• すべてのページには知性が必要でないとダメ。そうでなければ自動化しよう
• ページは新たなものかこれまで見たことがないイベントに関するものであるべき

長期にわたるモニタリング

システムは変化する。

• 今後も起こりうるうか？頻繁に起こりうるか？
• 根本原因に対策すべきか？
  • その対応のために一時的に可用性を落とすべきか？

などを長期の視点で検討していこう。

BigtableのSRE：過剰なアラートの物語

• アラートが出すぎて短期的な対応しかできなくなったで、一時的に可用性を落として、対策に取れる時間を増やしたら結果、より短い時間で解決できた例

Gmail：スクリプト化された予測可能なレスポンスの手動送信

• 暫定対応をとるか、根本対策をとるかで議論した例。マネージャーはそこのバランスをきちんとおさえておく必要がある。

長期的な視点

すべての問題を独立したイベントととらえず、全体をみて長期的に戦略をたてましょう。 ページの頻度などを四半期に一度程度見直しましょう。

まとめ

メールアラートの価値は限定的で、ノイズ化するのも簡単。 それほど重要でない進行中の問題はダッシュボードでモニタリングしてアラートの対象にしない、ということもよい。（アラートグループ的な考え） アラートは差し迫った本当の問題だけにしよう。

イベントブース出展（長時間の立ち仕事）を乗り切る

明日からAWS Summitです。

Mackerelのブースでポロシャツを着て立っている人になります。会期は明日から金曜日までの3日間です。

www.awssummit.tokyo

ブースで立っているというのはなかなか大変で、わたしはめちゃくちゃ体力があるわけではないので、うまく工夫して3日間をすごす必要があります。

先日も、クラウドコンピューティング EXPO に出展して、3日間立ってきました。その際にやったことと、その効果を雑に書き残しておきます。とりあえず疲労で腰痛になることをなんとしても避けたかったのと、今後のために立ち仕事の知見をためたかったので、けっこういろいろ試しました。

もちろん普段からスポーツをされていたり、身体が出来上がっておられる方には、無用の長物ということもあると思います。

普段はほぼ座りっぱなしだけど、まれに立ちっぱなしのことがあるという稀な人向けです。

個人的にやっておいてよかった！効果ある！と思った順番に書いていきます。

スニーカーを新調する

足をがっつりサポートして、かつ足の裏から疲れがこないようにクッション性の高いスニーカーが欲しくなり、新しく購入しました。

購入したのはこちらのNIKEのスニーカーです。

www.nike.com

ランニングシューズです。 

底のクッション性もとても高く、最近増えているくつ下っぽいデザインなのですが、かなりしっかりとしたサポート感があります。

お店の方曰く、長距離ランでタイムを縮めることを目的に開発しているとのこと。

そりゃ立ち続けるのにもいいわけです。

かなり気に入っています。靴重要です。

サロンパス 

【第3類医薬品】サロンパスAe 140枚

人にお勧めされてはじめて使いました。めちゃくちゃ有名ですが、使ったことはありませんでした。夜、足裏、足の甲、ふくらはぎ、腰、肩に貼りまくって寝ました。すると、驚くほど次の日に痛みが残らない！

しっかりした湿布臭で、開封した瞬間は、くさっ！！と驚きましたし、寝巻き、寝具への匂い移りもなかなかのものがありましたが、その効果の前には何も言えません。

足首サポーター

バンテリンサポーター 足くび用 ブラック ふつうサイズ 足長 24~26cm

 いよいよ疲れも蓄積された3日目にだけ使いました。

昔、山登りの下りではしゃいでしまって、捻挫したときに買ったものです。

私はもともと捻挫がくせになっていて、マッサージや整骨院などに行くとよく「足首がゆるい」と言われます。痛めないための予防に、激しい運動やランニングをするときなどにたまに使っています。

これをしていると足首ががっちりサポートされて、立っているのも少し楽になります。

スポーツ用レギンス 

スリムウォーク (SLIM WALK) ビューアクティ(Beau Acty) 美脚&美尻レギンス ブラック M~Lサイズ(leggings,Black,ML) 着圧 レギンス スポーツ

本来はランニングする際に使用するレギンス。こちらも3日目だけ使いました。

下半身の筋肉が全体的にサポートされるし、姿勢もよくなるのでかなり効果がある感じがしました。シュッとしたズボンを履かれる方には向かないかもしれませんが、それなりに生地も薄いので、ゆるめのズボンの下になら履いておくことも可能です。

締め付けも強いのはとてもよかったのですが、3日間ずっと履き続けるのは逆に疲れそうなので、最終手段という感じがしました。

事前に少し運動する 

余裕があると、普段でも筋トレやヨガをしているのですが、ここ最近はすっかりさぼっていたので、リハビリとして直前の週末に少し運動をしました。

眠っていた筋肉が生き返った感じがして、個人的にはやっておいてよかったと思いました。

むくみ防止靴下  

おそとでメディキュット ハイソックス M 着圧 加圧 靴下 美脚効果 おでかけ用

室内用の方が有名なメディキュットですが、外出用の靴下もあったので、2日目に使用してみました。むくみを防いで疲れも緩和されるかと思ったのですが、正直締め付けもそれほど感じられず、効果がはっきりとは感じられませんでした。

やはりハードに立ち続ける人向け、というよりハイソックスを履きながら足の形をスッキリ見せる、というのが本来の目的なんだろうなとしみじみ感じました。

まとめ

• ランニングウェア、シューズで全身固めたら3日間立ちっぱなしに向いてそう
• どんだけ身体を痛めやすいんだ。もっと運動しよう
• 明日もがんばるぞ

Mackerel の CRE になりました。

2月末に株式会社ハートビーツを退職して、3月から株式会社はてなで働きはじめました。三浦（id:missasan）です。

退職して入社して慌ただしくしていたらうっかり1ヶ月たってしまいました。瞬く間でした。 知っている人は少し前の話という感があるかもしれないですが、あらためてお伝えさせてください。

ハートビーツを退職しました。

ハートビーツには6年くらい在籍しました。でも6年しか勤められなかったなあ、と悔しいさもあります。

運用エンジニアもセールスもなんなら採用活動もイベント出展もしたし、経営層ともいつも身近でディスカッションできるすごく恵まれた立場で、なんだかほんとうに幅広くさまざまなことを経験させていただきました。 経験もスキルもノウハウも人とのつながりもたくさん大事なものをいただきました。 基本的にはハートビーツのサービスや働く人やエンジニアリングの美学の部分が大好きで、入社してからずっと可能な限りここで長く働いてやろうと思いながら暮らしていたので、自分が転職するなんてほんとうに意外です。

なぜ転職を決めたかというと理由はいくつかありますが、あらためてシンプルに考えると、お客さまの困りごとを技術で解決するということに自分が関わり続けたいと思ったからです。

今のハートビーツは、技術サイドとビジネスサイドの役割分担がしっかりできはじめていると思っています。 それはハートビーツにとってすごくよいことで、これまでは優秀なエンジニアが兼任していたセールスの業務を（だからこそよいところもいっぱいあった。でもエンジニアは大変だったと思います）、今はセールスのプロたちが担ってくれています。

私はもとはSIerでエンジニアでしたが、ハートビーツではエンジニア職として入社したわけではないので、徐々にビジネスサイドの役割に移行していったわけなのですが、お客さまの課題解決に注力したい私の気持ちと、セールスとして結果を出すために必要な業務の違い（バランスの違い）にいつも揺れていました。

そんなことをなんとなく考えながらも頑張っていたのですが、あるとき気づいたら「あ、転職しよう」と決めていました。 私は直感的に行動するところがあるので、根拠の前に心が決めてしまってからは、すごく早くいろいろと進めました。

転職について急な申し出だったにもかかわらず、ハートビーツのみなさまが本当に快く盛大に送り出してくれて、よい会社に勤めさせてもらったな、と改めて感謝の気持ちでいっぱいです。

送別会などに際して、私がファンであるハートビーツの人たちから、みうらさんのすごいところは、いつもお客さまの課題にフォーカスして考え続けられるところだと言ってもらえたことや、サーバ監視というある意味同じ業界として関わりのあるMackerelのチームに転職することは、ちゃんと生きてるってことだ、と言ってもらえた言葉は、ほんとうに宝物のように大事にしています。かなりうれしかったです。ありがとうございました。

Mackerel の CRE になりました。

はてなに応募したきかっけは「あ、転職しよう」となった私が、改めてはてなの採用ページで id:a-know さんの以下のエントリーを見たことです。

これを読んだときの私の感想は、なにこれ共感しかない!!!!出会ってもうたああ!!!!!!!! です。

Mackerelの主要な顧客でありユーザーである、いわゆるインフラエンジニア・SREという肩書きで仕事をしているエンジニアは、多くの企業において少数精鋭であり、それが故にインフラの安定運用というミッションに対しても、その少ない人数のメンバーに大きな責任がのしかかっている......というのが現状だと考えています。そんなお客様に寄り添い、お客様が今置かれている状況を少しでも良いものにしていくために私たちにできることをおこなっていく、ということが、我々MackerelチームのCREのミッションになります。

セールスエンジニア 改め Customer Reliability Engineer (CRE) になりました - Hatena Developer Blog

そうなんです。そうそうそうなんです。私が仕事するときにいつもじんわり考えてるのはこれなんです。 さらには、

• 顧客目線であること
• エンジニア職であること
• Mackerel が自社開発の SaaS であること

という CRE という職種や Mackerel 自体の魅力もあいまって、グサグサ刺さりました。

まさに「お客さまの困りごとを技術で解決するということに自分が関わり続けたい」という想いが叶う稀有な仕事だと感じました。

とりあえずa-knowさんに会って話したい！と思い立ち、次の瞬間にはアポをとるべく動いておりました。

実際にお会いしたa-knowさんは間違いなく「歩く信頼性」といった感じのすてきな方で、すぐに、この人とチームで仕事がしたいな、と思いました。 どこの馬の骨ともしれない私のアポを快く受けてくださって、まかないランチまで食べさせていただいて（胃袋もつかまれた）、a-knowさん、songmuさんありがとうございました。

その後、きちんと選考いただき、今に至ります。

CRE は新しい職種です。 意義や方向性やKPIもこれからどんどん作ったり変えたりして磨きをかけていける面白い仕事です。

Mackerel は toB のサービスである一方で、「エンジニアをワクワクさせる」という toC っぽい視点も持った魅力あるサービスです。

これからはこの Mackerel というサービスの CRE として、なるべくたくさんのエンジニア、もちろんそれ以外のロールの方にもよりよい、よりワクワクしたユーザ体験をお届けすべく奮闘してまいりますので、みなさまどうぞよろしくお願いします！