カスタマーサクセスのKPIについて考えはじめたころに参考にしたもの

前回ブログの続きです。カスタマーサクセスの仕事について考えていこう!となったとき、ちょうど発売されたのがこの本でした。

見てみると、発売されたのが 2018年6月 とのことなのでちょうどわたしが入社してから3ヶ月たったころのことだったので、これはうおお、みたいな感じで購入して読みました。 もともと取り組んでいた人からすると原文を読んでいて、やっと日本語訳されたか、という感じなのかもしれない。

カスタマーサクセスの本は、ちょうど私が感じていた以下のような課題についてけっこう答えを書いてくれているように思います。

  • カスタマーサクセスが仕事として責任をもつことは何なのか?
  • 他のカスタマーサクセスではどういったことをやっているのか?

カスタマーサクセスが持ちうるKPIが何なのか、というのはこの本がわかりやすかったという記憶は実はあまりなく、ネットで「カスタマーサクセス KPI」とかで調べた記事を読み漁っていました。あと当時感じていたこととしては、結局カスタマーサクセスの指標を調べようとして見ていたものはSaaSのKPIでもあるんですよね。 HiCustomerさんの記事や、前田ヒロさんの記事には特にお世話になりました。

media.hicustomer.jp

hiromaeda.com

今、前どんな記事見てたかな、と思いながら同じキーワードで検索してみたら良さそうな記事が1年前よりめちゃくちゃ増えている印象があって驚きました。自分が興味がある分野について世間も関心が高いというのは大変ありがたい。 というわけで、新しく見つけたこちらの記事が網羅的でとてもわかりやすいと思ったので、リンクを貼らせていただきます。

koni.hateblo.jp

これらを見ながら当時、私が注目した、取ってみたいと思ったKPIは以下のようなものです。

MRR Churn Rate

当月失ったMRR(月次収益) / 先月末時点でのMRR(月次収益)

一般的に、顧客数でChurnを測るCustomer Churn Rateと月次収益で測る MRR Churn Rate があります。両方見るのが本来的にはよいそうですが、Mackerelの売上は顧客数ではなく、顧客がMackerelに登録するサーバー数などに紐づいて増加するので、その要素も含んだ月次収益をまずは見始めるのがよいと思いました。

Negative Churn

Net MRR Churn Rate がマイナスである状態 (当月失ったMRR ー アップセル分のMRR ー 休眠顧客からの復活MRR) / 先月末時点でのMRR

既存ユーザーのアップセルだけで収益アップできている状態であれば値がマイナスになる。算数が苦手な私には直感的には理解しにくい値。アップセルの売上を目標にすると、特定顧客へのアプローチ(商談)によるものだけが対象になりがちですが、CREが実施している既存ユーザーに向けたイベント開催や、ドキュメントの作成、リリースブログの更新など広くマスにアプローチする活動も影響している Negative Churn をCREが見る指標とする方がより今の活動に即していると思いました。今どう思っているかはさておき。

顧客満足度

これも、当時のMackerelチームではみるすべがありませんでした。どうやって顧客満足度を集計するか、ということについてはその後検討されて、NPSを取ろう、ということになります。CREのそもそものミッションである顧客の信頼性を高めるということのダイレクトな指標になると思いました。

こんなことを 2018年8月頃 考えていて社内にフィードバックしていたようなので、じりじりとではありますが、着実に前に進んでいるな、と振り返って思います。

この後、実際に私が取り組んだのは、まずはKPIを整理して見られるようにしようということでした。 MRR Churn Rate、Negative Churn はすでにある値を成形するだけで見られたのですぐにやりました。 顧客満足度についてはNPSを取る準備からはじめました。

実は、カスタマーサクセスの文脈で、けっこう重要視される継続率LTV(顧客障害価値)については当時触れていません。 というのも、Mackerelというサービスの特性上難易度が高い部分があるからです。 これについてはこれからちょっとずつちゃんとやりたいと思っている部分だし、どういう難しさがあるのか、ということもどこかでまとめてみたいです。

次は、たぶんNPSについての記事を書くかなあという気持ちです。

Mackerel CRE の仕事の4軸と私がカスタマーサクセスに重心をおくに至った経緯について

はてなに入って1年がすぎました。 最近、ここ1年くらいでやってきたことをきちんと記録としてアウトプットしておきたいな、というモチベーションが出てきたので、つらつらとブログに残していこうと思っています。 徒然なるままにまとめているので、情報が足りないところやはしょられているところが出てきてしまいそうな気がしますが、質問などはSNSなどから直接いただけたらうれしいです。

はてなのCREでは、カスタマーサクセス担当というような雰囲気で仕事をしている私ですが、ここではそこに至った経緯のようなところを簡単にまとめてみました。

Mackerel のCREでは今、自分たちの仕事を4つの軸で表現しています。 ちなみに、これはあくまで"今"そうなっているだけなので、これからチームやプロダクトの状況によっては変わっていくことももちろんありえます。

  • カスタマーサクセス
  • テクニカルサポート
  • テクニカルアシスト
  • テクニカルコミュニケーション

2018年3月に入社したとき、Mackerel チームではちょうどsoudaiさんという偉大なCREが退職されて、a-knowさんというこれまた偉大なCREが開発チームやその他の職種の人と協力しながらほぼ一人でその業務を担っていました。

当時JOINしたての私には、その姿は脅威的で(今でもそれは変わらないけど)、営業同行などのいわゆるテクニカルセールスの分野から、展示会出展の準備のようなマーケティング分野、日々のテクニカルサポート業務、告知ブログ(ニュースレター)の更新、エバンジェリスト活動などなどあらゆる業務を目にも留まらぬスピードでこなしておられました。当時の私からするとCREという職種がいろいろな分野にひらけた魅力的なものあると感じると同時に、まだすべてをこなすほどの力がない自分がどういう軸で仕事を選びとっていけばよいのか困惑したのも本当です。

そういう悩みをa-knowさんに打ち明けたところ、a-knowさんはa-knowさんで、CREという新しい仕事を社内外に向けどう打ち出して認知してもらうか、というようなところを課題としてもっておられたので、a-knowさんの懐の広さによって受け入れてもらって、隔週で「CREについて考える会」というのを二人で開催することに至りました。

「CREについて考える会」はその名の通り基本的にはフリーディスカッションをしながら、次回に向けてアウトプットの宿題を設けたり、持ち寄ったアウトプットをその場で組み替えたり整理したりを繰り返しました。半年くらいは続けたと思います。

そこで様々なディスカッションを経て、生まれたのがこの4軸なのです。

ここでは、この4軸がそれぞれどのような仕事なのかまで詳しく触れないですが、ひとつ大事なことをお伝えしておくと、私はこの4軸はCREの仕事の中にあるミッション・ビジョン・バリューの一部ようなもので、目の前の取り掛かろうとしていることがCREの仕事か?自分のやるべきことか?を判断するときの軸だと思っているということです。もともとつくりはじめたモチベーションもそういうところでした。そういう意味では今はすごく私を支えてくれている4軸です。

仕事を完全にきれいに分類するための便利な切り口というわけでもないし、CREの中の役職や肩書きというわけでは、少なくとも今はまだなっていないです。今後CREが爆増するようなうれしいことが起きたときには、これらをもとにサブ的な肩書きをつけたりすることもあるかもしれませんが、まだそのような体制にはなっていません。

developer.hatenastaff.com

www.slideshare.net

この4軸が腹落ちしたころ、私はその他の業務とのうまくバランスをとりつつ、実は入社前から一番興味のあった「カスタマーサクセス」に自分の重心を置くことを決めました。

よっしゃカスタマーサクセスやっていくぞ、とこころに決めたわたしの次なる課題はカスタマーサクセス業務をどのように作っていき、どのように評価したり分析したりするのか、というところになるのですが、そろそろ京都に着きそうなので(今は京都出張の新幹線の中)また次のブログにまとめたいです。

Mackerel アドベントカレンダー(全部CRE)やってみた

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

クリスマスイブですね。

さて、Mackerel CREチームでは、この度全部CREでアドベントカレンダーをやってまいりました。

ブログという形で、日々文章を書いてアップし続けた経験ははじめてです。 最後は、アドベントカレンダーをやってみた感想をつらつら書いて終わりたいと思います。

まずはやってみる

はじめにid:a-knowさんに「今年も全部CREやろうと思うんだけどどう?」と言われたときは、いやー無理だろうと思いました。 Mackerelのアドベントカレンダーといえば、毎年すごいエンジニアの人が手を変え品を変え、面白い記事をアップしているものだし、前年のid:Soudaiにいたっては、毎日Mackerelのプラグインについて解説を書くというとんでもない所業をしでかされていた後だったので。 でも無理と思うようなこともできたらいいなと思うことはまずはYESと言ってみる、というスタイルで暮らしているところがあるので、今回もまずはトライしてみたという次第です。

実際にお題を考えたり、ブログを書き貯めたりすることはけっこう大変でしたが、最初に思考停止してYESと言ったおかげで、この体験をやってみることができてかつ最後までこれたのでよかったです。

2日に1回ブログ投稿する

高頻度のブログ更新のためにやったことはこんな感じ。

お題は先に決める

2日に1回ブログを投稿するために、まずは目次を書き出しました。 その日その日にお題を決めていくのは、難しいと持ったので、はじめにあたりをつけておく作業です。 自分が普段こういうものまとめたいなーとか、自分のなかで一度きちんと整理したいなーとか思っていたことを書き出しました。 それが、精査されて、アドベントカレンダーの記事になっています。

自分が今かけるものを書く、すごい記事を目指さない

途中までは、ばくぜんとすごい記事を書かなければ、と思っていました。ところが、すごい記事とはいったい…となってぜんぜんネタが思いつきません。思いついてもそれやるには結構準備や勉強が必要で、そもそも間に合わないのではと思うものばかり。投稿日が近づいた頃、やっと、自分が今かけるものを書こう!憧れるクオリティをめざすまえにやり遂げねば!と開き直ることにしました。ここにたどり着けてよかったです。

探せばヘルプに書いてあるようなこともあるし、誰かがもっとうまくまとめていることもあるかもしれないけど、そういうことじゃないんじゃないかと。 CREは実際に対面でことばでMackerelのあれこれについて説明することが多いです。どこかに書いてあったら説明できるかということそうではないし、自分の言葉でまとめることに意味があると思いました。

毎日ちょっとずつ満遍なく書く

目次が決まってからは、一個ずつ仕上げるのではなく、全部の記事を毎日ちょっとずつ満遍なく書いていきました。

最終的には今自分が本当に書きたい、あったら便利なお題にできたので、比較的に筆が進んで、あとは週末にコツコツ書き貯めたりしてなんとか2日に1回投稿することができました。 この一連の記事、自分ではけっこう満足しています。

毎日のご飯のように書く

先日、Mackerelとはまったく別件で、自炊する話についてブログを書きました。

自炊にはまりながら、料理の本を読んでいました。

この本の第1章にあたるところの最初のタイトルが秀逸です。

夕飯作りの「敗北宣言」をする

手の込んだものを作ることは大変だけどおいしいご飯は食べたい。そういう夜は、敗北宣言をして、ちょっとしたメソッドにしたがって手間のかからないご飯をつくっておいしく食べるというのがこの本のコンセプトです。私のアドベントカレンダーへのマインドに近いので、おもしろいです。

これ以外にも、うんうん頷きながら読めるフレーズがいくつも登場します。自分に刺さったエッセンスを書いておきます。本文そのままではなく、私の解釈です。

  • 構成するもの少なくてもいい
  • こうしとけば絶対においしい、という型をつくる
  • レパートリーは少なくてよい
  • 余計なことをしない

こったものでおもてなしするわけでなく、自分にとって絶対おいしいものを続けられる範囲でつくろう、というマインドがまさに今の自分にぴったりでした。 こういうことって、いろんなことに応用が聞く、なにかを続けるコツなのかもしれないな、と思いました。

というわけで、自分の晩ご飯のようにアドベントカレンダーを書いてしまいました。

最後に

ブログっていいですね。 みんが見られるところに、自分のための記事を書いていることによって、よい効能がいろいろありました。

  • 自分の関心ごとがわかる、人に伝わる
  • 物事への自分の理解度がわかる、人に伝わる
  • 自分の周囲の人との共通言語がうまれる

いちばん新鮮だったのは、はじめてお会いするお客様に、その日の打ち合わせで時間内にどこを重点的にご紹介したらよいか、という質問に「今日集めたメンバーはブログの記事に書いておられたようなことまではなんとなく理解しているメンバーです」と言ってもらえたことです。 こんなふうに社外の人と、ブログの内容をベースに話ができるようになるのか、と目から鱗でした。

直接Mackerelには関係ない感じでラストの記事を書いてしまいました。 自分の晩ご飯のような記事を読んでくださったみなさま、最後までお付き合いいただきありがとうございました。

CREになって考えていることや読んでいる本など。

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

いよいよネタも尽きてきたので、今日は本当にライトなネタです。

先日、MackerelプロダクトオーナーのSongmuさんがex-KAYAC Advent Calendar 2018に向けてこんな記事を書かれていました。

blog.song.mu

その中で、MackerelのMVVについて触れられています。 そのまま引用します。

  • ミッション
    • クラウド監視サービスを提供し、世のエンジニアの開発・運用プロセスを革新する」
  • ビジョン
    • DevOps中核サービスのデファクトとして進化しつづける
    • サービス監視・運用の価値を高め、面白くする
    • 顧客のサービス成長を加速させる
  • バリューズ
    • Infrastructure as Codeを体現する
    • devops文化を根付かせる
    • ドッグフーディング
    • エンジニアをワクワクさせる
    • OSSエコシステムと共生する

このビジョンのおもしろいところ、というか個人的に興味が惹かれているところは、Mackerelが冠としては「サーバー監視ツール」でありながら、バリューの中には「devops」というカルチャーについてのエッセンスが含まれていることです。

このことが気になってしょうがないので、最近はそればっかり考えているような気がします。 あまりさっと本質にたどり着ける器用な人間ではないので、いろいろな本や社内外の事例などをみたり、先輩に教えを請いながら右往左往して少しずつ頭の中に絵が描かれていっているという具合です。

ちょっと調べてアウトプットして、数日後何かを学んで見直すと、全然わかってないじゃん!というのを繰り返す日々。こういうのは楽しい。

Mackerleで、devopsを根付かせるっていったい何をどうやったらいいんだろう?というのはMackerelチームにいながらもいつも考えている課題です。

これを考えていくためには、いろいろ勉強する必要があるなあと感じています。

とはいえ、まずはdevopsそのものから。

Effective DevOps ―4本柱による持続可能な組織文化の育て方

Effective DevOps ―4本柱による持続可能な組織文化の育て方

DevOps教科書

DevOps教科書

ツールについて、カルチャーについて、いろいろな切り口があります。 先日Mackerel Drinkupを開催した際には、参加者の方と「devopsは変更に関する意思決定を早く、効果的にする手法」ということではないか、というは会話したりしていました。よりよい変更であること、それがはやくできる、ということはdevopsにとって重要なキーワードになりそうです。すごく印象に残りました。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE本は今運用ということについて考えるときに非常に学びの多い書籍です。 信頼性を高めるのではなく、コントロールする、という考え方が新鮮です。devopsということとSREということがどういった関わりをもつか、ということについてはまだまだ私の中で整理ができていないですが、「SREはdevopsを実現する具体的な手法のひとつ」とおっしゃられていた人もいるので、どちらも合わせて勉強していきたい概念です。

最近、私はMackerelでの運用設計のベストプラクティスをどうやってつくったらどうかということについてもずっと考えていて、そのための、特にモニタリングとインシデント対応については以下の本を参考にしています。

Webエンジニアが知っておきたいインフラの基本

Webエンジニアが知っておきたいインフラの基本

ソフトウェアエンジニアのための ITインフラ監視[実践]入門 (Software Design plus)

ソフトウェアエンジニアのための ITインフラ監視[実践]入門 (Software Design plus)

どちらも私の前職の先輩方々の教えです。

そして、いよいよ発売される以下の本も非常に楽しみにしています。

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

CREをしていて思うのは、本当にMackerelのユーザにはいろいろな人や企業がおられるな、ということです。

オンプレを運用されているところもあれば、クラウドに移行中のところもあり、クラウドを使いこなし、次はマイクロサービスをうまく運用していくことに目を向けられているところもあります。

devopsの文化に関するところついても、1つのチームで開発からインフラまですべてを見ているところもあれば、開発チームとインフラチームが別個に動いているところ、SREsがいるところ、それぞれの形態のチームが混在しているところ。様々です。

運用設計といっても、何がベストプラクティスになるのかは、こういったシステムや組織の状況によってきっと異なると思っています。

それぞれのユーザの方がどんなフェーズにおられて、今後どういう組織や運用を目指されているのか。 どんな段階を経て、その目指す姿に近づいていくのか。Mackerelというツールやチームがその変化に対していったいどんなお手伝いができるのかというのが、気になってしょうがいない今日この頃です。しかしまずは勉強ですね。

まだこのあたりのことについてきちんと自分なりのアウトプットできるところまで整理できていないので、来年またアウトプットできたらいいなと思います。

ネタがつきたといいながら、結果、来年の抱負のようなエントリーになったなあ。

アラートグループを設定してみる

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

みなさんはアラートグループは利用したことはありますか? 今日はアラートグループの設定方法や通知方法についてまとめてみます。

アラートグループとは

アラートグループとは、サービスやロールごとに同じ時間帯に発生したアラートをグループとしてまとめる機能です。

ユースケース

たとえばゲームシステムなどwebサーバーを何台も横並びにして負荷分散しているような環境をイメージしてください。 webという同じロールに200台などのサーバーが登録されています。かつそのwebサーバー群は同じデータベースサーバーに接続にいっているとします。 そのような状況で、データベースサーバーに障害が発生したとしたら、200台からデータベースへの接続エラーのアラートが一斉に送信されてしまいます。

アラートが大量に発生してしまうと以下のような弊害があります。

  • 大量のアラートを確認するために時間を割いてしまう
  • データベース接続エラー以外の重要なアラートが埋もれてしまう

また、このようなことが頻発すると、アラートを見ると人がアラートに慣れてしまって、重要性だという感覚が鈍ってしまう、という弊害もあります。

このような大量アラートをうまく管理するための機能としてアラートグループが開発されました。

思わぬ効能

アラートグループはこのように、同じロールに大量のサーバーが登録されているようなケースを想定して開発されました。では、ロールに登録されているサーバーが少ない場合や、そもそもサービスに登録されているサーバーが少ないような環境では意味をなさないか、というとそうでもありません。 各サーバーが共有するネットワークやストレージなどに障害があった際や、データベースサーバーに限らずDNSサーバーやログサーバーなど各サーバーが共有する機能に障害がおこったときも200台とはいわずとも、たくさんのアラートが発報されます。 または、サーバーの処理量が増加して、リソース監視の閾値ギリギリをふらつくような事象がおきたときに、同時にアプリケーションログにエラーが出力されているような場合もあるかもしれません。 このような時にも、アラートグループは同時間帯に起きたアラートの可読性がよいので便利です。

アラートグループの設定方法

アラートグループは、アラート一覧画面から設定します。 右上の[アラートグループ設定]をクリックします。

f:id:missasan:20181216172425p:plain

アラートグループ設定画面が表示されます。 右上の[新規アラートグループ設定を作成]をクリックします。

f:id:missasan:20181216172826p:plain

新規アラートグループ設定を作成画面が表示されます。

f:id:missasan:20181216172934p:plain:w450

アラートグループはサービス、ロール単位で設定することができます。

f:id:missasan:20181216173052p:plain:w450

アラートグループの通知設定

アラートグループの通知設定は通知チャンネルに設定できます。 通知チャンネルの編集画面を開くと、[通知するイベント]としてアラートグループを選択することができます。 デフォルトではオフになっています。

f:id:missasan:20181216174642p:plain:w450

この設定を変更すれば、運用の仕方に合わせて通知方法を選択することができます。

  • 通常の個別のアラートとアラートグループを両方通知する
  • 個別のアラートの通知をオフし、アラートグループのみを通知する
  • アラートグループは通知せず、GUIから参照するだけ
  • アラートグループ用の通知チャンネルを別途追加して、アラートグループだけ専用の通知先に分けて通知する

などなど

まずはアラートグループを有効にして様子を見ながら通知をどうするか、適切なものを選んでいくとよいと思います。

可読性のよいGUI

これはイメージですが、このような形で表示されます。 CPU使用率の中に一見だけアクセスログのエラーが混ざっているのもひと目でわかりやすくなっています。

f:id:missasan:20181216175615p:plain

アラートグループをうまく使いこなして、大掛かりな障害にもスムーズに対応できるとよいですね。

API と mkrコマンド を使ってみる

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

Mackerelでは複数のインターフェースを用意しています。 いちばんよく見るGUIの他に、別のアプリケーションなどからMackerelを操作可能にするAPI、そして、APIをより簡単に利用することができる、mkr コマンドです。

APIを叩いてみる

APIには、幅広くMackerelの操作をするためのものが揃っています。

  • サービス
  • ホスト
  • ホストメトリック
  • サービスメトリック
  • チェック監視
  • メタデータ
  • 監視設定
  • 通知チャンネル
  • 通知グループ
  • アラート
  • ダッシュボード
  • グラフアノテーション
  • ユーザ
  • 招待
  • オーガニゼーション

APIcurlでも実行してみることができるので、どんな情報が取得・更新できるのか、使い心地をぜひ試してみてください。 試しに、ホストAPIを使って、指定したサービスとロールに所属するホストの一覧を取得してみます。

curl -H "X-Api-Key: YOUR_API_KEY" -H "Content-Type: application/json" -X GET https://api.mackerelio.com/api/v0/hosts?service=sample-service\&role=sample-role

APIを叩くスクリプトや、アプリケーションを書くと、いろいろなことを自動化できそうでわくわくしますね。

ドキュメトにもっと詳しいことが載っています。

mackerel.io

mkrコマンドを使ってみる

APIを活用するには、何かしらスクリプトや簡単なコードを書く必要がある場合がありますが、そういったことをしなくても、APIを簡単に実行できるインターフェースが mkr コマンドです。

コマンド できること
status ホストの情報を取得します
hosts ホストの一覧を取得します
create 新規ホストを作成します
update ホストのステータスやロールを変更します
throw ホストメトリックまたはサービスメトリックを投稿します
metrics メトリックの値を取得します
fetch 最新のメトリックの値を取得します
retire ホストを退役させます
services サービスの一覧を取得します
monitors 監視ルールの操作を行います
alerts アラートの一覧を取得、クローズします
dashboards ダッシュボードの操作を行います
annotations グラフアノテーションの操作を行います
org オーガニゼーションの一覧を取得します
plugin プラグインの管理をします
help, h ヘルプを表示します

mkr コマンドを使って同じようにホストの一覧を取得する方法をまとめてみます。

今回は、ローカルのmacOSに mkr コマンドをインストールしていきます。インストールには brew を使います。

まずは、brew tap コマンドでリポジトリを追加します。

$ brew tap mackerelio/mackerel-agent

mkr コマンドをインストールします。

$ brew install mkr

mkr コマンドで利用するAPIキーを環境変数で指定します。

$ export MACKEREL_APIKEY=YOUR_API_KEY

mkr コマンドで、先ほどと同じようにサービスとロールを指定してホストの一覧を取得するとこのような感じです。 パッとホストIDの一覧や、ホスト名などを拾ってきたい場合には便利です。

$ mkr hosts -s sample-service -r sample-role
[
    {
        "id": "HOST_ID",
        "name": "sample-host",
        "status": "working",
        "roleFullnames": [
            "sample-service:sample-role"
        ],
        "isRetired": false,
        "createdAt": "2018-04-09T13:08:55+09:00",
        "ipAddresses": {
            "eth0": "IP_ADDRESS"
        }
    }
]

mkr コマンドで監視ルールを変更してみる

mkr コマンドのイチオシ機能は、監視ルールを手元で管理することができる monitors オプションです。 使い方はこんな感じです。

まずは、monitors オプションの中身を見てみましょう。 このように、監視ルールの設定をjson形式で見ることができるのが、このオプションです。

$ mkr monitors
[
    {
        "id": "MONITOR_ID",
        "name": "CPU %",
        "type": "host",
        "metric": "cpu%",
        "operator": ">",
        "warning": 80,
        "critical": 90,
        "duration": 1,
        "maxCheckAttempts": 1,
        "scopes": [
            "sample-service: sample-role"
        ]
    },

(省略)

画面で該当箇所を見るとこんな感じです。

f:id:missasan:20181216160518p:plain

このjsonは手元にファイルとしてダウンロードしてくることができます。 それが monitors pull オプションです。

$ mkr monitors pull
      info Monitor rules are saved to 'monitors.json' (6 rules).

ls をしてみると、monitors.json というファイル名でダウンロードされていることがわかります。

$ ls monitors.json 
monitors.json

jsonファイルはそのまま手元で編集することができます。vi コマンドでファイルを編集してみましょう。 今回は、warningの閾値を80%から85%に緩和してみます。

$ vi monitors.json

さらに monitors diff オプションを使うと、変更箇所の差分を見ることができます。 warningの閾値が80%から85%になっていることがわかりやすく表示されています。

$ mkr monitors diff
Summary: 1 modify, 0 append, 0 remove

 {
   "critical": 90,
   "duration": 1,
   "maxCheckAttempts": 1,
   "metric": "cpu%",
   "name": "CPU %",
   "operator": ">",
   "scopes": [
     "sample-service: sample-role"
   ],
   "type": "host",
-  "warning": 80
+  "warning": 85
 },

このままでは、単に手元のjsonファイルが変更されているだけなので、これをMackerel本体に同期します。 monitors push オプションを利用します。

$ mkr monitors push
      info Update a rule.
{
  "id": "3fRyxz3Nez3",
  "name": "CPU %",
  "type": "host",
  "metric": "cpu%",
  "operator": ">",
  "warning": 85,
  "critical": 90,
  "duration": 1,
  "maxCheckAttempts": 1,
  "scopes": [
    "sample-service: sample-role"
  ]
},

アップデートが成功したメッセージが出力され、実際に画面を見ると、閾値が変更されていることがわかります。

f:id:missasan:20181216160947p:plain

このようにして、手元で監視ルールの書き換え、反映を行うことができます。 また、この monitors.json ファイルを git などに置いておけば、バージョン管理をすることもできます。 その他のCIツールなどと連携して、git で変更がコミットされたら、mkr monitors push をキックするなどのような仕組みもつくれます。

mkrコマンドでは他にもさまざまな操作ができます。詳しくはこちらもヘルプをどうぞ。

mackerel.io

API や mkrコマンド を活用して、普段の作業を自動化してみてはいかがでしょう。

空前の自炊ブーム

自炊ブーム、定期的に訪れています。

今回の自炊ブームのきっかけは、風邪を引いたこと。寒くなって乾燥してきて、周囲に風邪を引いている人が増えていたので、とにかく暖をとるべく膝掛けやらヒーターやらベットカバーやら買って温まったり、家では冷たい水やジュースではなくお茶を飲む、うがいする、マスクする、早く寝る、R1飲むみたいなことをけっこうやったのに、結局風邪を引きました。

寝込みながら、これはもう、あとは食事と運動では、となって、とりあえず、食事のほうから改善をはじめたしだいです。

前回のブームは前職にいたときのお弁当ブームで、500kcal以内のお弁当を作って持参するということをやっていましたが、あまり続きませんでした。 (今は、はてなランチがあるので、昼の自炊は考えなくてよくてハッピー)

自分が自炊が続かない理由TOP1はもちろん「めんどくさい」ですが、TOP5くらいには入りそうな理由に、自炊による健康効果が見えにくい、というのがあります。 頑張って自炊したところで、痩せるでもなく、元気になるでもなく、めんどうになってやめる、というのがこれまでのパターンです。

ただ、今回はちょっと違ったので、報告です。

なんとなく健康効果がある気がしている

あくまでなんとなくですが、以下のような感じがしています。

  • わりと疲れにくい
  • お腹の調子がよい
  • 朝起きたとき疲れてない
  • お菓子そんなに食べたくならない
  • ジャンクそんなに食べたくならない

若さの貯金が切れて、なんともならなくなった分、こういう活動の効果が見えやすくなったんでしょうか。

特に下二つが顕著な気がしてます。 普段さんざんお世話になっているコンビニにあまり立ち寄らなくなったことが地味にうれしいです。まあまあ課金していたというのと、ほぼ私の体はコンビニでつくられています。と言うくらい頼りにしていたので。最近のコンビニはメニューも豊富でおいしくてすばらしいですよね。 自炊ブームがきてからは、立ち寄っても追加食材をちょっと買うくらい。

めんどくさいも減らしてみた

なんども言ってしまいますが、自炊が長続きしないTOP1はめんどくさいからです。 めんどくさいにもいろいろありますが、私の場合、そもそも買い物がめんどくさい、というのもあります。 これを少しでも楽にするために食材お届けサービスを試してみました。 結果を先に言うと、今のところサイコーです。

Oisix のお試し

比較するならここかなーというところの、大地を守る会、らでぃっしゅぼーや経営統合して、今やみんな仲間じゃん、という感じ。

www.oisix.com

お試しセットの感想は、とにかくサイコーじゃん、です。 野菜がめっちゃうまい。うまい気がする。 スーパーで買った野菜と合わせて何品かつくっても、今日の晩御飯のイチバンは味噌汁のカブだったね。というくらい野菜が主役の座をぶんどっていく感じがします。

味はサイコー、体験もサイコー。みんなぜひお試しセット頼んでみてほしいです。 ただ、お値段は日常使いするには悩ましいところでした。

イトーヨーカドーのネットスーパー

そこで、次に試したのが、こちらです。

www.iy-net.jp

食材に限らず、調味料なども商品数が豊富で、頼もしい。 お値段はスーパー価格を維持。配達料もまあよいか、という範囲。

Oisixのような野菜の味で体験を爆上げするような力強さはないですが、スーパーで何買う?何作る?とぶらぶらして、重い荷物を持って帰るという仕事がなくなるだけでも十分です。

なぜ、イトーヨーカドーにしたかというとセブンイレブンで受け取りができると目にしたから。それなら平日の夜も受け取れるじゃん、となったわけです。 しかしまだやり方がわからずで、ことの真偽もまだわかっていません!(調べようよ、という感じ)

ともあれ、このサービスのおかげで、土曜日の早めの時間帯にやまもり食材を受け取りして、週末はしっかり自炊して、平日も野菜を消費したいモチベーションで適度に自炊ができています。もちろん予定によっては外食もします。

とにかく、ネットスーパーのよさは、移動中とか空いた時間にちょいちょいと買うもの選べるところ。 実際にスーパーにいくわけじゃないから、重いとかそういう理由で買うものを制限せずに一度にどかっと買える。 カゴもって歩き回ったり、持ち帰るということがなくなるだけでこんなに買い物をする心にゆとりができるんですね。ネットってすばらしいですね。

まとめ

  • 自炊ってよい
  • 食材配達はブレイクスルー
  • Oisixの野菜は主役級にうまい
  • ネットスーパーは移動時間に食材選べる

なまけものが自炊続けるのってむずかしいですが、いろいろ便利な世の中になってたすかるねって話でした。しかし、なまけものはなかなか治らないので、またブームが去るときがくるやも。自炊ブームとかいってないで、いい加減生活しっかりしないさいって感じですね。